第15章 Dify进阶：RAG管道优化、Agent模式与工作流编排
AI智能体实战训练营 · 章节 15/33 · 45 学时
Dify进阶：RAG管道优化、Agent模式与工作流编排
上一章我们学习了Dify的基础操作，搭建了第一个知识库问答应用。本章将深入Dify的进阶功能——RAG管道优化、Agent模式、工作流编排、自定义工具开发、API集成等。掌握这些进阶功能，你才能用Dify构建复杂的企业级智能体应用。
一、RAG管道深度优化
RAG（检索增强生成）是Dify的核心功能之一。上一章我们介绍了基础的RAG配置，本章深入讲解如何优化RAG管道，提升检索和回答质量。
1.1 RAG管道的完整流程
Dify的RAG管道包含以下环节：
- 文档预处理：文档上传→格式解析→内容清洗
- 分段（Chunking）：把长文档切分成合适大小的块
- 向量化（Embedding）：用Embedding模型把每个分段转换成向量
- 存储：向量和原始文本存入向量数据库
- 查询预处理：用户问题→查询改写（可选）→向量化
- 检索：在向量数据库中搜索最相似的Top K个分段
- 重排序（Rerank）：用Rerank模型对检索结果重新排序（可选）
- 上下文组装：把检索到的分段组装成上下文，插入提示词
- 生成：大模型基于上下文生成回答
每个环节都会影响最终效果，需要逐一优化。
1.2 分段策略进阶
分段是RAG效果的关键环节。Dify支持多种分段方式：
| 分段方式 | 原理 | 适用场景 |
|---|---|---|
| 自动分段 | Dify自动按语义和分隔符分段 | 普通文档、结构不清晰的文档 |
| 自定义分段 | 用户指定分段标识符、分段大小、重叠 | 技术文档、有清晰结构的文档 |
| 父-子分段（Parent-Child） | 检索时用小子块精确匹配，返回时返回父块（更大的上下文） | 需要精确匹配但又需要完整上下文的场景 |
分段优化技巧：
- 按结构分段：对于有标题层级的文档（如手册、规范），按标题分段（每个小节一个分段），语义最完整
- 分段大小：一般300-800个token。技术文档可以小一点（300-500），故事性文档可以大一点（500-800）
- 重叠：10-20%的重叠，避免关键信息被切断。分段大小500，重叠50-100
- 避免切断：不要在句子中间、表格中间、列表中间切断。分段边界应该在段落之间、标题之后
- 元数据：给每个分段添加元数据（文档名、章节、设备类型、发布日期），支持过滤检索
1.3 检索策略优化
Dify支持多种检索方式，需要根据场景选择和优化：
检索方式对比：
| 检索方式 | 原理 | 优点 | 缺点 |
|---|---|---|---|
| 向量检索 | 计算问题和文档的向量相似度 | 理解语义，同义词/改写能匹配 | 可能漏掉精确关键词匹配 |
| 全文检索（BM25） | 基于关键词匹配的经典算法 | 精确匹配关键词、型号、编号 | 无法理解语义，同义词匹配不到 |
| 混合检索 | 同时进行向量和全文检索，合并结果 | 兼顾语义和精确匹配，效果最好 | 实现复杂，需要调权重 |
推荐：混合检索 + Rerank。这是目前效果最好的组合。
检索参数优化：
- 召回数量（Top K）：先召回10-20条，Rerank后取Top 3-5。直接召回3-5条可能漏掉相关结果
- 相似度阈值：0.5-0.7。太高漏掉相关结果，太低引入噪声
- Rerank模型：一定要开启（如果有）。推荐Cohere Rerank、Jina Reranker、BGE Reranker
- 查询改写：开启查询改写功能，用大模型把用户问题改写成更适合检索的查询。特别是多轮对话中，要结合上下文改写
- 多路召回：对同一个问题，用原问题、改写问题、提取关键词分别检索，合并去重
1.4 提示词优化
RAG的提示词需要精心设计，才能让大模型正确使用检索到的上下文：
你是一位专业的制造业知识管理专家。请基于以下参考资料回答用户的问题。
【参考资料】
{{context}}
【用户问题】
{{query}}
【回答规则】
1. 必须基于参考资料回答，不要使用参考资料以外的知识
2. 如果参考资料中没有相关信息，明确说"根据现有资料无法回答这个问题"，不要编造
3. 回答要准确、专业、有条理
4. 引用参考资料中的具体内容时，标注来源编号（如[资料1]）
5. 如果参考资料之间有矛盾，说明矛盾点，并建议以最新版本或官方文件为准
6. 涉及安全操作时，必须强调安全注意事项
【输出格式】
## 答案
（基于参考资料的回答）
## 信息来源
- [资料1] 《文档名》- 章节名
- [资料2] 《文档名》- 章节名
## 补充建议
（如果有，给出进一步的建议）1.5 RAG效果评估和持续优化
- 准备测试集：准备20-50个典型问题和标准答案，覆盖各种场景
- 评估指标：检索准确率（召回率、精确率）、回答准确率、幻觉率、完整性、相关性
- 人工评估：定期人工抽检回答质量，打分并记录问题
- 大模型评估：用大模型作为"裁判"，自动评估回答质量（可以大规模评估）
- bad case分析：对回答不好的案例，分析是检索问题（没检索到/检索到不相关）还是生成问题（没使用上下文/编造），针对性优化
- A/B测试：对分段策略、检索参数、提示词进行A/B测试，用数据找到最优配置
二、Agent模式
Dify的Agent模式是具备工具调用能力的自主智能体。与普通聊天助手不同，Agent可以自主判断需要调用什么工具、按什么顺序执行，完成复杂任务。
2.1 Agent vs 聊天助手
| 维度 | 聊天助手 | Agent |
|---|---|---|
| 工具调用 | 可以配置工具，但调用逻辑相对固定 | 自主判断是否调用工具、调用什么工具、按什么顺序调用 |
| 任务复杂度 | 适合简单问答、单步任务 | 适合复杂、多步骤、需要灵活应对的任务 |
| 自主性 | 较低，主要是回答问题 | 较高，可以自主规划和执行任务 |
| 可预测性 | 高，回答相对可控 | 较低，执行路径可能每次不同 |
| 成本 | 较低，大模型调用次数少 | 较高，可能多次调用大模型和工具 |
2.2 Agent的两种推理方式
Dify支持两种Agent推理方式：
- Function Calling（函数调用）：大模型直接输出工具调用的JSON格式，系统执行后返回结果。效率高、延迟低，推荐使用支持Function Calling的模型（如GPT-4o、Claude 3.5、DeepSeek等）
- ReAct（推理+行动）：大模型用自然语言输出思考过程（Thought）和行动（Action），系统解析后执行。兼容性好，适合不支持Function Calling的模型，但效率较低
推荐：优先使用Function Calling方式，效果更好、效率更高。
2.3 Agent配置要点
- 提示词：明确Agent的角色、能力、可用工具、行为规则、输出格式。特别要说明"什么时候应该调用工具，什么时候直接回答"
- 工具选择：只添加真正需要的工具（5-10个为宜）。工具太多会让Agent"选择困难"，降低调用准确率
- 工具描述：每个工具的名称和描述要清晰准确，说明功能、适用场景、参数含义。Agent是根据描述来判断是否调用的
- 模型选择：用能力较强的模型（如GPT-4o、Claude 3.5），Agent对模型的推理和工具调用能力要求较高
- 最大迭代次数：设置Agent的最大工具调用次数（如10次），避免无限循环
- 温度：设为0.1-0.3，Agent需要稳定性，低温度更可靠
2.4 Agent实战：制造业设备故障诊断Agent
🔧 实战案例：设备故障诊断Agent
场景：维修工输入故障现象，Agent自主查询设备档案、检索维修手册、查询历史故障案例、分析原因、给出维修方案、创建维修工单。
配置的工具（5个）：
1. 查询设备档案（自定义API工具）：根据设备编号查询设备型号、参数、安装时间、维护记录
2. 检索维修手册（知识库工具）：从维修手册知识库中检索相关内容
3. 查询历史故障（自定义API工具）：查询该设备的历史故障记录和维修方案
4. 创建维修工单（自定义API工具）：在工单系统中创建维修工单
5. 发送通知（自定义API工具）：给维修班组发送企业微信通知
Agent提示词要点：
- 角色：有15年经验的设备维修专家
- 工作流程：1）确认故障现象 2）查询设备档案 3）检索维修手册 4）查询历史故障 5）分析原因 6）给出维修方案 7）创建工单 8）通知维修班组
- 约束：必须基于查询到的信息分析，不要编造；涉及安全的操作必须强调安全规范；如果信息不足先询问用户
- 输出：诊断结论、可能原因（按可能性排序）、维修步骤、所需工具备件、安全注意事项、工单编号
工作流程示例：
用户："3号空压机异响，温度95度"
→ Agent思考：需要查询设备档案、检索维修手册、查询历史故障
→ 调用工具1：查询设备档案（设备编号3号空压机）
→ 调用工具2：检索维修手册（关键词：空压机异响高温）
→ 调用工具3：查询历史故障（3号空压机历史故障）
→ Agent综合三个工具的结果，分析原因
→ 生成诊断报告和维修方案
→ 调用工具4：创建维修工单
→ 调用工具5：通知维修班组
→ 返回最终结果给用户
场景：维修工输入故障现象，Agent自主查询设备档案、检索维修手册、查询历史故障案例、分析原因、给出维修方案、创建维修工单。
配置的工具（5个）：
1. 查询设备档案（自定义API工具）：根据设备编号查询设备型号、参数、安装时间、维护记录
2. 检索维修手册（知识库工具）：从维修手册知识库中检索相关内容
3. 查询历史故障（自定义API工具）：查询该设备的历史故障记录和维修方案
4. 创建维修工单（自定义API工具）：在工单系统中创建维修工单
5. 发送通知（自定义API工具）：给维修班组发送企业微信通知
Agent提示词要点：
- 角色：有15年经验的设备维修专家
- 工作流程：1）确认故障现象 2）查询设备档案 3）检索维修手册 4）查询历史故障 5）分析原因 6）给出维修方案 7）创建工单 8）通知维修班组
- 约束：必须基于查询到的信息分析，不要编造；涉及安全的操作必须强调安全规范；如果信息不足先询问用户
- 输出：诊断结论、可能原因（按可能性排序）、维修步骤、所需工具备件、安全注意事项、工单编号
工作流程示例：
用户："3号空压机异响，温度95度"
→ Agent思考：需要查询设备档案、检索维修手册、查询历史故障
→ 调用工具1：查询设备档案（设备编号3号空压机）
→ 调用工具2：检索维修手册（关键词：空压机异响高温）
→ 调用工具3：查询历史故障（3号空压机历史故障）
→ Agent综合三个工具的结果，分析原因
→ 生成诊断报告和维修方案
→ 调用工具4：创建维修工单
→ 调用工具5：通知维修班组
→ 返回最终结果给用户
三、工作流编排
Dify的工作流（Workflow）是可视化的多步骤流程编排工具。与Agent不同，工作流的流程是固定的、可预测的，适合标准化、复杂的业务流程。
3.1 工作流核心节点
| 节点类型 | 功能 |
|---|---|
| 开始（Start） | 工作流入口，定义输入参数 |
| LLM | 调用大模型进行文本生成、分析、推理 |
| 知识检索（Knowledge Retrieval） | 从知识库检索相关信息 |
| 工具（Tool） | 调用内置或自定义工具/API |
| 条件分支（IF/ELSE） | 根据条件选择执行路径 |
| 迭代（Iteration） | 遍历数组，对每个元素执行子流程 |
| 代码（Code） | 执行Python或JavaScript代码，进行数据处理 |
| 模板转换（Template Transform） | 用模板把输入数据转换成指定格式 |
| 变量赋值（Variable Aggregator） | 合并多个变量，用于分支汇合 |
| 结束（End） | 工作流出口，定义输出结果 |
3.2 工作流设计原则
- 单一职责：每个节点只做一件事，不要把多个功能塞进一个节点
- 输入输出明确：每个节点的输入变量和输出变量要清晰定义
- 从简单开始：先设计核心流程，跑通后再添加异常处理、优化细节
- 错误处理：对可能失败的节点（API调用、大模型调用）设置失败处理逻辑
- 避免过度复杂：节点太多的工作流难以调试和维护。如果超过15个节点，考虑拆分成多个工作流或用子流程
- 可测试性：每个节点可以单独测试，确保每个节点正确后再连起来
3.3 工作流实战：客户投诉自动处理流程
（与第13章Coze的案例类似，这里用Dify的节点实现，重点说明Dify工作流的特点）
- 用LLM节点做投诉分类和回复生成
- 用IF/ELSE节点做高优先级/普通优先级分支
- 用知识检索节点检索类似案例和回复模板
- 用代码节点做数据整理和格式转换
- 用工具节点调用API（发送通知、创建工单）
- 用变量聚合节点合并分支结果
3.4 工作流调试技巧
- 单节点测试：每个节点都可以单独运行，输入测试数据查看输出
- 逐步运行：用"运行"功能从开始节点逐步执行，查看每个节点的输入输出
- 检查变量引用：最常见的错误是变量引用错误——字段名不匹配、引用了不存在的变量。仔细检查每个节点的输入变量
- 大模型输出格式：大模型节点输出格式不稳定时，在提示词中明确要求格式（如"只返回JSON"），或用代码节点做格式校验和修正
- 查看执行日志：工作流运行后可以查看完整的执行日志，包括每个节点的输入输出、执行时间、状态
四、自定义工具开发
Dify支持自定义工具，可以把企业内部的API、第三方服务封装成工具，供Agent和工作流调用。
4.1 工具类型
- 内置工具：Dify内置了一些常用工具（网页搜索、代码执行、图片生成等）
- 自定义工具（API）：通过OpenAPI Schema或手动配置，把REST API封装成工具
- 自定义工具（代码）：用Python代码编写自定义工具（企业版功能）
4.2 自定义API工具配置步骤
- 进入"工具"→"自定义工具"→"创建自定义工具"
- 选择"从OpenAPI Schema导入"（如果有API文档）或"手动创建"
- 填写工具基本信息：名称、描述、图标
- 配置API：请求方法（GET/POST）、URL、认证方式（API Key/Bearer Token/无认证）、请求头
- 定义输入参数：参数名、类型、是否必填、描述、默认值
- 定义输出：可以用JSON Schema定义输出结构，或导入示例响应自动生成
- 测试工具：输入测试参数，查看API返回结果
- 保存发布
4.3 工具设计最佳实践
- 名称清晰：工具名称要能反映功能，如query_equipment_maintenance_records
- 描述详细：工具描述要包含：功能是什么、什么时候用、返回什么、和其他类似工具的区别。Agent是根据描述来判断是否调用的
- 参数描述清晰：每个参数都要有清晰的描述，包括含义、格式、示例。如日期参数说明格式是YYYY-MM-DD
- 单一职责：一个工具只做一件事。不要把多个API塞进一个工具
- 错误处理友好：API返回错误时，返回清晰的错误信息（错误码、错误原因、修正建议）
- 结果结构化：API返回JSON格式的结构化数据，不要返回纯文本
五、API集成与二次开发
Dify提供了完整的API接口，可以把Dify应用集成到企业现有系统中，也可以基于Dify进行二次开发。
5.1 应用API
每个Dify应用都有独立的API，可以通过API调用应用：
- 聊天消息API：发送消息，获取AI回复（支持流式和非流式）
- 工作流运行API：触发工作流运行，获取结果
- 消息反馈API：提交用户反馈（点赞/点踩）
- 建议问题API：获取下一轮建议问题
- 语音转文字/文字转语音API：语音交互
使用方式：在应用的"访问API"页面获取API Key，按照API文档调用。支持Python、JavaScript、cURL等多种方式。
5.2 知识库API
Dify的知识库也提供API，可以通过API管理知识库：
- 创建/删除知识库
- 上传/更新/删除文档
- 文档分段管理
- 检索（直接调用知识库检索，不经过大模型）
这对于需要批量管理文档、与企业文档系统集成的场景非常有用。
5.3 二次开发
Dify是开源的，可以基于源码进行二次开发：
- 前端定制：修改Web界面的样式、布局、功能，打造企业专属的AI应用界面
- 后端扩展：添加自定义的认证方式、权限系统、业务逻辑
- 模型扩展：添加不支持的模型供应商（需要自己实现适配器）
- 工具扩展：开发复杂的自定义工具（不只是API封装）
- 系统集成：与企业的SSO、ERP、CRM、OA等系统深度集成
二次开发需要一定的技术能力（Python后端、React前端），建议有技术团队的企业考虑。
六、企业级功能
6.1 多租户与团队管理
- 工作空间：Dify支持多工作空间，每个工作空间有独立的应用、知识库、成员
- 角色权限：支持管理员、编辑者、查看者等角色，精细控制权限
- 团队协作：多个成员可以协作开发应用、管理知识库
6.2 企业版高级功能
- SSO单点登录：支持SAML、OIDC等企业SSO协议
- 审计日志：记录所有操作日志，满足合规要求
- 自定义代码工具：用Python编写复杂的自定义工具
- 数据隔离：企业级数据隔离和安全保障
- 专属支持：企业级技术支持和SLA保障
6.3 安全与合规
- 数据私有化：私有化部署，数据完全在企业内部
- 传输加密：HTTPS传输加密
- 访问控制：API Key认证、IP白名单
- 数据脱敏：敏感信息脱敏处理
- 模型选择：可以选择符合合规要求的模型（如国内模型、本地部署模型）
🎯 本章小结：
• RAG优化：分段策略（按结构分段、300-800 token、10-20%重叠）、检索策略（混合检索+Rerank、Top K 10-20召回再精选、查询改写）、提示词（明确约束、标注来源、异常处理）、持续评估（测试集、bad case分析、A/B测试）
• Agent模式：适合复杂多步骤任务，支持Function Calling（推荐）和ReAct两种推理方式。配置要点：清晰提示词、适量工具（5-10个）、工具描述准确、强模型、最大迭代次数
• 工作流：适合标准化固定流程。核心节点10种，设计原则：单一职责、输入输出明确、从简单开始、错误处理、避免过度复杂
• 自定义工具：把企业API封装成工具。设计原则：名称清晰、描述详细、参数清晰、单一职责、错误友好、结果结构化
• API集成：应用API、知识库API，支持二次开发（前端定制、后端扩展、系统集成）
• 企业级功能：多租户、SSO、审计日志、数据隔离、安全合规
• RAG优化：分段策略（按结构分段、300-800 token、10-20%重叠）、检索策略（混合检索+Rerank、Top K 10-20召回再精选、查询改写）、提示词（明确约束、标注来源、异常处理）、持续评估（测试集、bad case分析、A/B测试）
• Agent模式：适合复杂多步骤任务，支持Function Calling（推荐）和ReAct两种推理方式。配置要点：清晰提示词、适量工具（5-10个）、工具描述准确、强模型、最大迭代次数
• 工作流：适合标准化固定流程。核心节点10种，设计原则：单一职责、输入输出明确、从简单开始、错误处理、避免过度复杂
• 自定义工具：把企业API封装成工具。设计原则：名称清晰、描述详细、参数清晰、单一职责、错误友好、结果结构化
• API集成：应用API、知识库API，支持二次开发（前端定制、后端扩展、系统集成）
• 企业级功能：多租户、SSO、审计日志、数据隔离、安全合规
下一章，我们将学习LangChain——最流行的AI应用开发框架。如果你需要高度定制化的智能体应用，或者想深入理解智能体的底层原理，LangChain是必须掌握的工具。
📝 本章练习（5题）
答案与解析请在 互动学习看板 中作答查看。
📚 AI智能体实战训练营 课程目录（33 章）
- 第1章 什么是AI智能体：从聊天机器人到自主决策系统
- 第2章 智能体的四大核心能力：感知·思考·行动·记忆
- 第3章 范式转移：智能体与传统软件的本质区别
- 第4章 2025年主流智能体平台全景对比与选型
- 第5章 智能体应用场景地图：从个人效率到企业级落地
- 第6章 编排思维：如何把大模型变成可执行的业务流程
- 第7章 Prompt工程实战：写出让智能体精准执行的指令
- 第8章 工作流编排入门：节点、连线、条件分支与循环
- 第9章 知识库RAG实战：让智能体拥有你的专业数据
- 第10章 工具调用实战：搜索·计算·API·数据库全掌握
- 第11章 多智能体协作：角色分工、任务分发与结果汇总
- 第12章 Coze/扣子入门：30分钟搭建你的第一个智能体
- 第13章 Coze进阶：插件开发、工作流深度编排与知识库优化
- 第14章 Dify入门：开源可私有化部署的智能体平台搭建
- 第15章 Dify进阶：RAG管道优化、Agent模式与工作流编排
- 第16章 LangChain入门：用代码构建可定制的智能体应用
- 第17章 LangChain实战：自定义Agent、工具链与记忆系统
- 第18章 Agent Harness与新一代框架：2025年智能体开发趋势
- 第19章 平台选型决策树：不同业务场景下的最优平台选择
- 第20章 任务拆解方法论：把复杂问题变成智能体可执行的步骤
- 第21章 提示词编排艺术：System·User·Function的三层协同
- 第22章 记忆系统设计：短期记忆、长期记忆与向量数据库选型
- 第23章 错误处理与容错：智能体执行失败时的兜底策略
- 第24章 评估与优化体系：如何量化衡量智能体的效果并持续改进
- 第25章 安全与合规：智能体应用的数据安全、隐私保护与风险防控
- 第26章 实战项目一：企业知识库智能问答助手（全流程实操）
- 第27章 实战项目二：制造业设备故障诊断智能体
- 第28章 实战项目三：供应链采购智能分析与比价助手
- 第29章 实战项目四：多智能体协同的项目管理办公室（PMO）
- 第30章 实战项目五：智能体与MES/ERP系统的深度集成
- 第31章 智能体落地路线图：从POC验证到规模化应用的完整路径
- 第32章 AI智能体工程师/产品经理的能力模型与成长路径
- 第33章 作品集打造与面试准备：如何拿到AI智能体岗位Offer