n8n零基础教程：从零搭建3个AI自动化工作流

AI Agent 工具越来越多，Hermes、OpenClaw 这类产品功能强大，但大量特性对普通用户来说根本用不上。如果你只想让重复劳动自动跑起来，n8n 依然是门槛与收益平衡得最好的选择。这期教程的价值在于：它没有停留在"拖拽节点"的概念介绍，而是从空白画布出发，连续搭建三个复杂度递进的工作流，把 n8n 的两条底层逻辑彻底讲透。

先解决跑在哪：云服务还是自建服务器

开始搭工作流之前，最关键的决策是 n8n 的运行环境。官方云服务适合试用，但最便宜的套餐把执行次数限制在每月 2500 次，一旦自动化跑得更频繁，就得升级到更贵的档位。

自建服务器则是另一套账：执行次数不设上限、数据完全留在自己手里、按年算下来成本明显更低。听起来是件技术活，但通过 Hostinger 的 VPS 可以一键部署 n8n，不需要碰终端命令。教程作者选择的是 KVM2 方案，双核加 8GB 内存，对文中演示的所有工作流来说绰绰有余，长期套餐月费在 10 美元以内。部署完成后设置好所有者账户即可进入，之后所有工作流 24 小时运行，合上笔记本也不影响。

VPS（虚拟专用服务器） 可以理解为在一台物理服务器上通过虚拟化技术划分出的独立小服务器，拥有自己的操作系统、CPU、内存和公网 IP。与共享主机不同，VPS 的资源相对隔离，用户可以完全控制环境，适合部署 n8n 这类需要长期运行、可能消耗较多资源的自托管应用。KVM 是目前主流的虚拟化方案之一，性能损耗小、隔离性好，Hostinger 的 KVM 系列 VPS 即基于此。选择 VPS 时主要看 vCPU 核数、内存大小和月流量，2 核 4GB 起步通常就足以支撑个人或小团队的 n8n 工作流。

三个工作流背后的两条底层逻辑

在动手之前，有必要先说清 n8n 的心智模型。每个节点就是一次任务执行——收到一封邮件、让 AI 读一遍、把数据写进表格——你按期望的顺序把节点连起来，整条链路就会在触发条件满足时自动跑完。

教程反复强调的两个基础概念，是所有自动化共通的：

第一，每个工作流都始于一个事件。 触发方式可以是手动执行、定时调度、表单提交、聊天消息、应用事件（新邮件、Stripe 新付款、Google Drive 新文件），以及最通用的 Webhook 调用。选择哪种触发，决定了工作流如何被"唤醒"。

第二，一个节点的输出就是下一个节点的输入。 这条规则衍生出 n8n 最核心的操作习惯：字段不用手打，从左侧输入面板拖进目标框，它就变成动态标签，值随上游数据自动变化。同一套两个节点，发给一个人和发给一千个人，写法完全一样。

工作流一：表单自动发送免费指南

第一个工作流用"表单提交"触发，搭建一个收集姓名、邮箱和需求描述的表单，提交后自动发送指南邮件，同时给运营者发一封通知。

操作上有几个值得记住的细节。测试阶段使用节点的测试 URL，表单只在编辑器打开时可用；点击 execute step 后，n8n 会以访客视角在新标签页打开表单。输出面板顶部的图钉图标可以把这次提交钉住，后续节点测试时直接复用这份数据，不必反复填写表单。

Gmail 节点第一次使用需要配置凭证，自建版需要在 Google Cloud 建项目、粘贴 client ID 和 secret，官方文档有逐步指引。作者给了一个更省事的思路：直接问 Claude 要连接步骤，说明自己是自建版本，它会给出对应的界面路径。邮件正文里用拖拽方式插入姓名和邮箱字段，预览区会显示填充后的效果。默认情况下邮件底部带一行"sent with n8n"署名，在节点里关掉 append n8n attribution 就能去掉。

一个容易被忽略的运维习惯是给节点重命名。一个月后在 executions 标签里看到"Gmail"和"Gmail 1"，你根本分不清谁是谁。确认无误后点击 publish 发布版本，表单的生产 URL 才真正对访客开放。

工作流二：带记忆和边界约束的客服 Agent

第二个工作流从聊天窗口起步，最终改造成能自动回复邮件的客服 Agent。核心是 AI Agent 节点，它下方三个插槽对应三个问题：用什么模型思考、记住什么、能用哪些工具。只有聊天模型是必填项。

模型选择上，教程用了 GPT-5 mini，理由是快、便宜，对客服场景够用。注意这里走的是 API key 按量计费，与 ChatGPT 订阅是两回事，充值 5 美元可以用很久，因为单次回答的成本只是几分钱的一个零头。

记忆是个关键分水岭。没有记忆时，每条消息都是全新对话——你说"十月要去里斯本"，再问"那边天气怎么样"，它完全不知道你在说哪里。挂上 simple memory 后，默认保留最近五条历史消息，追问就能接上前文。这里有个新手常踩的坑：公共聊天页面仍在跑旧版本，改动必须重新 publish 才生效。

真正让 Agent 变得可用的是 system message。教程给的提示词很短：告诉它是某网页设计工作室的客服，列出它被允许使用的五条事实（比如单页网站的价格、账单周期），并明确要求——答案不在清单里时，就说会有人跟进，不要编造。作者的原话是，最后这条规则承担了大部分工作，因为没有约束的 Agent 会自信地承诺一个你从未同意的交付日期。实测中，问五页网站要多久，它准确引用了提示词里的两周；问工作室是否做网店，它坦承没有这个信息。

把聊天触发换成 Gmail 收信触发后，同一个 Agent 就能接管邮箱。此时 memory 的 session ID 要改成发件人邮箱，让每位客户拥有独立记忆；再加一个 Gmail 回复节点，把 Agent 输出填进正文，回复就落在同一线程里。作者指出，触发器和 Agent 是两个独立部件，同一个 Agent 换个触发器就能跑在聊天窗口、收件箱或 WhatsApp 上。

System message（系统消息） 是大语言模型对话中的一个特殊角色，位于用户消息之前，用于设定模型的角色、行为边界和回答规则。它不像普通用户消息那样会被模型“看到”后直接回应，而是作为最高优先级的指令贯穿整个对话。在客服 Agent 场景中，system message 通常包含身份定义（你是谁）、知识范围（允许使用的事实清单）和兜底策略（不知道时如何回复）。相比微调模型，system message 成本极低且修改即时，是控制 AI 输出质量最直接的手段。

Simple memory 是 n8n 内置的轻量级会话记忆组件，底层通常基于内存或数据库存储最近的对话轮次。它的 session ID 相当于会话隔离键：相同 session ID 的对话共享历史，不同 session ID 则互不干扰。在聊天场景中，session ID 可以是固定值或用户 ID；切换到邮件触发时，需改为发件人邮箱，从而为每位客户建立独立记忆。需要注意的是，simple memory 只保留最近若干条消息，并非完整对话存档，长对话中较早的信息会被丢弃。

工作流三：Webhook 接住落地页的等待名单

第三个工作流处理 n8n 不认识的系统——比如你自己的网站。Webhook 本质上是一个 n8n 持续盯着的特殊链接，任何能向它发数据的服务都能启动工作流。

流程是：用 AI 建站工具生成一个带"加入等待名单"按钮的单页站点，弹窗收集姓名、邮箱、公司；n8n 侧选用 webhook call 触发，HTTP 方法设为 POST。这里有个能省一小时的原则——站点和 n8n 必须用同一个方法，节点里设成什么，就告诉建站工具用什么。测试时先点 listen for test event 再提交表单，因为测试 URL 只在点击后到第一个请求到达之间保持开放。

收到的数据会归在 body 字段下。写入 Google Sheets 前，表格必须已有表头行（姓名、邮箱、公司），n8n 靠这一行识别列名，没有表头就无从映射。选 append row in sheet，把左侧字段逐个拖进对应框即可。

发布环节是最容易漏的一步：站点还指着测试 URL，要把 webhook 节点的生产 URL 复制过去替换。最后在设置里配置 error workflow，指定一个失败时运行的工作流——作者用的是一个以 error trigger 开头、只发邮件通知的两节点流程，目的是在客户发现问题之前先知道自己出了问题。

Webhook 是一种“反向 API”模式：不是 n8n 主动去询问某个系统有没有新数据，而是由外部系统在事件发生时主动向 n8n 提供的 URL 发送 HTTP 请求。这个 URL 就是 Webhook 地址，请求方法常見的有 POST（提交数据）和 GET（获取数据）。n8n 的 Webhook 节点有两种 URL：测试 URL 仅在点击“listen for test event”后短暂开放，用于调试；生产 URL 在工作流发布后长期有效，供外部系统正式调用。因此，任何从测试切换到上线的场景，都必须把外部系统里配置的地址替换为生产 URL，否则请求会落空——这也是教程反复强调的高频错误点。

从接收到发出：HTTP Request 节点补上最后一块

三个工作流都在接收请求。要让 n8n 主动向外发请求，用 HTTP Request 节点，它能对接任何提供 API 的应用。真正的门槛从来不是节点本身，而是不知道该填什么。作者的做法是打开 Claude，说明要把哪个系统和 n8n 连起来、期望发生什么，并要求它先读该应用的 API 文档再回答，然后按它给出的步骤获取 API 访问权限，填入 method、URL、认证方式和请求体。

这也解释了为什么三个工作流可以同时运行而不互相拖慢——它们跑在自己的服务器上，没有执行次数限制。

常见问题

n8n 云服务和自建服务器怎么选？ 如果月执行次数低于 2500 次、想省去部署环节，云服务够用；一旦超过这个量级，自建的成本优势会迅速放大，而且数据自主可控。

AI Agent 为什么会编造答案？ 缺少 system message 约束。明确写出它可以使用的事实清单，并规定清单之外一律回复"会有人跟进"，就能显著减少幻觉承诺。

测试正常但线上不生效怎么办？ 检查是否已 publish 发布版本，以及外部系统是否仍指向测试 URL 而非生产 URL。这两处是最高频的排查点。