为什么要两个工具一起用
一句话:Dify 负责把 AI 能力做成稳定可调用的服务,n8n 负责把这些服务接进真实业务流程。
Dify 是一个 AI 应用搭建平台——在它里面编排 LLM 调用、RAG 检索、知识库问答、提示词模板,做成一个可以通过 API 调用的 AI 服务。n8n 是一个业务流程自动化引擎——它把 CRM、邮件、IM、数据库、表单、审批流串起来,支持在中间插入 AI 节点。
只用 Dify?AI 能力做好了但没法自动接进业务系统。只用 n8n 的内置 AI 节点?灵活性和知识库能力不如 Dify。两者结合:Dify 出能力,n8n 出流程。
Dify 侧的实操
搭建一个知识库问答服务(以内部 FAQ 为例)
- 在 Dify 后台点"创建应用",选 Chatbot 类型(如果要更灵活的控制选 Workflow)
- 进入"知识库"模块,点"创建知识库",上传文档——PDF、Markdown、TXT 都行,也可以直接同步 Notion 页面
- 关键步骤——分段设置:默认的自动分段在中文长文档上经常切割不准。建议进 Settings,把 Chunk Size 调到 500-800 token,Overlap 设 50-100。如果你的文档结构清晰(有明确标题),选按段落分段会更好
- 上传后点"Go to Document"检查分段结果,有明显断裂的手动调整
- 回到 Chatbot 或 Workflow 编辑器,拖一个 Knowledge Retrieval 节点连上 LLM 节点
- 配置提示词模板,核心是告诉 LLM:"基于以下检索到的内容回答用户问题,如果内容中没有相关信息,直接说不知道"
- 发布后在"访问 API"页面拿到 endpoint 和 API key
踩过的坑
- 分段是最影响效果的环节。知识库问答效果差,80% 的原因是分段不好。建议先用几个真实问题测试召回的是哪些分段,再决定要不要调整。
- RAG 召回率和文档质量强相关。原始文档写得含糊,AI 也找不到有用信息。上传前先人工过一遍文档质量。
- Workflow 编辑器偶尔有保存问题。复杂流程建议每加 2-3 个节点就手动保存一次,别等全做完再保存。
- 模型选择影响成本和延迟。知识库问答场景用 GPT-4o-mini 或 Claude 3.5 Haiku 性价比更高,不需要上最贵的模型。
n8n 侧的实操
把 Dify 的 AI 能力接入业务流程
- 在 n8n 创建新 Workflow
- 设置触发器:取决于你的业务入口——Webhook(网站表单提交触发)、Schedule Trigger(定时触发)、Email Trigger(收到邮件触发)、或者各种 IM 的消息触发
- 加一个 HTTP Request 节点:Method 设 POST,URL 填 Dify 的 API endpoint,Headers 里加
Authorization: Bearer <你的 API key>,Body 里传用户的问题。Content-Type 记得设 application/json - 处理返回结果:Dify 返回的 JSON 里取出 AI 的回答
- 加下游节点:发飞书消息、回复邮件、写入 Google Sheets、更新 CRM 记录——看你的业务需要
一个完整的例子:客服辅助回复
网站表单提交 → Webhook 接收
→ HTTP Request 调 Dify 知识库问答
→ IF 节点判断:AI 回复的置信度 > 0.8?
→ 是:自动发送回复邮件给客户
→ 否:发飞书消息通知人工客服处理
→ 无论哪条路径,都写一条记录到 Google Sheets 做追踪
关键配置
- Error Trigger 必须配:在 Workflow Settings 里开启 Error Workflow,指向一个错误处理流程(至少发一条告警消息)。否则节点失败会被静默吞掉,上线后你都不知道出了问题。
- IF 判断不能省:涉及客户交互的流程,AI 输出必须过一道校验。哪怕只是判断回复长度是否合理、有没有包含敏感词。
- human-in-the-loop:n8n 支持在流程中间加 Wait 节点,暂停执行等待人工确认。审批、对外发送通知、涉及金额操作的场景建议加上。
- 重试机制:HTTP Request 节点设置 Retry on Fail,设 2-3 次重试,间隔 5-10 秒。Dify 的 API 偶尔有超时,加重试能明显减少失败率。
落地顺序
第一阶段:内部试点(1-2 周)
从风险最低的场景开始:
- 内部知识库问答(员工问 HR 政策、产品文档查询)
- 简单的内容分类和标签
- 日报/周报的自动汇总和分发
这些场景的特点:结果容易验证、出错影响可控、业务方容易感知到价值。先在这个范围里跑通 Dify + n8n 的完整链路。
第二阶段:接外部触点(2-4 周)
内部跑稳后再接客户相关的流程:
- 客服辅助回复(必须保留人工确认)
- 线索分类和分发
- 评论/反馈的自动整理
这阶段人工确认节点不能省。出一次错给客户发了离谱回复,比节省的人力成本贵得多。
第三阶段:多系统协同
多个 Dify 应用 + 多条 n8n 流程串联,数据在系统之间流转。这阶段对监控、日志和错误处理的要求会高很多,建议同步搭建 n8n 的执行日志看板。
最容易犯的错
错 1:一开始就追求全自动
很多团队第一天就想把客服、审批、知识库、通知、报表全串起来。结果每个节点都不稳,联合起来更不稳。先做一个场景做到 90 分再扩展。
错 2:AI 输出不做质量校验
AI 回复不是 100% 可靠的。n8n 流程里必须加校验——至少要有关键词过滤、长度检查和异常兜底。把 AI 输出不经校验就发给客户是在挖坑。
错 3:Dify 和 n8n 职责分不清
如果你在 Dify 里也搭业务逻辑,在 n8n 里也做 AI 编排,最后会很混乱。干净的分工:Dify 只管 AI 能力(模型、知识库、提示词),n8n 只管流程(触发、判断、分发、集成)。两者通过 API 通信,各管各的。
错 4:不看执行日志
n8n 每次执行都有详细日志,包括每个节点的输入输出。上线后至少每天看一遍执行记录,早期很多问题在日志里就能发现,不用等到用户投诉。