Claude 的 dreaming 机制怎么修复记错的笔记：一个错误地标如何毁掉整局游戏

Anthropic 的 agent memory 研究展示了一个具体案例：Claude 在玩 Pokémon Red 时把地标方位记反，错误笔记在后续会话里反复导致迷路，最终靠 dreaming 会话对照原始 transcript 才修正。文章还给出两个工程教训：共享记忆表多 agent 同时写入会丢事实，以及 wiki 并不总是比直接搜索源文档更好。

一条错误笔记如何反复坑害新会话

• Claude 把月见山入口附近的宝可梦中心当路标，却错误记成建筑在山的东侧，实际入口在西侧
• 它离开建筑后误以为已穿过洞穴，走上一段单向悬崖掉回原路，导航工具又没显示落差，于是把问题归因为'走过头'，原始错误得以存活
• 第三次掉落后模型写下'我要停下来而不是继续循环'，实验设置自动让它继续，这条未修正的分支最终没能到达 Cerulean City
• 记忆机制本身不判断文件里一句话是真是假，正确规则能省去重复调查，错误规则则变成稳定复现错误的方式

dreaming 到底做了什么

• dreaming 指额外的会话，用来检查 transcript 并重组持久化上下文；Anthropic 对 agent memory 的定义不包括模型权重改动
• 研究者对存有错误笔记的文件夹跑 dreaming，Claude 对照原始会话记录发现错误并重写记忆，修正后的分支成功进入月见山并到达下一座城
• Managed Agents 的 Dreams 是异步任务：读取现有记忆库和选定的历史 transcript，产出独立的新存储，输入保持不变，开发者可先审查再决定是否挂载
• 注意：自定义 cookbook 工作流可以原地更新存储，'输出隔离'的保证只属于 Dreams API 本身，且该 API 仍在 research preview

文件越少不等于记忆越好

• 对比实验：Sonnet 3.7 一局写了 413 个记忆文件、225 个文件夹，只拿 1 个徽章；Fable 只留 9 个文件加一个 global.md，拿了 4 个徽章
• 这是不同模型的行为对比，不能隔离文件系统的因果作用，但模式有启发：Sonnet 存了大量会过时的游戏状态，Fable 的笔记更偏策略、计划和已验证的规则
• 屏幕上每回合可见的状态再存一份只是增加维护负担，文章描述 Sonnet 花了好几步整理文件而游戏里毫无动作
• 建议把'当前可观察状态'和'需要跨会话存活的知识'分开：坐标类信息很快过期，而关于工具行为的已验证规则更值得保留

wiki 不是万能药：数据与反例

• 在 Stainless 约 35 万文件、4.2 亿 token 的内部文档上建 wiki：纯搜索得 53%，搜索加 wiki 随规模增长到 54%–61%，wiki 单独最好成绩只有 48%
• wiki 加搜索每题省约 2 万 token，但文章没给全部离线会话的总构建成本；Dreams 按模型标准 API token 计费，任务可能要几分钟到几小时
• 反例一：某个 Harvey LAB 任务上 wiki 相比直接搜索没有明显收益，因为多数标准只需从单篇文档取一段
• 反例二：另一个任务的 wiki 长得比它要总结的源文档还大，复制源内容的表示只会增加维护负担

多 agent 共写一张表，57 个事实丢了 16 个

• 模拟收购任务中，多个 agent 把合同条款写进同一张共享表，最终简报只覆盖 57 个评分事实中的 41 个
• 失败原因：摘要质量差加上 agent 互相覆盖，关键条款在回答阶段开始前就已丢失
• 修正方案：每个合同单独一页、每页只有一个 agent 负责写入、条款逐字引用而非摘要，改进后覆盖全部 57 个事实
• 两项改动是一起生效的，无法单独归因；但'单一写者 + 保留原文 + 回答时回溯源链接'这个模式值得在多 agent 系统里试

落地前先想清楚的三件事

• 替换记忆库前先对比改动前后的笔记，尤其是会被自动注入的笔记
• 评估 wiki 的标准应该是'能否在可接受总成本下找到可靠证据、产出更好答案'，而不是目录更大、页面更多
• 持续检查每条记忆并不现实，Dreams 文档自己也承认这一点，所以要挑真正值得修的笔记跑 dreaming