n8n 入门与实战

n8n 是一款工作流自动化工具。它从“收到 Webhook 时”“每天早上 9 点”这样的触发条件（触发器）开始，把调用 API、转换数据、按条件分流、发到聊天工具等部件（节点）在界面上用线连起来，让整套处理自动运行。

名字来自 “nodemation”（node ＋ automation）的缩写：n 和 n 之间有 8 个字母，所以叫 n8n。同类工具还有 Zapier 和 Make，n8n 的特点如下。

• 可以在自己的服务器上运行（自托管） ── 用 Docker 就能启动，数据不必离开公司。也有云端版
• 也能写代码 ── 除了在界面上连线，还能把 JavaScript 或 Python 代码作为一个节点混进去，对开发者很友好
• 连接对象多 ── 内置 Slack、GitHub、GitLab、Jira、Google Sheets、PostgreSQL 等节点。官网的集成列表超过 2,000 项
• 容易接入 AI ── 有使用大语言模型的 AI Agent 节点，也支持 MCP（连接 AI 与外部工具的协议）

n8n 是柏林的开发者扬・奥伯豪泽（Jan Oberhauser）在 2019 年启动的项目，从个人工具成长为 AI 时代的自动化平台。

2.0 加入了许多偏向安全的改动：Code 节点改在独立进程（任务运行器）中执行，可执行服务器命令的 Execute Command 节点默认停用等。另外，工作流仅保存不会生效，只有点 “Publish” 才会切换到生产，以防改到一半的版本在生产中运行。

n8n 的工作流由一个触发器和与之相连的节点组成。在节点之间流动的，是 JSON 条目（item）的数组。

处理中途出错时，可以按节点选择“停止”还是“把错误传给下一个节点并继续”。整个工作流的失败，可以用另外准备的错误处理工作流（Error Trigger）接住并通知。

云端还是自托管

如果只是在本机试用，可以按官方步骤用 Docker 启动，然后在浏览器打开 http://localhost:5678。先创建管理员账号即可开始使用。

# 创建保存数据（工作流、加密密钥）的卷并启动
docker volume create n8n_data
docker run -it --rm --name n8n -p 5678:5678 \
  -e GENERIC_TIMEZONE="Asia/Tokyo" -e TZ="Asia/Tokyo" \
  -e N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true \
  -v n8n_data:/home/node/.n8n \
  n8nio/n8n:2.42.6

用于生产时，请把存储从 SQLite（默认）改为 PostgreSQL，固定版本（不用 latest，而是写成 2.42.6），并备份加密密钥（N8N_ENCRYPTION_KEY）。Docker 的用法见开发指南 No.5。

自托管版的版本区别

许可（Sustainable Use License）的注意点

n8n 的许可是“源代码公开，但不同于通常意义的开源”。官方 FAQ 的要点如下。尤其是做外包开发的公司，请先确认交付给客户的形式。

判断标准是“谁能决定工作流的内容”。官方也建议拿不准时向 n8n 公司（[email protected]）确认。本文不构成法律意见。

• 适合 ── 能通过 API 或数据库完成的处理、由事件驱动的处理、步骤明确的重复作业、身边有工程师的团队
• 不适合 ── 操作只有界面的系统（RPA 的领域）、需要毫秒级速度或批量处理海量数据（专用批处理或流处理更好）、需要严格事务的业务逻辑本身（写在应用里）

下面以 Web 系统开发现场为例，实际搭建并运行。对象是开发指南 No.5中使用的客户管理系统（Spring Boot ＋ Vue ＋ PostgreSQL）。

常见的烦恼

每次把新版本部署到测试环境，负责人都要对照检查表（Excel）手动确认页面和 API，贴截图、把结果写到群里，有问题再去建单 ── 是不是很熟悉？一次虽然不长，但每次部署都要做，还容易漏看、漏记。

用 n8n 搭建的流程

1. CI（GitLab CI、GitHub Actions 等）在部署到测试环境后调用 n8n 的 Webhook
2. n8n 读取测试用例（URL、期望的状态码、应包含的字符串），依次调用页面和 API 并判定
3. 再用只读用户连接数据库，确认迁移没有失败、主数据存在
4. 汇总结果发到聊天工具，不通过时自动建单
5. 用 HTTP 状态码（200／422）把结果返回给 CI，不通过就让流水线停下

① 把测试用例放进数据表

② 由 CI 调用 Webhook

Webhook 节点设置为用请求头中的令牌认证，并选择“用 Respond to Webhook 节点返回响应”。CI 端以 GitLab CI 为例可以这样写（示例）。

# .gitlab-ci.yml（节选）
acceptance:
  stage: verify
  needs: [deploy_staging]
  script:
    - >
      curl --fail-with-body -sS -X POST "$N8N_URL/webhook/acceptance"
      -H "X-Api-Key: $N8N_TOKEN" -H "Content-Type: application/json"
      -d "{\"env\":\"staging\",\"version\":\"$CI_COMMIT_TAG\",
           \"commit\":\"$CI_COMMIT_SHORT_SHA\",\"pipeline\":\"$CI_PIPELINE_URL\"}"

③ 用 HTTP Request 节点调用

• Method 写 {{ $json.method }}，URL 写 {{ $json.url }}，用表达式填入测试用例的值。进来 4 条数据，就调用 4 次
• 打开 Options 中的 Include Response Headers and Status 和 Never Error。遇到 404 或 500 也不会停下，状态码交给下一个节点判定
• 把 Settings 中的 On Error 设为“继续”，连接不上时也能进入判定

④ 用 Code 节点判定

// 把测试用例与 HTTP 结果逐条对照（节选）
const cases = $('受入テストケースを読む').all();
return $input.all().map((res, i) => {
  const c = cases[i].json;
  const status = res.json.statusCode;
  const body = String(res.json.data ?? '');
  const okStatus = status === c.expect_status;
  const okText = !c.expect_text || body.includes(c.expect_text);
  let detail = 'OK';
  if (status === undefined) detail = '接続できない';
  else if (!okStatus) detail = `ステータス ${status}（期待値 ${c.expect_status}）`;
  else if (!okText) detail = `期待した文字列がない：${c.expect_text}`;
  return { json: { case_no: c.case_no, title: c.title, ok: okStatus && okText, status, detail } };
});

节点名和提示语是日文，因为示例是为日本的开发团队制作的。

⑤ 检查数据库

在 Postgres 节点中使用只能执行 SELECT 的用户查询，查看迁移（Flyway）历史和主数据的条数。

SELECT
  (SELECT count(*) FROM flyway_schema_history WHERE NOT success) AS failed_migrations,
  (SELECT max(version) FROM flyway_schema_history WHERE success) AS schema_version,
  (SELECT count(*) FROM customer) AS customers;

⑥ 汇总、分流、返回

再用一个 Code 节点合并 API 与数据库的结果，生成通知文字和工单正文。IF 节点判断是否“全部通过”：通过则发通知并向 CI 返回 200；不通过则建单、发通知并向 CI 返回 422。建单可以用 GitLab、GitHub、Jira 等节点，或用 HTTP Request 调用各服务的 API。

在 2.x 中，改完工作流后一定要 Publish。只保存的话，Webhook 仍按上一次 Publish 的版本运行（笔者就曾以为改好了，实际跑的还是旧版本）。

在测试环境部署 1.0.1 版后调用，6 项全部通过。接着部署因配置错误导致 API 路径错位的 1.0.2 版（为了验证而故意加入的错误）再调用，3 项不通过，自动建单，CI 收到 422。

# 从 CI 调用时的响应（1.0.2）
{"result":"failed","passed":3,"total":6,"issue":"https://gitlab.example.com/crm/-/issues/102"}
HTTP 422

# 聊天中收到的消息（日文原文）
【受入チェック NG】staging v1.0.2（9d81e0c）3/6 件 合格
[OK] AC-01 画面のトップが表示される：OK
[NG] AC-02 アプリが起動している（ヘルスチェック）：ステータス 404（期待値 200）
[NG] AC-03 顧客一覧を取得できる：ステータス 404（期待値 200）
[NG] AC-04 顧客を登録できる：ステータス 404（期待値 200）
[OK] DB-01 マイグレーションの失敗がない：失敗 0 件（適用済み V1）
[OK] DB-02 顧客マスタにデータがある：3 件
課題：https://gitlab.example.com/crm/-/issues/102

聊天工具和工单系统由为验证准备的接收端（模拟服务）代替。实际运用时换成 Slack、Teams、GitLab 等节点或 API。

有什么变化

注意事项

• 测试数据会增加 ── 登记类测试每次都会产生数据。用一看就知道是测试的名称，并准备定期清理的工作流
• 权限最小化 ── 数据库用只读用户，Webhook 必须带令牌。只针对测试环境，不要对着生产
• 不能代替测试 ── 它不能代替单元测试或 E2E 测试，只是确认“部署是否正确完成”。细致的规格验证交给应用自己的测试
• n8n 本身也要运维 ── 固定和升级版本、备份、保管加密密钥。几乎每周都有新版本，要先定好升级流程
• 团队使用时 ── 免费的 Community 版无法与其他成员共享工作流和凭据。多人维护时也要考虑付费版

RPA（机器人流程自动化）是让软件机器人像人一样操作界面来完成业务的机制：读取界面上的项目、点击、输入、粘贴到另一个应用。最大的特点是，即使对方系统没有 API，只要有人能操作的界面就能自动化。

不过，“业务自动化”的工具并不只有 RPA。大致可以这样划分。

UiPath 是怎样的产品

UiPath 于 2005 年在罗马尼亚布加勒斯特以 DeskOver 之名创立，2015 年更名为 UiPath，2021 年在纽约证券交易所上市，是 RPA 的代表企业。在 Gartner 的 RPA 魔力象限中，截至 2025 年连续 7 年被评为“领导者”。如今它不只做 RPA，而是标榜包含 AI 智能体在内的“智能体自动化平台”。

价格方面，有面向个人和符合条件组织的免费 Community，每月 25 美元起的 Basic（最多 2 个机器人，数据仅在欧洲区域），以及需询价的 Standard 和 Enterprise，费用随用户数和机器人数累加（2026 年 10 月官网信息）。

先说结论：只要对方有 API 或数据库连接入口，并且构建者是开发者（或有开发者支持的团队），很多场景都可以用 n8n 替代。

另一方面，在下面这些场景中，用 n8n 替代 UiPath（或面向企业的 RPA 产品）很难，或者不划算。

反过来说，只要“只有界面”“在人的电脑上”“全公司统管数百个机器人”都不符合，就可以把 n8n 作为有力候选。

不必二选一。API 能到达的交给 n8n，只有界面的交给 RPA，接口处用 API 连接，这是比较现实的做法。

选择时要确认的事

已经在用 UiPath 的公司，可以先盘点现有机器人，把“用 API 就能完成的”迁到 n8n，效果最容易显现。刚开始做自动化的开发团队，建议先用 n8n 从开发和运维的自动化小步起步，遇到只有界面的系统时再考虑 RPA。