这篇 Zero-Mem 挂在 arXiv 上，7 月 31 号的。我在几个群里看到转的全是同一句——“零 token 记忆，记忆操作不调 LLM、不花 token。”然后就没有然后了。没人往下解释它靠什么做到，也没人反过来问一句：如果记忆操作能零 token，那前两年大家在 LLM agent 里辛辛苦苦搭的那层“记忆模块”，到底在干嘛？
这个反差才是这篇论文真正戳人的地方——不是那个数字，是它顺手把一堆人的记忆层给掀了。
Zero-Mem 干的事，一句话说完：原始交互轨迹是唯一 source of truth，组织、索引、检索、冲突消解全是确定性套路，不调 LLM。两个视图：实体-上下文图，管跨交互的网状连接；时间层级，管会话内的线性局部性。查询的时候两边加权检索，按图和时间结构恢复支持关系和上下文；校准器先丢冲突证据；最后才轮到 LLM 上场，读检索回来的轨迹答题。
到最终问答那一步之前，整条链零 token。这不是优化出来的，是构造上就成立的——一个完全不调 LLM 的流程，token 消耗当然是零。很多人的兴奋点全打在“零 token”三个字上，把一个定义式的事实当成了发现，反而把真正的发现漏了：它证明了要记住过去，不必先用 LLM 把过去压成一份中间表示。
按我理解，骨架大概长这样：
trajectory = [原始交互，一字不改] # 唯一 source of truth
view_graph = build_entity_context(trajectory) # 图：跨交互连接
view_time = build_temporal_hierarchy(trajectory) # 时间层级：会话局部性
candidates = weighted_retrieve(query, [view_graph, view_time])
clean = calibrate(candidates) # 确定性地丢冲突证据
answer = reader(clean) # 唯一一次 LLM 调用
关键就在中间那两行视图。别以为这是为了对称摆两个索引。原始轨迹里本来就有两种完全不同的结构维度：跨次会话里的实体和上下文是网状的，一次会话内的先后是线性的。一个扁平的向量相似度检索撑不住这两件事同时成立——网状关系在扁平空间里被压扁，先后顺序在相似度里基本消失。所以它拆开，分开建模，查询时再按相关性加权。这不是什么新鲜的算法，这是老老实实承认数据里有两层结构，然后各干各的活。
前两年 agent 记忆模块的主流做法，是让 LLM 自己在 session 结束的时候抽关键信息、写总结、生成 reflection，塞进向量库，下次查询拉出来用。听着高级，工程上这是在干什么？是让一个生成模型去当历史的压缩器。每次压缩都有信息损失；每次写入都可能写错；而且写错是欠的债，查询时不会自动还——你检索到的是一个已经错了的中间表示，不是历史本身，但你的 reader 分不清这二者的区别，它会把那个错当成历史来读。这就是半桶水记忆层的死法：用最聪明的东西去干最不适合它干的活。
Zero-Mem 的消融实验支持了两视图和查询相关性的贡献，结论甩得很硬：结构化 agent 记忆不靠生成对过去的中间表示也能成立。这句话值得单独立一块碑。
性能那边，在和相同的最终问答 reader、相同的上下文预算下，它比最快的基线把记忆操作时间成本降了 57.6%。注意“相同 reader、相同预算”这个前提——这是把记忆层之外的东西全锁死，只测记忆这层值多少。太多人做对比喜欢顺手换个更强的 reader，再说是记忆模块的功劳。这篇没有。reader 是同一个，预算是一样的，差出来的那 57.6% 才是记忆操作真正省掉的。这种测法我认。要跟我谈 benchmark，先学会把变量控制到只剩一个，再拿数字来。
还有一处我特别在意：校准器是“先丢冲突证据”，不是“先调和冲突”。差别在哪？调和是判断——两条证据打架，哪条可信，往往要结合当前问题来下注。判断该放在 reader，不该放在记忆层。记忆层的职责是如实呈现冲突，不是自作主张消灭冲突。让检索层保持“诚实的冲突”，把裁剪权留给最后那个唯一有资格调 LLM 的地方，这是把边界划对了。反过来，我在不少 agent 框架里见过在记忆层里就调一次 LLM 去“消解”冲突——那等于在档案室里请了个临时工替你改档案。
这论文没过同行评审，代码和实现细节要等评审后才公开。所以“有竞争力的性能”这几个字，现在先打问号。但“零 token”这件事，不看代码也不会错到哪去——记忆操作不调 LLM，零 token 是构造保证，不是一个需要复现才能信的实验结果。真正要盯的是它没放出来那部分：在省掉这一切之后，竞争力保住了没有。标题里最抓人的反而最不用怀疑，剩下那部分才决定它到底是不是一篇硬货。要让我改观，拿代码和复现来，别拿群里的转发截图。
这篇论文出来之后，我大概能预见到接下来会发生什么——会有人立刻把“零 token 记忆”包成一个 MCP server，或者做成一个 memory 中间件，对外喊“给你的 agent 接上零 token 记忆”。这就是本末倒置的下一轮。论文的原意是减少中间层，产业化的第一反应是再套一层中间层。论文说不需要生成对过去的中间表示，产品说“用我这个中间件就不用生成中间表示了”——后者听着像在复读前者，实际是在给那个刚被拆掉的记忆层换了张皮再刷一遍漆。给烂地基刷漆，刷得再亮，地基还是烂的。
现在如果你正在做 agent 记忆，这篇论文该给你按下这个顺序：先问新的交互能不能由历史直接回答。能直接回答，就别让 LLM 生成中间表示——中间表示是写入时的一次性错误，查询时还不会纠正。再问历史里到底有几种结构。跨会话的连接和会话内的局部性不是一个维度，一个 flat embedding 扛不住两个。分开建模，查询时再合并。最后才轮到 token。省 token 是前面两步做对之后的账单，不是设计目标。先看到“零 token”就冲，冲完发现场景里检索不出来，再回头在记忆层塞 LLM 补洞，补完说“检索不行”——这不是检索不行，是你没先把结构想清楚。
我的态度很明确：Zero-Mem 真正值得抄的不是“零 token”这张皮，是它把 agent 记忆从生成拉回检索这件事。它证明的不是“又多了一个省钱技巧”，是“你那个让 LLM 天天总结自己、写自己日记的记忆模块，本来就不该存在”。先把历史当数据想清楚、把结构搭明白，再谈要不要让 LLM 替你记。基础功没有捷径，记忆这层也一样——沙子上盖楼，楼越高越吓人。