DeepAI Paper API 中转站,DeepAI Agent 接入,OpenAI Compatible API,代码 Agent 教程,错误排查 OpenClaw 接入 DeepAI API 中转站：openai-completions 不发送 tools 导致工具调用失效

OpenClaw 接入 DeepAI API 中转站：openai-completions 不发送 tools 导致工具调用失效

2026年5月31日2026年5月31日| DeepAI Paper 编辑部DeepAI Paper 编辑部| 0 Comment| 下午11:09
OpenClaw 接入 DeepAI API 中转站：openai-completions 不发送 tools 导致工具调用失效 post thumbnail image
Categories:

OpenClaw 通过自定义 openai-completions Provider 接入 DeepAI API 中转站 时，普通聊天能返回内容，并不代表 Agent 工具调用已经真正打通。一个很典型的现象是：你让 Agent 搜索网页、读取环境或调用自定义函数，模型却只输出一段类似 {"name":"web_search","arguments":{...}} 的 JSON 文本，OpenClaw 没有执行任何工具。

OpenClaw 接入 DeepAI API 中转站时缺少 tools 参数导致 tool_calls 不执行的排查流程
工具调用能否执行，关键不只是模型支持 function calling，还要看请求体是否真的携带了 tools 和 tool_choice。

问题背景：模型会“写工具调用”，但客户端没有执行

这个问题来自 OpenClaw Issue #1866，后续也在 Issue #8923 中被再次反馈。用户使用本地 vLLM、TabbyAPI、Ollama 或第三方 OpenAI-compatible 服务时，直接调用 /v1/chat/completions 可以返回标准 tool_calls；但通过 OpenClaw 的自定义 openai-completions Provider 走同一模型时，请求里没有工具定义，模型只能把“想调用哪个工具”写成普通文本。

这类问题对 API 中转站尤其常见。因为 DeepAI API 中转站负责统一 Base URL、Key、模型路由和调用日志，但工具调用链路横跨三层：客户端是否发送 tools，中转站是否原样转发，模型服务是否支持并返回 tool_calls。任意一层断掉，前端表现都可能只是“Agent 不会用工具”。

先确认：OpenAI-compatible 工具调用需要什么

OpenAI 官方文档对 function calling 的核心流程很明确：请求里提供工具定义，模型返回工具调用，应用侧执行工具，再把工具结果回传给模型生成最终答案。也就是说，模型“支持工具调用”不是一句口头能力，而是要在请求体中看到 tools，并在响应里看到结构化的 tool_calls。

curl https://api.deepai.wang/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_DEEPAI_KEY" \
  -d '{
    "model": "your-tool-capable-model",
    "messages": [
      {"role": "user", "content": "查询北京天气"}
    ],
    "tools": [{
      "type": "function",
      "function": {
        "name": "get_weather",
        "description": "获取指定城市天气",
        "parameters": {
          "type": "object",
          "properties": {
            "city": {"type": "string"}
          },
          "required": ["city"]
        }
      }
    }],
    "tool_choice": "auto"
  }'

如果这条直连 DeepAI API 中转站的请求能返回 choices[0].message.tool_calls，说明模型和中转站大概率没有问题。接下来就应该检查 OpenClaw 发出的实际请求是否包含同样的 tools 字段。

复现路径：为什么会变成普通 JSON 文本

Issue #1866 的关键复现路径是：本地 vLLM 启动了 OpenAI-compatible 服务，并开启了工具调用解析，例如 Qwen 模型配合 Hermes tool-call parser。直接用 curl 测试时，模型会返回 finish_reason: "tool_calls" 和结构化参数；但 OpenClaw 走 api: "openai-completions" 时没有把工具定义发给模型。

  • 模型服务本身支持 tool calling，例如 vLLM、TabbyAPI、Ollama 或第三方兼容服务。
  • OpenClaw 自定义 Provider 只配置了 baseUrl、apiKey、api: "openai-completions" 和模型 ID。
  • Agent 内部有 web search、browser、文件操作等工具，但进入 Provider 时 context.tools 为空。
  • 模型没有收到函数 schema，只能根据系统提示模拟一段 JSON，因此客户端无法识别为真实工具调用。

排查步骤一：看请求体，而不是只看模型回复

排查这类问题时，不建议先调 prompt。真正要看的第一现场是 DeepAI API 中转站日志、OpenClaw gateway 日志，或者你自建 wrapper 收到的原始 JSON。如果请求体只有 model、messages、stream 等字段，没有 tools，那么模型再强也无法返回可靠的 tool_calls。

{
  "model": "deepai/your-model",
  "messages": [...],
  "stream": true
  // 缺少 tools 和 tool_choice
}

正确的请求至少应包含工具数组。对 Chat Completions 兼容接口来说，典型字段是 tools、tool_choice，以及必要时的 parallel_tool_calls。如果你之前已经遇到过并行工具调用 400，则还要根据模型能力决定是否关闭 parallel_tool_calls。

排查步骤二：确认 OpenClaw 版本与能力声明

Issue #8923 里有用户分析到，Provider 代码本身具备把 context.tools 转成请求参数的逻辑，真正的问题可能出在自定义 Provider 的能力识别：OpenClaw 没有把该模型标记为支持工具，导致上下文里根本没有工具定义。Issue #1866 评论中有人反馈 2026.2.2-3 版本已经修复相关问题；也有人提醒，后续测试时要确认实际运行的是更新后的 OpenClaw，而不是系统服务里仍然指向全局安装的旧版本。

  • 先升级 OpenClaw 到包含 tool calling 修复的版本，再重启 gateway / desktop / systemd 服务。
  • 如果你从源码分支构建，检查 systemd、PM2、Docker 或桌面快捷方式是否仍然启动旧的全局包。
  • 自定义 Provider 配置里明确使用 api: "openai-completions"，Base URL 写到 https://api.deepai.wang/v1，不要写到 /chat/completions。
  • 模型选择要用 DeepAI API 中转站后台实际开放的模型 ID，不要把展示名称、供应商别名和路由名混在一起。

DeepAI API 中转站接入建议

如果你要把 OpenClaw、Cline、Dify、n8n 等 Agent 工具统一接到 DeepAI API 中转站，建议把工具调用模型单独做一套验收清单。普通对话模型只需要返回文本；Agent 模型必须验证工具 schema、流式 chunk、tool call delta、非流式响应、错误码透传和日志可观测性。

{
  "models": {
    "providers": {
      "deepai": {
        "baseUrl": "https://api.deepai.wang/v1",
        "apiKey": "YOUR_DEEPAI_KEY",
        "api": "openai-completions",
        "models": [{
          "id": "your-tool-capable-model",
          "name": "DeepAI Tool Calling Model",
          "contextWindow": 65536,
          "maxTokens": 8192
        }]
      }
    }
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "deepai/your-tool-capable-model"
      }
    }
  }
}

上线前，至少做三次对照测试：第一，用 curl 直连 DeepAI API 中转站确认 tools 能返回 tool_calls；第二，用 OpenClaw 发起同一类搜索或函数调用，看中转站日志是否收到 tools；第三，确认工具执行后 OpenClaw 会把 tool result 回传给模型，而不是把第一次 tool call 当成最终回答展示给用户。

常见坑位

  • 只看返回内容：模型输出 JSON 文本不等于工具调用成功，必须看响应字段是不是 tool_calls。
  • Base URL 写太长：在 OpenClaw 配置里写 https://api.deepai.wang/v1，不要写完整接口路径。
  • 模型能力误判：同一个中转站下有些模型支持工具调用，有些只适合文本回复，建议在后台给团队标注清楚。
  • 服务没重启：升级 OpenClaw 或换分支后，systemd / Docker / 桌面进程不重启，日志里仍然是旧行为。
  • 并行工具默认开启：如果模型只支持单工具调用，要避免继续发送不兼容的 parallel_tool_calls: true。

参考资料

总结

OpenClaw 接入 DeepAI API 中转站后，如果 Agent 明明应该调用工具，却只输出 JSON 文本，优先检查请求体里有没有 tools 和 tool_choice。直连中转站能返回 tool_calls，说明模型和 DeepAI 路由基本可用；OpenClaw 侧则要升级到支持自定义 openai-completions 工具调用的版本，并确认实际运行进程已经切到新版本。把“模型支持”“客户端发送”“中转站转发”“工具结果回传”四个环节拆开验证，才能让 AI Agent 真正从会聊天升级为会执行。

Related Post