Agent跑16步成功率跌至0%！微软LinkedIn三篇论文揭「记忆」致命缺陷，benchmark全在骗人？

你有没有过这种感觉，Agent用着用着，越来越笨了？

不是那种一开始就不行的笨。是刚开始挺好的，给它一个任务，刷刷刷就搞定，你还挺兴奋，觉得这玩意终于能用了。然后你开始让它干更长的活儿，串更多的步骤，结果它就开始丢三落四，前面说过的事情后面又问你一遍，明明刚交代过的上下文，转头就忘得一干二净。

我最近用Claude Code跑一个比较复杂的重构任务，大概要改十几个文件，前面几步改得非常漂亮，到后面就开始出幺蛾子，把前面改好的东西又改回去了，有些约定好的命名规范到第八步就完全抛到脑后。我一度以为是我的prompt写得不好，反复调了好几版，结果还是这样。

后来我才发现，可能不是我的问题。

这两天同时冒出来三篇论文，来自微软、LinkedIn和一个独立研究者，三个团队互相不认识，研究的角度也完全不同，但最后指向了同一个结论，当前Agent最大的瓶颈，跟推理能力无关，跟工具调用也无关，就是「记忆」这件事，从根上就没做对。

我把这三篇论文翻了个底朝天，越看越觉得，这不是三个独立的发现，这是同一种病的三份诊断书。

顺着这个思路聊聊。

第一份诊断书来自微软。论文标题就很扎心，「How Fast Do Agents Rot?」，Agent腐烂的速度有多快。

他们做了一个规模挺大的实验，9个模型，从12亿参数的小模型到6710亿参数的旗舰，包括3个正在商用的闭源系统，4种任务类型，跑了10664条完整轨迹。就为了回答一个问题，Agent在短任务上表现很好，到底能撑多久。

答案是，撑不了多久。

在ToolQA这个需要调用工具的任务上，所有模型在2到4步的短任务里都接近满分。但是当步骤增加到16步，成功率就跌到了0到33%。你没看错，有些模型到16步的时候成功率是零。。。不是下降了一点，是从接近100%直接掉到接近0%。

而且这个衰减不是随机的，它服从一个非常优雅也非常残酷的数学规律，几何衰减。每走一步，都有一个固定的概率会出错，这个概率虽然很小，但它是乘上去的。0.95的16次方是0.44。0.9的16次方是0.19。这就像一根多米诺骨牌链，每一张牌倒下去的概率不用很高，链条够长，最后一张一定会倒。

但真正让我觉得有意思的是他们的另一个发现。很多做Agent的团队遇到长程衰减的第一反应是什么？砍上下文。觉得上下文太长了，模型lost in the middle嘛，把历史记录压缩一下，只保留最近的几轮，应该就好了吧？

结果恰恰相反。缩短上下文窗口之后，衰减反而变得更陡了。 logit斜率从-0.44直接陡到了-0.69，p值3乘以10的负6次方，统计上板上钉钉。

这件事之所以重要，是因为它否定了一个很多人默认的假设。大家以为Agent变笨是因为上下文太长记不住，但实际上Agent变笨是因为步数太多，每一步的小错误在累积。你砍掉上下文不仅没帮忙，反而把Agent赖以维持连贯性的线索也砍掉了，等于在一个正在失忆的人面前，把他的备忘录也没收了。

微软最后给出的数据更让人冒冷汗，把他们测出来的per-step reliability投影到真实的生产环境长度，GAIA级别的任务只剩0.42的成功率，如果是百步级别的生产流水线，只剩0.24。

也就是说，你在benchmark上看到的那些90%以上的通过率，放到真实工作流里，可能连四分之一都不到。

好，这是第一种失忆，短期记忆衰退，走着走着就忘了自己在干嘛。

回到「记忆」这个话题，第二份诊断书更有意思。LinkedIn的两位研究员Ankit Goyal和Jaideep Ray问了一个大家其实都遇到过但很少认真想过的问题，你给Agent换了一个新模型之后，它之前记住的东西还在吗？

他们设计了48条合成历史，用两个开源模型Llama 3.1 8B和Qwen 2.5 7B来做实验。每条历史都有精确的、可验证的答案，不靠大模型来打分，是真正的硬指标。然后他们把同一份记忆用四种方式存储，原始对话全文、RAG分块检索、模型自己写的压缩笔记、还有固定schema的知识图谱。存好之后，把读记忆的模型换掉，看看会发生什么。

结果非常魔幻。

固定schema知识图谱几乎不受影响，换模型之后准确率只变化了0.0004。你想想，0.04个百分点，约等于没变。因为schema是人定的，不管哪个模型来读，「project-A -- deadline -- Friday」就是这个意思，没有歧义空间。

但模型自己写的压缩笔记就完全是另一个故事了。同一对模型，从Llama写Qwen读，准确率涨了9.91个百分点。反过来，从Qwen写Llama读，准确率跌了13.28个百分点。 同一对模型，换个方向，结果直接反转。

你品品这有多荒谬。你以为你在升级模型，实际上你在赌博。赌的是新模型能不能读懂旧模型写的笔记。而且这个赌局连方向性都没有规律可循。

RAG的情况也好不到哪去。他们测了一个很多团队在实际中会做的事情，模型升级了但embedding index没有全量重建，只是新的数据用新embedding，旧的数据保留旧embedding，做了一个50/50的混合索引。结果呢，全量重建能带来11.9个百分点的提升，但混合索引只捕获了4.96。连一半都不到。

而且他们做了一个很精细的诊断，把记忆失败拆成了三个阶段，写入的时候丢了信息、检索的时候取错了、读取的时候理解错了。结果发现，NOTES模式80%的问题出在写入阶段，信息在被压缩成笔记的那一刻就已经丢了。RAG模式81%的问题出在检索阶段，信息其实存着呢，但搜索的时候没找到对的那条。

最扎心的是修复实验。如果你手里只有压缩后的笔记，没有保留原始对话历史，那么store-only repair在全部48个测试用例里，没有一个能恢复到90%以上的水平。一个都没有。但如果你保留了原始对话历史，34个用例里都能恢复。

这篇论文最后的结论写得很克制但很致命，记忆应该被视为Agent的长期组成部分，而不是当前模型的临时输出。

坦率的讲，我觉得这句话戳到了大部分Agent产品的痛处。现在市面上绝大多数Agent的记忆方案，说到底就是让当前模型把对话压缩成一段摘要，然后塞进下一轮的system prompt。这种做法的隐含假设是，模型能完美地把重要信息提炼出来，而且未来的模型也能完美地理解这些提炼。但LinkedIn的实验告诉你，这两个假设一个都不成立。

第二种失忆，升级性失忆。你换了一个更聪明的脑子，但这个新脑子读不懂旧脑子的笔记。

顺着上面的再聊聊第三份诊断书，这篇的角度最奇特。它不是研究Agent怎么忘事的，它研究的是Agent怎么「记太多事」的。

研究者爬了1867个GitHub仓库，追踪了247694条指令的完整生命周期。这些指令来自CLAUDE.md这类Agent配置文件，就是你告诉Claude Code「在这个项目里，你要遵守这些规则」的那个文件。

他发现了一个非常直觉但之前没人量化过的现象，这些文件只会变大，几乎不会变小。 生命周期内平均增长226%，超过三倍。每次commit平均净增4.9条指令。而且指令越老，被删掉的概率就越低，log-hazard值是每commit -0.032。如果是多人协作的仓库，这个衰减还会更快。

想想你自己的经验是不是也这样。某天Agent犯了一个错，你加一条规则，「永远不要在生产环境直接执行删除操作」。过了三个月，你已经忘了当初为什么加这条规则了，但你不敢删。因为你不知道删了会不会又出那个bug。于是它就一直留着。然后又有人加了一条，又有人加了一条。

这个研究者给这种现象起了一个非常精准的名字，叫「灾难性记忆」，catastrophic remembering。跟深度学习里那个著名的「灾难性遗忘」刚好是镜像。灾难性遗忘是模型学了新东西忘了旧东西。灾难性记忆是反过来，指令留存了下来，但当初写这条指令的理由消失了。

这有什么后果呢？你的CLAUDE.md变成了一座规则的坟场。每条规则都曾经有意义，但现在你分不清哪些还有用，哪些只是历史遗迹。而Agent在每次执行任务的时候，都要把这座坟场从头到尾读一遍。规则之间可能自相矛盾，可能有些已经被代码变更淘汰了，但Agent不知道，它只能老老实实全部执行。

好在这篇论文不只是提出问题，它还给了一个解法。做法说出来你可能会觉得太朴素了。就是给每条指令加注释。写清楚这条规则是因为什么失败加上去的，当时的假设是什么，验证的结果是什么。然后把注释对执行模型隐藏，只给维护者看。

效果呢？在51步的IFEval设置里，加了注释之后，excess prompt size从+211.3%降到了+1.4%。 因为维护者终于能判断哪些规则已经过时可以安全删除了。

他们还做了一个对照实验，往指令里填充同样长度的噪声文本，看是不是单纯因为文本变长了所以有效果。答案是没有。是注释里保留的理由在起作用，不是注释本身。

论文最后一句话让我反复琢磨了很久，「If English is the new code, why don't we have comments yet?」

如果自然语言是新的编程语言，为什么我们还没有注释？

好了，三份诊断书摊在桌上了。微软说Agent走着走着就忘了自己在干嘛。LinkedIn说你给Agent换个脑子，旧记忆就废了。GitHub实证说Agent的配置文件只会膨胀不会收缩，最后变成一堆没人敢碰的规则遗迹。

三种症状，三个团队，三个完全不同的实验设计，但你把它们拼在一起看，会发现它们描述的是同一个人。一个短期记忆在衰退的人，一个换了身体就认不出自己日记的人，一个把所有便利贴都贴在墙上但已经忘了每张便利贴的含义的人。

这不是三个独立的bug。这是同一个架构缺陷的三种表现。

我自己的感受是，现在整个Agent行业对「记忆」的理解，还停留在一个非常粗糙的阶段。大部分产品的做法就是把对话历史塞进上下文窗口，窗口不够了就让模型自己总结一下，总结完把原文扔掉。这就像一个人每天晚上睡觉前把当天的日记撕掉，只在脑子里默念一遍「今天最重要的事是xxx」，然后第二天靠这句话过日子。

能不能用？短期能用。能用多久？微软告诉你，16步。

我觉得这三篇论文加在一起，其实在说一件更大的事。我们一直在卷模型的推理能力，在卷它能不能写出更好的代码，能不能解更难的数学题，能不能通过更多的benchmark。但很少有人在认真做记忆这件事。

因为记忆不性感。记忆不会出现在benchmark的排行榜上。没有哪个模型发布会上会说，我们的新模型记性特别好。

但记忆才是Agent从「能做demo」到「能上生产」的那道坎。你能做一个跑两步就很惊艳的demo，但你做不了一个跑一百步还稳定的产品。因为一百步之后，你的Agent已经忘了第三步的约定。

说真的，我有时候觉得这整件事有点讽刺。我们造了一个能写代码能做数学的超级大脑，然后发现它的记忆系统还不如一个纸质笔记本靠谱。笔记本至少不会自己偷偷把内容改了，也不会因为你换了一支笔就认不出之前写的字。

LinkedIn那篇论文里有一句话让我印象很深，记忆应该比创造它的模型活得更久。

你想想这个要求有多朴素。一本笔记不应该因为你换了一个大脑就变成天书。一条规则不应该因为没人记得当初为什么写它就变成永恒的诅咒。一个Agent不应该因为多走了几步路就忘了自己是谁。

这些听起来是不是特别基础？但我们现在就是连这些基础的事情都没做到。

我最近在想，也许Agent的发展路径会跟数据库的历史有点像。早期的数据库也不怎么关心持久化和一致性，数据丢了就丢了，重来一遍。后来出了事故，大家才开始认真搞事务、搞WAL日志、搞多副本。记忆对于Agent，可能就是持久化对于数据库。不是一个feature，是一个基础设施。

只不过这一轮，我们要持久化的不是数据，是经验。不是表里的一行记录，是Agent在第三步犯了错、在第七步学到了教训、在第十二步形成了判断这整条因果链。

如果这条链断了，Agent就只是一个每次都从零开始的新手。不管它的底座模型有多强大。

论文的最后那句话说得好，如果英语是新的编程语言，那我们确实该给它加上注释了。

不过我觉得还可以再往前走一步。也许我们不只需要注释。也许我们需要的是给Agent的记忆系统做一次彻底的重新设计，像当年从文件系统进化到关系型数据库那样的重新设计。

但这件事什么时候会发生，我也不知道。我只知道现在三篇论文已经把病因写得很清楚了。剩下的就是看谁先动手治。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。