Agent 记忆里，少做比多做更好

上海交大和清华的团队发了一篇论文，系统测了 12 种 Agent 记忆系统。做法跟之前同类研究不一样：他们不看最终答案的 F1 分数，而是把记忆系统拆开，从数据库管理的角度逐个模块打分——存什么、怎么提取、怎么检索、怎么维护，各算各的。

论文标题叫 Are We Ready For An Agent-Native Memory System?，语气带着质疑。读完之后我觉得质疑得对。12 套系统跑 5 个 benchmark，结论汇总下来指向同一件事：在 Agent 记忆里，少加工、少抽象、少重组，效果反而更好。

这跟 AI 圈的直觉相反。大家觉得记忆系统应该更智能——用 LLM 总结对话、提取关键信息、构建知识图谱、自动合并相似内容。这篇论文用数据告诉你：这些操作每一步都在丢信息，而丢掉的信息往往是后面答题需要的。

保留原文，别急着总结

论文里最 striking 的实验是 LightMem 的三组对照。

同一个系统，分别用三种方式存对话：原文、LLM 生成的摘要、轻度压缩（去口水话但保留原始措辞）。结果：

• 原文：LoCoMo Exact Match 24.2，LongMemEval Substring EM 26.0
• 摘要：LoCoMo EM 8.5，LongMemEval Substr EM 11.7
• 压缩：LoCoMo EM 23.6，LongMemEval Substr EM 10.7

摘要把分数砍掉了三分之二。压缩在 LoCoMo 上还行，到 LongMemEval 也崩了。

原因不复杂。LLM 总结对话时，它不知道哪些细节后面会用到。一句”我家狗叫小白”在总结时可能被省略，但 20 轮对话后用户问”小白最近怎么样”，你就答不上来。摘要优化的目标是覆盖率，但覆盖率跟可回答性不是一回事。

MemTree 的实验也印证了这一点：把树结构加深，效果只有微小提升。层级帮你导航，但没法恢复已经被删掉的内容。

写入时别过滤，检索时再筛

论文管这个叫”晚过滤原则”（Late Filtering Principle）。

MemoChat 测了两种提取方式：用规则做话题分割 vs 用 LLM 做话题分割。规则的 LongMemEval ROUGE-L F1 是 18.6，LLM 的是 15.9。MemOS 测了”快速记忆”vs”精细记忆”：快速模式 LoCoMo Ans F1 是 40.8，精细模式是 5.0——差了 8 倍。

精细提取看起来更聪明，但它提前替你做了判断：哪些信息重要、哪些可以丢弃。问题是，这个判断在写入时刻往往做不准。用户随口提的一个爱好、一个日期、一个地名，在当时语境下无关紧要，但 5 个 session 之后成了答题的关键线索。

保守的做法是写入时多存一点，把过滤推迟到检索阶段。检索时你有 query，你知道在找什么，这时候过滤才靠谱。

LightMem 还测了”只存用户发言”vs”用户+助手都存”。加上助手发言后 LoCoMo EM 从 24.2 涨到 25.5——因为助手回复里有澄清和精确化的信息，丢了就找不回来。

保守合并，别推倒重建

维护模块的实验给出了一个操作性很强的结论。

MemoryOS 测了三种维护策略：默认即时合并、延迟写入（扩大缓冲区再合并）、保守合并（提高合并阈值，只合并高度相似的）。结果保守合并最好，延迟写入最差。

延迟写入的问题在于：用户问了，但你还没把最近几轮的对话写进记忆库，检索就找不到。表面上省了几次写操作，实际上检索质量掉了。

更宏观的成本分析在 RQ5：图结构系统（Cognee、Zep）的 utility 跟 MemoryOS 差不多，但操作延迟是后者的 4-5 倍。因为图结构每次更新都可能触发全局的实体消歧和关系重建。LightMem 和 MemTree 用的是局部维护——只更新受影响的子树或分段——成本低一个数量级，效果差不了多少。

论文的原话：efficiency is governed by maintenance scope rather than structure alone。翻译成人话：决定维护成本的，是你的更新操作影响多大范围，而不是你用了什么数据结构。

没有万能架构

上面三条说的是”别做过头”，但论文另一个核心结论是”看场景”。

四种架构各有所长：

• 向量检索：简单问答够用，便宜，但跨 session 推理弱
• 知识图谱（Zep、Cognee）：多跳推理和事实更新强，但操作成本高
• 分层记忆（MemGPT/Letta）：上下文管理做得好，但 Letta 在知识更新测试里拿了 0 分
• 混合多引擎（A-MEM、MemOS）：各场景都不差，但构建和维护最复杂

论文在 DB-Bench（数据库操作任务）上的发现很有意思：Long Context（什么都不存，直接塞进 prompt）拿了最高的 Exact Match 48.2。因为在需要精确执行操作序列的任务里，完整保留中间状态比任何记忆压缩都靠谱。

这说明一件事：记忆系统的价值取决于 workload 的瓶颈在哪里。瓶颈是跨 session 的事实关联？你需要关系结构。瓶颈是精确的操作历史？你需要保留完整 trace。瓶颈是长对话里的某个细节？你需要原文和好的检索。

我的 Agent 怎么记忆

我自己跑一个 Hermes Agent，用了几个月。读完这篇论文，回头看自己的记忆架构，发现踩了好几个论文里提到的坑。

我的记忆系统是 MEMORY.md——一个平铺的 markdown 文件，每条记忆用 § 分隔，注入到每次对话的 system prompt 里。检索靠 session_search（FTS5 关键词搜索）。技能沉淀在 skills/ 目录，手动创建。

对照论文的四模块框架：

表示与存储：token-level 原文，论文证明这是保真度最高的方式。这一点歪打正着做对了。

提取：纯手动。用户说了什么值得记的，我用 memory 工具写进去。没有自动提取，也没有 LLM 总结。论文的”晚过滤原则”说这样做没问题——手动提取本身就是最保守的提取。

检索与路由：最大的短板。FTS5 只做关键词匹配，没有 recency 权重，没有 importance 分级，没有混合检索。论文 Finding 2 说 retrieval 是一个 evidence-completion 问题，不是一个 top-1 ranking 问题。我的 session_search 找一个关键词还行，找”三个月前讨论过的某个投资逻辑”就不灵了。

维护：MEMORY.md 快满了（2193/2200 字符）。每次整理都是全量重写——读一遍，手动删旧条目，保留还需要的。论文说局部维护比全局重组高效得多，但我现在被迫做全局重组，因为没有删除单个条目的粒度控制。

如果要改，优先级最高的是检索。论文 Finding 8 给了明确指引：加一个轻量的 query planning 步骤，检索质量就能显著提升。SimpleMem 加了 planning 后 Ans F1 从 18.7 涨到 20.7，Substring EM 从 17.0 涨到 21.7。具体来说就是在检索前先让 LLM 分析一下”这个 query 到底在找什么”，然后再去搜。成本很低，效果明显。

维护层面，MEMORY.md 的 2200 字符上限是个硬约束。论文说局部维护好过全局重组，但我的架构不支持局部。一个可行的改法是给每条记忆加时间戳和访问计数，自动淘汰最久没用的——类似 MemoryOS 的 Heat score 机制。不过对于一个个人 Agent 来说，这个工程量值不值得做，是个问题。

最后

这篇论文值得读，不是因为它的结论多么出人意料，而是因为它用扎实的数据证明了一些工程师已经隐约感觉到的东西。

记忆系统的设计里，每一层抽象都有代价。总结丢细节，压缩丢精度，图谱重建慢，激进合并打乱时序。论文的核心教训是：在你不确定要不要加一层处理的时候，默认不加。

论文代码开源于 github.com/OpenDataBox/MemoryData，12 套系统的评测框架可以直接跑。如果你在搭需要长期记忆的 Agent，花两小时把 Table 2 到 Table 5 看一遍，比读十篇综述都值。