为什么企业级问答需要更聪明的路由机制在构建企业级智能客服或内部知识助手时我们常遇到一个痛点用户的问题五花八门。有些是关于公司制度、产品参数的“内部知识”有些则是关于天气、新闻或通用常识的“外部问题”。如果只用单一的知识库检索RAG遇到知识库没有的内容时模型往往会强行编造幻觉或者生硬地回答“我不知道”体验极差。传统的“聊天助手”模式往往是一条路走到黑缺乏灵活的判断能力。而 Dify 的Chatflow对话工作流正是为了解决这类复杂逻辑而生。它允许我们通过可视化的方式像搭积木一样设计对话的“大脑”。今天我们就从零开始利用 Dify Chatflow 搭建一个具备“智能路由”能力的 RAG 应用它能先判断问题是否属于私有知识范畴若是则精准检索内部文档若否则自动调用外部搜索引擎确保每一个回答都准确可靠。Chatflow 与工作流的核心优势在动手之前有必要厘清为什么我们要选择 Chatflow 而不是普通的“聊天助手”或Agent。普通的聊天助手适合简单的单轮问答逻辑线性难以处理复杂的条件判断。Agent虽然具备自主规划能力但在企业场景中其不可控的“黑盒”决策有时会导致流程偏离预期。相比之下Chatflow提供了可视化编排的能力它将对话过程拆解为一个个明确的节点Node。Chatflow 的核心优势在于确定性与上下文管理。确定性控制你可以精确指定在什么条件下走哪条路径。比如“只有当用户询问内部政策时才检索知识库”这种逻辑在 Chatflow 中可以通过“条件分支节点”完美实现。多轮对话记忆Chatflow 内置了sys.conversation_id和sys.query等变量天然支持多轮交互中的状态保持非常适合需要追问细节的客服场景。混合增强它能够轻松串联“知识库检索”、HTTP 请求调用外部 API”、JSON 解析”等多种能力实现内外网信息的无缝融合。对于企业级应用这种“可观测、可控制”的流程编排是保证服务质量的关键。第一步初始化 Chatflow 应用登录 Dify 控制台进入【工作室】页面。点击“创建空白应用”在类型选择弹窗中务必选择Chatflow注意不是 WorkflowWorkflow 更适合一次性批处理任务而 Chatflow 专为多轮对话设计。填写应用基本信息名称企业智能问答助手描述基于私有知识库与外部搜索的智能路由系统图标选择一个代表智慧或连接的图标创建成功后你将进入可视化的画布界面。默认会有一个“开始”节点和一个“结束”节点。我们的目标是在这两者之间构建一套完整的判断与执行逻辑。核心架构智能路由的设计思路要实现“聪明”的回答核心在于路由策略。我们不能让用户的问题直接冲向知识库而是要在中间加一道“安检门”。整体流程设计如下用户提问接收用户的自然语言输入。意图判断LLM 节点让大模型充当“分类器”分析用户问题是否与我们的私有知识库相关。结果解析JSON 解析节点将 LLM 的判断结果结构化提取出布尔值True/False。条件分支If/Else 节点根据解析结果分流。分支 A相关进入知识库检索节点获取内部文档片段由 LLM 生成回答。分支 B不相关进入 HTTP 请求节点调用外部搜索引擎 API获取网络信息由 LLM 整合回答。最终输出无论走哪条路最终都将生成的答案返回给用户。这种设计确保了“内行问内行外行问外行”极大降低了幻觉率。节点详解一构建意图判断器流程的第一个关键节点是LLM 节点我们将其命名为“意图分类器”。它的作用不是回答问题而是判断问题的属性。在配置该节点时提示词Prompt的设计至关重要。我们需要明确 instruct 模型只输出标准的 JSON 格式不要包含任何多余的废话。System Prompt 示例你是一个意图分类助手。请分析用户的输入问题判断其是否与企业内部知识库包含公司制度、产品手册、技术文档相关。 如果问题涉及公司内部信息返回 {related: true} 如果问题是通用常识、新闻、天气或与内部知识无关返回 {related: false}。 严禁输出任何 Markdown 标记或额外解释仅输出纯 JSON 字符串。User Prompt 示例用户问题{{#sys.query#}}这里利用了 Chatflow 的内置变量sys.query它代表用户当前的输入。通过这样的设定LLM 会像一个守门员一样给每个问题打上标签。节点详解二结构化解析与条件分支LLM 输出的虽然是 JSON 字符串但在工作流引擎中它目前还只是一个文本。为了让后续的“条件分支节点”能够识别我们需要使用JSON 解析节点。新建一个 JSON 解析节点连接在“意图分类器”之后。输入变量选择上一步 LLM 节点的输出文本。解析 schema定义我们需要提取的字段。在这里我们只需要一个布尔值字段键名为related。解析完成后工作流就能识别出true或false的状态了。接下来就是核心的条件分支节点If/Else。配置分支逻辑条件 1Internal Knowledge当json.related等于true时走此分支。条件 2External Search当json.related等于false时走此分支。这就形成了两条并行的处理路径实现了真正的智能路由。节点详解三内部知识库检索配置进入“相关”分支我们需要配置知识检索节点。这是 RAG 应用的核心。关联知识库在节点设置中勾选你预先上传并清洗好的企业知识库如 PDF 格式的员工手册、Word 格式的产品规格书等。检索参数调优检索模式建议选择“混合检索”Hybrid Search结合关键词匹配与向量语义相似度提高召回率。Top K设置为 3-5 条。过多的上下文可能会干扰模型过少则可能信息不足。阈值Score Threshold设为 0.6 左右。如果相似度低于此值说明知识库中没有强相关内容避免强行引用。Rerank 模型强烈建议开启重排序Rerank。Dify 支持接入 Jina AI 或其他 Rerank 模型。它会对初步召回的文档片段进行二次精细排序确保最相关的片段排在前面显著提升回答质量。检索到的内容会自动注入到上下文变量中通常为#context#。随后连接一个LLM 节点用于生成最终回复。生成节点 Prompt 示例请依据以下检索到的内部资料回答用户问题。如果资料中没有提及请诚实告知不要编造。 参考资料{{#context#}} 用户问题{{#sys.query#}} 回答风格专业、简洁、符合企业规范。节点详解四外部搜索 API 集成进入“不相关”分支既然知识库帮不上忙我们就转向外部世界。这里需要使用HTTP 请求节点来调用第三方搜索引擎 API如 Bing Search API、Google Custom Search 或 Serper 等。配置请求方法POST 或 GET视具体 API 而定。URL填入搜索引擎的 API 端点。Headers添加认证信息如Ocp-Apim-Subscription-Key: YOUR_API_KEY。Body/Params将用户的查询{{#sys.query#}}作为搜索关键词传入。处理响应 搜索引擎返回的通常是复杂的 JSON 数据。我们需要再用一个JSON 解析节点或代码节点从返回结果中提取出摘要信息Snippet或标题链接。例如提取前 3 条搜索结果的文本内容。生成回复 最后同样连接一个LLM 节点。生成节点 Prompt 示例用户的问题超出了内部知识库范围。请根据以下网络搜索结果进行总结回答。 网络信息{{#search_results#}} 注意请注明信息来源并保持客观中立。通过这种方式即使面对知识库之外的突发新闻或通用百科问题你的应用也能给出有据可依的回答而不是冷冰冰的“我不知道”。调试与发布确保流程闭环在完成所有节点连接后不要急着发布。利用 Dify 右侧的预览与调试面板进行测试。测试用例 1内部问题输入“公司的年假制度是怎样的”观察运行轨迹应命中“意图分类器” -related: true- 进入“知识检索” - 输出基于文档的回答。测试用例 2外部问题输入“今天北京的天气如何”观察运行轨迹应命中“意图分类器” -related: false- 进入HTTP 请求” - 调用搜索 API - 输出基于网络的回答。如果在调试中发现 LLM 判断失误例如把内部产品名当成了通用词可以微调“意图分类器”的 Prompt增加 Few-Shot少样本示例告诉模型哪些词属于内部范畴。确认流程无误后点击右上角的发布按钮。你可以选择将其发布为 Web 应用直接分享给团队成员使用也可以获取 API 密钥嵌入到企业的 OA 系统或钉钉/飞书机器人中。结语通过 Dify Chatflow我们不仅仅是在做一个问答机器人而是在构建一个具备“思考能力”的业务系统。利用条件分支和智能路由我们将私有知识的深度与公共信息的广度完美结合。这种架构不仅解决了传统 RAG 容易幻觉的痛点还为企业后续扩展更多功能如对接 CRM 系统、自动工单创建等留下了充足的接口空间。技术的价值在于解决实际问题。当你看到用户不再因为“查不到”而 frustration而是得到精准、分层的解答时这套可视化工作流的价值便得到了最好的体现。现在你可以打开 Dify尝试搭建属于你的第一个智能路由应用了。