Dify 怎么用？六步搭个能上线的知识库问答-知了AI

一、Dify 是什么：把写代码调模型，换成画图连节点

一句话说清：Dify（dify.ai）是开源的大语言模型应用开发平台。可以把它理解成一个工作台，左边选模型，中间拖节点，右边看结果，做完之后能直接变成一个网页、一段嵌入代码，或者一个供后端调用的接口。云端注册就能用，也能用 Docker Compose 装进自己的服务器。

它和 LangChain 的关系最容易被搞混。LangChain 是一套 Python 和 JavaScript 库，能力强，但界面、日志、权限、知识库全得自己写。Dify 把这些周边做成了产品：编排画布、知识库、提示词调试、调用日志、成员权限，开箱就在那里。用掉的是写代码的自由度，换来的是不写代码的速度。

和 Coze 比，差别在”能不能搬走”。Coze 是托管服务，开箱好用，应用长在别人的云上；Dify 社区版开源，一条命令就能装进自己的机房，数据不出内网。这一条，决定了它在国内企业里的位置。

1.1 Dify 的四种应用类型，选错就白忙

在 Dify 里新建应用，只有四个选项：聊天助手（Chatbot）、文本生成、Agent、工作流（Workflow 与 Chatflow）。聊天助手是最短路径，挂上知识库就能答问；文本生成是一次性输入输出，适合批量改写、摘要、翻译；Agent 让模型自己决定调哪个工具，适合开放式任务；工作流把每一步摊开，适合流程固定、要求可复现的场景。

1.2 四种类型怎么选

给一条实用判断：答案需要多轮追问的用聊天助手，一次生成一段文字的用文本生成，步骤之间有判断分支的用工作流，需要模型自主搜索和试错的用 Agent。内部知识库问答这种必须给依据的场景，优先 Chatflow，它既保留多轮，又能把检索节点画出来给你看。

应用类型	输入	输出	适合的场景	上手难度
聊天助手 Chatbot	多轮对话	对话答案	客服、FAQ、内部问答	低
文本生成	单次表单或变量	一段文本	批量改写、摘要、翻译	低
Agent	任务描述	自主多步结果	调研、开放式任务	中
工作流 Workflow	结构化参数	结构化结果	报表、审核、数据加工	中高
Chatflow	多轮对话 + 分支	对话答案 + 引用	带依据的知识库问答	中高

四种类型不是互斥的。常见组合是：工作流负责批量清洗文档、生成摘要，结果回写进知识库；聊天助手站在前台接用户；Agent 只留给”帮我查一下上周的工单”这种开放式请求。Dify 允许一个工作空间里放多个应用，把它们串起来，比硬塞进一个大工作流更好维护。

1.3 Dify 不做什么，先划清边界

Dify 不做模型训练，也不做微调，它只调用别人的模型；它不是文档管理系统，知识库是给检索用的，不是给人归档用的；它也不是万能的胶水层，复杂的事务一致性、高并发写入，仍然要回到自己的后端处理。

二、上手前要准备的三件事

2.1 入口：云端试用还是自己装

云端入口是 cloud.dify.ai，注册即可用，免费额度够跑通一个演示。自托管走 Dify 的 GitHub 仓库，进 docker 目录，把 .env.example 复制成 .env，改掉密钥和端口，再执行 docker compose up -d，默认 80 端口起一整套服务。第一次拉镜像要十几分钟，别以为卡死了。

2.2 先回答一个问题：文档能不能出门

这是选择 Dify 部署方式的唯一标准，不是预算。客户合同、病历、工资表这类东西，只要落到第三方服务器上，合规就过不去；反过来，公开的产品手册、帮助文档，放云端更省事。先想清这一点，后面所有选择都会简单。

2.3 模型：对话、向量、重排要分开准备

很多人只准备了一个对话模型的 Key，结果知识库建不起来。Dify 里至少要三类模型：对话模型负责生成答案，Embedding 模型负责把分段变成向量，Rerank 模型负责重排检索结果。前两个必须有，第三个决定混合检索的上限。国内模型、OpenAI 兼容接口、Ollama 本地模型都能接。

费用结构也要提前想清：云端有免费额度，专业版和团队版按官网标价；自托管软件免费，账单转移到机器和运维上。两条路的钱，花的地方完全不一样。

还有一件常被忽略的准备工作：把边界写下来。同一个工作空间里堆十几个应用，名字全是”测试一””测试二”，三个月后没人说得清哪个还在用。Dify 支持给应用改名字、写说明、加标签，这些字段不是装饰，是给半年后的自己留的线索。

三、核心能力拆解：六个模块，缺一个都跑不顺

3.1 可视化编排画布：核心不是拖拽，是变量

Dify 画布上每个节点的输出都是一个变量，下游用 {{#节点名.变量名#}} 引用。开始节点有 sys.query，知识检索节点有 result，大模型节点有 text。连线之前先想清楚这一步要消费上游的哪个变量，比连线本身重要得多。

Dify 的画布支持条件分支、迭代、变量聚合、问题分类、参数提取。判断标准很简单：如果一段逻辑在纸上画不出来，就别指望在画布上画明白。

3.2 知识库：分段、索引、检索三件事

上传文档后第一件事是分段。通用分段按分隔符切，自定义分段可以按标题层级切；父子分段保留”整段给模型、子段做检索”的结构，长文档用这个模式效果好很多。Dify 的分段预览会直接显示每一块的内容，别跳过这一步。

索引阶段要选 Embedding 模型，检索阶段要选方式：向量检索看语义相近，全文检索看关键词命中，混合检索把两者加权，需要挂 Rerank 模型。TopK 和分数阈值决定召回多少段，这两个参数没有通用值，只能拿真实问题在命中测试里调。

元数据是这个模块里最被低估的一项。给每份文档打上部门、密级、生效日期三个字段，检索时按条件过滤，比事后靠提示词约束可靠得多。制度更新时把旧版本的生效日期改掉，用户就再也搜不到过期条款，这件事在 Dify 里点几下就能配完。

3.3 模型管理：一个入口管所有供应商

Dify 的系统模型是平台预置的，自定义模型可以填 OpenAI 兼容的地址和密钥，把任何兼容接口的服务接进来；本地部署的 Ollama、Xinference 也能接。每个模型能设负载均衡和故障转移，主模型超时自动切备用。

这条对生产影响很大：换模型不该改工作流，只该在模型设置里换一个名字。做不到这点的搭建方式，早晚要返工。

3.4 提示词调试：调话术的地方，也是看成本的地方

编排页右侧就是提示词编辑区，支持变量插入、上下文插入、对话历史。调试时能看到每次调用的 token 数、耗时、以及模型返回的原始内容。写提示词时把检索到的内容当参考资料显式引用，比让它自己回忆准得多，这也是 Dify 比裸调接口省心的地方。

3.5 代码节点与插件

Dify 的代码节点支持 Python 3 和 JavaScript，输入输出都是变量，适合做格式转换、字段清洗、简单计算。插件市场里能装模型供应商、工具（搜索、网页抓取、数据库），以及别人封装好的扩展。

判断：代码节点越少，应用越好维护。它不是用来写业务逻辑的，是用来补画布表达不了的那一小块。写多了，Dify 就退化成了一个难用的编辑器。

3.6 日志与标注：把”答得不对”变成可复现的样本

日志页能回看每一次调用：用户输入、检索到的分段、模型输出、耗时、token 消耗。标注页可以给某条回答打分、改写成标准答案，并把标注设为直接回复，下次相似问题优先命中。

这两个功能的价值不在好看。它把一句模糊的”用户觉得答得不对”，变成一条能复现、能回归的样本。没有日志的 RAG 应用，调优全靠猜。

四、六步落地：用 Dify 搭一个内部知识库问答

场景定死：一家四十人的公司，把产品手册、售后 FAQ、行政制度放进去，做一个只给员工用的问答入口，最后通过接口接进内部后台。下面每一步都给具体位置和参数。

4.1 第一步：新建应用，选 Chatflow

进入 Dify 工作台，点创建空白应用，选 Chatflow，名字写”内部知识库问答”。不建议一上来用 Agent，它会自己决定要不要检索，答案不可复现，出了问题很难查。要的是稳定，不是聪明。

4.2 第二步：建知识库，先把文档洗干净

进 Dify 的知识库页面新建，先传 20 到 50 份，不要一次性把三个 G 的共享盘倒进去。上传后打开分段预览，把页眉页脚、页码、”第 X 页共 Y 页”这类噪声删掉，再保存。这一步偷懒，后面调多久都没用。

参数给一组起点：最大分段长度 400 到 500 token，重叠 50 到 80 token，按标题或空行切。表格多的文档单独建一个库，用自定义分段，别和正文混在一起，否则一张表被切成十几块，检索出来全是残句。

4.3 第三步：在画布上连四个节点

开始节点连知识检索，检索连大模型，大模型连直接回复。检索节点里选刚建的库，查询变量用开始节点的 sys.query，TopK 设 4，分数阈值先给 0.4 到 0.5，检索方式选混合检索并挂上重排模型。检索节点的输出接进大模型的上下文变量。

测试时打开显示引用，这样能直接看到它引了哪一段。Dify 默认不把引用摆到明面上，很多人第一次调，压根不知道模型看的是哪块内容。

四个节点之间的变量要一段一段接：开始节点的 sys.query 给检索节点当查询词，检索节点的 result 给大模型当上下文，大模型的 text 给直接回复。变量选择器会把上游节点的输出列出来，手写变量名很容易拼错，一个字符不对，整条链路就断在半路。

4.4 第四步：写系统提示词，把边界写死

可直接套用的一段：你是公司内部知识库助手，只依据提供的资料回答；资料里没有的，直接说”资料中没有这项内容，建议联系行政或对应负责人”，不要推测；回答控制在三百字以内；涉及流程的按步骤列出；结尾标注引用的文档名。

这段话里最重要的不是语气，是”没有就说没有”。RAG 应用最大的信任崩塌，是模型在没检索到内容时编一个像样的答案，而用户当场就信了。

参数上再补两点：温度调到 0.1 到 0.3，问答不需要创造力；最大回复长度按场景给，内部问答三百到五百 token 足够。Dify 允许在节点里单独覆盖模型参数，不必改全局设置，这对多个应用共用一个模型的团队很重要。

4.5 第五步：拿二十个真问题跑一遍

从群里翻二十条真实提问，逐条测。看三件事：检索有没有召回正确分段、答案有没有越界、引用对不对得上。答错的去标注页记一条，把正确说法写进去，再设为直接回复。这一轮通常能改掉一半问题。

判断：如果检索没召回，改提示词是白费功夫。先看日志里的召回片段，再决定是改分段、换 Embedding，还是补文档。顺序错了，一天就没了。

4.6 第六步：发布，三种方式选一种

右上角点发布后有三个出口：Web 应用，平台直接给一个可访问页面，能配欢迎语和访问控制；嵌入网站，给 iframe 或一段 JS 脚本，粘到内网系统里就能用；接口，给后端服务调用。前两个适合快速验证，第三个才是长期方案。

接口的用法：应用页点访问 API，创建密钥，得到一个以 app- 开头的字符串；请求头带 Authorization: Bearer 加这个密钥；对话接口是 POST /v1/chat-messages，参数包括 query、inputs、response_mode（streaming 或 blocking）、conversation_id、user。多轮就靠回传上一次的 conversation_id，不传就是新会话。

工作流类应用走 /v1/workflows/run，参数是 inputs 加 response_mode；文件先传到 /v1/files/upload 拿 id，再在参数里引用。并发和限流在 API 扩展页配置，别等被打爆才想起来。

import requests

BASE = "你的 Dify 服务地址"
KEY = "app-xxxxxxxx"

r = requests.post(
    f"{BASE}/v1/chat-messages",
    headers={"Authorization": f"Bearer {KEY}"},
    json={
        "inputs": {},
        "query": "报销多久到账",
        "response_mode": "blocking",
        "conversation_id": "",
        "user": "u_1024",
    },
)
print(r.json()["answer"])

这段代码里唯一需要改的是地址和密钥。user 字段看着无关紧要，其实决定了会话隔离和用量统计，别图省事写死一个固定值。上线前把 blocking 换成 streaming，用户不用等十几秒才看到第一个字，体验差别很大。

五、六条进阶技巧，都是踩过坑才明白的

5.1 分段大小按问题粒度定，不按文档结构定

用户问的是”报销要几天”，不是”财务制度第三章”。在 Dify 里分段，要刚好装下一个完整答案，装不下就拆，装了三四个主题就切。检验方法：随便抽五段，遮住上下文读一遍，能独立看懂就是合格的段，看不懂就是切错了。

5.2 混合检索加强制重排，但别无脑开

向量检索擅长同义表达，全文检索擅长型号、编号、专有名词，Dify 的混合检索把两者加权，再用重排排序，召回质量提升明显。代价是每次查询多一次模型调用，延迟涨两三百毫秒。内部问答能接受，实时客服就得算笔账。

5.3 用会话变量做隔离，别用一个应用服务所有部门

会话变量能存用户身份、部门、权限级别，检索时按元数据过滤。同一个应用，销售看到销售政策，财务看到财务制度，靠的是过滤条件，不是提示词里写一句”请不要回答无关内容”。后者只能算提醒，前者才是权限。

5.4 代码节点只做转换，不做业务

拿它拼字符串、洗 JSON、算日期都行；拿它连数据库、写业务规则就不行。原因很实在：代码节点出错时，日志里只有一段堆栈，工作流上下文全丢了，排查成本比放在后端高得多。Dify 的调试面板对这个场景帮助有限。

5.5 把标注攒成评测集

每次上线前，把标注过的一百条问答导出来当回归题。改了分段、换了模型、调了提示词，都拿这套题跑一遍，看正确率是升还是降。没有这套题，每次优化都只是感觉变好了，两周后连自己都不信。

5.6 给每个应用留一份变更记录

Dify 的编排页有版本历史，改坏了可以回到上一个版本。但版本号不会告诉你”为什么改”，所以在应用说明里手写一行：几月几日，改了分段长度，原因是售后问题召回不全。半年后接手的人，靠这一行能省掉两天排查。

六、横向对比：Dify 站在哪一格

功能列表谁都能写得漂亮，真拉开差距的是四条线：开源性、私有化能力、上手难度、生态。下面这张表按这四条排，比按功能排更有决策价值。

工具	开源性	私有化	上手难度	生态	最适合谁
Dify	开源，社区版可自托管	强，Compose 一键部署	中	插件市场在成长	企业内部应用、RAG 问答
Coze 扣子	闭源，托管为主	弱，走官方云	低	插件多，流量入口好	做 Bot、接社交平台
n8n	开源	强	中	几百个系统集成，最全	流程自动化、系统串联
FastGPT	开源	强	中低	围绕知识库，偏垂直	纯问答、客服知识库
RAGFlow	开源	强	高	文档解析见长	复杂版式、深度检索
LangChain	开源库	完全自主	高	库最全，更新最快	要精细控制的工程团队

6.1 三条主轴上的真实差别

私有化：Dify、n8n、FastGPT、RAGFlow 都能自己装，Coze 主要走托管。上手：Coze 最快，FastGPT 次之，Dify 中等，RAGFlow 和 LangChain 最陡。生态：n8n 的集成节点最多，LangChain 的组件最全，Dify 靠插件市场在追，追赶速度不慢但还没追平。

选型的顺序应该是先定私有化要求，再定检索精度，最后才比界面。私有化过不了，后面全白搭；检索精度不够，界面再顺也救不回来。Dify 在这两关上都算及格，界面是它额外送的，所以它常被当成”先跑起来”的那个选项。

6.2 什么时候该离开 Dify

离开 Dify 通常是三种情况：需要极细的检索策略，自己控制分块、打分、融合，用 RAGFlow 或干脆自己写；需要复杂的异步编排、事务、重试，回到代码用 LangChain；需要跟几百个 SaaS 系统对接，n8n 更顺手。

还有一种是组合用法：用 n8n 做定时抓取和系统同步，把清洗好的文档推进 Dify 的知识库，问答仍然交给 Dify。两个工具各干擅长的事，比强行让一个包办到底稳。前提是团队里有人同时懂两边，否则接口会成为新的故障点。

反过来，如果你的需求是两周内上线一个能用的问答，别纠结。Dify 的默认值已经比大多数人手写的第一版要好，先把闭环跑通，再谈替换。

七、价格与部署：钱到底花在哪

7.1 云端：按席位和调用量

官网有免费额度，够做演示和小流量试用；专业版、团队版按年或按月订阅，含更高的调用额度、更多成员席位、更长的日志保留。具体价格以官网为准，活动期会变，别拿旧截图当预算依据。

专业版和企业版的差别主要不在功能，在协作与合规：多工作空间、成员角色、单点登录、审计日志、更长的日志留存。个人开发者用不上这些，但五十人以上的公司往往就卡在权限这一关。Dify 社区版在这里是刻意留白的，别指望自己打补丁绕过。

7.2 自托管：软件不花钱，机器要花钱

Dify 官方 Compose 起的是全家桶：API 服务、前端、PostgreSQL、Redis、向量数据库、沙箱、反向代理。4 核 8G 是能跑的下限，二十人以上日常用建议 8 核 16G 起，向量库单独放一块 SSD。备份要覆盖数据库和向量库，只备份其中一个，恢复时会对不上。

7.3 两条路怎么选

维度	云端	自托管
起步成本	低，注册即用	中，要一台像样的机器
数据位置	第三方服务器	自己的机房或云主机
扩容方式	买更高套餐	加机器、调容器资源
运维投入	几乎为零	升级、备份、排障都要人
适合谁	小团队、公开资料	有合规要求、有运维