

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


## 摘要

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


![8879521551b4002a7e79735f36008a95.jpeg](https://developer.qcloudimg.com/http-save/yehe-9678105/3b7c267a8568f23b63a8330cc839794a.jpg)

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

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

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

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

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

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/26dba411d83b803df8863d75228197f5.png)


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

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

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

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

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

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

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

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

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

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

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

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

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


![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/52fb5668555610db970b95cd0a6cc1e7.png)



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



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

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

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

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/cc33c6397e05205645bb91a3a1eeefa7.png)

所以记忆系统里必须有一个"核对"环节，而测试要验证的正是这个环节存在且有效。可执行的用例是注入一条已知错误的笔记，检查下一轮任务中 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 题。

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

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

| 验收维度 | 观测对象 | 通过口径 | 已知失效样本 |
|---|---|---|---|
| 写入质量 | 笔记条目类型分布 | 瞬时状态类条目占比低于阈值 | 记录屏幕已显示的位置与金钱 |
| 检索成本 | 完成任务步数、token 消耗 | 同等复杂度下不高于无记忆基线 | 413 份文件导致查找缓慢 |
| 内容时效 | 数值型/状态型事实一致性 | 同主体不多值 | 宝可梦中心位置写错 |
| 错误传播 | 注入错误笔记后的行为 | 出现纠正或拒绝使用 | 连续三次从同一悬崖掉落 |
| 任务收益 | 按任务类型分组的达成率 | 每组相对基线有增益或不降 | 单文档任务无明显收益 |

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

### 什么时候不该上记忆

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

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

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

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

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


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

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

人工智能

测试

数据库

记忆验收应聚焦信噪比与传播路径，而非召回率。Anthropic测试显示：413份记忆文件仅获一徽章，9份文件获四徽章。记忆分四层，各层独立失效。核心测错误笔记的扩散与纠正机制，写入质量、检索成本、时效、传播四维度需分别验证，并依据任务类型分组评估收益。

软件测试

Agent

腾讯云双十一大促

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Anthropic 的记忆实验：九份笔记拿四个徽章，四百多份只拿一个-腾讯云开发者社区-腾讯云

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐