Agent记忆分层：摘要与检索协同

这道题其实问的是，当对话历史长到几千轮甚至跨天的时候，怎么让[[Agent]]既记得住又反应快。核心矛盾就是大模型窗口有限，推理成本也高，所以不能一股脑全塞进去。我的思路是用**分层记忆加[[混合检索]]**来解耦合。

先说记忆分层。我分成三层：工作记忆、短期记忆和长期记忆。工作记忆就是最近几十轮对话，直接塞进prompt，保证即时连贯性。但满了就得下沉，触发条件可以是token数超阈值或者轮数到上限。下沉到短期记忆，这里我会做两件事：一是增量摘要，每K轮用轻量模型总结发生了什么和用户意图变化；二是提取关键事件，比如决策点、用户确认、任务状态变更。存储格式是带时间戳、摘要、实体和重要性分数。长期记忆就存到[[向量库]]里，对话片段做[[embedding]]，加上元数据比如时间、主题、情绪。另外用户画像、偏好这些结构化数据我会丢到SQL或图数据库里。

检索策略是混合召回。工作记忆直接读最近N轮；短期记忆做语义匹配，把摘要向量化取Top-K；长期记忆多路召回，结合向量相似度、时间衰减和关键词过滤。这里有个技巧：检索时把当前query和近期摘要拼接起来作为查询向量，能显著提升相关性。

更新和刷新机制分几种情况。被动压缩就是工作记忆满时，最旧的内容生成摘要下沉。主动摘要在检测到任务完成或话题切换时立即做，生成章节摘要。短期记忆我设TTL比如7天，但高重要性事件比如用户投诉会标记永久保留。冲突解决很简单，新摘要和旧记忆冲突时，保留时间戳最新的，或者触发澄清对话让用户确认。

举个例子，导航Agent。用户周一规划周末路线，周三继续问，短期记忆里要保留‘规划中’这个状态。长期记忆重点存家、公司、常去地点的POI关联。但实时交通状况不存长期记忆，只存‘用户偏好避开高速’这类规则。

落地风险我得特别提一下。首先是成本权衡，摘要用7B模型，主推理用70B，向量检索用[[HNSW]]索引，召回延迟要控制在50毫秒以内。如果不满足这个延迟，用户会感觉卡顿。另一个坑是短期记忆TTL设太短，高重要性事件丢了，所以上线前我会重点检查重要性打分逻辑。

另外我还想提一个延伸点：当记忆里包含图片、语音等[[多模态]]信息时，怎么统一管理？比如用户发了一张截图问‘这个路况怎么样’，单纯文本摘要会丢信息。我的想法是给多模态内容也生成文本描述存到短期记忆里，但这样会引入[[Hallucination]]风险，描述不准反而误导Agent。这个平衡挺难拿捏的。

所以整体上，我更倾向把记忆管理看作一个分层过滤加动态权衡的系统，而不是一个静态的存储方案。核心就是根据场景选对策略，并且随时监控延迟和召回质量做调整。