Agent 的记忆由什么组成：读 Anthropic《The components of agent memory》
克尔凯郭尔说，人生只能向后理解，却必须向前过。 Anthropic 这篇文章的开头借用了这句话：Agent 在写下一条记忆的那一刻，并不知道将来哪些事会用得上。
Anthropic 在 2026 年 11 月 6 日发布了长文 The components of agent memory，作者是 Lance Martin。文章不长篇讨论架构名词，而是用几组评测去回答一个很朴素的问题：一个 Agent 的记忆，到底由哪些部分组成，每一部分各自贡献了什么。
读完之后我最大的感受是：它把「记忆」从一个笼统的功能，拆成了几种分工明确的东西，并且给了一个贯穿全文的动作——dreaming，也就是在会话之外、回头整理记忆。
这篇文章按原文的脉络梳理一遍，图片均来自原文，数字以原文为准；结尾是我自己的一些理解与实践建议。
说明：文中涉及的模型（Sonnet 4.6、Opus 4.7、Sonnet 5、Opus 5、Opus 5.5、Sonnet 5.5、Fable 5 等）与评测结果均出自原文。原文配图版权归 Anthropic 所有，本文仅作学习分享。
一、先把「记忆」的边界划清楚
原文给的定义很克制：Agent 记忆，是 Claude 从经历中获得、并在会话之间保留下来的知识，以「之后能读到的上下文」的形式存在。 经历包括和用户的交互，也包括被分配的任务。
同样能让模型「学到东西」或「管理上下文」的机制，有三种被明确排除在外：
这个划分很有用。很多人讨论「Agent 记不住」时，其实混着说了这几件事。原文聚焦的只是最后能落到文件、目录、数据库里，下一个会话还能读到的那部分。
二、一张图：记忆的四层与 dreaming
原文的核心模型是一个分层结构。从下往上：
- Transcripts（会话日志）：可搜索的事件记录，是最原始、最完整的那一层。
- Memory notes（记忆笔记）：Claude 在会话中写下的「值得记住的观察」。
- Memory representations（记忆表征）：从日志和笔记计算出来的结构，例如 wiki。
- Injected context（注入上下文）：每个新会话开始时就预先加载进来的那一小部分。
图 1：记忆层级与 dreaming。来源：Anthropic
图中那个包住中间四层的红框就是 dreaming。它借用了神经科学里的类比：人在清醒时由海马体快速记录经历，但只有一部分会在睡眠和安静休息时被「回放」、逐步整合进新皮层，变成长期知识。
对应到 Agent：
- 在线写入：会话中，Claude 一边干活一边记笔记（快、即时可用，但视野只有当前会话）。
- 离线整理：会话之间，Claude 回看日志与笔记，纠错、提炼、建索引、决定下次开局带什么（慢、要花算力，但能看到全局）。
这个想法的源头之一是 Letta 与 UC Berkeley 提出的 sleep-time compute：利用交互之间的空闲时间重新组织已有上下文。
后面整篇文章，基本就是在逐层回答：每一层、每一种 dreaming 操作，实际带来了什么。
三、在线写笔记：记忆是一种预测
图 2：会话直接写入记忆笔记这一层。来源：Anthropic
人脑里，一段经历前后释放的化学信号会给它打上「重要」的标记，被标记的记忆在离线时更常被回放。Agent 也可以做类似的事：在日志里给关键事件打标，或者直接写进一个记忆目录。
问题在于：还没发生的事，它怎么知道现在什么重要？
原文给出的视角是——写记忆本质上是在做预测。写下一条规则，就是预测这个模式还会再出现；写下一个已核实的事实，就是预测未来某个会话会想直接用它、而不必再查一遍。
3.1 CL-Bench：看模型能不能把学习闭环跑通
为了观察这一点，Anthropic 用了 Continual Learning Bench（CL-Bench）1.0 里的一个数据库任务：Claude 需要查数据库回答一连串问题，每答完一题会被告知正确答案，然后可以写记忆。
实验在 Claude Managed Agents 上跑：每道题都是一个全新会话，唯一能跨会话保留的，是一个持久化的 记忆目录。
理想情况下，记忆能支撑这样一个学习闭环：
不同代际的模型，走到了这个闭环的不同位置：
图 3：CL-Bench 数据库任务上各模型「无状态基线」与「带记忆」的平均得分。来源：Anthropic
有两点值得注意：
- Sonnet 4.6 几乎没吃到记忆的红利——光有猜想、不去验证，记下来的东西帮不上忙。
- Opus 5.5 与 Sonnet 5.5 带记忆后的分数和 Opus 5 接近，但它们的无状态基线更高，所以「提升」看起来反而小一些。记忆的价值，要看它补上的是不是模型本来就缺的那部分。
四、判断「该记什么」：宝可梦里的两种记忆目录
第二个评测更有意思：让 Claude 玩《宝可梦 红》。这是一个很长的任务，游戏状态不停变化，正好用来考察模型对「什么值得记」的判断。每局开始时给模型一个可读写的记忆文件夹。
原文对比了 Sonnet 3.7 和 Fable 5 在大约第 10,000 步时的记忆目录：
图 4：同一比例尺下的两个记忆目录，面积表示记忆的字符量。来源：Anthropic
Sonnet 3.7 的思路是「什么都可能有用」：每场战斗、每件道具、每个 NPC 都单独存一个文件。问题是宝可梦的状态一直在变，这份事无巨细的档案也就一直在过期。越往后，它花在翻记忆上的时间越多，花在玩游戏上的越少——原文记录到，大约第 10,000 步时它开了第四个「master」记忆文件夹，接下来 17 步里新建 6 个文件、删掉 9 个，游戏里一步没动。
Fable 5 的取舍很清楚：只记游戏不会直接告诉你的东西。
- 金钱、所在位置这类每回合都能从屏幕上读到的信息，存下来是冗余的。
- 策略、计划、验证过的规则，只有自己推理出来才存在，不写下来就会消失。
于是它的结构是：
global.md当仪表盘：当前目标、挑战道馆的预案，以及它给自己定的记忆使用规则；locations/：特定路线的导航计划；gameplay/：对游戏机制的理解和策略。
原文举了一个很生动的例子：连续 7 个精灵球都没抓住一只鲤鱼王（最好抓的宝可梦之一）之后，它写下一条规则，大意是「连续失败 3 次以上，就在菜单步骤之间插入额外等待、改变出手时机」——因为它正是这样做之后才抓到的。
后来的 Opus 5.5 也是类似做法：一个很小的记忆文件夹，记着当前目标和下一步，边玩边重写，最后通关了。
五、怎么引导 Agent 写记忆：讲用途，不讲做法
图 5：左，Sonnet 4.6 在不同引导下的得分；右，被要求「只记录失败」时，各模型从记忆中获得的收益变化。来源：Anthropic
CL-Bench 上，Anthropic 只告诉模型「有一个记忆文件夹可用」。这种笼统的说明，对 Opus 4.7 和 Opus 5 已经足够。
他们又试了给出具体规则，比如「只记录失败」。结果：
越强的模型，越不该被固定规则绑住。 预先写死「记什么」，会削弱它们自己判断重要性的能力。
反过来，较老的模型很吃引导。Sonnet 4.6 常常不读记忆目录，也不去验证自己的假设。在提示词里要求它「回答前先读记忆文件、再显式验证假设」，得分从 0.364 涨到 0.641，几乎翻倍。而 Sonnet 5 不用提醒，10 次里有 9 次会先读记忆；Sonnet 4.6 不到一半。
所以 Anthropic 对前沿模型的默认做法是：只给简单的指引——用户要求时、或者某件事明显值得记时，就写一条记忆——剩下的交给 Claude 自己判断。
六、Dreaming：离线整理记忆的五种方式
在线写笔记有天然的局限：Claude 只看得到当前会话，记下的东西可能一开始就是错的，也可能随着环境变化逐渐失效——而下一个会话会读到它，并且相信它。
Dreaming 就是为这些问题准备的。原文列出了它的五种作用。
6.1 纠错：用原始日志校验笔记
图 6：从日志层指向笔记层的箭头，即用原始记录校正笔记。来源：Anthropic
这一节的例子是宝可梦里的月见山（Mt. Moon）。这是一个洞穴，入口在地图西侧、出口在东侧，入口附近有一个陷阱：一道只能往下跳的单向台阶，跳下去就回到来时的路，而且很难爬回去。
Claude 把山脚的宝可梦中心当作地标，所以它会不会掉下台阶，取决于它以为宝可梦中心在山的哪一侧。
某一刻，Claude 错误地记下「宝可梦中心在东侧」。走出中心时它宣布月见山已经在身后，并把笔记更新为「Mt Moon DONE」。几步之后它跳下了台阶，回到了来时的路上。由于导航工具没有显示这个落差，它还给自己找了个解释：只是往西走过头了。
图 7：左为原始记忆，Claude 朝下一座城市走去；右为 dreaming 修正后，Claude 折返回洞穴入口。来源：Anthropic
接着 Anthropic 对这个包含错误位置的记忆文件夹跑了一次 dreaming：Claude 拿笔记去对照会话日志，发现了错误并改写。日志提供了 ground truth，笔记才有了被校验的依据。
图 8：累计 3,000 步内前往华蓝市（Cerulean）的进度。来源：Anthropic
- 记忆 + dreaming：直接回到月见山，在第 1,935 步抵达华蓝市。
- 原始记忆：在同一处台阶掉下去三次，第三次后它说想停下来不再绕圈；实验设置的自动回复让它继续，它就一路退回了上一座城市深灰市（Pewter）去补给，始终没到华蓝市。
- 无记忆：同样没能翻过这座山。
一条错误的笔记，比没有笔记更糟——它会让 Agent 带着十足的把握走错路。
6.2 构建表征：wiki 何时有用
图 9：从日志与笔记指向表征层，即构建 wiki 一类的结构。来源：Anthropic
记忆越积越多，就需要一张地图。原文用的一种表征是 wiki：由 Claude 编写和维护的一组页面，每页汇总它对某个主题的了解，并链接到相关笔记。链接就是导航路径。（这个形式和 Karpathy 分享过的 LLM wiki 思路 是一脉相承的。）
实验一：大规模企业文档。 语料来自 Anthropic 5 月收购的 Stainless 公司内部文档，约 35 万个文件、约 4.2 亿 tokens。评测集是 25 个关于这批语料的问题，Claude 有一个搜索工具。随后让 Opus 5 Agent 在 128 个会话里用 dreaming 构建 wiki：探索文件、编写或修正带链接的页面、合并重复项、对照原文核实结论。每个会话都在前人的进度上继续，靠一份共享日志协调。
图 10：中间为得分随 dreaming 投入增长的曲线；左右两侧是 2 个会话与 128 个会话后的 wiki 网络，每个点是一页，连线是页面间的链接。来源：Anthropic
wiki 本身也从 103 页、766 条链接长到了 222 页、12,893 条链接。原文的比喻很贴切：早期的 wiki 像新员工的知识，后来像老员工的。
但真正最好的组合是 wiki + 搜索：分数最高，而且每个问题大约省下 2 万 tokens。wiki 是地图，搜索是实地勘察，两者互补，而不是谁替代谁。
实验二：什么任务适合 wiki。 这里用了 Harvey LAB 基准（根据一组文档生成法律简报，按评分标准打分）和一组关于并购的文档。
图 11：左为并购问答，多数评分项需要跨 2 份以上文档；右为一项 LAB 任务，多数评分项能在单份文档里直接搜到。来源：Anthropic
- 并购的 24 个问题：一半以上需要跨多份文档整合信息，很多还需要判断或计算。在这类题上，查 wiki 得分 87%，只用搜索 73%。
- 某项 LAB 任务：评分项多数能用文本搜索从单份文档里找到，wiki 没有明显增益。
还有一个反面案例：
图 12：10 份文档共 115 KB，生成的 wiki 有 68 页、255 条链接、203 KB，是原始语料的 1.77 倍。来源：Anthropic
原文引用了博尔赫斯的短篇《论科学的精确性》：制图师画出了一张和帝国一样大的地图。一份比原文还大的 wiki，等于什么也没抽象。
我的理解是：wiki 的价值在于「跨文档的关系」和「压缩」。如果答案本来就躺在单份文档里，或者 wiki 写得比原文还细，那它就只是额外的维护成本。
6.3 提升到注入层：让下一个会话开局就知道
图 13：注入上下文会加载进每个会话，下面的层在需要时再读取或搜索。来源：Anthropic
Dreaming 还可以把笔记「提升」到最顶层，由 Agent 的运行框架（harness）在每个会话开始时预先加载。这样 Claude 不需要去搜，甚至不需要知道有东西可搜。
但注入层要非常节制：
- 注入的记忆会持续占用宝贵的 token；
- 一条错误的笔记会被带进每一个会话；
- 加载了也不代表会遵守——Claude Code 的文档里就提醒过，指令文件越长，遵循度越低。
所以 dreaming 在这一层的主要工作，反而是让它保持小：把细节往下层挪，只在顶层留一个链接。
Claude Code 的 auto memory 就是这样做的：不会把所有记忆都塞进上下文，只加载 MEMORY.md 的前 200 行或 25 KB。这个头部充当索引，告诉 Claude「我知道什么、去哪找」。
6.4 面向目标：先想清楚「什么最重要」
Dreaming 还可以塑造记忆生长的方向。像 Claude Duet 这类助理，记忆最好围绕「它在帮助的那个人」来组织；而不同任务里，真正重要的信息也各不相同。
原文的例子是 LAB 里一项模拟公司收购的任务：给一组合同，简报按「是否准确描述合同条款」打分。
图 14：左，多个 Agent 同时写一张共享条款表，57 个事实留下 41 个；右，每份合同由一个 Agent 单独成页并逐字引用条款，57 个全部保留。来源：Anthropic
一开始的 wiki 构建指令很基础，没说 wiki 将来怎么用。构建时，几个 Agent 同时往一张共享的条款表里写，结果互相覆盖，表里的条款概括得不好，还丢了一些。基于这个 wiki 生成的简报，57 个事实只覆盖了 41 个（72%）。
合同条款是这个 wiki 最重要的部分，但指令里没有说。于是他们跑了一个循环：Claude 反思失败 → 提出指令修改 → 重建 wiki。在这个循环里 Claude 自己意识到条款的重要性，并改写了构建指令：
- 每份合同单独一页；
- 每页只由一个 Agent 负责；
- 条款逐字引用，而不是汇总进共享表格。
改进后，简报的评分项 100% 可满足。
这个案例里我觉得有两层教训：一是记忆的组织方式要服务于下游用途；二是多 Agent 并发写同一个文件，会悄悄丢数据——这在任何协作式记忆系统里都值得提前设计。
6.5 跨会话补洞
单个会话写笔记时，只看得到自己的上下文。Dreaming 可以横跨多个会话，找出共性模式或反复出现的错误。
图 15：第二轮整理前 38 个条目、225 条链接，其中 6 个页面的 9 条链接指向一个并不存在的页面；整理后 41 个条目、278 条链接。来源：Anthropic
构建 LAB wiki 时，Claude 有时会链接到还没写的页面。第二轮 dreaming 找到了 9 条指向缺失页面的链接，把它们改指向同一文档的已有页面，又新增了 3 个页面，其中包括一个索引页。
七、原文留下的开放问题
文章最后没有给标准答案，而是列了几个仍在探索的问题：
- 什么时候写记忆？ 在会话中写，能在源头捕捉重要性、马上可用，但会分散主任务的注意力；交给 dreaming 在后台写，不打扰主任务，但产出不能立刻用上。
- 怎么让记忆保持新鲜？ 记忆可能一开始就错，也可能随环境漂移。Dreaming 能修，但要花算力，持续校验所有记忆并不现实。也许应该把 dreaming 集中在容易变化的信息上，或者按访问频率调节整理的节奏。
- 要不要以日志搜索为地基？ 表征（wiki）配合搜索有时很有效，但维护表征本身也要算力，还要防止错误和幻觉在里面累积。
结尾一句我很喜欢：再好的模型也无法真正预知下一轮会发生什么；dreaming 给了 Claude 一个向后看的机会，去整理、纠错，并维护那些让未来会话更容易取用记忆的结构。
Anthropic 还提供了两份上手材料：dreaming 入门 cookbook 和 knowledge wiki 示例。
八、我的几点体会
读完之后，回头看自己日常用 Claude Code、写 Skills 和 AGENTS.md 的方式，有几件事想得更清楚了。
8.1 记规则时，顺手记下「我怎么知道的」
Opus 5 的笔记之所以有用，不只因为有规则，还因为每条规则都带着依据和陷阱。依据决定了未来的自己（或另一个 Agent）敢不敢直接用这条规则，以及它失效时去哪里核对。
一条好的记忆笔记大概长这样（示意）：
规则、依据、陷阱三行各有分工：规则告诉你做什么，依据告诉你为什么可信，陷阱告诉你哪里容易反着用。
8.2 不要记环境会告诉你的东西
宝可梦的对比放在代码仓库里同样成立。目录结构、函数签名、git 历史，Agent 随时能读到，写进记忆只会过期、只会占地方。真正值得记的是读代码读不出来的东西：为什么这么设计、踩过什么坑、用户偏好什么、某个约束从哪来。
8.3 注入层越小越好
AGENTS.md、CLAUDE.md、MEMORY.md 这类每次都会加载的文件，就是注入层。它们越长，每条规则被遵守的概率越低，错误也会被带进每一次会话。比较好的做法是：顶层只放索引和少数硬性约束，细节下沉到 Skills、文档或单独的记忆文件里，顶层留一行指针。
8.4 给记忆安排「睡觉」的时间
在线写的记忆一定会有错、有重复、有过期。与其指望每次都写对，不如定期整理一次：对照实际情况核实、合并重复、删掉过时的、把重要的提上来。Claude Code 里的 consolidate-memory 这类整理技能，本质上就是一次手动触发的小型 dreaming。
8.5 告诉 Agent 记忆是为了什么，而不是怎么记
「只记录失败」这条规则让强模型的记忆收益掉了不少。给 Agent 写记忆相关的提示词时，更值得写清楚的是这份记忆将来服务于什么任务（比如「合同条款是最重要的」），而不是一套死板的记录格式。用途讲清楚，组织方式它自己会找到。
Agent 的记忆，说到底和人的笔记本没什么不同：写的时候要猜未来，读的时候要怀疑过去。 能在两者之间来回走一趟，才算真正记住了。
参考