OpenClaw 接入 DeepAI API 中转站：返回 tool_calls 但工具不执行的排查

OpenClaw 接入 DeepAI API 中转站 或其他 OpenAI-compatible Provider 后，最容易让人困惑的一类问题是：你直接用 curl 调上游接口，模型能返回合法 tool_calls；但在 OpenClaw 会话里，Agent 只说“我正在写文件”或“我会执行命令”，实际 write、exec 等工具没有被调用。这个问题不是单纯的 Base URL 或 Key 错误，而是要分清模型返回、API 中转、OpenClaw 解析和本地工具调度四层。

问题背景：curl 有 tool_calls，OpenClaw 没有执行

在 openclaw/openclaw Issue #67745 中，用户配置了自定义 OpenAI-compatible Provider，直接请求 Provider 的 /chat/completions 接口时，带 tools payload 可以返回合法 tool_calls，返回里的 finish_reason 也是 tool_calls。但在 OpenClaw 里要求写文件或执行命令时，Agent 只给出自然语言承诺，文件没有创建，命令也没有运行。

Issue 描述里还提到几个重要证据：/tools 命令能列出 write 和 exec；模型连通性测试能返回 OK；gateway 状态也健康。这说明问题不在“有没有工具”或“模型能不能聊天”，而在 OpenClaw 是否把模型返回的工具调用解析出来并交给本地工具执行器。

用 DeepAI API 中转站先确认上游是否真的返回 tool_calls

DeepAI API 中转站在这里的价值，是把“模型层是否正确”先剥离出来。你需要在日志里确认请求体包含 tools，工具选择策略是 tool_choice: "auto" 或等价配置，上游响应里存在 choices[0].message.tool_calls，并且 finish_reason 是 tool_calls。如果这些都成立，就说明 API 中转站没有把工具参数丢掉，模型也确实决定调用工具。

上游成功响应应关注：
finish_reason: "tool_calls"
message.content: null 或空文本
message.tool_calls[0].function.name: "write" / "exec"
message.tool_calls[0].function.arguments: JSON 字符串

如果 DeepAI API 中转站日志里没有 tools，那要回到 OpenClaw Provider 能力检测和请求构造；如果有 tools 但上游只返回文本，说明模型或模型映射不支持工具调用；如果上游已返回 tool_calls，问题就更可能在 OpenClaw 的响应解析和工具调度。

四层排查模型

1. Provider 配置层：Base URL、模型名、API 类型是否指向 OpenAI-compatible Chat Completions，并且模型被标记为支持工具。
2. 中转站透传层：DeepAI API 中转站是否保留 tools、tool_choice、stream 设置和模型名映射。
3. 模型响应层：响应是否是标准 OpenAI Chat Completions 形态，尤其是 tool_calls 字段位置和 arguments 格式。
4. OpenClaw 调度层：客户端是否把 finish_reason=tool_calls 解析为本地 write、exec 等工具调用，而不是把它当普通文本结束。

最小复现：用 write 和 exec 两个工具测试

不要一开始就拿复杂自动化任务排查。建议用两个最小指令测试，一条写文件，一条执行命令：

Write "hello" to test.txt
!echo hi

同时做三组对比：第一，直接 curl DeepAI API 中转站或上游 Provider，看是否返回 tool_calls；第二，在 OpenClaw 会话里执行同样意图，看是否生成文件或运行命令；第三，检查 OpenClaw 日志里是否出现工具调度事件。如果第一组成功、第二组失败、第三组没有工具事件，就基本可以排除 Key、网络和模型基础连通性。

常见坑位

• 自然语言承诺不等于工具调用：Agent 说“我会写文件”，但没有 tool_calls 或没有工具调度事件，就不会产生真实动作。
• Provider 能力检测过于保守：自定义 OpenAI-compatible Provider 可能被客户端判断为不支持工具，从而不发送 tools。
• arguments 格式不标准：OpenAI Chat Completions 的 function.arguments 通常是 JSON 字符串，某些兼容服务返回对象会导致解析失败。
• 流式和非流式差异：非流式 curl 成功，不代表 OpenClaw 的流式解析也能正确聚合 tool_calls 增量。
• 模型映射混乱：中转站把模型映射到另一个不支持工具的模型时，日志里要能看到实际路由后的上游模型。

DeepAI API 中转站的日志建议

为了帮助 OpenClaw 用户快速定位，DeepAI API 中转站最好在日志里把工具调用相关字段单独展示：是否收到 tools、工具数量、工具名列表、tool_choice、上游 finish_reason、是否存在 tool_calls、arguments 是否是可解析 JSON。这样用户一眼就能知道问题在 API 层还是 OpenClaw 客户端层。

推荐日志摘要：
tools_count = 2
tool_names = ["write", "exec"]
tool_choice = "auto"
finish_reason = "tool_calls"
tool_calls_count = 1
arguments_json_valid = true

处理建议

1. 升级 OpenClaw 到包含 OpenAI-compatible tools 相关修复的版本。
2. 先关闭流式或用非流式请求对比，确认是否是流式 tool_calls 增量聚合问题。
3. 确认 DeepAI API 中转站没有把 function.arguments 从 JSON 字符串改成对象。
4. 把直接 curl 的完整响应、OpenClaw 日志、DeepAI 中转站日志放在一起比较。
5. 如果中转站和上游都返回标准 tool_calls，就重点检查 OpenClaw 的 Provider 能力标记、工具调度器和版本变更。

SEO 与产品文档建议

搜索“OpenClaw tool_calls 不执行”“OpenAI-compatible Provider 工具不调用”“DeepAI API 中转站 OpenClaw tools”“finish_reason tool_calls 但文件没写入”的用户，通常已经具备较强的开发背景。他们需要的不是泛泛的接入文档，而是能分辨模型、网关、客户端、工具调度边界的排查清单。把这些字段写进 DeepAI API 中转站文档和日志说明，会显著提升开发者信任感。

参考资料

• OpenClaw Issue #67745：Custom OpenAI-compatible provider returns valid tool_calls directly, but OpenClaw never executes tools
• OpenClaw Issue #8923：Custom OpenAI-compatible providers don’t send tools parameter for function calling
• OpenClaw OpenAI Provider 文档

总结

OpenClaw 接入 DeepAI API 中转站时，如果直接请求能返回 tool_calls，但会话里工具不执行，排查重点应从“API 是否可用”转向“OpenClaw 是否发送 tools、是否解析 finish_reason、是否调度本地工具”。用 DeepAI API 中转站日志确认上游已经返回标准工具调用，再结合 OpenClaw 本地日志检查工具调度链路，才能快速定位问题所在。