Gemini 工具调用后提示 missing thought_signature，怎么修？

Gemini 第一次请求正常，函数调用后却报缺少 thought_signature，应先检查两次请求之间保存的 model content。把带签名的原始函数调用 part 放回历史，再追加函数结果。只保存函数名和参数，可能丢掉下一轮需要的状态。

本文针对工具调用的后续请求，依据 Google 的思考签名文档，核验日期为 2026 年 9 月 14 日。不同代际模型和 API 的要求不同，不能认为所有 Gemini 模型只要没有签名就会返回同一种 HTTP 400。

按实际接口找到字段

报错可能写成 snake_case，而原生 REST 请求使用 camelCase。在原生 generateContent JSON 中，thoughtSignature 位于 part 上，与 functionCall 同级。Python SDK 对象通常使用 thought_signature；兼容端点则可能把元数据放在提供商扩展字段中。

不要因为报错里的拼写不同，就把字段搬到猜测的位置。第一次调用成功，只能证明第一次请求被接受。后续请求才会用到历史，此时纯文字存储或适配器可能已经丢失必要状态。

先保留 model 回应，再追加工具结果

历史记录中应先包含模型返回的完整内容，后面再放携带真实 functionResponse 的 user content。具体结构以 Google 函数调用指南为准。保留 parts 的原顺序，不要从聊天组件显示的内容重新拼装。

后续调用的顺序可以这样理解：

user: 原始任务
model: 原始返回内容，包括 functionCall 和带签名的 part
user: functionResponse，包含真实执行结果
model: 下一次响应

这是用于说明的合成序列，不是可执行请求，也不是真实 API 测试记录。实际调用必须使用该任务收到的响应。不要用随机字符串，或其他人会话中的示例替换签名。

并行调用不要求每个调用都有签名

在当前文档所述的 Gemini 3 工具流程中，每一步的第一个函数调用 part 携带必需的签名。并行回应里的后续函数调用 part 不需要各自附带签名。如果本地校验器要求每个并行 part 都有独立签名，反而可能拒绝正确响应。

保留原来的分组，例如带签名的调用一、调用二，然后返回各自对应的结果。如果两个调用来自同一条并行 model 回应，不要重排成调用一、结果一、调用二、结果二。顺序执行的多个步骤则不同：每个新 model 步骤都要保留自己的返回状态。

这对把所有工具统一转换成独立消息的中间件尤其重要。通用表示虽然方便，也可能丢掉原始分组。需要保存足够的信息，以便重建目标端点要求的原生消息序列。

用了 SDK，也要检查自己保存了什么

保留完整响应和历史时，官方 SDK 的会话处理可以管理签名。但如果应用把响应转成文字、只提取函数参数，或存入删减过字段的 JSON 结构，这项保证就不能覆盖整个应用了。

对比三个对象：提供商原始响应、应用保存的历史，以及下一次真正序列化的请求。找出带签名的 part 第一次消失或改变的位置。常见检查点包括数据库字段、消息过滤器、回调处理和不同 API 之间的适配器。

最小复现可以使用只返回固定本地值的无副作用函数，完整走一轮函数调用。调试目标是验证状态续接，不是在排查序列化时重复执行付款或部署。本文也没有声称某个第三方客户端版本已修好这类问题。

降低思考强度不是通用解法

不要认为把思考设为 minimal 就可以免除工具流程的签名要求。应按具体模型与接口查看思考功能文档。修改生成参数，并不能恢复已经丢掉的状态。

Google 对部分导入的调用轨迹提供了特殊处理方式，但如果应用丢失的是自己刚收到的模型响应，特殊跳过标记不应成为常规修复办法。先修正历史保存过程，否则应用可能只是隐藏了校验症状，仍在持续丢弃有用元数据。

也要区分签名缺失和函数结果格式错误。结果名称错误、调用对应关系缺失或工具 schema 无效，可能产生不同报错。保留完整状态码和错误正文，不要仅凭 HTTP 400 就套用同一套排查。

怎样验证修复结果

修正序列化后，用原来出错的路由和 SDK 版本，再跑一遍同样的小型函数流程。确认后续请求被接受，模型回答也使用了函数结果。如果依赖并行函数，还要单独验证并行场景；单调用成功不能证明并行流程正常。

记录测试属于本地结构校验，还是真实 API 调用。语法检查不能证明提供商会接受请求。如果经过网关，除非实际测试过并能说明机制，不要宣称网关能自动补回客户端丢失的状态。

模型费用和接入信息可参阅 Gemini 3.8 API 指南。若是另一提供商的类似错误，参阅 Claude 签名排查；不能把 Claude 原生字段直接复制到 Gemini 消息中。

常见问题

每个并行函数调用都必须有签名吗？

不需要。文档所述 Gemini 3 并行流程把必需签名放在该步骤的第一个函数调用 part 上。原样保留返回的分组即可。

为什么错误写 snake_case，REST 却用 camelCase？

错误用语和 SDK 属性名可能与原生 REST 字段不同。应遵循实际接收请求的接口 schema。

换提供商能解决吗？

不一定。如果客户端在发送前就丢掉了必要状态，换目的地也不能恢复这些状态。先检查请求处理过程。