刚刚，Anthropic公开Claude内部记忆架构设计

Agent 能跨会话记事，不等于它有了可靠记忆。Anthropic 公开 Claude 内部记忆架构：原始记录、笔记、Wiki、注入上下文四层金字塔，靠 Dreaming 在中间回查证据、修正笔记，再把索引注入下一次会话。

Agent 能跨会话记住事情，不等于它真的拥有了可靠的长期记忆。真正困难的是：什么值得记住，错误记忆由谁修正，新会话应该优先看到什么，以及记忆维护本身要消耗多少上下文和算力。

Anthropic 最近公开了 Claude 内部记忆架构的设计思路。核心不是简单增加一个数据库，而是让在线记录和离线整理形成闭环：Agent 先记录经历，再由 Dreaming 过程回查原始记录、修正笔记、组织 Wiki，最后把最重要的索引注入下一次会话。

这套设计对开发者很有参考价值。记忆系统如果只会“越存越多”，最终会拖慢 Agent；如果只记失败，也会丢掉已经验证的成功经验。可靠记忆需要生命周期、证据链、分层访问和持续压缩。

Claude的记忆是一座四层金字塔

Claude 的跨会话记忆可以拆成四层：

1. Transcripts：完整的对话、任务和工具执行记录。
2. Memory Notes：Claude 主动写下的经验、规则、失败原因和计划。
3. Wiki：更稳定、结构化、可互相链接的知识表示。
4. Injected Context：新会话开始时自动加载的少量高价值索引。

Dreaming 不是第五层存储，而是贯穿四层的维护引擎。它从原始 Transcript 中寻找证据，修正已有 Note，组织 Wiki 页面，再把高频且重要的内容压缩成顶层索引。

四层之间不是一次性搬运。新经验可能先写入笔记，经过多次使用和验证后上升到 Wiki；失效、重复或被证据推翻的内容则被下沉或删除。记忆因此拥有了生命周期，而不是一张永久增长的事实表。

需要特别区分四类概念：模型训练产生的权重变化、单次会话内的学习、为延长当前任务而做的上下文压缩，以及真正跨会话保存的记忆。它们解决的问题、成本和安全边界都不一样。

记得少，Agent反而走得更远

在 CL-Bench 1.0 的数据库任务中，Claude 每次都从新会话开始，只能读取跨会话保留的记忆目录。答错后，它可以记录失败、提出解释、验证解释，再把已经确认的规则沉淀为下一次可用的经验。

Opus 5 的平均奖励从无记忆时的 0.564 提升到 0.828。真正带来跃迁的不是多存几条事实，而是保存了规则、验证依据和已知陷阱，形成了“执行、复盘、验证、沉淀”的学习循环。

宝可梦实验说明，记得多不等于记得好。约一万步运行后，Sonnet 3.7 写下 413 个文件，分布在 225 个文件夹中，却只拿到一枚徽章；Fable 5 只保留 10 个文件，却拿到四枚徽章。

位置、金钱这类每回合都能从屏幕读取的信息，不值得反复写入；策略、路线和验证过的规则，才是跨会话记忆的高价值内容。Sonnet 3.7 曾连续 17 步忙于增删记忆，完全没有推进游戏。

记忆目录会反过来影响 Agent：文件越多，检索和维护越耗步数，真正的任务空间越少。记忆不是免费资产，它需要预算，也需要垃圾回收策略。

模型越强，越不需要死板的记忆规则

一个直觉做法是规定“只记失败”。实验结果却显示，成功经验和已验证事实同样重要。只记录失败，会让 Opus 5 和 Opus 4.7 的记忆收益分别减少 0.234 和 0.150。

旧模型往往需要更多脚手架。Sonnet 4.6 加入记忆后平均奖励只有 0.364；明确要求它在答题前读取文件并验证猜想后，分数升至 0.641，接近无记忆基线的两倍。

因此，前沿模型更适合被告知“记忆为什么存在”，而不是被一套固定规则强行规定每次必须记什么。能力越强，越应该把显著性判断交给模型，同时让证据校验和权限边界留在系统层。

Dreaming用原始记录纠正错误记忆

在线写入最危险的问题是：一次错误判断可能被后续会话反复继承。宝可梦月见山任务中，Claude 错把宝可梦中心记在山洞东侧，并据此写下“月见山已经完成”。错误笔记不断被后续会话信任，角色三次回到旧路线，最终没有抵达下一座城市。

Dreaming 会把笔记重新和原始 Transcript 对照，找到位置错误并改写记忆。使用修正笔记的运行在第 1935 个累计动作抵达 Cerulean City，而原始记忆和无记忆两组都没有到达。

这个案例说明，记忆不是事实本身，而是可被原始经验校验的缓存。原始记录是证据锚点，笔记是压缩后的工作材料；两者必须保留可追溯关系。

128 轮离线整理，把文件堆变成知识地图

Anthropic 使用 Stainless 的约 35 万个文件、4.2 亿 Token 语料，让 Opus 5 在 128 个会话中持续撰写、合并、修剪并互链 Wiki 页面。

在 25 道评测题上，只使用 Wiki 的得分从 13% 提升到 48%；Wiki 加搜索达到 61%，高于单独搜索的 53%，同时每题少消耗约 2 万 Token。

Wiki 的价值不是取代搜索，而是先提供地图，再减少盲目搜索。需要跨文档组合信息时，Wiki 得分 87%，单独搜索为 73%；答案集中在单篇文档时，优势则不明显。

知识地图也可能膨胀到原始文档的 1.77 倍。也就是说，整理不是把语料换一种方式抄一遍，而是提取稳定概念、关系、索引和证据位置。

最珍贵的顶层，只放一个小索引

Dreaming 可以把高频、重要的笔记提升到 Injected Context，由 Harness 在新会话开始时自动加载。Claude 不需要先意识到应该搜索什么，就能获得完成当前任务所需的最小背景。

顶层不能无限扩张。注入内容会占用 Token，错误也会进入每次会话，过长指令还会降低遵循度。Claude Code 的自动记忆因此只加载 MEMORY.md 的前 200 行或 25 KB，其余细节留在下层按需读取。

顶层是目录，不是仓库。Dreaming 的一项核心工作，就是不断把细节下沉，只留下重要节点和链接。

目标写对，记忆才会朝正确方向生长

记忆如何组织，取决于它服务什么目标。在法律合同任务中，多个 Agent 起初共同维护一张条款表，相互覆盖导致信息丢失，最终只保留 57 项关键事实中的 41 项，完成度为 72%。

Claude 反思失败后改写构建指令：每份合同由一个 Agent 独立建页，条款逐字保留。结果 57 项事实全部保留，简报评测标准满足率达到 100%。

第二轮 Dreaming 还能跨会话补洞：将九个指向不存在页面的链接改到已有页面，并新增三个页面。它不仅整理已有经验，也在修复经验之间的连接。

给Agent记忆系统补上工程控制

如果要把这套思路落到代码 Agent 或企业知识库中，建议把记忆系统拆成四个独立组件：

组件	工程职责
原始记录	保存对话、工具调用、结果和证据，不随意覆盖
在线笔记	记录当前任务中值得复用的规则和决策
离线整理	合并、纠错、去重、建链接和删除失效内容
注入索引	只加载当前任务最需要的少量上下文

同时要记录记忆来源、更新时间、验证状态和使用效果。错误记忆不能只靠人工搜索发现，应该支持从笔记回溯到原始记录，再由评测任务验证修正是否有效。

国内开发者如果需要将 Claude Code 等工具接入兼容 API，可通过 [Code80]https://code.ai80.vip/home 配置 endpoint；记忆文件、用户数据、模型权限、密钥和审计规则仍应由项目侧控制。

常见问题

Dreaming是一个新的存储层吗？

不是。Dreaming 是贯穿 Transcript、Memory Notes、Wiki 和 Injected Context 的离线整理与维护过程。

记忆是不是越多越好？

不是。过多、重复或错误的记忆会消耗检索和执行步数。高质量记忆应该优先保存规则、策略、验证结果和稳定知识。

为什么要保留原始Transcript？

因为笔记可能出错。原始记录提供证据锚点，Dreaming 可以用它校验和修正压缩后的记忆。

为什么顶层上下文要尽量小？

注入内容会占用每次会话的 Token，错误也会被重复带入。顶层更适合放索引和高频规则，详细内容留在下层按需读取。

Agent记忆系统最重要的指标是什么？

除了命中率，还要看记忆是否仍然正确、是否减少重复工作、维护成本、检索 Token、错误传播和任务最终收益。

国内开发者如何接入兼容 API？

可以通过 Code80 了解接入方式，同时自行管理模型权限、记忆数据、密钥、数据留存和审计日志。