Agent 长期记忆架构与更新策略
存储检索架构、更新策略及与大模型协同方式详解
原题:在AI Agent系统中,长期记忆机制对于维持用户交互一致性至关重要。请设计一种可行的长期记忆存储与检索方案,说明其架构组成、更新策略及与大模型的协同方式。
Agent · 字节真题
30 秒回答
- 区分短期记忆与长期记忆的层级设计
- 支持多维度检索的记忆存储结构
- 增量更新与定期总结的更新策略
- 记忆注入大模型的上下文管理机制
回答与解析
答案要点
- 区分短期记忆与长期记忆的层级设计
- 支持多维度检索的记忆存储结构
- 增量更新与定期总结的更新策略
- 记忆注入大模型的上下文管理机制
- 解决记忆冲突与遗忘的优先级策略
架构组成:三层记忆体系
1. 工作记忆(Working Memory)
- 当前对话窗口的原始上下文
- 直接送入大模型的标准输入
2. 短期记忆(Short-term Memory)
- 最近N轮对话的完整记录
- 按时间序列存储,支持快速回溯
3. 长期记忆(Long-term Memory)
- 用户画像:偏好、习惯、人口属性(结构化存储)
- 事件记忆:重要交互片段(向量化存储)
- 知识记忆:用户专属知识(可结合RAG)
存储与检索设计
存储层
| 类型 | 存储方式 | 示例 |
|---|---|---|
| 用户画像 | 关系型/文档数据库 | JSON格式,支持原子更新 |
| 事件记忆 | 向量数据库 + 元数据 | 摘要向量 + 时间戳 + 主题标签 |
| 原始对话 | 对象存储 | 压缩归档,用于总结生成 |
检索策略
- 多路召回:向量相似度 + 时间衰减 + 主题标签过滤
- 重排序:用轻量模型对候选记忆打分,取Top-K
- 动态窗口:根据当前话题相关性调整记忆权重
更新策略
实时更新
- 每轮对话后提取关键信息(用LLM或规则)
- 增量写入短期记忆,异步更新长期记忆
定期总结
- 对话结束后触发总结任务,生成"会话摘要"
- 周期性(如每周)聚合摘要,更新用户画像
冲突处理
- 时间戳优先:新记忆覆盖旧记忆
- 置信度机制:模型输出置信度,低置信度标记待确认
与大模型协同
输入 = 系统提示 + 检索到的长期记忆 + 短期记忆 + 当前用户输入
记忆注入技巧
- 用特殊标记区分记忆来源,如
[用户偏好: ...] - 控制记忆长度,避免淹没当前上下文
- 敏感记忆(如用户纠正过的错误)高亮处理
口语版讲法(约4分钟)
- 长期记忆本质是跨会话的上下文管理
- 三层记忆架构与各自的存储方式
- 检索策略:多路召回加轻量重排
- 更新策略:实时增量与定期总结结合
- 记忆注入大模型的技巧与风险
这道题问的是长期记忆,其实本质上是问怎么把大模型从单轮对话的“近视”状态,变成能跨会话感知用户上下文。很多团队做Agent,短期记忆靠窗口,长期记忆就简单存个用户画像,但实际落地你会发现,光存画像不够,用户行为是动态的,需要一套分层方案。
我倾向于把记忆分成三层。第一层是工作记忆,就是当前窗口的对话上下文,直接送进模型。第二层是短期记忆,存最近几轮完整的对话记录,按时间序列存,方便回溯。第三层才是长期记忆,这里又可以细分成三类:用户画像,用结构化数据存,比如偏好、习惯;事件记忆,用向量存重要交互片段,比如用户投诉过某个功能;知识记忆,用户专属的知识,可以结合 RAG 来搞。
具体存储上,用户画像我倾向用关系型或者文档数据库,支持原子更新。事件记忆必须用 Vector Database,同时带上元数据,比如时间戳、主题标签,不然纯向量检索容易跑偏。原始对话压缩归档,定期拿来生成摘要。
检索这块,我不会只用向量相似度。因为用户话题可能漂移,时间越久越不重要。所以我会做多路召回:向量相似度、时间衰减、主题标签过滤,三条路一起走,然后拿一个轻量模型做 重排,比如 Cross-Encoder 打分,取Top-K。这里有个坑:如果召回太多,重排成本会很高,所以我会先粗筛,控制候选数在几十条以内。
更新策略分实时和定期。实时更新:每轮对话后,用LLM或者规则提取关键信息,增量写到短期记忆,异步更新长期记忆。定期总结:对话结束后触发一个总结任务,生成会话摘要;周期性比如每周,聚合摘要更新用户画像。冲突处理上,我倾向于时间戳优先,新覆盖旧。但如果模型对某个信息的置信度低,我会标记成待确认,不直接覆盖,避免把用户随口一说当作真实偏好。
和大模型协同的方式,就是把记忆拼到输入里。我会用特殊标记区分来源,比如[用户偏好:喜欢简洁回复],让模型知道这是长期记忆。同时控制记忆长度,如果太长,我会先摘要再注入,避免淹没当前上下文。敏感记忆,比如用户纠正过的错误,我会高亮处理,让模型优先参考。
这里其实有个更底层的取舍:长期记忆的更新频率和检索延迟之间怎么平衡。如果用户每句话都实时更新向量库,写入压力会很大;但如果延迟更新,又可能错过关键信息。我倾向的做法是,对高频但低价值的信息做缓冲区,批量写入;对关键事件,比如用户明确表达不满,就立即写入并触发重索引。这个缓冲区的策略,其实跟数据库的写缓冲有点像,但具体阈值怎么设,得看业务场景。
所以整体来说,我不会把长期记忆当成一个静态的数据库,而是看作一个动态的上下文管理问题。核心是分层的架构、多路检索、以及和模型输入的无缝拼接。落地时我会特别关注检索延迟和记忆一致性,如果这两点没保障,记忆再多也是噪音。
关键一句:长期记忆更新频率与检索延迟的平衡,高频低价值信息用缓冲区批量写入,关键事件立即写入并触发重索引。
面试官还可能这样问
- 问法 1 · 场景切入
假设你做一个长期使用的个人助手,用户今天说‘我喜欢吃辣’,下周问‘推荐个餐厅’,你怎么让助手还记得上次的口味偏好?具体记忆怎么存、怎么取、怎么跟模型配合?
- 问法 2 · 层层追问
Agent的记忆你一般怎么管理?……历史对话多了全塞进去肯定不行……那怎么筛选出真正有用的长期记忆?……如果要让记忆能跨会话、跨天生效,你的存储和检索架构怎么设计?
- 问法 3 · 直球架构
请设计一个AI Agent的长期记忆方案:包括存储结构、更新策略、以及如何把记忆注入到大模型的上下文中。重点说清三层记忆体系的划分、多路检索的流程、和增量更新的时机。