Anthropic 的记忆实验：九份笔记拿四个徽章，四百多份只拿一个

一句话定位：这不是"它记得多不多"，而是"一条错的东西能活多久、能扩散到多远"——被测对象是记忆的信噪比与传播路径，不是召回率。同样的断言可迁移到知识库检索、多轮对话上下文、配额缓存、配置中心等任何"读到的可能是旧值"的场景。

摘要

Anthropic 在 2026 年 11 月 6 日的工程博客里公开了一组对 Agent 记忆的评测：旧模型存了 413 份记忆文件只拿到一个徽章，新模型只存九份拿到四个。同一天发布的"做梦"机制能在后台比对会话记录修正错误笔记，但也存在把错误笔记推进到每一轮会话的风险。这篇把记忆验收拆成四个可测维度，并给出判定器该写在哪一层。

一万步左右，两套记忆策略，差距是这样的：一套存了 413 份记忆文件，分布在 225 个文件夹里，拿到一个徽章；另一套只有两个文件夹、九个文件，外加一个顶层 global.md，拿到四个徽章。

这是 Anthropic 在 2026 年 11 月 6 日发布的工程博客中给出的对比，任务是在《宝可梦 红》里通关，作者 Lance Martin。原文对差距的解释不复杂：旧模型记下了屏幕本来就一直在显示的东西，比如金钱和位置，这些信息每回合都在变，存下来很快过期，查找还费时间；新模型留的是计划、策略和验证过的规则，这些内容只有自己写下来才存在。

对做测试的人来说，这组对比真正的价值不在"少即是多"这个结论，而在它暴露出记忆这件事有独立的失效模式。记忆不是上下文的延伸，它是一个会被写入、被检索、会过期的持久化存储。 写入策略、检索开销、内容时效、错误传播，这四件事每一件都能单独出故障。

原文自己也划了边界：这组对比是一次单独运行，不能当作统计结论。下面所有分析都在这个前提下进行。

记忆的四个层次，决定了你能在哪一层写断言

官方把 Agent 记忆分成四层，从下到上依次是：可搜索的会话记录、Agent 自己写的记忆笔记、由笔记构建的结构化表示（比如互相链接的 wiki）、以及每次会话开始时注入的上下文。

这四层不是纯粹的分类学，它决定断言写在哪。

会话记录层可以断言完整性和可检索性。说白了就是：这件事发生过，事后能查到。这一层出问题最典型的表现是"复盘时找不到当时为什么这么决定"。

笔记层可以断言内容质量。笔记里有没有把已验证事实和未验证猜测分开，有没有记录规则成立的依据。原文提到 Opus 4.7 把笔记合并成一份参考文档并开始标记哪些事实已核对、哪些还未确认，Opus 5 是第一个闭环的——它的大部分条目包含一条规则、这条规则为什么为真、对早前问题的回答，以及沿途发现的陷阱警告。

表示层可以断言结构与一致性。wiki 页面之间有没有互相链接、同一个事实有没有在不同页面出现冲突表述。

注入层只能断言范围和来源。每次会话开头注入什么，是成本最高也最危险的一层，因为注入的内容会进入每一轮。

原文有一句话说得很重：一条被提升到注入上下文的错误笔记，会扩散到每一次会话。这句话应该被写进任何记忆系统的验收清单第一行——注入层没有"局部错误"这个概念。

四百多份为什么更差：三个可以分别测的成因

把"笔记多反而差"当成一个笼统的现象，是没法测的。我把它拆成三个可以分别构造用例的成因。

第一个是重复存储。笔记里存了屏幕每回合都在显示的状态，等于把瞬时状态固化成了持久事实。测法很直接：让 Agent 跑一段任务，然后检查它的笔记里有多少条目描述的是"当回合可观察、下回合即变化"的信息。这类条目占比高，就是写入策略过宽。

第二个是检索成本。笔记越多，找一条相关内容要翻的页越多，而这个开销会挤占真正用于任务的步骤预算。原文的描述是这些过时的内容"查找起来还费时"。这一条可以用步骤数间接量化：同等任务复杂度下，带记忆运行的步骤数如果持续高于无记忆基线，而任务成功率没有提升，说明检索开销吃掉了收益。

第三个是互相矛盾。同一件事在不同笔记里有两种写法，Agent 读到哪份就按哪份做。这类问题的表现是行为不稳定，而不是明显错误，最难排查。测法是做一次笔记一致性扫描：把笔记里所有"数值型事实"和"状态型事实"抽出来比对，出现同主体多值即为冲突。

三个成因对应三种修法，所以必须分开测。混在一起看，你只会得出"记忆效果不好"这个既不能归因也不能行动的结论。

那条写错的笔记，是怎么一路传下去的

官方记录了一个很适合当教材的案例：一条关于宝可梦中心位置的记忆写错了，导致 Agent 连续三次从一处单向悬崖上掉下去。在一次"做梦"过程把这条笔记与会话记录比对并纠正之后，另一次运行直接穿过山洞到达了下一个城市。

这里要分清两件事：一次是"笔记错了"，一次是"错了之后还在用"。

笔记写错是写入质量问题，无法完全避免。真正致命的是第二条——错误笔记被检索出来、被当作可信事实、并且没有任何环节质疑它。原文对这个机制的表述是，原始会话记录充当真相基准，Agent 逐条核对笔记，发现不符就重写。

所以记忆系统里必须有一个"核对"环节，而测试要验证的正是这个环节存在且有效。可执行的用例是注入一条已知错误的笔记，检查下一轮任务中 Agent 是否会因为这条笔记做出错误动作，以及是否在做出动作前出现任何纠正行为。这条用例有两个方向：完全不纠正算失败；纠正了但代价是任务步骤翻倍，也要记录，因为这说明核对太粗。

顺带提醒一个反直觉的发现。原文说，对更强模型来说，给它们讲清"记忆是用来干什么的"比给它们规则更有效；而当把 Opus 5 限制为"只记失败"时，它从记忆里获得的收益减少了 0.234。也就是说，规则过细会削掉判断力。

这条对测试的含义是：不要用"笔记条数""是否遵守写入规则"作为验收指标。规则遵守得好，未必代表记忆有用；反过来，一个看起来"没按规矩来"的写入策略，可能在任务指标上明显更好。验收要落在任务结果和故障率上，而不是写入行为的合规度。

能力验证的两种口径，别混着报

原文里还有一组大规模的例子，用来验证记忆在真实文档库上的效果。约 35 万份文件、约 4.2 亿 token 的语料，128 次会话构建出一个 wiki，页面从 103 页增长到 222 页；用 25 个问题评测，仅用 wiki 时评分标准达成率从 13% 提升到 48%；wiki 加搜索达到 61%，而纯搜索是 53%，每题大约节省 2 万 token。

这里有个容易被忽略的细节：同一篇原文也写了 wiki 不一定有用。在答案都落在单份文档里的任务上，没有明显收益；在另一个任务上，wiki 的大小长到了源文件本身的 1.77 倍。文章列出的局限也很直白：几个结果来自单次运行，题目集只有 24 到 25 题。

这组信息对验收最实际的意义是：记忆类改动必须按任务类型分组验收。答案集中在单文档的任务、需要跨多文档综合的任务、需要时序推理的任务，这三类对记忆的敏感度完全不同。用一个大平均分去验收，会把"多文档综合提升很大、单文档毫无变化"这种真实情况抹平成"略有提升"。

我建议的验收表结构是这样的。

最后一列不是装饰。每一行都必须能对应到一个具体的官方失效样本，否则这一行很可能只是想象出来的风险。

什么时候不该上记忆

写完上面这些，我想补一句原文没有明说、但在实践里很常见的判断：有些场景不该上记忆。

判断依据可以简化成两个问题。这件事下次真的会再用到吗？如果用不到，那存下来只是给检索增加负担。这条信息过期的速度有多快？如果几分钟内就失效，那它更适合放在上下文里，而不是持久化存储里。

原文对记忆的定义本身就限定了范围：记忆是 Agent 从经验中获得、并在会话之间保留的可读上下文，它不包括权重变化、单会话内的学习，也不包括压缩。这个定义反过来给了测试一个边界：凡是落在"压缩"和"单会话学习"里的行为，不应该用记忆的验收标准去衡量。

把这条边界讲清楚，能省掉很多无效争论。团队里常见的分歧是"这个功能到底算不算记忆"，而实际上它可能只是上下文压缩，验收标准完全不同。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。