Zero-Mem：给 AI Agent 的记忆系统做"减法"，零 token 完成所有记忆操作

你有没有这样的经历：跟一个 AI 助手聊了三天，第四天你问它"上周我说过我喜欢什么口味的咖啡"，它开始翻聊天记录——但翻记录这个动作本身，又花掉了你大量 token。

每次它要"回忆"，就得调用一次大模型来总结、提取、检索过去的对话。记忆越积越多，"回忆"的成本也越来越高。这就好比你每次想想起一件事，都要重新把过去十年的日记从头到尾读一遍，然后写一份摘要——光回忆本身就耗尽了你今天的精力。

Zero-Mem 提出了一个激进的问题：记忆操作真的需要调用大模型吗？

论文地址：https://arxiv.org/abs/2607.29377
代码仓库：https://github.com/TheMoon0815/Zero-mem

现有 Agent 记忆系统的"生成税"

要理解 Zero-Mem 为什么重要，先得看清现有系统的问题。

当前主流的 Agent 记忆系统——Zep、Mem0、A-Mem、MemoryOS、GAM——都在做一件事：用大模型来管理记忆。具体来说，它们让 LLM 来做这些事：

1. 总结：把长对话压缩成要点
2. 提取：从对话中抽取实体、关系、事件
3. 更新：新信息来了，合并、修改、删除旧记忆
4. 检索：用户问问题时，用 LLM 来判断哪些记忆相关

这些操作每一次都是一次 LLM 调用，每一次都消耗 input + output token。一个长对话可能有几百轮交互，记忆操作可能被触发几十次。这就是"生成税"——你不仅要为最终回答付费，还要为"回忆"付费。

更深层的问题是：生成即丢失。当你把原始对话压缩成摘要时，你丢失了细节。当你把多次对话合并成一条记忆时，时间线模糊了。当你用 LLM 来"理解"记忆时，它可能引入自己的幻觉。原始证据被层层抽象覆盖，最终回答的溯源链断了。

Zero-Mem 的核心洞察：不生成，只筛选

Zero-Mem 的核心思想可以用一句话概括：

记忆操作不需要生成，只需要结构化的筛选。

这就像图书馆管理。传统方式是：每来一批新书，就让一个图书管理员（LLM）读一遍，写摘要、分类、建索引卡。Zero-Mem 的方式是：书原封不动放上架，只建一个目录系统（实体图 + 时间层级），你查的时候按目录找，找到原书直接翻。

具体来说，Zero-Mem 保留了所有原始交互痕迹（trace），不做任何生成式抽象。它在这些痕迹上建了两个互补的"视图"：

视图一：实体-上下文图（关系视图）

Zero-Mem 用一个轻量级的命名实体识别模型（比如 spaCy，不是 LLM）扫描每段对话，提取人名、地名、机构名等实体。然后建一个图：

• 实体节点和上下文节点之间的边：表示某实体出现在某段对话中
• 上下文节点之间的边：表示相邻的对话片段

这个图记录的是"观察到的事实"——谁在哪里被提到过——而不是 LLM 推断的"谁和谁有什么关系"。

当你问"上周和小王讨论的那个项目进展如何"时，Zero-Mem 不会让 LLM 去总结所有关于小王的记忆。它做的是：

1. 从问题中提取实体"小王"
2. 在图上找到"小王"节点
3. 沿着边传播激活——找到所有包含"小王"的对话片段
4. 再沿着相邻边找到这些片段前后的上下文

这个过程用的是 Personalized PageRank（一种图算法），不是 LLM 生成。

视图二：时间层级（局部视图）

图结构擅长找关系，但不擅长找时间顺序。Zero-Mem 同时把对话组织成层级结构：

• Turn（轮次）：一次完整的问答交互
• Window（窗口）：几个相邻的轮次组成一个短窗口
• Episode（片段）：几个窗口组成一个完整的事件
• Local（局部）：某个候选证据的紧邻上下文

当你问"昨天下午三点左右我们聊了什么"时，时间层级视图优先被激活。系统从 Episode 到 Window 到 Turn 逐层缩小范围，找到那个时间段的对话。

双视图协调

Zero-Mem 的关键设计是：不同的问题需要不同的视图。

• "小王的项目进展" → 关系查询 → 图视图优先
• "昨天下午聊了什么" → 时间查询 → 层级视图优先
• "上次小王说项目延期了，后来怎么解决的" → 混合查询 → 两个视图都激活

系统用一个轻量级的查询分析器（不是 LLM）来判断问题的类型，然后给两个视图分配不同的权重。两个视图的检索结果融合后，进入"证据闭合"步骤——补充关系连接和局部上下文。

确定性校准：最后一道防线

检索到的证据在交给最终回答的 LLM 之前，还要经过两步确定性校准：

1. 证据校准：丢弃冲突证据（比如同一事实在不同时间有不同值，保留最新的），过滤不支持问题的内容
2. 回答校准：LLM 回答后，检查答案是否有证据支持、类型是否匹配、格式是否正确

这两步都是确定性规则，不调用 LLM。

关键数据：零 token + 57.6% 延迟下降

Zero-Mem 在多个长记忆和长上下文问答基准上测试，核心结果：

• 记忆操作 LLM 调用数：0（对比基线系统动辄几十次）
• 记忆操作 LLM token 消耗：0（encoder 计算单独计费，不算 LLM token）
• 记忆操作延迟降低 57.6%（对比最快的基线系统，使用相同的最终 QA reader 和等量上下文预算）
• 性能保持竞争力（不是最强，但在多个基准上与基线系统差距很小）

57.6% 这个数字值得展开。Zero-Mem 省掉的不只是 token 钱，更是时间。在 Agent 需要快速响应的场景里，记忆操作延迟降低一半意味着用户体验质的提升。

消融实验：两个视图缺一不可

论文的消融实验验证了每个模块的贡献：

• 去掉图视图 → 关系类问题准确率显著下降
• 去掉时间层级 → 时间类问题准确率下降
• 去掉双视图协调（只用一个视图）→ 整体性能下降
• 去掉确定性校准 → 答案可信度下降

这说明 Zero-Mem 不是"少做了什么所以更快"，而是"用结构化方法替代了生成式方法，同时保持了效果"。

这篇论文的深层意义

Zero-Mem 触及了 Agent 系统设计的一个根本问题：LLM 应该做什么？

当前的趋势是"万物皆 LLM"——记忆管理用 LLM，工具选择用 LLM，结果验证用 LLM。这导致 Agent 的每一步都是一次 LLM 调用，成本和延迟层层叠加。

Zero-Mem 提出了一个相反的思路：

LLM 应该只做它最擅长的事——理解问题、生成回答。其他所有结构化、可规则化、可算法化的操作，都应该用专门工具完成。

这个思路和 Euclid-MCP 的"让 LLM 当诗人，让 Prolog 当会计"异曲同工。也和 Rebucca 的"小模型初筛 + 大模型验证"思路相通。分工比统一更有效——这不是一个新发现，但 Zero-Mem 把它推到了极致：记忆操作的 LLM 调用数直接归零。

另一个值得关注的点是"溯源"（provenance）。Zero-Mem 强调每个记忆单元都保留原始文本、来源标识、时间戳。这意味着任何最终回答都可以追溯到原始对话。在 AI 系统越来越需要可审计性的今天，这个设计价值重大——你不能用一个 LLM 生成的摘要去解释另一个 LLM 生成的回答，因为两层幻觉叠加后无法溯源。

局限与展望

Zero-Mem 也有明显的局限：

1. 实体识别依赖外部 NER 模型：spaCy 的效果决定了图视图的质量。对中文、多语言场景，NER 质量可能不如英文。
2. 复杂推理需要更多：有些记忆操作可能确实需要推理（比如"根据用户过去三个月的行为推断偏好变化"），纯检索可能不够。
3. 基准测试有限：论文测试的是问答基准，真实 Agent 场景（多轮工具调用、多模态输入）下效果待验证。

但 Zero-Mem 的核心贡献不在于"比基线好多少"，而在于证明了一个可行性：结构化记忆操作可以完全不需要 LLM 生成。这个证明本身就有价值——它打开了一扇门，让后续工作可以在"零生成"的基础上叠加更复杂的结构化操作。

结语

Zero-Mem 让我想起一个古老的工程原则：最好的代码是没有代码。同理，最好的 LLM 调用是不调用。当你发现一个操作不需要 LLM 时，你不仅省了钱，还获得了确定性、可审计性和速度。

在 Agent 系统越来越复杂、LLM 调用越来越密集的今天，Zero-Mem 提醒我们：不是所有问题都需要用生成来解决。有时候，你需要的只是一个好的目录系统。

论文：https://arxiv.org/abs/2607.29377
代码：https://github.com/TheMoon0815/Zero-mem