Agent 记忆的组成部分：Anthropic The components of agent memory 文章的简要解读

Anthropic Engineering 团队于 2026 年 11 月 6 日发布了《The components of agent memory》，讨论一个正在变得具体的问题：Agent 该把什么留到下一次会话，以及这些留存物由谁来整理。本文把原文的核心概念与几组关键证据作简要介绍，并写下几点我自己的理解。

封面｜Agent 记忆的组成部分

文章目录

[Agent 记忆的组成部分：Anthropic The components of agent memory 文章的简要解读](#Agent 记忆的组成部分：Anthropic The components of agent memory 文章的简要解读)

一、原文在解决什么问题

原文借人脑的分工起笔：海马体即时捕捉经历，让记忆快速可用，但只有一部分会在离线期被重放、提炼并整合为新皮层里的长期知识。映射到 Agent 上，大量工作本来就留在日志或 transcript 里，缺的是「把其中哪些沉淀下来、由谁在什么时候沉淀」这套机制。

因此原文讨论的 agent memory 有明确边界：它指 Claude 从交互与任务中获得的、跨会话保留、以后能读回来的上下文知识；不包含权重更新、单次对话内的 in-context learning，也不包含为了续接上下文窗口而写的 compaction 摘要。

在这个边界里，最棘手的问题被原文一句话点破：写下一条规则，本质上是在预测「这个规律以后还会用到」；可写入的那一刻，模型还不知道未来会发生什么。剩下的篇幅，基本都在回答「既然判断不了，那靠什么补救」------答案是 dreaming：在交互之间的空闲期回看日志，修正错误、生成新笔记、构建新的记忆表示，甚至决定未来会话预先加载什么。

二、四个关键概念

记忆笔记（memory notes）：会话中把被判断为显著的事件写成可读文件，存进跨会话持久的目录。原文用 CL-Bench 1.0、Pokémon Red 等场景观察「不同模型各自记了什么」。
显著性判断（salience）：什么值得记，由模型自己判断。原文的经验是「告诉 Claude 记忆是干什么的会有帮助，但不要告诉它怎么用」；给强模型预设固定规则反而可能削弱效果。
dreaming ：离线整理机制。它可以用 transcript 作为 ground truth 校验笔记、纠正写错或已过时的内容，也可以把散落笔记整理成互相链接的 wiki，或把少量笔记上浮到记忆层级顶部。
注入上下文（context injection） ：顶层内容在每次会话开始时被预加载，所以必须保持很小。原文提到 Claude Code 的 auto memory 只加载 MEMORY.md 的前 200 行或 25 KB，把这段当作索引用。

图｜记忆层次与 dreaming 的位置，编者据原文概念绘制，不是原文图表的复制

原文 Figure 1｜Claude 可以用 dreaming 组织记忆：纠正错误、创建笔记、构建新的记忆表示，或影响未来会话预先加载什么内容。图源：Anthropic

三、原文里最有说服力的三组证据

以下只摘取能说明结论的少量事实，完整设置、逐项分数与图表请见原文。

① 记忆能不能形成学习闭环，取决于模型能力。 在 CL-Bench 1.0 的数据库任务里，每题都从全新会话开始，只保留一个可跨会话读取的记忆目录。原文观察到：Sonnet 4.6 最远只到「提出答错原因的假设」，目录里散落着未经检验的猜测；Opus 5 是第一个把「记录失败 → 提出假设 → 验证 → 形成规则」这个闭环跑通的模型，多数条目同时写下了规则、规则为何为真的依据、早前答案和踩过的坑。Opus 5.5 与 Sonnet 5.5 同样闭合了闭环。

② 记得多，不等于记得好。 玩 Pokémon Red 的对比里，Sonnet 3.7 不加区分地记录，约 10,000 步时留下 413 个记忆文件、225 个文件夹，只拿到 1 枚徽章 ；Fable 5 只写了 2 个文件夹共 9 个文件加一个顶层 global.md，拿到 4 枚徽章 。原文的归因很直接：金钱、位置这类信息每轮都能从屏幕读到，存下来是冗余且会持续过时；真正只有模型自己能产出的是策略、计划和验证过的规则。Fable 5 的 global.md 放当前目标与预先写好的攻略，gameplay 放学到的机制。

③ 离线整理确实能累积出可用的知识。 原文用一份约 350,000 个文件、约 420M tokens 的内部文档语料，让 Opus 5 agents 跨 128 个会话 增量构建 wiki，并围绕 25 个问题 评分：从 2 个会话扩展到 128 个时，得分从 13% 提升到 48% 。同一评测里，只用搜索工具是 53%，只用 wiki 最好 48%，而「搜索 + wiki」随 wiki 增长从 54% 升到 61%，且每题省约 20,000 tokens。

原文 Figure 10｜中：随连续会话构建 wiki，25 个问题的得分；左、右：2 次与 128 次会话后的 wiki 示例，每个点是一个页面，连线连接相互链接的页面。图源：Anthropic

原文也给了反例，值得和上面一起读：在某个 LAB 任务里，评分准则大多能从单个文档直接检索到，wiki 没有显示明确增益；另一次，wiki 甚至长得比原始文档还大，等于没做抽象。

四、几点个人理解

原文是一篇工程实践报告，没有把这些推论写成结论。下面是我在读的时候想到的，与前文的事实介绍分开列在这里，供讨论。

1｜「记忆是一次预测」把设计重心从「存什么」挪到了「谁来判断」。 原文有个对照实验很能说明问题：给强模型设定「只记录失败」这类固定规则，反而让它失去记忆带来的大部分增益；但对较旧的 Sonnet 4.6，提示它「回答前先读记忆、并显式验证假设」，分数接近翻倍，而 Sonnet 5 未经提示就会在 10 次里自发读记忆 9 次。我的理解是：记忆策略正在变成模型能力的一部分，而不是一个可以独立硬编码的模块。由此推出的一条工程含义（原文没直接写）是------能力不达标的模型仍需外显规则兜底，规则该随模型能力退场，而不是一开始就写死。

2｜记忆层该按「单位检索成本的信息增量」来评价，而不是覆盖率。 413 比 9 这个对比之所以反直觉，是因为详细记录既会过时，又会持续吃掉翻检时间与上下文预算；原文记录了 Sonnet 3.7 在 17 步里只顾整理文件、游戏中零操作。我倾向于把它理解成一条更通用的判据：能被环境直接重读的信息不该进记忆，只有「模型自己推出来、不写就消失」的东西才值得占位置。

3｜dreaming 实质是把一致性维护从在线链路挪到后台。 原文那个 Mt. Moon 案例很典型：一条「PokéCenter 在东侧」的错误笔记被后续会话直接信任，导致 Claude 反复走下单向 ledge；用 dreaming 对照 transcript 改写后，它重新进洞并抵达 Cerulean City。代价是「整理产物未必立即可用」。所以这是延迟换正确性的取舍，而不是免费优化------原文结尾也把「何时创建记忆」列为开放问题。我的一点判断是，与其对全部记忆做同样的整理节奏，不如按信息变化频率分层处理。

4｜和国内常见做法的一点对照（纯属编者联想）。 原文没有讨论向量库或 RAG，以下不是原文观点。很多团队做 Agent 记忆会先上检索链路，而原文这条路是让模型自己维护可读的文本笔记、再在离线期整理成互相链接的 wiki。二者解决的其实不是同一个问题：前者偏海量内容的召回效率，后者偏「模型主动组织、可解释、可校验」。我判断它们不互斥，但成本结构不同------wiki 需要持续算力维护，原文也提醒要防止它累积错误与幻觉。

5｜别把「提升」读成通用结论。 原文所有分数都是官方在同一套流程下自行评测、对象都是公开 checkpoint 的 Base 模型，且原文自己写明「没有模型能真正知道未来轮次会发生什么」；wiki 在部分任务上还明确没有增益。这些数字更适合当作「这条路径可行的证据」，而不是可直接移植到自己系统里的预期值。

五、原文自己列出的开放问题

原文结尾没有收束成结论，而是留了三类问题，我按原意压缩如下：

何时创建记忆：会话内即时写入立即可用但分散主任务注意力；dreaming 放到后台，产物却未必能马上被取用。
如何保持记忆可靠更新：预测会错、规则会漂移，dreaming 能修但需要算力；持续检查全部记忆不现实，或许该聚焦易变信息或调整整理节奏。
要不要把 transcript 搜索当作记忆的基础：表示（如 wiki）与搜索结合有时有效，但维护表示本身要花算力，还得防错误与幻觉累积。

六、原文信息与版权说明

项目	内容
原文标题	The components of agent memory
发布方 / 团队	Anthropic · Engineering
发布日期	2026-11-06
撰写	Lance Martin（插图：Monika Tuchowska）
原文链接	https://www.anthropic.com/research/components-of-agent-memory