在Dify平台构建能够处理多轮对话的智能系统，核心在于选择正确的应用类型——Chatflow。Chatflow天然具备对话记忆能力，能记住用户上一轮询问的是“第一款笔记本的保修期”，当用户接着问“那第二款呢”时，上下文依然能关联到同一产品线。相比之下，Workflow每轮都是全新会话，如果强行用于客服场景，用户只能反复解释背景信息，导致体验大幅下降。
新建应用时，请务必手动选择【Chatflow】。一旦选错，后续无论怎样配置节点都无法启用对话记忆功能，所有努力都将付诸东流。
以用户提问“你们最新版App支持指纹登录吗？安卓和iOS有区别吗？”为例。真实的处理流程需要拆解为五个步骤：意图识别→知识库检索→相关性校验→分支决策→生成回复。这五步绝不能合并到一个LLM节点中，否则模型很容易混淆“是否支持”和“平台差异”这两个子问题，导致要么遗漏答案，要么编造不实信息。
明确Chatflow与Workflow的根本分界
打开Dify控制台后，第一步就是确认你创建的是【Chatflow】。它内置了sys.conversation_id和Memory节点，能够记住对话历史。Workflow不具备此能力，每次触发都是一次全新会话——如果非要用于客服场景，用户只能反复交代背景，体验极其糟糕。
新建应用时，在“应用类型”下拉菜单中必须手动选择【Chatflow】，选错后将无法启用对话记忆功能，后续所有节点配置都失去实际意义。
拆解任务：从用户一句话到结构化执行路径
第一步：拖入“开始节点”，命名为“用户原始输入”，勾选“启用对话记忆”——这是整个多轮流程的锚点。
第二步：接一个“LLM节点”，提示词写明：“请严格按JSON格式输出：{‘intent’: ‘功能咨询’, ‘keywords’: [‘指纹登录’, ‘安卓’, ‘iOS’]}。不加解释，不补全字段。”这一步的目的是将口语化表达转化为结构化指令，为后续节点提供可编程判断依据。
第三步：用“条件判断节点”接收上一步的JSON，设置规则：当intent == “功能咨询”且keywords包含“指纹登录”时，走“知识库检索”分支；否则走“兜底搜索”分支。注意这里必须使用字段值匹配，不能依赖LLM自由判断，否则稳定性会降为零。
知识检索与相关性双校验机制
方法一：纯向量检索（适合技术文档）
拖入“知识检索节点”，选择已上传的《App功能手册》知识库→设置top_k=3→开启“启用重排序”。BGE-M3模型对中文技术术语召回更精准，但如果你的知识库是客服话术集，BCE-Embedding可能更贴合日常表达。
方法二：混合检索（推荐上线前压测）
先接“向量检索节点”，再接“关键词检索节点”→用“合并节点”将两路结果去重合并→最后经过“重排序节点”。这样做能同时捕获“指纹识别”和“Face ID”这类语义相近但字面不同的表述，避免漏检。
【关键陷阱】不要跳过相关性判断直接喂给LLM。实测显示，未经筛选的知识片段中约37%存在时效偏差（例如引用了已下线的老版本API），直接使用会导致回答错误。必须插入独立的“相关性判断节点”，提示词限定为：“仅输出true或false，判断检索内容是否直接回答‘指纹登录支持情况’，不涉及原因分析。”
动态分支与流式输出配置
① 当相关性判断输出true时，连接至主LLM节点，提示词模板为：“基于以下知识：
② 当输出false时，改走HTTP请求节点，调用Google Custom Search API，query参数拼接为“site:yourdomain.com 指纹登录 Android iOS latest version”。
③ 两个分支最终都接入“回复节点”，务必勾选【启用流式输出】——用户看到文字逐字出现，体验远优于等待3秒后整段弹出，且能随时中断生成。