n8n 自动化该选 Agent 还是工作流？实测拆解

对同一批支持任务进行 30 轮受控对话，两种方案都完成了 20 个案例；但新版 n8n Agent 调用了 40 次范围受限的工作流，并保留了 20 个会话。在 n8n 自动化中，Agent 和工作流的分工不在于谁能自动化更多：步骤固定时让工作流主导，只有当对话必须决定下一步时才交给 Agent。

n8n 自动化怎么选：Agent 还是工作流

如果运行前就能画出完整步骤，选 n8n 工作流；如果下一步取决于用户说了什么、工具返回了什么，或当前对话已经确认了什么，选 n8n Agent。用于生产环境的客服与运营时，通常最稳妥的是混合架构：Agent 负责判断，职责单一的工作流负责执行。

真正的分界线并不是自动化里有没有模型。工作流可以调用模型，但依旧保持确定性；Agent 也可以调用工作流，但只要下一项工具由模型而非画布决定，它仍然是 Agent 架构。

归根结底只需回答一个问题：下一步应该由谁决定？ 如果答案是自动化设计者，就继续让工作流主导；如果答案是模型——它要结合当前对话和工具结果再作判断——就使用 Agent。n8n 在发布说明里也给出了相同建议：固定步骤适合工作流，开放式请求则适合能够自行规划步骤的 Agent。n8n 的发布说明对这条边界讲得非常直接。

2026 年 9 月 25 日发生了什么变化

n8n 于 2026 年 9 月 25 日推出了新的 Agents 功能区。如今，Agent 是项目中的一等对象，拥有自己的模型、指令、工具、记忆、会话、草稿、已发布版本、渠道和定时任务。它与工作流并列存在，而不是被锁在某一张画布里。n8n 最新 Agents 文档将它定位为处理开放程度过高、不适合固定工作流的任务入口。

这次更新最有价值的地方，是 Agent 有了统一且可复用的身份。同一个已发布 Agent 可以在渠道中回复消息、按计划运行，也可以接收其他工作流发来的消息。会话历史会记录对话、工具、输出、错误和待处理审批。编辑草稿也不会悄悄改变线上已发布版本。

即便如此，也不应让模型广泛访问所有系统。把工作流作为工具，可以为它划定清晰的操作契约：命名明确的输入、受控凭据、已知输出，以及可选的审批边界。一位早期使用者的反馈很准确：与其再做一层聊天外壳，不如把现有工作流复用为工具。

n8n AI Agent 工作流构建器究竟变了什么

旧方案是在一条工作流内，用 Chat Trigger、记忆、AI Agent 节点、模型和工具拼出一个 Agent。这种方式仍然可用。新构建器则把长期存在的 Agent 身份、会话、版本和多个入口统一放进一个共享对象。

这不只是编辑器换了样式，而是职责归属发生了变化：

• Agent 负责对话和工具选择循环。
• 已发布工作流负责范围明确的操作，例如查询账户或起草回复。
• 调用渠道、定时任务或工作流决定何时向 Agent 交付任务。
• 审批者对敏感工具作出最终决定。

n8n Agents 与 AI Agent 节点有什么区别

现有的 AI Agent 节点依然是工作流节点。它连接一个聊天模型和至少一项工具，然后在该次工作流运行期间选择工具。n8n 表示，已有的 AI Agent 节点方案会继续正常运行。当前节点文档仍将其描述为“模型加工具”的设计。

如果 Agent 只属于一条工作流，而且触发器、记忆配置和生命周期都应由这条工作流管理，就继续用该节点。如果一个 Agent 身份需要跨对话延续，或要从多个入口调用，再使用新版 Agent。迁移并非强制要求，现有的节点式 Agent 无须迁移也能继续运行。

同一项客服任务，两种实现方式

这次受控对比使用一个一次性的本地 n8n 2.40.7 实例、一个确定性的 OpenAI 兼容本地模型端点，以及一份固定 JSON 测试数据。测试比较的是路由和编排，不是模型质量或云端延迟。

n8n AI Agent 示例：客服分流

测试数据包含 20 张合成支持工单：

• 其中 10 张采用固定格式，包含工单 ID、账户 ID、产品模块和问题描述。
• 另有 10 张故意缺少账户 ID 和产品模块，因此系统必须追问一次，才能给出有效结果。
• 每个最终案例都有固定的预期队列：计费、技术或通用。

两种方案都处理了同样的 30 轮用户消息。10 张信息完整的工单各用 1 轮；10 张信息不完整的工单先提出问题，再处理 1 次补充回复，共增加 20 轮。

1. 1

   搭建固定流程

   工作流包含 3 个节点：webhook 接收工单，共用的本地模型完成分类，解析器返回结构化 JSON。每条传入消息都按这个顺序经过 3 个节点。

2. 2

   搭建 Agent

   Agent 使用同一个模型、明确的分流指令、持久化会话记忆，以及 3 个已发布的工作流工具：Get Account Context、Draft Support Reply 和 Page On Call。前 2 个可直接使用，Page On Call 则必须经过审批。

3. 3

   判定任务是否完成

   只有当输出包含预期的最终队列时，该案例才算完成。测试还分别记录了追问轮次、执行次数、会话数、模型端点请求数、工作流工具调用数、失败次数和不必要操作。

两种方案都把 20 个最终案例分配到了预期队列。这并不能证明 Agent 与工作流的判断能力相同。测试桩被刻意设计为确定性，以便单独观察编排差异。结果揭示的是额外机制出现在哪里：固定工作流每轮只发出 1 次模型请求，Agent 则会反复调用模型，用于选择工具、接收工具结果、生成回复并维持本次运行。

在这套本地环境中，Agent 的 100 次端点请求由 70 次流式推理或工具循环请求，以及 30 次非流式辅助请求组成。这个结果提醒你必须计量模型供应商的用量，但不能把它当成通用倍数。换一个模型、记忆配置、prompt 或产品版本，请求数都可能变化。

n8n Agent 适合哪些 n8n 自动化场景

当一段对话会改变计划时，就该使用 Agent。比如，一条以“账单不对”为开头的支持请求，后续可能需要查询账户、追问细节、核对政策，或先取得审批才能操作。缺失信息到位之前，你无法预先确定正确分支。

如果计划早已明确，就使用工作流。夜间导出、webhook 到 CRM 的同步，或线索信息补全流程，都更需要显式节点、可预测的重试，以及无需还原模型判断即可检查的执行路径。

控制与调试：工作流胜出

工作流更容易分析，因为所有可能的后续节点都摆在画布上。确定性流程一旦失败，执行记录会直接告诉你哪个节点出错。涉及资金流转、记录删除、权限变更等操作时，灵活性往往意味着风险，因此工作流才是正确的默认选择。

Agent 会话提供的是另一种追踪记录：消息、工具选择、输出、错误和审批。这当然有用，但无法把概率性的判断变成一张预先声明的流程图。如果步骤根本不需要变化，加入推理循环只会多制造一个故障面。

对话与状态：Agent 胜出

任务需要跨越多轮对话时，Agent 更有优势。会话会被保存且可以恢复，会话记忆默认开启。在测试中，10 张信息不完整的工单收到缺失的账户和产品信息后，仍在原会话中继续。固定工作流之所以也能得出相同答案，只是因为补充消息重复了足够多的上下文，能让无状态分类器完成判断。

进入真实客服环境后，这项差异会进一步放大。如果第 2 条消息只说“EU 账户”，工作流就必须从数据存储中重新加载早先的工单，或在输入里接收历史记录；Agent 会话则已经掌握对话上下文。情景记忆还可以跨会话工作，不过 n8n 目前要求该功能使用 OpenAI 凭据。

敏感操作：工作流胜出，Agent 放在前面

最安全的混合方案，是向 Agent 自由开放只读工具，并为所有副作用增加审批。在另一次紧急工单冒烟测试中，Agent 先完成只读账户查询，随后选择 Page On Call 并暂停。只有审批者接受该工具调用后，寻呼工作流才会运行。

这才是合理的安全模型：Agent 可以建议或请求执行某项操作，但影响范围应由职责单一的工作流和明确审批控制。凭据绑定在工具上，因此 Agent 不需要一份无所不能的宽权限凭据。

综合选择：混合架构

新版 Agent 最适合充当工作流之上的对话控制层，而不是取代工作流。Agent 负责理解、追问和选择；工作流负责验证、修改系统并返回结构化结果。这种分工也能让你脱离负责选择工具的模型，单独测试每项操作。

n8n Agent 的执行成本

截至 2026 年 9 月 26 日，n8n 并没有为 Agent 单独设置套餐。Agent 的 1 轮对话算 1 次执行，Agent 与工作流的执行都会从同一配额中扣除。n8n 的发布文章还说明了一点：该轮内部的工作流工具调用和子 Agent 调用，不会单独计为套餐执行次数。

当前按年付费的价格是：Starter 每月 $20，包含 2,500 次执行；Pro 每月 $50，包含 10,000 次执行。这两个价格均根据实时 n8n 价格页面核实，页面的年付选项显示可节省 17%。如果需要了解套餐之间更完整的取舍，请参阅另一篇 n8n 价格分析。

来看简报中的容量规划场景：200 次对话，每次 3 轮。

• 200 × 3 得到 600 次 Agent 执行。在配额计算中，内部工作流工具仍包含在这些轮次里。
• Starter 中，$20 ÷ 2,500 等于每次套餐内执行分摊 $0.008。600 轮会分摊本月订阅中的 $4.80，还剩 1,900 次执行。
• Pro 中，$50 ÷ 10,000 等于每次套餐内执行分摊 $0.005。同样的 600 轮分摊 $3.00，还剩 9,400 次执行。

这些商数只是成本分摊，并不是账单上的边际单价。如果第 601 轮仍在套餐额度内，Starter 账单上不会因此多出一笔 $0.008。

临界点取决于配额，而不是 Agent 相对工作流有折扣。Starter 可以容纳 833 次完整的 3 轮对话，共 2,499 次执行；第 834 次对话会达到 2,502 次，超过 2,500 次额度。Pro 可以容纳 3,333 次这样的对话，共 9,999 次执行；第 3,334 次对话会达到 10,002 次，超过 10,000 次额度。

如果固定工作流每收到 1 条聊天消息就接收 1 次 webhook，那么同样的 600 轮也会消耗 600 次执行，所以执行费用持平。但在模型层面，固定工作流仍可能更便宜：它可能只发出 1 次模型请求，而 Agent 会围绕工具进行多次判断。

模型用量不计入执行配额。n8n Gateway 点数使用独立的预付余额，也可以改用自己的供应商凭据。Gateway 点数文档指出，如果余额归零，受支持的节点就会失败，直到所有者充值、启用自动充值或切换凭据。本地测试中 30 次与 100 次请求的差距，正说明执行次数和模型支出都必须纳入监控面板。

会话、版本、审批与工作流调用

当多个入口需要保持同一种行为时，新版 Agent 才真正体现价值。n8n 会把每段对话保存为会话，其中包括消息、工具和待处理审批。实测数据创建了 20 个会话，每张工单对应 1 个；其中 10 张需要补充信息的工单，都在第 2 轮恢复了原有会话。

版本管理把实验和生产分开。编辑时草稿会自动保存；点击 Publish 则会生成快照，供渠道、定时任务和生产聊天使用。本地验证中，只修改草稿的指令会产生一个新草稿版本，但当前版本 ID 和已发布指令均保持不变。在实时运营期间调整 prompt，就需要这种行为。

n8n Message an Agent：一个 Agent，多个入口

Message an Agent 节点让工作流可以调用现有的已发布 Agent。一个双节点冒烟工作流把计费工单发送给同一个 Support Triage Agent，收到了完整结果，并记录了相同的 2 次限定范围工具调用：先查询账户上下文，再起草回复。该节点还支持自定义会话键，因此工作流可以延续已知对话，而不是每次从零开始。

由此可以组成一种实用架构：

1. 确定性工作流接收并验证事件。
2. Message an Agent 只把需要对话判断的部分交给已发布 Agent。
3. Agent 从限定范围的工作流工具中作出选择。
4. 调用方工作流接收 Agent 的文本、用量、工具调用日志和会话引用。

不要把这个架构连成环。调用 Agent 的工作流，不应同时作为工具挂载到该 Agent 上。入口工作流与操作工作流应彼此分离，并通过名称清楚标明边界。

审批也会进入同一条会话追踪记录。Agent 选中敏感工具时会暂停，并展示调用参数。选择 Approve 后会从暂停处继续，选择 Reject 则会取消操作。相比一句泛泛的“人工介入”，这种机制更实用，因为审批者能在凭据被使用前看到拟调用的工具和输入。

面对高风险自动化，仅靠会话历史仍然不够。应把 Agent 失败和可疑的工具选择送入独立审查路径，并根据所处理的数据设置保留、脱敏和告警策略。AI Agent 故障分析指南介绍了这层独立的可观测性机制。

无需全部重做，如何切换架构

切换架构应该是把稳定工作流包装成工具，而不是在 prompt 里把它们重新画一遍。现有工作流已经包含了真正有价值的部分：凭据、验证、API 调用、数据转换和失败处理。

1. 1

   保留确定性主干

   继续把定时任务、webhook、验证和不可逆写入留在工作流中。不要只为了让架构看起来更像 Agent，就迁移一套固定流程。

2. 2

   把操作变成契约

   为每个可调用工作流设置范围明确的输入 schema 和结构化输出。把只读查询与副作用分开，确保审批只加在真正需要的位置。

3. 3

   只挂载最少的工具

   起步时，只给 Agent 配置完成一项任务所需的少数几个工作流。具体明确的名称和描述能帮助模型正确选择，也能让会话日志更容易审计。

4. 4

   测试对话，而不只是测试 prompt

   测试固定格式案例、信息缺失案例、重复消息和不安全请求。发布快照前，应评估最终输出、追问轮次、工具调用、被拒绝的操作和模型用量。

5. 5

   最后再接入入口

   已发布 Agent 稳定后，再连接渠道、定时任务或 Message an Agent 工作流。复用同一个身份，不要在多张画布上复制指令。

如果步骤固定、当前 AI Agent 节点只属于一条工作流，或合规要求无法接受 Preview 软件，就不要切换。对于自托管 Enterprise 和队列模式部署，当前答案更明确：继续等待。如果你正在评估 n8n 周边更完整的自动化技术栈，可以参考 AI 自动化工具对比。

迁移成本藏在接口中，而不是节点数量里。每个工作流工具都需要清晰输入、受控凭据、可预测输出、可安全去重的操作，以及负责审批的所有者。Agent 会很快暴露薄弱的契约，因为它可能用原工作流设计者未曾预料的顺序调用同一项工具。

Preview 限制与最终建议

n8n Agents 目前处于 Preview 阶段。在 n8n Cloud 上，所有运行最新稳定版的用户都可以使用。自托管需要从 2.32.3 起，并在手动设置中启用 agents 模块。完整的 AI 辅助构建器不是必需项，但自托管知识库需要 Daytona 沙箱，渠道则需要一个公开 webhook URL。

有两项限制可能直接阻止迁移：Agents 尚不支持自托管 Enterprise，也不支持队列模式。n8n 还警告，Telegram 等自托管渠道连接可能失败，因此当前建议使用常规模式。

适合生产环境的架构应当保持克制：所有已经明确步骤的流程，继续由工作流主导；只有当对话必须判断下一步时，才放入 Agent。向它提供范围受限的工作流工具，保存会话，发布经过测试的快照，并在每项会产生实质副作用的操作前加入审批。

这样已经能发挥新版 Agent 的自主能力，同时不必让一个 Preview Agent 接管整套自动化系统。

常见问题

可以用 n8n 构建 Agent 型 AI 吗？

可以。新版 Agents 功能区可以构建跨会话选择工具的持久化 Agent；现有 AI Agent 节点则在一条工作流内部实现 Agent 行为。根据任务所需的范围选择即可。

所谓 4 大 AI Agent 是哪些？

AI Agent 并不存在权威的“4 大”名单。选择时应看具体任务、所需集成、审批模式、部署限制和成本，而不是泛泛的热度排名。

AI Agent 有哪 5 种类型？

业界没有统一的 5 类体系。设计 n8n 方案时，更有用的区分是：下一项操作由固定流程图决定，还是由模型从范围受限的工具中选择。

n8n 工作流与 Agent 型工作流有什么区别？

n8n 工作流按照预先声明的节点图运行；Agent 型设计则让模型选择下一项操作，同时仍可由底层工作流执行已经批准的工具。

ChatGPT 属于 Agent 型 AI 吗？

一条聊天回复本身并不等于 Agent 行为。Agent 行为是围绕目标选择操作或工具、观察结果，再决定下一步。

Agent 分为哪 4 种？

并不存在一套能统一约束 n8n 的 4 类标准。更应该评估运行特征：状态、规划、工具访问和自主程度。

排名前 3 的 AI Agent 是哪些？

没有放之四海而皆准的前 3 名。合适的 Agent 取决于它必须访问哪些系统、需要多强的控制，以及能够部署在哪里。

AI 有哪 7 种类型？

“7 种类型”列表属于教学分类，不是架构规则。它无法替你判断客服或运营流程应该放进 n8n 工作流还是 Agent。

AI Agent 由哪 5 个部分组成？

实现 n8n Agent 时，应先考虑模型、指令、工具、记忆和访问控制。只有用例确实需要时，再加入知识、渠道、定时任务或子 Agent。

如果真正棘手的是对话中的决策点，我可以帮助你设计并构建 Agent，同时保留工作流作为控制层。