本文永久链接 – https://tonybai.com/2026/11/07/anthropic-components-of-agent-memory
大家好，我是Tony Bai。
【导读】
AI Agent 正在从一次性问答工具走向长期自主工作的智能体。但一个始终没有解决好的问题是：当一次任务结束、上下文窗口关闭，下次启动的 Agent 如何继承过去的经验？
Anthropic 最新研究《The components of agent memory》提出了一套颇具启发性的记忆架构：从会话日志、记忆笔记，到知识 Wiki，再到自动注入上下文的记忆层，并通过一种叫作 Dreaming 的机制，在任务间隙持续整理和修正记忆。
更有意思的是，Anthropic 用 Pokémon 游戏、数据库问答和企业文档分析等实验，展示了这套机制如何让 Agent 从错误中学习、避免重复踩坑，并逐步构建自己的知识体系。
这可能意味着，Agent Memory 的竞争正在从“谁能存储更多历史”转向“谁更善于管理和利用经验”。
【文章要点】
- Agent Memory 不等于聊天记录。真正有价值的是能够跨会话复用的经验、规则和知识。
- Dreaming 是核心机制。Agent 在空闲时回顾历史记录，提炼经验、纠正错误、构建知识。
- 记忆不是越多越好。Pokémon 实验表明，精准记忆策略和规律，比无差别保存所有经历更有效。
- 记忆需要分层。原始日志、记忆笔记、知识 Wiki 和自动注入上下文各司其职。
- 记忆必须能够自我纠错。历史日志可以成为事实依据，帮助 Agent 识别和修复错误记忆。
- 知识地图可以提升复杂任务表现。当任务需要跨多个文档整合信息时，Wiki 能够发挥明显作用。
- 未来的 Agent Memory 是动态系统。它需要持续更新、遗忘、压缩和围绕目标进行组织。
Agent 最大的问题：每次启动，都像一个新人
想象这样一个场景。
你让一个 AI Agent 连续几天开发一个软件项目。
第一天，它研究了项目结构，发现测试需要设置特殊环境变量，记录了几个关键 API 的调用方式，还踩了一个配置方面的坑。
第二天，它修复了一个 Bug，发现昨天采用的某种实现方式存在问题，最终找到了一种更好的解决方案。
第三天，它继续开发。
问题来了：如果每次任务都启动一个全新的 Agent，前两天积累的经验还能保留下来吗？
通常情况下，答案并不乐观。
LLM 的上下文窗口是有限的。一次会话结束后，模型并不会自动保留这次会话中的所有经验。即使 Agent 使用了文件、向量数据库或其他外部存储，也不意味着它真正学会了如何利用这些信息。
这就是 Agent Memory 要解决的问题。
但 Anthropic 在这篇研究中提出了一个值得关注的观点：
Agent Memory 不应该只是一个存储历史信息的地方，而应该是一套持续组织和改进知识的系统。
这意味着，Agent 不仅要能够记住过去，还要能够回顾过去、修正过去，并为未来的任务重新组织知识。
Dreaming：让 Agent 在空闲时整理经验
Anthropic 借鉴了人类大脑的记忆机制。
人类并不是把经历过的所有事情都原封不动地保存下来。海马体在经历发生时参与记忆编码，而在睡眠和安静休息期间，大脑可能通过重放近期经历，将部分信息整合为长期知识。
Anthropic 将类似的思路引入 Agent，称之为 Dreaming（梦境整理）。
它的基本思想是：
Agent 工作时，持续产生会话记录、工具调用记录和任务结果。这些信息首先被保存在原始日志中。
当 Agent 暂时不工作时，系统启动一个后台整理过程，让模型重新审视这些历史记录。
在这个过程中，Agent 可以：
- 从历史任务中提炼值得长期保留的经验。
- 检查已有记忆，发现其中的错误。
- 将零散笔记整理成结构化知识。
- 建立不同知识之间的关联。
- 将最重要的信息提升到下一次会话的初始上下文中。
可以把它理解为：工作时积累经验，休息时消化经验，下次工作时带着更好的知识重新出发。
这与传统的 RAG 有一个重要区别。
传统 RAG 更关注如何从已有知识库中检索相关信息，而 Dreaming 还关注如何持续改造和维护这个知识库。
记忆不是越多越好：一个 Pokémon 实验
Anthropic 做了一个非常有意思的实验：让 Claude 玩《Pokémon Red》。
这是一款需要长时间探索、战斗、收集道具和完成任务的游戏，非常适合测试 Agent 的长期记忆能力。
研究人员比较了两个模型在游戏进行到约 10000 步时的记忆组织方式。
结果令人意外。
一个模型是 Sonnet 3.7。它倾向于记录几乎所有经历：每场战斗、每件道具、每个遇到的 NPC，甚至为很多细节单独创建文件。
最终，它生成了：
- 413 个记忆文件。
- 225 个文件夹。
- 977,930 个字符。
另一个模型是 Fable 5。它只创建了：
- 9 个普通记忆文件。
- 2 个文件夹。
- 1 个全局记忆文件
global.md。
总计只有约 43,406 个字符。
但 Fable 5 的游戏进度明显更好，获得了 4 枚徽章，而 Sonnet 3.7 只获得了 1 枚。
为什么？
因为 Sonnet 3.7 把大量游戏状态也保存了下来，例如当前金钱、地图位置等。这些信息实际上每一轮都能从游戏画面中重新获取，根本没有必要长期记忆。
更糟糕的是，游戏状态一直在变化，之前记录的信息很容易过期。Agent 不得不花费大量时间整理和检查这些记忆，反而影响了真正的游戏进度。
Fable 5 则采取了不同的策略。
它主要记录那些无法直接从当前游戏画面中获取、但对未来决策有帮助的知识，例如：
- 当前的长期目标。
- 接下来应该采取的行动计划。
- 某条路线的导航策略。
- 已经验证有效的游戏技巧。
- 过去失败后总结出的经验。
例如，连续七个精灵球都没能抓住一条鲤鱼王后，Claude 将经验总结为一条规则：如果连续三次以上捕捉失败，可以尝试改变操作节奏，在菜单操作之间插入额外等待。
这才是真正有价值的记忆。
记忆的价值不在于保存了多少信息，而在于保存了多少未来无法轻易重新获得、并且能够改善决策的信息。
Anthropic 提出的四层记忆架构
那么，一个成熟的 Agent Memory 应该如何组织？
Anthropic 在文章中展示了一套分层架构。
它包含四个层次：
- Transcripts：原始会话日志。
- Memory Notes：记忆笔记。
- Memory Representations：结构化知识表示，例如 Wiki。
- Injected Context：自动注入下一次会话的上下文。
可以用下面这张图理解它们之间的关系。
Transcripts：保留原始经历
这是最底层，也是最接近事实的一层。
它记录 Agent 在过去会话中做过什么，包括用户输入、模型输出、工具调用以及工具返回结果。
为什么要保留原始记录？
因为记忆笔记可能存在错误，而原始日志能够作为回溯和验证的依据。
如果 Agent 只保存自己总结出来的结论，却丢弃了原始经历，那么一旦总结出错，后续就很难发现问题。
Memory Notes：提炼值得记住的信息
这一层负责把原始经历转化为简洁的记忆笔记。
例如，一个 Coding Agent 在多个会话中发现：
- 项目使用 Go 1.26。
- 测试需要设置特定环境变量。
- 某个模块的接口不能随意修改。
- 某种构建方式在 CI 环境中存在问题。
这些信息可以被整理成独立的 Markdown 文件，供未来会话读取。
值得注意的是，Anthropic 认为 Agent 应该具备判断信息重要性的能力。
它并没有主张为所有任务预先设定僵化的记忆规则。
研究发现，在能力较强的模型上，赋予模型自主判断哪些信息值得记住的自由度，往往比硬性规定“只记录失败”更有效。
Memory Representations：构建知识地图
当记忆越来越多，单纯依靠一堆 Markdown 文件就不够了。
Agent 需要知道不同知识之间有什么联系，以及应该从哪里找到相关信息。
Anthropic 将这类结构化知识表示称为 Memory Representations，其中一个重要形式就是 Wiki。
它由多个相互链接的知识页面构成，类似于一张可以持续维护的知识地图。
例如，一个软件项目的 Wiki 可以包含：
- 项目架构。
- 核心模块。
- API 设计。
- 构建与部署流程。
- 已知问题。
- 技术决策及其背景。
当 Agent 需要解决一个复杂问题时，就可以通过 Wiki 快速定位相关知识，而不必每次从海量原始日志中重新寻找线索。
Injected Context：把最重要的知识带入下一次会话
这是最靠近 Agent 工作入口的一层。
某些信息非常重要，如果每次都要求 Agent 主动搜索，就会增加额外成本。
因此，系统可以把最关键的记忆预先注入下一次会话的上下文。
例如：
- 当前正在进行的项目。
- 用户的重要偏好。
- 项目的关键约束。
- 当前目标和下一步计划。
- 最重要的技术决策。
不过，这一层必须保持足够精简。
Anthropic 特别提到，注入的记忆会占用宝贵的上下文 Token，而且错误记忆如果被持续注入，可能在每次会话中反复影响 Agent。
这也是为什么 Claude Code 的 Auto Memory 不会把所有记忆文件都塞进上下文，而是通过 MEMORY.md 作为入口索引，只自动加载其前 200 行或 25 KB。
记忆也会出错：Dreaming 如何纠正错误？
如果 Agent 在某次任务中记住了错误信息，那么这条错误记忆可能在未来不断被使用。
这甚至比没有记忆更糟糕。
Anthropic 用 Pokémon 游戏中的一段经历展示了这个问题。
Claude 在探索 Mt. Moon（月见山）时，错误地记住了 Pokémon Center 的方位。
随后，它根据这个错误记忆判断自己已经通过了山洞，于是继续向前走。
但实际上，它走错了方向，反复掉进之前走过的路线。
问题在于：Agent 不仅记错了，还把自己的错误推理当成了事实。
Anthropic 随后启动 Dreaming，让 Claude 回顾之前的会话记录，并将记忆笔记与原始日志进行比对。
最终，Claude 发现了位置判断错误，修正了记忆。
结果非常明显：
- 没有记忆的运行无法顺利通过山洞。
- 使用错误记忆的运行反复走回头路。
- 使用 Dreaming 修正记忆后，Claude 成功重新进入山洞，最终抵达下一座城市 Cerulean City。
这说明一个重要问题：
长期记忆系统不能只负责写入，还必须具备验证、纠错和更新的能力。
记忆不是一份永远正确的事实清单，而是一套需要持续维护的知识资产。
从零散笔记到知识 Wiki：复杂任务的突破
记忆笔记解决了信息保存问题，但如果 Agent 要处理数十万份文档，单纯依赖笔记文件和文本搜索还够用吗？
Anthropic 进一步测试了 Wiki 的价值。
研究人员使用了一个包含约 35 万份内部文档的数据集，总规模约 4.2 亿 Token。
他们让多个 Claude Agent 持续工作，通过 Dreaming 构建和维护一套相互链接的 Wiki。
整个过程持续了 128 个会话。
随着 Wiki 不断完善，Agent 对相关问题的回答能力也持续提升。
在一组包含 25 个问题的测试中：
- 仅经过 2 个会话构建的 Wiki，评分达到 13%。
- 经过 128 个会话持续整理的 Wiki，达到 48%。
- Wiki 与搜索工具结合，最终达到 61%。
而单独使用搜索工具时，得分为 53%。
更重要的是，Wiki 不只是提升了回答准确率，还节省了成本。
结合 Wiki 和搜索工具，每个问题平均可以节省约 20,000 个 Token。
不过，Anthropic 也发现了一个有趣的边界：
并不是所有任务都需要 Wiki。
如果答案可以直接从某一份文档中搜索出来，Wiki 带来的收益就不明显。
只有当任务需要跨多个文档关联信息、进行综合判断或计算时，知识地图才更有价值。
研究中还有一个值得警惕的案例：某次 Wiki 最终比原始文档还要大。
这让人想起博尔赫斯的短篇小说《论精确的科学》，其中的地图绘制者最终制作了一张与帝国本身一样大的地图。
地图失去了抽象和简化的意义。
Agent Memory 也面临同样的问题：如果知识库只是不断复制原始信息，而没有真正提炼出有价值的结构，那么它就失去了存在的意义。
对 Agent 工程实践有什么启示？
Anthropic 的研究并不只是提出一种新概念，它还给 Agent 工程实践带来了几个值得思考的方向。
第一，Agent Memory 应该与任务执行解耦。
不要让 Agent 在每次工作时都承担大量记忆整理任务。
可以在任务结束后，或者夜间空闲时，启动独立的后台整理流程。
第二，记忆应该分层，而不是堆在一个文件里。
原始日志负责追溯，记忆笔记负责提炼，Wiki 负责建立关联，注入上下文负责提供即时可用的信息。
不同层次应该有不同的更新频率和访问策略。
第三，记忆需要具备来源和可信度。
一条经验究竟来自真实验证，还是模型自己的推测？它是在什么时间、什么环境下成立的？
这些信息应该尽可能保留。
特别是技术类 Agent，版本、配置和环境变化都可能让历史经验失效。
第四，Agent 应该学会记住经验，而不是记住所有状态。
当前目录、当前时间、当前进度等信息，很多时候可以通过工具重新获取。
真正值得长期保存的是那些经过验证的规则、技术决策、失败教训和隐含约束。
第五，Dreaming 也需要成本控制。
后台整理并不是免费的。它需要额外的模型调用和计算资源。
因此，什么时候整理、整理哪些记忆、哪些记忆需要重新验证，都值得纳入系统设计。
小结：Agent 的下一场竞争，是经验管理能力
过去，我们讨论 Agent 时，关注点主要集中在模型能力、工具调用、规划能力和多 Agent 协作。
但当 Agent 开始承担持续数天、数周甚至数月的任务时，另一个问题会越来越突出：
它能否把过去的经验真正转化为未来的能力？
Anthropic 这篇研究给出了一个很有启发性的方向：
Agent 不应该只是一个拥有更大上下文窗口的模型，而应该是一个能够持续积累、整理、验证和利用经验的系统。
Dreaming 让记忆整理从实时任务中分离出来；分层架构让不同类型的知识各司其职；Wiki 让零散信息形成关联；记忆纠错机制则避免错误在长期运行中不断放大。
当然，这套机制仍有不少开放问题，例如记忆的更新频率、过期知识的淘汰、错误记忆的检测，以及后台整理的计算成本。
但方向已经相当清晰。
未来优秀的 Agent，可能不只是因为它使用了更强的模型，而是因为它拥有一套更好的经验管理系统。
真正聪明的 Agent，不仅要善于完成今天的任务，还要善于让今天的经历，成为明天完成任务的优势。
原文链接：《The components of agent memory》，2026 年 11 月 6 日 - https://www.anthropic.com/research/components-of-agent-memory
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
- 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
- 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
- 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
- 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
- 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
- 告别低效，重塑开发范式
- 驾驭AI Agent(Claude Code)，实现工作流自动化
- 从“AI使用者”进化为规范驱动开发的“工作流指挥家”
扫描下方二维码，开启你的AI原生开发之旅。
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
