去年写过两篇 n8n 的东西，当时主要拿它做定时任务和数据搬运。这次回头折腾它的 AI Agent 节点，感受明显不一样了：以前的 n8n 是"流程图里塞一个 AI 步骤"，现在的 n8n 是"给 AI 配一箱工具，让它自己决定怎么干活"。
这篇不重复基础注册部署，聚焦 Agent 节点本身，讲清楚它跟普通工作流的区别，以及我搭一个"自动盯数据、异常就写日报"的智能体踩过的坑。
AI Agent 节点和普通工作流的区别
普通 n8n 工作流是死的：触发器响了，节点从上往下执行，每一步做什么都是你预先画好的。
AI Agent 节点不一样。官方文档的定义是：连接一个聊天模型和一个或多个工具，由 Agent 自己决定调用哪些工具来完成任务。你只负责给它工具箱，路径让它自己挑。
打个比方：普通工作流是流水线，Agent 是一个坐在工位上、桌上摆着一堆工具的助理。你说"帮我处理这封邮件"，流水线只会按固定步骤拆解，助理会先看内容，可能查附件、可能去查表格、可能直接回复。
另外注意一点：从 n8n 1.82.0 起，老的 Agent 类型设置已经废弃，所有 AI Agent 节点统一按 Tools Agent 模式工作，网上老教程里让你选 Agent 类型的部分可以直接跳过。
搭一个最小可用的 Agent
核心就三块：
1. Chat Trigger
作为入口，装个网页聊天窗口，你的 Agent 就有了自己的界面。
2. AI Agent 节点
在里面写系统提示词，定义这个助理的角色和边界。比如我写的是："你是数据分析助理，负责检查每日销售数据，只讨论数据相关的问题。"
3. 工具子节点
关键一步：AI Agent 节点必须至少挂一个工具子节点，否则跑不起来。常见的有 Postgres/MySQL 工具（直接查数据库）、HTTP Request 工具（调外部接口）、Calculation 工具（算数）、Code 工具（跑脚本）。
把 Chat 模型挂上去（OpenAI、Claude、Gemini 或本地模型都行），一条最简单的 Agent 流水线就通了。
我的实战：每天自动盯数据的助理
具体场景：每天早上 8 点自动检查前一天的订单数据，有异常就汇总成一封日报发飞书。
流程是这样画的：
Schedule Trigger（每天8点）→ Postgres 节点查昨日汇总 → IF 节点判断波动是否超过阈值 → 超了就走 AI Agent，挂上数据库查询工具，让它自己去拉明细、定位是哪个品类出的问题 → 输出整理成日报格式 → 飞书节点推送。
重点在 AI Agent 那一步：传统做法是我写死 SQL 逐个品类查，Agent 的做法是我在提示词里告诉它"这里有一个能查订单表的数据库工具，请找出波动最大的三个品类并总结可能原因"，查询逻辑它自己组装。
实测下来，简单场景它能处理得不错，数据库工具用得有模有样。但有一个重要经验：别让它自由发挥太狠。有一次它自己发明了一个表名，查了个空结果还在那儿振振有词地分析。所以工具子节点里的 SQL 权限一定要收窄，只给只读账号、只开放必要的表。
三个值得注意的坑
工具不是越多越好。给 Agent 挂十几个工具，它选错的概率直线上升。我的原则是每个 Agent 专注一类事，工具控制在三五个以内。
系统提示词要把边界写死。"你是一个助理"没用，要写"你只能调用 X 和 Y 工具，遇到 Z 情况直接回复'超出能力范围'"。它比你想象的更听话，前提是你说清楚了。
重要动作必须加人工确认。n8n 的 Human in the loop 做法很成熟：Agent 输出后接一个等待批准的节点，人点头了才执行发邮件、写数据库这类动作。全自动驾驶翻车一次，你就再也不会想用第二回。
什么时候该用 Agent，什么时候别用
判断路径是固定的就别用 Agent。步骤确定、顺序确定的流程，普通工作流更可靠、更便宜、更好排查。Agent 适合路径不确定的场景：输入五花八门、需要多步查询和判断、你没法穷举所有分支的情况。
一句话：能用普通流程解决的用普通流程，确实需要"随机应变"的再上 Agent。
相关阅读：之前写过 n8n+Dify 搭个人自动化助手、AI Agent 概念入门，配合这篇看更完整。