一句话讲清楚👉🏻上交、清华和 MemTensor 的这项研究把 Agent 记忆拆成表示存储、抽取、检索路由和维护四个数据管理模块，并用 12 套代表系统的统一实验说明：长期记忆的瓶颈已经从“能不能存”转向“能不能在更新、检索、成本之间稳定取舍”。

• 论文标题：Are We Ready For An Agent-Native Memory System?
• 论文链接：https://arxiv.org/abs/2606.24775
• Github 链接：https://github.com/OpenDataBox/MemoryData

过去一年，很多 Agent 产品都开始强调“记忆”。用户偏好、历史对话、工具调用、项目状态、长期计划，都希望被系统记住，下一次对话还能接上。

但工程里真正麻烦的地方很快就露出来了：把历史塞进向量库，只解决了“有地方放”；把最近上下文塞进 prompt ，只解决了“短期能看见”。一旦任务跨越多轮、多天、多工具，记忆会遇到更具体的问题：

■新事实来了，旧事实要不要作废？

■用户前后说法冲突，系统该信哪一个？

■需要找的是某个实体、某段时间、某条操作链，单纯相似度能不能找准？

■记忆越积越多，索引、更新、压缩的成本会不会爆掉？

它把讨论重心从“模型能不能记住”移到了“系统如何管理不断变化的记忆”：Agent 记忆是一套会持续写入、查询、更新、压缩和失效的数据管理系统。

论文梳理了多类 Agent 记忆系统的典型执行流程，从流式记忆、层级记忆、知识图谱记忆到混合架构。

这个判断很实用。因为很多 Agent 的失败，早在生成答案之前就已经埋下了：该写入的信息没写好，该作废的信息还在，被召回的证据缺了一半，或者维护一次记忆的开销已经高到没法线上运行。

先把“记忆”从 RAG 里拆出来

论文先做了一件很必要的事：给 Agent memory 划边界。

RAG 通常面对的是一个相对静态的外部语料库。用户来了一个问题，系统去检索相关段落，把它们塞回上下文，然后生成答案。这个过程更像“读”。

Agent 记忆面对的是持续变化的个体状态。它记录的是历史交互、环境观察、工具执行、中间计划、用户偏好和长期事实。它同时承担读、写、改、删、合并、过期和迁移。

论文把一个 Agent 记忆系统形式化为四个模块：

其中， 负责记忆表示与存储， 负责从交互流中抽取记忆， 负责检索与路由， 负责维护、更新和生命周期管理。

这个拆法比“某某记忆框架效果好不好”更有解释力。因为同一个系统的表现，往往取决于这些模块怎样组合：表示是否保留了足够证据，抽取是否过早压缩，检索是否能处理时间和关系，维护是否能控制冲突与成本。

不同记忆系统在任务效果、检索、更新、长程稳定性和成本上各有优势，很难用单一榜单概括。

放到工程里看， Agent 记忆已经不太像一个可选插件，更像会影响稳定性、成本和可维护性的底层设施。早期大家关心有没有 memory ；下一阶段真正拉开差距的，会是 memory 的数据模型、查询计划、更新策略和运维成本。

四个模块，决定记忆能不能长期工作

第一个模块是表示与存储。记忆可以是一段原始文本、一组事实、一棵树、一个图，也可以是同时包含文本、向量、关系和元数据的复合对象。

记忆表示从扁平 token 、向量表示，到图、树和复合结构，决定了后续能否做精细查询与更新。

扁平文本和向量的优势是简单、便宜、易接入。它们适合快速保存事实、偏好和短片段历史。代价也明显：当问题需要“谁和谁的关系”“某个事实什么时候变过”“旧事实是否仍然有效”时，单个向量很难承载这些结构。

图和树更适合处理关系、实体、时间和层级。比如用户先说住在 A 城市，后来搬到 B 城市，再后来问“我现在附近有什么餐厅”，系统要知道最新状态，还要知道旧事实已经过期。这类问题天然需要版本、时间戳、实体绑定和冲突处理。

物理存储侧可以使用上下文寄存、向量数据库、图数据库、关系型数据库或多引擎组合。

第二个模块是抽取。交互流进来之后，系统要决定怎么写入记忆：原样拼接、提炼成自由文本事实，还是按 schema 抽成实体关系。

记忆抽取决定了原始对话、工具日志和环境信息会以什么粒度进入长期存储。

这里最容易踩坑的是“写入时过度聪明”。 LLM 摘要看起来干净，实际可能删掉之后才会有用的小细节。很多长期记忆问题的关键，恰恰藏在原话里的日期、名字、顺序、条件和例外里。

第三个模块是检索与路由。论文把检索分成原生注意力、语义近邻、图遍历、 Agent 自主路由和多阶段混合执行。

检索路由从简单相似度搜索扩展到图遍历、查询规划、多阶段混合检索。

相似度搜索解决“像不像”，但很多记忆查询问的是“是否同一个实体”“哪条事实更新过”“支撑证据分布在哪几段历史里”。这时仅靠 top-1 相似结果不够，系统需要先规划查询，再组合证据。

第四个模块是维护。它处理的是记忆系统里最容易被低估的一组动作：冲突解决、版本管理、容量控制、语义合并、过期删除。

维护模块决定记忆如何更新、合并、遗忘，以及如何避免无限增长。

对线上 Agent 来说，维护是必需能力。没有维护，系统会变成一个越用越脏的日志仓库：旧事实还在，新事实也在，检索时两者一起被召回，模型只能靠猜来判断哪个有效。

细粒度维护实验比较了合并强度、 flush 时机和摘要粒度对长期一致性的影响。

统一评测： 12 套系统，没有通吃方案

论文评测了 12 套代表性记忆系统和两个参考基线，覆盖 5 类 benchmark workloads 、 11 个数据集。比较对象包括 Mem0 、 MemoChat 、 Zep 、 Cognee 、 MemTree 、 Letta 、 LightMem 、 SimpleMem 、 MemOS 、 MemoryOS 、 A-MEM 等，基本覆盖了几条主路线：轻量事实/摘要存储、图或树结构记忆、层级记忆、混合检索与多引擎记忆。

为了避免把所有结果堆成一张不可读的大表，我把论文的主要结论压缩成一个手机端可读的小表：

端到端效果显示，不同工作负载下领先系统会变化，单一架构很难覆盖所有场景。

在总体效果上，论文给出的第一条判断很直接：没有一种记忆架构在所有任务上占优。结构感知系统在 LongMemEval 这类跨会话任务上更强，混合过滤在 LoCoMo 的精确 grounding 上更有优势，保留操作轨迹的方式在 DB-Bench 这类状态执行任务上更稳。

这里有一个对产品设计很有用的启发：先判断你的 Agent 主要错在哪里。

如果错在跨会话聚合，比如“用户三周前说过偏好，昨天又改过一次”，那就需要时间和关系结构。如果错在长对话里的精确事实，比如“之前提到的餐厅叫什么”，粗暴摘要可能反而伤害结果。如果错在工具操作链，比如数据库增删改查的状态依赖，完整 trace 可能比抽象事实更重要。

检索要看证据拼装

论文在检索保真度实验里专门看了 LoCoMo 上的 evidence-level retrieval 。结果很有代表性： SimpleMem 的 Recall@1 最高，达到 39.0 ；但当检索预算变大， A-MEM 和 MemTree 在 Recall@5/@10 上更强， A-MEM 达到 69.5/85.9 ， MemTree 达到 59.7/80.5 。

检索实验表明，早期命中和完整证据召回是两件事，结构化组织更擅长拼回远距离证据。

所以只盯着 top-1 指标很危险：第一条命中可能相关，但回答一个长期记忆问题往往还需要第二条、第三条证据来补齐时间和约束。 Agent 记忆里的问题经常需要多条历史共同支撑：一个偏好在早期对话里出现，一个约束在后来补充，一个时间点又在另一轮里被改写。

所以，检索层的目标不该只是“先找一条最像的记忆”。更合理的目标是两个阶段：先定位可能相关的证据区域，再把互补证据组装完整。图结构、层级树、混合检索和查询规划的价值，主要就体现在第二阶段。

未来 Agent memory 的检索接口会越来越像一个小型查询优化器。它需要返回带来源、时间、实体关系和有效状态的证据包，而不是若干孤立 chunk 。

更新能力：强模型救不了脏记忆

动态更新是 Agent 记忆和普通 RAG 最大的区别之一。

论文把更新问题拆成知识更新、时间推理和不同 LLM backbone 下的稳定性。在事实修订任务里，图或关系组织的优势更明显： Zep 在 Knowledge Update 上达到 44.4 Substring EM 和 36.8 ROUGE-L F1 ； Cognee 在 Temporal Reasoning 上达到 18.7 Substring EM 和 35.8 ROUGE-L F1 ； MemOS 在 LoCoMo 的最新状态 grounding 上 Exact Match 达到 8.9 。

更换 LLM backbone 会改变绝对分数，但记忆管线本身的相对稳定性仍然很关键。

Backbone ablation 也值得单独看。换更强的生成模型之后，答案质量会上升，但系统之间的大体排序变化有限。也就是说，模型可以把已经找对的证据说得更好，却很难稳定修复“旧事实和新事实混在一起”的底层问题。

这点在做产品时很容易被忽视。很多团队看到记忆回答错了，会先换更强模型，或者加更长 prompt 。短期可能改善语气和部分推理，但如果记忆层没有实体绑定、版本管理和冲突处理，错误会反复出现。

长期记忆的更新能力，应该在写入和维护阶段就建进去：同一个实体的新旧事实要能关联，同一属性的更新要能判定有效性，过期信息要能被标记或降权，避免所有文本片段被系统当成同等可信。

长程稳定：存得多不等于记得住

长程实验回答了另一个常见问题：上下文窗口越来越长，记忆系统还必要吗？

论文结果给出的答案很克制。长上下文在某些需要原始 trace 的任务上依然强，但随着输入变长、干扰变多，它会明显掉分。 LongBench 中， Long Context 从 Short 到 Medium 的 Accuracy 从 42.6 掉到 19.0 ；而 SimpleMem 从 35.2 到 34.9 ，变化很小。

随着上下文长度、历史会话数量和证据距离增加，扁平检索和纯长上下文都会遇到稳定性问题。

在 LoCoMo 上， Embedding RAG 的 Answer F1 会随着 evidence gap 拉大从 37.1 掉到 7.4 ； Cognee 、 MemOS 、 MemoryOS 这类带结构或综合维护的系统更稳。

这里的核心问题已经从容量转向组织形态。如果所有信息都平铺，远距离证据会被大量相似但无关的片段淹没；如果过度摘要，关键细节又可能在第一轮压缩时丢掉。

比较靠谱的方向，是让记忆保留多层次入口：底层有较高保真的原始证据，中间有会话或主题级组织，上层有实体、事件、时间和任务状态。查询时先缩小范围，再回到具体证据。

成本：结构越强，维护越贵

论文最接近工程落地的一组实验，是操作成本。

很多记忆系统论文只看效果，很少看构建索引、写入维护和查询延迟。实际部署时，这些成本会直接决定系统能不能用。论文用平均操作延迟和归一化 utility 做了比较。

成本实验显示，局部维护和局部检索更容易落在效率前沿，图级全局维护代价很高。

结果大致可以概括为：

结构化记忆当然值得做，只是要看维护范围。更准确的结论是：成本主要取决于维护范围，而不是结构本身。

如果每次写入都触发全局图更新、多存储同步或整段记忆重写，系统很快会变慢。相反，如果维护只发生在局部路径、局部 segment 或局部实体邻域，效果和成本更容易平衡。

这会直接影响产品设计。用户刚改了一个偏好，实时链路只需要更新这个用户、这个实体附近的记忆；全局去重、历史重排和跨会话压缩，更适合放到后台慢慢做。在线路径上追求“每次都把全局记忆整理得很完美”，很容易把延迟和成本推高。

细粒度实验：过度抽象会伤害记忆

论文最后还做了四个模块的消融实验，结论很适合用来指导架构选型。

在表示与存储上，保留原始内容比更强抽象更稳。 LightMem 的 User-Only Raw 在四项指标上最好， User-Only Compressed 在 LoCoMo 上接近，但 LongMemEval 明显下滑； User-Only Summary 更弱。原因不难理解：摘要一旦删掉细节，后续再好的检索也找不回来。

在抽取上，覆盖优先通常比精筛优先更稳。 MemOS 的 Fast Memorize 在 LoCoMo 上远高于 Fine Memorize ， 25.5 EM 、 40.8 Answer F1 对 2.5 EM 、 5.0 Answer F1 。更精细的抽取不一定带来更好推理，因为它可能提前丢掉组合推理所需的上下文。

在检索上，适度规划有效，额外反思不一定加分。 SimpleMem 加 Planning Only 后， LoCoMo Answer F1 和 LongMemEval 指标都有提升；再加 Reflect 反而没有继续变好。对记忆路由来说，明确查询约束比让模型多想几轮更有价值。

在维护上，保守合并优于延迟 flush 和粗粒度摘要。 MemoryOS 的 Conservative-Merge 比默认设置略好， Delayed-Flush 下滑。换成工程语言，就是“该写入时别拖太久，该合并时别合太狠”。

给做 Agent 的几个判断

第一，别把 Agent 记忆只做成一个向量库封装。向量检索适合找相似内容，但长期 Agent 需要处理实体、时间、版本、冲突和生命周期。向量库可以是底层组件，不应该是全部架构。

第二，写入阶段要尽量保留证据。很多长期任务的关键证据，在写入时看起来并不重要。过早摘要、过早过滤、过早结构化，都可能让系统在未来的问题上失去可恢复性。

第三，检索阶段要从“找 chunk”升级为“找证据组”。一个长期记忆问题常常需要多条历史共同回答。召回结果应该带来源、时间、有效性、实体关系和置信线索。

第四，维护策略要局部化。全局整理看起来优雅，在线成本很容易失控。更现实的设计，是把同步维护限定在局部实体、局部会话或局部任务状态上，把重型整理放到异步后台。

第五，评测不能只看最终回答。论文反复强调端到端指标不够。一个记忆系统至少要测五件事：任务效果、证据检索、动态更新、长程稳定、操作成本。只看 F1 或 LLM judge ，很容易把系统层问题藏起来。

这篇论文给我的最大启发是： Agent memory 的下一阶段不会只是“更长上下文”或“更好的 embedding”。真正有壁垒的地方，可能会回到数据系统那些老问题：数据模型、索引、查询计划、事务式更新、版本控制、压缩、缓存、后台维护。

Agent 要想长期可靠地做事，记忆层必须从一个辅助模块长成一套基础设施。它不需要一开始就很复杂，但至少要知道自己在管理什么、如何更新、如何作废、如何证明召回的证据仍然有效。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】