我们真的准备好做"Agent 原生"的记忆系统了吗？——12 个记忆系统的一次硬核体检
一句话先说结论：这篇论文没提出什么新方法，但它干了一件更稀缺的事——把 12 个主流 Agent 记忆系统拉到同一个台子上，用数据库系统的尺子量了个遍，然后告诉你：别再问"哪个记忆系统最好"了，这个问题本身就问错了。
先聊聊我为什么会停下来读这篇
做过 Agent 的人大概都有过这种体验：给模型接上一个"记忆系统"，demo 跑得很漂亮，能记住用户三天前说过的生日。然后你换个场景——让它处理一连串相互依赖的数据库操作，或者跨十几个会话去拼一个事实——它就开始胡言乱语，要么记串了，要么干脆忘了。
更尴尬的是，你想横向比一比到底哪个记忆方案更靠谱，结果发现满世界的评测都在报 F1、BLEU 这种端到端的任务分数。分数是涨了，可你完全不知道为什么涨——是表示层存得好？检索准？还是维护策略对路?整个记忆系统被当成一个黑盒,涨了就吹,跌了也不知道病灶在哪。
这篇 arXiv 2606.24775（《Are We Ready For An Agent-Native Memory System?》）就是冲着这个黑盒来的。它的姿态很有意思——不站在"NLP 评测"的视角,而是站在数据管理这个视角看记忆系统。说白了,作者把 Agent 的记忆当成了一个数据库:有存储、有抽取(写入)、有检索(读)、有维护(更新和淘汰)。既然是数据库,那衡量它就不能只看"查得准不准",还得看运营成本、架构权衡、动态更新下的鲁棒性。
这个切入角度,我个人是真的喜欢。因为它把一个被营销话术裹得严严实实的领域,重新拉回到了工程的地面上。
论文信息
- 标题：Are We Ready For An Agent-Native Memory System?
- 作者：Wei Zhou, Xuanhe Zhou, Shaokun Han, Hongming Xu, Guoliang Li, Zhiyu Li, Feiyu Xiong, Fan Wu
- arXiv：2606.24775（v1, 2026 年 6 月 23 日提交）
- 方向：cs.CL / cs.DB / cs.IR（注意它挂在数据库分类下,这本身就是个信号）
- 代码：https://github.com/OpenDataBox/MemoryData ，分类清单 https://github.com/OpenDataBox/awesome-agent-memory
作者阵容里有做数据库系统出身的研究者，也有专注记忆方向的团队。这个组合恰好解释了论文为什么会从"数据管理"而不是"对话理解"的角度去拆记忆——屁股决定脑袋，但这次决定得挺对。
核心摘要
现有 Agent 记忆系统的评测,普遍只看端到端任务成功率,把底层系统当黑盒。这篇论文提出一个四模块分析框架,把 Agent 记忆拆解成「表示与存储、抽取、检索与路由、维护」四个部分,然后在 5 类工作负载、11 个数据集上系统评测了 12 个代表性记忆系统 + 2 个参考基线。
最有价值的三个结论:其一,没有任何单一架构能在所有场景通吃,有效性取决于记忆结构跟工作负载瓶颈的对齐程度;其二,保留原始内容比堆抽象层次更重要,保守整合比激进压缩更安全——每多一层抽象,就多丢一层信息;其三,局部化维护远比全局重组划算,运营成本的关键不在于用不用结构,而在于每次写入要在结构里传播多远。
这不是一篇会让你学到新 trick 的论文,但它是那种能帮你少踩坑、做技术选型时心里有底的论文。值得花时间细读。
一、把记忆系统拆成四个模块,这事为什么关键
论文做的第一件事,是给 Agent 记忆系统建了一个形式化框架,记作四元组 \(\mathcal{M}_{sys} = \langle \mathcal{R}, \mathcal{S}, \mathcal{Q}, \mathcal{U} \rangle\)。别被符号吓到,它对应的就是记忆生命周期里的四个动作。
下面这张图是全文的地基,展示了四类典型记忆系统的执行工作流——从流式反思、层次分级,到知识图谱、复合混合。
图 1：Agent 记忆的典型执行工作流。不同架构在"信息怎么进来、怎么组织、怎么取出去"这条链路上做了完全不同的取舍。
四个模块拆开来讲:
① 表示与存储（\(\mathcal{R}\)）——记忆长什么样、存在哪。逻辑表示从最简单的 token 序列(离散文本/连续向量),到图与树拓扑(时序知识图谱、层次树),再到异构复合结构(比如 MemOS 的 MemCube)。物理存储则从瞬态的上下文寄存器,到单引擎(向量库/图库/关系库),再到多引擎混合。
② 抽取（\(\mathcal{S}\)）——原始的对话流、工具日志怎么变成记忆条目。三档:原始序列直接拼接、无模式语义抽取(像 Mem0 抽离散事实)、模式约束的结构化抽取(像 Zep 抽实体-关系三元组)。
③ 检索与路由（\(\mathcal{Q}\)）——查询来了,怎么找到相关的那部分记忆。从原生注意力、语义稠密检索(KNN)、拓扑子图遍历,到自主 Agent 路由(函数调用、查询扩展),再到多阶段混合执行。
④ 维护（\(\mathcal{U}\)）——记忆怎么更新、合并、淘汰。包括基于时间戳的多版本管理、容量驱动的物理淘汰、LLM 驱动的语义整合,以及离线的连续参数化优化。
我觉得这个拆法最大的价值,是它让"哪个记忆系统更好"这种含糊的问题,变成了一系列可以分别回答的具体问题:你的瓶颈到底在写入(抽取)、读出(检索)、还是在维护?不同模块的设计,对最终效果的贡献能被单独量化出来。这就是数据管理视角带来的好处——把黑盒拆成可观测的组件。
二、12 个系统同台:领跑者会随着负载切换
论文把 12 个代表性记忆系统按四模块特征做了完整分类(Table 1),大致归为三类:
| 类别 | 代表系统 |
|---|---|
| 序列上下文类 | MemoChat、Mem0、MEM1、MemAgent |
| 结构拓扑类 | MemTree、Zep、Mem0ᵍ、Cognee |
| 多范式混合类 | LightMem、SimpleMem、MemOS、MemoryOS、A-MEM、Letta (MemGPT) |
外加两个参考基线:Long Context 直接长上下文,和 Embedding RAG 向量检索增强。评测覆盖 5 类工作负载:LoCoMo(长对话 QA)、LongMemEval(多会话长记忆)、DB-Bench(数据库操作的过程性执行,来自 LifelongAgentBench)、LongBench(双语多任务长上下文),指标口径部分来自 MemoryAgentBench。
端到端结果直接戳破了一个幻想:没有谁能通吃。 看下面这张主结果图——
图 7：三类工作负载上的端到端有效性。注意领跑者是怎么换人的。
具体数字很说明问题:
- LongMemEval(跨会话事实连接)上,结构感知系统领跑:Zep 拿到 48.0 的 LLM Judge Accuracy,Cognee 的 ROUGE-L F1 达 35.3。
- LoCoMo(长对话精确锚定)上,混合过滤系统最准:MemOS 的 Exact Match 达 11.5。
- DB-Bench(过程性数据库操作)上,保留完整轨迹的方法最强:Long Context 的 EM 达 48.20,MemoChat 的任务成功率高达 55.40。
看出规律了吗?记忆结构必须跟工作负载的瓶颈对齐,这是全文最核心的判断。具体来说:
- 时序/图组织的记忆最适合跨会话聚合和事件顺序推理——比如 LongMemEval 里那些散落在十几个会话中的个人事实,你得把它们"连起来"。
- 摘要优先、由粗到细路由的记忆适合长但语义连贯的对话里做精确锚定——比如 LoCoMo 里要找回某个具体日期。
- 保留完整轨迹的记忆在正确性依赖中间状态变化时是刚需——比如 DB-Bench 里那些相互依赖的 UPDATE 和 INSERT,你压缩掉任何一步,整条执行链就崩了。
这里有个细节特别值得说:在 DB-Bench 上,Long Context 拿了最高的 EM,但 MemoChat 的任务成功率明显更高。这说明什么?EM 这种指标根本捕捉不到"记忆是否真的支撑了任务成功执行"。 你的答案字符串对上了,不代表你这一连串操作真的跑通了。这正是论文反复强调"要超越 Exact Match"的原因。
如果一定要在全负载覆盖里选最接近前沿的,MemoryOS 和 MemOS 整体最稳。但"最稳"不等于"最优",这点后面成本分析会狠狠打脸。
三、消融实验:每多一层抽象,就多丢一层信息
如果说端到端结果告诉你"选型要看场景",那细粒度消融才是这篇论文真正的金矿。它把四个模块逐个拆开,量化每个设计选择的实际代价。
表示层:保留原始内容,比堆抽象更重要
这是 Table 3 的结论,我觉得是全文最反直觉、也最实用的发现之一:
| 方法变体 | LoCoMo EM | LoCoMo Ans.F1 | LongMemEval Substr.EM | ROUGE-L F1 |
|---|---|---|---|---|
| LightMem 仅用户原文 | 24.2 | 38.9 | 26.0 | 31.4 |
| 仅用户摘要 | 8.5 | 15.6 | 11.7 | 17.4 |
| 仅用户压缩 | 23.6 | 38.6 | 10.7 | 19.1 |
| MemTree 偏扁平树 | 18.2 | 30.7 | 23.0 | 29.9 |
| MemTree 更深的树 | 18.7 | 31.2 | 23.3 | 30.9 |
| Mem0 默认 | 3.2 | 6.2 | 9.3 | 16.5 |
| Mem0 图存储 | 3.0 | 6.5 | 8.3 | 15.9 |
盯着第一行和第三行看:同样是 LightMem,把原文换成压缩版本,LongMemEval 的 Substring EM 从 26.0 直接掉到 10.7,腰斩还不止。而对比 MemTree 的扁平树和更深的树——加深树结构,提升微乎其微(23.0 → 23.3)。
结论很硬:你以为的"智能压缩"和"层次组织",在很多场景下其实是在主动丢信息。 原始内容的保真度,比你精心设计的抽象拓扑值钱得多。
抽取层:抽得越细,多跳推理死得越惨
Table 4 接着补刀。直觉上,把对话抽取成细粒度的结构化事实,应该有利于检索吧?数据说:看场景。
| 方法变体 | LoCoMo EM | Ans.F1 | LongMemEval Substr.EM | ROUGE-L F1 |
|---|---|---|---|---|
| MemOS 快速记忆 | 25.5 | 40.8 | 20.7 | 26.1 |
| MemOS 精细记忆 | 2.5 | 5.0 | 22.3 | 30.2 |
| LightMem 仅用户原文 | 24.2 | 38.9 | 26.0 | 31.4 |
| LightMem 混合原文 | 25.5 | 39.7 | 25.3 | 31.4 |
看 MemOS 那两行——精细记忆(Fine Memorize)在 LongMemEval 的词汇级事实检索上确实小涨(20.7 → 22.3),但 LoCoMo 的 EM 从 25.5 暴跌到 2.5。
为什么?因为多跳推理需要的是上下文之间的关联,而细粒度抽取把对话切成一颗颗孤立的事实碎片,关联全断了。抽取的选择性越强,下游可答性损失越大。 更广、更少选择性的抽取,反而保住了回答问题的能力。
检索层:规划有用,但叠加反思就是画蛇添足
Table 5 看检索与路由:
| 方法变体 | LoCoMo Ans.F1 | Recall | LongMemEval Substr.EM | ROUGE-L F1 |
|---|---|---|---|---|
| A-MEM 混合-平衡 | 24.6 | 49.9 | 27.5 | 25.9 |
| SimpleMem 无规划 | 18.7 | 86.4 | 17.0 | 22.9 |
| SimpleMem 仅规划 | 20.7 | 90.6 | 21.7 | 27.9 |
| SimpleMem 规划+反思 | 20.0 | 88.6 | 21.3 | 26.1 |
显式查询规划 + 平衡的混合检索融合,是提升最稳的组合(A-MEM 混合-平衡那一行几乎全面领先)。SimpleMem 加了规划之后,Recall 从 86.4 涨到 90.6。
但请注意最后两行:在规划之上再叠一层反思(reflection),Recall 反而从 90.6 掉到 88.6。额外的推理步骤不但不增益,还可能干扰路由决策。 这个发现挺扎心的——我们总以为"让模型多想想"总是好的,实际上对检索路由这种任务,想多了反而坏事。
下面这张图把检索保真度讲得更透:
图 8：按检索预算(Recall@K)和证据距离分桶的检索表现。SimpleMem 在 Recall@1 上最高(39.0),但 A-MEM 和 MemTree 在更大预算下反超——Recall@5/@10 分别达 69.5/85.9(A-MEM)和 59.7/80.5(MemTree),且随证据距离增加更稳。扁平的 Embedding RAG 过了最短距离桶就急剧跳水。
四、长程稳定性:仅追加的记忆会"灾难性退化"
这部分(RQ4)是我认为对实际工程最有警示意义的。先看图:
图 10:(a) LongBench 上的上下文长度鲁棒性;(b) LongMemEval 上的会话历史增长;(c) LoCoMo 上的时序证据距离漂移。
几个数字触目惊心:
- LongBench 上,SimpleMem 从短上下文到中等几乎不动(35.2 → 34.9),而 Long Context 从 42.6 暴跌到 19.0——长上下文基线在变长时直接崩了一半。
- LoCoMo 上,随着证据距离拉远,Embedding RAG 的 Answer F1 从 37.1 跌到 7.4。而 Cognee、MemOS、MemoryOS 这些图/整合系统保持显著更高。
论文把缺乏生命周期管理的系统返回陈旧事实这个现象,起了个很传神的名字,叫 过去的幻觉,英文是 hallucinations of the past。你的记忆里存着一条早就被更新过的旧事实,系统不知道它过期了,理直气壮地报出来。这不是模型在编,是记忆系统没做好版本治理。
更新鲁棒性方面(Table 2 部分数据):知识更新场景最强的是 Zep(Substring EM 44.4 / ROUGE-L F1 36.8),时序推理最强的是 Cognee(18.7 / 35.8)。图方法在处理动态更新上确实最可靠。
但这里有个反转值得记住:对时间依赖的查询,原始长上下文检索常常还干得过多数记忆方法。原因是——标准的语义整合(把对话压成摘要)经常会破坏掉关键的时间线索。你为了省空间做的摘要,顺手把"什么时候发生的"这个信息给抹了。
五、成本账:贵的不一定值,关键看写入传播多远
终于到了我最想聊的部分。前面 MemOS、Cognee、Zep 这些结构化系统效果很能打,但它们的运营成本呢?这张图直接把遮羞布扯了:
图 11:效用-延迟权衡(左)与跨负载延迟足迹(右)。横轴是每次查询的平均操作延迟,纵轴是归一化效用。
看这组对比(效用 @ 单次操作延迟):
- LightMem:48.3 效用 @ 3.67 秒——又快又能打,稳坐效率前沿。
- MemTree:63.5 效用 @ 15.9 秒——效用更高,延迟可控。
- MemoryOS:82.0 效用,但要 28.6 秒。
- Cognee / Zep:效用都超过 84,但分别要 116.5 秒、155.1 秒。
在 LongBench 工作负载下,分化更夸张:LightMem 只要 17.3 秒,而 Mem0、MemoChat、MemoryOS、A-MEM 分别飙到 374.2、460.2、490.0、552.1 秒。
差出一个数量级还不止。论文给的解释一针见血:运营效率不取决于你用不用结构,而取决于每次写入要在结构里传播多远。
- LightMem 用分段压缩 + 有界混合检索,写入只影响局部 → 便宜。
- MemTree 用路径局部的树聚合,不需要全局刷新就能保住大部分效用 → 性价比高。
- 而图全局整合、多存储同步、反复全量重写记忆的系统,组织能力更强,但随着记忆增长,运营成本压得越来越重。
这就引出了全文的成本结论(O7):最划算的机制,把维护限制在有界的子集里(localized maintenance);反复重组大规模全局状态的机制(global reorganization),效率最低。
说实话,这个结论从数据库的角度看一点都不新鲜——局部更新永远比全表重建便宜。但能在 Agent 记忆这个被各种花哨架构包装的领域,把这条朴素的工程规律量化出来、摆到台面上,我觉得就是这篇论文的价值所在。
最后维护策略的消融(图 12)也印证了同一逻辑:
图 12:保守整合(Conservative-Merge)优于延迟刷新和过度粗化的摘要。MemoryOS 用保守合并时 Ans.F1 从 23.2 微升到 23.5,而延迟刷新直接掉到 20.6。
保守整合(动得越少越好)是最佳默认维护策略;延迟刷新会在"表面覆盖"和"实际可答性"之间制造欺骗性的权衡——看起来记忆覆盖全了,真要答题时却答不出来。
六、那么,我们到底准备好了吗?
回到标题这个问题。论文的回答其实是含蓄的"还没有,但知道该往哪走了"。它提炼出六大洞察,我挑最有信息量的几条:
- 没有通用最优架构——复合混合系统擅长对话 QA,图方法擅长单跳事实召回但在时序推理上吃力。有效性来自"把对的证据保留在对的抽象层级"。
- 检索准确度会随时间距离退化——这是基于相似度检索的根本局限,证据离查询越远,检索越不准。
- 图方法最可靠地处理知识更新,但缺乏生命周期管理的系统会陷入"过去的幻觉"。
- 仅追加型存储会灾难性退化,而语义整合常常破坏时间线索。
- 高度结构化系统的成本高出数个数量级,却未必带来成比例的准确度增益。
- 每层抽象都在丢信息——压缩、摘要、事实抽取,层层递减;保守整合是最佳默认。
所谓"agent-native"的记忆系统,在作者看来应该是这样的:能在合适的抽象层级保留合适的证据、有显式的生命周期管理、保留时序线索、并且把维护成本局部化。
我的判断
先说优点。这是一篇做得很扎实的系统性测量论文,在一个被产品 demo 和营销话术严重污染的领域里,提供了难得的、可复现的横向基准。它最大的贡献不是某个数字,而是那个四模块框架——它给"评测一个记忆系统"提供了一套可分解、可观测的方法论。以后再有人跟你吹某个记忆系统多强,你可以反问一句:你的瓶颈在哪个模块?
几个让我特别认同的判断:保真度优于抽象、保守整合优于激进压缩、局部维护优于全局重组——这三条放到任何数据密集型系统里都成立,论文用 Agent 记忆这个具体场景把它们重新验证了一遍,且给出了量化代价。
再说说我的保留。第一,论文本质上是个 benchmark study,结论偏"诊断"而非"药方"——它告诉你各种架构的病在哪,但没给出一个统一的、更好的设计。这当然不是它的目标,但读完会有种"道理都懂,然后呢"的轻微落空感。第二,5 类负载 / 11 数据集听着覆盖很广,但 Agent 记忆的真实场景(尤其是工具调用密集、多 Agent 协作)其实远比这复杂,DB-Bench 已经是最接近"过程性"的了,我还是觉得评测口径偏静态 QA。第三,所有结论都建立在当前这批系统的具体实现上,记忆方向迭代极快,半年后这张排行榜可能就得重画。
但瑕不掩瑜。如果你正在做 Agent 记忆的技术选型,或者想搞清楚自己的记忆系统到底卡在哪一环,这篇 2606.24775 值得你逐表读完——尤其是 Table 3/4/5 那几张消融表,信息密度极高。它不会给你一个"用这个就对了"的答案,但会让你在做权衡时,心里那杆秤稳得多。
觉得有启发的话,欢迎点赞、在看、转发。跟进最新 AI 前沿,关注我