记忆笔记#

我们所说的“智能体记忆”，是指 Claude 从经验中获得——包括与用户的交互以及被指派的任务——并在会话之间保留下来、以之后可读取的上下文形式保存的知识。它不包括模型学习或管理上下文的其他方式，例如改变权重（训练时设定的内部参数）、上下文学习（in-context learning，在单次对话中获得的知识），以及压缩（compaction，由 Claude 撰写摘要替换较早的轮次，以便它能在新的上下文窗口中继续工作）。

在人类大脑中，经历之前、之中或之后释放的化学信号可以给一段记忆“打上标记”，表示它很重要。被标记的记忆在离线时段比未标记的记忆更频繁地被重放。这一被称为重放（replay）的过程有助于稳定记忆，并把它们整合进长期记忆。

类似地，Claude 可以在会话日志中实时标记显著事件，方便之后查找；也可以把它们写进记忆存储，例如一个存放记忆笔记的文件夹（图 2）。但在还不知道接下来会发生什么的时候，Claude 如何判断当下什么才是显著的？

图 2：同一张记忆层级图，突出显示记忆笔记层。一个箭头从会话直接指向记忆笔记，表示 Claude 写下的显著观察。

记忆可以是对未来需求的预测#

记忆有时就是一种预测。智能体写下一条规则，就是在预测它所描述的模式会再次派上用场。例如，记下一个已验证的事实时，它预测的是：未来某个会话中的智能体希望直接依赖这个事实，而无需再次核实。随着时间推移，Claude 在这类预测上已经进步了很多。

以持续学习基准 CL-Bench 1.0 中的一项任务为例。该基准衡量智能体利用记忆完成长程任务的能力。其中一项任务要求 Claude 通过在数据库中查找信息来回答一系列问题。Claude 给出答案后，会被告知正确答案，并可以写一条记忆来帮助回答之后的问题。

记忆可以在此支撑一个学习闭环。如果 Claude 答错了，它可以记录这次失败，提出关于错因的假设，检验这些假设，并把发现转化为今后答题的规则。

我们使用 Claude Managed Agents 运行了这项 CL-Bench 1.0 任务。Claude 在每个问题开始时都处于全新会话，唯一的例外是：它可以从一个跨会话保留的记忆目录中读取文件。

不同模型在建立自己的学习闭环方面取得了不同程度的成功。Claude Sonnet 4.6 已经能提出关于答案为何错误的假设；它的记忆目录是一堆散乱的文件，每个文件都列着若干未经检验的猜测。

图 3：CL-Bench 数据库任务，比较有无记忆（无状态基线）时各模型的表现。左：平均奖励柱状图，每组依次为无状态基线与记忆存储——Opus 5.5：0.655 / 0.838，Sonnet 5.5：0.644 / 0.833，Opus 5：0.564 / 0.828，Opus 4.7：0.383 / 0.700，Sonnet 5：0.306 / 0.610，Sonnet 4.6：0.330 / 0.364。右：同样这些模型在 30 个问题上的滑动平均奖励曲线，分别对应有记忆与无记忆。

Claude Opus 4.7 把笔记整合成一份参考文档，并开始标注哪些事实已经核实、哪些尚未确认。Claude Sonnet 5 在评分器检查之后把每个答案标记为已确认，答错时则写下更正。

Claude Opus 5 是这些模型中第一个真正闭合学习环的。它的大多数条目都包含一条规则（以及它如何知道这条规则成立）、对先前问题的答案，以及对沿途发现的陷阱的明确警告（图 3）。

与 Opus 5 一样，Claude Opus 5.5 和 Claude Sonnet 5.5 也都闭合了学习环，用记忆记录关于如何最好地回答未来问题的、经过验证的规则。在有记忆的情况下，二者的得分与 Opus 5 大致相当，尽管它们在无记忆时的基线表现略高。

Claude 学会了判断什么值得记住#

我们还评测了 Claude 玩《宝可梦 红》（Pokémon Red）的能力。这款游戏要求 Claude 处理复杂的长程任务，正好可以检验它判断“该把什么存进记忆”的能力。每次运行开始时，我们给每个模型一个记忆文件夹，它可以在游玩过程中读取和写入（图 4）。

我们比较了 Claude Sonnet 3.7 与 Claude Fable 5 各一次运行、均进行到约 10,000 步时的记忆文件夹。一个关键差异在于它们各自认为什么值得记住。Sonnet 3.7 假设一切都可能有用，不加区分地写记忆。它的记忆文件夹像一本“遭遇档案”：每场战斗、每件捡到的物品、每个遇到的非玩家角色，往往都单独存一个文件。最终，Sonnet 3.7 在 225 个文件夹里写了 413 个记忆文件，只拿到一枚徽章（徽章代表玩家在游戏中的进度）。

相比之下，Fable 5 只在两个文件夹里写了 9 个文件，另有一个顶层的 global.md，拿到了四枚徽章。

图 4：同一比例下宝可梦记忆目录的矩形树图，面积表示记忆的字符数。Claude Sonnet 3.7 的目录庞大而拥挤，413 个文件、977,930 个字符，分布在 locations、main、battles 以及若干“consolidated”文件夹中；Claude Fable 5 的目录很小，10 个文件、43,406 个字符，分布在 locations、gameplay 和 global.md 中。

Sonnet 3.7 的做法之所以成问题，主要是因为《宝可梦》的游戏状态在不断变化——它那份详细的记录持续过期。结果，随着进程推进，Claude 不得不把越来越多的时间和资源花在翻检记忆上，而不是玩游戏。例如在 10,000 步左右，Sonnet 3.7 开始整理它的第四个“master”记忆文件夹。在接下来的 17 步里，它创建了 6 个文件、删除了 9 个，却没有在游戏里采取任何行动。

Fable 5 则用记忆来记录游戏没有明确告诉它的东西。Sonnet 3.7 写进记忆的某些信息——比如玩家有多少钱、玩家在地图上的位置——每一回合都能从屏幕上读到，存下来是冗余的。相反，关于策略、计划和经过检验的规则的记忆文件，只有 Claude 自己推导出来才会存在；如果它不写下来，这些内容就会消失。

Fable 5 据此组织了记忆。它的 global.md 充当仪表盘，记录当前目标、为挑战道馆（赢取徽章的地方）预先写好的计划，以及模型自己使用记忆的规则。locations 文件夹存放特定路线的导航计划，gameplay 文件夹则存放基于它对游戏机制的理解而总结的策略。例如，在连续七个精灵球都没能抓住一只鲤鱼王（最容易捕捉的宝可梦之一）之后，Claude 写道：“如果连续 3 个以上球失败，就改变节奏（在菜单步骤之间插入额外的‘等待’按键）——这样做之后立刻就抓到了。”

凭借小得多的记忆文件夹，Fable 5 在游戏中的进度远超 Sonnet 3.7。Opus 5.5 采用了类似的做法：它维护一个小文件夹的记忆笔记，追踪当前目标和下一步行动，边玩边重写，最终通关。

引导 Claude 写记忆#

我们发现，告诉 Claude 记忆是用来做什么的有帮助，但不要规定它怎么用。在 CL-Bench 上，我们只是告诉 Claude 有一个记忆文件夹可用。这条笼统的提示就足以让 Opus 4.7 和 Opus 5 有效利用记忆，并给二者带来了明显的性能提升（图 3）。

我们还测试了给模型设定具体的记忆规则，每次测试一条规则，把每种规则下记忆带来的增益与没有规则时的增益作比较。当我们把规则设为“只记录失败”时，Opus 5 和 Opus 4.7 从记忆中获得的性能提升都大幅缩水（图 5 右）。对更强的模型而言，让它们自行判断显著性，比事先设定固定规则更有效；这些规则反而可能削弱表现。

图 5：左：Sonnet 4.6 在 CL-Bench 数据库任务上的平均奖励——基线 0.330，使用记忆 0.364，使用记忆并改进指令 0.641；参考线标出 Opus 4.7 有记忆时 0.700、Opus 5 有记忆时 0.828。右：被要求“只记录失败”时记忆增益的变化——Opus 5：−0.234，Opus 4.7：−0.150，Sonnet 4.6：−0.020。

我们还注意到，引导对较老的模型帮助最大。例如，Sonnet 4.6 经常不读取记忆目录中的文件，也没有去检验关于错因的假设。

在这项任务中，提示 Claude 在回答前先读记忆文件、然后明确检验自己的假设，几乎让它的基准分数翻倍（图 5 左）。Sonnet 5 则会自发这样做：在 10 次中有 9 次未受提示就先去读了记忆。相比之下，Sonnet 4.6 这样做的时候不到一半。

对于前沿的 Claude 模型，我们通常只给出简单的指引：当有人要求时，或当某件事明显值得记住时，创建记忆笔记；具体判断交给 Claude 自己。

Dreaming 可以修正记忆#

由于 Claude 是依据它在会话中判断的显著性来写记忆的，一条从一开始就写错、或随环境变化而失真的笔记，可能会在之后的会话中被 Claude 读到并当真。

Dreaming 给了 Claude 一种用原始对话记录校验笔记的办法（图 6）。在 Claude 使用 Managed Agents 玩《宝可梦》、并把记忆目录挂载进去时，我们看到了一个正面例子。

图 6：带 dreaming 的记忆层级图，突出显示从对话记录指向记忆笔记的箭头，表示 dreaming 依据对话记录修正笔记。

在游戏的一段流程中，玩家必须穿过月见山（Mt. Moon）——一个入口在地图西侧、出口在东侧的洞穴系统。入口附近有一个陷阱：一处单向的悬崖边，会把玩家送到来时的路上，而且没有明确的办法爬回去。Claude 把宝可梦中心（PokéCenter，位于山入口处的建筑）当作地标，因此它是否会走下那个悬崖，取决于它认为宝可梦中心在山的那一侧。

有一次，Claude（错误地）写下宝可梦中心在东侧。它走出宝可梦中心时宣称：“月见山在我身后了”，并更新笔记：“月见山完成。”但月见山并不在它身后。几个动作之后，Claude 越过悬崖，落回了来时的路（图 7）。它的导航工具没有显示这次坠落，于是 Claude 得出结论：“我往西走过头了”，并认为自己一直在正确的一侧。事实并非如此。

图 7：两张宝可梦地图，智能体位于悬崖边。左：“原始记忆”，存储的笔记是错的，箭头显示智能体朝下一座城市前进；右：“记忆 + dreaming”，一次离线处理修正了笔记，箭头显示智能体返回洞穴入口。

随后我们测试了 dreaming 能否帮助 Claude 避开这个陷阱。我们针对包含错误宝可梦中心位置的记忆文件夹运行 dreaming：Claude 拿笔记与会话记录对照，发现错误并重写了它。对话记录为它提供了校验记忆的事实依据。有了修正后的记忆笔记，Claude 径直回到月见山，最终抵达了华蓝市（Cerulean City）。

在笔记未修正的那次运行中，Claude 三次掉回那条来时的路。第三次失败后，它似乎放弃了，写道：“我要停下来，不再这样循环。”我们设置的自动回复指示它继续。它照做了，一路回到山前的城镇尼比市（Pewter City），希望在那里治疗和补给。那次运行结束时，Claude 始终没有抵达华蓝市。

图 8：3,000 个累计动作内朝华蓝市推进的进程曲线。记忆 + dreaming 的那次运行在第 1,935 个动作抵达华蓝市；仅用原始记忆的那次运行掉下悬崖、退回尼比市；没有记忆的那次运行则从未抵达华蓝市。

Dreaming 可以构建新的记忆表示#

借助 dreaming，Claude 可以构建帮助自己浏览记忆的“表示”（图 9）。它使用的一种记忆表示叫做 wiki：由 Claude 撰写和维护的一组页面，汇总它关于某个主题的知识，并与其他笔记建立链接。这些链接实际上为 Claude 提供了一张地图，让它能翻检记忆，在需要时高效定位。

图 9：带 dreaming 的记忆层级图，突出显示从对话记录和记忆笔记指向记忆表示层（例如 wiki）的箭头。

像 wiki 这样的表示可以帮助 Claude 遍历其不断增长的知识库。我们使用一份内部文档语料来研究 wiki 作为记忆表示的收益——这些文档来自我们在 5 月收购的软件公司 Stainless，约 35 万个文件、约 4.2 亿个 token。我们围绕这份语料构造了一组 25 个问题的评测集，并给 Claude 一个搜索工具来探索。我们还指示 Claude 用 dreaming 基于这些文件构建 wiki。在 128 次会话中，我们让 Opus 5 智能体探索文件、撰写或修正相互链接的 wiki 页面、合并重复内容，并对照来源核查说法。

每次会话都在之前会话的进展上继续，并通过共享日志协调工作。当 dreaming 从 2 次会话扩展到 128 次时，这 25 个问题上的评分项达成率从 13% 提升到 48%（图 10）。

Claude 逐步构建 wiki。创建初始 wiki 后，它会在后续轮次的 dreaming 中增补、编辑或删减。在 dreaming 的早期轮次，Claude 的知识像一个新员工，仅凭 wiki 答题的能力有限。dreaming 越多，它的知识地图就越丰富，越像一位老练的员工。在测试中我们发现，当同时给它搜索工具时，wiki 的帮助最大。当它同时使用搜索和 wiki 时，随着 wiki 增长，其综合得分从 54% 升到 61%；而只能使用搜索工具时为 53%。仅靠 wiki 答题时，Claude 的最高得分是 48%。同时使用搜索和 wiki 还能为每个问题节省约 20,000 个 token。

图 10：中：随着 wiki 生成所用 dreaming token 从 200 万增长到 1.28 亿，达标评分标准的折线图。wiki + 搜索工具从 54% 升至 61%，仅 wiki 从 13% 升至 48%，只有搜索工具、没有 wiki 时持平于 53%。左、右：示例 wiki 的网络图，2 次会话后为 103 个页面、766 条链接，128 次会话后为 222 个页面、12,893 条链接。

我们想测试哪类任务能从 Claude 拥有 wiki 中受益。为此，我们使用了 Harvey LAB 基准，以及一组关于某次并购的文档。该基准给 Claude 一组文档，要求它依据内容生成一份法律简报，然后按一列标准给简报打分。这些评测或许不如宝可梦之旅有趣，但为我们提供了多样化的文档集合来构建 wiki。

我们指示 Claude 根据这些文档构建 wiki，然后要求它分别借助 wiki 和直接文件搜索来回答问题（关于该并购）或生成法律简报（LAB 基准）。其中一项测试提出 24 个关于并购的问题（图 11 左），过半需要 Claude 跨多份文档查找信息，许多还需要运用判断或做计算。在这些条目上（红线和橙线），Claude 查阅 wiki 时得分为 87%，而只用搜索时为 73%。

图 11：两张把评分标准与来源文档对应起来的图。左：wiki 收益更明显的任务，24 个关于并购的问题大多可借助公开文件回答，其中大多数标准需要综合 10 份文档中两份或更多的信息，9 条需要判断或算术。右：wiki 收益不明显的任务，57 条标准中的大多数都能通过在一份文档（通常是交易概览备忘录）中做文本搜索找到。

另一些情况下，wiki 的作用就没那么大了。在一项 LAB 任务中（图 11 右），简报的评分标准往往可以在一份文档里通过文本搜索找到，wiki 相对搜索没有明显收益。在另一项 LAB 任务中，wiki 甚至长得比原始文档还大（图 12）。就像博尔赫斯极短篇小说《论科学的精确性》里的制图师，画出的地图精细到与它所描绘的帝国同样大；Claude 也做了一份极其详尽的 wiki，实际上没有抽象出任何东西。

图 12：一次 wiki 构建及其第二轮处理。左：一个圆圈代表语料，10 份文档、115 KB 文本；箭头指向一个更大的圆圈，代表据此构建的 wiki：68 个页面、255 条链接、203 KB，是语料的 1.77 倍。wiki 中部分页面没有任何链接。

Dreaming 可以把笔记提升到记忆层级的顶层#

Dreaming 还可以把笔记“浮”到记忆层级的顶层，智能体运行框架（harness）则可以在每次会话开始时把它们预先加载进 Claude 的上下文（图 13）。这意味着 Claude 无需去搜索它们，甚至不需要知道有东西可搜。

把记忆提升进新会话（一种上下文注入）必须谨慎。注入的记忆会占用宝贵的 token，而一条错误的笔记可能被带进每一次会话。加载笔记也不能保证 Claude 会照做：我们在 Claude Code 文档中提醒过，指令文件越长，遵循度越低。因此记忆层级的顶层必须保持相对精简，而 dreaming 在这里的很多工作就是维持这一点——把一些细节下移到更低的层级，只留下链接。

Claude Code 的自动记忆也用同样的方式保持注入层精简，由 Claude 在会话期间自行维护。Claude 不会把全部自动记忆都加载进每次会话的上下文窗口，只加载 MEMORY.md 的前 200 行或 25 KB。这个头部充当索引，告诉 Claude 它知道什么、去哪里找。

图 13：带 dreaming 的记忆层级图，突出显示从对话记录和记忆表示指向顶部注入上下文层的箭头；注入上下文会被加载进下一次会话，其下的层级则在 Claude 需要时被读取或搜索。

Dreaming 可以让记忆聚焦于特定目标#

Dreaming 还可以塑造记忆的生长方式。例如，像 Claude Duet 这样的助手，往往受益于围绕它所帮助的人来组织记忆；dreaming 可以被调整成服务于某个特定目标来构建记忆。

指导记忆如何生长的指令因任务而异，它告诉 Claude 哪些信息才真正重要。例如，LAB 基准中的一项任务模拟公司收购，并提供一组合同。简报的评分标准是它是否准确描述了合同条款。

我们最初使用的 wiki 生成指令很基础，没有告诉 Claude 如何使用 wiki。这项任务高度依赖合同条款。在构建 wiki 的过程中，多个智能体同时往一张共享的合同条款表里写入（图 14 左）。

图 14：改进指令前后，有多少评分所需的合同事实进入了 wiki。左：多个智能体写入同一共享页面（provisions.md），一个智能体的保存抹掉了另一个智能体的内容，57 条评分事实中只有 41 条保留下来；右：每份合同由一个智能体负责，各写自己的页面并逐字引用条款，57 条事实全部保留。

结果是一份缺失关键事实的 wiki。当我们给依据该 wiki 生成的简报打分时，Claude 只写进了 57 条事实中的 41 条（72%）。排查问题后我们发现，那张共享表格对合同条款的概括很糟糕，有些条款干脆缺失，因为智能体之间互相覆盖了对方的写入。

合同条款是这份 wiki 最重要的部分，但指令没有说明这一点。为了找到更好的指令，我们跑了一个循环：Claude 反思自己的失败，提出对指令的修改，然后重建 wiki。这个循环让 Claude 发现遵循合同条款有多重要，并据此重写了构建 wiki 的指令。

每份合同在 wiki 中都有自己的页面，由单个智能体撰写，逐字引用条款，而不是把它们概括进一张共享表。当我们给依据这份改进后的 wiki 生成的简报打分时，100% 的标准都能满足，此前为 72%。

Dreaming 可以补上单次会话留下的空白#

Claude 撰写记忆笔记时，只能看到那一次会话的上下文。Dreaming 可以跨多次会话搜索，找出共同模式或纠正常见错误。

在为 LAB 基准构建 wiki 时（示例见图 14），Claude 有时会链接到尚未创建的页面。第二轮 dreaming 弥补了其中许多缺口。在一项任务中（图 15），dreaming 发现 wiki 里有 9 条链接指向一个不存在的页面，于是把它们改指向同一份文档的现有页面。它还新增了三个页面（包括一个索引）来改进 wiki。

图 15：wiki 在第二轮 dreaming 前后的对比。前：38 个条目、225 条链接，其中 6 个页面上的 9 条链接指向不存在的 “escrow-agreement”；后：41 个条目、278 条链接，9 条链接全部改指向 “buyer-form-escrow-agreement”，并新增 index、instructions email、escalations 三个页面。

向后理解，向前看#

如何为智能体设计记忆系统，还有许多未解问题。其中之一是 Claude 应该在什么时候创建记忆。当 Claude 处理任务时，它可以写入记忆存储（例如文件夹、文件或数据库），在源头捕捉显著性，让重要细节立刻可用于之后的轮次或会话。但当下记录笔记不可避免地会把 Claude 的注意力从主任务上引开。相反，dreaming 可以把记忆创建推到后台，但 dreaming 的输出未必能立即被 Claude 取用。

另一个问题是如何让记忆可靠地保持最新。Claude 可能做出错误预测，或把一开始就错误的规则写进记忆。随着环境变化，记忆也可能逐渐偏离、变得无关。Dreaming 是修正这些错误的一种方法（图 8），但它需要算力。让 Claude 持续检查所有记忆可能并不现实。更重要的也许是让 dreaming 聚焦于可能变化的信息，或仔细调整 dreaming 的节奏（例如依据记忆被访问的频率）。

把对话记录搜索视为 Claude 记忆的基础，也是合理的。把表示（例如 wiki）与搜索结合（图 10）有时会很有效。但 Claude 需要投入算力来维护记忆表示，确保它们不会累积错误或幻觉。

尽管 Claude 对显著性的判断已经进步，但没有任何模型能真正知道未来轮次会发生什么。Dreaming 让 Claude 有机会向后看，用算力整理记忆、修正错误，并维护那些让未来会话更容易取用记忆的表示。随着 Claude 变得更强，记忆系统也会演进；关于如何设计 Claude 的记忆系统，我们还有很多要学。

参见我们的 cookbook：dreaming 入门与知识 wiki。