Are We Ready For An Agent-Native Memory System?：Agent 记忆系统还没到“原生”阶段

一句话定位：这篇论文从数据管理视角系统评估 Agent memory，结论是没有一种架构通吃，真正可靠的长期记忆必须按 workload 设计表示、写入、检索和维护策略。

论文：Are We Ready For An Agent-Native Memory System?
代码：OpenDataBox/MemoryData
发布时间：2026-06
适合读者：Agent memory、长期对话系统、个人助手、RAG 平台、知识图谱记忆和生产级 Agent 基础设施建设者。

---

1. 背景：Agent memory 不是一个增强模块，而是一套数据系统

大模型 Agent 要长期工作，就必须记住历史。

它可能要记住用户偏好、跨 session 的对话事实、工具调用结果、数据库操作状态、环境观察，以及过去推理过程中产生的中间结论。

最简单的方案是把历史放进上下文窗口。窗口不够时，就做 RAG。再进一步，就把历史抽成 facts、summary、graph、tree、memory block 或多层结构。

过去两年，Agent memory 系统快速增多。Mem0、Letta、Zep、A-MEM、MemOS、MemoryOS、SimpleMem、LightMem、MemTree、MemoChat 等系统都在回答同一个问题：Agent 应该怎么记住长期状态？

但这也带来一个问题：这些系统到底怎么比较？

如果只看最终 QA 准确率，会把 memory 当成黑盒。一个系统为什么答对，是因为写入抽得好，还是检索路由好，还是更新机制好？一个系统为什么答错，是因为没存、存丢了、搜不到，还是搜到了但生成模型没用上？

这篇论文的价值在于把 Agent memory 从“算法模块”拉回“数据管理系统”。论文关心的不只是最后答案准不准，而是 memory 的完整生命周期：表示、存储、抽取、检索、路由、更新、合并、失效、成本和长期稳定性。

---

2. 核心问题：我们离 agent-native memory 还有多远

论文题目问的是：Are We Ready For An Agent-Native Memory System?

这里的 agent-native memory，不是普通 RAG，也不是简单上下文工程。

RAG 通常是静态、只读、单次查询导向的：给一个 query，从固定语料里找 passages，塞进 prompt 生成答案。

Context engineering 更宽泛，它关注每一轮推理时如何组织有限上下文：系统提示词、工具描述、检索结果、短期状态等。

Agent memory 则更像一个持久、可更新、面向 agent 状态的数据系统。它要在长期运行中不断接收新信息，处理旧信息，解决冲突，维护版本，并在未来某个时刻把相关状态重新取回。

这意味着 Agent memory 的难点不只是“搜得准”，还有三个更系统的问题。

第一，状态会变化。用户过去喜欢 A，现在改成 B；订单状态、项目计划、工具执行结果都可能被后续信息覆盖。append-only 的 memory 很容易返回过期事实。

第二，证据会分散。一个问题可能需要组合多次会话里的碎片事实。单个 top-1 命中不够，系统要能把证据重新组织起来。

第三，成本会持续增长。记忆越多，写入、索引、检索、维护越贵。一个 benchmark 上看起来精致的系统，长期运行后可能因为全局重组成本过高而不可用。

---

3. 论文的四模块框架

论文把 Agent memory system 形式化为四个模块：representation and storage、extraction、retrieval and routing、maintenance。

这个拆法非常实用，因为它把“memory 系统表现好坏”拆成了可定位的工程问题。

3.1 Memory Representation and Storage：记忆以什么形态存在

第一层问题是记忆怎么表示。

最朴素的是 token-level sequence。比如把事实写成自然语言句子、JSON memo、summary，或者直接保留在上下文与 KV cache 里。这类方法简单、可读，但缺少结构，难做精确更新和关系推理。

第二类是 graph 或 tree-based topology。比如 Zep、Mem0g、Cognee 这类系统把实体、关系、时间和事件组织成图；MemTree 则用层级树组织细节和摘要。结构的好处是能沿关系或层级找证据，也更容易表达“同一实体的新旧状态”。

第三类是 heterogeneous composite representation。比如 MemOS 的 MemCube、A-MEM 的 atomic notes、MemoryOS 的 segment-page 设计。它们通常同时包含文本、metadata、embedding、时间戳、类别和链接，目标是在一个 memory object 里兼顾检索、过滤、更新和长期维护。

第二层问题是记忆存在哪里。

有些系统只用上下文窗口或临时 register，速度快但容量有限。有些系统用单一后端，比如向量库、图数据库或关系库。有些系统会使用多引擎组合，比如 vector + graph + BM25 + SQL，靠不同索引负责不同查询模式。

论文的判断是：结构本身不是银弹。关键是结构是否保留了 workload 需要的证据，以及维护这个结构要付出多少成本。

3.2 Memory Extraction：写入时怎么从历史里生成记忆

写入路径决定了 memory store 里到底有什么。

论文把 extraction 分成三类。

第一类是 raw sequence concatenation。不做复杂抽取，直接保留原始片段或摘要状态。这类方法成本低，信息保留多，但检索和维护压力会转移到后面。

第二类是 schema-free semantic extraction。比如从对话中抽出独立事实：“用户是素食者”“用户住在上海”。这类方法粒度清楚、便于向量检索，但容易丢掉上下文和时间条件。

第三类是 schema-constrained structured extraction。比如抽实体、关系、事件、时间戳，写入知识图谱或结构化 memory object。它更适合冲突处理和时间推理，但写入成本更高，也更依赖抽取质量。

论文后面的 ablation 给出一个很重要的结论：写入时不要过早丢信息。

更强的摘要、更细的抽取、更复杂的 schema，不一定带来更好的端到端效果。很多任务需要的是原始细节、上下文线索和可追溯证据。一旦写入阶段把这些信息压缩掉，后面的图、向量或规划都恢复不了。

3.3 Memory Retrieval and Query Routing：查询时怎么找到相关记忆

检索模块决定 memory 是否能在需要时被用上。

论文覆盖了五类 retrieval / routing 方法。

第一类是 native attention-based retrieval。记忆留在上下文里，靠模型 attention 自己找。它省掉外部检索，但长上下文里的噪声和位置退化仍然明显。

第二类是 semantic dense retrieval。典型向量 top-k。它适合短距离语义相似事实，但面对时间距离很远、证据分散、需要多跳组合的问题会明显退化。

第三类是 topological subgraph traversal。从实体或事件节点出发，在图上扩展相关邻域。这类方法适合关系明确的问题，但需要好的图构建和边语义。

第四类是 autonomous agentic routing。让 LLM 自己规划检索、生成查询、调用工具。它更灵活，但延迟和失败模式也更难控制。

第五类是 multi-stage hybrid execution。同时或顺序结合 BM25、dense retrieval、SQL filter、图遍历、rerank 等策略。论文认为这类方法在很多场景下更稳，因为它不把所有希望押在单一相似度上。

这里最关键的观点是：retrieval fidelity 不是 top-1 排名问题，而是 evidence assembly 问题。

Agent 问题经常不是“找到一条最像 query 的记忆”就结束，而是要把多条、分散、跨时间的证据组合起来。A-MEM、MemTree 这类显式组织证据空间的系统，在 Recall@5 和 Recall@10 上更能体现优势；平面 embedding RAG 在证据距离变远后下降更明显。

3.4 Memory Maintenance：记忆怎么更新、合并和遗忘

长期系统真正难的是维护。

论文把 maintenance 分成几类。

第一类是 timestamp-based multi-versioning。不直接删除旧事实，而是用时间戳、validity flag、版本链来表达某条事实在什么时候有效。Zep、Mem0g、LightMem、SimpleMem、MemOS 都有类似思路。

第二类是 capacity-driven physical eviction。当容量超过限制时，按 FIFO、token limit、heat score 或 decay score 删除旧记忆。它能控制增长，但可能误删未来重要证据。

第三类是 LLM-driven semantic consolidation。用 LLM 合并冗余事实、改写摘要、执行 CRUD。它能让 memory 更紧凑，但如果合并过激，会把稀疏线索压掉。

第四类是 continuous parametric optimization。把一部分记忆优化放到模型参数或离线训练里，降低在线延迟，但维护复杂度更高。

论文的维护结论很工程化：保守合并通常比激进摘要更稳；局部维护比全局重组更划算；延迟 flush 看起来保留了更多短期内容，但可能让查询时证据还没有进入可检索状态。

---

4. 实验设计：五个 RQ，不只看最终分数

论文在五类 benchmark workload 和 11 个数据集上评估代表性 memory 系统，并设置两个 baseline：Long Context 和 Embedding RAG。

它回答五个研究问题。

RQ1：整体任务效果。 不同 memory 系统是否能提升端到端任务表现？评测覆盖 LoCoMo、LongMemEval、DB-Bench 等长期对话、跨 session 记忆和状态执行任务。

RQ2：检索证据保真度。 系统是否能取回 gold evidence，而不只是最终答对？这把检索问题从生成模型里剥离出来。

RQ3：动态更新稳健性。 当事实被修正、时间状态变化、LLM backbone 替换时，memory pipeline 是否仍然可靠？

RQ4：长跨度稳定性。 当上下文更长、历史 session 更多、证据距离更远时，系统是否退化？

RQ5：操作成本。 不同 memory 系统的构建、查询和维护延迟如何？准确率提升是否值得付出成本？

这个实验设计比单纯 benchmark 排名更有价值。它不是问“谁第一”，而是问“哪个模块在哪类 workload 下失效”。

---

5. 核心发现一：没有通用最优，只有 workload-aligned memory

论文最重要的结论是：没有一个 memory 系统支配所有 workload。

在 LongMemEval 这类跨 session 事实聚合和时间分散证据场景里，Zep、Cognee 等结构化、关系化系统更有优势。

在 LoCoMo 这类长对话问答里，MemOS、MemoryOS 这类混合过滤和粗到细定位方式表现更稳，因为它们能先缩小范围，再保留局部细节。

在 DB-Bench 这类过程执行任务里，Long Context 和 MemoChat 这类 trace-preserving 方法反而更强。因为正确性依赖操作顺序和中间状态，过度抽象后的事实 memory 可能丢掉执行语义。

这对工程选型很重要。

如果你的 Agent 主要是个人长期偏好和跨 session 事实更新，图、时间戳和版本机制很重要。

如果你的 Agent 主要是长对话问答，检索策略要能先定位相关 session 或 topic，再取局部证据。

如果你的 Agent 主要是代码、数据库、工具链任务，原始 trace 可能比精炼事实更重要。

---

6. 核心发现二：证据组织比单点命中更重要

很多检索评测看 Recall@1 或 top-k 命中，但 Agent memory 的难点经常是证据重组。

论文在 LoCoMo 上分析 evidence distance，发现 flat Embedding RAG 在证据距离变远后明显退化。原因很直观：越早的证据和当前 query 的表面相似度越弱，越容易被近期或语义相近但无关的内容挤掉。

SimpleMem 在 Recall@1 上很强，说明压缩式 memory 能较快定位一个高相关点。但 A-MEM 和 MemTree 在更大的检索预算下更强，说明图、树、链接和层级组织能帮助系统补齐更多证据。

这说明长期 memory 的检索目标应该拆成两步。

第一步是 early localization：先找到一个可能相关的入口。

第二步是 evidence completion：沿结构、时间、主题或实体关系补齐支持证据。

只做第一步，系统可能“看起来搜到了”，但最终回答缺少关键上下文。

---

7. 核心发现三：动态更新不是靠更强 LLM 硬推出来的

论文专门评估了 knowledge update、temporal reasoning 和 backbone robustness。

结果很有启发：换更强的生成模型通常能提高绝对回答质量，但不会从根本上修复 weak memory pipeline。

如果系统没有把新旧事实绑定到同一实体，没有记录时间有效性，也没有在 query-time 选择当前有效状态，那么更强 LLM 也只是面对一堆混杂证据做猜测。

Zep、Cognee 在事实修正和时间推理上更有优势，是因为图或关系结构让更新可以落到实体、关系和时间上。

MemOS、MemoryOS 在某些最新状态查询上更稳，是因为混合过滤能帮助它们定位当前有效证据。

相反，append-only 或纯 dense retrieval 很容易出现“过去的幻觉”：系统不是没记住，而是把过期事实和最新事实一起交给了模型。

这个结论可以总结成一句话：更新可靠性是 memory representation 和 retrieval selectivity 的问题，不是单纯模型规模问题。

---

8. 核心发现四：长跨度退化来自抽象不合适，不只是容量不够

当记忆跨度变长时，系统面对的不是简单的“存不下”。

真正的问题是：记忆表示能不能在长时间后仍然保留可用证据。

Long Context 会因为噪声、位置和注意力分散而退化。Flat dense memory 会因为远距离证据和 query 相似度变弱而退化。过度摘要会因为细节被压掉而退化。

论文发现，显式关系、时间结构、层级摘要和多视图过滤能缓解这种退化。

图结构适合保留实体、事件、时间之间的连接。层级结构适合先定位主题或 session，再回到局部细节。多视图过滤适合在长历史里排除大量 distractor。

所以长跨度 memory 的关键不是“把历史压得更短”，而是“用什么抽象保留未来可能需要的证据路径”。

---

9. 核心发现五：维护范围决定操作成本

论文的 RQ5 把准确率和延迟放在一起看。

结果显示，高结构化系统往往更贵，但贵不一定总能换来成比例收益。

LightMem 和 MemTree 位于比较好的效率前沿。LightMem 通过轻量分段和局部检索控制成本；MemTree 通过路径局部聚合保留较高 utility，同时避免每次全局重组。

Cognee、Zep、MemoryOS 这类更强结构系统能获得更高 utility，但往往要付出更高构建和查询延迟。

A-MEM、Mem0、MemoChat 等系统在某些长上下文 workload 下也会出现较高延迟，原因常常不是“用了结构”，而是维护或查询涉及了较大范围的全局协调。

这给生产系统一个很直接的原则：不要只问 memory 结构多强，要问每次写入会影响多大范围。

局部 append、局部 merge、局部 traversal、局部 rebuild 通常更可控。

全局重写、全局图合并、多 store 同步、反复全库比对，短期 benchmark 可以接受，长期运行会变成成本黑洞。

---

10. 组件级 ablation：很多直觉需要反过来

论文第 5 节做了细粒度组件对比，结论很值得工程团队记住。

表示层面：保留原始内容通常比更抽象的 summary 更稳。LightMem 的 User-Only Raw 在多个指标上强于 User-Only Summary。原因是摘要会丢掉精确名字、日期、上下文线索，而这些恰恰是长期 QA 需要的。

抽取层面：写入时应该保守保留，而不是过早过滤。MemOS 的 Fast Memorize 在 LoCoMo 上大幅强于 Fine Memorize，说明更精细的抽取不一定更适合下游组合推理。

检索层面：轻量 planning 有价值，但额外 reflection 不一定有收益。SimpleMem 加 Planning Only 比直接检索更好，但 Planning + Reflect 没有继续提升，说明推理步骤不是越多越好。

维护层面：保守合并优于延迟 flush 或过粗 summary。MemoryOS 的 Conservative-Merge 略优于默认设置，而 Delayed-Flush 变差，说明把近期内容留在未整理状态并不一定能提高可回答性。

这些结论背后有一个共同原则：memory 系统最怕把未来要用的信息提前处理掉。

写入时过度抽象、维护时过度合并、检索时过度相信单一相似度，都会让系统在长期场景里变脆。

---

11. 对工程团队的启发

第一，先定义 workload，再选择 memory 架构。不要用一个通用 benchmark 分数决定所有场景。

第二，把 memory 写入路径当成核心设计。抽什么、不抽什么、保留多少原文、是否记录时间和 provenance，往往比后面换一个更强 LLM 更重要。

第三，检索要从 top-k 思维升级到 evidence assembly。长期任务常常需要入口定位、结构扩展和证据补齐。

第四，动态更新必须有一等公民设计。时间戳、版本、实体绑定、失效规则和当前状态选择不能靠 prompt 临时解决。

第五，维护要局部化。能局部 merge 就不要全局重写，能路径更新就不要全图刷新，能异步 compaction 就不要阻塞在线查询。

第六，评测要分层。端到端 QA 分数之外，至少要测 evidence recall、update correctness、long-horizon stability、construction latency、query latency 和 memory growth。

---

12. 一句话判断

这篇论文的价值不是告诉我们“哪个 Agent memory 系统最好”，而是告诉我们为什么这个问题本身问错了。

Agent memory 没有通用最优架构。真正的 agent-native memory 必须理解 workload：什么信息会变化，什么证据会分散，什么查询要求最新状态，什么任务必须保留执行 trace，什么成本可以被后台摊销。

长期来看，Agent memory 会越来越像数据库、搜索系统和运行时状态管理的结合体。它不是模型旁边的一个插件，而是 Agent 能否长期可靠工作的基础设施。