n8n 怎么接第三方 API？用自己的 Key 跑通一个完整工作流

n8n 的 AI Agent 可以接第三方 OpenAI 兼容 API：创建 OpenAI 类型的凭据，填入自己的 API Key 和供应商的 Base URL，再在 OpenAI Chat Model 子节点中选用这份凭据。前提是供应商支持工作流实际使用的模型和功能。凭据连接测试成功，还不足以证明任务能完成。

本文提供不含凭据的工作流 JSON：对一条合成账单工单分类，调用只读查询工具，再检查输出是否正确。Ofox 是本文的接入示例，也是文章发布方。流程使用经典 AI Agent 节点，不是单独的 Agent Builder 功能，不会退款或发送消息。

我们于 2026 年 10 月 20 日，通过 n8n 2.43.8 的服务器命令行执行了该工作流，经 Ofox 调用 deepseek/deepseek-v4.1-flash-1017。修正后的运行拿到了成功的工具返回值，并通过最终结果校验。此前一轮却出现了“流程成功、工具失败”的情况，因此下载模板专门保留了校验节点。这是一次小规模合成任务接入测试，不代表所有模型、n8n 版本或生产环境的稳定性。

导入前准备什么

准备一个你有编辑权限的 n8n 实例、具备所选模型访问权限和足够余额的 Ofox 账号，并确认允许将测试输入发送给对应供应商。先与生产流程分开。我们的运行环境是本地自托管实例，没有测试 n8n Cloud 或 Agent Builder。

复制模型 ID 前，先查Ofox 模型目录。目录能说明公开的可用性，不能代替你自己账号的工具调用测试。如果换用其他模型，需要重新做下文的验收。OpenAI 兼容也不等于支持 OpenAI 的所有端点、内置工具或响应格式。

模板包含五个节点：

Agent 通过 Chat Model 接口连接模型，通过 Tool 接口连接 Code Tool。普通执行线为 Manual Trigger → Classify demo ticket → Validate result。它们是不同的连接类型，不能把所有线都接成普通主流程连接。

导入模板，配置自己的 API Key

1. 下载工作流 JSON，先检查内容再导入。文件包含提示词和 JavaScript，没有 API Key、凭据引用、固定输出或真实客户数据。
2. 在一个空白 n8n 工作流中打开菜单，选择 Import from File，导入下载的 JSON。n8n 也支持从 URL 导入，具体入口可参考官方导入导出说明。
3. 打开 Ofox Chat Model，在凭据栏新建 OpenAI 凭据。这里的类型表示兼容接口，不意味着 Key 必须由 OpenAI 签发。
4. 在 Ofox 的 API Keys 页面创建或复制自己的 Key，填入 API Key；Base URL 填 https://api.ofox.ai/v1。本例的 Organization ID 留空。保存后，在模型节点中选中这份凭据。
5. 只有当账号仍可访问该模型时，才保留 deepseek/deepseek-v4.1-flash-1017。界面若提供模型选择方式，使用精确 ID，不用展示名称代替；更改后检查实际保存的值。
6. 本模板关闭 Use Responses API，实际测试走 Chat Completions。初次验证保留 Maximum Number of Tokens 为 2048、Timeout 为 60000 毫秒、Max Retries 为 0，Agent 的 Max Iterations 为 3。

复用此前凭据教程中的真实英文界面截图，用于说明 Base URL 的填写位置。它不是 10 月 20 日运行的截图，也不证明本工作流已经通过。不同 n8n 版本的标签可能变化；本轮实测依据是下文说明的服务器命令行执行数据。

不要把完整的 /chat/completions 操作地址填进需要 API 根地址的字段，也不要重复添加 /v1。如果凭据测试绿了，工作流仍返回 404，可继续看n8n 端点排错指南。本文补的是完整任务和结果验收，不再重复写一篇路由排错文章。

OpenAI Chat Model 官方文档 区分了 Chat Completions 和 Responses。这里关闭 Responses 是为了选用已测试的路径，不是修复所有 schema 错误、403 或工具不兼容问题的通用办法。模板中的本地 Code Tool，也不等同于 OpenAI 内置的网页搜索、文件搜索工具。

执行工单，同时检查最终输出和工具结果

模板使用一条很小的合成输入：

Request ID: DEMO-1020
Message: I was charged USD 19.50 twice.
I have not supplied a payment ID.

含义是：编号 DEMO-1020 的用户说自己被重复收取了 19.50 美元，但没有提供支付 ID。Agent 必须先调用 lookup_demo_ticket，参数 request_id 为 DEMO-1020。工具不查询真实账号，只通过 JavaScript 返回固定测试数据：

{"request_id":"DEMO-1020","payment_id_present":false}

这个工具让测试覆盖了一次完整交互：模型选择工具，n8n 执行工具，模型拿到结果后再回答。生产流程需要用经过授权的真实查询替换固定数据；本示例不能证明任意 CRM 或支付系统连接器都能使用。

保持工作流未激活，点击 Execute workflow 手动执行。导入及本轮运行已通过服务器命令行验证；上述编辑器步骤依据 n8n 官方导入路径和模板保存的节点配置，没有另行完成 Cloud 界面实测。

查看 Classify demo ticket，预期输出必须恰好包含以下字段和值：

{
  "request_id": "DEMO-1020",
  "category": "billing",
  "amount": 19.5,
  "currency": "USD",
  "action": "request_payment_id"
}

还要检查 intermediate steps。工具名称匹配不够，observation 中必须有对应工单编号、payment_id_present: false，并且没有错误。模板打开了 Return Intermediate Steps，使最后一个节点能够检查这份证据。

最后打开 Validate result。通过时，它会输出相同的业务字段，并附加 validated: true 和 tool_verified: true。多余字段、错误动作、无效 JSON、缺少工具调用或工具返回失败都会使节点报错。下游没有邮件发送或退款节点。

这个校验器有意写死了这一条测试数据的正确答案。如果只改工单内容，不改逐字段断言，校验就会失败。适配自己的任务前，先写出新用例的预期规则，保留字段和类型检查，并明确测试未知 ID、查询无结果等情况。不要为了让流程变绿，就改成“只要是合法 JSON 都接受”。

第一轮测试为什么被判为失败

第一轮本地运行中，模型确实调用了工具，但工具 observation 返回：

Received tool input did not match expected schema
Unrecognized key(s) in object: 'toolCallId'

整个工作流仍显示成功，也给出了符合预期的分类。原校验器只检查“是否调用过工具”，没检查工具是否提供了可用数据。因此我们没有把这一轮算作接入成功。

修正后的测试工具要求输入中必须有字符串 request_id，同时允许额外属性。工具代码只使用允许的测试工单 ID，并返回固定数据，不把整个输入转发给其他服务，也不执行写操作。这个处理兼容了当前安装环境中观察到的额外字段。最终输出的字段要求仍然严格，校验器也补上了工具返回值检查。不要为了消除这个错误，直接撤掉生产操作的严格校验。如果工具会修改数据，应先查清节点和运行环境的行为，明确允许的输入，再继续接入。

修正后的运行用了两次模型调用：第一次请求工具，第二次在查询成功后返回分类。n8n 记录的两次调用合计为 1,019 个输入 token、101 个输出 token；被否决的第一轮则用了三次调用。这些是本次记录的用量，不是账单，也不保证后续运行消耗相同。

另有五类本地反例测试，确认校验器会拒绝：无效 JSON、多余字段、错误动作、未调用工具、工具返回错误。这些是人为构造的校验输入，没有人为触发真实供应商宕机、限流或计费失败。本轮的 toolCallId 现象也不是对 Agent Builder 另一类 get_environment 报错的复现。

换成自己的 Key 后，费用由谁收

需要分开看三部分：

选用 Ofox 凭据后，应到 Ofox 账号查看该模型的请求记录和账单。n8n 界面中的 Gateway credits 余额不会用来支付 Ofox Key 的调用；给供应商充值，也不会增加 n8n Gateway credits 或 Assistant credits。Gateway credits 官方文档 对这些余额和自有凭据路径作了区分。

本例的 Code Tool 只执行本地固定数据查询，不发起外部工具服务请求；真实搜索或抓取工具可能另行收费。Agent 在一次工作流执行中也可能多次调用模型，两轮测试已经显示了这一点。

做预算时，汇总所有调用的输入、输出和单独报告的缓存类别，包括重试，以及已经产生可计费用量的失败尝试。使用对应模型、供应商和账号的实际费率，再加上外部工具费用。不要把文本模型的输出单价套到全部 token 上，也不要把一次 n8n 执行当成一次 API 请求。本文不引用 Ofox 具体牌价，也不宣称测得了费用节省。

先用合成数据和小预算验证。未查清错误前保持重试关闭，之后再按错误类型设置有限重试。模型重试次数和 Agent 迭代次数一起增大，可能只会增加调用，并不能修复无效 Key 或不受支持的 schema。

导入后失败，按哪一层排查

如果问题属于 DeepSeek 路由或服务异常，继续参考DeepSeek API 排错与备用模型切换指南。备用方案必须保留需要的协议、工具能力和结果约定；只换模型名称，不等于完成迁移验证。

接入真实任务前，去掉只适用于本例的固定数据假设，确认真实数据的访问权限，并给写操作单独设置授权和防重复机制。第一步不必做大：用自己的凭据，完成一次模型与工具的完整交互，并让结果通过明确的检查。跑通后，再结合Ofox 认证文档和账号请求记录，把这些检查带入实际工作流。