Agent Memory 21篇论文学习路线 · essay
Agent Memory 21篇论文学习路线
来源主文:一口气读完 agent memory 的 21 篇核心论文
这组笔记的目标不是翻译论文,而是把 Agent Memory 拆成可学习、可比较、可落地的工程知识。每篇拆解都围绕同一条主线:论文要解决什么问题,作者怎样建模记忆,信息如何写入、更新、检索、使用,实验或案例证明了什么,最后怎样迁移到 Personal Knowledge Agent。
本地原文与同步边界
每篇 01 到 21 的拆解笔记顶部都嵌入了本地原文:
代码块收起展开
F:\2. ObsidianNotes\技术栈\AI Agent\essay\paperspapers/ 是本机原文资料目录,已加入 Obsidian vault 的 .gitignore,不会同步到 GitHub 或博客;中文精读笔记会同步。essay/papers/19-Awesome-Multimodal-Memory-README.md 是原始资源清单,不作为本文的二次加工笔记,避免污染来源材料。
重要校正:源文章里 A-MEM 的 arXiv 指向 2409.09908 是错误的;本地使用的是正确论文 2502.12110。
总体框架
Agent Memory 不是单个算法,而是一组围绕“长期状态”的系统能力。
读论文时始终问一个问题:这篇论文是在补上这条链路里的哪一段?
图中 MT 指 Memorizing Transformers,MLLM 指 MemoryLLM,GA 指 Generative Agents,MM 指多模态记忆检索资源。
这张图只负责定位,不承载长解释:横轴回答“记忆藏在模型里,还是放在外部系统里”;纵轴回答“记忆主要是静态召回,还是会在运行中持续更新”。读图时先看象限,再看论文点位,最后回到下面这张工程矩阵判断路线。
| 象限 | 代表论文 | 关键机制 | 工程判断 |
|---|---|---|---|
| 内部更新 | Memorizing Transformer、MemoryLLM、Memory3、WISE、Titans | 参数、hidden state、补丁层、memory token | 研究价值高;工程首版不宜直接押注,因为回滚、权限、审计和污染隔离难。 |
| 外部治理 | MemGPT、Mem0、Zep、A-MEM、MIRIX、MemOS | 记忆对象、图谱、生命周期、命名空间、调度策略 | 最适合作为 Personal Knowledge Agent 的主路线,能做 API、表结构、权限和 trace。 |
代码块收起展开
| 检索增强 | HippoRAG、MemLong、多模态检索资源 | 向量、BM25、图检索、长上下文切片、rerank | 解决“资料很多但找不准”的问题;关键不在存储,而在召回、排序和证据组织。 |
| 经验沉淀 | Generative Agents、Voyager、Reflexion、CoALA | 事件流、反思、计划、技能库、认知分层 | 解决“做过的事如何变成下次策略”;适合落到任务复盘、失败归因和技能复用。 |读 21 篇论文时不要按标题记,而要按象限判断:它修改的是记忆位置、更新方式、检索方式,还是行为复用方式。这个判断会直接影响你后面写 Java 服务时该建表、建图、建队列,还是只做评测和策略层。
论文地图
四条阅读主线
主线一:外部记忆系统
先读 01 -> 05 -> 03 -> 04 -> 06 -> 07。
这条线回答:如果要把 Agent 的记忆做成一个服务,数据结构、API、检索、更新、权限、审计应该怎么设计。
| 问题 | 重点论文 | 你要学会的工程对象 |
|---|---|---|
| 上下文不够放怎么办 | MemGPT | memory page、context scheduler |
| 用户事实怎么长期保存 | MemoryBank、Mem0 | memory item、profile、decay |
| 事实冲突和时间变化怎么办 | Zep | temporal edge、valid time、fact history |
| 记忆之间怎样自组织 | A-MEM | note graph、link、evolution |
| 多 Agent/多组件怎样共享记忆 | MIRIX、MemOS | namespace、capability、policy |
主线二:检索增强记忆
先读 08 -> 21 -> 19。
这条线回答:记忆不只是存下来,还要能在正确时刻被找回来。
| 检索方式 | 解决的问题 | 风险 |
|---|---|---|
| 向量检索 | 语义相似召回 | 召回相似但不关键 |
| BM25/关键词 | 精确词匹配 | 语义泛化弱 |
| 图检索 | 多跳关联 | 构图成本高 |
| 时间过滤 | 新旧事实区分 | 时间字段不准会误导 |
| rerank | 提升最终上下文质量 | 延迟和成本增加 |
主线三:模型内部记忆
先读 11 -> 12 -> 13 -> 14 -> 15。
这条线偏研究,但能帮你理解“为什么大多数工程系统先做外部记忆”。模型内部记忆强在推理融合,弱在可解释、可回滚、可权限控制。
quadrantChart title Agent Memory 方法取舍 x-axis "难治理" --> "易治理" y-axis "弱融合" --> "强融合" quadrant-1 "理想但困难" quadrant-2 "工程主流" quadrant-3 "价值较低" quadrant-4 "研究前沿" "外部 Memory Store": [0.78, 0.48] "RAG 检索": [0.72, 0.42] "知识图谱记忆": [0.64, 0.58] "模型编辑": [0.32, 0.78] "KNN Memory": [0.42, 0.68] "Memory Tokens": [0.28, 0.82]
主线四:经验、反思与技能
先读 09 -> 20 -> 10 -> 18。
这条线回答:Agent 做过一件事之后,怎样把结果变成下一次可用的经验,而不是只留下聊天记录。
| 论文 | 经验如何产生 | 经验如何使用 |
|---|---|---|
| Generative Agents | 从事件流抽取反思 | 反思影响计划和行为 |
| Reflexion | 从失败轨迹生成语言反馈 | 下次任务作为策略提示 |
| Voyager | 成功行为沉淀成技能代码 | 后续任务检索并调用技能 |
| CoALA | 按认知架构分层 | 工作记忆、长期记忆、行动协同 |
推荐学习顺序
如果你目标是做 Personal Knowledge Agent,按这个顺序读:
不要从综述开始死啃。先用工程论文建立对象感,再用综述补全分类。
精读模板
每篇论文至少回答 12 个问题:
| 维度 | 具体问题 |
|---|---|
| 问题 | 这篇论文认为现有 Agent/LLM 缺什么记忆能力? |
| 对象 | 它记的是什么:事实、事件、偏好、技能、参数、模态片段? |
| 写入 | 什么信息会被写入,谁决定写入? |
| 表示 | 记忆是文本、向量、图、代码、token,还是模型权重? |
| 更新 | 新旧记忆冲突、合并、遗忘、失效怎样处理? |
| 检索 | 触发检索的条件是什么,怎样排序? |
| 注入 | 检索结果怎样进入上下文或模型状态? |
| 行动 | 记忆怎样改变回答、工具选择、计划或技能调用? |
| 验证 | 实验到底证明了哪个环节有效? |
| 局限 | 成本、隐私、时效性、冲突、评测有什么问题? |
| 工程 | 如果用 Java/Spring 实现,需要哪些表、服务和任务? |
| 迁移 | 它能为 Personal Knowledge Agent 提供哪个模块? |
工程落地总图
对应 Java 后端模块:
| 模块 | 职责 | 可先实现的最小版本 |
|---|---|---|
MemoryIngestionService | 接收对话、笔记、工具结果 | 保存原始 event |
MemoryExtractionService | 从 event 抽取事实/偏好/任务 | LLM 抽取 JSON |
MemoryStore | 存储记忆对象 | PostgreSQL + pgvector |
MemoryGraphService | 管理实体关系 | 先用关系表,后续换图数据库 |
MemoryRetrievalService | 检索相关记忆 | BM25 + embedding hybrid |
MemoryGovernanceService | 权限、TTL、冲突、版本 | owner、scope、status 字段 |
ContextBuilder | 把记忆放进 prompt | token 预算 + source path |
MemoryEvalService | 评测记忆是否帮到任务 | 固定问题集 + trace 对比 |
最小数据模型
代码块收起展开
// MemoryRecord = 一条可治理的长期记忆。
// 重点不是“存一段文本”,而是让记忆能被检索、更新、审计和删除。
public record MemoryRecord(
String id, // 全局唯一 ID,便于 trace 和更新。
String ownerId, // 记忆归属:用户、项目或组织。
String scope, // user/project/session,决定可见范围。
String type, // fact/preference/task/skill/reflection。
String content, // 记忆正文,给模型或检索器使用。
String source, // 来源:chat、obsidian、tool、paper。
double confidence, // 抽取可信度,低可信记忆不要直接强注入。
long validFrom, // 生效时间,支持时序事实。
Long validTo, // 失效时间,null 表示仍有效。
String status // active/superseded/deleted。
) {}这个模型能覆盖 Mem0、Zep、MemoryBank、Reflexion 的最小交集。先把它做扎实,比一开始追求复杂图数据库更重要。
评测标准
没有评测,记忆系统很容易变成“看起来聪明,实际乱记”。
| 评测项 | 问题 | 证据 |
|---|---|---|
| 写入准确率 | 该记的是否记了,不该记的是否没记 | 抽取样本人工标注 |
| 检索命中率 | 用户问题相关记忆是否被找回 | top-k recall |
| 上下文有效性 | 找回的记忆是否真的改善回答 | A/B eval |
| 冲突处理 | 新事实是否覆盖旧事实 | 时序测试 |
| 隐私与权限 | 项目/用户记忆是否串库 | 权限回归测试 |
| 成本延迟 | 每轮记忆检索是否可接受 | trace 里的 latency/token |
| 可解释性 | 回答能否说明用了哪条记忆 | source id / source path |
读完后的产出
读完 21 篇不应该只留下“我知道很多论文”。应当产出一个可实现的 Personal Knowledge Agent 设计:
- 一张记忆类型表:事实、偏好、任务、反思、技能、资料片段。
- 一个
MemoryRecord数据模型。 - 一个写入策略:什么时候抽取,什么时候拒绝写入。
- 一个更新策略:合并、覆盖、失效、遗忘。
- 一个检索策略:关键词、向量、图、时间过滤、rerank。
- 一个上下文策略:哪些记忆进 prompt,超预算怎么压缩。
- 一套 eval:固定问题、预期记忆、预期引用、失败归因。
这才是这组论文对工程学习的实际价值。