n8n AI Agent 接入 DeepAI API 中转站 时，有一类问题特别容易误判：OpenAI-compatible 自定义 Base URL 下，普通对话能成功，但一旦给 Agent 挂上 MCP Client、HTTP Request Tool 或其他 Tools，工作流就失败。这个现象说明 Key 和 Base URL 未必有错，真正要查的是模型是否支持工具调用、n8n 发送的 tools/tool_calls 是否被中转站完整透传，以及上游接口是否兼容 n8n 的调用方式。
问题背景：聊天可以，MCP/Tools 一接就失败
在 n8n Issue #15862 中，用户描述了一个典型场景：n8n AI Agent 使用自定义 Base URL 指向 OpenAI-compliant API，连接普通模型时看起来可用，但当 Agent 尝试使用 attached MCP clients 或 Tools 时失败。这个 Issue 已关闭，但它暴露的问题对所有 API 中转站都很常见：聊天补全只是最小能力，工具调用是另一套更复杂的协议面。
n8n 官方 OpenAI node 文档也提醒，OpenAI node V2 引入了 Responses API，并且文本操作里同时有 Chat Completions 和 Model Response 两类路径；部分操作支持 Tools connector。换句话说，同一个“OpenAI 凭据”在 n8n 内部可能被不同节点、不同 operation、不同 API 协议使用，不能只用“连接测试成功”判断整个 Agent 工作流没问题。
为什么 API 中转站场景更容易踩坑？
DeepAI API 中转站的价值在于统一 Key、统一 Base URL、统一模型路由和日志观测。但对 n8n AI Agent 来说，请求体里不只有 messages，还可能包含 tools、JSON Schema、tool choice、streaming 标记、函数调用结果、MCP 返回内容等结构。如果中转站只按“普通聊天接口”做了兼容，遇到 Agent 工具调用时就可能出现 400、404、模型无响应、工具永远不触发、或流式输出中断。
因此排查时要把问题拆成三段：n8n 是否真的把工具 schema 发出去了；DeepAI API 中转站是否完整收到了并转发；上游模型是否支持该格式的工具调用。如果这三段只验证了一段，就很容易把模型能力问题误判为 Base URL 问题，或者把中转站参数过滤问题误判为 n8n bug。
推荐的最小复现流程
- 先创建一个只有 AI Agent + OpenAI Chat Model 的最小工作流，Base URL 指向
https://api.deepai.wang/v1，确认普通问答能返回。 - 再挂一个最简单的 Tool，例如返回固定 JSON 的 HTTP Request Tool 或 Code Tool，不要一开始就接复杂 MCP 服务。
- 在 DeepAI API 中转站日志里对比两次请求体：无 Tool 时是否只有
messages，有 Tool 时是否出现tools或tool_choice。 - 确认中转站转发到上游时没有删除
tools、没有把 JSON Schema 改坏、没有把流式事件包装成 n8n 无法解析的格式。 - 换一个明确支持工具调用的模型做交叉验证。如果换模型后可用，说明 Base URL 不是核心问题，模型能力或模型映射才是重点。
DeepAI API 中转站日志应该重点看什么？
建议在中转站日志里增加四类字段：请求路径、模型名、工具参数摘要、上游错误原文。对 n8n 来说，/v1/chat/completions 和 /v1/responses 的排查重点不同；Chat Completions 更关注 tools、tool_choice、tool_calls，Responses API 还要关注 input item、tool output item 和流式 event 类型。
检查清单： - path: /v1/chat/completions 还是 /v1/responses - model: 是否被中转站映射为支持 tools 的模型 - request.tools: 是否存在，schema 是否完整 - stream: n8n 是否开启流式，事件格式是否兼容 - upstream_error: 保留上游原始 status code 和 message
常见坑位
- 连接测试成功但运行失败：凭据测试通常只验证认证或轻量接口，不代表工具调用协议可用。
- 模型名映射到不支持工具的上游：普通聊天模型可以回答文本，但不会产生
tool_calls。 - 中转站过滤未知字段：如果网关只白名单保留
model、messages、temperature，工具 schema 会被截断。 - 流式事件不兼容：n8n Agent 等待的是工具调用增量事件，上游或中转站如果只返回普通文本流，工具不会被触发。
- MCP 工具太复杂：先用单个固定返回的工具验证，再接文件系统、浏览器、数据库等复杂 MCP 服务。
给站长的 SEO 与产品建议
搜索“n8n AI Agent MCP Tools custom base URL failed”“n8n OpenAI compatible tools 不触发”“API 中转站 tools 参数丢失”的用户，往往已经把基础聊天跑通，正在进入真实自动化场景。DeepAI API 中转站如果能在文档里明确列出 Chat Completions、Responses API、工具调用、流式事件和模型能力矩阵，就能显著降低这类用户的试错成本。
文章和产品页里可以自然覆盖这些关键词：n8n AI Agent 接入、OpenAI Compatible API、DeepAI API 中转站、MCP Tools 排查、LLM 工具调用、Responses API 中转。重点不是堆关键词，而是把“普通聊天成功”和“Agent 工具调用成功”之间的差异讲清楚。
参考资料
- n8n Issue #15862：AI Agent with MCP/Tools Fails with Custom Base URL
- n8n OpenAI node documentation
- n8n OpenAI Text operations documentation
总结
n8n AI Agent 通过 DeepAI API 中转站接入 OpenAI-compatible 模型时，如果普通聊天正常、MCP/Tools 失败，优先不要重置 Key 或反复改 Base URL。正确路径是先看 n8n 是否发出工具 schema，再看中转站是否完整透传，最后看上游模型是否支持工具调用和流式事件。把这三段链路拆开，才能稳定定位 Agent 自动化工作流里的真实故障点。
