一句话总结
Anthropic 于 2026 年 11 月 6 日发布智能体记忆研究：把会话记录写成可复用笔记，再用离线「dreaming」阶段校验、纠错并构建 wiki，在约 35 万个文件、4.2 亿 token 的内部语料上，25 道题的评分从 13% 提升到 48%；wiki 叠加检索时综合得分从 54% 升至 61%，单用检索为 53%。
事件概述
2026 年 11 月 6 日，Anthropic 工程团队在官方研究博客发布《The components of agent memory》，系统说明 Claude 在跨会话任务中如何组织记忆。文章把记忆定义为「Claude 从经验中获得、并在会话之间保留、以可读取的上下文形式保存的知识」，并明确把它与三类机制区分开：修改模型权重、单次会话内的上下文学习、以及压缩（compaction）。
文章的核心方法是把记忆分成两个阶段：会话进行中，Claude 把值得留存的事件写成笔记；会话之间，再由一个叫 dreaming 的离线阶段回放日志，对照原始记录校验笔记、纠正错误，并生成新的记忆表征。Anthropic 称，这一思路来自 Letta 与 UC Berkeley 提出的 sleep-time compute，即让模型利用交互之间的空闲时间重整上下文。
关键信息
| 项目 | 官方公布内容 |
|---|---|
| 发布时间 | 2026 年 11 月 6 日（官方标注 Nov 6, 2026） |
| 记忆形式 | 持久化文件（笔记、目录、wiki 页面），不修改模型权重 |
| dreaming 作用 | 回放会话日志、校验笔记、纠错、生成 wiki 等待检索表征 |
| 评测语料 | 约 350,000 个文件、约 4.2 亿 token，来自 2026 年 5 月收购的 Stainless |
| 评测规模 | 25 道题，128 个 dreaming 会话，Opus 5 智能体 |
| wiki 单独作答 | 从 2 个会话时的 13% 提升到 128 个会话时的 48%（按评分项计） |
| wiki + 检索 | 综合得分从 54% 升至 61%；单用检索为 53% |
| token 成本 | wiki 加检索每题约节省 20,000 token |
| 法律文档评测 | Harvey LAB 并购题 24 问：wiki 87%，单用检索 73% |
记忆的两层：笔记与 dreaming
Anthropic 把「写什么」视为对未来的预测：写下一个已验证的事实，等于预测未来会话可以直接依赖它而无需复核。不同代际模型在这件事上的表现差异明显。在 Continual Learning Bench 1.0 的数据库任务中，Sonnet 4.6 只会零散记录若干未经验证的猜测；Opus 4.7 把笔记合并成一份参考文档，并标注哪些事实已核查；Sonnet 5 在评分器确认答案后才标记为已确认；Opus 5 则首次形成闭环，多数条目同时包含规则、规则的验证方式与踩过的坑。Opus 5.5 与 Sonnet 5.5 同样形成了闭环。
在《宝可梦 红》的长周期测试中，记忆选择差异被量化。游戏进行到约 10,000 步时，Sonnet 3.7 写下了 413 个记忆文件、分布在 225 个文件夹，只拿到 1 枚徽章；Fable 5 只写了 2 个文件夹里的 9 个文件，外加一个顶层 global.md，拿到 4 枚徽章。官方分析称，Sonnet 3.7 把屏幕上每回合都能读到的状态（金钱、位置）也写进记忆，导致记录迅速过期，后期不得不花大量步骤整理记忆；Fable 5 只记录游戏不会直接告诉它的策略、计划与验证过的规则。
dreaming 的价值在于给笔记提供「真值」。在月见山悬崖的例子中，Claude 误记宝可梦中心在东侧，走出中心后写下「月见山已完成」，随即掉回原路；导航工具不显示落差，它连续三次坠崖后写下「我要停下来」。dreaming 把这条笔记与原始会话记录对照，发现方位记反，改写后 Claude 重新进入山洞并抵达下一座城市。
评测结果与成本
规模最大的一组评测使用 Stainless 的内部文档：约 35 万个文件、约 4.2 亿 token。Anthropic 构造了 25 道题，让 Opus 5 智能体在 128 个会话中逐步建 wiki，包括探索文件、编写与修正带链接的页面、合并重复内容、对照来源核查说法。
按官方数据，随着 dreaming 从 2 个会话扩展到 128 个会话，25 道题的评分项完成度从 13% 升到 48%。wiki 与检索结合时，综合得分随 wiki 成长从 54% 升到 61%，而只给检索工具时为 53%；同时每题约节省 20,000 token。
在法律文档场景，Harvey LAB 并购题中需要跨文档整合的 24 道题上，查 wiki 的得分为 87%，单用检索为 73%。另一个合同条款任务暴露了协作写入的问题：多个智能体同时写一张共享条款表，57 条中只有 41 条（72%）进入 wiki；改为每份合同单独一页、由单个智能体逐字引用条款后，57 条全部保留，评分项完成度达到 100%。
局限与适用边界
Anthropic 在文中列出多项限制，这些限制决定了该方法不能被无条件套用：
- 错误笔记会被反复注入。若一条记忆从开始就是错的，或被预加载进每个会话，错误会在后续任务中持续传播。
- wiki 存在膨胀风险。在一个 LAB 任务中，Claude 生成的 wiki 比原始文档本身还大，等于没有完成抽象。
- 检索仍然必要。当答案只存在于单个文件时，直接检索与 wiki 效果相当；wiki 的优势主要出现在需要跨多份文档整合的任务。
- 成本发生在会话之外。dreaming 需要额外算力，只有当任务足够长、足够重复，能够摊薄整理成本时才划算。
- 注入层必须保持很小。Claude Code 的 auto memory 只加载 MEMORY.md 的前 200 行或 25 KB 作为索引，官方文档提示更长的指令文件会降低遵循度。
官方同时说明，对更强的模型，给出「记忆用来做什么」的简单指引比规定固定规则更有效。测试中把规则设为「只记录失败」时，Opus 5 与 Opus 4.7 从记忆中获得的提升都明显缩水。
行业影响
这篇研究给出的可迁移结论有三点。第一，智能体记忆的核心不是更大的上下文窗口，而是「写什么、何时校验」的选择能力。第二，离线整合（dreaming）把记忆维护从主任务中剥离，代价是额外算力与延迟。第三，衡量记忆系统要看任务完成度与 token 成本的组合，而不是单看命中率。
需要区分事实与判断：上述分数与案例均来自 Anthropic 官方博客，属厂商自报口径；文章本身也声明测试规模有限，结论不能直接推广到全部场景。是否采用该方案，取决于任务是否存在跨会话、跨文档的重复查询需求。
官方来源
- Anthropic：The components of agent memory（2026 年 11 月 6 日）
- Anthropic Cookbook：Dreaming with a dynamic workflow