Dify 和 n8n 并不是真正的竞争对手——它们交付的是不同的东西。Dify 是用于构建 LLM 应用本身的平台：聊天应用、智能体或 RAG 支持的助手。n8n 是通用工作流自动化平台，模型调用只是一个节点，与数百个连接器、计划任务和 Webhook 并列。如果交付物是 AI 产品，就从 Dify 开始。如果交付物是偶尔向模型提问的业务流程，就从 n8n 开始。反过来搜索——n8n 对比 Dify——答案也一样，因为选择取决于你要构建什么。
真正容易让人困惑的是费用。Dify 按AI 响应计费，n8n 按工作流执行计费，而你的模型提供商按token计费。这三个单位无法相互换算，因此针对这两者的大多数并列价格表在第一行之前就已经具有误导性。
先说明两个版本事实，因为很多关于这两者的已收录文章已经过时。n8n 处于2.x系列：最新版本是n8n@2.39.9，发布于 2026 年 9 月 21 日。Dify根本没有 2.x 发布系列——当前主版本系列是 1.x，最新版本为 1.17.1，发布于 2026 年 9 月 10 日。两个仓库都在持续维护且未归档（Dify 和 n8n 的最新版本页面，已于 2026 年 9 月 21 日重新检查；n8n 发布频繁，因此补丁版本可能已经再次变化）。
应该选择哪一款
| 您的情况 | 选择 | 为什么 |
|---|---|---|
| 你交付的是聊天应用、智能体或 RAG 支持的助手 | Dify | 提示词工作台、知识库和已发布应用就是产品本身，而不是需要从节点组装出来的东西 |
| AI 步骤位于更长的流程中——CRM、电子邮件、电子表格、Webhook、计划任务 | n8n | 模型节点与连接器位于同一个画布上，因此模型不是核心 |
| 非管理员可以构建应用，但不得接触提供商密钥 | Dify | 只有工作区所有者和管理员可以管理提供商，添加的任何密钥都适用于整个工作区，并计入添加者自己的提供商账户 |
| 你需要独立环境和 Git 版本控制 | n8n，从 Business 层级开始 | “Different environments”和“Version control using Git”首先出现在 n8n 定价页面中 Business 套餐自己的功能列表里；Starter 和 Pro 未列出这些功能 |
| 你想在没有供应商账户的情况下自行运行它 | 两者皆可，但请先阅读许可证 | Dify Community 使用带有禁止多租户条款的修改版 Apache 2.0；n8n Community 属于 fair-code，仅限内部业务或非商业用途 |
| 你已经为其中一个付费，并想整合到另一个上 | 都不是，想要低成本完成 | 两个项目都没有记录可导入对方格式的导入器，因此应按重建而非转移来安排预算，并根据匹配度做选择 |
表格背后有两个结构性差异，值得直接说明。权限：Dify 的提供商配置是仅限管理员、作用于整个工作区的操作——其文档明确表示只有所有者和管理员可以管理提供商，并且你添加的密钥“会计入你自己在该提供商处的账户”，这可能正是你想要的治理方式，也可能正是你不想要的瓶颈。n8n 则围绕项目组织共享，其定价页面按层级对项目数量计量：Starter 提供一个共享项目，Pro 提供三个，Business 提供六个，Enterprise 无限。执行模型：无论内部发生多少次模型调用，n8n 的一次运行都是一次工作流执行；而 Dify 每次模型调用收费一次，因此相同逻辑在两种计量方式下的结果会大不相同。
已发布的套餐和价格
Dify Cloud 按工作区定价。下面的年度价格字符串就是定价页面实际呈现的内容；该页面还带有“Bill Annually Save 17%”切换开关。
| Dify 套餐 | 价格 | 消息额度 | 成员 / 应用 | 知识库 |
|---|---|---|---|---|
| 沙盒 | 免费 | 200（一次性，不是每月） | 1 个成员，5 个应用 | 50 个文档，50MB，30 天日志 |
| Professional | 每个工作区每月 $59，或每个工作区每年 $590 | 每月 5,000 个 | 3 个成员，50 个应用 | 500 个文档，5GB，无限日志 |
| Team | 每个工作区每月 $159，或每个工作区每年 $1,590 | 每月 10,000 个 | 50 个成员，200 个应用 | 1,000 个文档，20GB，无限日志 |
| Community（自托管） | 免费 | 无——你承担自己的模型费用 | 单个工作区 | 你自己的基础设施 |
| 企业版 | 定制，联系销售 | 未公开 | 未公开 | 未公开 |
2026 年 9 月 19 日从dify.ai/pricing和dify.ai/pricing/dify-cloud读取。对比表还显示 Sandbox 具有“5,000 API Rate Limit/month”，而付费层级没有此类限制。Dify Premium（AWS Marketplace 上的机器映像）是单独的 SKU；此处未引用其价格，因为本次检查期间未能通过 Dify 官方页面确认具体数字。
n8n Cloud 按套餐定价，配额统计的是执行次数，而不是模型调用次数。货币提示：n8n.io/pricing在 2026 年 9 月 19 日本次检查中以欧元呈现，未验证其他地区的买家是否会看到另一种货币——请在结账时确认。
| n8n 套餐 | 价格，按年计费 | 执行次数 / 月 | 并发数 | AI（Gateway）额度 |
|---|---|---|---|---|
| 入门版 | €20/月 | 2,500 | 5 | 每月 2,300 次 |
| Pro | €50/月 | 10,000 | 20 | 每月最多 13,700 次 |
| Business | €667/月 | 40,000 | 套餐卡片未说明 | 套餐卡片未说明 |
| 企业版 | 定制，联系销售 | 自定义 | 200+ | 套餐卡片未说明 |
| Community（自托管） | 免费 | 不作为配额出售——上述执行次数额度附属于 Cloud 套餐 | 你自己的硬件 | 自行托管时无法使用 Gateway 额度 |
所有列出的付费层级中，用户和工作流数量均无限制；从 Business 起提供自行托管选项。免费试用宣传为 Pro 级功能，包含 1,000 次执行和 5 次并发执行。
有三种不同的东西都被称为额度
这是聚合页面会跳过的部分，却决定了你的预算。
| 单位 | 一个单位是什么 | 它忽略了什么 |
|---|---|---|
| Dify 消息额度 / AI 额度 | “一次模型调用（一次输入和一次输出），无论使用多少 token，都计为一次响应” | 完全忽略 token 数量——200 token 的回复和 200,000 token 的回复都算一次响应，不过更大的模型会消耗更多额度 |
| n8n 执行 | “完整工作流的一次运行。工作流中有多少步骤或处理多少数据都无关紧要” | 节点数量、数据量，以及运行内部发生多少次模型调用 |
| 提供商 token | 按每百万 token 的费率计算输入和输出 token | 什么都不忽略——这是实际跟踪模型完成了多少工作量的计量方式 |
Dify 对同一单位使用两个名称：定价页面称为“message credits”，而当前文档称为“AI credits”。Dify 自己的文档将每个模型每次响应的额度成本交由定价页面说明，而该按模型划分的表格无法为本页面逐字提取——因此此处不列出按模型计算的额度数字。
n8n 的配额范围比看起来更窄，对你更有利。其执行文档说明“只有生产执行会计入此配额”，并排除编辑器中的手动运行、由Execute Sub-workflow调用的子工作流运行（仅父工作流计数）、错误工作流运行、返回空数据的轮询，以及格式错误或被拒绝的 Webhook 请求。文档也从另一个角度提醒：Schedule Trigger 每次触发都会计为一次执行，无论结果如何；Webhook Trigger 则会为每个激活它的入站请求计为一次，包括空请求体。
诚实的比较不能回避另一点：n8n 现在自己销售模型访问权限。Gateway 额度“自 n8n 2.36.0 起可用”，仅限 n8n Cloud Starter 和 Pro，在“n8n Cloud Enterprise 或自行托管的 n8n 上不可用”，按“服务定价页面列出的费率按请求计费”，而充值额度“在购买后 12 个月过期”。这与网关所完成的是同一项工作，只是作为产品内部功能销售。文档指向 n8n Cloud 应用内的服务定价页面；该页面在 2026 年 9 月 21 日对未登录抓取未提供可读取的费率表，因此此处不公布每美元对应的额度数字，也不与其进行成本比较。可以确认的是适用范围：Gateway 额度不适用于自行托管或 Cloud Enterprise；同一文档还指出，目录之外的服务“仍可按 n8n 的通常方式工作：使用你自己的 API 密钥创建凭据”。Dify 的等效功能较弱，而且它自己也如此说明——密钥和 AI 额度“可以共存”，由 Usage Priority 开关决定先扣除哪一项。
将其中任一产品指向你自己的模型端点
两者都接受第三方 OpenAI 兼容端点，也都接受 Anthropic 兼容端点；在两种情况下，界限都不是“我能否设置 base URL”——该字段存在于每个项目源代码随附的凭据和插件架构中，而且两个定价页面都没有显示对此设置套餐门槛。真正的界限是端点应答的协议，以及默认关闭的能力标志。
| 问题 | n8n | Dify |
|---|---|---|
| 端点放在哪里 | Credentials → OpenAI，其中的 Base URL 字段默认为 https://api.openai.com/v1；或 Credentials → Anthropic，默认为源地址 https://api.anthropic.com，不带 /v1 | 安装官方 OpenAI-API-compatible 插件，然后进入 Model Provider → Add Model，其中需要填写 API Base URL 字段 |
| 模型发现 | 下拉菜单调用 GET {base}/models；当 base URL 不是 api.openai.com 时，会取消仅聊天模型的 id 过滤，因此该端点的 /models 返回什么就会提供什么，无论是聊天模型还是其他模型 | 没有。该插件仅为 customizable-model，因此每个模型都要手动输入，每行一个 |
| 协议 | OpenAI Chat Model 节点上的 Use Responses API 切换开关——请参见下方尚未解决的默认值 | 一个 api_type 开关，默认值为 default: chat_completions，备选项为 responses |
| 工具调用 | 通过连接了聊天模型的 AI Agent 节点工作 | 默认关闭。function_calling_type默认为no_call，因此在聊天模式下工作的网关，在 Agent 节点中会静默失败，直到你进行设置 |
| 无法重新指向的端点 | OpenRouter 凭据将其 URL 固定为 type: 'hidden' | 每个自定义模型都绑定到自己的密钥：删除唯一的密钥也会删除该模型 |
| BYOK 本身的套餐门槛 | 未发现——Base URL 字段在 n8n 源代码的凭据架构中声明，且定价页面没有列出任何层级条件 | 添加提供商未发现任何门槛；在 Cloud 文档中，使用 Load Balancing 将请求分散到多个密钥被标记为 Professional 和 Team 功能 |
源文件，获取于 2026 年 9 月 19 日：OpenAiApi.credentials.ts、AnthropicApi.credentials.ts、OpenRouterApi.credentials.ts以及Dify 的 openai_api_compatible.yaml。值得注意的是：n8n 的官方 OpenAI 凭据页面仍仅记录 API 密钥和组织 ID，从未提及 Base URL 字段；而用于补充该字段说明的社区拉取请求（n8n-docs#5146）已关闭且未合并。此路径最重要的字段没有文档说明，因此这里引用源文件。
一个确实尚未解决的默认值
n8n 的两个官方来源对于新添加的 OpenAI Chat Model 节点调用哪个端点存在分歧。master 分支中的节点源代码声明 responsesApiEnabled，并设置 default: true；该设置显示在节点版本 1.3 及更高版本中，而 1.3 是该节点版本列表中的最新条目——这看起来意味着 Responses API 已开启。节点文档则给出相反说法：“否则，OpenAI Chat Model 节点将默认使用 Chat Completions API。”两者均于 2026 年 9 月 19 日获取，而且对于今天添加的节点不可能同时为真。本页面不判断哪一个正确。打开节点，查看该切换开关，并注意该设置决定请求访问 /responses 还是 /chat/completions——如果端点只提供两者之一，这就是每次调用正常工作与返回 404 的区别。Kunavo 实现了两条路径，因此在这里开关处于哪一种状态都能正常使用，但请检查设置，不要想当然。
自定义端点在 n8n 中无法跨越两个边界。内置 Responses 工具——Web Search、File Search 和 Code Interpreter——是 OpenAI 托管的功能；文档还补充说明，它们“仅在 OpenAI Chat Model 节点与 AI Agent 节点结合使用时受支持”。此外，在节点级别设置的 base URL（而不是在凭据上设置）会在使用前根据凭据的域名限制进行检查——节点源代码会对其调用 assertOpenAiCredentialAllowsUrl，当 URL 超出这些域名时就会抛出错误。
在 Dify 一侧，默认值就是关键所在。除 function_calling_type: no_call 外，手动添加的模型初始值为 structured_output_support: not_supported 和 vision_support: no_support，每一项都需要手动切换，以匹配端点的实际行为。stream_include_usage 默认启用是有原因的：如果端点没有在最终流式响应块中返回 usage，Dify 会回退到本地估算，而该估算只计算第一条提示消息，因而会低估多消息提示。相同文件还提供了面向网关的明确逃生选项——可以省略顶层 user 字段，因为“某些 OpenAI 兼容网关会拒绝它”；还提供 token_param_name 开关，以及严格与扩展兼容模式——这充分说明网关路径是受维护的使用场景，而不是权宜之计。
对于 Anthropic 风格的访问，Dify 的官方 Anthropic 插件为 predefined-model 和 customizable-model，并带有可选的 anthropic_api_url 字段，因此你可以将其内置的 Claude 列表指向另一个端点。如果这样做，请注意 ID：Dify 的内置文件夹将 claude-opus-5、claude-sonnet-5、claude-opus-4-8、claude-opus-4-7、claude-opus-4-6 和 claude-sonnet-4-6 等不带日期的 ID 与 claude-sonnet-4-5-20250929 等带日期的 ID 混在一起。第一组中的不带日期 ID 是 Kunavo 目录 slug；带日期的形式不是，而且 Dify 文件夹中的并非每个 ID 都对应当前在售的产品。使用你的密钥调用 GET /v1/models，并从返回结果中选择——该列表已经排除了不提供服务的项目。Kunavo 的 base URL 完全遵循这两种约定：OpenAI 风格字段使用 https://api.kunavo.com/v1，Anthropic 风格字段使用不带路径的源地址 https://api.kunavo.com（请参阅base URL 文档，了解为什么在此处添加 /v1 会产生 404）。
n8n 的 Anthropic 凭据有一个特有细节，这是通过阅读两个项目的代码而不是测试得出的：该凭据使用 x-api-key 进行身份验证，并使用 GET {base}/v1/models 进行自检；Kunavo 的 /v1/models 与 /v1/messages 一样，会在该请求头中接收密钥，因此凭据测试和模型下拉菜单都应能正常响应。下拉菜单使用模型的 display_name 标记每个模型，并在缺失时回退到 ID；Kunavo 的列表没有 display_name，因此显示 ID——而且列出的是目录中的所有模型，不只是 Messages 端点提供的 claude- ID，所以请选择其中一个。上述内容均未在本页面进行运行时测试。纯 OpenAI 兼容路径才是快速入门文档所记录的路径。
Dify 中网关密钥无法覆盖的内容
Dify 工作区有五个默认模型槽位——其模型提供商文档列出了这些槽位——它们是检验任何模型提供商实际覆盖范围的标准。Kunavo 密钥会填入其中一个槽位；其余四个槽位无法解析到 Kunavo 运行的任何内容。
| Dify 默认槽位 | 它的作用 | Kunavo 当前情况 |
|---|---|---|
| 系统推理模型 | 通用 LLM 任务的默认模型 | 已覆盖——聊天目录就是用于此目的的 |
| 嵌入模型 | 为知识库内容建立索引并进行检索 | 未提供服务。目录中没有嵌入模型，因此此步骤会在本地运行或通过外部提供商运行 |
| 重排模型 | 根据相关性重新排列检索结果 | 未提供服务。 Dify 的重排类型会向 {base}/rerank 发送请求，而 Kunavo 没有此路由 |
| 语音转文本模型 | 将音频转换为文本 | 未提供服务。目录中没有列出语音转文本模型 |
| 文本转语音模型 | 将文本转换为音频 | 未提供服务。当前目录中未启用文本转语音模型，因此此槽位也会指向其他位置 |
在规划迁移之前，请明确这一点：Dify 知识库或 RAG 流程仍然需要从其他来源获取嵌入模型，通常还需要重排模型。网关密钥覆盖的是推理槽位，而不是整个工作区。RAG 实现指南介绍了通常如何安排这种拆分。
一个具体的成本估算
这是用于说明的令牌算术，不是经过测量的任务成本，也不是账单上限。假设一个分流工作流在生产环境中每月运行 2,000 次，并且每次运行进行两次模型调用——一次用于分类，一次用于起草——每次发送4,000 个输入令牌并返回400 个输出令牌。这相当于 4,000 次模型调用、1,600 万个输入令牌和 160 万个输出令牌。费率采用实时的Kunavo 目录每百万令牌价格。
| 模型 | 每 1M 个令牌的输入 / 输出 | 本月预计令牌成本 |
|---|---|---|
| Claude Haiku 4.5 | $0.70 / $3.50 | $16.80 |
| GPT-5.6 Terra | $0.70 / $4.20 | $17.92 |
| Claude Sonnet 4.6 | $2.10 / $10.50 | $50.40 |
| Claude Opus 5 | $3.50 / $17.50 | $84.00 |
现在把平台的计量方式放在旁边比较。同一工作负载在 n8n 中是2,000 次生产执行——低于 Starter 的 2,500 次——因为两次模型调用都包含在一次运行中。在 Dify 中则是4,000 次 AI 响应，因为 Dify 会计算每次模型调用，因此会立即超过 Sandbox 的 200 次一次性额度，并处于 Professional 的每月 5,000 次额度之内。仅模型选择一项，就会让相同 4,000 次调用的令牌成本从 $16.80 变为 $84.00，这通常比套餐等级更具影响力。目录中列出的最低费率和完成任务的最低成本仍然是两个不同的问题：需要重试的较便宜模型，成本可能高于无需重试的较昂贵模型。
Kunavo 的目录金额是计费下限，而不是上限：上游报告费用后，账单金额取目录成本与上游成本乘以适用加价两者中的较高值。缓存费用和外部工具费用不包含在此示例中。最低充值金额为预付余额中的$10——这是资金最低限额，而不是任务费用或订阅费用。请参阅计费详情以及AI 成本优化，了解如何衡量自己的工作负载，而不是盲目相信此类估算。
同时运行两者，以及改变选择的成本
现实中对“Dify 还是 n8n”最常见的答案是两者结合，但分属不同层次：Dify 构建并托管 AI 应用，n8n 触发应用并将结果接入业务的其余部分。这两个产品都不禁止这种组合，而且能让每个工具承担其设计用于完成的工作。代价是两套计量方式和两组凭据，因此在把它视为低成本选项之前，请先检查两者。
它不是迁移路径。两个项目都没有记录用于导入对方格式的工具，因此应计划重建逻辑，而不是移动逻辑。这也是应根据适配性而非价格进行选择的最有力理由：套餐账单下个月还可以改变，而重建无法撤销。如果你选择的是模型路由而不是平台，OpenAI 兼容 API 指南介绍了这两个工具所需的端点，LLM 网关指南介绍了网关能为你做什么以及不能做什么。
两个客户端都没有经过针对 Kunavo 的运行时测试。以上内容均来自当前源代码和当前官方文档，Kunavo 也没有为任一工具发布设置指南——配置采用标准的 OpenAI 兼容方式。在尝试时保留一条可用路由，先运行一个范围受限的任务，然后查看账户实际记录的费用。准备为密钥充值时，创建 Kunavo 账户；或者浏览集成索引，查看已有文档化设置流程的客户端。
常见问题
Dify 比 n8n 更好吗？
不能笼统地说哪个更好，因为它们交付的是不同的东西。Dify 是一个 LLM 应用平台：其代码仓库将自身描述为一个用于构建智能体工作流和 RAG 流水线的空间，在同一个协作工作区中提供模型和工具支持，交付物是 AI 应用。n8n 是通用工作流自动化平台，模型调用只是节点类型之一，与连接器、Webhook、计划任务和数据库并列，交付物是流程。AI 产品本身是重点时，选择 Dify。AI 步骤位于更长的业务流程中时，选择 n8n。反过来问 n8n 对比 Dify，答案也一样——选择取决于你要交付什么，而不是哪个工具更强。
Dify 和 n8n 可以协同工作吗？
可以，而且这是一种常见的组合，而不是权宜之计。Dify 文档说明，你发布的每个应用都会同时成为一个 REST API，你可以使用 API 密钥从自己的后端调用它；n8n 提供 HTTP Request 节点。因此，Dify 应用可以作为 n8n 工作流中的推理步骤，而 n8n 负责触发器、连接器和重试。如果这样做，请同时考虑两种计量方式：Dify 会为其应用发出的每次模型调用计为一次 AI 响应，n8n 则会将调用它的整个工作流运行计为一次生产执行。两个项目都没有记录可导入对方格式的导入器，因此 Dify 应用和 n8n 工作流仍是两个工件，而不是在工具之间迁移后合并为一个。
Dify 和 n8n 哪个更便宜？
不能仅从套餐价格回答这个问题，因为两种套餐的计量对象不同，而且两者计量的都不是通常成本最高的部分。Dify Cloud 按工作区定价，并统计消息额度，其中一次 AI 响应就是一次模型调用，无论使用多少 token。n8n Cloud 按套餐定价，并统计生产执行次数，其中一次执行就是一次完整的工作流运行，无论其中包含多少步骤或模型调用。除非你始终使用包含的额度，否则模型 token 费用还会在两者之外另行产生。自行托管任一产品都会移除订阅费用，但仍需承担基础设施费用和模型费用，同时受各项目许可证限制。
Dify 和 n8n 哪个更适合 RAG？
按设计来说是 Dify。它将知识库作为一等对象提供，并按套餐设置文档和存储限制；其工作区还为 embedding 和 rerank 提供专用的默认模型槽位，与推理模型并列。n8n 可以通过向量存储和 embedding 节点搭建检索流水线，但需要你自行组装和维护。无论选择哪种方式，都要注意模型侧的影响：检索需要 embedding 模型，通常还需要 rerank 模型，而 Kunavo 目前两者都不提供。因此，无论选择哪个平台，Dify 或 n8n RAG 技术栈中的这部分都要在本地运行或通过外部提供商完成。
我可以在 Dify 和 n8n 中使用自己的 API 密钥吗？
两者都提供该字段，且两个定价页面都没有显示对此设置套餐门槛。在 n8n 中，OpenAI 凭据包含可编辑的 Base URL，默认为 https://api.openai.com/v1；Anthropic 凭据也包含该字段，默认为源地址 https://api.anthropic.com，不带 /v1；OpenRouter 凭据将其 URL 固定为隐藏字段，无法重新指向。在 Dify 中，你可以安装官方 OpenAI-API-compatible 插件并手动添加每个模型，或者将官方 Anthropic 插件指向自定义 API URL。Dify 还允许密钥与其自身的 AI 额度共存，由提供商卡片上的 Usage Priority 开关决定优先扣除哪一项。
Dify 是开源的吗？n8n 是开源的吗？
两者的答案都需要限定条件，而且 GitHub 的仓库 API 对两个许可证都报告 NOASSERTION。引用 github.com/langgenius/dify 和 github.com/n8n-io/n8n 中的两个 LICENSE 文件：Dify 使用修改版 Apache License 2.0：允许商业使用，但从源代码运行多租户环境需要书面授权，其中一个租户意味着一个工作区；并且不得移除或修改前端中的徽标和版权信息。n8n 属于 fair-code，而不是 OSI 意义上的开源：Sustainable Use License v1.0 仅允许将其用于你自己的内部业务目的，或用于非商业用途或个人用途；文件名中包含 .ee. 或目录名中包含 .ee 的文件需要付费的 n8n Enterprise License，且除 master 以外的分支明确未获许可。
已于 2026 年 9 月 19 日检查并于 2026 年 9 月 21 日复查：通过 GitHub API 检查了两个 GitHub 仓库及其最新版本；两个许可证文件；dify.ai/pricing、dify.ai/pricing/dify-cloud 和 n8n.io/pricing；Dify 模型提供商文档；n8n 执行、Gateway credits 和 OpenAI Chat Model 文档；以及 n8n 的 OpenAI 和 Anthropic 凭据、其 OpenAI Chat Model 节点、Dify 的 OpenAI 兼容和 Anthropic 插件清单的原始源代码。两个产品均未安装，也未指向 Kunavo，因此本文内容没有任何测试结果。Kunavo 令牌费率来自实时目录，所有美元数字均为说明性算术。