https://jiajia.fun/qa/4f69b5ee-%E8%AF%BB%E8%AF%BB%E8%BF%99%E7%AF%87%E6%96%87%E7%AB%A0-%E4%BB%8E-transcripts-%E8%BF%99%E7%A7%8D%E5%85%A8%E9%87%8F%E4%BA%8B%E4%BB%B6%E6%97%A5%E5%BF%97-%E5%88%B0-memory-notes-%E8%BF%99%E7%A7%8D-agent-%E4%B8%BB%E5%8A%A8%E8%AE%B0%E5%BD%95%E7%9A%84%E9%87%8D%E8%A6%81%E8%AE%B0%E5%BF%86-%E5%86%8D%E5%88%B0-memory-representations

# https://www.anthropic.com/research/components-of-agent-memory，读读这篇文章。从 Transcripts 这种全量事件日志，到 Memory notes 这种 Agent 主动记录的重要记忆，再到 Memory representations 这种相互关联的复杂图谱，最后到 injected context 这种每次载入上下文的重要常识。说说这个过程中，记忆是怎样形成的，是怎样固化，淘汰，更新的。

回复 群友 3892 这篇之前有群友问过，完整解读在这里：https://jiajia.fun/digest/3d9bc42bab3319755bffed14 你问的是记忆的形成、固化、淘汰和更新这条链，按四个组件拆开讲，关键点在于：\*\*每一层的可信度不一样，记忆的维护本质上是不断用更低层的事实去纠正更高层的抽象\*\*。 一、形成：写得少比写得多好 第一层是 transcript，全量事件日志，不经过判断，是原始事实。它本身不是“记忆”，是记忆的燃料。真正的记忆从 memory notes 开始——Claude 在会话里按显著性主动写笔记，这在机制上对应人脑的“标记”：经历当下被打上标签，之后才会被优先重放。 形成这一步最难的是判断什么值得写。文章里 Pokémon 的对比最能说明：Sonnet 3.7 觉得一切都重要，1 万步写了 413 个文件、225 个文件夹，只拿到一个徽章；Fable 5 只写了 9 个文件，拿到四个徽章，还打穿了游戏。差别在于前者记的是屏幕上每回合都能读到的东西（钱多少、人在哪），后者记的是只有靠推理才存在、不写就消失的东西（策略、计划、验证过的规则，比如连丢三个球之后要改变按键节奏）。 所以这里的选择标准是：\*\*能从原始日志低成本读回来的，不写；必须靠当前这次推理才产出的，才写\*\*。文章还补了一条反直觉的结论：给强模型定死规则（比如“只记录失败”）反而会让它掉分，因为固定规则覆盖不了判断；该给的是“记忆是用来干什么的”，怎么用交给模型自己判断。老模型才需要喂具体操作指令。 二、固化：从笔记到表示 笔记攒多了是散沙，固化这一步就是把散沙变成结构。做法是 dreaming——在空闲时把 transcript 当事实基准，反过来读一遍自己的笔记，写错就改、缺页就补、重复就合并。 wiki 是最主要的表示形式：一堆 Claude 自己写、自己维护、互相链接的页面，链接本身就是一张可导航的地图。它是一轮一轮长大的，早期像新员工，答不出什么；dreaming 从 2 轮加到 128 轮，25 题的成绩从 13% 涨到 48%。 但固化不是无脑建图，两条边界很关键： 一是 wiki 只在需要跨文档综合的地方有收益。涉及多份文件才能答的题，用 wiki 87%、纯搜索 73%；而单文档能检索到的题，wiki 没增益，甚至膨胀到比原始文件本身还大——那就是画了一张跟领土一样大的地图，等于没抽象。 二是固化的效果取决于结构跟目标对不对齐。同一个合同任务，一开始多个 agent 往同一张共享表里写，互相覆盖，57 个条款只剩 41 个，达成率 72%；改成一份合同一页、一个 agent 写、逐字引用不摘要，57 个全中，100%。所以固化里真正要紧的不是“有没有图谱”，是\*\*结构有没有按这个任务的判断标准来定\*\*。 三、淘汰：往下挪，而不是删掉 淘汰在文里最反直觉的地方是它主要不动内容，动的是位置。 笔记往上层提拔变成 injected context（每轮预加载），这件事必须极其克制：注进去的东西每轮都占 token，一条错的笔记会被带进此后每一个会话；而且指令越长遵循率越低，这跟 Claude Code 那份 MEMORY.md 只加载前 200 行或 25KB 是同一个原因。 所以顶层要一直保持小，dreaming 有一大块工作就是把细节往下挪、只留链接，让顶层当索引而不是当仓库。真正的“删”体现在别处：Pokémon 的例子中那个模型在 17 步里写了 6 个文件、删了 9 个文件，一步游戏都没玩——这是写得太多导致的维护税。Fable 5 那个 global.md 就是典型做法，只放当前目标、预设计划和“该不该写记忆”的规则本身，随玩随改。 四、更新：靠原始日志校正，这是整套设计的命门 笔记不可信，因为它是当下判断的产物，环境一变就会漂。文章里 Mt. Moon 那个例子讲得很清楚：模型记错了 PokéCenter 在哪一侧，出门就宣布“山在我身后、已完成”，然后掉下单向悬崖、滑回原路，连掉三次后写“我决定停止而不是继续循环”。dreaming 拿 transcript 去核对这条笔记，发现错了，重写之后它直接回洞穴、走到了下一个城市。没有记忆的对照组同样过不去。 这里能提炼的规则是：\*\*记忆只作为假设，transcript 是真值\*\*。任何一层抽象（笔记、wiki、注入的常识）都要能被下层的原始记录打回并重写，否则抽象出来的东西会一层层放大错误，这就是 wiki 会累积幻觉的原因。 更新还有两个当下的开放问题，值得你记住，做设计时一定会撞上： 一是写入时机。当场写保真度高，但打断主线任务；放后台 dreaming 不干扰，但产出不是立即可用。这是取 trade-off，没有通解。 二是更新频率。不可能全量校验所有记忆，可行做法是把算力集中在“会变的信息”上，或者按访问频率调 dreaming 的节奏——越常被读到的记忆，越值得花 token 去校验。 落到你想要的那句话：这条链的形成是把经验压缩成预测（写下一条规则，就是在赌未来还会用到它），固化是把笔记组织成可导航的结构，淘汰是把细节沉到下层、顶层只留索引，更新是拿原始日志不断把上层假设打回原形。四件事里最容易做错的都是同一个方向——写得太多、抽象得太满、顶层塞得太厚。 要不要我接着把这条链对到 Claude Code 那套自动记忆的实际文件结构上，看看顶层索引、dreaming 和 wiki 各自落在哪个位置？