一条基于运气的笔记，压过了几百次记录
让智能体跑完一轮就把经验写下来，下次开新会话前先读一遍，这是当下很主流的自改进做法。它便宜、不需要改权重、还能跨会话积累。arXiv 2610.33029 问了一个很窄但很要命的问题：如果那条经验是基于纯粹坏运气写出来的，会怎样。
研究者的设计相当克制。他们造了 256 个虚构的重复工作场景，比如导出数据、寄送发票，每个场景里都有两款可以互换的工具：一款可靠，历史上几百次运行的成功率在 80% 到 93% 之间；一款明显更差，只有 50% 到 70%。在每个场景里，智能体都正确地选了那款好工具。
关键的一步是：这一轮的结果是人为指派的。有时成功，有时随机失败——而这次失败与决策质量毫无关系，是纯运气。随后模型按 ReasoningBank 方法，根据这个结果写下一经验条目存进记忆。
11.6% 对 0.4%
然后研究者开一个干净的全新会话，让它扮演读者：这个会话能看到完整且准确的历史日志，知道上一轮的结果，再让它为下一个任务选工具。
结果落差很大。记忆里放中性提示时，模型选到更差工具的比例是 0.4%；放的是「好工具成功后写的经验」时，同样是 0.4%；而当记忆里是那条「好工具随机失败后写的经验」时，这个比例升到 11.6%。
换句话说，一次不走运被写成文字之后，它的分量超过了几百次跑出来的统计记录。研究一共收集了十一款模型的 90084 次响应，其中六款表现出明显易感性，另外五款 Claude 与 GPT 模型低于 10%——但没有一款归零。
改两句提示词能压下去，但压不到零
论文也试了缓解办法，而且效果显著。在提示词里加三句话，要求模型评价决策本身而不只是结果，错误率降到 7.5%。再把指令改成对成功与失败两种结果统一处理、并明确给出「无需改动」这个选项，降到 3.1%。
两个数字都远好于 11.6%，但都不是零。这一点才是真正要记住的：这是模型处理文本经验时的一种系统性倾向，不是某个实现里的 bug，因此也不会被某次提示词调整彻底消除。
它和「把教训写进权重」是什么关系
本站不久前记过一份方向相反的工作：让智能体把纠错经验蒸馏进低秩适配器存进经验库，底座与旧适配器都冻结，需要时按任务相似度挂载。那份工作在三套环境上拿到 8.9 到 17.0 个百分点的整体提升，思路是让教训真正被记住。
两份放在一起看，就构成了一个完整的两面。一面是教训记不住，于是换个会话又摔进同一个坑；另一面是教训记得太牢，而这条教训本身可能是错的。自改进系统的默认假设是「写下来的经验是资产」，这份研究证明它同样可能是负债，而且负债的表现形式很隐蔽——日志齐全、统计显著、每一步都合规，只有那条笔记是错的。
还有一层更现实的含义。在真实系统里，随机失败远比实验里常见：网络抖动、第三方接口临时不可用、并发下的资源争用。这些事件的共同点是与工具本身的质量无关，但它们同样会被写进笔记。一个长期跑着的自改进智能体，如果只按结果归因，工具偏好迟早会被这类噪声带偏。
能做什么，以及这篇证据的边界
能做的有两件。其一，写经验的时候要求模型同时记录归因——这次失败是工具的问题、参数的问题，还是环境的问题——而不是只记录结果。论文里那三句话起作用的机制大概就在这里。其二，给记忆条目配上计数器：一条经验的依据是几次观察，而不是只有一次。
边界也要说清楚。256 个场景是虚构的重复工作任务，两款工具的可靠性差距被设定得很明确，真实环境里的工具选择往往更复杂。实验采用预注册设计，协议、代码与测试数据在正式运行前经 Zenodo 与比特币区块链时间戳冻结，这一点是可信度上的加分项。但公开摘要未给出逐款模型的具体数值与场景清单，这些细节目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。