Agent 记忆设计：从堆日志到分层整理

把工具结果、聊天记录和零碎事实全部塞进向量库，再靠余弦相似度检索，不一定能让 Agent 越用越聪明。记忆也会过期、出错，还会挤占执行任务的注意力。

这篇文章解读了 Anthropic 于 2026 年 11 月 6 日发布、Lance Martin 撰写的记忆研究。它最有用的结论是：Agent 应该保存经过验证的经验，并保留纠错依据。至于要不要建知识库、安排后台整理，则要看收益能否覆盖维护成本。

该记住的是经验，还是随时能查到的状态？

研究里的记忆有明确边界：Agent 从用户和任务中获得知识，跨会话保存，以后作为上下文读取。它不包括更新模型权重、单次对话内的上下文学习，也不等同于压缩旧消息的 compaction。

研究把记忆分成四层：原始会话记录 transcripts、工作中写下的笔记 notes、相互链接的知识页面 representations，以及每次会话启动时自动加载的 injected context。旁边还有一个整理过程 dreaming：离线重读记录，修正笔记、补齐关联，再挑选值得放进启动上下文的内容。这延续了 Letta 和 UC Berkeley 的 sleep-time compute 思路，把部分计算安排到任务间隙。

为什么不能全存？Pokémon Red 实验很直观。在约 10,000 步时，Claude Sonnet 3.7 已经建立 225 个目录、413 个记忆文件，却只拿到 1 枚徽章。它一度花了 17 步创建 6 个文件、删除 9 个文件，游戏操作完全停了下来。

Claude Fable 5 则在两个目录里写了 9 个文件，另加一份 global.md，记录当前目标、道馆计划和自己的记忆规则，拿到 4 枚徽章。

钱和地图位置每回合都能从屏幕读取，存下来容易过期；走通的策略和验证过的规则，才是下一次需要复用的东西。

记忆的价值取决于它减少了多少重复探索，而不是保存了多少内容。

不过，这里比较的是不同模型，不能据此断言「少写文件」单独造成了成绩提升。

模型越强，记忆规则就该写得越少吗？

在 Continual Learning Bench（CL-Bench）1.0 中，Agent 回答数据库问题，每次尝试后获得正确答案，并能为后续会话写记忆。

Opus 5 首次形成了研究所说的完整闭环：记录规则、规则成立的依据、此前答案，以及容易踩的坑。它保存的不只是结论，还有以后判断结论是否适用的线索。

但当研究要求 Opus 5 和 Opus 4.7「只记录失败」时，记忆带来的收益损失了很大一部分。失败记录无法覆盖成功验证出的规则，固定筛选条件也可能挡住有用经验。

旧模型又是另一种情况。明确要求 Sonnet 4.6 先读记忆、再检验自己的推测，得分接近翻倍。Sonnet 5 无需提醒，10 次里有 9 次会先读记忆；Sonnet 4.6 自发这样做的比例不到一半。

因此，文章建议：能力强的模型可以只给记忆目录和用途说明；能力较弱的模型需要明确步骤。这不是取消约束，而是区分「它不会主动做」和「它已经会做」。具体该给多少提示，仍要用自己的任务验证。

Dreaming 能修错，但知识库不是越大越好

Pokémon 实验中，Claude 曾错误记录 PokéCenter 位于 Mt. Moon 东侧，又宣布「Mt Moon DONE」。随后它跳下一处单向台阶，反复绕回前一条路线，无法到达 Cerulean City。

一次 dreaming 检查把笔记与会话记录对照，发现并改正错误。Claude 才重新进入洞穴，抵达目的地。

笔记是一条待核实的判断，原始记录才是追查它从何而来的依据。

同样的整理机制也能建立 wiki，但收益与问题类型有关。在 Stainless 约 350,000 个文件、约 420M tokens 的语料上，研究使用 25 道评估题。Dreaming 从 2 个会话扩大到 128 个会话后，仅依靠 wiki 的评分标准覆盖率从 13% 提升到 48%。

加入搜索后，search + wiki 从 54% 提升到 61%，纯搜索为 53%，每题还节省约 20,000 tokens。

另有 24 道并购问题，其中超过一半需要结合多份文档。在这些跨文档题目上，wiki 得分为 87%，纯搜索为 73%。但 Harvey LAB 法律简报任务的大部分评分项来自单篇文档，wiki 没有明确收益。另一个任务里，wiki 甚至比源文档还大。

大白话解释：如果答案需要把散落各处的条件拼起来，提前整理关系可能有用；一次文本搜索就能找到答案时，再维护一套页面未必划算。

谁来写记忆、启动时读多少，都要有边界

知识库也有并发写入问题。在一项 LAB 收购任务中，多个 Agent 同时往共享表格写合同条款，彼此覆盖。最终简报只包含 57 个评分事实中的 41 个，覆盖率为 72%。

研究反思并重写构建指令后，改成每份合同单独一页、由一个 Agent 写入，并逐字引用条款，结果达到 57/57，也就是 100%。这次改动同时涉及写入归属和内容要求，不能只归功于拆页面。

启动时加载的记忆则需要严格限量。文章给出的 Claude Code auto memory 行为是：只加载 MEMORY.md 的前 200 行或 25 KB，用它索引已有知识及其位置。错误内容一旦进入这一层，就会影响每次会话；文章还转述文档提醒，过长的指令文件会降低遵循程度。

基于这些实验，作者提出了自己的工程方案，明确不是 Anthropic 的实现代码：用 run ID 保存完整记录；笔记附上来源和验证状态；每晚或每 N 次会话安排 dreaming，纠错、去重、修复链接，只把少量高价值笔记提升到启动索引，并在代码里限制行数或字节数。

检查也应有所取舍。研究承认持续核验全部记忆并不现实，可以优先处理易变信息，或按访问频率调整整理周期。

我的判断

我赞同把记忆看成需要维护的数据。它至少要回答三个问题：谁写的，依据是什么，现在还成立吗？这比单纯调整向量检索参数更接近问题根源。

但这些结果还不足以证明某种记忆架构普遍更好。游戏比较混入了模型能力差异；「强模型少干预」依赖具体模型和任务；wiki 实验的题量有限，也没有给出完整的构建成本、整理耗时和长期维护账单。

Dreaming 也有代价：会话内记笔记占注意力，后台整理又不能立即提供结果，还可能引入新的错误。对于作者提出的每晚整理、按 N 次会话触发等方案，原文没有给出对照数据，应当视为工程经验。

纯文本搜索或会话记录检索，仍然适合作为起点。只有跨文档问题反复出现、整理后的收益能被测出来，才有理由增加 wiki 这一层。

能拿来做什么

• 给日常 AI 编程记忆建立准入条件。优先保存已验证的项目约定、故障原因和修复陷阱，文件路径、当前构建状态等可直接读取的信息，按需查询即可。
• 为前端或 Node 项目的经验笔记附上任务 ID、原始记录位置和验证结果。尚未复现的推测明确标注，后续纠错才能找到依据。
• 把启动记忆做成简短索引，并在加载代码里设置行数或字节上限。复杂排障过程放在独立文件，需要时再读取。
• 用真实历史问题比较纯搜索与 search + wiki，记录答案正确性、token 消耗和整理成本。只有确实需要拼接多份文档的问题，才优先尝试 wiki。