Claude 提示 thinking block 中的签名无效时，先检查实际回传的结构化会话。保留原始思考块及其签名，不要用界面上的文字重新拼接。如果报错明确提到 different conversation，还要检查前面的 system 提示词、工具定义和消息是否改变。
这两种原因需要区分：即使签名字符串原封不动，带会话绑定的内容块也可能因为前置内容被改写而失效。本文依据当前思考功能排错文档，核验日期为 2026 年 9 月 14 日。以下是协议排查方法，不代表所有模型都执行相同的绑定规则。
修改历史之前，先读完整报错
记录错误类型、完整错误文字、request ID、模型标识和客户端版本。确认是第一次请求就失败，还是工具调用、恢复会话或编辑历史之后才出现问题。找到这个分界点，有助于定位丢失或改变状态的处理环节。
| 现象 | 优先检查 |
|---|---|
| 返回工具结果后失败 | assistant 的完整内容是否保留下来 |
| 流式调用后失败 | 内容块结束前是否收齐签名事件 |
| 生成摘要或修改提示词后失败 | 报错是否明确指出会话绑定 |
| 只在某个适配器中失败 | 各协议转换处实际序列化的请求 |
不要把私人会话历史或完整签名贴到公开 issue。先提供脱敏后的块类型和转换过程通常更有用。需要对比自己的请求处理过程时，可在本地保留未改动的诊断副本。
保留 assistant 的完整内容
原生 thinking 块包含 thinking 和不透明的 signature。redacted_thinking 块使用 data，不能当作普通可见文字处理。思考文字为空，也不能单凭这一点判断块已损坏。 构建多轮对话历史时，assistant 消息必须包含原始响应中的全部 content 块（含 thinking 类型块），若在转发或存储环节丢弃了非文本块，再次请求时服务端签名校验将失败，这一行为在 Claude 原生 API 与 等兼容端点上均有记录。
官方思考与工具调用流程文档说明了这些内容块在后续工具轮中的作用。应保留原值、原顺序以及 assistant 回应中的其他内容。不要总结思考块、替换签名，或根据界面的纯文字记录重建消息。
下面的 Python 片段演示拿到响应后如何保留内容，不是完整请求，也不是真实 API 测试。请根据安装的 SDK 调整序列化方式；原则是保留返回内容，而非只提取 text 字段。
assistant_content = [block.model_dump(exclude_none=True) for block in response.content]
messages.append({"role": "assistant", "content": assistant_content})
# Append the real tool_result message next, following the native tool protocol.
不要往示例请求里填一个自己编的签名。字符串看起来像签名，不代表它是提供商签发的有效状态。如果原始内容已经丢失，应查明丢失原因，不能靠编造内容补齐。
流式处理不能只收集文字
流式集成需要正确组装协议支持的内容块事件。Messages API 参考文档说明，signature_delta 在对应的 content_block_stop 之前到达。只保存 text_delta 或可见思考文字的收集器，无法保留与完整 SDK 响应对象等价的结构。 在处理流式响应时，thinking 块与 text 块属于不同的事件类型，需要分别捕获并按顺序拼接，部分聚合网关如 OpenRouter 或 会在流式层面对事件结构做透传处理，开发者应参考各平台文档确认 event type 的实际字段映射关系。
检查断流、取消或界面重绘是否让客户端把尚未组装完的内容块标记为完成。调试时保留块索引和事件顺序。屏幕上出现一段可读的回答，并不意味着可以把未完成的块交回 API。
使用官方 SDK 支持的流式处理方式，可以减少自行组装事件的工作。但如果应用之后又把历史压成纯文字或筛掉内容块，SDK 也无法保护这些数据。对比内存中的响应与下一次实际序列化的请求，两者之间的转换往往最值得检查。
会话绑定要单独排查
当前文档说明了 Claude Fable 5.1 的会话绑定签名规则：对 2026 年 8 月 31 日及以后创建的账户，以及设置了文档所述绑定控制的请求执行该校验。这是特定模型的规则。报错明确指出 different conversation 时，即使思考块本身没改，前面的 system 指令、工具定义或消息被改写，也可能导致失败。
这类流程应采用只追加新内容的历史记录，或使用文档支持的服务端压缩与上下文编辑机制。不要在本地大幅重写历史后，认为保留签名就一定能。官方也提供特定模型的恢复控制，但它们不是能复制到所有 Claude 请求中的通用参数。
本文不把开启特殊恢复 beta 作为第一步。应先确认模型与完整报错确实符合该功能的适用范围。会丢弃内容块的恢复选项可能改变保留的状态，需要作为明确的应用设计选择来评估。
不要把切换模型一律判为无效
当前排错文档说明，目标模型无法读取的其他模型内容块，可能被丢弃，不一定产生会话绑定错误。因此，“切换模型一定会破坏思考签名”说得过于绝对，也不能据此断言所有跨提供商路由都不兼容。 当请求从 claude-3-5-sonnet 切换至 claude-3-7-sonnet 后出现 invalid_signature 错误，根本原因通常是历史消息中残留了旧模型生成的 thinking 块而非模型本身不可用，OpenRouter 与 的错误响应体中均会返回具体的 block 校验失败位置，可据此定位问题。
记录原模型、目标路由和实际报错，再查看相关兼容性文档。如果客户端在 Claude 原生消息与其他 API 格式之间转换，应核实必要元数据是否保留，不能猜测一套通用字段映射。
工具结果配对是另一层独立校验。如果报错点名的是没有结果的工具 ID，应使用缺少 tool_result 的排查方法，而不是修改签名。Gemini 也有自己的思考签名字段，不能与 Claude 原生 signature 互换。
常见问题
直接修改签名值能修好吗？
不能。应把它视为提供商返回的不透明状态。原块还在时，恢复完整内容，并查找修改或丢弃它的转换逻辑。
为什么第一次成功，第二次请求才失败？
后续请求可能丢失了结构化思考数据，也可能改变了带会话绑定的前置内容。对比第一次完整响应与真正发出的后续请求，不要只看聊天文字。
新会话成功，能证明问题已经解决吗？
不能。新会话可以隔离损坏的历史，但如果适配器仍会剥离必要字段，下一轮工具调用可能再次失败。结束排查前，应验证内容保留过程。
参考来源
- ofox 文档：模型目录 — https://docs.ofox.io/zh/develop/models
