Claude记忆机制Dreaming公开：用空闲算力「做梦」通关宝可梦

Claude 背后的独门记忆机制彻底公开了，核心就俩字——做梦。

让模型在会话间隙利用空闲算力偷偷睡上一觉，在“梦境”里重新检查过去的经历、纠正错误记忆，再把零散的信息整理成能够跨会话复用的知识。

没学会做梦的旧版 Claude 玩宝可梦能把自己玩到原地破防。连续三次从单向悬崖掉回老路之后，它直接在执行记录里撂挑子：

我还是停下来吧，省得一直原地打转。

学会做梦之后，不仅能过滤无效干扰轻松通关；啃下35万份复杂企业文档后，回答准确率还能直接暴涨到近五成。

以前 AI 做题需要思考，现在玩个游戏还得先睡上一觉？

用离线计算沉淀长期知识

Claude 做梦的思路，确实借鉴了人类的记忆机制。

人为什么要在睡觉时做梦呢？神经科学研究表明，海马体在白天接收高密度的短期碎片记忆；到了休息阶段，大脑回放白天的经历，将零散事实筛选、沉淀并结构化，逐步整合进大脑皮层，转化为长期知识。

Anthropic 将这种即时记录与离线整理相结合的思路，用到了 Agent记忆系统 中。

在现有的 Agent 架构中，系统往往面临两难：上下文窗口随任务轮次增加而膨胀，导致推理延迟与调用成本激增；而若依赖粗粒度的长文本摘要或向量检索（RAG），关键技术细节又容易被遗漏，逻辑链条支离破碎。

Anthropic 的解法是引入 空闲计算（Sleep-time compute），在用户离线或交互暂停时启动 Dreaming 流程。

这套架构将 Agent 记忆划分为四个层级：

1. 原始会话记录：包含交互输入、模型输出、工具调用参数与执行反馈的底层真实日志
2. 记忆笔记：Agent 执行任务时记录的局部经验要点
3. 记忆表示层：跨会话维护、结构化且包含超链接的网状知识库
4. 注入上下文：新会话启动时预加载的高优先级索引信息

在交互暂停、系统处于空闲时，模型在后台启动 Dreaming 流程，调取原始会话记录，交叉校验笔记内容，修正逻辑矛盾，进而更新全局记忆表示。

之所以需要离线记忆整理，是因为记录记忆的核心目标在于为后续任务提供有效先验。基础的记录方式倾向于保存详尽的操作流水账；在 Anthropic 看来，更有效的记忆机制，在于提炼通用的操作规则、排错记录与具备复用价值的决策链路，从而在后续会话中直接调用。

413份笔记不如10份核心规则

这套系统到底好不好使，《宝可梦》成了“主考官”。

早期版本的 Claude（如 Sonnet 3.7）记录信息事无巨细。打完一场野怪，存个文件；捡到一个精灵球，存个文件；路边 NPC 说了句废话，也单独存个文件。不知不觉，它就整出了 413 份记忆文件，塞满了 225 个文件夹，文本量飙到近 98 万字符。

这种记录方式带来了沉重的维护负担。模型在随后的 17 个操作步骤里，新建 6 份文件、删除 9 份文件……然而大部分计算资源都被用于整理笔记了，游戏里的角色一步没挪。玩到最后，只惨兮兮地拿到一枚道馆徽章。

而更高级的模型（如 Claude Fable 5 和后续的 Opus 系列），学会的第一件事就是断舍离。

金币数量、当前坐标、血条实时数值？这些在游戏界面上一眼就能看清的显式信息，统统不记。整个系统只建立了 10 份核心文件（包含 9 份分类模块和 1 个顶层 global.md），总共只有 4.3 万字符。

这种抓大放小的策略带来了更高的推关效率，Claude 操作的角色直接暴走道馆，连拿四枚徽章通关。

新版本记的又是什么呢？是游戏界面不会直接告诉它的策略知识。例如连续用 7 个精灵球都没抓到鲤鱼王，它便提炼出规律：“连续 3 次捕捉失败，应调整按键等待间隔”。

在 CL-Bench 1.0 数据库基准测试中，这种整合“错误样本、归因分析、验证结果与最终规则”的机制，使 Opus 5.5 的平均得分从无长期记忆时的 0.655 提升至 0.838。

而前面提到的月见山悬崖死循环，则验证了做梦的纠错能力。

如果没有做梦机制，Claude 拿着那份写着“Mt Moon DONE”但方向相反的死笔记，只会不断强化自己的错误认知，甚至脑补出“我只是往西走过头了”的借口，最终心态炸裂原地罢工。而在引入 Dreaming 后，离线算力介入，模型带着审视的眼光重新翻看原始底层日志，对照真实坐标反馈，当场纠错：“不对，我的笔记方位记反了！”

于是它在后台把那份有毒的路线笔记直接撕掉重写。第二天醒来重新上号，掉头穿过山洞，一把翻过悬崖直奔华蓝市。

结构化知识网络

除了单机游戏，离线做梦机制在处理大规模企业资料时同样展现出结构化优势。

Anthropic 拿出了被其收购的软件公司 Stainless 的内部资料——约 35 万份文档，总计 4.2 亿 Token。然后派出了 Claude Opus 5 建立企业知识库，并设置了 25 道高难度跨文档综合问题进行大考。

模型在会话间歇不断“做梦”，将散落的内容编织成带有超链接网络的企业维基百科：

• 第 2 轮结束：生成 103 个页面、766 条关联链接
• 第 128 轮结束：膨胀至 222 个高聚合页面、12893 条链接

测试数据显示，仅依赖该知识网络回答，测试得分从初期的 13% 提升至 48%；知识网络配合原始文档检索，整体得分从纯检索的 53% 提升至 61%。资源消耗方面，采用该组合方案后，平均单题消耗减少了约 2 万个 Token。

Wiki 的优势在需要跨文档整合信息的任务中更加明显。在并购材料分析等跨文档多跳推理任务中，依靠结构化知识网络的回答准确率为 87%，高于单独依赖文档检索的 73%。

但研究团队也指出了知识抽象可能带来的冗余与信息丢失问题。在一次仅有 115KB 原始输入的测试中，Claude 生成的知识文件体积达到 203KB，相当于原始文档的 1.77 倍，摘要反而失去了压缩意义。

此外，在 多Agent协同编辑 共享合同表格时，由于缺乏并发控制，多个智能体相互覆盖内容，导致原有的 57 项关键事实丢失了 16 项。研究人员随后让 Claude 分析失败原因，调整知识库构建指令：每份合同由独立 Agent 负责整理，合同条款尽量保留原文，不再让多个 Agent 共同修改同一份汇总表。重新构建 Wiki 后，生成的法律简报满足了全部 57 项评分标准。

此外，Dreaming 还可以修复知识库里的失效链接。有一次，Claude 发现 9 条链接指向一个不存在的 Wiki 页面。重新检查后，它把这些链接改为指向已经存在的正确页面，同时增加了 3 个新页面作为索引和说明文档。

从补充知识、纠正错误，到维护页面之间的关系，Dreaming 都可以参与处理。但这些操作同样会消耗计算资源，而且整理出的 Wiki 越复杂，后续维护的工作量也越大。

记忆还得控制体积

知识库可以不断扩展，但真正进入 Claude 上下文的信息不能无限增加。

Anthropic 在文章中特别提到了 Claude Code 的自动记忆设计。每次新会话启动时，系统不会加载整个自动记忆目录。它只加载 MEMORY.md 文件开头的 200 行或最多 25KB 内容。 这部分主要承担索引作用。Claude 可以先了解自己保存了哪些信息、对应文件在哪里，真正需要细节时，再读取或检索下层记忆。

使用频率高、后续任务经常需要的内容，可以提升到更容易获取的位置；不必每次直接加载的细节，则可以留在下层，只保留相关索引。

而且，Dreaming 本身也有计算成本。前台一边执行任务一边记录太多内容，会影响任务推进；全部交给后台整理，又可能让一些重要信息无法及时用于下一次操作。历史记录还会随着环境变化逐渐过时，例如代码库已经重构，旧的操作规则可能就不再适用。

因此，记忆何时创建、多久检查一次、哪些内容值得长期保留，仍然需要根据任务场景调整。Anthropic 目前也没有给出一套通用于所有任务的标准化做梦节奏。

参考链接：
[1] AnthropicAI 官方 X 推文：https://x.com/AnthropicAI/status/2118814753154064501
[2] 官方博客 The components of agent memory：https://www.anthropic.com/research/components-of-agent-memory

关于 Agent 记忆的实践与讨论，欢迎到 云栈社区 一起交流。