16. Memory in the Age of AI Agents:Agent Memory 的大一统综述

论文:Memory in the Age of AI Agents: A Survey Forms, Functions and Dynamics
本地原文:

![[papers/16-Memory-Age-AI-Agents-2512.13564.pdf]]

论文定位与阅读路径

核心定位

这是一篇很大的 Agent Memory 综述。它的价值不是提出某个新算法,而是给你一个总框架:从“记忆由什么承载”“记忆为什么存在”“记忆如何形成和演化”三个维度理解所有记忆系统。

如果你只想记一句:

Forms 讲记忆放在哪里,Functions 讲记忆用来干什么,Dynamics 讲记忆如何变化。

为什么这篇适合作为总图

前面 1-15 篇各讲各的:

• MemGPT 讲上下文和外部存储。
• Zep 讲时序知识图谱。
• Voyager 讲技能库。
• MemoryLLM 讲模型内部记忆池。
• Titans 讲测试时学习。

这些论文术语很多,容易乱。第 16 篇综述就是把它们放到一个坐标系里。

原文结构导读

证据链阅读

方法框架与核心机制

三维框架总览

mindmap
  root((Agent Memory))
    Forms
      Token
      Parameter
      Activation
      External Storage
      Structured Memory
    Functions
      Factual
      Episodic
      Procedural
      Working
      Reflective
    Dynamics
      Formation
      Consolidation
      Update
      Retrieval
      Forgetting
      Governance

第一维:Forms,记忆由什么承载

Forms 问的是:

记忆到底放在哪里?

学习者视角:

文本记忆：写在纸上。
参数记忆：背进脑子里。
激活记忆：正在脑子里想的中间状态。
外部存储：文件柜/数据库。
结构化记忆：整理好的知识地图。

第二维:Functions,记忆用来干什么

Functions 问的是:

Agent 为什么需要这段记忆?

这比“短期/长期”更精确。因为一段记忆可以长期保存,但功能上是程序性记忆;也可以短期存在,但功能上是工作记忆。

第三维:Dynamics,记忆如何变化

Dynamics 问的是:

记忆从哪里来,怎么变,怎么被用,什么时候消失?

这是做 Agent 工程最有用的一维。

用三维框架定位前面论文

这样你就不会把所有 Memory 都看成“向量库”。

工程映射与实践启发

这篇对工程最有用的部分

如果你要做 Personal Knowledge Agent,最重要的是把 memory pipeline 拆出来:

对应后端模块:

局限、对比与阅读检查

初学者最容易混的点

1. Memory 不等于 RAG

RAG 通常查的是外部静态资料。Agent Memory 更强调动态积累、更新、遗忘和个性化。

2. 长上下文不等于长期记忆

长上下文只是一次能塞更多内容。长期记忆要能跨会话保存和管理。

3. 参数知识不等于 Agent 记忆

模型预训练知识是静态的。Agent 记忆是运行中产生的、和用户/任务相关的动态知识。

4. 保存一切不是好记忆

真正的记忆系统要会选择、压缩、合并和遗忘。

前沿方向

这篇综述里值得你后续追的方向:

概念校准

你自己的学习系统也有三维:

1. 笔记写在哪里:纸质本、Obsidian、脑子里。
2. 笔记用来干什么:背概念、记错题、做项目流程。
3. 笔记怎么变:新建、合并、复习、删掉、更新。

Agent Memory 也是同一套逻辑,只是对象换成 AI Agent。

局限与边界

1. 综述很大,容易读完觉得什么都懂一点但没有落地。
2. 术语多,不要一开始就追所有引用。
3. 它提供地图,不提供单个系统的完整实现。
4. 部分前沿方向还没有成熟工程方案。

阅读检查清单

1. Forms/Functions/Dynamics 三维框架。
2. 为什么短期/长期分类不够用。
3. 如何把不同论文放进同一个坐标系。
4. 做 Agent 工程时 memory pipeline 应该有哪些模块。
5. 后续读论文时用这三问定位:放在哪、干什么、怎么变。

深度精读:用 Forms/Functions/Dynamics 反推系统设计

1. 这篇综述最有价值的是“坐标系”

读综述最怕变成“论文名单”。这篇真正有用的是三维坐标:

Form: 记忆由什么承载
Function: 记忆服务什么能力
Dynamics: 记忆如何变化

以后看到任何 memory 论文,你先放进这个坐标系,就不会乱。

2. 为什么短期/长期分类不够

短期/长期只描述保存时间,但不能描述作用。

例子:

“当前正在扩写第 16 篇” 是短期工作记忆。
“用户喜欢深度讲解” 是长期偏好记忆。
“怎么扩写论文笔记” 是长期程序性记忆。
“刚才哪个 patch 失败” 是短期情景记忆。

你看,时间维度和功能维度是两件事。

3. Form 维度对应工程存储选型

综述不是让你全做,而是让你知道每种形态适合什么。

4. Function 维度对应业务对象

你的 Personal Knowledge Agent 可以这样拆:

如果只用一个 memory 字段存全部,后续检索一定混乱。

5. Dynamics 维度对应服务接口

Formation -> extractMemory()
Consolidation -> summarizeAndMerge()
Update -> updateOrInvalidate()
Retrieval -> searchMemory()
Forgetting -> decayOrArchive()
Governance -> auditAndAuthorize()

这已经是一套后端 service 设计。

6. 用这篇综述做系统蓝图

你可以把这张图当成后续项目架构草图。

7. 读 Resources and Frameworks

这一节不要当目录扫过去。你要从里面建立 benchmark 意识:

1. 长对话记忆测什么。
2. 多跳记忆测什么。
3. 时间变化测什么。
4. 用户个性化测什么。
5. 事实更新测什么。

没有评测,memory 系统就是玄学。

8. 前沿方向怎么选

对你当前阶段,优先级如下:

这能避免你被所有方向同时拉扯。

论文精读主线:问题-方法-验证-局限-启发

1. 核心结论

这篇综述用 Forms、Functions、Dynamics 三维框架给 Agent memory 建坐标系,帮助判断记忆由什么承载、服务什么功能、如何随时间变化。

本篇的阅读重心是:用 Forms、Functions、Dynamics 给 Agent memory 建立统一坐标系。读完后要能说清它改变的是 runtime、存储、检索、更新还是评测层;否则只是记住了论文名。

2. 问题背景

Agent memory 领域术语混乱:短期/长期、episodic/semantic、RAG、cache、profile、skill 都被叫 memory。没有统一坐标系,很难比较论文,也很难设计系统边界。

把问题具体化为失败样例:讨论记忆时只说“加个 memory”,却分不清承载形态、服务功能和更新动态,导致系统设计混乱。用这个样例反推论文动机,比泛泛说“上下文不够”或“记忆不准”更有判断力。

3. 核心方法

综述把记忆拆成三个维度:Forms 关注记忆载体,Functions 关注记忆用途,Dynamics 关注记忆如何写入、更新、遗忘和共享。用这三维可以重新定位已有方法。

flowchart TD
    M[Agent Memory] --> F[Forms: 承载形态]
    M --> U[Functions: 功能用途]
    M --> D[Dynamics: 变化机制]
    F --> S[存储选型]
    U --> A[业务能力]
    D --> L[生命周期接口]

方法部分按数据流读:先判定记忆 form,再说明服务的 function,最后定义 dynamics:写入、衰减、合并、遗忘和治理。每一步都要能标出输入、输出、控制点和失败后该记录的日志。

4. 技术细节

Forms 对应工程存储,Functions 对应服务接口,Dynamics 对应生命周期。比如 Obsidian Markdown 是 form,帮助长期学习是 function,自动更新和版本控制是 dynamics。

final class MemoryDesignChecklist {
    private final FormClassifier formClassifier; // 判断记忆是文本、图、技能、多模态还是模型内部状态
    private final FunctionMapper functionMapper; // 把记忆映射到问答、规划、个性化、反思等用途
    private final DynamicsPolicy dynamicsPolicy; // 定义写入、更新、遗忘、共享和删除规则
    private final ArchitectureReviewer reviewer; // 用三维框架审查系统是否缺层

    MemoryResult handle(MemoryInput input) {
        // 1. 判断记忆是文本、图、技能、多模态还是模型内部状态
        // 2. 把记忆映射到问答、规划、个性化、反思等用途
        // 3. 定义写入、更新、遗忘、共享和删除规则
        // 4. 用三维框架审查系统是否缺层
        // 输出中保留 traceId、sourceIds、decisionReason，方便复盘和回滚。
        return MemoryResult.withTrace(input.traceId());
    }
}

字段检查重点是 form、function、dynamics、accessPolicy、updateRule 可直接变成设计评审字段。这些字段不是装饰,它们决定后续能否检索、审计、回滚、限权和做离线评测。

5. 实验验证

综述不靠单一 benchmark 证明,而是靠分类是否解释已有工作、是否揭示空白、是否能指导新系统设计。读它时应把 21 篇论文逐篇放进三维坐标,检验框架是否有用。

实验阅读重点:综述不靠单一指标;要看这个分类能否解释已有系统,并帮助发现你设计里的缺口。如果论文没有直接给出这层证据,复现时就要自己补机制级指标。

6. 局限与启发

框架抽象强,不能替你实现检索或写入。启发是把它当总图:每新增一种记忆,都问 form/function/dynamics 三个问题,避免只因为技术流行就加模块。

迁移到你的项目时,结论是:以后评审自己的 Agent,不要先问用什么库,先问每条记忆是什么形态、用于什么功能、怎样变化。先把边界做对,再追求更复杂的模型或更大的记忆规模。

7. 关键术语表

8. 复现难点

最容易把框架当名词表。真正使用时,要把每个维度落到接口和字段。例如 dynamics 必须变成 update/delete/expire/share API,而不是一句“支持动态记忆”。

复现入口应从失败集开始:把 21 篇论文逐一映射到三维表格,若某篇放不进去,说明框架或你的理解需要修正。只有先证明旧方案会坏,才知道新机制是否真的解决了问题。

9. 代码框架建议

为每个 memory module 写一张设计卡:form、function、writeTrigger、updatePolicy、deletePolicy、owner、riskLevel、evalMetric。没有填完不允许进入实现。

代码验收门槛:任何 memory feature 提案都要填三列:形态、功能、动态;填不清就不进入实现。这条门槛应写进测试或 trace 字段里,避免实现只停留在 demo。

10. 相关论文对比

它和 Agent Memory Survey 都是总览,但这篇更强调概念坐标;CoALA 更强调认知架构;MemOS 更强调系统资源治理。

横向比较时抓这个角度:这篇是元框架,MemOS 是治理实现,CoALA 是认知架构,Agent Memory Survey 是研究地图。比较对象不是谁“更先进”,而是谁负责哪一层失败。

11. 批判性思考

综述的价值在清晰,不在直接效果。缺点是抽象容易让人以为所有记忆都必须实现。工程上应该按任务需要选择最少记忆形态。

批判边界:分类框架的风险是看起来完整但不产出实现;必须落到接口、字段、评测和失败样例。这不是否定论文,而是把论文结论放回真实系统的成本、权限和恢复约束里。