n8n 的 Agent 节点：让模型接上真实系统

在 n8n 里，Agent 不是终点，而是流水线中间的一段。左边有触发器，右边有具体的动作——发消息、写数据库、开工单、回写 CRM。模型负责判断，n8n 负责把判断变成真实世界里发生的事。

它本来是个自动化工具

理解 n8n 要从它的起点开始：这是一个可视化的工作流自动化平台，用节点连成流程，由事件触发。定时任务、Webhook、某个系统里的变化，都能成为起点；后面的节点按顺序执行，中间可以分支、可以等待、可以调用代码。

这个出身决定了它的性格：先解决"连得上、跑得稳、出错能查"，再谈智能。AI 能力是后来加的，加的方式也很克制——不是另起一套 Agent 框架，而是把模型调用做成节点，放进原有的流程里。

AI Agent 节点：把几百个集成变成工具

n8n 最实际的价值在这里。

它的 AI Agent 节点可以让模型自己选工具、自己决定调用顺序，而"工具"就是平台里已有的集成节点：查数据库、搜 Slack 历史、创建 Jira 工单、发邮件、调任意 HTTP 接口。你不需要为每个系统写一套工具封装，配好节点、挂到 Agent 上就行。

对工程团队来说，这解决的是最枯燥的那部分工作：认证、重试、错误处理、字段映射。这些事每个系统都不一样，自己写一遍要花几天，而且每次接新系统都要再写一遍。

配套的还有代码节点。可视化表达不了逻辑时，可以直接写 JavaScript 或 Python，读写上下游数据。这一点让它不至于在复杂场景下卡死——纯无代码工具的通病是遇到例外就得换工具，n8n 留了出口。

人在回路不是可选项

把 Agent 接进真实业务，最怕的是它自作主张。

n8n 的做法是把"等待人工确认"做成流程里的一个节点：Agent 生成内容，流程暂停，人收到通知，确认后继续执行；不确认就停在那儿。这比在提示词里写"请谨慎操作"可靠得多——前者是流程约束，后者是请求。

配套的是执行记录：每次运行都能看到每个节点的输入输出、耗时、成功或失败。排查问题时不用猜模型想了什么，直接看它拿到了什么、返回了什么。这一点对上线后的维护至关重要，也是它和"写个脚本调 API"的主要区别。

图 1　判断、动作与留痕，各在哪一段

按执行计费，改变了用法

n8n 的计价单位是一次工作流执行，而不是执行里的每个步骤。一个二十步的流程，和两步的流程，算一次。

这个结构直接影响设计思路：既然步骤不额外收费，就可以把校验、清洗、日志、通知都放进同一条流程里，而不是为了省钱把它们拆到外面。对高频运行的流程，成本差异会很明显。

自托管的社区版是另一个变量：软件本身免费，执行次数不受限，成本主要是服务器。对数据不能出内网的团队，这是决定性的一条。

许可和运维，要先看清

它采用的是 fair-code 许可，源代码可见、可自托管、可商用，但不能把 n8n 本身作为托管服务转售。对内部使用没有影响，对想拿它做产品的团队是一条硬约束。

运维上还有两个现实问题。

一是画布复杂度。流程一旦超过几十个节点，画布会变得难以阅读，调试靠滚动和记忆。缓解办法是把稳定的大流程拆成子流程，或者把复杂逻辑收进代码节点。

二是状态。Agent 节点默认不保留跨执行的记忆，需要持久化就得外接数据库或缓存。做多轮对话类应用时，这一点必须提前设计，否则会出现"它怎么忘了上一句"的问题。

和 Dify 的取舍

两者经常被放在一起比，其实解决的问题不同。

Dify 围绕"构建一个应用"：知识库、提示词调试、发布成 API 或网页、可观测，一套东西是为终端用户产品准备的。适合做客服助手、内部问答、需要长期迭代的 AI 应用。

n8n 围绕"让流程自动跑"：触发、集成、审批、回写，一套东西是为业务系统之间的连接准备的。适合做告警处理、线索分配、工单流转、内容分发。

判断方法很直接：如果核心问题是"用户怎么和 AI 对话"，看 Dify；如果核心问题是"AI 的判断怎么变成系统里的动作"，看 n8n。两者也可以并存——用 Dify 做交互层，用 n8n 做执行层。

什么时候它不合适

需要复杂状态机、需要精细控制每一步重试策略的场景，代码框架更合适；需要极低延迟的在线推理，工作流引擎会引入额外开销；完全没有技术人员的团队，画布上的概念仍然偏工程化，学习成本不低。

还有一条容易被忽略：如果流程本身还没理顺，先别急着自动化。把一个人工流程原样搬进画布，只会让混乱跑得更快。

对已经有一堆系统要对接、又想让模型参与判断的团队，n8n 的位置很难被替代——它不承诺最聪明的 Agent，但承诺每一步都能看见、能停、能改。这一点在真实业务里，往往比多几个百分点的准确率更值钱。至于"一次性任务"，交给通用 Agent更省事；而"要长期维护的 AI 应用"，Dify 那条路更顺。