n8n新Agent类型支持用自然语言描述任务、选择模型和工具,快速创建可执行自动化工作流的AI代理。
n8n 现在有了 Agents。你描述一个 agent 应该做什么,给它一个模型以及它可以使用的工具和工作流,它自己就能推导出执行步骤。你可以在 Slack 里跟它对话、按定时计划运行它,或者从任意工作流里调用它——在这所有场景中都是同一个 agent。
有了 agents,那些开放式或来回交互的任务处理起来就容易多了,这类任务如果做成固定工作流会变得很复杂。而且构建 agent 不需要先学会工作流的用法。
Agents 和你的工作流并排存在,两者被设计为协同工作。你的 agent 可以把你的工作流当作工具来用,这样你就能精确控制它在你的系统里可以做什么。而当一个工作流需要 agent 来完成某个步骤时,新的 Message an Agent 节点可以在工作流内部调用它。
如果你现在正在使用 AI Agent 节点,它没有任何变化。你之前构建的所有内容继续正常运行。
👇 观看下面这个视频,里面有详细的真实案例演示。👇
自从 n8n 诞生以来,自动化意味着要先理清步骤然后把它们加到画布上。这对很多工作仍然是正确的方式。比如一个线索进来,你做数据丰富、打分、分配。流程越固定,工作流就越合适,哪怕其中某一步是一个模型在做决策。
但两件事发生了变化:
模型能够自己推导出"怎么做"。 给一个当前的模型一个目标以及合适的工具,它非常擅长自己找出到达目标所需的步骤。
人们期望的是说出想要什么结果。 越来越多的人想的是定义一个目标、让事情被处理掉,而不是先设计流程。
对于输入每次都不同的工作来说,这两点最为关键。团队里有人在 Slack 上问,为什么某个客户的用量上个月下降了。回答需要几轮:拉取账户信息、问对方指的是哪条产品线、查看支持历史、回来给出总结和后续问题。下一个步骤取决于上一个问题的答案,所以没法提前把流程确定下来。
一封客服邮件、一个新 GitHub issue,或者任何你知道领域但不知道具体任务形式的请求,都是同样的道理。对于这类工作,你想用自然语言描述目标,给 agent 它需要的东西,然后让它边走边推导步骤。
在此之前,在 n8n 里承担这样的任务意味着把开放式对话塞进一个工作流。你可以做到,而且很多人确实这么做了,但需要花不少功夫来构建。Agents 就是为这类任务而生的。
有时候你希望工作流做主、agent 作为其中的一个步骤。有时候你希望 agent 做主、工作流作为工具。n8n 现在两种方式都支持。
确实如此,我们自己也是。一个 chat trigger、一个 memory 节点、一个带几个工具的 AI Agent 节点,再加上一个把它们包起来的工作流。很多 n8n 用户就是这样构建 agents 的,而且能用。
区别在于你有多少东西需要自己组装。这有点像自己组装 PC 和买整机。自己装能有一台可用的机器,但每个零件都要自己选、每根线都要自己接。整机到手时已经全部接好、开机即用,但你仍然可以打开来添加你需要的东西。
n8n Agents 就是那个整机版本。Memory、sessions、channels、版本控制和审批是每个 agent 自带的,所以你把时间花在 agent 实际上要做什么上。你仍然可以用任何你喜欢的工具或工作流来扩展它。
构建 agent 不需要懂工作流怎么写。你用自然语言描述 agent 应该做什么,之后再打开它时,它的指令读起来就像你给同事写的一份简报。如果你的第一个 agents 是在某个工具里写指令然后挂载工具这种方式构建的,那在 n8n 里就是这样来构建的。
agent 运行之后,你可以看到它做了什么。每个 session 展示了 agent 的每一步操作、调用了哪些工具,以及每次调用的输入和输出。
→ 完整文档见 docs。
一个 agent 可以使用三类工具,每个工具你可以单独选择:
MCP servers. 连接一个服务,agent 立即获得它的所有工具,然后自己推导如何使用它们。这是配置最快的方案,你也可以排除任何你不想让它接触的工具。
n8n tools & nodes. 你已经在用的集成,针对一个特定动作配置好,参数由你指定。配置工作量更大,但对 agent 能做什么有更精确的控制。
Workflows. 一个你已经构建好的完整流程,按你定义的方式原样运行。
工作流是我们最激动的部分。你在 n8n 里构建的每个工作流都可以被一个 agent 使用,而且完全不需要改动。
以一个处理入站队列的客服 agent 为例。它有三个工作流作为工具:
Get account context. 从 CRM 拉取账户信息、检查合同状态、评估健康度。它能工作,而且很无聊——这是对工作流最高的赞美。
Add a note to the account. 接收一个账户 ID 和一条备注,然后写入。仅此而已。
Page on-call. 向 on-call 频道发送一条紧急工单通知。
agent 读取每个工单、判断是否需要账户背景、起草回复、记录操作日志,并将任何紧急情况升级。它决定每个工作流何时运行。而工作流运行后发生什么是不变的,一步一步按你构建的方式执行。
第二个工作流尤其值得注意。如果没有工作流挡在中间,记录一条备注意味着要给 agent 你的 CRM 写权限,并信任它的指令能把操作限制在备注字段。有了工作流,agent 从不持有那个凭证。它持有的是一个只加备注、不做其他任何事的工作流。

在此之上,是你所期望的控制能力:
Approvals. 把一个工具标记为敏感操作,agent 在使用它之前会暂停等待 Approve 或 Reject。对于客服 agent,呼叫 on-call 就需要等人来审批。
Per-tool credentials. 每个工具用你附加给它的凭证来运行。agent 从不持有你实例的密钥。
对 agent 本身的访问遵循你的 n8n 角色体系,所以谁可以编辑和发布它由你决定。
所以对于每个使用场景,你可以决定多少是固定流程、多少由 agent 决定。而且这条线可以 later 调整:想把某个任务固定下来,就从 agent 里拉出来做成工作流;想让某个工作流在有人介入的情况下使用,就交给 agent。
对于任何敏感操作,从爆炸半径小的地方开始:限定范围的工具、一个测试 channel,以及对任何写入记录系统的操作开启审批。
一个客服 agent 只有在团队能信赖它时才有用。三件事有助于此:
一个 agent,到处可用。 把它连接到 Slack,整个团队都在那里跟它对话,每人各自进行。放到计划任务里做每早巡检。从你的工单录入工作流里调用它。一次改指令、发布,所有接入的地方都拿到新版本。
草稿和已发布版本。 团队继续使用已发布版本的同时,你可以编辑和预览草稿。准备好了再发布。需要时可以恢复、回滚或取消发布。
Sessions 和执行日志。 输入、工具调用、输出和错误,按 session 记录,这样你可以看到它上周二做了什么。
Agents 也能反方向在工作流里使用。当一个工作流需要 agent 来完成某个步骤时,加入 Message an Agent 节点。它把用你工作流数据构建的消息发送给 agent,并把 agent 的回答传递给下一个节点。

agent 自带指令、工具和 memory,所以节点本身保持简单:你定义输入什么,得到回答回来。这是你的团队在其他地方使用的同一个已发布 agent,所以当你更新 agent 时,每个调用它的 workflow 都获得更新。
AI Agent 节点仍然在,而且一如既往地工作。用哪个取决于任务本身。
打开 Agents 标签页并点击 Create Agent,或者跟 n8n Assistant 描述你想要什么。Assistant 会为这个任务挑选最合适的——工作流或 agent——并把它构建出来。如果你已经确定想要一个 agent,直接说出来就行。无论哪种方式,你都会得到起草好的指令、工具和 channels,随时可以测试。
有了 Gateway credits,你不需要从 AI 提供商那里拿 API key 就能开始试用。选一个模型,进行第一次对话,之后再带来你自己的 key 如果你需要的话。
有了 Assistant 和 Gateway credits,开始使用只需要描述你想要什么。最终你得到的是一个你可以自己阅读和修改的 agent。
如果你不确定第一步做什么,可以试试一个内部 Slack bot,连接团队经常查询的一两个系统。以下是一些其他思路:
完整指南见 docs:Build and manage agents。
可用性:
成本。 Agent 一次对话轮次算一次执行。调用你的工作流和调用 sub-agents 不单独计费,agents 共享你的工作流执行配额。用 n8n Assistant 构建 agent 会消耗 AI credits,和任何 Assistant 对话一样。
仍在预览阶段。 Cloud 上的每个人都可以使用 agents,而且它们能正常工作。我们逐版本在改进它们,所以在发布前先测试,任何敏感操作保持开启审批。
我们后续还会为 agents 带来更多能力。同时,告诉我们你构建了什么、它做了什么、以及哪里出了问题。我们一直在密切关注社区论坛。
0:00 / 0:10 1× Agents & Workflows - Better Together.
Agents & Workflows - Better Together.
n8n 用户来自各种各样的背景、经验水平和兴趣方向。我们一直在希望通过博客文章来展示不同用户及其项目。如果你正在使用 n8n 并希望为社区带来灵感,欢迎联系我们 💌