n8n + Dify 企业 AI 自动化实战

为什么把 Dify 和 n8n 放在一起看

Dify 和 n8n 处理的不是同一件事。Dify 更靠近 AI 服务本身，知识库、提示词、模型调用和问答逻辑都在这一层；n8n 更靠近业务入口，表单、邮件、消息、审批和数据库更新通常都在这里。如果把这两个工具放在同一层理解，后面很容易一边调问答效果，一边又在流程里补判断，最后越来越乱。

Dify 更适合先把问答服务做出来，n8n 再负责把这个服务接进真实业务入口。这样分开之后，哪里出了问题也更容易查。回答不对，就回 Dify 看知识库和提示词；流程没走通，再去看 n8n 的触发器和返回结果。

先在 Dify 里把问答服务搭出来

如果是内部 FAQ 这类场景，可以先在 Dify 创建 Chatbot 或 Workflow，然后把 PDF、Markdown、TXT 或 Notion 页面放进知识库。上传之后不要急着发布，先检查分段结果。中文长文档在默认设置下经常切得太碎，或者把同一段内容切散，后面检索出来的内容就会对不上问题。

比较常见的做法，是先把 Chunk Size 调到 500 到 800 token，Overlap 设在 50 到 100 左右，再根据文档结构决定要不要按段落分段。做完以后，用几个真实问题试一下，看召回出来的是不是你原本想让它引用的那几段。如果召回不对，先改分段，不要急着怪模型。

提示词也不用写得太花。知识库问答最重要的是让模型只围绕检索内容回答，没有内容就直接承认没找到。这个阶段里，很多问题其实和模型本身关系不大，更多出在资料切分、资料质量和提示词边界不够清楚。

再用 n8n 接到业务入口

等 Dify 的问答质量基本稳定以后，再去 n8n 建 Workflow 会省很多时间。业务入口可以是 Webhook、定时任务、邮件触发，也可以是来自 IM 工具或表单系统的消息。接法本身并不复杂，核心动作就是用 HTTP Request 调 Dify 的 API，再把返回结果分给后面的处理步骤。

如果是客服辅助回复，一个很常见的流程就是：网站表单提交以后，先把问题发给 Dify；如果回答可信度足够高，就自动生成回复；如果回答不够完整，或者命中了敏感条件，就直接转人工。这里真正不能省的，不是“能不能自动发出去”，而是中间的判断和记录。至少要有一层规则去拦明显不该自动发出的回答，也要把问题、回答结果和是否转人工记下来，后面才知道哪里需要继续调。

这类流程里最常出问题的地方

第一类问题出在资料本身。原始文档写得含糊，或者已经过时，模型后面再怎么调也不会给出稳定回答。第二类问题出在分段，切得太碎会丢上下文，切得太长又容易把不相干的内容混进去。第三类问题出在流程判断，尤其是涉及客户回复时，如果没有最基本的校验和人工确认，自动化做得越多，后面返工越大。

还有一个常被忽略的地方是日志。n8n 每次执行都会留下输入输出，如果上线后不看这些记录，很多错误不会主动暴露出来。等到客户真的收到离谱回复，再去回查，代价通常比前面多花十分钟看日志高得多。

一个更实际的落地顺序

如果团队是第一次做这类自动化，不必一开始就把客服、审批、知识库和通知全接起来。更现实的顺序，是先拿风险最低的一类内部问答试运行，确认资料、检索和回答都没有明显问题，再慢慢接外部入口。等外部问题也能稳定处理以后，再考虑更复杂的多系统协作。

这样做不算慢，反而是在减少重复调整。因为很多团队最后卡住，不是不会搭工具，而是把太多步骤挤在第一轮里，结果每改一处都牵动整套流程。把 Dify 的问答服务先做扎实，再让 n8n 接进业务入口，后面会清楚很多。