OpenClaw 通过 DeepAI API 中转站 或其他 OpenAI-compatible 网关调用不同模型时，最容易忽略的是 provider-specific metadata。普通聊天只看 messages 和 content 就够了，但 Gemini 这类带 thinking / reasoning 的模型，在工具调用链路里还可能要求保留 thought_signature。一旦中转层丢掉它，第一轮工具调用能成功，第二轮回传工具结果却会 400。
extra_content.google.thought_signature 需要在 tool result 回传时原样保留。GitHub Issue 背景：第一次工具调用成功，回传结果时报 400
OpenClaw GitHub 仓库中有一个已关闭且标记为 completed 的 Issue：用户通过 Google Vertex AI 的 OpenAI-compatible endpoint 使用 Gemini 3 Flash 作为 subagent 模型。模型第一次能正常返回 tool call，但 OpenClaw 把工具结果发回模型时，Vertex API 返回 400，提示函数调用缺少 thought_signature。
根因是 Gemini 在 thinking 启用时，会在 assistant message 和 tool call 的 extra_content.google 中返回 thought_signature。后续把 tool result 发回模型时，这个签名必须原样带回。OpenAI-compatible 适配层如果只保留标准字段，而丢掉 extra_content，就会破坏工具调用 roundtrip。
为什么 OpenAI-compatible 仍然需要保留扩展字段
OpenAI-compatible 是一套通用协议，但不同模型供应商仍然可能在响应里放入扩展字段。对于工具调用，扩展字段常常不是“可有可无的元数据”，而是下一轮请求必须带回的状态凭证。
- 标准字段：
tool_calls、function.name、function.arguments。 - Gemini 扩展：
extra_content.google.thought_signature。 - 风险点：中转层、SDK、日志清洗或消息转换时把扩展字段丢掉。
- 结果：tool result 回传时模型无法验证思考状态，返回 400。
DeepAI API 中转站用户应该怎么理解这个问题
如果你通过 DeepAI API 中转站统一接入不同模型，建议把工具调用分成两层看：第一层是标准 OpenAI-compatible 工具协议，第二层是具体供应商的扩展状态。中转站可以统一鉴权、路由、日志和额度，但在转发工具调用时，不能随意丢弃 provider-specific 字段。
对于 Gemini、Claude、OpenAI 新模型或其他带 reasoning 的模型，工具调用链路中可能存在类似签名、reasoning id、tool state、cache id 等字段。它们未必都显示在 UI 中，但可能决定下一轮请求能否通过。
排查步骤：确认 thought_signature 是否被保留
- 抓取第一次模型返回的 assistant message，确认 tool call 中是否包含
extra_content.google.thought_signature。 - 抓取 OpenClaw 内部 transcript，确认这个字段是否被存储。
- 抓取 tool result 回传给模型的下一轮请求，确认同一个签名是否被原样带回。
- 检查中转站或代理是否做了 JSON 字段白名单过滤。
- 升级到包含修复的 OpenClaw 版本，重新跑同一个工具调用用例。
错误表现和误判
- 普通聊天正常：只能说明基础 messages 链路可用。
- 第一次工具调用成功：说明模型能生成 tool call，但还没验证 tool result roundtrip。
- 第二轮 400：优先看工具结果回传格式和 provider-specific metadata。
- 不要只换 Key：这个问题不是认证失败，而是请求体缺少必要状态。
中转站和网关的实现建议
如果你维护 DeepAI API 中转站、模型网关或 OpenAI-compatible adapter，建议遵循这些原则：
- 转发工具调用消息时，保留未知但安全的扩展字段。
- 不要只按 OpenAI 标准字段重建 tool_calls，避免丢失 provider metadata。
- 对不同 provider 增加回归测试：tool call → tool result → final answer。
- 日志里记录字段是否存在，但不要泄露完整敏感签名。
- 确保同一 provider、同一模型、同一会话内才重放这类签名，避免跨路由污染。
为什么这对 Agent 工作流很重要
Agent 工具调用不是一次请求就结束。它通常包含模型选择工具、外部工具执行、工具结果回传、模型继续推理和最终回答。任何一环丢失上下文或签名，都会让工作流看起来“不稳定”。对于 OpenClaw、Claude Code、Dify、n8n 这类 Agent 工具，模型能聊天只是第一步，工具 roundtrip 稳定才是生产可用的核心。
参考资料
- OpenClaw GitHub 仓库
- OpenClaw Issue #77925：Gemini tool calls missing thought_signature
- OpenClaw 请求丢失历史 messages 排查
- DeepAI API 中转站教程导航
总结
OpenClaw 接入 DeepAI API 中转站或其他 OpenAI-compatible 网关调用 Gemini 工具时，遇到第二轮 tool result 400，不要只看 Base URL 和 API Key。真正的关键可能是 extra_content.google.thought_signature 是否被保留并回传。跨模型中转时，provider-specific metadata 是工具调用可靠性的基础，不能被适配层随手丢掉。