使用Dify低代码平台搭建知识库问答智能体

时长：约 34 分钟

学习目标

能说清一个知识库问答工作流从「接收问题」到「给出答案」的完整闭环。
掌握低代码平台里「知识检索」与「大模型」两个核心节点的配置要点。
了解 Dify 与 Coze 各自的发布方式，以及发布前必须做的测试层级。
会借助调试面板、日志和测试用例定位并优化智能体的回答。

一、知识库问答工作流的总思路

本节先给出「实操 2：构建一个知识库问答工作流」的整体蓝图。一个标准的知识库问答流程可以拆成四步：

工作流起点：接收用户输入，这是整个问答流程的触发环节，把用户的问题或需求作为后续操作的核心依据。
执行知识检索：以用户输入为查询关键词，在预设的专业知识库中精准检索，筛选出与问题相关的知识片段。
关键条件判断：对检索结果做置信度评估，判断召回内容是否足够匹配用户问题、能否支撑准确回答。
结果分支处理：置信度达标时，把检索结果作为上下文传给大模型生成有依据的答案；未达标时，直接调用模型回答，或引导用户重新提问以明确需求。

这四步是所有「检索增强问答」类智能体的通用骨架，无论用 Coze 还是 Dify，落点都一样。

二、在 Coze 中搭建知识库问答工作流

课程在扣子（Coze）里完整演示了一遍编排过程，核心是三个节点：

起始节点：设定启动工作流所需的输入，例如 USER_INPUT、CONVERSATION_NAME 等变量，声明必填项。
知识库检索节点：选定目标知识库（如「智能客服知识库」），用输入变量作为 Query 召回最匹配的信息，并以列表形式返回。
大模型节点：调用大模型，使用变量和提示词生成回复。

检索节点里有两个值得记下的配置点：

搜索策略：可选语义检索或混合检索，混合检索会结合向量与关键词，通常召回更稳。
召回控制：通过「最大召回数量」和「最小匹配度」过滤噪声，匹配度阈值太低会引入无关内容。

大模型节点的提示词是质量控制的关键。课程示例把客服行为拆成「技能」写进系统提示词：

技能 1 知识库回答：优先使用【已知参考资料】作答，不要编造；资料里没有对应答案时，直接告知「抱歉，该问题我暂时没有查到相关信息」。
技能 2 异常处理：信息不完整（如未提供订单号/手机号）时，明确提示用户补充后再查询。
技能 3 用户反馈与投诉处理：先情绪安抚，再记录诉求、时间、对象等关键信息，优先匹配知识库标准流程，需要升级则告知跟进时效。
技能 4 跨部门协助指引：问题超出知识库范围时，告知转对应部门并给出对接建议。

同时在「限制」里写明：只处理客服相关问题、拒绝无关话题、禁止编造知识库不存在的内容、回答口语化且不输出 Markdown 标题符号。可见「把边界写进提示词」比事后补救更有效。

三、试运行与日志

配置完成后先「试运行」，用真实问题验证。调试区能看到本次运行消耗的 Tokens、知识库实际召回的内容，以及模型基于召回片段生成的回答。

判断要点不是「有没有回答」，而是「召回片段对不对、回答有没有照着召回内容说」。如果发现答非所问，优先回到检索节点调整召回数量或匹配度阈值。

四、智能体的发布方式

发布不是「点一下」就结束，要按场景选对渠道：

Dify 三种核心发布模式：Web 应用模式生成独立访问链接、可配密码保护，适合企业内部快速试用；API 端点模式提供标准化接口，方便开发者集成到自有前端或业务流程；嵌入网站模式通过 iframe 或聊天气泡把智能体嵌进官网/内部门户。
Coze 生态化发布：主打一键多端分发，可快速发布到飞书、微信客服、Discord、掘金等平台，借助平台原生流量降低落地门槛。

一句话记忆：Dify 偏私有化与自有集成，Coze 偏生态化一键分发。

五、对话测试与调试

Dify 的调试面板像智能体的「CT 扫描仪」，能从四个层面透视运行状态：

灵活输入测试：用内置输入框模拟真实用户的各种提问，快速验证响应与意图理解。
全链路响应透视：不只看到最终回复，还能看到 Prompt 构建、模型调用、工具执行等内部过程。
精细化日志分析：记录每个节点的执行耗时、Token 消耗，以及 RAG 实际匹配到的文档片段。
精准问题追踪：每次请求生成唯一追踪 ID，出现异常时可快速回溯全流程定位根因。

测试贯穿整个生命周期，课程把它分成三个层级：

单元测试：单独验证每个功能节点或原子能力是否符合设计预期。
集成测试：打通全工作流，验证节点间联动、数据流与交互协作。
用户验收测试：邀请真实目标用户参与，从准确性、交互体验和业务解决能力三个视角评估。

六、测试用例设计与评估

设计测试用例要覆盖三个维度：功能正确性（知识库内问题能否精准回答）、鲁棒性（知识库外问题能否妥善处理）、边界情况（超长输入、多语言混合、敏感词触发等极端场景）。

执行上，准备 20 个以上有代表性的问题逐一测试，记录回答内容与召回片段，最后用「回答命中率」量化评估知识掌握程度与服务可靠性，为模型迭代提供可落地的客观依据。

七、实操 3 预告：Dify 公司制度问答助手

本课末尾抛出「实操 3：使用 Dify 搭建带知识库的问答智能体」，场景是「公司内部制度问答助手」：

场景：覆盖差旅标准、考勤规则、费用报销、人事流程等内部规章制度，替代人工解答。
数据底座：把 5 份 PDF 内部制度文件导入 Dify 做向量化处理。
落地成果：发布可复用的 Web 问答链接，回答时自动附带原文条款引用，既解决员工问题又实现制度依据可追溯。

下一节会把这个预告完整走一遍。

常见坑

检索匹配度阈值设得太低，噪声片段混进上下文，模型被带偏。
提示词只写「你是客服」，不写边界和「不知道就直说」，模型照样自由发挥。
没试运行就发布，结果上线后才发现召回或回答不合预期。
只看最终答案不看 ReAct/日志轨迹，同一个错误反复出现。
跳过单元测试直接做端到端验收，基础节点的小问题被放大成整条流程的故障。

自测题

知识库问答工作流的四步闭环分别是什么？
检索节点的「最大召回数量」和「最小匹配度」各控制什么？
为什么要在系统提示词里把「资料没有就说不知道」写清楚？
Dify 的三种发布模式分别适合什么场景？它与 Coze 的发布思路有何不同？
智能体测试的单元、集成、用户验收三层级各自关注什么？

答案提示：1. 接收输入 → 知识检索 → 条件判断 → 分支处理；2. 前者控制返回片段数量，后者过滤低相关内容；3. 从机制上降低幻觉、保持可追溯；4. Web 应用/API 端点/嵌入网站，Dify 偏私有化集成、Coze 偏生态一键分发；5. 单节点正确性、全流程联动、真实用户体验与业务解决能力。

本节小结

这一节把「会用工作流」升级为「能交付一个可用的知识库问答智能体」：先用「接收输入 → 检索 → 判断 → 分支回答」搭骨架，再通过提示词里的技能与限制守住回答边界，最后用调试面板、三层级测试和命中率评估保证质量，并按场景选择合适的发布渠道。下一节的实操 3 就是这套方法论在 Dify 上的完整落地。