10 月 1 日挂上 arXiv 的这篇 Mem++（编号 2610.02002），来自一个横跨高校与工业界的七人团队。它瞄准的场景叫「组织级 Agent」：一个在企业里干了几个月的助手，需要处理大量被反复修订的决策文档。论文的核心论点只有一句话，但这句话足以动摇当前几乎所有 Agent 记忆系统的设计假设——在写入时压缩记忆，是一个根本性的错误。
问题：决策会变，而你的记忆库把旧版本扔了
先看一个具体场景。公司 3 月发文规定「供应商付款审批限额 5000 美元」，7 月又发文调整为「10000 美元」。现在你问 Agent：「6 月 15 日那天，超过 8000 美元的付款走什么流程？」
正确答案需要两步：先确定 6 月 15 日生效的是哪个版本的规则（3 月版），再基于那个版本回答。这在人类的文档管理里叫「按时间点查询」，数据库领域叫时态查询。
而当前主流的记忆系统是怎么处理的？论文把它们的通病归纳为「写入时蒸馏」：文档进来时，先用 LLM 抽取事实、生成笔记摘要，或者转成知识图谱的边。这些方法有个致命的共同点——它们在任何问题被提出之前，就预先决定了这个记忆库将来能回答什么。7 月的新文档一进来，3 月版的「5000 美元」要么被覆盖，要么被摘要稀释成一个没有时间维度的模糊条目。时间维度被压缩过程系统性抹掉了。
方案：把压缩从写入端挪到读取端
Mem++ 的框架由三个设计决策构成，每一个都针锋相对。
第一，整篇存，不蒸馏。 每份文档带着日期和作者原样入库，不做摘要、不抽事实、不建图谱。写入路径上没有任何生成模型调用，这意味着零幻觉、零蒸馏成本、写入延迟趋近于零。
第二，读取时按时间点选档。 收到问题后，系统先解析问题所指的时间点，只检索日期不晚于该时间点的文档。「6 月的问题」只看 6 月之前的版本，「现在的问题」才看全部。这一步是 Mem++ 与普通 RAG 的本质区别：普通 RAG 会把 7 月的新规则一起捞出来污染答案。对组织场景来说，这个时间点过滤还有一个隐含收益——合规审计要求你能够证明「当时依据的是什么」，只有保留版本的架构才答得出这个问题。
第三，词法与语义双路融合。 因为库里存的是原始文档而非精炼摘要，单靠向量相似度容易漏掉术语精确匹配，单靠关键词又抓不住同义改写。Mem++ 在读取时融合词法排序与语义排序，把「选哪个版本、取哪几段」的判断交给最终作答的模型。
一句话总结这个哲学：不确定未来会被问什么，那就什么都别删。压缩的成本不应该花在写入时（那时你不知道要保留什么），而应该花在读取时（那时你已经知道问题是什么）。
实验：三个基准，三张成绩单
论文的评测覆盖组织决策专用基准 OrgMemBench，以及两个公开长记忆基准 LoCoMo 和 LongMemEval-S。三个关键数字：
- OrgMemBench：跨两个作答模型，Mem++ 超过最强的记忆系统基线 8.0 到 13.1 分。这个幅度在记忆系统对比里是罕见的大差距，因为基线们面对的正是它们设计上最不利的场景——版本随时间演化。
- 对 RAG 的胜利：用 gpt-4.1-mini 作答时，Mem++ 总分高于朴素 RAG 2.6 分。值得注意的是这恰好说明「原样存」并不天然赢——朴素 RAG 也存原文，但它缺时间点过滤和融合排序，在版本冲突场景下会把新旧规则一起喂给模型。
- 公开基准不偏科：LoCoMo 上拿下最佳平均 LLM 判官分；LongMemEval-S 上排名第二，输给的正是它自己的实体图谱变体——团队诚实地展示了一个混合路线（原文为主、图谱为辅）可能更优。
工程视角：什么时候该用它
Mem++ 的适用边界其实很清晰。它的三个前提是：文档有可靠的时间戳；修订以「新文档」而非「改旧文档」的形式发生；查询带有时间维度或版本敏感性。会议纪要、政策文档、合同修订、工单记录、合规审计——这些场景全部命中。
反过来说，如果你的记忆内容是用户偏好、闲聊摘要这类没有严格版本语义的数据，Mem++ 的收益会退化为普通 RAG。另外，原始文档全量存储对检索层要求更高：语料规模上去之后，双路融合加上时间过滤的查询延迟需要专门优化，论文没有给出大规模语料下的性能曲线，这是它留给工程界的一道 open question。
一个值得玩味的行业回声
有意思的是，就在这篇论文发布前后，HN 上一篇 342 分的热帖主张「Agent 需要的不是记忆，而是文档」。两者从相反的出发点走向了同一个结论：长期记忆的最好载体是那份未被压缩的原始记录。Mem++ 的贡献在于把这个直觉变成了可复现的基准数字——保留全部版本加上时间点查询，比任何聪明的蒸馏管线都多拿 8 分以上。
对正在给企业 Agent 选型记忆方案的人来说，这篇论文的实用建议浓缩成一句：先问你的记忆系统能不能回答「这个政策上个月是什么」，不能的话，重新考虑那层写入时压缩。