n8n 接入 DeepAI API 中转站：Tools Agent 提示模型不支持工具调用怎么排查

n8n 的 AI Agent 节点可以把模型、工具、数据库、HTTP 请求和业务系统组合成自动化工作流。接入 DeepAI API 中转站或其他 OpenAI-compatible Provider 时，普通聊天能通并不代表 Tools Agent 一定能跑通。最常见的问题之一是：模型本身支持工具调用，但 n8n 提示 Tools Agent requires Chat Model which supports Tools calling。

n8n 接入 DeepAI API 中转站时 Tools Agent bindTools 和工具调用能力校验排查流程 — n8n Tools Agent 不只要求模型能聊天，还要求 Chat Model 对象、工具协议和多轮工具历史都兼容。

GitHub Issue 背景：OpenAI-compatible 模型被 Tools Agent 拦截

n8n GitHub 仓库中有一个已关闭的 Issue：用户在自托管 n8n 1.123.4 中，用 LangChain Code 节点创建 ChatOpenAI，Base URL 指向一个 OpenAI-compatible Provider。模型本身支持 tool calling，但 Tools Agent 仍然抛出验证错误，认为这个 Chat Model 不支持工具调用。

用户尝试把 model name 伪装成 gpt-4 来绕过校验，再用参数切换真实模型。结果验证能过，但执行会挂起或在多轮工具历史里出现格式错乱。这说明：绕过校验不是稳定方案，Tools Agent 需要的是完整的工具调用协议兼容，而不只是 OpenAI-compatible 的聊天接口。

为什么 OpenAI-compatible 不等于 Agent 工具兼容

OpenAI-compatible 通常意味着接口路径、鉴权方式和请求响应结构大体接近 OpenAI API。但 Agent 工具调用还涉及更多细节：

Chat Model 对象是否暴露 bindTools 或等价能力。
模型是否能返回标准 tool_calls。
多轮历史中 assistant tool call 与 tool result 是否能正确配对。
流式输出、token 统计和错误格式是否被 n8n/LangChain 正确处理。
Provider 是否需要专用 SDK 或专用历史格式。

所以，DeepAI API 中转站里某个模型能完成普通聊天，不代表它一定适合 n8n Tools Agent。要单独验证工具调用。

DeepAI API 中转站推荐测试流程

如果你要在 n8n Tools Agent 里使用 DeepAI API 中转站，建议按下面顺序测试：

先用普通 OpenAI Chat Model 节点测试 Base URL、API Key 和模型 ID。
再用 AI Agent 的普通聊天模式测试单轮回复。
接入一个最简单工具，例如天气、时间或 echo 工具，验证是否能产生 tool call。
测试第二轮追问，确认工具历史不会被模型当成普通文本复读。
最后再接入数据库、HTTP Request、复杂 API 和生产工作流。

Base URL 和模型 ID 仍然要先排除

工具调用问题容易让人直接怀疑 n8n，但基础配置仍然要先排除。OpenAI-compatible Base URL 通常应填写：

https://api.deepai.wang/v1

不要填写完整的 /chat/completions 路径。模型 ID 要使用 DeepAI API 中转站后台实际支持的名称。API Key 不要手动加 Bearer 前缀，n8n 会处理认证头。

排查 bindTools 校验失败

如果 n8n 报 requires Chat Model which supports Tools calling，可以从三层判断：

对象层：传给 Tools Agent 的是否是真正的 Chat Model，而不是普通 LLM、字符串或包装对象。
接口层：这个 Chat Model 是否暴露 bindTools，n8n 是否能识别。
Provider 层：即使对象通过校验，上游模型是否真的按标准返回 tool_calls。

不要长期依赖伪装模型名、 monkey patch 或把真实模型藏进额外参数的方式。这些方法可能让校验通过，但在流式响应、多轮历史或工具结果回传时出问题。

多轮工具历史是第二个关键测试点

Issue 的后续测试提到：第一轮工具调用成功后，第二轮追问时模型可能无法正确解析通用 OpenAI 历史格式，反而输出原始 JSON 或复读工具日志。这类问题说明 Provider 对多轮工具历史的格式要求和 n8n/LangChain 默认格式不完全一致。

第一轮能调用工具，只证明单轮 tool call 可用。
第二轮能理解工具结果，才说明 Agent loop 真的可用。
如果模型复读工具 JSON，检查历史消息格式和 Provider 专用适配器。
如果执行挂起，检查流式输出、超时、token 统计和连接关闭行为。

DeepAI API 中转站后台应该看什么

请求是否到达：没有日志就先查 n8n 网络、Base URL 和凭据。
请求体是否包含 tools：没有 tools 就说明 n8n 没把工具绑定成功。
响应是否包含 tool_calls：没有 tool_calls 可能是模型不支持或参数不兼容。
第二轮是否带历史：确认 assistant tool_call 和 tool result 都在 messages 中。
错误码：400 多看工具 schema，401 看 Key，404 看路径或模型，429 看频率和并发。

生产建议

在生产环境里，建议为 n8n Tools Agent 单独创建 DeepAI API Key，并限制可用模型。先选择明确支持工具调用的模型，不要把所有 OpenAI-compatible 模型都默认接入 Agent。对于数据库写入、订单操作、通知发送等高风险工具，还要增加人工审批或条件分支，避免模型工具调用格式异常造成业务事故。

参考资料

总结

n8n Tools Agent 接入 DeepAI API 中转站时，不要只验证普通聊天。真正要验证的是 Chat Model 是否能被 n8n 识别为支持 bindTools，请求里是否带 tools，模型是否返回标准 tool_calls，以及第二轮工具历史是否仍然稳定。OpenAI-compatible 是基础，Agent 工具调用兼容才是生产可用的关键。