Zero-Mem：LLM Agent 的记忆模块终于可以不烧 token 了

做 Agent 时绕不开一个矛盾：记忆模块越做越重，但每次读写都要额外调一次 LLM。写一条记忆要 token，读一条记忆也要 token，检索完再拼进上下文又是一轮。一个跑了几十步的 Agent，光记忆操作消耗的 token 可能比主任务还多。很多系统为了省 token，把原始交互记录压缩成摘要，丢细节不说，查起来还不放心——总觉得那个被合并掉的分支里藏着关键信息。

7 月底 arXiv 上线了一篇论文，标题就冲着这个痛点去的：Zero-Mem: Zero-Token Memory Operations for LLM Agents。核心主张非常激进——结构化记忆操作不需要生成，不需要额外调 LLM，不消耗任何 LLM 输入或输出 token。

怎么做到的？Zero-Mem 不做「写完对话 → 调 LLM 总结 → 存摘要 → 检索时再调 LLM 匹配」这套流程。它直接把原始交互痕迹当成唯一记录源，然后用两种方式组织这些痕迹。一种是实体-上下文图，把不同轮次里提到同一实体或话题的片段串起来；另一种是时序层级，按会话的局部顺序和状态组织。每次来一个新 query，系统同时查这两种视图，通过确定性校准先丢弃冲突证据，再把剩下的结构化上下文喂给最终的回答 LLM。整个过程只有最后一步调了 LLM。

论文给出的数据够直接：在长记忆和长上下文问答 benchmark 上，Zero-Mem 达到了有竞争力的准确率，同时把记忆操作的时间成本比最快的基线降低了 57.6%——这是跟最快的基线比，不是最慢的。而且全程不消耗 LLM token，账单干净，记忆模块跑再多步也不额外烧钱。

从开发者角度看，这个思路的吸引力不在理论优雅，而在工程直觉。带长期记忆的 Agent 一直面临一个两难：要么靠额外 LLM 调用做精细检索，项目后期 token 成本失控；要么硬压缩记忆，丢信息、丢可追溯性。Zero-Mem 相当于给了第三条路——不压缩、不额外调用，靠结构化的原始痕迹做检索。代价是编码器计算单独算，但那比 LLM 调用便宜一到两个数量级。

论文提交于 7 月 31 日，代码会在同行评审后开源到 github.com/TheMoon0815/Zero-mem。目前源码还没放出，但架构已经写得足够清楚，有兴趣的可以先把论文扒下来读一遍，特别是 ablation 部分，实体-上下文图和时序层级各自的贡献拆得很干净。

不过也得留个心眼。57.6% 的时间节省是在特定 benchmark 和上下文预算下测的，实际生产环境里的 session 长度、检索分布、延迟要求都不一样。编码器计算听起来便宜，但要塞进实时推理管线，中间那层图的构建和维护也得算进延迟。

但方向是对的。Agent 记忆不应该成为第二个 LLM 调用入口，它应该更底层、更安静。Zero-Mem 至少证明了一件事：不需要为记住而生成。

相关链接
- 论文页面：https://arxiv.org/abs/2607.29377
- GitHub（待开源）：https://github.com/TheMoon0815/Zero-mem