n8n

n8n（发音为“n-eight-n”）是一款由 n8n GmbH 开发的公平代码（fair-code）工作流自动化平台，由创始人 Jan Oberhauser 于 2019 年首次发布。它与 Zapier 和 Make 属于同一类别，通过基于节点的视觉化画布连接应用程序并自动化流程，但有一个决定性的区别：你可以免费在自己的服务器上进行自托管。Community Edition（社区版）没有执行次数限制、用户数量上限或工作流限制。你唯一的成本就是服务器。截至 2026 年 4 月，该项目在 GitHub 上的星标数已超过 185,000，并服务于 3,000 多家企业客户，包括 Vodafone、Delivery Hero 和 Microsoft。

该平台内置 500 多种原生集成节点，涵盖数据库、CRM、云服务和通信工具，外加完整的 JavaScript 和 Python Code 节点，用于处理超出拖拽范围的复杂逻辑。其 AI 层在 2025 年得到了显著扩展，包括具备记忆功能的专用 AI Agent 节点、规划代理、多代理编排，并原生支持 OpenAI、Anthropic Claude、Google Gemini 和 Mistral AI。2025 年 4 月，n8n 添加了原生 MCP（模型上下文协议）节点，允许像 Claude 和 Cursor 这样的外部 AI 代理直接将 n8n 工作流作为工具调用。这使得该平台不仅是一个传统的集成中心，更是一个强大的 AI 代理运行环境。

2026 年 4 月的 n8n 实际功能

从核心来看，n8n 是一个可视化自动化构建器，工作流中的每个步骤都由一个节点表示。节点可以线性连接，也可以通过条件逻辑、循环和子工作流调用进行分支。Webhook 节点接收传入请求；Transform 节点重塑 JSON 数据；数据库节点写入 PostgreSQL；HTTP Request 节点调用自定义 API。该画布能够处理 Zapier 无法直观呈现的复杂分支逻辑。

AI 代理层是自 2024 年以来最重大的演进。AI Agent 节点作为一个自主循环运行：它接收传入的触发器（通常是聊天消息或 Webhook），从可用的工具节点中进行选择、执行、评估结果并迭代。Memory 节点让代理在会话之间保持上下文。规划代理可以将目标分解为子任务，并委派给专门的子代理。整个多代理系统无需编写代码即可构建，当然，对于需要代码的逻辑，也可以使用 Code 节点。

2025 年 4 月 10 日，n8n 发布了 v1.88.0 版本，引入了原生的 MCP Client Tool 和 MCP Server Trigger 节点，使 n8n 成为首个原生支持 MCP 的主流可视化自动化平台。这意味着在 Claude Desktop 或 Cursor 中运行的 AI 代理可以直接将 n8n 工作流作为工具调用，从而将你的整个自动化库转变为 AI 可访问的函数库。

“绝对是游戏规则的改变者” —— mohamed3nan，n8n 社区论坛，2025 年 4 月，关于 MCP 节点发布的评价

2025 年 12 月发布的 2.0 版本通过隔离的任务运行器引入了默认安全的执行机制，将工作流逻辑与 n8n 主进程分离，以控制故障并减少攻击面。它还添加了发布/保存模型，将草稿与实时推送更改分开，这对于运行生产工作流的团队至关重要。

n8n 与 Zapier 和 Make 的定位对比

Zapier 是市场的老牌产品。它面向非技术业务用户，提供向导式设置、6,000 多种集成，以及按任务收费的定价模型（多步 Zap 中的每个操作都单独计费）。一个运行 1,000 次的 10 步 Zap 会消耗 10,000 个任务。Zapier 没有自托管选项，低级套餐不支持自定义代码，也没有带记忆和工具循环的专用 AI 代理运行环境。它的优势在于简单性和支持应用的广度。n8n 在大体量下的定价更具优势（1,000 次工作流执行 = 1,000 次 n8n 执行，而 Zapier 需要 10,000 个任务），增加了完整的 JavaScript/Python 代码访问权限，并提供了 Zapier 无法比拟的自托管功能。社区成员一致反馈，从 Zapier 中级套餐切换到自托管 n8n 后，每年可节省 $300-$500。

Make（前身为 Integromat）是最接近的可视化竞争对手。它使用“Scenario”画布，对于简单的流程来说，可以说比 n8n 的画布更干净、更直观，而且它按操作而不是任务定价。然而，Make 没有自托管选项，这将其排除在所有数据主权用例之外。Make 的 AI 集成很基础：提供 AI 步骤，但没有专用的代理循环、没有记忆节点，也不支持 MCP。n8n 的多代理编排和 MCP 集成与 Make 目前提供的任何功能都不在同一个层级。Make 赢得了那些想要精致视觉体验而不接触 JSON 的非技术用户；而 n8n 则赢得了需要数据控制、代码访问或真正 AI 代理工作流的团队。

Pipedream 是开发者优先的托管替代方案。n8n 是带有可选代码的可视化画布，而 Pipedream 则是代码优先，采用垂直堆叠的线性步骤；每个步骤都可以是 Node.js、Python、Go 或 Bash。Pipedream 是完全托管的，没有自托管选项，适合那些想要开发者级别的强大功能而无需承担 DevOps 开销的团队。n8n 在可视化工作流构建和自托管方面击败了 Pipedream；而对于那些习惯用代码而不是节点思考，并希望获得无需基础设施管理的无服务器运行环境的团队来说，Pipedream 则优于 n8n。

工作流和代理循环的实际体验

对于熟悉 API 的人来说，在 n8n 中构建一个基本的 Webhook 到数据库的工作流只需不到 30 分钟。而构建一个生产级的 AI 代理（处理支持工单、查找客户记录、起草回复并将异常路由到人工审核队列）则需要几天时间。一位开发者记录了构建一个 23 节点的发票自动化工作流的过程，耗时 3 天，将客户每周 40-50 张发票的手动处理量降低到了 90% 的自动化处理。

简单与复杂之间的体验差距是真实存在的。对于简单的触发-操作自动化（如 Google Sheets 添加行，发送 Slack 通知），一旦完成初始设置，n8n 并不比 Zapier 难。当工作流出现分支、涉及自定义数据转换或分层多个代理时，难度就会激增。错误消息偏向技术性：当节点失败时，你会看到确切的错误，但解析它需要知道 401 响应意味着什么，以及如何阅读 JSON 解析错误。

“如果你懂技术，并且每月运行超过约 1,500 个任务，自托管 n8n 在 2-3 个月内就能回本。” —— nguyenthieutoan，n8n 社区论坛，2026 年 4 月

自托管增加了一层维护工作。Community Edition 运行在 Docker 上，需要一个数据库（轻量级使用 SQLite，生产环境使用 PostgreSQL），并且需要随着新版本的发布进行定期更新。用户反馈在实际操作中每月需要花费 2-8 小时进行维护。这是定价页面没有提及的免费套餐的真实成本。

n8n 适合哪些人

n8n 的核心用户是开发者或技术运维主管，他们需要的自动化超出了 SaaS 工具所允许的范围。这意味着在大体量工作流上触及 Zapier 定价上限的团队、处理敏感数据且无法通过第三方云服务器路由的公司，以及希望通过可视化界面编排代理工作流而不是从头编写脚本的 AI 构建者。

受监管行业（医疗保健、金融、法律）的企业团队专门使用 n8n 自托管，因为所有工作流数据都保留在他们自己的基础设施内。负有 GDPR 义务的欧盟公司也出于同样的原因使用它。这些团队可能会为 Business 套餐（$800/月）付费，或者运行 Enterprise 版本以获得受监管环境所需的 SSO、SAML、LDAP 和 Git 版本控制功能。

AI 代理用例吸引了一个独特的构建者社区：人们构建自主研究助手、内容生成管道、多步客户服务代理和内部 Copilot。n8n 的可视化代理构建器足够易用，即使编写 Code 节点超出了他们的能力范围，对 API 有基本了解的非工程师也能编排可运行的代理。

n8n 不是什么

对于非技术用户来说，n8n 不是 Zapier 的替代品。如果你的团队无法阅读 JSON 错误消息、无法配置 Webhook，并且不了解 GET 和 POST 请求之间的区别，那么使用 n8n 将会令人沮丧。拥有 18,000 名 LinkedIn 粉丝的 n8n 教育者 Tom Crawshaw 清楚地描述了这种模式：“对 n8n 感到兴奋，花 20 多个小时尝试学习它，结果什么能用的都没建出来。”他 2025 年 11 月的帖子引发了 2,593 条评论，大多数人都证实了这种体验。

除非你为 n8n Cloud 付费，否则 n8n 不是一个托管的、零 DevOps 的解决方案。自托管确实是免费的，但它需要投入时间。服务器更新、失败工作流调试、数据库备份和基础设施扩展都是实实在在的责任。没有任何技术能力的团队应该使用云端套餐或考虑 Zapier。

Business 套餐的定价断崖是一个反复被抱怨的问题。从 Pro（$60/月）升级到 Business（$800/月）是 13 倍的跨度，这通常是因为需要 SSO、Git 版本控制或超过 3 个共享项目而触发的。那些已经超出 Pro 需求但又无法承担 $800/月的中型团队，只能选择自托管或留在缺乏他们所需组织功能的套餐上。截至 2026 年 4 月，n8n 尚未解决这一差距。

n8n 也不是一个实时、高频的事件处理器。它能很好地处理计划任务和 Webhook 触发的工作流，但处理大型数据集（每次运行 500 多个项目）的工作流可能需要 10-15 分钟，不适合对延迟敏感的应用程序。