快来看,n8n更新了!介绍 n8n 智能体

内容来源:https://blog.n8n.io/introducing-n8n-agents/
内容总结:
n8n 正式推出 Agents 功能,用户只需用自然语言描述智能体(Agent)的职责,为其配置模型、工具和工作流,智能体即可自行规划并执行步骤。该功能支持在 Slack 中对话、按计划运行,或从任意工作流中调用,且在各场景下均为同一个智能体。
Agents 的定位与价值
对于开放式、需要多轮交互、流程难以预先固定的任务,Agent 比传统固定工作流更为合适。用户无需先学习工作流的搭建方式即可创建 Agent。Agent 与工作流并列存在、协同工作:Agent 可将工作流作为工具调用,从而精确控制其在系统中的行为边界;工作流也可通过新增的 "Message an Agent" 节点在某个步骤中调用 Agent。现有的 AI Agent 节点保持不变,已构建的内容不受影响。
为何此时推出
过去在 n8n 中实现自动化,需要先梳理步骤并搭建到画布上,这对流程固定的任务依然适用。变化在于两点:一是当前模型具备"自行规划步骤"的能力,给定目标和工具后能很好地推导实现路径;二是用户越来越期望"只描述结果,由系统完成"。对于输入每次不同的任务(如 Slack 中询问某客户用量下降原因、支持邮件、GitHub 新 issue 等),无法预先编排流程,Agent 正是为此类任务而设计。n8n 现在同时支持"工作流主导、Agent 作为其中一步"和"Agent 主导、工作流作为工具"两种模式。
与以往自建 Agent 的区别
此前用户已可通过聊天触发器、记忆节点、AI Agent 节点加若干工具自行组装 Agent,这种方式可行但需自行拼装大量部件。n8n Agents 相当于"预装机":记忆、会话、渠道、版本、审批等能力内置,用户可专注于定义 Agent 的职责,同时仍可用任意工具或工作流进行扩展。
Agent 的组成
构建 Agent 无需了解工作流原理,用自然语言描述职责即可。每个 Agent 包含:模型(支持已有凭证的任意模型或 n8n Gateway 额度)、指令(角色、语气、行为边界、工具偏好)、渠道与触发器(Slack、Telegram、Linear、Discord、定时计划)、工具(n8n 内置集成、MCP 服务器、任意工作流)、技能(可复用的指令与参考文件,可跨 Agent 共享)、子 Agent、知识库(支持上传 csv、pdf、markdown、txt 文件,n8n Cloud 可用,也支持向量存储)、记忆(默认保存会话对话,也可跨会话记忆)、会话(每次对话均被存储、可回看、可继续)。运行后,每个会话都会展示 Agent 的每一步操作、调用的工具及各次调用的输入输出。
工作流可作为 Agent 的工具
Agent 可使用三类工具,逐项选择:MCP 服务器(一次接入即获得该服务全部工具,设置最快,可排除不需要的工具)、n8n 工具与节点(针对具体动作配置参数,设置更多但控制更精确)、工作流(已构建的完整流程,按既定方式运行)。以支持 Agent 处理工单队列为例,它可将"获取账户上下文""为账户添加备注""呼叫值班人员"三个工作流作为工具,自行决定何时调用;而工作流内部的执行步骤完全固定。其中"添加备注"工作流尤为关键:若不经工作流,Agent 需直接获得 CRM 写权限;经工作流封装后,Agent 不持有该凭证,只能执行"添加备注"这一件事。
配套控制包括:审批机制(将工具标记为敏感后,Agent 使用前需人工批准或拒绝)、按工具配置凭证(每个工具使用所绑定的凭证,Agent 不持有实例密钥)、Agent 本身的访问权限遵循 n8n 角色体系。用户可按场景决定"固定流程"与"Agent 自主决策"的比例,并可在后期调整这条界线。对敏感操作,建议从小范围开始:限定工具范围、使用测试渠道、对写入记录系统的操作启用审批。
面向团队使用的设计
一是"一个 Agent,处处可用":接入 Slack 后全团队可各自对话,可设定时任务,也可从工单接入工作流中调用;修改指令并发布后,所有接入处同步更新。二是草稿与已发布版本:团队使用已发布版本的同时可编辑预览草稿,准备好后再发布,支持恢复、回滚、取消发布。三是会话与执行日志:按会话记录输入、工具调用、输出与错误,可追溯历史操作。
在工作流中使用 Agent
反向使用同样支持:工作流需要 Agent 执行某一步时,添加 "Message an Agent" 节点,用工作流数据构造消息发给 Agent,并将其回复传给下一节点。Agent 自带指令、工具和记忆,节点本身保持简单。调用的即是团队各处使用的同一个已发布 Agent,Agent 更新后所有调用它的工作流同步获得更新。AI Agent 节点仍然保留,可按需选用。
快速上手
打开 Agents 标签页点击 Create Agent,或直接向 n8n Assistant 描述需求,Assistant 会判断适合工作流还是 Agent 并完成构建,指令、工具、渠道会预先草拟待测试。借助 Gateway 额度,试用阶段无需自备 AI 厂商 API 密钥,可先选模型开始首次对话,之后再接入自有密钥。入门建议从连接一两个团队常用系统的内部 Slack 机器人开始,其他示例包括:读取新工单并获取账户上下文、草拟回复的支持 Agent;调研新线索并向 Slack 推送摘要的研究 Agent;关注新 issue 并推荐后续动作的 Linear Agent;按计划推送夜间变更晨报的定时任务。完整指南见文档《Build and manage agents》。
须知事项
可用性方面:n8n Cloud 最新稳定版用户均可使用;自托管需额外配置;即将登陆 Enterprise。成本方面:Agent 的一轮交互计为一次执行,对工作流和子 Agent 的工具调用不单独计费,Agent 与工作流共享执行额度;使用 n8n Assistant 构建 Agent 会像其他 Assistant 对话一样消耗 AI 额度。该功能仍处于预览阶段,Cloud 用户均可使用且功能可用,官方将逐版本改进,建议发布前充分测试,并对敏感操作保持审批开启。官方表示近期将推出更多 Agent 相关能力,并欢迎用户在社区论坛反馈构建成果、实际表现与不足之处。
中文翻译:
n8n 现已推出智能体(Agents)功能。你只需描述智能体应该做什么,给它一个模型以及它可以使用的工具和工作流,它就会自行规划出执行步骤。你可以在 Slack 中与它对话,按计划定时运行它,或从任何工作流中调用它——在所有场景中,它都是同一个智能体。
有了智能体,处理开放式或来回交互的任务变得更加容易——这类任务如果构建为固定工作流,往往会变得很复杂。而且你无需先学习工作流的运作方式,就能构建一个智能体。
智能体与你的工作流并列存在,二者天生协同工作。你的智能体可以将你的工作流作为工具使用,因此你可以精确决定它被允许在你的系统中做什么。当某个工作流需要智能体来完成其中一步时,新增的“向智能体发送消息”(Message an Agent)节点会在工作流内部调用它。
如果你目前正在使用 AI Agent 节点,它没有任何变化。你已经构建的一切都会继续正常运行。
👇 请观看以下视频,其中通过一个真实案例进行了详细讲解。👇
为什么选择智能体,为什么是现在
自 n8n 诞生以来,实现自动化就意味着要梳理出步骤并将它们添加到画布上。对于大量工作来说,这仍然是正确的做法。一条线索进来,你对其进行丰富、评分、路由。序列越固定,工作流就越适合,即使其中某一步是模型在做决策。
有两件事发生了变化:
- 模型能够自行规划“怎么做”。给当前一代模型一个目标和合适的工具,它非常擅长找出达成目标的步骤。
- 人们期望直接提出结果。越来越多的人希望定义一个目标,然后由系统来处理,而不是先设计流程。
这在每次输入都不同的工作中最为重要。团队中有人在 Slack 里问,为什么某个客户上个月的使用量下降了。回答需要几轮交互:拉取账户信息,询问指的是哪条产品线,查看支持历史,然后回来给出摘要和一个后续问题。下一步取决于上一个问题的答案,因此无法提前规划好流程。
一封支持邮件、一个新的 GitHub issue,或者任何你知道领域但不知道具体任务的请求,都是如此。对于这些工作,你希望用自然语言描述目标,给智能体访问所需资源的权限,让它边做边规划步骤。
在此之前,要在 n8n 中承接这样的工作,意味着要把一段开放式对话塞进工作流里。你可以做到,很多人也确实这么做了,但构建起来需要不少功夫。智能体就是为这类工作量身打造的。
有时候你希望由工作流主导,智能体作为其中的一个步骤。
有时候你希望由智能体主导,工作流作为工具。
n8n 现在两种都支持。
“但我已经在 n8n 里构建智能体好几年了”
你确实构建过,我们也是。一个聊天触发器、一个记忆节点、一个挂载了几个工具的 AI Agent 节点,再加上一个工作流把这一切串起来。很多 n8n 用户运行的智能体正是这样搭建的,它们能正常工作。
区别在于你需要自己组装多少东西。这有点像自己攒电脑和买整机的区别。自己攒能得到一台能用的机器,但每个零件都要你挑,每根线都要你接。整机到手时一切已连接就绪,你仍然可以打开它,添加你需要的东西。
n8n 智能体就是整机版本。记忆、会话、渠道、版本和审批随每个智能体一起提供,这样你就能把时间花在智能体应该做什么上。你仍然可以用任何工具或工作流来扩展它。
智能体包含哪些内容
你不需要了解工作流如何运作就能构建一个智能体。你用自然语言描述智能体应该做什么,之后打开它时,它的指令读起来就像你给同事写的简报。如果你最初的智能体是在某个写指令、挂工具的工具中构建的,那么在 n8n 中就是这样构建的。
每个智能体拥有:
- 模型。 任何你有凭据的模型,或使用 n8n 的 Gateway 额度。
- 指令。 它的角色、语气、应该做什么和不应该做什么,以及优先使用哪些工具。
- 渠道与触发器。 Slack、Telegram、Linear、Discord、定时计划。
- 工具。 内置的 n8n 集成、MCP 服务器、任何工作流。
- 技能。 可复用的指令和参考文件,智能体在需要时加载,可在智能体之间共享。
- 子智能体。 一个智能体可以调用另一个智能体。
- 知识库。 上传 csv、pdf、markdown 或 txt 文件,让智能体基于这些内容回答问题。在 n8n Cloud 上可用。也支持向量存储。
- 记忆。 默认保存会话对话,也可以跨会话记忆。
- 会话。 每次对话都会被存储、可审查,并且可以随时继续。
一旦运行起来,你可以看到它做了什么。每个会话都会展示智能体采取的每一步、调用了哪些工具,以及每次调用的输入和输出。
你的工作流可以成为智能体的工具
智能体可以使用三种工具,你可以逐个选择:
- MCP 服务器。 连接一个服务,智能体就能一次性获得其所有工具,然后自行决定如何使用。设置最快,你可以排除任何不想让它接触的工具。
- n8n 工具与节点。 你已经在使用的集成,针对某个具体操作设置好你选择的参数。设置更多,但对智能体能做什么有更精确的控制。
- 工作流。 你已经构建好的完整流程,完全按照你定义的方式运行。
工作流是我们最兴奋的部分。你在 n8n 中构建的每一个工作流,都可以被智能体使用,而且不需要做任何改动。
以一个处理入站队列的支持智能体为例。它有三个工作流作为工具:
- 获取账户上下文。 从 CRM 拉取账户信息,检查合同状态,评估健康度。它能正常工作,而且很无聊——这是你能给一个工作流最高的赞美。
- 给账户添加备注。 接收一个账户 ID 和一条备注,然后写入备注。它只能做这些。
- 呼叫值班人员。 向值班频道发送紧急工单。
智能体阅读每张工单,判断是否需要账户上下文,起草回复,记录发生的事情,并升级任何紧急事项。它决定每个工作流何时运行。工作流运行时做什么是固定的,一步一步,按照你构建的方式执行。
第二个工作流值得注意。如果没有中间的工作流,记录备注就意味着要给智能体对你 CRM 的写入权限,并信任它的指令会将它限制在备注字段内。有了工作流,智能体永远不持有那个凭据。它持有的是一个只添加备注、不做其他任何事情的工作流。
围绕这些,有你期望的控制措施:
- 审批。 将某个工具标记为敏感,智能体在使用它之前会暂停,等待批准或拒绝。对于支持智能体来说,呼叫值班人员会等待人工确认。
- 按工具的凭据。 每个工具使用你附加给它的凭据运行。智能体永远不持有你实例的密钥。
- 对智能体本身的访问遵循你的 n8n 角色权限,因此谁可以编辑和发布由你决定。
所以你可以按用例选择,多少是已定义的流程,多少由智能体决定。你之后也可以移动这条线:当你希望某个任务固定下来时,把它从智能体中抽出来放进工作流;当你希望某个工作流被灵活运用时,把它交给智能体。
对于任何敏感操作,从影响范围小的地方开始:限定范围的工具、测试频道,以及对任何写入记录系统的操作设置审批。
为依赖它的团队而构建
一个支持智能体只有在团队能信赖它时才有用。有三件事有助于做到这一点:
- 一个智能体,到处使用。 把它连接到 Slack,整个团队在那里与它对话,每个人有各自的对话。把它放到定时计划上,每天早上扫一遍队列。从你的工单接收工作流中调用它。修改一次指令,发布,所有连接的地方都会获得新版本。
- 草稿和已发布版本。 在团队继续使用已发布版本的同时,编辑和预览草稿。准备好后发布。需要时可以恢复、回滚或取消发布。
- 会话和执行日志。 输入、工具调用、输出和错误,按会话记录,这样你可以看到它上周二做了什么。
在工作流中使用智能体
智能体也可以反向工作。当某个工作流需要智能体来完成其中一步时,添加“向智能体发送消息”节点。它会根据你的工作流数据构建一条消息发送给智能体,并将智能体的回答传递给下一个节点。
智能体自带它的指令、工具和记忆,因此节点本身保持简单:你定义输入什么,然后拿回答案。它就是你团队在其他地方使用的同一个已发布智能体,所以当你更新智能体时,每个调用它的工作流都会获得更新。
AI Agent 节点仍然存在,并且一如既往地正常工作。哪个适合就用哪个。
快速上手
打开“智能体”标签页,点击“创建智能体”,或者向 n8n 助手描述你想要什么。助手会为任务选择最合适的方案——工作流或智能体——并构建它。如果你已经确定想要一个智能体,直接说就行。无论哪种方式,你都会得到起草好的指令、工具和渠道,可以直接测试。
有了 Gateway 额度,你不需要 AI 提供商的 API 密钥就能试用。选一个模型,开始第一次对话,之后如果需要再带入你自己的密钥。
有了助手和 Gateway 额度,上手只需要描述你想要什么。你最终得到的是一个你自己能读懂、能修改的智能体。
如果你不确定先构建什么,可以试试一个连接到你团队经常询问的一两个系统的内部 Slack 机器人。其他一些想法:
- 一个支持智能体,读取新工单,拉取账户上下文并起草回复
- 一个研究智能体,调查入站线索并向 Slack 发布摘要
- 一个 Linear 智能体,关注新 issue 并推荐后续行动
- 一份按定时计划发送的早晨摘要,汇总夜间发生的变化
完整指南见文档:构建和管理智能体。
你需要了解的事项
- 可用性:
- 在 n8n Cloud 上,所有使用最新稳定版的用户均可使用。
- 自托管(需要一些额外设置)。参见自托管设置。
- 即将登陆 Enterprise。
- 费用。 与智能体的一轮交互算一次执行。对工作流和子智能体的工具调用不单独计数,智能体共享你的工作流执行配额。使用 n8n 助手构建智能体会消耗 AI 额度,与任何助手对话一样。
- 仍处于预览阶段。 Cloud 上的所有用户都可以使用智能体,它们能正常工作。我们正在逐个版本改进它们,所以发布前请先测试,对任何敏感操作保持审批开启。
我们很快会为智能体带来更多功能。在此期间,告诉我们你构建了什么、它做了什么、哪里出了问题。我们正在密切关注社区论坛。
英文来源:
n8n now has Agents. You describe what an agent should do, give it a model and the tools and workflows it can use, and it works out the steps itself. You can talk to it in Slack, run it on a schedule, or call it from any workflow, and it's the same agent in every one of those places.
With agents, it's easier to handle open-ended or back-and-forth jobs that could get complicated to build as a fixed workflow. And you can build an agent without first learning how workflows work.
Agents sit next to your workflows, and the two are built to work together. Your agent can use your workflows as tools, so you decide exactly what it's allowed to do in your systems. And when a workflow needs an agent for one of its steps, the new Message an Agent node calls it from inside the workflow.
If you use the AI Agent node today, nothing about it has changed. Everything you've built keeps working.
👇 Check out the following video which goes into detail with a real world example. 👇
Why agents, and why now
For as long as n8n has existed, automating something meant working out the steps and adding them to the canvas. That's still the right approach for plenty of work. A lead comes in, you enrich it, score it, route it. The more fixed the sequence, the better a workflow fits, even if one of the steps is a model making a decision.
Two things have changed:
- Models can work out the how. Give a current model a goal and the right tools, and it's really good at figuring out the steps to get there.
- People expect to ask for an outcome. More and more, people want to define a goal, and have it handled, instead of designing the process first.
That matters most for jobs where the input is different every time. Someone on the team asks in Slack why a customer's usage dropped last month. Answering takes a few rounds: pull the account, ask which product line they mean, check the support history, come back with a summary and a follow-up question. The next step depends on the answer to the last one, so there's no way to lay out the process in advance.
The same goes for a support email, a new GitHub issue, or any request where you know the domain but not the task. For those jobs, you want to describe the goal in plain language, give the agent access to what it needs, and let it work out the steps as it goes.
Until now, taking on a job like that in n8n meant fitting an open-ended conversation into a workflow. You could do it, and plenty of people did, but it took some work to build. Agents are built for those jobs.
Sometimes you want the workflow in charge, with the agent as a step inside it.
Sometimes you want the agent in charge, with workflows as tools.
n8n now gives you both.
"But I've been building agents in n8n for years"
You have, and so have we. A chat trigger, a memory node, an AI Agent node with a few tools attached, and a workflow around it to hold it all together. Lots of n8n users run agents built exactly this way, and they work.
The difference is how much of it you have to assemble yourself. It's a bit like building your own PC versus buying a pre-built one. Building your own gets you a working machine, but you pick every part and connect every cable. A pre-built PC arrives with everything connected and ready to go, and you can still open it up and add what you need.
n8n Agents are the pre-built version. Memory, sessions, channels, versions and approvals come with every agent, so you spend your time on what the agent should do. You can still extend it with any tool or workflow you like.
What goes into an agent
You don't need to know how workflows work to build one. You describe what the agent should do in plain language, and when you open it later, its instructions read like a brief you'd write for a colleague. If your first agents were built in a tool where you write instructions and attach tools, this is how you build them in n8n.
Each agent has: - A model. Any model you have credentials for, or n8n's Gateway credits.
- Instructions. Its role, its tone, what it should and shouldn't do, and which tools to prefer.
- Channels & triggers. Slack, Telegram, Linear, Discord, a schedule.
- Tools. Built-in n8n integrations, MCP servers, any workflow.
- Skills. Reusable instructions and reference files the agent loads when it needs them, shareable across agents.
- Sub-agents. One agent can call another.
- Knowledge. Upload csv, pdf, markdown or txt files for the agent to ground its answers in. Available on n8n Cloud. Vector stores as well.
- Memory. It holds the session conversation by default and can remember across sessions as well.
- Sessions. Every conversation is stored, reviewable, and can be picked up again.
Once it's running, you can see what it did. Each session shows every step the agent took, which tools it called, and the input and output of each call.
Your workflows can be your agent's tools
An agent can use three kinds of tools, and you choose per tool: - MCP servers. Connect a service and the agent gets all of its tools at once, then works out how to use them. The quickest to set up, and you can exclude any tools you don't want it to touch.
- n8n tools & nodes. The integrations you already use, set up for one specific action with the parameters you choose. More setup, and more control over exactly what the agent can do.
- Workflows. A whole process you've already built, run exactly the way you defined it.
Workflows are the part we're most excited about. Every workflow you've built in n8n is something an agent can use, and none of it needs to change.
Take a support agent handling the inbound queue. It has three workflows as tools: - Get account context. Pulls the account from the CRM, checks contract status, scores health. It works, and it's boring, which is the highest compliment you can pay a workflow.
- Add a note to the account. Takes an account ID and a note, and writes the note. That's all it can do.
- Page on-call. Posts an urgent ticket to the on-call channel.
The agent reads each ticket, decides whether it needs account context, drafts a reply, logs what happened, and escalates anything urgent. It decides when each workflow runs. What happens when a workflow runs is fixed, step by step, the way you built it.
That second workflow is the one to notice. Without a workflow in between, logging a note would mean giving the agent write access to your CRM and trusting its instructions to keep it to the notes field. With the workflow, the agent never holds that credential. It holds a workflow that adds a note and does nothing else.
Around that, the controls you'd expect: - Approvals. Mark a tool as sensitive and the agent pauses for Approve or Reject before using it. For the support agent, paging on-call waits for a person.
- Per-tool credentials. Each tool runs with the credential you attached to it. The agent never holds the keys to your instance.
- Access to the agent itself follows your n8n roles, so who can edit and publish it is up to you.
So you choose, per use case, how much is defined process and how much the agent decides. And you can move that line later: pull a task out of the agent into a workflow when you want it fixed, or hand a workflow to an agent when you want it used with discretion.
For anything sensitive, start where the blast radius is small: scoped tools, a test channel, and approvals on any action that writes to a system of record.
Built for teams that rely on it
A support agent is only useful if the team can count on it. Three things help with that: - One agent, used everywhere. Connect it to Slack and the whole team talks to it there, each in their own conversation. Put it on a schedule for a morning pass over the queue. Call it from your ticket-intake workflow. Change the instructions once, publish, and every place it's connected gets the new version.
- Drafts and published versions. Edit and preview the draft while the team keeps using the published version. Publish when you're ready. Restore, revert, or unpublish when you need to.
- Sessions and execution logs. Inputs, tool calls, outputs and errors, per session, so you can see what it did last Tuesday.
Using agents inside workflows
Agents work in the other direction too. When a workflow needs an agent for one of its steps, add the Message an Agent node. It sends the agent a message built from your workflow data and passes the agent's answer to the next node.
The agent brings its own instructions, tools and memory, so the node itself stays simple: you define what goes in, and you get the answer back. It's the same published agent your team uses everywhere else, so when you update the agent, every workflow that calls it gets the update.
The AI Agent node is still there and works as it always has. Use whichever fits the job.
Getting started
Open the Agents tab and click Create Agent, or describe what you want to n8n Assistant. The Assistant picks the best fit for the job, workflow or agent, and builds it. If you already know you want an agent, say so. Either way you get the instructions, tools and channels drafted, ready to test.
With Gateway credits, you don't need an API key from an AI provider to try it. Pick a model, have the first conversation, and bring your own keys later if you want to.
Between the Assistant and Gateway credits, getting started takes little more than a description of what you want. What you end up with is an agent you can read and change yourself.
If you're not sure what to build first, try an internal Slack bot connected to one or two systems your team asks about all the time. A few other ideas: - A support agent that reads new tickets, pulls account context and drafts a reply
- A research agent that looks into inbound leads and posts a summary to Slack
- A Linear agent that watches new issues and recommends follow-ups
- A morning summary of what changed overnight, on a schedule
The full guide is in the docs: Build and manage agents.
Things you should know - Availability:
- On n8n Cloud for everyone on the latest stable version.
- Self-hosted (with some extra setup). See Self-hosted setup.
- Coming to Enterprise soon.
- Cost. One turn with an agent is one execution. Tool calls to your workflows and to sub-agents don't count separately, and agents share your workflow execution quota. Building an agent with n8n Assistant uses AI credits, as any Assistant conversation does.
- Still in preview. Everyone on Cloud can use agents and they work. We're improving them release by release, so test before publishing and keep approvals on anything sensitive.
We have more coming for agents soon. In the meantime, tell us what you built, what it did, and where it fell down. We're reading the community forum closely.