dify中ai追问接口名说明st-lt记忆未配置，需启用混合记忆、设stm窗口14～18轮并开启智能token裁剪，绑定ltm知识库（内置或外部），通过正则触发高价值实体写入。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
当用户在Dify中连续追问12轮以上技术细节时，AI突然问“您之前提到的接口名是什么”，说明短时记忆已溢出、长期记忆未生效——这不是模型能力问题，而是ST-LT Memory机制未正确配置。
启用并区分短时与长时记忆开关
进入Dify工作流编辑页，点击目标LLM节点右侧「记忆」面板→打开顶部蓝色「启用记忆」开关→在下方展开「高级配置」区域。
找到「记忆类型」下拉菜单，【必须选择“短时+长时混合”而非单选任一】；若只开短时记忆，跨会话信息无法留存；若只开长时记忆，当前对话轮次间连贯性会断裂。
确认两项子开关均处于开启状态：短时记忆（STM）控制当前会话内上下文滚动加载，长时记忆（LTM）触发知识库检索与写入。
配置短时记忆窗口与裁剪策略
在STM设置区，将「记忆窗口大小」滑块拖至14～18轮之间。这个数值不是凭经验设定的——它需匹配你所用模型的上下文上限：GPT-4 Turbo（128K）可设至25轮，而Qwen2.5-7B（32K）建议不超过12轮。
勾选「启用智能Token裁剪」。这一步很关键：Dify不会简单按轮次丢弃最旧消息，而是调用model_instance.get_llm_num_tokens()逐条计算真实Token占用，从最早一轮开始剔除，直到总Token数≤（模型上限－预留响应空间500 Token）。
不勾选此项会导致：中文对话中每轮平均120字≈180 Token，14轮即2520 Token，但若某轮含大段代码或日志，单轮就占2000 Token，系统仍会强行保留全部14轮，直接触发模型超限报错。
绑定长时记忆知识库并设置检索规则
方法一：使用内置知识库作为LTM后端
在LTM设置区，点击「选择知识库」→从下拉列表中选取已创建的用户档案库或事件图谱库。该知识库必须已完成文档上传与向量化索引，否则检索返回空结果。
设置「检索Top-K」为3～5，「相似度阈值」调至0.65。阈值过低（如0.4）会召回大量噪声片段；过高（如0.85）则关键信息可能被过滤掉——实测0.65在客服类对话中召回准确率与覆盖率平衡最佳。
方法二：对接外部向量数据库（如Milvus）
切换至「自定义向量库」模式→填写API Endpoint、API Key及Collection名称→测试连接成功后，在「元数据过滤」栏输入user_id == "${user_id}"，确保每次只检索当前用户专属记忆。
【注意：此处user_id变量必须已在会话初始化时由前端传入，且字段名与知识库元数据schema严格一致，否则过滤失效】
编写记忆写入触发逻辑
第一步：在LLM节点下游添加「条件分支」节点，判断响应中是否包含新事实类语句。
第二步：配置判定规则为正则表达式：/我叫|我的地址是|过敏源是|订单号[0-9]{5,}/i，覆盖姓名、地址、健康禁忌、订单标识等高价值实体。
第三步：分支「满足条件」路径接入「知识库写入」节点→选择同一知识库→将提取出的实体文本构造成标准chunk格式：{"content": "用户张伟，地址北京市朝阳区建国路8号，花生过敏", "metadata": {"user_id": "${user_id}", "timestamp": "${now()}"}}。
第四步：设置chunk embedding策略为「句子级分块」，禁用「段落合并」。长段落合并会导致过敏源和地址混在同一向量中，后续检索时易发生语义漂移——比如搜“花生”却召回含“北京”的无关chunk。
