Anthropic 让 Agent 学会了「做梦」，重新思考 AI 的长期记忆

Leafw 收录于 AI

2026-11-08 约 8364 字预计阅读 17 分钟

2026 年 11 月 6 日，Anthropic 发布了一篇名为《The components of agent memory》的技术文章，讨论了一个在 Agent 开发中越来越重要的问题：如何让 AI Agent 拥有真正有价值的长期记忆？

提到 Agent Memory，我们可能首先想到的是将历史对话保存到数据库，通过 Embedding 和向量检索，在需要时将相关内容重新注入上下文。

这也是目前许多 Agent Memory 框架采用的基本思路。

但随着 Agent 开始承担越来越复杂的任务，这种简单的记忆机制逐渐暴露出一些问题。

例如：

Agent 应该记住哪些信息？难道每一次工具调用、每一段对话都值得永久保存吗？
如果 Agent 曾经得出过错误的结论，这个错误会不会在未来反复影响它？
当 Agent 已经积累了数百万 Tokens 的历史信息，如何快速找到真正有价值的知识？
如果某个经验最初看起来不重要，但后来发现非常关键，Agent 是否有机会重新识别它？

Anthropic 认为，Agent Memory 需要具备更完整的生命周期管理能力。

为此，他们提出了一种分层记忆架构，并引入了一个很有意思的机制：Dreaming（做梦）。

简单来说，就是让 Agent 在执行任务之外，利用额外的计算资源，回顾过去的经历，纠正错误，提炼经验，并将零散的信息组织成未来可以复用的知识。

一、为什么 Agent 需要「做梦」？

文章开头引用了丹麦哲学家克尔凯郭尔的一句话：

Life can only be understood backward, but it must be lived forward.

生活只能回头理解，却必须向前经历。

Anthropic 认为，这句话同样适用于 Agent Memory。

当 Agent 正在执行任务时，它只能根据当前掌握的信息判断什么值得记忆。

但这种判断未必准确。

例如，一个编程 Agent 在排查数据库性能问题时，可能尝试了十几种方案。

它可能把最终解决问题的 SQL 记录下来，却忽略了某一次失败实验暴露出的数据库兼容性问题。

直到未来再次遇到类似的问题，它才发现之前那个细节十分重要。

人类也会遇到类似情况。

我们每天经历大量事件，但最终能够形成长期记忆的只是其中一部分。

神经科学研究认为，大脑会在睡眠和安静休息期间重新激活部分经历，并逐渐将其整合为更稳定的长期知识。

Anthropic 希望 Agent 也能够拥有类似的机制。

Agent 正常工作时，持续产生会话记录、工具调用结果和重要观察。

当它暂时不需要执行用户任务时，另一个独立的记忆维护过程可以重新审视这些历史记录。

这个过程被称为 Dreaming。

需要说明的是，Dreaming 并非 Anthropic 首次提出的概念。此前 Letta 和 UC Berkeley 已经探索过类似的 Sleep-time Compute 思路。

Anthropic 这篇文章的价值，在于将 Dreaming 放进一套完整的 Agent Memory 架构中，并通过一系列实验分析不同记忆机制的实际效果。

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

Anthropic 将 Agent Memory 划分为四个层级。

四个层级分别是：

层级	名称	作用
L1	Transcripts	保存原始会话和事件日志
L2	Memory Notes	保存 Agent 提炼的重要事实和经验
L3	Memory Representations	通过 Wiki 等形式组织知识
L4	Injected Context	将关键记忆自动加载到新会话

这里的四层是逻辑划分，不代表必须部署四套独立的存储系统。

1. Transcripts：原始记忆

Transcripts 保存 Agent 的原始执行过程，包括用户对话、工具调用、任务执行结果等。

例如，一个编程 Agent 可能产生这样的记录：

        
用户要求优化某个 SQL 查询。

Agent 查询数据库执行计划。
Agent 发现部分查询未命中索引。
Agent 尝试调整 SQL。
第一次修改失败。
第二次修改触发数据库兼容性问题。
第三次修改成功。

这些记录通常非常庞大，不适合直接全部加载到上下文中。

但它们保留了 Agent 实际经历过什么。

这就为未来的记忆验证提供了依据。

2. Memory Notes：重要经验

Memory Notes 是 Agent 从原始经历中提炼出的信息。

比如：

        
数据库查询优化经验

- 当前项目使用 MySQL 兼容数据库。
- 部分聚合查询需要注意 ONLY_FULL_GROUP_BY。
- 月度分表查询应尽可能限制扫描范围。
- 修改 SQL 后需要重新验证执行计划。

与原始日志相比，这些内容更加简洁，也更容易被未来的 Agent 复用。

不过，这里存在一个关键问题：

Agent 如何知道哪些内容值得保存？

Anthropic 认为，保存一条记忆，本质上包含了对未来需求的预测。

当 Agent 将一个规则写入长期记忆时，它实际上是在预测：未来某个会话可能需要再次使用这个规则。

但 Agent 无法提前知道未来会发生什么。

这也是 Dreaming 发挥作用的原因。

3. Memory Representations：知识组织

随着 Memory Notes 不断积累，简单的文件列表或向量检索可能无法满足复杂任务需求。

例如，Agent 需要回答：

「为什么某个项目最终选择了 ShardingSphere，而没有采用应用层手动分表？」

这个答案可能散落在多个会话中，包括架构设计、性能测试、技术选型和故障排查。

如果只检索其中一两条记忆，Agent 可能无法还原完整的决策过程。

因此，Anthropic 引入了 Wiki 这样的知识表示形式。

它可以将相关信息组织成相互关联的页面：

        
        
        
    
项目知识库
├── 系统架构
│   ├── 技术选型
│   └── 模块依赖
├── 数据库
│   ├── 分表设计
│   ├── SQL 兼容性
│   └── 性能优化
└── 故障记录
    ├── 查询异常
    └── 数据库超时

Wiki 页面之间可以通过链接建立关联。

这样 Agent 在回答复杂问题时，可以顺着知识关系逐步寻找信息，而不需要完全依赖向量相似度。

4. Injected Context：自动注入的记忆

这是最接近当前 Agent Prompt 的一层。

对于一个长期参与 Java 项目开发的 Agent，我们可能希望它在每次会话开始时，就知道：

        
# 项目基本信息

- JDK 17
- Spring Boot 3.x
- 使用 MyBatis-Plus
- 采用按月分表
- 修改数据库结构需要考虑历史分表兼容性

# 更多信息

- 数据库设计：memory/database.md
- 代码规范：memory/coding.md
- 已知问题：memory/issues.md

这类信息不需要每次都执行搜索。

但是，自动注入的记忆也存在明显问题。

如果内容太多，会消耗大量上下文窗口，并且可能降低模型对重要规则的遵循程度。

因此，Anthropic 强调这一层必须保持精简。

文章还提到了 Claude Code 的 Auto Memory。

Claude Code 不会把所有记忆文件全部加载到上下文中，而是只自动读取 MEMORY.md 的前 200 行或 25 KB，以先达到的限制为准。

顶层文件更多承担知识索引的作用。

真正需要具体信息时，再读取对应的记忆文件。

这与 Agent Skill 中常见的 Progressive Disclosure（渐进式披露）非常相似。

三、记忆越多，Agent 就越聪明吗？

Anthropic 通过一个很有意思的实验回答了这个问题。

他们让不同版本的 Claude 玩《宝可梦红》。

游戏过程中，Agent 需要记住路线、道具、角色、战斗经验和当前任务。

研究人员比较了 Claude Sonnet 3.7 与 Claude Fable 5 在大约执行 10,000 个动作之后的记忆情况。

实验结果如下：

指标	Sonnet 3.7	Fable 5
记忆文件	413 个	10 个
文件夹	225 个	2 个
记忆字符	977,930	43,406
游戏徽章	1 枚	4 枚

Sonnet 3.7 保存了大量细节。

几乎每次战斗、每个发现的道具、每个遇到的 NPC，都可能形成独立的记忆文件。

结果随着游戏进行，很多记录逐渐失效。

例如，角色当前位置和持有金钱会不断变化。

这些内容原本就能够从游戏画面中直接读取，长期保存反而增加了维护成本。

甚至在一次实验中，Sonnet 3.7 连续执行了 17 个步骤，创建了 6 个文件、删除了 9 个文件，却没有执行任何游戏操作。

相比之下，Fable 5 的记忆非常精简。

它主要保留三类信息：

当前目标和行动计划。
已经验证过的游戏规则。
未来可能反复使用的策略。

它还使用一个 global.md 文件管理核心信息和记忆索引。

最终，Fable 5 用远少于 Sonnet 3.7 的记忆，取得了更好的游戏进展。

这个实验揭示了一个重要问题：

记忆系统的效果，不能简单通过记录数量衡量。

Agent 应该尽可能保存那些无法轻易重新获取、未来又可能复用的信息。

对于能够随时通过工具获取的实时状态，通常没必要反复保存为长期记忆。

当然，这并不意味着记忆越少越好。

真正重要的是 Agent 对信息价值的判断能力。

Anthropic 将这种能力称为 Salience Judgment，即显著性判断。

四、Agent 能否通过记忆不断积累经验？

接下来，Anthropic 使用了 CL-Bench 1.0 中的数据库问答任务。

实验要求 Claude 根据数据库回答一系列问题。

每次回答后，系统会向它提供正确答案。

随后 Agent 可以根据反馈更新自己的记忆文件。

值得注意的是，每次提问都会开启新的会话。

不同会话之间唯一能够继承的，就是持久化的记忆目录。

因此，这个实验可以直接观察跨会话记忆是否真正提升了表现。

部分结果如下：

模型	无记忆	使用记忆
Sonnet 4.6	0.330	0.364
Opus 4.7	0.383	0.700
Opus 5	0.564	0.828
Sonnet 5.5	0.644	0.833
Opus 5.5	0.655	0.838

这些分数是特定数据库任务的平均奖励值，并不代表模型的通用能力分数。

可以看到，对于较强的模型，持久化记忆带来了明显的收益。

但不同模型使用记忆的方式也存在差异。

较早的模型在回答错误之后，往往只会记录一些未经验证的猜测。

而能力更强的模型开始形成完整的经验学习过程：

        
        
        
    
回答问题
    ↓
检查结果
    ↓
分析错误原因
    ↓
提出并测试假设
    ↓
提炼可靠规则
    ↓
更新长期记忆
    ↓
未来会话复用

例如，Opus 5 的记忆通常包含：

某条规则是什么。
该规则为何可信。
已经验证过的答案。
过去发现的陷阱及注意事项。

这相当于让 Agent 从一次次任务中积累经过验证的经验。

不过，Anthropic 还发现了一个反直觉的现象。

对于能力较强的模型，过度约束记忆行为，反而可能降低效果。

研究人员尝试要求 Agent「只记录失败」。

结果 Opus 5 和 Opus 4.7 从记忆中获得的性能增益明显下降。

因为这种规则可能让 Agent 忽略其他有价值的信息。

对于较强模型，Anthropic 更倾向于告诉它记忆的目的，然后让模型自行判断应该保存什么。

但这也取决于模型本身的能力。

例如，对 Sonnet 4.6 明确要求「回答前读取记忆，并验证之前的假设」，就将成绩从 0.364 提升到了 0.641。

因此，Agent Memory 的策略不能完全脱离底层模型能力来设计。

五、Dreaming：让 Agent 主动纠正错误记忆

到这里，Agent 已经能够通过历史经验改进表现。

但还有一个棘手的问题。

如果 Agent 保存的是错误记忆，该怎么办？

错误记忆比缺少记忆更加危险。

因为 Agent 可能会在未来的任务中反复读取它，并将其视为已经验证的事实。

Anthropic 同样通过《宝可梦红》中的一个实验展示了这个问题。

游戏中，Claude 需要穿过月见山，前往下一个城市。

但它错误记录了宝可梦中心的位置，将位于山洞入口西侧的建筑，记成了东侧。

这个看似很小的错误，造成了严重后果。

Claude 误以为自己已经穿过山洞。

随后它按照错误记忆继续行动，反复走到错误方向，甚至多次回到之前的路线。

最终，它没有成功抵达目标城市。

研究人员随后启用了 Dreaming。

Dreaming 重新读取原始会话日志，将历史记录与当前 Memory Notes 进行比较。

经过检查，Claude 发现之前对宝可梦中心位置的记录有误。

于是它修改了对应的记忆文件。

当下一次 Agent 读取这条记忆时，就能够正确判断自己所处的位置。

在实验中：

没有记忆的 Agent，未能抵达目标城市。
使用未经修正记忆的 Agent，同样未能抵达。
使用 Dreaming 修正记忆的 Agent，在累计第 1,935 个动作时成功抵达。

这个实验体现了 Dreaming 的重要价值。

它使得 Agent 可以在任务之外重新审视自己的结论。

而且这里有一个值得关注的设计：

Dreaming 使用原始 Transcripts 作为验证记忆的事实依据。

这意味着原始日志虽然庞大，却依然非常重要。

如果某条 Memory Note 存在争议，系统可以通过来源信息回溯到最初的对话或工具调用记录。

当然，原始日志也不一定永远正确。它可能包含用户的错误陈述或工具的异常结果。

因此，实际系统还需要区分原始观察、外部证据、推理结论以及已经验证的事实。

六、为什么 Anthropic 又引入了 Wiki？

Memory Notes 解决了重要信息的保存问题。

Dreaming 则可以维护这些信息的准确性。

但当记忆规模继续增长时，另一个问题出现了：

Agent 如何从大量彼此独立的记忆中找到完整答案？

传统方案通常采用关键词搜索或者向量检索。

但当一个问题需要结合多个历史事件、多个文档以及复杂的知识关联时，单独搜索可能会遗漏重要信息。

Anthropic 因此尝试让 Dreaming 构建 Wiki。

Wiki 可以将知识整理成相互链接的页面。

例如：

        
# 数据库分表设计

## 当前方案
采用按月分表。

## 设计背景
参见：[数据库性能问题](./performance.md)

## 技术选型
参见：[ShardingSphere 选型](./shardingsphere.md)

## 已知兼容性问题
参见：[SQL 兼容性问题](./sql-issues.md)

这样 Agent 可以通过一个入口逐步探索相关知识。

为了验证这种方式的效果，Anthropic 使用了收购的软件公司 Stainless 的内部文档。

文档规模约为：

350,000 个文件。
4.2 亿 Tokens。
25 个用于评估的问题。

他们通过 128 个连续会话构建和维护 Wiki。

实验结果如下：

方案	综合得分
仅使用搜索	53%
仅使用 Wiki	48%
Wiki + 搜索	61%

其中，随着 Wiki 不断完善，Wiki 与搜索结合的成绩从早期的 54% 提升到了 61%。

同时，结合 Wiki 和搜索，平均每道题还能节省约 20,000 Tokens。

这个结果非常有意思。

Wiki 单独使用时，效果甚至不如搜索。

但两者结合，却能进一步提高表现。

因为 Wiki 提供了知识之间的组织结构，而搜索可以补充 Wiki 没有覆盖的原始资料。

另外，Anthropic 还使用企业并购相关的法律文档进行了测试。

当问题需要结合多个文档时，使用 Wiki 的得分达到 87%，而只使用搜索的得分为 73%。

但并非所有任务都需要 Wiki。

如果答案已经集中在某一个文档中，直接搜索往往足够。

Anthropic 甚至遇到过 Wiki 比原始文档还大的情况。

原始文档只有 115 KB，生成的 Wiki 却达到了 203 KB，约为原始资料的 1.77 倍。

这种情况下，Wiki 已经失去了信息抽象的意义。

所以 Wiki 需要根据任务特点进行构建和维护。

七、Dreaming 不仅管理记忆，还可以优化记忆组织方式

文章还介绍了一个容易被忽略的实验。

在处理企业并购合同的任务中，Anthropic 让多个 Agent 并行构建 Wiki。

最初，多个 Agent 会同时编辑同一个合同条款汇总文件。

结果出现了并发写入问题。

某个 Agent 刚刚保存的内容，可能被另一个 Agent 覆盖。

最终，Wiki 只能保留 57 个关键事实中的 41 个。

研究人员随后让 Claude 分析失败原因，并尝试改进 Wiki 构建方式。

改进后的方案是：

每份合同由一个 Agent 负责，生成独立的 Wiki 页面。

同时，合同中的关键条款保留原始表述，避免过度概括导致信息丢失。

经过调整，57 个关键事实全部得以保留。

这说明 Dreaming 除了能够修正具体记忆，也可以帮助改进记忆的组织策略。

对于需要多个 Agent 并行处理知识的系统，这个实验尤其值得注意。

因为 Memory Service 最终仍然是一个有并发读写需求的存储系统。

如果没有合理的隔离与冲突控制机制，仅仅依靠 LLM 的推理能力并不能保证数据一致性。

八、Dreaming 应该如何在 Agent 系统中落地？

前面的内容主要来自 Anthropic 的实验。

接下来讨论一下，如果我们要开发自己的 Agent 平台，可以如何借鉴这套架构。

我比较倾向于把 Agent Runtime 与 Memory Service 解耦。

其中可以划分为三个核心组件。

1. Memory Reader：负责记忆读取

Memory Reader 负责根据当前任务加载合适的历史信息。

它需要支持几种模式：

自动注入

在 Agent 启动时读取少量高优先级记忆。

例如当前项目、开发规范、用户明确要求遵守的约束等。

语义检索

当 Agent 遇到与历史任务相关的问题时，通过关键词或向量检索找到相关内容。

知识导航

对于需要复杂推理的任务，可以通过 Wiki 和知识索引逐步探索关联信息。

这里应当避免将所有 Memory Notes 一次性加载到 Prompt 中。

2. Memory Writer：负责记忆写入

Memory Writer 负责将重要信息保存到长期存储。

但我不建议只保存文本内容。

例如，可以采用下面这种数据结构：

        
        
        
    
{
  "id": "mem_001",
  "type": "verified_rule",
  "content": "月度分表查询需要限制扫描范围",
  "scope": {
    "tenantId": "tenant_001",
    "projectId": "report-engine"
  },
  "confidence": 0.95,
  "source": {
    "sessionId": "session_123",
    "eventIds": ["event_12", "event_15"]
  },
  "verifiedAt": "2026-11-08T10:00:00Z",
  "status": "active"
}

这里最重要的几个字段是：

type：区分事实、经验、规则、偏好等信息。
scope：明确记忆的适用范围。
confidence：表示当前对这条记忆的可信程度。
source：记录记忆的原始来源。
verifiedAt：记录最近一次验证时间。
status：控制记忆是否仍然有效。

其中，可信度可以由模型评估和外部验证共同确定，不应仅凭模型自行打分就认定事实正确。

对于多租户 Agent 平台，还需要额外考虑租户、用户、项目等不同维度的记忆隔离。

3. Dreaming Worker：负责记忆维护

这是整套架构中最值得研究的部分。

Dreaming Worker 可以作为独立任务运行，也可以通过已有的 Agent Runtime 调用 LLM 完成维护。

我认为至少可以支持以下几类任务。

记忆去重

当多个会话保存了相似经验时，将它们合并，减少重复信息。

事实验证

读取 Memory Notes 的原始来源，对关键事实进行重新确认。

过期清理

识别已经失效的配置、历史状态或临时信息。

经验提炼

从多次相似任务中总结能够复用的规则。

知识组织

将分散的 Memory Notes 组织成 Wiki，并维护页面之间的链接。

记忆晋升与降级

高频使用的重要记忆，可以进入自动注入上下文。

长期没有使用、或者不再重要的信息，可以保留在下层存储中，按需检索。

不过，Dreaming 不一定需要不断运行。

根据文章提出的开放问题，我们可以考虑使用以下触发条件：

当前会话结束。
Agent 完成一个重要任务。
发现两条记忆相互冲突。
某条记忆被频繁访问。
某类知识发生较大变化。
系统进入空闲时间。

对于记忆规模较大的系统，还可以采用增量处理方式，避免每次重新扫描全部历史记录。

九、Agent Memory 与 RAG、Skill 有什么关系？

读到这里，可能会产生一个问题：

既然 Agent Memory 包含搜索、Wiki 和上下文注入，它与现有的 RAG、Skill 是否存在重叠？

我认为它们可以理解为不同层面的能力。

RAG 解决知识检索

RAG 的核心能力是让模型在回答问题时获取外部知识。

它更关注：

「当前问题需要从哪些资料中获取信息？」

当然，RAG 也可以结合重排、知识图谱和复杂的检索策略。

但它本身并没有规定一套持续维护 Agent 历史经验的机制。

Memory 解决经验积累

Memory 更关注：

「Agent 在过去的经历中学到了什么，以及这些经验如何帮助未来的任务？」

它可能保存用户偏好、已经验证的规则、历史决策、失败教训等。

Memory 可以使用 RAG 技术进行检索，但还需要管理这些信息如何产生、更新和失效。

Skill 解决能力复用

Skill 通常用于封装特定任务的执行方法。

例如：

如何生成数据库迁移脚本。
如何执行代码审查。
如何生成符合企业规范的营销话术。

Skill 更接近可以重复调用的工作流程和能力说明。

Memory 则可以记录执行这些 Skill 时发现的经验。

例如，Agent 多次调用某个数据库迁移 Skill 后，发现特定数据库版本存在兼容性问题。

这个经验可以进入 Memory。

经过验证之后，系统还可以考虑将它沉淀到 Skill 的执行规范中。

因此，这三者完全可以协同工作。

不过，是否将 Memory 中的经验自动写回 Skill，需要谨慎设计。

对于生产系统，我更倾向于先让 Agent 提出修改建议，再经过自动测试或人工审核，避免错误经验污染正式执行流程。

十、我对这篇文章的几点思考

Anthropic 的这篇文章，让我重新思考了 Agent Memory 的定位。

过去我们讨论 Agent Memory 时，经常将重点放在存储和检索上。

例如：

使用 Redis、PostgreSQL 还是向量数据库？
如何设计 Embedding？
如何降低向量检索的延迟？
如何处理长上下文？

这些问题当然重要。

但 Anthropic 的实验表明，决定长期记忆价值的，可能首先是 Agent 对记忆内容的判断和维护能力。

1. 长期记忆需要具备可纠错能力

传统的记忆提取流程，通常会把 LLM 生成的摘要直接保存起来。

但摘要本身可能包含错误。

如果缺少验证机制，这些错误会随着时间持续累积。

因此，我认为未来比较成熟的 Agent Memory 系统，应该为重要记忆保留来源信息，并支持重新验证。

这也是 Dreaming 最直接的工程价值。

2. 记忆应该是一套动态知识系统

用户的偏好可能变化，项目的技术架构也可能调整。

过去正确的记忆，未来不一定仍然适用。

因此，Memory 不能只支持不断追加数据。

它还应该支持更新、合并、废弃、重新验证以及知识关系重组。

当然，这些维护行为同样需要消耗模型计算资源。

如何控制 Dreaming 的成本，仍然是需要进一步研究的问题。

3. 模型能力可能改变 Memory 框架的设计方式

Anthropic 在实验中发现，较强模型往往能够自行判断什么值得记忆。

过度详细的记忆规则，有时反而会限制模型表现。

这让我想到 Agent Framework 的另一种发展趋势。

随着模型能力提升，Framework 可能会逐渐减少对模型行为的硬编码控制。

框架仍然需要提供明确的权限、边界和存储接口，但具体的信息提炼、知识关联和记忆维护，可以更多交给模型完成。

当然，这种思路是否有效，还需要结合具体模型和业务场景评估。

4. Dreaming 的复杂度需要与实际收益匹配

虽然文章展示了 Dreaming 的不少优势，但不能忽略它的成本。

例如，Anthropic 在 Wiki 实验中使用了大量额外计算，进行了 128 个连续的记忆构建会话。

对于普通 Agent 应用，这种规模的维护未必划算。

如果只是一个简单的个人助手，少量结构化记忆加语义搜索可能就已经足够。

而对于需要长期运行、反复处理相似任务、积累大量业务知识的 Agent，Dreaming 和 Wiki 才可能发挥更大的价值。

所以我认为，实际落地应该从简单的 Memory Notes 开始，再逐步引入验证、整理和知识组织机制。

最后

Anthropic 在文章最后留下了一个很有意思的观点。

Agent 永远无法准确预测未来会发生什么，因此也无法在每一次任务执行过程中，完美判断哪些经历值得保存。

但它可以在事后回顾自己的经历。

通过 Dreaming，Agent 可以重新理解过去发生的事情，纠正错误，将分散的信息整理成更有价值的知识。

这可能是未来长期运行 Agent 的一个重要方向。

Agent 的记忆能力，最终不应该只取决于它能够保存多少历史信息，还应该取决于它能从这些经历中提炼出多少可复用、可验证的经验。

对于 Agent 开发者来说，真正值得关注的，也许已经不只是如何给模型增加一个 Memory Tool。

更重要的是，如何构建一套能够持续演进的记忆系统。

参考资料

Anthropic：The components of agent memory，2026 年 11 月 6 日。
Anthropic：Agent Memory Cookbook
Continual Learning Bench (CL-Bench)