一句话 — n8n 和 Dify 在自托管 AI 评测里经常并列出现，但它们想占据栈里完全不同的层。对照一套自建 AI 系统认真评估之后，我们吸收了 n8n，跳过了 Dify。决策归到同一个问题——“它想占据哪一层，而我是不是已经拥有那一层？"——两个平台的答案正好相反。这篇把决策框架完整摊开，你可以对着自己的栈跑一遍同样的评估。

为什么这个对比在 2026 年还值得写

半年前问"哪个 OSS AI 平台应该自己跑”，认真的答案大概只有三个。今天有几十个，而且彼此功能严重重叠。Dify 和 n8n 在评估清单里几乎总是并列出现——都用 TypeScript 写、都能 Docker 自托管、都有可视化编辑器、都能调 LLM。

这种表面的相似很有误导性。它们想占据的栈层完全不同。 把它们当替代品评估是一个范畴错误，代价就是一周的部署+返工。

对照已有的自托管栈认真评估后，我们得到的结论是：

• Dify 想当 orchestrator。如果你已经有一个 orchestrator，Dify 一无是处。
• n8n 想当执行层（execution layer）。如果你还没有执行层，n8n 是市面上最好的开箱选项之一。

Dify 是什么

Dify 是开源 LLM 应用开发平台（Apache 2.0，GitHub 55k+ ⭐）。它的卖点：

• 可视化工作流编辑器 — 拖节点构建 AI 流水线
• 内置 RAG — 上传文档，得到一个可查询的知识库
• Agent 构建器 — 预打包的 prompt 模板 + tool calling
• 模型网关 — 在 OpenAI / Anthropic / DeepSeek / 本地模型之上抽象一层
• 可观测性 dashboard — 请求日志、延迟、成本

2025–2026 年 Dify 用自研的 “Beehive Runtime” 替换了底层 LangChain，工程实现确实扎实。这个产品本身是认真做的。

它的目标用户：想发布一个 AI 应用、但不想写代码、也不想自己维护各个基础设施组件的人。

同族产品：Flowise、Langflow、FastGPT。这些都是"平台优先"的 AI 构建工具。

n8n 是什么

n8n 是开源工作流自动化（GitHub 162k+ ⭐）。可以理解成自托管版 Zapier，但有写代码的逃生口。

• 400+ SaaS 连接器 — Notion、Slack、Stripe、Telegram、GitHub 等等
• Trigger → Action → Condition 可视化工作流编辑器
• Webhook — 接收外部事件并路由到动作
• 轮询触发器 — RSS、定时任务、文件监听
• 原生重试 / 错误处理 — 每个节点都有重试策略

n8n 不想成为 LLM 平台。它有调用 LLM 的节点，但核心定位是"连接任意 SaaS 系统、对事件作出反应"。

这个区分很关键。n8n 是 plumbing-first，AI 节点是可选项。Dify 是 AI-first，其他所有东西都折叠进来。

关键判断题：替换还是吸收？

评估任何平台时，正确的问题不是“它好不好？"。正确的问题是 “它想占据我栈里哪一层，而我是不是已经拥有那一层？”

答案只有两种：

• 替换（Replace）：平台想占据你已有的层。引入它意味着推掉能跑的代码，换成一个更不灵活的黑盒等价物。
• 吸收（Absorb）：平台想占据你还没有的层。引入它只是填补一个空白，不和任何东西竞争。

这个框架把原本会拖好几天的模糊辩论，压成了几个清晰快速的决定。文章剩下的部分把这个框架对照两个平台各跑一遍。

Dify 在栈里想占据的位置

Dify 想一口气占据五层。下面把每一层对照"一套已经有 code-based orchestrator 的栈”（任何 agent harness——Claude Code、LangGraph、或自研）：

更深一层的洞察：Dify 是为"不写代码但想发布 AI 应用"的人造的。 这是一个真实存在的市场，Dify 服务得也不错。但只要你已经有一个 code-based orchestrator 在跑，引入 Dify 就意味着推掉能跑的组件，换成不灵活的等价物，只是为了塞进一个可视化 UI。净成本：一周迁移、灵活性全损、零新增能力。

我们的结论：跳过。 不是因为 Dify 差，而是没有空白给它填。

n8n 在栈里想占据的位置

n8n 的定位结构性地不同。它不想当大脑，它想当电线。

n8n 的四个核心能力，对照一套典型的自建 AI 栈：

关键观察：这四个能力没有一个和已有 orchestrator 通常占据的层竞争。 它们坐在下面。它们填的是 code-based orchestrator 单独存在时仍然会有的空白：

• 事件驱动入口（大多数自建栈只有 cron）
• 现成的 SaaS 适配器（大多数自建栈没有通用适配器层）
• 现成的重试语义（大多数自建栈是手写错误处理）
• 公开 RSS 轮询，绕过协议锁定的服务比如 YouTube（大多数自建栈没有）

我们的结论：吸收。 n8n 成为一个依赖——一个维护良好、文档齐全、生产验证过的执行层——不和任何能跑的东西竞争。

浮现出的架构模式

两个决定之后形成的心智模型：

                       Orchestrator（决策，判断）
                       ─────────────────────────────────
                                   │
            ┌──────────────────────┼──────────────────────┐
            │                      │                      │
            ▼                      ▼                      ▼
        知识层                  工具接口                 时间触发器
       （你的 RAG）            （你的 API /             （cron）
                                MCP server）
                                   │
                                   ▼
                       ┌────────────────────────┐
                       │  n8n（执行层）          │
                       │  ─────────────────────  │
                       │  • webhook            │
                       │  • SaaS 适配器         │
                       │  • RSS / 轮询          │
                       │  • 重试 / 状态机        │
                       └────────────────────────┘

给自己设的硬约束：n8n 只能当执行层，永远不当决策层。 n8n workflow 里不放任何 AI 判断。n8n 负责接收信号、转发、失败重试、回传结果。所有判断留在 orchestrator 手里。

为什么需要这个约束？因为 n8n 有 LLM 节点。你能在 workflow 里塞一个"用 GPT 总结这封邮件"的调用。一旦这么干，你的推理就被切成两半——一部分在 orchestrator 的 prompt 上下文里，一部分在不透明的 n8n 节点里——于是你有两个系统在做决策，但没有共享记忆。这就是把简单 workflow 拖进维护噩梦的失败模式。

把 n8n 严格限定在 plumbing 角色，是让这个架构跑得起来的纪律。

部署 n8n 前值得知道的三个踩坑

第一天跑 n8n 时常让人意外的三件事：

1. REST API 不支持 PATCH archive workflow。 API 能创建和读 workflow，但不能通过 API 删除或归档。清理必须走 Web UI。如果你计划动态生成 workflow，需要为手动清理留时间，或者直接写 SQLite 数据库。（在 n8n 2.22+ 修了，2.21.x 线还有这个限制。）

2. Webhook 路径全局唯一，即使 workflow 未激活也占着。 删掉一个 workflow，但 webhook 路径还留着注册表里，挡住任何新 workflow 复用这个路径。把 webhook 命名空间当成你必须管理的扁平全局空间。从第一天起就用 workflow 名做路径前缀。

3. API key scope 不包含 workflow:execute。 API 能读 workflow，但不能编程触发——webhook 是唯一的执行入口。对大多数架构这其实是对的（webhook 就是集成点），但如果你期待"用 API 按需启动一次 workflow"，n8n 不是这个思路。

什么时候你应该选 Dify

公平地说：Dify 是合适的工具，当你：

• 不想写代码，也不想单独维护各个基础设施组件。
• 需要一个精致的 UI 给非技术用户去构建和调整 workflow。
• 想要一站式托管体验（RAG + 模型网关 + 可观测性 + UI），而且这些组件你还没串起来。
• 在为小团队搭一个面向客户的 chatbot，发布速度比架构灵活性重要。

只要其中任何一条描述了你，Dify 是认真的选择，我们不会反对。

什么时候你应该选 n8n

n8n 是合适的工具，当你：

• 需要集成特定的 SaaS 产品（Notion、Slack、Stripe、Telegram 等），不想手写每个 API 客户端。
• 想要事件驱动的 workflow（webhook、轮询、定时），不想自己搭事件总线。
• 想要可视化编辑器让非技术队友能看到和修改流水线。
• 接受 workflow 是 execution-only——没有判断，只有 plumbing。

n8n 不适合：

• 需要多步 LLM 推理且步骤之间共享记忆。用 agent harness（Claude Code、LangGraph、OpenAI Agents SDK）。
• 需要完全控制 prompt 格式、token 预算、fallback 链。n8n 的 LLM 节点对认真的场景太抽象。
• workflow 逻辑每周都变。可视化编辑器对稳定 workflow 很好，对快速迭代的 workflow 是拖累——代码比节点重构快得多。

更深的原则：“模型是 commodity，编排才是护城河”

跳过 Dify、吸收 n8n，这两个决定其实是同一个原则的两个侧面：

• 模型（DeepSeek、GPT、Claude、Mistral、Llama）是可互换的。一个环境变量切换。
• 平台（Dify、LangFlow、Flowise）也是可互换的。它们用不同方式打包相似的能力。
• 编排（orchestration）——把模型、知识、工具、结果连起来的那层系统——才是真正的杠杆所在。

当你已经有一个强 orchestrator，你就不需要一个想当 orchestrator 的平台。你需要把 plumbing 做好的 plumbing。这就是 n8n 赢得位置的理由。

这个原则可以泛化。每次评估一个 AI 平台，先问自己：它想占据我的编排层，还是填补编排层下面的空白？ 如果是"占据"而你已经有 orchestrator，跳过。如果是"填补空白"而那个空白真实存在，吸收。

收尾

两个平台。相反的决定。底层逻辑一样：它想占据哪一层？我是不是已经拥有那一层？

• Dify 想占据编排层 → 已被覆盖 → 拒绝。
• n8n 想占据执行层（事件触发、SaaS 集成、重试、轮询）→ 未被覆盖 → 吸收。

如果你现在正在评估自托管 AI 工具，这是第一个该问的问题。能省下很多没意义的部署，更能省下后面更没意义的返工。

参考

• Dify GitHub — 55k+ ⭐，Apache 2.0
• n8n GitHub — 162k+ ⭐，Sustainable Use License
• Model Context Protocol（MCP）规范
• 上一篇：RAG vs Agents