Agent 一直在“失忆”？问题不在模型，而在我们根本没做对 Memory

很多 Agent 项目失败，不是模型不行，而是根本没有"记忆系统"。

这两年，"给 Agent 加 memory" 几乎成了共识，向量库、RAG、长上下文、KV cache......工具越来越多，但一个尴尬的现象是：

Agent 依然健忘、反复犯错、前后矛盾，跑久了还会"人格崩坏"。

问题到底出在哪？

最近一篇由 NUS、人大、复旦、北大 等机构联合完成的百页综述

《Memory in the Age of AI Agents》，给了我一个非常工程化的答案：

我们大多数人在做的，并不是 Agent Memory，而只是"信息外挂"。

这篇文章，我不打算复述论文，而是站在工程师视角，讲清三件事：

为什么"向量库 ≠ Agent Memory"
Agent Memory 的系统级抽象应该长什么样
如果你真的要做一个"会成长的 Agent"，架构该怎么设计

一、先说结论：没有 Memory，就没有长期可用的 Agent

在真实工程里，你一定见过这些现象：

Agent 反复问已经问过的问题
已经失败过的策略，下次还是照样走
多轮任务一长，就开始自相矛盾
用户偏好、身份设定，在 session 之间直接蒸发

这些问题不是 prompt 没写好，也不是模型不聪明，而是：

系统没有能力跨时间维持"认知状态"。

换句话说：
Agent 没有活在时间里。

这正是为什么这篇综述直接把 Memory 定位为：

Agent 的基础设施（first-class primitive）

而不是一个"增强模块"。

二、为什么"长 / 短期记忆"这个划分已经过时了？

工程中最常见的说法是：

short-term memory：上下文窗口
long-term memory：向量库

但问题是：

有的"长期记忆"只服务于事实一致性
有的服务于能力成长
有的只在单个任务里作为工作区

它们失败的方式完全不同。

继续用时间维度去切分，只会让架构越来越混乱。于是这篇综述提出了一个对工程师极其友好的统一框架：

Forms -- Functions -- Dynamics

它不问"记多久"，而是问三个更关键的问题：

三、Forms：记忆"放在哪里"？

也就是：系统到底靠什么承载记忆？

1️⃣ Token-level Memory（最常见，也是最容易翻车的）

这就是我们熟悉的：

向量库
文本片段
轨迹日志
结构化记录

它的优势非常工程化：

可读、可查、可改
易于治理
能和工具链集成

但论文明确指出一个现实问题：

Flat memory（简单堆历史）在规模上一定会退化。

所以，真正能跑长期的系统，必然会走向：

结构化（Planar） ：图、表、关系
分层抽象（Hierarchical） ：细节 + 总结并存

👉 向量库只是 Flat Memory 的一种实现，不是终点。

2️⃣ Parametric Memory（写进权重）

这是把经验"内化"成模型参数：

finetune
adapter
policy head

优点是快、直接、无需检索；

缺点同样致命：

成本高
不可审计
难以精确修改

👉 它更像"长期沉淀层"，而不是日常记忆系统。

3️⃣ Latent Memory（隐状态里的记忆）

记忆存在于：

隐状态
连续表示
memory tokens

它介于外部存储和参数内化之间，

适合高频更新、多模态场景。

但工程上要清楚：

它几乎不可解释，只适合"机器自己用"。

四、Functions：记忆"到底干什么用"？

这是全文对工程最有价值的抽象 。论文不再按时间，而是按功能失败模式，把 Agent Memory 分成三类。

1️⃣ Factual Memory：让 Agent 记住"世界是什么样的"

这是一个可治理的事实层：

用户偏好
环境状态
代码库结构
工具返回结果

如果你做过复杂 Agent，一定知道这个痛点：

事实一旦散落在历史对话里，就会被忘、被误引、被编造。

Factual Memory 的价值就是：

把"可核查的世界状态"从上下文中解放出来。

2️⃣ Experiential Memory：让 Agent 真正"吃一堑长一智"

这是最容易被忽略、但最像"智能"的一类记忆。

它关注的不是"发生了什么"，而是：

哪些策略有效
哪些路径是坑
哪种解法在什么条件下可复用

论文把它拆成三层：

Case-based：原始轨迹
Strategy-based：抽象方法
Skill-based：可执行能力

👉 有没有 strategy / skill memory，是区分"Agent"和"带历史的 LLM"的分水岭。

3️⃣ Working Memory：让 Agent 在单个任务里不被信息淹没

这不是"短期记忆"，而是注意力管理：

面对超长文档
面对复杂 DOM
面对多工具输出

Working Memory 的职责是：

压缩
折叠
抽象
裁剪

👉 本质上，它是一个推理资源调度模块。

五、Dynamics：为什么你的 Memory 存了却"没用"？

这是很多 Agent 项目真正失败的地方。

论文明确指出：

Memory 不是一个模块，而是一个闭环系统。

完整生命周期是：

复制代码

形成（Formation）
 → 演化（Evolution）
 → 检索（Retrieval）
 → 决策
 → 反馈
 → 再形成

关键工程启示只有一句话：

没有进入决策回路的 Memory，等于不存在。

很多系统的问题不是没存，而是：

检索触发策略不对
取回内容没被 Planner 真正使用
没有 evolution，记忆逐渐腐化

六、下一代 Agent Memory，会往哪走？

论文最后给出的判断非常明确：

从 Retrieval → Generation
- 不只是取旧文本，而是生成"更可用的抽象记忆"
从手工规则 → 自动管理
- Agent 自己决定什么时候写、写什么、删什么
从 Pipeline → RL-driven Control
- 记忆操作成为可学习策略的一部分

这意味着一个重要转变：

Memory 正在从外挂，变成 Agent 能力的一部分。

七、给工程师的一句话总结

如果你只记住一句话，那就是：

Agent Memory 不是"存得久"，
而是"存得对、取得到、用得上、还能进化"。

当你把 Memory 当成系统级能力 来设计，而不是一个检索插件时，

你做的，才是真正意义上的 Agent。

如果你也在做 Agent 系统，希望它能跑得久、学得会、行为稳定，那请认真对待 Memory ------ 它不是锦上添花，而是地基。