2026 年 n8n AI 工作流 API 示例代码怎么写：鉴权、参数传递与流式返回片段

2026 年 n8n AI 工作流 API 示例代码怎么写：鉴权、参数传递与流式返回片段

n8n 的优势是把触发、判断、循环和通知串成一条可视流程，但一旦涉及模型请求的细节，光靠现成节点往往不够用，还是得落一小段代码。

这篇内容按“鉴权 → 参数传递 → 流式返回 → 排查”的顺序，把一段可改造的 n8n AI 工作流 API 示例代码拆开讲清楚，方便你直接套进现有流程。

一、先想清楚：为什么要在 n8n 里写代码调模型

常见的诉求大概有三类：一是把上游节点拿到的数据整理成模型能读的格式，二是把长文本切成可控的分片并逐段处理，三是处理流式返回的片段拼接。这三类操作在可视化节点里能做一部分，但遇到字段嵌套、条件分支和逐行解析时，代码节点的可控性明显更好。

需要提前说明的是，下面所有字段名和接口路径都属于结构示例。实际使用时，请以你所选平台控制台展示的接口地址、模型名称和兼容协议为准。

二、鉴权：凭证放在哪一层最合适

方式一：HTTP Request 节点配合预定义凭证

如果流程里只有少量模型调用，直接用 HTTP Request 节点最省事。凭证交给 n8n 的 Credentials 管理，节点里只填业务参数。

Method: POST
URL: {Base URL}/v1/chat/completions
Authentication: Generic Credential Type
Header: Authorization = Bearer <API_KEY>
Content-Type: application/json

这样做的好处是 Key 不会出现在工作流导出的 JSON 里，团队成员复制流程时也不会带着凭证到处跑。

方式二：在 Code 节点里手动发起请求

const res = await this.helpers.httpRequest({
  method: 'POST',
  url: $env.AI_BASE_URL + '/v1/chat/completions',
  headers: {
    Authorization: 'Bearer ' + $env.AI_API_KEY,
    'Content-Type': 'application/json',
  },
  body: {
    model: 'your-model-name',
    messages: [{ role: 'user', content: $json.prompt }],
  },
});
return [{ json: res }];

把地址和 Key 放进环境变量，是为了在不同环境之间切换时不用改代码。需要提醒的是，环境变量在生产实例上也要做好权限控制，不要图方便直接写进节点参数里。

• 凭证集中管理：优先使用 Credentials，只有在同一流程需要动态切换账号时才用环境变量。
• 不做硬编码：Key 不进入工作流导出文件，也不进入截图和日志。
• 便于轮换：预留两个 Key 的位置，需要更换时不用改动整个流程。

三、参数传递：把上游数据安全地映射进请求体

参数传递是 n8n 里最容易出问题的一环。上游节点可能是单条数据，也可能是数组；字段可能是字符串，也可能是对象。映射之前先确认数据类型，比事后调试请求体更高效。

// 表达式方式读取上游字段
{{ $json.title }}
{{ $json.items.map(i => i.text).join('\n') }}

还有一点容易被忽略：超时设置。模型响应时间不确定，节点默认超时可能偏短，遇到长文本时容易直接判定失败。把超时和重试策略一起配置，流程的稳定性会好很多。

四、流式返回片段怎么处理

如果希望把模型输出边生成边推送给下游，就需要处理流式返回。常见的返回格式是每行以 data: 开头，最后以结束标记收尾。解析时不要假设一次拿到完整内容，而要按行切分、逐段拼接。

const text = $json.raw || '';
let out = '';
for (const line of text.split('\n')) {
  if (!line.startsWith('data:')) continue;
  const payload = line.replace('data:', '').trim();
  if (payload === '[DONE]') break;
  try {
    const delta = JSON.parse(payload);
    out += delta.choices?.[0]?.delta?.content || '';
  } catch (e) {
    // 忽略不完整的分片
  }
}
return [{ json: { answer: out } }];

流式返回的难点不在解析，而在“不完整分片”的处理。网络传输可能把一行 JSON 切成两段，如果直接对每一段做解析，就会出现大量解析失败。稳妥的做法是保留缓冲区，等完整的行再解析。

另外要判断工作流到底需不需要流式。如果只是把结果写进数据库或发送通知，用普通返回更简单；只有面向实时对话、打字机效果或长文生成进度展示时，流式的价值才明显。

五、多模型流程里，Key 与地址如何统一

当一条 n8n 流程里同时调用了对话、图像、语音甚至视频模型，凭证和地址的管理就会变得琐碎。每个平台一个地址、一种鉴权写法、一套错误码，维护成本会随着模型数量线性上升。

通联AI中转站 提供的思路是用一个 Base URL 和统一的 API Key 承接多模型调用，流程里只需要维护一套凭证配置，切换模型时改模型名称即可。对于需要在一个自动化流程中按任务选择不同能力的工作流，这种方式能减少重复配置。实际接入前，建议先在控制台确认接口地址、模型名称与兼容协议，再回到 n8n 里替换环境变量。

如果团队里有多个工作流共用同一套凭证，最好约定命名规范，例如按环境加前缀，并在 通联AI中转站 控制台里分别创建 Key，这样某个流程出现异常时可以单独停用，而不影响其他自动化任务。

六、上线前的检查清单

1. 凭证是否放在 Credentials 或环境变量中，而不是节点参数里。
2. 接口地址与模型名称是否来自控制台，而非旧文档。
3. 上游字段类型是否与请求体要求一致，是否存在空值。
4. 是否设置了合理的超时、重试次数与失败告警。
5. 流式解析是否处理了分片截断与结束标记。
6. 工作流导出文件中是否残留明文 Key。
7. 是否记录调用量，便于后续核对用量与余额。

工作流跑通之后，真正影响长期维护成本的是 Key 和地址的集中程度。建议先到控制台确认可用模型、接口地址与凭证管理方式，再把生产环境的工作流切过去。

进入通联控制台统一管理 API Key