n8n 管集成、Dify 管推理：两个一起用的组合打法
数据截至 2026-07，价格与限额以各官网为准。
n8n 和 Dify 不是竞品关系，硬要二选一往往两头别扭：n8n 是工作流自动化平台，强在触发器、连接器和数据搬运，AI 只是它节点里的一种；Dify 是围绕大模型构建应用的平台，主场是聊天机器人和 RAG。第三方评测里反复出现的一句结论是——生产环境最好用的组合是两者并用，n8n 管集成与路由，Dify 管 AI 推理。把这条线画清楚，很多”到底该用哪个”的纠结会直接消失。
一个很常见的误解是：既然 n8n 里也有 LLM 节点、也能连向量库，那再引入 Dify 就是多此一举，徒增一个要维护的系统。这个判断在小规模场景下确实成立——如果你的 AI 部分只是”把这段文字总结成三句话”，塞在 n8n 里就够了。但一旦提示词需要反复调、知识库需要持续喂文档、同一套问答逻辑要被三四个入口复用，把这些东西散落在若干个 n8n 节点里维护，很快就会变成谁也不敢动的一团线。分层的价值不在于技术上做不到，而在于改起来的成本。
为什么是 n8n 在外、Dify 在内
这个方向不能反过来，原因在两边的能力结构上。
n8n 自带 400 多个集成，Slack、HubSpot、PostgreSQL、Google Sheets、通用 HTTP 请求都是现成节点，还有原生的 JavaScript 和 Python 代码节点兜底。也就是说，“事件从哪来、数据往哪去”这一层，n8n 已经把绝大部分脏活预置好了。同样一件事如果要在 Dify 侧做，你多半得自己写胶水代码。
Dify 的强项在另一侧：模型接入和定制、提示词的版本化管理、RAG 的整套检索链路，都是它的主场，而且低代码的形态让非工程角色也能参与调优。把”这句提示词改一下”这种高频动作留在 Dify 里，产品或运营同事自己就能改完发布，不用每次都找人去动工作流。
所以分工是：外层由事件驱动、由 n8n 编排；内层的”这段话该怎么问模型、该查哪个知识库”封装在 Dify 里，对外只暴露一个稳定接口。
最小接线：一个 HTTP 请求节点就够了
具体怎么连，其实简单到有点反高潮——n8n 侧不需要什么专用插件，用通用的 HTTP 请求节点调用 Dify 应用暴露的接口就行。
流程大致是这样：在 Dify 里建好应用、调好提示词和知识库，它会给这个应用生成对应的调用端点和一把 App Key；具体路径、参数名和返回结构以你控制台里那个应用页面当时显示的说明为准，这篇不替官方写死接口细节。回到 n8n，加一个 HTTP 请求节点，把端点填进去，鉴权信息放在 n8n 的 Credentials 里而不是硬编码在节点参数里，请求体带上用户输入和会话标识，返回的结果再接后续节点做落库或推送。
有几个实操建议：
- 给这个节点单独设超时和重试。模型调用比普通接口慢得多，n8n 默认的超时值不一定够，超时后无脑重试又可能造成重复扣费，重试次数建议保守。
- 把 Dify 的返回原样存一份。不要在 n8n 里只取自己需要的那个字段就丢掉其余内容，出问题时原始返回是唯一能复盘的东西。
- 会话标识由 n8n 生成并传入。多轮对话场景下，谁来维护会话 ID 必须一开始就定死，否则上下文串号的排查会非常痛苦。
职责线画在”确定性”和”不确定性”之间
如果只能记一条切分原则，就记这个：确定性的活归 n8n，不确定性的活归 Dify。
归 n8n 的：定时或事件触发、从数据库和第三方系统取数、字段清洗与格式转换、条件分支、失败重试、结果写回、通知推送、权限和审计相关的记录。这些逻辑的正确性可以用”输入 A 必然得到输出 B”来验证。
归 Dify 的：提示词、知识库切片与检索策略、模型选型与参数、输出格式的约束、多轮对话的上下文管理。这些东西没有唯一正确答案，只有”这版比上版好一点”，需要频繁试错。
线画清楚之后有个副产品：两边的迭代节奏可以解耦。Dify 里换个模型、调个提示词，只要接口契约不变，n8n 那边一行都不用改，也不用重新发布工作流。反过来 n8n 增加一个数据来源，Dify 侧同样无感。
三个可以直接抄的组合场景
内部知识问答机器人。 n8n 接企业 IM 的消息事件，做完身份识别和权限校验，把问题发给 Dify 里那个挂了知识库的应用，拿到回答后再由 n8n 决定回到哪个群哪个话题，同时把问答记录写进数据库做后续分析。知识库的维护完全在 Dify 侧完成，跟工作流没有耦合。如果你想先理解检索链路本身，可以看用 n8n 搭一个企业 RAG 知识库问答，再决定这层要不要挪进 Dify。
批量内容处理流水线。 n8n 定时从数据源拉一批待处理记录，循环调用 Dify 应用做分类、抽取或改写，结果分支写回不同的表。这里 n8n 的价值集中在”批量、断点续跑、失败隔离”上——某条记录失败不该拖垮整批，这类控制逻辑放在工作流层比塞进提示词里可靠得多。
表单与工单的自动分派。 表单提交事件触发 n8n，Dify 负责判断意图和紧急程度并给出结构化结果，n8n 拿到结果后按规则路由到对应负责人，并在超时未处理时自动升级。注意分派规则本身属于确定性逻辑，应该留在 n8n，不要让模型直接决定”派给谁”——规则变了改配置就行，不用重新调提示词。
自托管与成本：两套系统怎么摆
按第三方评测汇总的口径，Dify 和 n8n 都是开源的，自托管可以免费使用，但服务器成本和大模型 API 调用费另计；云版本则都需要付费。这两家也都被评价为很适合自托管，相比之下 Coze 的自托管复杂度要高不少。
分开看：Dify 的自托管社区版本身免费，因为它接的是你自己的模型 API Key，成本纯按用量走；云版据第三方评测的说法从每月 59 美元起、另有免费档，并按消息额度、应用数、存储分档限制。n8n 自托管没有授权费，另有面向企业的授权自托管版本，提供单点登录、版本控制、高级权限这类能力；云版低档位的执行次数上限比较紧，高频自动化容易变贵，也有第三方测算称在每月十万次以上操作的量级下自托管每年能省下三千到五千美元。
这些数字全部来自第三方评测口径，不是官方定价页，以各官网当前定价页为准，别拿它去做预算表。
真正值得注意的是组合之后的成本结构变化：n8n 的计费看执行次数，Dify 的计费看消息额度或你自己的模型用量，两条计费线是独立的。 组合方案里一次业务流程往往对应 n8n 的一次执行加 Dify 的一次调用，做容量估算时两边都要算。如果打算自托管，可以先看Dify 自托管成本怎么算把服务器这块摸清楚。
什么情况下不该组合
诚实说，组合方案不是默认答案，下面几种情况下它是负担：
- AI 只是流程里可有可无的一步，比如就一句总结。直接用 n8n 自带的 LLM 节点，别为了架构好看多养一个系统。
- 纯对话产品、几乎没有外部系统集成。这种场景 Dify 单独跑就够了，n8n 加进来只是多一跳延迟。
- 团队没人能长期维护两套自托管服务。多一个系统就多一份升级、备份、监控和故障排查的责任，人手不够时这笔账很快会变负。
- 延迟极度敏感的链路。多一跳网络调用就多一段耗时，实时性要求高的场景要先测再定。
选型的整体判断可以参考Dify、n8n、Coze 怎么选那篇，这里只补一句：三家定位不同，不存在谁更强，只有”你的流程从哪里开始”这一个真问题。
常见坑
- 鉴权信息硬编码在 HTTP 节点里。一定要走 n8n 的凭据管理，否则导出工作流 JSON 时会连密钥一起带出去。
- 只测通路不测失败路径。模型超时、返回内容不符合预期格式、额度耗尽，这三种情况都要在工作流里显式处理，不能默认调用必然成功。
- 让模型输出自由文本再用正则去解析。要结构化结果就在 Dify 侧把输出格式约束好，n8n 侧解析失败要有兜底分支。
- 两边各存一份提示词。调试时在 n8n 节点里临时改了一版提示词又忘了同步回 Dify，是最容易产生”线上线下不一致”的来源。提示词只应该有一个家。
- 忽略版本管理。工作流和 AI 应用都会持续变更，上线前留个可回滚的版本，比出事后靠记忆复原可靠。
小结
n8n 和 Dify 的组合不是技术炫技，而是把”改起来成本很低的东西”和”需要频繁试错的东西”分开放。n8n 负责事件、集成、路由和可靠性，靠的是它 400 多个现成连接器和代码节点兜底的能力；Dify 负责提示词、知识库和模型调用，靠的是它在 LLM 应用这一层的低代码形态。接线本身很简单，一个 HTTP 请求节点加一把 Key 就能跑通，难的是把职责线画对、把失败路径想全。成本上两条计费线要分开算，涉及具体价格一律以各官网当前定价页为准。最后别忘了：如果你的 AI 只是流程里的一小步，单用 n8n 就是更好的答案。