n8n + 9Router AI 网关：本地工作流自动化部署

场景

我在 Docker 上跑着 n8n 做各种自动化流程，另一台机器上部署了 9Router AI 网关（OpenAI 兼容 API）。两个系统各自运转得很好，但一直缺一个环节：在 n8n 工作流的中间步骤调用 AI 模型。

比如：让一个定时工作流从数据库里拉出数据，交给 LLM 分析，把结论发到通知服务。或者做一个「输入文本 → 同时用两个模型评估 → 对比输出」的对比器。

这篇文章就是我的配置过程——n8n 的 HTTP Request 节点怎么配、有什么坑、做什么样的工作流最实用。

核心思路

n8n 虽然内置了 OpenAI 节点，但如果你用的是第三方 AI 网关（后端跑多个模型的组合、备用回退、流量路由），直接配 OpenAI 节点行不通。它的价值预设是你只有一家供应商。

所以更通用的方案是：HTTP Request 节点 + 自定义凭证，直接调 AI 网关的 /v1/chat/completions 端点。

这个模式的好处是：
- 不绑定特定供应商：网关后端可以是任何 OpenAI 兼容服务
- 自由控制模型选择：通过修改 body 里的 model 参数切换
- 可以在工作流里做多模型编排：先让 A 模型处理，不满足条件再调 B

反过来它也有成本——没有 OpenAI 节点那种开箱即用的对话交互界面，得自己解析返回的 JSON。

配置步骤

第一步：创建 HTTP Request 节点

在你的 n8n 工作流里加一个 HTTP Request 节点：

第二步：写请求体

{
  "model": "gl",
  "messages": [
    {"role": "system", "content": "你是一个有用的助手"},
    {"role": "user", "content": "={{ $json.body.prompt }}"}
  ],
  "stream": false,
  "max_tokens": 2000
}

如果你的工作流用 Webhook 接收外部请求，传入的数据在 $json.body 下，不是 $json 顶层——这是 n8n 解析 JSON body 的默认行为，跟 REST API 创建的工作流是否正常工作无关。

第三步：写 Code 节点处理响应

9Router 返回的是标准 OpenAI 格式，用 Code 节点解析：

const raw = $input.first().json;
const choice = raw.choices?.[0]?.message?.content || '无响应';
return [{ json: { result: choice, model: raw.model } }];

Timeout 建议设 120 秒——AI 模型推理在低配机器上可能慢，HTTP Request 节点的默认超时只有 30 秒，大模型很容易超。

模型选择策略

9Router 的模型别名体系可以帮助你在工作流里保持配置的简洁性：

我日常的做法是：简单任务用 gl 不用选，长文本指名 gl_1m，偶尔需要特定模型胜过自动回退时才写全名。9Router 通过 GET /v1/models 返回可用模型列表和对应前缀，加新模型上去后不用改工作流配置。

工作流模板

这四个模板按复杂度排列，可直接抄。

模板 1：AI 文本助手（3 节点）

最简单的调用模式。适合飞书 Webhook、自定义 API 端点。

Webhook → HTTP Request (调 AI) → Code (解析返回)

外部发 POST 请求给 Webhook URL，body 里带 prompt 字段，AI 处理后返回结果。

模板 2：多模型评估（5 节点）

同一份输入让两个模型各自跑，然后对比输出。适合评测结果质量。

Manual → HTTP Request (模型A) → HTTP Request (模型B)
  → IF/合并 → Code (对比输出)

两个 HTTP Request 并排放置而不是串联——n8n 默认按连接顺序执行，要把两个请求独立连接到触发器上并行跑，或者用 Merge 节点合并后再对比。后者更可控。

模板 3：AI 分析 + 通知（4 节点）

定时任务分析数据，推通知。

Schedule → HTTP Request (AI 分析数据)
  → Code (格式化) → HTTP Request (发通知)

Schedule 触发后，用 AI 处理数据（日志、报表、监控指标等），格式化结果后推给通知服务（ntfy、Telegram、微信等）。这个模式可以做日报摘要、异常日志分析、定时巡检报告。

模板 4：SSH 采集 + AI 分析（4 节点）

到远程服务器跑命令，结果交给 AI。

Manual → SSH (远程执行脚本) → Code (解析输出) → HTTP Request (AI 分析)

通过 SSH 节点在远程主机执行命令（如系统检查、日志提取），结果用 Code 节点解析后传给 AI 模型分析。n8n 容器内没有 Python，所以需要远程执行或用 Function 节点的 JavaScript 做处理，这是 n8n Docker 部署的一个限制。

踩坑记录

坑 1：非标准 SSE 响应混入

即使请求里设了 stream: false，9Router 回退路径上的某些中转层有时仍会返回 text/event-stream 格式，末尾带 data: [DONE]。Code 节点收到的不是标准 JSON，而是多行文本。

处理方式：在 Code 节点先 normalize：

let raw = $input.first().json;
// 检查并移除 SSE 残留
if (raw && typeof raw === 'string' && raw.includes('data: [DONE]')) {
  raw = raw.substring(0, raw.indexOf('data: [DONE]'));
  const lines = raw.split('\n').filter(l => l.startsWith('data: {'));
  if (lines.length > 0) {
    raw = JSON.parse(lines[lines.length - 1].replace(/^data: /, ''));
  }
}

坑 2：SSH 节点 non-interactive shell

n8n SSH 节点使用 non-interactive shell 登录远程主机，不会加载 .bashrc（或 .zshrc），所以安装在用户目录下的 CLI 工具（pip install –user 装的东西）找不到。如果 SSH 节点要执行自定义脚本，要么命令前加 export PATH=$PATH:/path/to/bin，要么在远程主机上用绝对路径调用。

坑 3：超时配置不够大

HTTP Request 节点默认 timeout 30 秒。AI 模型推理在高负载或使用大模型时经常超过这个时间。手动设大 timeout 值是必须的——120 秒是个安全的起点。另外，如果配置了多模型降级（模型 A 超时后换模型 B），每个请求的超时时间要单独配置。

坑 4：API Key 的 JSON 序列化问题

如果你的 API Key 含有特殊字符（如 +、/、=——base64 编码常见结尾），在 n8n 的 Generic Credential 里直接粘贴可能 OK，但在工作流 JSON 参数里硬编码会把 + 解析成空格。正确的做法是：用 n8n 的 Credential 功能存 API Key，表达式引用 $credentials.http.header。不要自己拼 header 字符串。

总结

把 n8n 和 AI 网关串起来的核心价值不是单次调用——那跟 curl 一样——而是编排能力：按条件选模型、多个模型并行对比、失败后自动降级、把 AI 输出接回后续流程。

如果你已经有 n8n 和 AI 网关，不需要额外软件或节点，一个 HTTP Request 节点就够了。如果还没搭网关，9Router、OpenRouter、阿里云百炼都提供 OpenAI 兼容 API，配置方式完全一样。

技术要点回顾：
- 用 HTTP Request + Header Auth 调 OpenAI 兼容 API，不用 OpenAI 专用节点
- Timeout 设大（120s），处理非标准 SSE 响应
- 用模型的 alias 别名保持工作流配置简洁
- 多模型编排时注意并行 vs 串行的节点连接方式
- API Key 存 Credential 里，不要硬编码