OpenClaw 通过 DeepAI API 中转站 接入不同 OpenAI-compatible 模型时，工具调用不是只看 tools 是否支持，还要看模型是否支持并行工具调用。一个很典型的坑是：客户端给所有模型都发 parallel_tool_calls: true，但某些模型只允许一次调用一个工具，于是直接返回 400，后续 exec、read、write、browser 等工具都可能进入异常状态。
parallel_tool_calls。GitHub Issue 背景：parallel_tool_calls:true 让所有工具失效
这个问题来自 OpenClaw Issue #37048。用户在 OpenClaw v2026.3.2 中配置 NVIDIA NIM 上的 moonshotai/kimi-k2.5，该模型通过 OpenAI-compatible API 提供服务，但只支持单工具调用。OpenClaw 在请求里发送 parallel_tool_calls: true 后，服务端返回：
400 This model only supports single tool-calls at once!
更麻烦的是，第一次 400 后，Agent 后续可能继续出现 Tool not found、LLM request timed out、工具不可用等连锁现象。用户尝试在配置里写 parallelToolCalls: false 或 requestParams.parallel_tool_calls: false，旧版本还会提示 Unrecognized key。临时可用的回退办法是降级到 2026.2.25。
已修复线索：PR #39356 做了 API-gated 参数注入
OpenClaw PR #39356 已合并修复这个问题。修复重点不是简单删除 parallel_tool_calls，而是把参数注入限制在兼容的 OpenAI 风格 payload 上：openai-completions 和 openai-responses。同时，PR 支持 parallel_tool_calls 和 parallelToolCalls 两种别名，并处理不同配置层级的优先级覆盖。
PR 也明确了边界：它不会自动在 provider 返回 400 后重试，不会修改非 OpenAI payload schema，也不会改动无关的工具分发逻辑。也就是说，站长和开发者仍然需要知道每个模型是否支持并行工具调用。
DeepAI API 中转站场景下怎么判断
- 先确认请求是否到达 DeepAI API 中转站，路径通常是
/v1/chat/completions或兼容接口。 - 查看请求体是否包含
tools和parallel_tool_calls: true。 - 看目标模型返回的错误字段。如果明确提示 only supports single tool-calls，就是模型能力不匹配。
- 升级 OpenClaw 到包含 PR #39356 的版本，或对该模型配置
parallelToolCalls: false。 - 重新跑一个只会触发单个 read 或 exec 的最小工具任务，确认返回 200 且工具链路完成。
错误请求和正确请求的区别
容易失败的请求通常长这样：
{
"model": "kimi-style-model",
"messages": [...],
"tools": [...],
"parallel_tool_calls": true
}
对只支持单工具调用的模型，应让请求显式禁用或根本不注入该字段：
{
"model": "kimi-style-model",
"messages": [...],
"tools": [...],
"parallel_tool_calls": false
}
如果客户端、SDK 或中转层会自动添加参数，就要做模型能力 gating：只有确认模型支持并行工具调用时才添加；否则保持单工具调用模式。
中转站应该承担什么，不应该承担什么
DeepAI API 中转站适合统一 Key、模型路由、日志、限流、计费和部分 OpenAI-compatible 协议适配。但 parallel_tool_calls 属于模型能力参数：不同模型、不同供应商、甚至同一供应商不同版本都可能不一样。中转站可以帮助你在日志里看清请求体和错误响应，也可以做路由策略，但不应该无条件把不兼容参数强行塞给所有模型。
更稳的实践是：在模型配置里记录 capability，例如 supportsParallelToolCalls、maxToolCalls、singleToolCallOnly。OpenClaw、OpenAI-compatible adapter 或中转站都应基于这些能力决定是否注入参数。
常见误区
- 看到 OpenAI-compatible 就默认全功能兼容：协议兼容不代表支持所有 OpenAI 扩展字段。
- 把 400 当成 Key 错误：这个错误通常是请求参数和模型能力不匹配，不是鉴权失败。
- 只关心 tools schema：schema 正确也可能因为并行调用参数被拒绝。
- 工具全部失效后继续重试：先修正参数，再清理会话或重新开始最小任务验证。
- 对所有模型使用同一套参数：代码 Agent 模型、聊天模型、单工具模型应有不同参数模板。
上线前验证清单
- 为每个 DeepAI 中转站模型记录是否支持工具调用、是否支持并行工具调用。
- 用单个 read 工具测试单工具调用是否成功。
- 再用两个独立工具测试并行调用能力，不支持时确认不会发送
parallel_tool_calls:true。 - 在中转站日志里保存状态码、错误字段和 model id，方便后续归因。
- 升级 OpenClaw 到包含 PR #39356 的版本，并验证 alias 配置优先级是否按预期生效。
参考资料
- OpenClaw Issue #37048：parallel_tool_calls breaks models that only support single tool calls
- OpenClaw PR #39356：gate parallel_tool_calls to compatible APIs
- OpenClaw Gemini thought_signature 工具调用 400 排查
- DeepAI API 中转站教程导航
总结
OpenClaw 接入 DeepAI API 中转站时，如果工具调用一触发就返回 400 This model only supports single tool-calls at once，优先检查请求体里的 parallel_tool_calls。对只支持单工具调用的模型，应禁用该参数，或升级到包含 PR #39356 的 OpenClaw 版本，让参数只注入到兼容 API 中。代码 Agent 的稳定性来自模型能力、客户端参数和中转站日志三者对齐，而不是把同一套 OpenAI 参数强行套给所有模型。
