Agent Memory 不只是 RAG：一套数据系统视角的评测

一句话讲清楚

这篇论文想回答的问题不是“给 agent 加记忆有没有用”，而是：如果把 agent memory 当成一个真正的数据管理系统，它到底应该怎么拆、怎么评、怎么取舍。

作者把 agent memory 拆成四个模块：记忆表示与存储、记忆抽取、记忆检索与路由、记忆维护。在这个框架下，他们评测了 12 个代表性记忆系统和 2 个参考基线，覆盖 5 类 benchmark workload、11 个数据集。核心结论很清楚：没有一种记忆架构能通吃所有场景；真正有效的 memory system，取决于它的结构是否对准当前任务的瓶颈。

换句话说，agent memory 不是“向量库 + top-k 检索”的同义词。它更像一个会持续写入、更新、检索、合并、遗忘的数据库系统，只是查询语义更模糊，数据更不稳定，更新也更依赖自然语言和上下文。

一、它要解决什么问题

过去很多 agent memory 评测，主要看最终任务指标：F1、BLEU、Exact Match，或者问答是否答对。这个角度当然有用，但会把 memory system 当成一个黑盒：只看“最后答没答对”，不问里面的 memory 是怎么存的、怎么查的、怎么更新的、更新成本有多高。

论文认为，这会漏掉几个真正系统层面的关键问题：

1. 架构 trade-off 看不清。 同样叫 memory，有的是纯上下文拼接，有的是向量库，有的是 temporal knowledge graph，有的是多引擎混合系统。只看最终分数，很难知道差异来自表示、检索、维护，还是 LLM backbone。
2. 动态更新能力被低估。 agent memory 不是静态文档库。用户偏好会变，事实会被纠正，旧信息会过期。系统必须处理 conflicting knowledge 和 temporal state。
3. 成本没有被认真纳入。 一个系统如果为了多几个点的准确率，牺牲了极高的构建时间、查询延迟、全局重组成本，生产中未必划算。
4. benchmark 仍偏聊天回忆。 很多数据集关注多轮对话里的事实回忆，但真实 agent 还会执行工具、跨任务积累状态、维护过程性信息。

所以这篇论文的出发点是：把 agent memory 从“算法模块”提升为“数据管理对象”来评估。

二、论文怎么定义 Agent Memory System

论文先区分了三件容易混在一起的东西：RAG、context engineering、agent memory system。

RAG 通常是 stateless、read-only 的检索机制：给一个 query，从静态语料里找相关 passages，再塞回 prompt。Context engineering 更宽，是每一轮推理前组织有限 context window 的实践，包括 prompt、tool 描述、检索片段、历史摘要等。

而 agent memory system 关心的是更长周期的东西：它要维护 agent-specific state，支持持续写入、检索、更新、压缩、失效和生命周期治理。论文把它形式化为四个模块：

这个拆法的好处是：它不再把“记忆系统”当成单一方法，而是能问得更细：一个系统强，是因为表示保留了证据？检索更准？更新机制能处理旧事实？还是只是用了更强的 answer model？

三、12 类系统放到同一张图里看

论文评测的系统覆盖了几类典型路线。

第一类是 Sequential Context。例如 MemoChat、Mem0、MEM1、MemAgent。它们更多把 memory 表示为 token-level sequence、fact list、JSON memo、上下文寄存器或有限状态。优点是简单直接，缺点是结构化程度有限，遇到长程关系、冲突更新、时间状态时容易吃亏。

第二类是 Structural Topological。例如 MemTree、Zep、Mem0g、Cognee。它们使用 tree、graph、temporal knowledge graph、entity-relation triplets 等结构，把事实之间的关系显式化。这类系统的优势通常出现在跨 session、temporal reasoning、knowledge update 等场景。

第三类是 Multi-Paradigm Hybrid。例如 LightMem、SimpleMem、MemOS、MemoryOS、A-MEM、Letta。它们往往把文本、向量、关系、元数据、时间戳、图结构或多种 index 混合起来。理论上最接近真实生产系统，但也最容易遇到维护成本和复杂度问题。

论文的一个重要视角是：结构不是越复杂越好。结构能带来检索和更新优势，但只有当维护范围是局部的、更新不是全局重组时，结构才划算。

四、端到端评测：没有万能 memory

论文在 5 类 workload、11 个数据集上做了评测，端到端部分重点看 LoCoMo、LongMemEval 和 DB-Bench。

结果不是某个系统一路领先，而是不同 workload 换冠军：

这里的关键不是谁赢，而是为什么换场景就换赢家。

如果任务瓶颈是跨 session 汇总和事件顺序，temporal graph 或 relation-aware retrieval 更有优势。如果任务是在长但语义连贯的对话里找具体事实，summary-first 或 coarse-to-fine routing 更有用。如果任务依赖操作顺序和中间状态，比如数据库操作，原始 trace 的保留反而更关键。

这也解释了为什么 Exact Match 不够。LoCoMo 里很多答案短、规范、可直接验证，EM 仍然有意义；但 LongMemEval 这种跨 session synthesis，正确答案可能有不同表述；DB-Bench 则更极端，最终状态对不对比字面输出更重要。

五、检索不是 top-1 排名问题，而是 evidence completion 问题

RQ2 专门看 memory retrieval fidelity：系统能不能把回答问题所需的证据找出来，而不是只看最终回答。

一个很有意思的结果是：SimpleMem 的 Recall@1 最高，达到 39.0；但当 retrieval budget 放大时，A-MEM 和 MemTree 更强。A-MEM 的 Recall@5 / Recall@10 达到 69.5 / 85.9，MemTree 达到 59.7 / 80.5，而且在 evidence distance gap 变大时更稳定。相反，flat Embedding RAG 在证据距离变远后下降明显。

这说明强 memory retrieval 不只是“第一条命中”。很多问题需要的证据是旧的、分散的、跨多个 turn 或 session 的。系统真正要做的是把相关 evidence 重新组装起来。

所以论文给出的设计启发是：

• early localization 和 evidence assembly 要分开看；
• 压缩型 memory 可能擅长先找出一个显著事实；
• 图、树、链接结构更适合补全多个互相关联的证据；
• 纯向量相似度更适合短距离、语义接近的场景。

这对 agent 工程很实际：如果你的 agent 只是查最近偏好，向量检索可能够用；如果它要长期跟踪用户、项目、工具调用、决策依据，memory 结构就不能只是 flat cache。

六、更新能力：强模型不能替你解决旧记忆冲突

RQ3 看的是 memory evolution robustness：系统能不能吸收修正后的事实，处理 temporal state，并且在不同 LLM backbone 下保持稳定。

论文给出的结果也不是单一胜者：

• 在直接事实更新上，Zep 表现最好，Knowledge Update 的 Substring EM 为 44.4，ROUGE-L F1 为 36.8；
• 在时间分散的证据上，Cognee 最强，Temporal Reasoning 的 Substring EM 为 18.7，ROUGE-L F1 为 35.8；
• 在最新状态的精确 grounding 上，MemOS 的 LoCoMo EM 最高，为 8.9；Cognee 的 Answer F1 最高，为 28.1。

论文还做了 LLM backbone ablation。更强的生成模型会提高绝对回答质量，但不会根本改变哪个 memory pipeline 有效。MemOS 在不同 backbone 下仍保持较强：32.2、41.2、38.6、41.2。作者据此认为：稳定的更新行为主要发生在最终生成之前。

也就是说，如果 memory 没有把“后来更新的事实”和“原来的实体 / 事件”绑定起来，或者 query-time retrieval 没有筛掉旧状态，靠更强的 LLM 也很难稳定补救。LLM scaling 更像是 answer realization 的增强，不是 stale memory resolution 的替代品。

七、长程稳定性：问题不是存得多，而是抽象得对

RQ4 看 long-horizon stability：context 变长、历史 session 变多、supporting evidence 离当前 query 更远时，系统是否还能稳定。

论文里有两个对比很直观：

• LongBench 中，SimpleMem 从 Short 到 Medium 只从 35.2 降到 34.9；Long Context 却从 42.6 掉到 19.0。
• LoCoMo 中，Embedding RAG 随 evidence gap 变大，从 37.1 Answer F1 掉到 7.4；Cognee、MemOS、MemoryOS 等结构化或 consolidated memory 系统更稳定。

这说明长上下文并不是简单地“多塞就好”。一旦输入里有大量 distractors，原始长 prompt 会让模型注意力和检索目标变得混乱。真正的瓶颈变成：系统有没有用合适的抽象把远处的事实和当前问题连接起来。

论文总结出三种有效支撑：

1. multi-view filtering：长输入里干扰多时有用，SimpleMem 是例子；
2. relation-aware indexing：supporting facts 跨很多 turn/session 时有用，Cognee 和 Zep 是例子；
3. coarse-to-fine summarization：先定位相关 session，再解决局部细节时有用，MemOS 和 MemoryOS 是例子。

八、成本：真正贵的是全局维护

RQ5 是这篇论文最像“数据系统论文”的部分：它不只问效果，还问 utility-latency trade-off。

论文用 Avg. Operation Latency/Query 和 Normalized Utility 看成本收益。结果显示，LightMem 和 MemTree 在 memory-augmented 系统里处在更好的效率前沿：

更高 utility 的系统当然存在，但代价会快速上升。尤其是 graph-wide consolidation、多存储同步、whole-memory rewriting 这类机制，会让维护成本随 memory growth 放大。

论文在 LongBench 上的 latency footprint 更尖锐：LightMem 是 17.3s，MemTree 是 116.7s，而 Mem0、MemoChat、MemoryOS、A-MEM 分别升到 374.2s、460.2s、490.0s、552.1s。

所以作者的结论不是“结构化 memory 太贵”，而是更精确的一句：效率由维护范围决定，不由结构本身决定。 局部更新和局部搜索可以很划算；一旦每次写入都牵动全局重组，再漂亮的结构也会变成成本黑洞。

九、细粒度消融：四个模块分别告诉我们什么

论文进一步拆了四个模块做 ablation。

1. 表示与存储：保留证据比更强抽象更重要

LightMem 的 User-Only Raw 在四个指标上最好：LoCoMo EM 24.2、Answer F1 38.9；LongMemEval Substring EM 26.0、ROUGE-L F1 31.4。User-Only Summary 明显更弱；User-Only Compressed 在 LoCoMo 上接近 raw，但在 LongMemEval 上从 26.0 Substring EM 掉到 10.7。

这说明如果任务需要精确恢复 session-level details，原始内容保留很重要。轻压缩可以保留推理主线，但会损失精确名称、日期、细节。层级结构能帮助访问，却不能找回已经被摘要删掉的信息。

2. 抽取：写入时不要太早过滤

Memory extraction 的结论是 late filtering principle：写入时要尽量保留上下文，过滤应该更多推迟到检索阶段。

例如 MemOS 的 Fast Memorize 在 LoCoMo 上远强于 Fine Memorize：EM 25.5 vs. 2.5，Answer F1 40.8 vs. 5.0。LightMem 的 Hybrid Raw 比 User-Only Raw 在 LoCoMo 上略好，说明 assistant turn 中的澄清、日期、改写也可能是后来回答问题的关键。

这里的工程含义很直接：不要让 extractor 在写入阶段过早判断什么是“重要信息”。很多细节单独看不起眼，但后来组合起来才成为答案。

3. 检索与路由：有用结构胜过盲目加复杂度

A-MEM 的 Hybrid-Balanced 比 Hybrid Sparse-Leaning 更好，LoCoMo Answer F1 24.6 vs. 23.0，LongMemEval Substring EM 27.5 vs. 24.3。SimpleMem 的 Planning Only 比 No Planning 和 Planning + Reflect 都好，说明显式规划有帮助，但额外 reflection 不一定继续增益。

所以 retrieval routing 的重点不是“多加一层 LLM 思考”，而是加入恰好有用的结构：适度 dense-sparse fusion、轻量 query planning、明确的 route。路线已经清楚后，再反思一遍可能只是增加成本和噪声。

4. 维护：保守合并好过延迟 flush 或粗暴摘要

MemoryOS 的 Conservative-Merge 比默认略好：Answer F1 从 23.2 到 23.5，Substring EM 从 22.4 到 22.8；Delayed-Flush 则降到 20.6 / 19.5。MemoChat 强制单主题摘要也弱于默认多主题 consolidation。

这说明维护策略要平衡：太晚写入，证据在 query time 仍然碎；合并太粗，低频但有用的细节会被抹掉；比较稳的是保守地整合相关信息，保留跨 turn linkages。

十、这篇论文对做 agent memory 的实践启发

我觉得这篇论文最有价值的地方，不是给出一个“最佳 memory system”，而是给了一个判断框架。

如果你的 agent 主要需要短期事实和最近偏好，轻量 raw memory、向量检索、简单时间戳可能就够了。此时上复杂 graph 可能只是在买维护成本。

如果你的 agent 要长期跟踪用户、项目、组织、实体关系、反复更新的事实，那 flat embedding RAG 很快会遇到边界。你需要 revisability：后来的事实要能绑定到同一实体、同一事件或同一状态，而不是追加成一条孤立文本。

如果你的 agent 做的是工具执行、数据库操作、工作流推进，trace-preserving memory 很重要。因为正确性常常依赖中间状态和操作顺序，不只是某个 isolated fact。

如果你的 agent 面临长历史、多噪声、多 session，关键不是“把所有历史塞进去”，而是要有从 coarse 到 fine 的 routing：先定位相关 session、相关实体、相关任务阶段，再让 LLM 生成答案。

最后，如果你的系统要上线，必须把 cost model 放进设计里。不要只问“检索准不准”，还要问：每次写入会不会触发全局重算？每次查询会不会跑 graph-wide traversal？维护成本会不会随用户记忆增长线性甚至超线性上升？

十一、边界与可疑之处

这篇论文是一个系统性实验研究，但也有边界。

第一，它主要研究 textual 和 structured memory。多模态记忆、真实 GUI 操作轨迹、代码仓库级长期记忆，不是这篇的重点。

第二，它仍然依赖现有 benchmark。虽然作者已经指出聊天式 benchmark 的局限，但很多结论仍来自 LoCoMo、LongMemEval、LongBench 等数据集。真实 agent workload 里的 tool logs、失败恢复、用户纠错、跨任务迁移，可能还需要更贴近生产的评测。

第三，不同系统的工程成熟度、实现细节和默认参数会影响结果。论文试图在统一 testbed 下比较，但 memory system 本身高度异构，完全公平并不容易。

第四，成本评估主要看 latency / operation utility，不等于完整生产成本。真实部署还会涉及存储成本、并发、权限、隐私、审计、数据生命周期、用户可控删除等问题。

附录：原文中的关键图表与数值索引

这份整理基于 arXiv API 元数据和 arXiv source / LaTeX 源码。Jina 抓取 ar5iv 页面时只返回了论文首页元数据和摘要，因此正文依据以 source 中的 main.tex、1_introduction.tex、2_definition.tex、3_taxonomy.tex、4_overall.tex、5_finegrained.tex、7_conclusion.tex 为准。

原文关键图表包括：

• figures/intro_example_workflows_v6.pdf：Typical Execution Workflows of Agent Memory
• figures/memory_representation_v3.pdf：Memory Representation Methods
• figures/memory_storage_v3.pdf：Memory Storage Methods
• figures/memory_extraction_v2.pdf：Memory Extraction Methods
• figures/memory_retrieval_v3.pdf：Memory Retrieval Methods
• figures/memory_maintenance_v2.pdf：Memory Maintenance Methods
• figures/table2_barchart_v2.pdf：LoCoMo、LongMemEval、DB-Bench 上的总体效果
• figures/RQ2_recall_barline_plot_v2.pdf：LoCoMo retrieval results
• figures/RQ3_llm_backbone_bar.pdf：LLM backbone ablation
• figures/RQ4_three_panel_stability_v2.pdf：长程稳定性三面板
• figures/RQ5_frontier_heatmap_combined.pdf：operation cost
• figures/m4_maintenance_figure.pdf：maintenance strategy ablation

原文明确的 5 个总体 finding 可以压缩成五句话：

1. Workload-Aligned Memory：强 memory 不是单一表示，而是结构对准 workload bottleneck。
2. Evidence-Centric Memory Organization：检索质量更依赖证据组织和重组能力，而不只是 top-1 排名。
3. Temporal Update Fidelity：更新可靠性是 pipeline-level 设计问题，不是单纯靠更强 LLM。
4. Horizon-Structured Memory：长程记忆的难点从“存更多历史”变成“选择正确抽象”。
5. Operational Scaling Rule：效率由维护范围决定，局部更新和局部搜索比全局重组更可扩展。