n8n 最近上线了一个新入口，名字很直接，叫 Agents。
看介绍时很容易把它归进“低代码平台终于也加了 Agent”的那一类新闻：选模型，写几句角色说明，挂上工具，再接 Slack、Telegram 或定时任务。这样的界面现在并不稀奇。
我反而盯住了它对 workflow（工作流）的处理。n8n 没有把 workflow 当成 Agent 出现之前的旧东西，而是让它变成 Agent 可以调用的工具。谁决定调用？Agent。调用之后具体能做什么？workflow。
这听起来像产品结构上的小调整，落到权限上却差得很远。
本文依据 n8n 9 月 25 日的官方发布和文档。新 Agents 仍在 preview（预览）阶段，官方文章讲的是设计方向和公开能力，实际部署时的权限、凭据与审批效果还要看团队自己的配置。下面只拆它把“判断”和“执行”切开的那一层。
画布适合确定的事，Agent 适合没法提前写完的事
n8n 一直擅长处理画得出来的流程。
一条线索进来，补全公司信息，检查合同状态，按分数分给销售。这种任务有明确顺序，输入格式也相对稳定。画布上的每个节点都知道自己该做什么，跑错了可以沿着节点往回找。
问题出在那些一开始根本画不完的任务上。
假设有人在 Slack 里问：“某个客户上个月的使用量为什么掉了？”系统先得确认是哪个客户、哪条产品线；然后查合同和工单；查到一半也许发现对方刚换了管理员，需要回头追问；最后才能整理出一个能让人判断的答案。
你没法在任务开始前，把每个分支都摆到画布上。下一步取决于上一轮查到的东西，也取决于对话里新补进来的信息。
图：n8n Agents 界面示意，来源：n8n 官方发布。
n8n 给 Agents 留的正是这个位置。输入不完整、需要来回问、路径要边走边定的任务，交给 Agent。步骤已经稳定、动作不该临场变化的任务，仍然留给 workflow。
官方说法也没有把其中一方说成另一方的替代品。有时 workflow 在外面控制流程，Agent 只是一个节点；有时 Agent 带着目标工作，workflow 成了它手里的工具。把这两种情况放进同一套产品，至少比硬把一段开放式对话塞进固定节点图里顺得多。
图：通过消息与 Agent 交互的官方示意，来源：n8n 官方发布。
“写 CRM 备注”这个例子，比功能清单重要
n8n 的发布里有一个支持 Agent 的例子。
它会读进来的工单，判断要不要查客户资料，起草回复，记录处理过程，紧急时再通知值班同事。为了做这些事，Agent 有三条 workflow 可以调用：拿客户上下文、给账户写备注、通知值班。
真正该多看两眼的是第二条。
要是直接把 CRM 的写权限交给 Agent，模型能动到哪里，取决于那份凭据本身。你可以在提示词里反复强调“只写备注，不要改别的”，但这只是行为期待，不是技术边界。
n8n 的方案换了个方向。Agent 不拿 CRM 凭据，只看得到一条 workflow。这条 workflow 只接收账户 ID 和备注内容，里面的动作也已经写死：向指定账户写一条备注。不能删账户，不能改合同，不能临时拼一条导出客户库的查询。
这相当于把“允许操作 CRM”换成“允许请求系统完成一个明确动作”。
图：Agent 调用 workflow 的官方示意，来源：n8n 官方发布。
模型还要自己判断此刻要不要记备注，是不是先查一下客户状态，还是该把问题转给值班人员。但真正触到业务系统时，可走的路已经被缩窄了。
很多 Agent 设计讨论喜欢从“要给它哪些工具”开始。更实际的问题是：每个工具暴露出的能力到底有多大。
一张 CRM 管理员凭据，接近万能钥匙。一条参数有限、只完成一件事的 workflow，更像只开了一条缝的窗口。前者要求模型始终克制，后者让它即便跑偏，也没那么容易跑到不该去的地方。
谁来判断，谁来执行
这件事可以拆成两个问题。
什么时候该做？
客户邮件语气含糊，要不要先问一句？一张工单看起来像故障，还是普通咨询？现在该读知识库，还是该查账单？这些判断和对话上下文绑在一起，写成一张固定流程图往往很笨。Agent 处理这类变化会自然一些。
具体怎么做？
查哪个系统，用谁的凭据，允许写哪些字段，通知发到哪个频道，失败后要不要重试，几次之后必须停下来，这些事情不应该等模型临场决定。它们更适合被写进 workflow，变成一个普通但可预测的业务接口。
所以 workflow 不是 Agent 出现后该被淘汰的东西，反而是 Agent 的动作边界。
这条边界也不必一开始就画死。一项工作刚出现很多例外时，可以先让 Agent 带着几个窄 workflow 处理。过一段时间，团队发现其中一步已经稳定下来，就把它抽出来做成固定流程。反过来，原来一条标准流程如果不断遇到例外和追问，也可以让 Agent 协调其中的分支。
边界应该跟着业务的稳定程度走，不必跟着“Agent 越多越先进”的说法走。
审批和日志，平时不起眼，出事时才值钱
Agent 一旦接触写操作，两个常被当成附属功能的东西会突然变得很重要：审批和记录。
n8n 可以把工具标成敏感。Agent 走到那一步会暂停，等待 Approve 或 Reject。发布文档用的是通知值班人员的例子：模型可以判断事情可能紧急，但真正把人叫醒前，仍留给人确认。
这不是因为模型永远不可信。只是有些动作的代价不适合交给概率。写一封内部草稿可以多试几次；改生产数据、通知客户、触发值班，通常不能只凭“模型看起来很确定”就放行。
另一件事是会话和执行日志。n8n Agents 保存每次对话、工具调用、输入和输出，也区分草稿版本与已发布版本。这些东西在演示里不抢眼，真正出了问题却是仅有的线索：谁发起了任务？模型当时读到了什么？它调用了哪条 workflow，带了什么参数？跑的是哪一版 Agent？
如果答不上来，所谓“Agent 做错了”就无从分析。你可能只看得到最后一段回复，却不知道它中间查了什么、哪一步越过了边界，是模型的判断错了，还是 workflow 本身给得太宽。
这也是“接几个 MCP 工具”之后很快会遇到的现实。工具越来越多，必须能看清每一项能力是怎么被调用的；业务动作越敏感，凭据、参数、审批和日志越应该留在可检查的位置。
workflow 也会把错误执行得很漂亮
当然，把动作封进 workflow 不会自动变安全。
如果一条 workflow 接收任意自然语言，再拿它去拼任意 SQL；如果它允许传入任意 URL 访问内部服务；如果它默认用管理员凭据写入多个系统，那么“受控工具”只是换了个名字。风险从 Agent 的权限移到了 workflow 的参数和实现里。
还有一种更常见的情况：流程本身错了，但它跑得很顺。Agent 也许准确判断了调用时机，workflow 却把错误账户 ID 写进了 CRM，或者默认给所有客户发同一封邮件。前面多一层推理，救不了后面一条有问题的业务规则。
因此，workflow 也得按业务 API 来设计。输入尽量有限，输出要可预期，权限按最小范围给，失败时知道停在哪里，关键写操作留得下记录。听上去没有 Agent 那么炫，但这里才是自动化系统真正耐用的地方。
小团队的起点，不必是一套大平台
这套思路不需要等到用上 n8n Agents 才能开始。
如果你已经在让 Agent 帮忙做内部自动化，挑一件最小的写操作就够了。例如给工单加标签、给 CRM 补一条备注，或者把日报草稿投到指定频道。不要把数据库或 SaaS 的完整凭据直接放给 Agent。先写一条很窄的 workflow 或脚本，只收必要参数，只做一个动作，把时间和结果记下来。
然后才让 Agent 决定什么时候调用它。
今天这样做，多了一层包装。等动作慢慢增多，你会发现它反而更省事：每一项能力开放到什么程度，都有地方可查；某条动作要收紧、替换或加审批，也不用重写整套 Agent。
Agent 负责在模糊里找路径，workflow 负责在确定处把路修窄。把两者揉成一个全能角色，短期看起来省步骤；把职责拆开，才更像能被长期维护的业务系统。
参考来源
以上来源以 n8n 的产品发布与文档为主，反映的是官方设计和可用性口径；实际权限边界、审批配置和自托管部署效果仍需在具体环境中验证。