一句话 — 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

TL;DR — 我们逆向了 Claude Code 的 TypeScript 源码，搞清楚了它的 Agent 架构如何处理安全、复杂任务和工具权限。然后把这些模式用到了一个开源项目上——让玩家在泰拉瑞亚游戏里跟 AI 聊天，AI 还能给道具、改天气、传送玩家。以下是我们的发现、实现过程和踩坑总结。

为什么要拆 Claude Code 的源码

Claude Code 不只是个编程助手。底层它是一个 Agent 运行时——会 spawn 子 Agent、管理文件权限、跑 bash 命令、判断什么时候该问用户什么时候该直接做。我们想搞清楚它的内部机制，然后把这些想法用到一个完全不同的场景：泰拉瑞亚游戏服务器。

我们的项目 terra_llm_bridge 把泰拉瑞亚 TShock 服务器接到了一个 LLM 上。玩家在聊天框打 @ai 就能跟 AI 对话——但 AI 不止能聊天，还能做事：给道具、改天气、传送玩家，甚至能切换困难模式。最后那条就是我们翻车的地方。

第一次有玩家让 AI 设成雨天，LLM 自作主张调了 terra_world_hardmode(confirm=True)——把整个服务器的世界不可逆地切成了困难模式。没人要求它这么做。模型自己觉得该做就做了。

我们需要一个真正的权限系统。于是去翻 Claude Code 的源码。

Claude Code 的 7 层权限架构

通读 src/utils/permissions/permissions.ts 的约 1500 行代码，加上 Agent 工具的基础设施（约 3800 行），一套清晰的架构浮现出来。Claude Code 不是靠单点检查做安全——它有七层：

Layer 1a: 拒绝规则   →  "永远不允许 Bash(git push --force)"
Layer 1b: 询问规则   →  "Bash(curl *) 总是弹窗确认"
Layer 1c: 工具自检   →  每个工具 checkPermissions() 自己的逻辑
Layer 1d: 工具自拒   →  Read 工具白名单特定路径
Layer 1f: 内容规则   →  "就算 bypass 模式，npm publish 也要弹窗"
Layer 1g: 安全检查   →  ".git/、.claude/ 永远不能绕过用户确认"
Layer 2:  模式旁路   →  bypassPermissions / auto / acceptEdits / dontAsk
Layer 3:  YOLO 分类器 →  AI 读全文 transcript，判断是否安全

最有意思的是 YOLO 分类器——一个独立的小模型，读取完整对话记录，把每次工具调用分类为安全或危险。两阶段系统：快速分类器处理明显 case，深度思考分类器处理边界情况。

但对我们最有用的不是 AI 分类器。而是 Claude Code 如何在结构上防止某些工具在错误的上下文中被调用——通过工具白名单、黑名单和子 Agent 特化。

Agent 模式：不是多 Agent 协作，而是专项 Worker

Claude Code 用的不是"Agent 之间协商谈判"的多 Agent 协作。它是一个主协调器 + 专项 Worker：

主 Agent（Tool Calling，全部工具）
  │
  ├─ 简单: "读文件 X" → Read 工具
  │
  └─ 复杂: "审计这个分支" → Agent("Explore")
                              │
                              ├─ 工具: [Read, Grep, Glob]  ← 白名单
                              ├─ 禁止: [Edit, Write]        ← 黑名单
                              ├─ 系统提示: "你是文件搜索专家"
                              └─ 返回结果 → 主 Agent 行动

每个子 Agent 类型由三要素定义：

1. 工具权限（白名单 + 黑名单）——能碰什么
2. 系统提示——角色专属指令
3. 模型——Explore Agent 用 Haiku（便宜），Plan Agent 用 Sonnet（推理强）

核心洞察：主 Agent 不会变更复杂。它保持简单，只有一个 Agent 工具让它把复杂任务委派出去。子 Agent 就是另一个 Tool Calling 循环，只是工具受限 + 提示词不同。

这套架构的可组合性是关键：每个零件简单，但组合起来能处理单个 prompt 消化不了的复杂度。

我们怎么把这个模式用到 terra_llm_bridge

我们的泰拉瑞亚桥接比 Claude Code 简单——46 个工具而非几百个，“安全问题"是"别在玩家问天气时切 hardmode"而不是"别让 AI rm -rf /"。但模式是直接可以搬的。

问题

改之前：LLM 同时看到所有 46 个工具。当玩家问"给我最强套装”，LLM 会并行调 wiki_search 查资料 + give_item 给东西——一边查 wiki 一边已经预判了 Solar Flare 套装。有时候猜对，有时候给召唤师玩家塞了一套战士装备。

解决方案：两阶段工具开放

我们没有加子 Agent——46 个工具不需要。但我们在 graph 层面用了工具限制模式：

route → llm(研究)  ⇄  tool      →  escalate  →  llm(行动)  ⇄  authorize  ⇄  tool  →  output
        17 个只读工具                          46 全工具      关键词 gate
        wiki、lookup、状态                       give、kick、spawn

图有两个阶段：

研究阶段——LLM 只拿到 17 个只读工具（wiki_search、item_lookup、player_list、world_info 等）。它不能调 give_item、kick、spawn 或任何破坏性工具。先查资料。

升级（escalate）——当 LLM 输出文本（没有更多 tool_call），图自动切到行动模式，注入提示：“你现在可以访问全部工具了。”

行动阶段——LLM 拿到全部 46 个工具，可以对研究发现做出行动。

这是结构层面强制执行的，不是 prompt 建议。LLM 在研究阶段根本调不了 give_item，因为这个工具没绑定。

权限 Gate

在两阶段拆分之前，我们还加了 authorize_node——LLM 和 ToolNode 之间的硬拦截，检查玩家聊天最近的消息是否包含该工具领域的关键词：

1
2
3
4
5
6

GATED_TOOLS = {
    "terra_world_hardmode": {"hardmode", "hard mode", "肉山", "困难模式"},
    "terra_player_kick":    {"kick", "踢出", "踢了"},
    "terra_server_stop":    {"stop server", "关服", "停服"},
    # ... 还有 8 个
}

如果玩家说"设个雨天试试"而 LLM 想调 world_hardmode，authorize_node 检查：玩家最近的消息里有 hardmode 相关的关键词吗？没有？拦截。 这个工具调用被替换成 BLOCKED 消息，ToolNode 根本看不到。

这是粗过滤器——它检查的是玩家提到了什么，而不是玩家请求了什么。“上次打肉山的时候"会通过关键词检查，尽管玩家没要求开 hardmode。但粗够了：目标是拦截灾难性的跨界调用（天气 → hardmode），不是完美理解意图。

我们选择不做的

没有 YOLO 分类器

Claude Code 的 AI 分类器读完整 transcript，用另一个模型判断工具调用是否安全。我们没做，因为：

• 增加延迟——每次 gated 工具调用前多一次 LLM 请求
• 泰拉瑞亚聊天风险低——给错套装可以补救
• 关键词匹配已经能拦住灾难性 case

没有子 Agent 派生

Claude Code 为复杂任务 spawn 子进程。我们不需要：

• 泰拉瑞亚工具面小（46 个）
• 多轮工具调用已经能处理我们实际面对的场景
• 给游戏聊天机器人 spawn 子进程是过度工程

没有 ReAct 模式

经典的 Thought → Action → Observation 循环会增加 token 消耗，但不改变我们的核心能力。DeepSeek 的 thinking tokens 已经承担了推理，而两阶段工具访问比基于 prompt 的 ReAct 更可靠地强制了"先研究再行动”。

一张图看清架构

┌──────────────────────────────────────────────────────────┐
│  泰拉瑞亚服务器（TShock + C# 插件，24 个游戏 Hook）        │
│  玩家输入 "@ai 给我最好的套装"                             │
└──────────────────────┬───────────────────────────────────┘
                       │ JSON webhook
┌──────────────────────▼───────────────────────────────────┐
│  Python aiohttp 监听器 (:9876)                            │
└──────────────────────┬───────────────────────────────────┘
                       │
┌──────────────────────▼───────────────────────────────────┐
│  LangGraph StateGraph                                     │
│                                                           │
│  route  →  llm(研究)  ⇄  tool      17 只读工具           │
│               │                                           │
│          escalate  →  llm(行动)  ⇄  authorize  ⇄  tool   │
│                          46 全工具      关键词拦截         │
│               │                                           │
│             output  →  广播到游戏聊天                      │
│                                                           │
│  记忆: AsyncSqliteSaver 按玩家（thread_id）持久化          │
└──────────────────────────────────────────────────────────┘
                       │
         ┌─────────────┴──────────────┐
         ▼                            ▼
   TShock REST API              Terraria Wiki API
   (give / kick / spawn)        (terraria.wiki.gg)

源码分析的启示

读 Claude Code 源码教会我们三件事，适用于任何 Agent 项目：

1. 安全是分层的，不是二元的。 一个 confirm 参数对 LLM 来说只是软建议。真正的安全需要结构性约束——LLM 不该能调用它无权使用的工具，就像 Web 服务器不该让你访问没有权限的端点，不管你怎么礼貌地请求。

2. 工具限制是最便宜也最可靠的安全形式。 Claude Code 的 Explore Agent 之所以"只读"，不是因为 prompt 写了——是因为 Edit 和 Write 不在它的工具列表里。我们的研究阶段之所以"先查资料"，不是 prompt 建议——是因为 give_item 根本没绑定。你不能通过 prompt injection 绕过不存在的工具。

3. 特化胜过复杂化。 Claude Code 的子 Agent 不比主 Agent 更聪明——只是更受约束。更少的工具 + 聚焦的 prompt = 更可靠的行为。我们的两阶段系统同理：先限制，准备就绪再扩展。

关于这个项目

terra_llm_bridge 是一个连接泰拉瑞亚游戏服务器与 LLM 的开源项目。功能包括：

• 24 个游戏 Hook——自研 C# TShock 插件捕获聊天、Boss 击杀、死亡、登录等 24 种事件
• 46 个管理工具——给道具、管玩家、控天气、召 NPC、管区域和权限
• 两阶段 Agent——研究（17 工具）→ 行动（46 工具）
• 硬权限 Gate——基于关键词的 authorize_node 拦截未授权工具调用
• MCP 服务端——同 46 工具暴露给 Claude Code 做服务器管理
• 持久化记忆——通过 LangGraph AsyncSqliteSaver 按玩家保持对话历史

项目目前处于活跃测试阶段，尚未发布到 GitHub。我们在私有泰拉瑞亚服务器上运行，迭代 Agent 架构后再开源。如果对代码感兴趣或想提前体验，欢迎联系。

技术栈：Python 3.14, LangGraph 1.x, DeepSeek（Anthropic 兼容 API）, C# .NET 9, TShock v6.1.0, aiohttp, httpx.