n8n 是什么？把 API、Webhook 和 AI Agent 串起来的自动化积木
我一直觉得，很多人第一次接触 AI Agent 的时候，会把“Agent”想得太玄乎：好像必须是一个会自己思考、自己规划、自己改代码的大模型系统。
但真放到自己的网站、服务器、路由器这些日常折腾场景里，你会发现还有另一类东西特别重要：它不一定很聪明，但它很会把事情串起来。
n8n 就是这种工具。
它不是一个单纯聊天机器人，也不是某个大模型客户端。更准确地说，n8n 是一个开源自动化工作流平台。你可以把它理解成一块“自动化插线板”：左边接 Webhook，右边接数据库，中间接 HTTP API、邮件、表格、消息通知，必要时再接一个大模型节点，让它帮你判断、总结或者生成内容。
这篇不写玄学，也不吹“全自动财富机器”。我只按一个普通站长、设备折腾党的视角，说说 n8n 在 AI Agent 体系里到底适合干什么。
一、n8n 到底是什么？
n8n 的核心是“节点 + 流程”。
比如一个最简单的流程可以是这样：
- 收到一个 Webhook 请求；
- 读取请求里的标题和链接；
- 调用大模型 API 做摘要；
- 把结果写入表格或数据库；
- 最后发一条 Telegram / QQ / 邮件通知。
从这个角度看，n8n 和 Dify、FastGPT、LangGraph 这类工具不太一样。
Dify 更像是“把一个 AI 应用搭出来”；FastGPT 更偏知识库问答和企业应用；LangGraph 更适合程序员写复杂 Agent 状态机。而 n8n 的强项是：我不关心你里面是不是 AI，我先把各个系统连通。
这点对个人站长很实际。比如我的 ai.godsun.pro 这种 WordPress 教学站，真正麻烦的往往不是“写一段文字”，而是这些琐碎动作：生成内容、生成配图、上传媒体、设置分类、检查 URL、失败后提醒、第二天继续补发。这里面有些步骤适合 Agent 判断，有些步骤其实就是固定流程。
n8n 就适合接住这些固定流程。
二、它在 Agent 体系里的定位：不是大脑，更像神经线
如果把一个完整 Agent 系统拆开看，大概有几层：
- 大模型：负责理解、生成、判断；
- Agent 框架：负责规划任务、调用工具、管理上下文；
- 自动化平台：负责把外部系统连起来；
- 数据和消息通道：负责存储、触发、通知。
n8n 更接近第三层。
它不一定要替代 Hermes Agent、Codex、Claude Code 这类“会干活”的 Agent。更合理的用法是：让 n8n 做触发器和流程编排，让 Agent 做需要判断和生成的部分。
举个很接地气的例子：
- 每天早上 n8n 定时触发；
- 检查 WordPress 最近是否有文章；
- 如果没有，就通过 API 调用 Hermes Agent 或某个写作流程；
- 写完后再走发布、配图、验证；
- 如果公网 URL 返回 502，就发消息提醒，或者触发恢复脚本。
这里 n8n 并没有“变聪明”，但它让整个链路更稳。它负责按时按点、按条件把事情推进下去。
这也是我觉得它值得放进 Agent 大全的原因：不是所有 Agent 平台都必须站在聚光灯下面，有些工具就是负责接线、触发和兜底。
三、n8n 适合谁？
1. 有多个服务要打通的人
如果你只是每天打开一个聊天框，让 AI 帮你写几句话，那 n8n 可能有点重。
但如果你已经有 WordPress、Telegram、飞书、表格、数据库、Webhook、NAS、服务器脚本这些东西，n8n 的价值就出来了。
它能把“原本要手动点来点去”的流程变成自动链路。比如：
- 新表单提交后自动通知；
- RSS 有新内容后自动总结；
- 网站异常时自动发消息；
- GitHub issue 新增后丢给大模型分类；
- 每天固定时间生成一份站点巡检报告。
这些事情单独看都不难，但每天重复就烦。
2. 想玩 Agent，但还不想写太多代码的人
n8n 的可视化流程对新手比较友好。很多常见服务都有现成节点，HTTP 请求也能直接配置。
当然，它不是完全零门槛。你至少要理解 API、JSON、Webhook 这些概念。但相比自己从零写 Python 脚本、处理鉴权、处理重试，n8n 的上手压力低一些。
3. 小团队或个人站长
对个人站长来说，n8n 最实用的不是“炫技”，而是降低漏事概率。
比如文章发布后自动检查：
- 页面是否 200；
- 图片是否能打开；
- 是否误发成 future；
- 是否有 404；
- 是否需要发消息提醒。
这些检查很枯燥，但它们直接关系到网站质量。AI 写得再好，如果文章没发布成功、图片挂了、链接打不开，最后还是白忙。
四、不适合谁？
n8n 也不是万能的。
如果你只是想找一个“开箱即用的聊天机器人”，n8n 不适合。它没有 Dify 那种完整的应用前台，也不是 ChatGPT 那样打开就能聊。
如果你追求非常复杂的 Agent 规划能力，比如多轮推理、状态回滚、代码级工具调用、复杂记忆系统，那 n8n 也不是主角。它可以参与流程，但不适合承担全部智能。
还有一点要注意：n8n 自托管虽然自由，但并不等于零维护。你要考虑：
- 容器升级；
- 数据库备份；
- 凭据安全；
- Webhook 暴露到公网的安全边界；
- 流程失败后的重试和告警。
这些都是真实运维问题，不是画几条线就结束。
五、最简部署/使用思路
n8n 常见有两种用法：云服务版和自托管版。
云服务省事，但长期成本和数据位置要自己权衡。自托管更自由，适合放在云服务器、N100 小主机、NAS 或家庭内网机器上。
如果只是个人折腾，我更建议先从 Docker / Podman 容器开始，不要一上来就把它做成复杂集群。
一个比较稳的思路是：
- 先在内网部署 n8n；
- 用本地文件或数据库保存工作流；
- 确认基础流程能跑；
- 需要公网 Webhook 时，再通过反代、HTTPS、访问控制逐步开放；
- 涉及密钥的地方，不要把 API Key 明文写在文章、截图或公开仓库里。
如果是在低配设备上，比如路由器或 512MB 内存的小盒子，我个人不建议硬上 n8n 做主服务。它比纯脚本更吃资源，也要跑 Node.js 和数据库。路由器更适合做状态采集、网络入口、轻量脚本；n8n 主体还是放在 N100、云服务器或 ARM64 小主机上更靠谱。
六、和其它 Agent 怎么分工？
我会这样分：
- n8n：负责定时、触发、连接各个平台；
- Hermes Agent：负责真正的任务执行，比如写文章、查站点、调工具；
- Dify / FastGPT：负责面向用户的知识库问答或固定 AI 应用；
- Codex / Claude Code：负责代码修改、项目级开发；
- LangGraph / AutoGen / CrewAI：适合程序员做更复杂的 Agent 编排实验。
也就是说，n8n 不一定是“最聪明的那个”，但它可以是“最守时的那个”。
一个现实的 Agent 系统，往往不是一个工具打天下，而是多个工具各干各的。会写代码的就写代码，会接 API 的就接 API，会定时触发的就定时触发。
七、我的建议：先拿它做小流程，不要一开始就做大平台
如果你第一次接触 n8n，我不建议一上来就做“全自动内容工厂”或者“全自动运维中心”。这种目标听起来爽，实际很容易翻车。
更稳的做法是先做三个小流程：
- 一个 Webhook 测试流程：收到请求后发消息；
- 一个站点巡检流程：每天检查网站状态；
- 一个 AI 摘要流程：输入一段链接或文本，调用模型生成摘要。
这三个跑通之后，你自然就知道 n8n 的边界在哪里。
它能把系统串起来，但不要指望它替你判断所有事情。真正需要判断的部分，还是交给大模型和 Agent；真正需要稳定执行的部分，再交给 n8n。
这才是比较健康的用法。
下期预告
下一篇我准备继续补一个主流 Agent/自动化工具：Make / Zapier 这类云端自动化平台，和 n8n 到底有什么区别。
重点会聊：
- 云端自动化平台适合谁；
- 为什么国内访问和账号稳定性要考虑；
- 和自托管 n8n 怎么取舍；
- 在个人 Agent 系统里，哪些流程适合放云端，哪些最好留在自己机器上。
如果你也是一边折腾 WordPress、路由器、服务器，一边想把 AI Agent 接进日常流程，可以先收藏这篇。n8n 不是最酷的那个工具，但很多时候，它正好是最实用的那根线。
本文基于个人搭建 Agent 教学站、WordPress 自动发布和服务器运维流程整理。
