Mem++：别在写入时压缩记忆——把选择权留给提问的那一刻
想象一个场景：你是一家公司的 AI 助手，负责回答关于公司决策的问题。有人问："我们 3 月份选了哪个供应商？"
目录
当你的组织记忆"压缩"得太早
想象一个场景：你是一家公司的 AI 助手，负责回答关于公司决策的问题。有人问："我们 3 月份选了哪个供应商？"
这个问题听起来简单，但在组织里，"3 月份选了哪个供应商"可能意味着：
- 2 月 15 日，技术部发备忘录推荐供应商 A
- 3 月 3 日，采购部发邮件选择了供应商 B
- 3 月 20 日，CEO 批示改回供应商 A
- 4 月 1 日，又收到一份更新，选了供应商 C
Mem++ 的核心洞察就是：大多数记忆系统犯了一个错误——它们在写入时就把文档压缩成事实，但此时还没有人提问，你根本不知道哪些信息重要。
写入时压缩 vs 读取时选择
当前主流的 LLM 记忆系统——无论是 RAG、知识图谱、还是 MemGPT 风格的分层记忆——都有一个共同假设：在文档进入记忆系统的那一刻，就应该把它"消化"成结构化的事实、笔记或图边。
这个假设看起来合理：压缩后存储成本低、检索速度快。但 Mem++ 的作者指出，这种做法等于在问题提出之前就锁定了能回答什么问题。
打个比方：你去图书馆找一本关于"二战"的书。一种图书馆把每本书都拆成卡片索引——"二战始于1939年"、"诺曼底登陆在1944年"——你只能查到这些预设的事实。另一种图书馆保留每本书的完整内容，等你来问具体问题时，再去检索相关段落。
前者是写入时压缩，后者是读取时选择。Mem++ 选择了后者。
Mem++ 的三段式架构
Mem++ 的设计极其简洁，分三个阶段：
写入路径：每份文档原封不动地存入，附带日期和作者。写入时不调用任何生成模型，不做摘要，不做实体抽取。存储成本就是原始文档本身。
可选的整合层：对近重复文档进行分组，标记旧版本为"已被取代"——但不删除。整合只是加了一层关系标注，原始记录完整保留。
读取路径：当问题到来时，只检索"问题所问时间点之前"的文档，然后融合词法排序和语义排序来选择相关证据。选择权交给回答模型——它可以看到多个版本的文档，自己判断哪个版本在问题所问的时间点上是有效的。
关键区别在于：Mem++ 不是简单地"保留所有东西"（那只是个数据库），而是让每个文档保持完整，附带日期，把版本之间的选择推迟到读取时。
"非破坏性"到底意味着什么
"非破坏性"这个词听起来像技术术语，但它的含义很具体：
1. 不覆盖：新文档不会覆盖旧文档。如果 3 月 20 日的备忘录改变了供应商选择，3 月 3 日的邮件仍然完整保留。 2. 不蒸馏：不会把一份 10 页的备忘录压缩成"供应商 = B"这样一个三元组。文档就是文档。 3. 不在写入时生成：不调用 LLM 来做摘要或实体抽取。写入路径是纯存储操作，零 token 消耗。
这三条加在一起，意味着 Mem++ 的写入路径极其便宜——它只是一个带日期索引的文档存储。
实验结果：8-13 分的提升
Mem++ 在 OrgMemBench（组织记忆基准测试）上的表现：
- 超越最强基线 8.0-13.1 分（跨两个回答模型）
- 使用 gpt-4.1-mini 时，总成绩超过 RAG 2.6 分
- 在 LoCoMo（对话基准）上获得最佳 LLM-judge 平均分
- 在 LongMemEvalS 上排名第二，仅次于其自身的实体图变体
为什么这违反直觉
Mem++ 的反直觉之处在于：它似乎在"浪费"存储空间。保留所有文档的完整内容，不压缩、不蒸馏，这不是更贵吗？
但作者指出，真正的成本不在存储，而在信息损失。当你把一份备忘录压缩成"供应商 = B"时，你丢失了：
- 这份备忘录是谁写的
- 什么时候写的
- 上下文是什么
- 有没有附加条件
- 有没有同时提到了其他选项
更深层的洞察：选择权本身是有价值的
Mem++ 让我想到金融学里的一个概念：期权价值。
一份金融期权之所以有价值，是因为它给了你在未来某个时点做选择的权利——但不是义务。你今天不需要知道未来股价会涨会跌，你只需要保留选择权。
记忆系统也是一样。写入时压缩等于"提前行权"——你在还没有看到问题的情况下就做了选择：哪些信息重要、哪些可以丢弃。这等于放弃了未来提问时的选择权。
Mem++ 的设计哲学是：保留所有文档，把选择权推迟到读取时。 这在金融学里叫"延迟行权"，在记忆系统里叫"非破坏性写入"。
对 Agent 系统的启示
当前 Agent 记忆领域有一个明显的趋势：越来越复杂的写入时处理。MemGPT 让 LLM 自己决定何时压缩；Hindsight 让模型从交互中学习心智模型；AutoCompact 把压缩决策和任务奖励联合训练。
这些方法都在试图让"压缩"变得更聪明。但 Mem++ 走了另一条路：不要压缩，直接存。
这不是说压缩永远是错的——对于纯对话场景（LoCoMo、LongMemEval），压缩仍然有竞争力。但对于组织记忆场景——多人、多文档、多版本——非破坏性写入的优势是决定性的。
当信息来源是多作者的文档流，而不是单一对话历史时，写入时压缩的信息损失太大。
一个更根本的问题
Mem++ 暴露了一个更根本的问题：我们为什么默认要压缩？
可能是因为 RAG 的范式太深入人心了——"检索增强生成"暗示了先检索再生成，而检索的对象通常是压缩后的知识片段。可能是因为存储成本在历史上是瓶颈，"压缩"成了默认的好习惯。
但在 2026 年，存储成本已经不是主要矛盾，LLM 的上下文窗口已经从 4K 涨到 128K 甚至更长。真正稀缺的不是存储空间，而是信息的完整性。
Mem++ 的贡献不是发明了一个新算法，而是质疑了一个被广泛接受的默认假设。有时候，最好的创新不是"做得更聪明"，而是"不做"。
论文：Mem++: Non-Destructive Memory for Long-Term Organizational LLM Agents