n8n 是什么
n8n 是一个开源的低代码自动化工具，核心是用「节点」连成「工作流」：一个节点收邮件、下一个节点调 API、再下一个节点写数据库，串起来就是一条自动化流水线。它火起来是因为把原本要写代码才能串的系统对接，变成了拖拽配置，非工程师也能搭。它的定位是「连接器的胶水」，不是单纯的 AI 工具。
Agent Builder 是什么
n8n 在 8 月发布的 Agent Builder，是把 AI agent 能力直接嵌进工作流编辑器。过去 n8n 里用 AI 要手动接 LLM 节点，现在可以用可视化方式定义一个「会自己决定下一步做什么」的 agent：给它目标，它按需调用工作流里的工具节点。等于在原来的确定性流水线里，加了一段「AI 自主决策」的环节。
从触发器到产出的链路
一条典型的 agent 工作流是这样跑的：触发器节点（新邮件到达、定时触发、或外部 Webhook 打过来）启动流程；LLM 节点读取上下文、判断该做什么；工具节点执行具体动作（调业务 API、写数据库、发消息）；最后产出节点把结果落地（归档文件、推送通知、写回一张表）。Agent Builder 的价值在于，中间「判断该调哪个工具」这一步不用你写死分支，由模型按需决定。
它适合什么任务
- 多步骤业务流程：要连三四个外部系统、步骤固定但偶有例外的，最划算。
- 要接真实系统的：发邮件、写库、调内部 API，这类确定性动作模型自己跑比人点快。
- 非高频定制的：流程相对稳定、一个月改不了几次的，可视化维护成本低。
和纯代码 agent 的差异
最大差别在可维护性：n8n 改流程是拖节点，非工程师能上手；纯代码 agent 改逻辑要动代码、要会跑环境。反过来，纯代码在复杂分支、自研推理、超低延迟上更灵活，n8n 卡在节点能力边界时反而别扭。选型看团队：没人写代码就 n8n，要深度定制就代码，不是谁取代谁。
一个常见误区：别把全部逻辑塞进 agent
新手容易犯的错是把整条流程都交给 agent 自主决策，结果不可控、难调试，出问题不知道卡在哪。更稳的做法是「确定性部分写死、不确定部分交给 AI」：文件搬运、写库这些固定动作用普通节点，只有「该归哪类」「这句话什么意思」这类判断留给 agent。混合架构比全 agent 更可预测，也更好排查哪一步出错，别为了用 agent 而 agent，可控比炫技重要。
一个真实案例
某团队用 Agent Builder 搭了「邮件附件自动归档」：触发器监听指定邮箱，新邮件到来后 LLM 节点读取附件内容和标题，判断它属于合同、发票还是设计稿，再调用工具节点把文件存到对应分类目录、并在数据库写一条索引（文件名、类型、来源、时间）。原本要行政每天手动整理半小时，现在自动完成，人只复核异常。它省掉的是「分类判断」这个最耗人的环节，不是省那点点击。
必须说清的边界
Agent Builder 不适合三类场景：一是超低延迟要求（agent 决策有推理耗时）；二是极复杂的自定义逻辑（节点表达不了）；三是需要自研模型推理的（它调用现成模型，不做训练）。它是「流程自动化加 AI 决策」的组合拳，不是万能 agent 框架，套错场景反而慢。
局限声明
n8n 与 Agent Builder 的功能、定价、节点能力随版本迭代，本文基于 8 月发布信息与使用经验，具体可用节点与限制以你部署的版本文档为准。涉及敏感系统对接时，权限与数据安全须自行评估，工具不替代合规责任。