本文是《AI Agent 实战》系列第 3 篇。前两篇我们用手写代码的方式理解了 Agent 的构成和 LangGraph 的图编排。本篇换个路线一行代码都不写用 Dify 把一个私有知识库问答 Agent 搭出来。适合不想啃框架、但手上有一堆文档想让 AI 能问答的人。上篇发出去后评论区最高频的一句话是我是产品/运营我不想学 LangGraph但我想让我们公司的产品手册、制度文档、历史工单能被 AI 问答怎么办这个需求有个专业名词叫RAG检索增强生成把你的文档切成片段、向量化存起来用户提问时先检索相关内容再把内容喂给大模型作答。自己写这套流程你要处理文档解析、分块、Embedding、向量库选型、检索召回、重排、提示词拼装——至少几百行代码。而 Dify 把它做成了拖拽和填表。先说清楚本篇能给你什么30 分钟内跑通一个能回答你私有文档的问答应用一套检索效果优化清单这是大多数教程跳过、但决定你能不能真正落地的部分一份踩坑记录包含准确率上不去的具体原因。需要先明确的边界Dify 适合知识库问答、流程编排、内部工具类 Agent。如果你的场景需要复杂的多步任务规划、精细的状态控制、自定义循环逻辑还是得上 LangGraph见第 2 篇。两者不冲突很多人是 Dify 做上层应用、LangGraph 做底层能力再通过 API 打通。一、Dify 是什么以及它的应用类型怎么选Dify 是一个开源的 LLM 应用开发平台把模型接入、提示词编排、知识库RAG 管道、工具调用、发布与监控这些环节做进了一个可视化工作区。它既能用官方云服务也能 Docker 本地私有化部署——对文档敏感的企业这一条往往是决定性优势。版本号提示Dify 已进入 1.x 阶段2026 年迭代到 1.17 系列知识库、工作流、Agent 能力都在持续增强。本文界面描述基于 1.x 较新版本具体菜单名称以你部署的版本为准。四种应用类型别一上来就选最复杂的类型是什么适合什么Chatbot聊天助手单轮/多轮对话最简单先理解 RAG本篇入门用它Agent会自主判断并调用工具需要工具编排的问答如查库存、查订单Chatflow带画布编排的对话流有分支、有多轮交互的客服场景Workflow批处理式工作流内容生成、数据处理这类一次性跑完的任务我见过太多人一开始就上 Workflow把简单问答做成复杂 DAG最后自己维护不动。合理路径是先用 Chatbot 理解 RAG → 再用 Agent 理解工具调用 → 最后才上 Chatflow/Workflow。【图 1四种应用类型选择决策树】二、先搭好环境云服务还是本地部署路线 A用官方云服务本篇演示走这条注册即用有免费额度可以先把流程跑通额度和计费规则会变动手前请以官网当前定价页为准。优点是不用管服务器缺点是文档会存在第三方公司真实文档请先过合规。路线 BDocker Compose 本地部署git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d启动后访问http://localhost/install完成初始化。几个务实提醒配置门槛默认栈会拉起 PostgreSQL、Redis、向量库Weaviate/Qdrant 可选等多个容器2 核 4G 会跑得很勉强建议至少 4 核 8G 起。版本升级前看 Release NotesDify 近几个版本有过依赖相关的升级注意事项别在业务高峰直接up -d覆盖。内网/离线环境模型和插件都需要能访问到注意提前配置模型服务地址或插件镜像源。选哪条验证想法用 A涉及私有数据或要做交付用 B。三、核心概念Dify 的 RAG 是怎么工作的理解这条链路后面的参数你才知道自己在调什么原始文档 ↓ 解析提取文字、表格、图片 ↓ 分段清洗切 Chunk决定一段知识有多大 ↓ 向量化Embedding 模型把每段变成向量存入向量库 ↓ 用户提问 ↓ 问题向量化 ↓ 检索向量检索 / 全文检索 / 混合检索召回 Top-K 片段 ↓ Rerank 重排可选把真正相关的排到前面 ↓ 拼进提示词交给大模型 ↓ 生成答案可开启引用来源标注对应 Dify 里的四个可配置旋钮旋钮在哪配影响什么分段策略知识库 → 处理规则知识颗粒度直接决定召回完整性Embedding 模型知识库 → 索引方式检索质量的天花板检索方式知识库 → 检索设置能不能召回关键词类问题Top-K / 阈值应用 → 上下文设置喂给模型的信息量与成本【图 2RAG 全链路 Dify 对应配置位置示意图】四、实战从零搭一个产品手册问答 Agent我用一份虚构的《智能硬件产品手册》做演示20 页 PDF 30 条 FAQ 一份保修政策文档。步骤 1创建知识库知识库 → 创建 → 选择导入已有文本上传文档。这里就遇到第一个决策分段模式选哪个模式怎么切适用通用模式按段落/句子自动切结构松散的纯文本父子模式先切大块父再切小块子检索命中子块、生成时回退父块技术文档、手册推荐问答对模式按 Q-A 成对存储FAQ、工单库召回精准度最高我选了父子模式。原因手册里如何配对蓝牙设备这段被切成 4 个子块用户提问只会命中其中一句答案缺步骤用父子模式则子块保检索精度、父块保上下文完整。分段参数中文技术文档建议Chunk Size 300–500 tokenOverlap 10%–20%。用 Dify 默认策略直接跑技术文档的检索精度通常会打折——这是最常见的效果差原因之一。【图 3分段设置界面截图位置】步骤 2索引与检索设置索引方式选高质量经济模式是关键词倒排中文语义匹配基本不够用。Embedding 模型中文场景优先 BGE-M3bge-m3这类中文表现好的模型云服务路线可以直接用它提供的内置 embedding。检索方式选混合检索并开启 Rerank纯向量检索会漏掉精确关键词型号编号、SKU、专有名词全文检索会漏掉同义表达混合检索 重排是当前的稳定解。Top-K 设 3–5相似度阈值 0.5 左右起步。别贪心把 Top-K 调到 10喂给模型的片段越多噪声越大、Token 越贵、模型越容易被互相矛盾的片段带偏。步骤 3召回测试这一步千万别跳过知识库自带的召回测试是整个流程里性价比最高的功能。在建应用之前先拿 5–10 个真实问题去测测试问题 期望召回 实际结果 设备怎么连蓝牙 配对章节 ✅ 命中步骤完整 保修期是几年 保修政策条款 ❌ 召回了退换货政策跨文档混淆 X200 支持哪些频段 规格表 ❌ 未命中表格被切碎我这一步就抓出两个真问题表格被切碎规格参数表按纯文本切分后型号和频段分到了不同片段。解法把规格表单独抽成问答对模式的知识库或上传时保留表格结构。多文档信息串味保修政策和退换货政策相似度高交叉后模型拼出不存在的条款。解法给文档加元数据标签检索时按标签过滤同时在提示词里强制只依据给定上下文回答不得推测。准确率上不去八成问题在这一步就能定位。没有召回测试你根本无法判断是模型笨还是检索没找到。步骤 4创建 Chatbot 应用并挂载知识库工作室 → 创建应用 → Chatbot。核心配置模型日常问答够用即可DeepSeek、通义等 OpenAI 兼容模型都能接上下文知识库选刚建的那个引用来源打开便于人工核对答案依据提示词见下。你是本产品的官方客服助手。 【回答规则】 1. 只能依据下方检索到的「上下文」回答不得凭借自身知识推测或补充。 2. 上下文中找不到答案时固定回复这个问题我需要为你转接人工客服 请拨打 400-XXX-XXXX。不要编造。 3. 涉及价格、保修期限、医疗或安全说明的内容必须逐字引用上下文原文。 4. 回答不超过 200 字操作步骤用编号列表。第 2 条是这套应用里最重要的一句。知识库问答最大的业务风险不是答不上来而是答错还很自信——把不存在的服务承诺发给客户是要担责的。宁肯它说不知道。步骤 5跑一遍真实问题Q: X200 支持哪些频段 A: 根据产品规格X200 支持以下频段 - 4GBand 1/3/5/8/34/38/39/40/41 - 5Gn1/n3/n28/n41/n78/n79 来源产品手册 V2.3 第 7 页 规格参数表 Q: 我买了两年屏幕摔坏了能免费修吗 A: 这个问题我需要为你转接人工客服请拨打 400-XXX-XXXX。 说明保修政策中未包含意外损坏的免费维修条款需人工判定第二问的拒绝回答是符合预期的——文档里确实没有免费维修条款模型没有编造。这比硬答一个可以免费维修安全得多。到这里一个可用的问答 Agent 就搭完了全程没写一行代码。五、再往上加一层让 Agent 会查工单、会调接口纯问答只能回答文档里写了什么。真实客服还需要查这个用户的订单状态。用 Dify 的Agent 节点 自定义工具把你的内部接口按 OpenAPI/Swagger 描述或写成 Dify 工作流当工具用在工具 → 自定义里注册填服务 URL 与鉴权应用类型选 Agent挂上知识库 这个工具模型自己判断查参数走知识库检索查订单走工具调用。进阶玩法Dify 1.x 已支持知识编排Knowledge Pipeline可视化编排文档摄取、解析、切分、索引的全过程把标准清洗逻辑做成可复用流水线比默认上传即索引可控得多多模态检索知识库支持图文联合理解PDF 里的产品图、说明书示意图也能参与检索人机介入节点在退款、改地址等敏感动作前插入人工审批——和第 2 篇 LangGraph 的interrupt是同一个工程思想。六、常见坑与排查清单按现象 → 原因 → 解法整理答非所问 / 明明有答案却说不知道先跑召回测试。召回不到 → 分段或 Embedding 问题分段太碎、切断了完整段落召回到了还答错 → 提示词约束不足或上下文太多互相矛盾。答案把两份文档的内容混在一起多文档交叉是高频事故。解法文档打元数据标签按标签过滤检索、拆分成多个知识库、提示词强约束仅依据上下文。表格、参数、价格答错表格按文本切分会散架。解法关键表格单独转成问答对模式或用能保留表格结构的解析方式涉及价格保修一律要求逐字引用。默认分段策略直接上线效果一般按内容类型定制技术文档按标题层级切、合同保留表格结构、论文注意段落完整性。回答很慢Rerank 会引入额外延迟。解法控制 Top-K、给关键节点配结果缓存、无依赖节点用并行执行。本地部署容器起不来 / 内存爆掉检查宿主机资源默认栈至少 4 核 8G内存不足时优先精简向量库而非硬扛。成本失控Token 大头在检索片段过长。解法Top-K 收敛、缓存、把长文档拆库按需检索、高频问题走小模型兜底。七、和 LangGraph 到底怎么选这是最常被问到的问题一张表说清维度DifyLangGraph上手门槛低可视化高需要写代码知识库/RAG开箱即用配置化自己接可控性强复杂流程与循环有工作流但深度定制受限状态图 条件边表达力最强精细状态控制/中间件一般强Checkpointer、interrupt、reducer私有化支持注意资源要求支持更灵活团队维护非工程角色也能改提示词和知识库需要工程能力适合场景知识库问答、内部工具、客服流程任务规划、多 Agent、复杂自主决策务实建议先用 Dify 验证需求是否成立跑通了、要往复杂逻辑走的时候再换 LangGraph。很多团队一上来就选更强大的框架结果两周还没跑通第一版需求本身已经被证伪了。总结本篇你完成了用 Dify 零代码搭出一个能回答私有文档的知识库问答 Agent理解了 RAG 链路各环节对应的配置旋钮尤其是分段策略与混合检索掌握召回测试这个定位问题的关键手段以及只依据上下文、答不了转人工这条安全约束通过自定义工具把问答升级成能查订单的 Agent。下一篇预告《AI Agent 常见报错与调试方法》——把 LangGraph、Dify、模型 API 三层最容易炸的问题整理成一张排查表遇到问题按表定位不再靠猜。配套的《知识库分段参数速查表》和《产品手册问答完整 DSL》我打包好了评论区回复Dify领取。