导读Dreaming 能通过回查会话记录帮助 Claude 修正记忆，修正版还需接入后续会话。 Anthropic 11 月 6 日公布的工程案例说明，跨会话保存笔记能延续经验，也可能延续错误。本文从一次游戏导航失败讲起，拆解纠错需要什么输入、修正怎样生效，以及后台整理仍需付出的验证和维护成本。
一条错误笔记，让 Claude 反复走回原路
11 月 6 日，Anthropic 发布了介绍 Agent 记忆组成的工程文章，其中一个案例是 Claude 玩《宝可梦 红》时，把位置记反了。
游戏中的月见山入口在西侧、出口在东侧。入口附近还有一道单向台阶，跳下去就会落回来时的道路。Claude 用附近的宝可梦中心当作地标，却把它误记在山的东侧。
于是，走出中心后，它认定自己已经穿过山洞，准备去下一座城市。实际还在入口一侧的它，很快跳下台阶，回到了旧路。导航工具又没有显示这次跳落，它便把失败解释成往西走过头了，继续沿用原来的位置判断。
左侧依据错误笔记前往下一座城市，右侧修正笔记后返回洞穴入口；这是官方展示的行为对照
来源：Anthropic，原文图 7
Claude 还把这次误判写成了“月见山已通过”的进度笔记。下一次规划路线时，这条笔记就成了继续出发的依据。
笔记一旦成为下一步决策的前提，记错就不再只影响一句回答。它会影响 Agent 选择哪条路、是否重查当前位置，以及下一次怎样理解失败。
保存下来的，是经历还是判断？
先把这里的“记忆”说清楚。本文讨论的是 Claude 在任务中写下、以后还能读取的外部内容，例如跨会话保留的文件。写入这种记忆不会直接改变模型权重。
一份会话记录可以保留观察、工具返回和行动过程；一份记忆笔记则会从中挑选、概括，形成以后要用的判断。两者的职责不同。
用一个假设的数据库场景来说明：“这次查询返回空列表”是一项工具结果，“数据库里不存在这条记录”则是对结果的解释。后者方便以后直接使用，却也可能忽略另一种原因：查询条件写错了。
这解释了为什么只让 Agent“记住重要信息”还不够。重要性回答的是以后可能需不需要，正确性回答的是现在有没有依据。即使一条笔记对下一步极其重要，它也可能从写下时就是错的。
同样，重复保存一条结论不会增加独立证据。假如后续摘要只是引用前一份摘要，出现多份相同说法，也可能只是同一次错误被复制了多遍。因此，我更关心的是：检查笔记是否可信时，能不能回到它所依据的观察或结果。
别再笼统谈 Agent 记忆：先分层，再问三个问题
Dreaming 怎样把错误改回来？
Dreaming 可以理解为任务之外的一轮记忆整理：让模型回看历史记录，检查已有笔记，再修正、合并或重新组织它们。
橙色路径表示从会话记录回查、校正记忆笔记；上层还包括 Wiki 等组织形式和每次会话预先载入的内容
来源：Anthropic，原文图 6
读这张图时，可以先盯住最下面两层：下层留下发生过什么，上层保存提炼出的知识。纠错时，模型需要从上层的结论返回下层，检查原来有没有看错、漏掉信息，或得出了过强的结论。
我觉得这里最值得关注的，是校对时增加了原始记录这个参照。如果只把错误笔记交给模型，让它重新润色，输出可以更整齐，却没有因此得到位置判断的新依据。
原始记录也有边界。在这个案例里，它足以帮助发现位置错误；如果所需观察从未被记录，或者工具本身返回了错误信息，回读记录仍可能无法解决问题。此时需要新的观察或外部核验，不能只靠反复整理旧材料。
在月见山案例中，研究团队对包含错误位置的记忆目录运行了 Dreaming。Claude 把笔记与会话记录对照，发现位置判断有误，重写笔记。后续运行改为返回洞穴，并最终抵达华蓝市。
横轴为累计动作数，纵轴表示向华蓝市推进的估计进度；橙线使用修正后的记忆，蓝色虚线使用原始记忆，灰色点线不使用记忆。这组轨迹展示个案差异，不是总体成功率
来源：Anthropic，原文图 8
“改完笔记”之后，还有一步很容易被忽略：下一次会话究竟读哪一份？
这个过程在产品中也有了具体的输入输出约定。按 11 月 10 日核对的官方文档，Anthropic 的托管 Agent 服务 Managed Agents 提供研究预览功能 Dreams：开发者提交既有记忆库和历史会话，由后台异步整理，得到另一份记忆库，原输入保持不变。开发者审阅后，可以让未来的新会话读取这份输出库。
生成修正版和让后续任务读到修正版，是两个步骤。后台整理完成后，需要明确新会话使用哪份记忆，纠错才有机会影响下一次行动。
从“我猜原因是”到“这条规则有依据”
纠错还关系到一个更普遍的问题：Agent 从失败中学到的，究竟是经验，还是一个未经检查的解释？
Anthropic 在 CL-Bench 1.0 的数据库任务中，让 Claude 每回答一道题就开启新会话。跨会话保留的是记忆目录；作答后，模型能获得正确解法，并为后续问题留下笔记。
官方报告中，Sonnet 4.6 的笔记主要停留在对错误原因的猜测；Opus 5 则进一步保存经过验证的规则，以及确认规则的依据。这组任务考察的是跨会话利用笔记的能力，也为判断记忆质量提供了参照：同样有地方保存经验，模型实际完成的验证步骤可能不同。
回到前面的空查询例子。如果 Agent 直接把“记录不存在”存成已确认事实，后续就可能跳过本来值得再查的内容。可以先核对查询条件，修正有误的部分，再重新执行并检查返回结果，判断原来的解释是否成立。
更有用的经验要交代检查过什么：当时用了什么查询，核对或修正了哪些条件，最后的返回结果支持什么结论。这样，下一次读到笔记时，Agent 才有机会判断它是否适用于眼前任务。
失败记录、原因假设和已验证规则，值得保留为不同状态。这是我从这些实验中提炼出的设计判断。回看历史可以帮助发现线索，但涉及真实效果的规则，仍要由相应结果检验；一段流畅的失败解释不能替代这一步。
纠错之后，记忆还要继续维护
记忆会出错，也会过期。昨天验证过的接口、路径或任务状态，今天可能发生变化。因此，记忆系统既要判断当时的依据，也要判断这些依据是否仍适用于当前任务。
每次行动前重查全部历史，代价很高；把全部笔记都放进新会话，也会占用上下文。Anthropic 因而讨论了分层组织：少量内容预先载入，具体细节在需要时再读取或搜索，后台再负责整理和修剪。
这对纠错有直接影响：每次会话都会加载的内容里，一条错误结论就可能反复影响新任务。即使底层文件已经修正，启动时加载的摘要若仍保留旧判断，新会话依然可能受到误导。
实际维护时，可以把复核重点放在容易变化、又经常被调用的信息上。例如接口或路径变更后，检查相关笔记及启动摘要；一次已验证的判断反复失效时，再回查它原先的适用条件。这是依据上述机制可以采取的工程做法，具体多久整理一次，仍需按任务的变化速度和维护开销决定。
Dreaming 把回看经历、校正笔记的工作放到后台，提供了一条可行路径，也增加了计算和检查成本。月见山案例里，修正后的记忆改变了路线；迁移到其他任务时，需要验证的仍是同一件具体的事：更新后的记忆，是否让 Agent 在相关条件下采取了更合适的行动。
参考资料 上下滑动
•Anthropic，《The components of agent memory》，2026 年 11 月 6 日： https://www.anthropic.com/research/components-of-agent-memory•Claude Platform Docs，Dreams（输入输出、审阅及后续会话采用机制，11 月 10 日核对）： https://platform.claude.com/docs/en/managed-agents/dreams
文章仅做学术分享，如有侵权请联系删除，非常感谢！