解读 Agent 记忆架构

https://www.anthropic.com/research/components-of-agent-memory

这篇文章非常值得研究，尤其是对于正在做 Agent、长期记忆、RAG、知识库和多 Agent 系统的人来说。

Anthropic 在 2026 年 11 月 6 日发布的这篇文章，标题是 The components of agent memory（Agent 记忆系统的组成部分）。

我认为它最重要的价值在于：它把 Agent Memory 从简单的「保存对话、下次读取」，提升到了一个完整的持续学习与知识维护系统。

文章提出了一个很有意思的思路：

Agent 不应该只是不断积累记忆，还应该在空闲时回顾历史、纠正错误、提炼规律、重组知识，并决定哪些信息值得在未来使用。

Anthropic 把这个后台整理过程称为 Dreaming（做梦）。

下面从架构、技术机制、实验数据和工程实践几个方面拆解。

一、首先理解 Agent Memory 到底是什么

我们先区分几个容易混淆的概念。

Anthropic 讨论的重点是第四种：Agent Memory。

举个例子。

你让一个 Coding Agent 帮你部署 Django 项目。

第一次：

1. Agent 尝试使用某个部署命令。
2. 发现阿里云 FC 的运行环境不支持这种配置。
3. 尝试修改配置。
4. 最终解决问题。

第二次，你又让它部署另一个 Django 项目。

普通 Agent 可能又会重复之前的错误。

有记忆能力的 Agent 则可以记住：

• 之前遇到过什么问题。
• 为什么会出现这个问题。
• 最终采用什么方案解决。
• 哪些方案已经验证，哪些只是猜测。

这样，Agent 就不只是保存历史记录，而是在逐渐积累自己的工程经验。

二、Anthropic 提出的四层记忆架构

这是整篇文章最核心的部分。

文章将 Agent Memory 分成四层。

第一层

Transcripts — 原始交互记录

最底层，保存 Agent 经历过的事情。

• 用户与 Agent 的对话
• 工具调用及返回结果
• 执行过程、错误和最终结果
• 任务执行日志

第二层

Memory Notes — 记忆笔记

从原始经历中提炼出值得保留的信息。

• 用户偏好
• 已验证的事实
• 解决问题的方法
• 经验教训
• 尚未验证的假设

第三层

Memory Representations — 记忆表示

把零散笔记组织成结构化、可关联的知识体系。

• Wiki
• 知识图谱
• 主题索引
• 实体之间的关系
• 跨任务的知识关联

第四层

Injected Context — 注入上下文

每次启动 Agent 时，自动加载最重要的信息。

• 当前目标
• 关键用户偏好
• 重要约束
• 经常使用的规则
• 知识库入口索引

这四层不是简单的文件夹分类，而是有不同职责的记忆体系。

我特别强调一下它们之间的关系：

• Transcripts 负责记录发生了什么。
• Memory Notes 负责提炼值得记住什么。
• Memory Representations 负责组织知识之间的关系。
• Injected Context 负责决定每次启动时应该提前知道什么。

例如，一个 Coding Agent 可以有这样的目录：

agent-memory/
│
├── transcripts/
│   ├── session-001.jsonl
│   ├── session-002.jsonl
│   └── session-003.jsonl
│
├── notes/
│   ├── deployment.md
│   ├── debugging.md
│   └── user-preferences.md
│
├── wiki/
│   ├── index.md
│   ├── django.md
│   ├── aliyun-fc.md
│   └── database.md
│
└── MEMORY.md

这里 MEMORY.md 就是最上层的入口，其他内容按需检索。

这实际上是一种分层存储设计：不是所有记忆都应该进入 LLM 的 Context。

三、核心创新：Dreaming（做梦）

这是文章最值得关注的技术思想。

传统 Agent Memory 通常有两种做法：

做法 A：实时记录

每次对话结束，Agent 就把重要信息写进记忆。

问题：

• Agent 当下不一定知道哪些信息未来有用。
• 可能产生大量重复记录。
• 容易把错误判断写成事实。
• 记录本身会消耗当前任务的注意力和 Token。

做法 B：定期总结

例如每天晚上总结一次对话。

问题：

• 通常只是摘要压缩。
• 很少验证之前的结论。
• 不一定会发现多个会话之间的关联。
• 不一定会重新组织知识结构。

Anthropic 提出的 Dreaming 则更进一步。

它的工作过程可以理解为：

这里有一个很重要的概念：

Agent 在执行任务时负责积累经验，空闲时负责消化经验。

这与人类大脑在睡眠时整理记忆的思路类似。

不过要注意，这只是架构上的类比，并不是说 LLM 真的拥有类似人脑海马体的生理机制。

3.1 Dreaming 可以纠正错误记忆

Anthropic 做了一个很有意思的实验：让 Claude 玩 Pokémon Red。

游戏过程中，Claude 曾经错误地记录：

某个 Pokémon Center 位于月见山的东侧。

实际上位置判断是错的。

这个错误导致 Agent 后续判断路线时不断出错，甚至反复掉入同一个陷阱。

Anthropic 做了两组对比：

• Raw Memory：直接使用原始记忆。
• Memory + Dreaming：先回顾历史执行记录，再修正记忆。

Dreaming 通过检查原始 Transcript，发现了之前记录与实际行为之间的矛盾，最终纠正了位置判断。

结果：

• 使用修正后记忆的 Agent 最终到达了 Cerulean City。
• 使用错误记忆的 Agent 多次掉回原来的路线，始终没能完成目标。
• 没有记忆的 Agent 同样没有完成目标。

这个实验说明一个非常重要的问题：

记忆不一定越多越好，错误的记忆甚至可能比没有记忆更糟糕。

所以，Memory 系统必须有一个能够回溯原始证据、验证并修正旧记忆的机制。

3.2 Dreaming 可以建立新的知识结构

这部分更接近我们熟悉的 RAG 和知识库。

Anthropic 使用了 Stainless 的内部文档作为实验数据：

• 约 35 万个文件。
• 总计约 4.2 亿 Tokens。
• 使用 128 轮 Dreaming，让 Agent 持续整理知识。
• 建立 Wiki，维护页面之间的链接。
• 持续补充、修改、合并重复内容，并检查知识来源。

实验结果：

Wiki 建设过程中的知识问答表现

这里的数据单位是满足的评分标准比例，不是传统意义上的准确率。

几个值得注意的结论：

1. 仅使用 Wiki，评分从 13% 提升到 48%。
2. Wiki + Search 从 54% 提升到 61%。
3. Wiki + Search 相比单独 Search，提升了 8 个百分点。
4. 每个问题还节省了约 20,000 Tokens。

为什么 Wiki 和 Search 配合效果更好？

因为两者解决的问题不同：

• Search：找到原始文档中的信息。
• Wiki：理解信息之间的关系，提供更好的知识导航。

举个例子：

你想了解一家公司的某项技术决策。

单纯搜索可能只能找到某次会议纪要。

但 Wiki 可以帮助 Agent 发现：

• 这项决策最初来自哪个需求？
• 涉及哪些系统？
• 之前有哪些相关技术讨论？
• 后来有没有修改？
• 与其他模块有什么关联？

这就是从文档检索走向知识组织。

不过，Anthropic 也发现一个反例：如果一个问题只需要从单份文档中搜索，Wiki 并没有明显优势。甚至有一次，Wiki 的体积达到了原始文档的 1.77 倍。

这说明知识组织本身也有成本，不能为了建立知识结构而建立知识结构。

四、Memory 应该记录什么？一个非常有意思的实验

Anthropic 让 Claude 玩 Pokémon 时，比较了两个模型的记忆策略。

两者差异非常明显。

Sonnet 3.7 倾向于记录一切：

• 遇到了什么 NPC。
• 打了什么战斗。
• 拿到了什么道具。
• 到过什么地点。

它认为所有事情都可能有用。

最终产生了大量记忆文件，而且这些信息还会随着游戏进程不断过期。

Fable 5 则采取了完全不同的策略：

只记住那些不能直接从当前游戏画面获取、但未来仍然有价值的信息。

例如：

• 某个关卡应该如何通过。
• 某个操作失败后应该尝试什么。
• 已经验证有效的游戏策略。
• 当前长期目标和下一步计划。

它甚至有一个 global.md，作为整个记忆系统的总入口。

最终，Fable 5 仅用 10 个文件，就比 Sonnet 3.7 取得了更好的游戏进展。

这里有一个非常值得记住的原则：

记忆应该优先保存未来无法轻易重新获得的信息，而不是重复保存当前环境已经可以直接观察到的信息。

举几个工程例子：

这里还有一个重要区别：

任务状态（State）和经验知识（Knowledge）不应该混为一谈。

例如：

• 当前正在部署到第 3 步：State。
• 这种部署方式为什么会失败：Knowledge。
• 以后遇到同类问题应该如何处理：Strategy。

三者可以放在不同的存储结构中。

五、Agent 应该自己决定记住什么吗？

Anthropic 做了一个实验。

他们给 Agent 设置不同的记忆规则，例如：

• 只记录失败。
• 自己判断什么重要。
• 给出明确的记忆写入要求。

结果发现：

对于能力较强的模型，让模型自主判断哪些信息值得记忆，通常比预先规定死板的记忆规则效果更好。

尤其是只允许记录失败的策略，反而削弱了 Opus 5 和 Opus 4.7 从记忆中获得的性能提升。

为什么？

因为成功经验同样重要。

例如：

你让 Agent 修复一个 Docker 构建失败的问题。

它尝试了三种方法：

• 方法 A：失败。
• 方法 B：失败。
• 方法 C：成功。

如果只记录失败，它可能知道 A、B 不行，却不知道 C 为什么有效。

更合理的记忆应该包含：

problem: Docker build failure

attempts:
  - method: A
    status: failed
    reason: incompatible dependency

  - method: B
    status: failed
    reason: incorrect build context

  - method: C
    status: success
    reason: corrected build context

verified_rule:
  condition: when build context is incorrect
  solution: explicitly set the correct build context

confidence: verified
evidence: session-001

注意这里的 verified。

Anthropic 的实验也体现出一个重要思想：

记忆不仅应该记录结论，还应该记录结论是如何得到的，以及它是否经过验证。

这对防止 Agent 幻觉特别重要。

六、为什么不能把所有记忆都放进 Context？

这是一个很容易被忽略，但非常重要的工程问题。

假设你的 Agent 已经运行了半年，积累了：

• 1000 次对话。
• 500 个技术问题。
• 2000 条经验笔记。
• 100 篇 Wiki。
• 100 万 Tokens 的历史记录。

每次启动 Agent，是否应该把这些东西全部塞进 Context？

当然不应该。

原因有三个：

1. Context 有容量限制。
2. 输入 Token 越多，成本越高。
3. 信息太多会干扰模型对当前任务的关注。

Anthropic 提出的解决方案是：Memory Promotion（记忆提升）。

Dreaming 可以把某些重要的记忆提升到最上层，下一次启动时自动注入。

例如：

# MEMORY.md

## 当前项目

- 项目使用 Django + MySQL
- 使用阿里云 FC 部署
- 数据库迁移使用 Alembic / Django migrations

## 重要技术约束

- FC 环境使用 Python 3.12
- 数据库连接池需要限制连接数
- 时区需要显式处理

## 详细知识

- [Django 部署](wiki/django.md)
- [FC 配置](wiki/aliyun-fc.md)
- [数据库问题](wiki/database.md)

每次 Agent 启动，只需要读取这个入口。

当任务涉及 FC 部署时，再进一步读取 wiki/aliyun-fc.md。

这实际上是一个分级加载机制：

文章还特别提到，Claude Code 的 Auto Memory 也采用类似思路：每次启动最多读取 MEMORY.md 的前 200 行或 25KB，详细记忆并不是全部自动加载。

这里有一个很值得借鉴的设计：

最上层的 MEMORY.md 不应该是一个越来越长的记事本，而应该是整个记忆系统的索引。

七、Dreaming 还能解决多 Agent 协作的问题

文章还有一段很有意思，涉及多 Agent 共同维护 Wiki 时的数据冲突。

Anthropic 使用 Harvey LAB 的法律文档任务进行实验。

场景是模拟一家公司并购，需要分析多个合同，并生成法律简报。

最初，他们让多个 Agent 同时维护一个共享文件：

wiki/
└── provisions.md

每个 Agent 负责一个合同，把合同条款整理到同一个文件中。

结果出现了问题：

多个 Agent 同时写入，共享内容发生覆盖，部分信息丢失。

57 条需要保留的合同事实，最终只留下了 41 条。

72% 保留率

后来 Anthropic 调整了知识组织方式：

wiki/
├── contract-a.md
├── contract-b.md
├── contract-c.md
├── contract-d.md
└── index.md

每个 Agent 独立负责一个合同：

• 每个合同独立建立页面。
• 关键合同条款尽量原文引用。
• 避免多个 Agent 同时修改同一个文件。
• 最后通过索引建立关联。

最终 57 条事实全部保留。

100% 保留率

这件事说明：

多 Agent 知识库不能简单地采用多个 Agent 共同写一个大文件的方式。

需要考虑：

• 写入边界。
• 文件归属。
• 并发冲突。
• 数据来源。
• 内容完整性。
• 后续校验。

从工程角度看，我更倾向于：

1. 每个 Agent 负责独立的知识单元。
2. 采用独立文件或独立数据库记录。
3. 使用版本号或乐观锁控制并发。
4. 由专门的 Consolidation Agent 负责知识整合。
5. 整合完成后再更新全局索引。

这比让所有 Agent 直接修改一个公共 Wiki 更可靠。

八、这套系统实际上还包含一个重要能力：目标驱动的记忆

Anthropic 认为，记忆系统不应该对所有任务采用同样的整理方式。

例如：

假设有两个 Agent。

Agent A：个人助理

它应该重点记住：

• 用户偏好。
• 长期目标。
• 工作习惯。
• 历史决策。
• 经常使用的工具。

Agent B：合同审查 Agent

它应该重点记住：

• 合同条款。
• 金额和日期。
• 责任主体。
• 条款之间的约束关系。
• 原始文档证据。

这两个 Agent 的记忆结构显然不同。

Anthropic 在合同实验中发现，如果没有明确告诉 Agent 哪些信息最重要，Agent 可能会采用不适合任务的知识组织方式。

他们通过反思任务失败，调整 Wiki 构建规则，最终让每个合同拥有独立页面，并要求关键条款原文保留。

因此，Dreaming 不仅是整理记忆，还可以根据目标改变记忆的组织方式。

我认为这意味着：

Memory 不应该只有一个通用的记忆提炼器，还应该有面向不同业务目标的记忆策略。

九、把这篇文章放到现有 AI 技术体系中看

我认为这部分最值得深入理解。

很多人会把 Agent Memory、RAG、向量数据库、知识图谱混在一起。

但它们实际上不是同一个层次的东西。

它们不是互相替代的关系。

例如，一个成熟的 Agent Memory 系统完全可以使用：

• MySQL：保存记忆元数据、状态、版本。
• 对象存储：保存原始 Transcript。
• Vector DB：语义检索记忆。
• Wiki：组织长期知识。
• LLM：判断重要性、提炼知识、纠错。
• 定时任务：执行 Dreaming。

其中，向量数据库只是检索组件，不是记忆系统本身。

一个特别值得注意的地方是：

Anthropic 的实验中，Wiki + Search 比单纯 Search 更好，但 Wiki 单独使用并不如两者结合。

这意味着，知识组织和原始资料检索应该并存，而不是让摘要或 Wiki 取代原始资料。

十、如果自己实现一套 Agent Memory，应该怎么设计？

结合文章，我认为可以把它落地成一个相对完整的架构。

我会把系统拆成六个模块：

具体可以这样实现：

我会特别设计一个记忆状态字段：

{
  "content": "FC部署时需要注意时区配置",
  "category": "technical_experience",
  "status": "verified",
  "confidence": 0.95,
  "source": "session-001",
  "created_at": "2026-11-08",
  "last_verified_at": "2026-11-08",
  "access_count": 5,
  "version": 2
}

其中：

• verified：已经通过实际验证。
• unverified：尚未验证。
• outdated：可能已经过期。
• superseded：已经被更新的结论替代。

这样 Dreaming 就可以有依据地管理记忆，而不是让模型随意覆盖旧知识。

十一、这篇文章有哪些不足和待解决问题？

Anthropic 自己在文章最后也提出了几个开放问题。

1. 什么时候执行 Dreaming？

实时执行会干扰当前任务，完全后台执行又可能导致新知识无法及时使用。

可能的策略：

• 每次 Session 结束后执行轻量整理。
• 每天执行一次完整 Dreaming。
• 高频访问的记忆优先重新验证。
• 出现重大错误时触发专项 Dreaming。

2. 如何判断记忆是否过期？

例如：

之前记录数据库版本是 MySQL 8.0。

半年后项目升级到 MySQL 9.x。

旧记忆不一定完全错误，但已经不再适用于当前环境。

需要有版本、时间、来源和适用范围等信息。

3. 如何避免 Dreaming 自己产生幻觉？

这是我认为最重要的问题。

假设 Agent 第一次就理解错了某个技术问题，第二次又根据错误记录进行总结，那么错误就可能被进一步固化。

所以 Dreaming 应该尽量：

• 回溯原始 Transcript。
• 检查工具返回的真实结果。
• 区分事实和推测。
• 保留原始证据。
• 不确定时降低置信度，而不是强行给出结论。

4. Dreaming 本身需要多少计算资源？

这也是一个成本问题。

几亿 Tokens 的知识库，不可能每次都重新阅读一遍。

需要增量整理、按需验证、变化检测，以及根据记忆访问频率安排后台任务。

另外，文章中的实验主要来自 Anthropic 自己的模型、任务和测试环境，不能直接理解为所有 Agent 在生产环境都能获得相同提升。尤其是 25 个问题的 Wiki 实验，样本规模还比较有限。

十二、我的总结：这篇文章真正重要的是什么？

我认为有三个层次。

第一层：从记忆存储转向记忆管理。

以前我们设计 Agent，重点是如何保存信息、如何检索信息。

现在应该进一步考虑：

• 哪些信息值得保存？
• 哪些信息已经过期？
• 哪些结论需要验证？
• 哪些经验可以合并？
• 哪些记忆应该被提升到 Context？

第二层：从 RAG 转向持续知识构建。

传统 RAG 更多是被动的：

用户提问 → 检索文档 → LLM 回答。

Anthropic 描述的方向则是：

Agent 执行任务 → 积累经验 → 后台整理 → 建立知识体系 → 下一次执行得更好。

这实际上是一个持续学习的工程闭环，但不需要修改模型权重。

第三层：Agent 开始具备跨 Session 的经验积累能力。

我觉得这是长期 Agent 系统非常重要的基础能力。

一个真正长期运行的 Agent，不应该每次启动都像一个新员工。

它应该逐渐了解：

• 自己负责什么。
• 之前做过什么。
• 哪些事情已经验证。
• 哪些方案曾经失败。
• 如何利用过去的经验解决新问题。

当然，这仍然不是模型参数意义上的学习，而是外部记忆系统带来的持续经验积累。

对你研究 Agent 架构的一个启发

我觉得可以把这篇文章和现在流行的 Coding Agent、RAG、Multi-Agent Harness 放在一起理解：

这几项能力组合起来，才逐渐接近一个真正可以长期工作的 Agent 系统。

我个人最看好的是 Dreaming + Wiki + Search 这个组合。

因为它不只是解决个人助手的记忆问题，还可以用于：

• 企业内部知识库持续维护。
• Coding Agent 的项目经验积累。
• 自动化运维 Agent 的故障经验库。
• 多 Agent 协作中的知识沉淀。
• 长周期自主研究 Agent。

尤其是 Coding Agent：如果它能把每次代码修改、构建失败、Bug 修复、技术决策沉淀成经过验证的项目知识，那么它就不再只是一个每次重新理解代码的工具，而是一个逐渐熟悉项目历史和工程习惯的开发者。

这可能是 Agent Memory 最有实际商业价值的方向之一。