2026年9月25日，n8n在博客上发布了Agents，作者是Ophir Prusak。开篇一句话就把平台的前提改写了：你描述一个agent该做什么，给它一个模型、给它能用的工具和工作流，剩下的步骤由它自己排。
对一个靠把步骤拖上画布起家的工具来说，这句话把约定从流程挪到了结果——操作者说目标，agent去谈怎么做。发布会没回答的那个问题不在交互层面，而在运营层面：agent实际选的那条路，谁来复核？
它和拖步骤不是一回事
公告对边界的表述很克制。n8n存在至今，自动化一件事就意味着把步骤想清楚、加到画布上。这套模型仍然适配大量工作：线索进来，补全信息，打分，再分发。
n8n划的线是：下一步是否取决于上一个答案。同事在Slack里问某个客户用量为什么掉了，回答要来回几轮——拉账户、问是哪条产品线、查支持记录。公告给出的理由是：下一步取决于上一个答案，所以没法提前把流程铺出来。
示例是一个支持agent，手里握着三个工作流当工具：一个拉账户上下文，一个给账户加备注，一个呼叫值班。什么时候跑哪个由agent决定；里面发生什么保持不变，还是你搭的那个样子。
中间那个加备注的工作流值得停一下。没有它，记一条备注就意味着给agent开CRM的写权限，再指望它的指令老实待在备注字段里；有了它，agent从不持有那份凭证。每个工具用自己的凭证跑，敏感工具停下来等审批，一个发布出去的agent同时服务Slack、定时任务和入口工作流——指令改一次、发布，所有接它的地方都拿到新版本。
工作流说了算，还是agent说了算
这次发布底下的设计决定是：两种模式现在都存在。有时你要工作流说了算，agent只是里面的一个步骤；有时你要agent说了算，工作流是它的工具。
Message an Agent节点覆盖第一个方向——工作流用自己数据拼一条消息发出去，拿回答案；Agents标签页则把每个已有工作流都当成可调用的工具。n8n明确说这条线可以随时挪：想让某个任务固定下来，就把它从agent里抽出来；想让某个工作流被酌情使用，就把它交给agent。
真正改变运营的是这个反转。当工作流是工具时，工作流的权限定义了agent的活动半径：agent能碰到什么，由它可调用的工作流被允许做什么决定，而不是由它的指令决定。公告用更直白的话说了同一件事：对任何敏感的事，从活动半径小的地方开始——限定范围的工具、测试频道，以及任何写入记录系统的动作都要审批。
一个agent由什么组成
这个定义重要，因为它不只是个聊天外壳。每个agent打包了模型、读起来像你写给同事的简报的指令、频道和触发器（Slack、Telegram、Linear、Discord、定时任务）、三个层级的工具——MCP服务器、为某个具体动作配置好的n8n集成、整个工作流——再加上技能、子agent、知识文件、记忆和会话。
记忆、会话、频道、版本和审批随每个agent自带；会话被存储、可复核、可恢复，草稿以版本形式发布，团队在此期间继续用着旧版。
用AI Agent节点的团队不会被打断：那个节点还在，照旧工作。新原语和旧的原语并排存在，而不是替换它，所以大多数现有搭建暂时不用改。n8n用的类比是：买整机还是自己装——整机到手就是接好的，但你仍然可以拆开看。
会话日志、活动半径、预算
到这里，发布就变成了一个运营决定。每个会话记录agent走的每一步、调用的每个工具，以及每次调用的输入和输出——审计轨迹是默认给的。会话日志就是复核界面；把它当成代码评审里的diff，它是agent能不能继续干下去的门，不是事后补的功课。
成本模型让这份约定可以计数：和agent的一轮对话就是一次执行。来自工作流或子agent的调用不单独计数，它们共用工作流执行额度。构建agent时n8n Assistant也会消耗AI积分，那是另一笔构建期成本。于是执行次数成了一个可用的预算单位——在账单到来之前，轮次计量就是一道能执行的天花板，这在生产里比在演示里重要得多。
一个假设：支持队列里，agent可以调加备注的工作流，但不能调账户导出——导出够不着，因为那个工作流不在它的工具集里。
预览状态，以及没变的部分
这次发布带着诚实的提醒。Agents在n8n Cloud上对运行最新稳定版的所有人开放，自托管部署需要一些额外配置，企业版支持是“很快”，功能本身仍在预览阶段——n8n的底线是先测再发布，敏感动作保留审批。
几个不太方便的事实对规划有用：agent适合开放式任务而不是固定序列，自托管还不是开箱即用，没变的AI Agent节点则奖励那些已经理解新约定的团队。
可操作的顺序很短：在接进生产之前，先决定agent可以调用哪些工作流、那些工作流能做什么；像看diff一样看会话日志；在第一个忙碌月份到来之前，给轮次计量定个数。
热门跟贴