Anthropic 拆解 Agent 记忆：四层结构，97 万字符的记忆输给 4 万字符
如果只看官方博客，容易以为「把四层搭好就行了」。HN 上那条讨论里，最有分量的一类批评恰恰指向框架本身：把记忆定义成「关于未来需求的预测」，等于绕开了「模型无法持续学习」这个根本问题。换句话说，四层结构管理的是外部知识，而模型本身在每一次会话之间仍然什么都没学到。
还有几条批评值得直接放进来，因为它们是用户真实踩到的坑：
- 「模型创造有用记忆的能力很差」：有读者说自己试了很久，模型写出的记忆基本没用，做不了任何跨时间累积。这对应官方那条数据——Sonnet 4.6 几乎吃不到记忆的好处。
- 「关掉记忆是我减少 WTF per minute 的最好办法」：不止一个人说，把记忆关掉之后 agent 行为稳定多了。这呼应官方那条「注入风险」：一条坏笔记会在每次会话里重犯。
- 缺少溯源：有读者指出，多数记忆系统是改写或覆盖旧记忆，而不是保留原始来源。没有溯源，冲突就无从裁决——而这正是四层结构把「原始记录」放在地基上的理由。
- 「dreaming」这个词本身被反感：不少人认为把人类的「做梦」搬到机器上是过度拟人。这个批评偏语言学，但它指向一个真实风险——拟人化的词容易让人误以为这套机制和人类的记忆巩固是同一回事。
这些批评不影响官方数字的有效性，但它们决定了你怎么用这套框架：把它当成「管理上下文的工程方案」，而不是「让模型学会东西的机制」。前者现在就能用，后者还是开放问题。
7）能直接抄走的几条做法
官方给了建议，这里挑出可以直接落地的：
- 告诉记忆是干什么用的，但别规定死规则。越强的模型越应该自己判断什么值得记；对老模型反而要明确写「回答前先读记忆」「失败后先测假设」。
- 注入层保持索引化。Claude Code 的自动记忆只读
MEMORY.md前 200 行或 25 KB，剩下的靠链接往下找。这条几乎零成本，值得直接照抄。 - 多轮增量建 wiki，别想一次建完。每轮检查链接、补缺页。官方那个补页例子：9 个指向缺失
escrow-agreement页的链接被改指到已有页，补了 3 个页面，wiki 从 38 条/225 链接变成 41 条/278 链接。 - 并发写入必须分工。一份来源给一个 agent，精度要求高的地方逐字引用原文。上面那个 72% → 100% 的差距就是这么来的。
- 按任务类型选方案。需要跨多份文档综合 → wiki + 搜索；答案基本在单份文档里 → 纯检索更划算。
小结
这篇博客真正的贡献是把「agent 记忆」从一个模糊的卖点变成了四层有成本结构的工程问题。最该记住的三条是：注入层要小、笔记会被验证或推翻、wiki 是搜索的补充而不是替代。
最该警惕的是两个数字。第一个是 Sonnet 3.7 的 97.8 万字符换 1 个徽章——记忆的量不是成就，能把记忆压成一张地图才是。第二个是「只记失败」让 Opus 5 掉 0.234 分——不是所有「记下来」都是好事，错误的归纳会变成每次会话都要背的包袱。
最后一句留白：整套框架处理的是「会话之间保留什么」，而不是「模型本身学到什么」。官方在定义里就把权重更新排除在外了。所以真正的持续学习，到这篇为止仍然是空的。
想同时跑 Claude、GPT 几家的顶级模型订阅、在自己的 agent 里对比不同记忆方案？可以看看俱乐部的 Claude Max / ChatGPT Pro 拼车方案。
参考来源
这组数字该这么读：wiki 从 13% 爬到 48%，涨了三倍多，但仍然打不过纯搜索的 53%。加上搜索才到 61%。所以所谓「建 wiki 更好」是有前提的——它是在给搜索做补充，而不是替代。HN 上有读者从图里读出「wiki + 搜索比只吃 dreaming 更好、dreaming 只带来边际增益」，这个解读和上面的数字是一致的。
最有操作价值的一段反而很小：一个合同条款任务，起初 57 个事实只活下来 41 个（72%），原因是多个 agent 互相覆盖了同一个共享页面；改成「一份合同给一个 agent、条款逐字引用」之后，57 个全部活下来（100%）。同样的模型、同样的记忆结构，只改了并发写入的粒度，结果从 72% 到 100%。
5）官方自己承认的代价与风险
这篇博客值得读的地方在于，它没有把记忆写成纯收益。它列出的限制很具体：
- 时序矛盾：会话中写的笔记立刻可用但会打断任务；dreaming 产出的东西不打断任务，但可能太晚。这个问题没有公认解法。
- 过期：笔记写的时候可能就是错的，环境一变就失效。而一条过期的规则比没有规则更容易误导。
- 成本：持续核验所有记忆不现实，dreaming 本身要烧算力。所以「多久 dream 一次」是个真问题——官方的建议是朝「容易变化或访问频繁的信息」倾斜。
- 表示层质量：wiki 会积累错误和幻觉，也可能长大到比原始语料还大，却什么也没抽象出来（那个 203 KB 就是例子）。
- 注入风险：一条坏笔记会被注入到每一次会话；而且越长的指令文件，遵守率越低。
- 任务依赖：wiki 的收益不普适，简单的单文档任务可能不值得建。
6）HN 上最尖锐的批评：四层结构绕开了根本问题
如果只看官方博客，容易以为「把四层搭好就行了」。HN 上那条讨论里，最有分量的一类批评恰恰指向框架本身：把记忆定义成「关于未来需求的预测」，等于绕开了「模型无法持续学习」这个根本问题。换句话说，四层结构管理的是外部知识，而模型本身在每一次会话之间仍然什么都没学到。
还有几条批评值得直接放进来，因为它们是用户真实踩到的坑：
- 「模型创造有用记忆的能力很差」：有读者说自己试了很久，模型写出的记忆基本没用，做不了任何跨时间累积。这对应官方那条数据——Sonnet 4.6 几乎吃不到记忆的好处。
- 「关掉记忆是我减少 WTF per minute 的最好办法」：不止一个人说，把记忆关掉之后 agent 行为稳定多了。这呼应官方那条「注入风险」：一条坏笔记会在每次会话里重犯。
- 缺少溯源：有读者指出，多数记忆系统是改写或覆盖旧记忆，而不是保留原始来源。没有溯源，冲突就无从裁决——而这正是四层结构把「原始记录」放在地基上的理由。
- 「dreaming」这个词本身被反感：不少人认为把人类的「做梦」搬到机器上是过度拟人。这个批评偏语言学，但它指向一个真实风险——拟人化的词容易让人误以为这套机制和人类的记忆巩固是同一回事。
这些批评不影响官方数字的有效性，但它们决定了你怎么用这套框架：把它当成「管理上下文的工程方案」，而不是「让模型学会东西的机制」。前者现在就能用，后者还是开放问题。
7）能直接抄走的几条做法
官方给了建议，这里挑出可以直接落地的：
- 告诉记忆是干什么用的，但别规定死规则。越强的模型越应该自己判断什么值得记；对老模型反而要明确写「回答前先读记忆」「失败后先测假设」。
- 注入层保持索引化。Claude Code 的自动记忆只读
MEMORY.md前 200 行或 25 KB，剩下的靠链接往下找。这条几乎零成本，值得直接照抄。 - 多轮增量建 wiki，别想一次建完。每轮检查链接、补缺页。官方那个补页例子：9 个指向缺失
escrow-agreement页的链接被改指到已有页，补了 3 个页面，wiki 从 38 条/225 链接变成 41 条/278 链接。 - 并发写入必须分工。一份来源给一个 agent，精度要求高的地方逐字引用原文。上面那个 72% → 100% 的差距就是这么来的。
- 按任务类型选方案。需要跨多份文档综合 → wiki + 搜索；答案基本在单份文档里 → 纯检索更划算。
小结
这篇博客真正的贡献是把「agent 记忆」从一个模糊的卖点变成了四层有成本结构的工程问题。最该记住的三条是：注入层要小、笔记会被验证或推翻、wiki 是搜索的补充而不是替代。
最该警惕的是两个数字。第一个是 Sonnet 3.7 的 97.8 万字符换 1 个徽章——记忆的量不是成就，能把记忆压成一张地图才是。第二个是「只记失败」让 Opus 5 掉 0.234 分——不是所有「记下来」都是好事，错误的归纳会变成每次会话都要背的包袱。
最后一句留白：整套框架处理的是「会话之间保留什么」，而不是「模型本身学到什么」。官方在定义里就把权重更新排除在外了。所以真正的持续学习，到这篇为止仍然是空的。
想同时跑 Claude、GPT 几家的顶级模型订阅、在自己的 agent 里对比不同记忆方案？可以看看俱乐部的 Claude Max / ChatGPT Pro 拼车方案。
参考来源
这组数字该这么读：wiki 从 13% 爬到 48%，涨了三倍多，但仍然打不过纯搜索的 53%。加上搜索才到 61%。所以所谓「建 wiki 更好」是有前提的——它是在给搜索做补充，而不是替代。HN 上有读者从图里读出「wiki + 搜索比只吃 dreaming 更好、dreaming 只带来边际增益」，这个解读和上面的数字是一致的。
最有操作价值的一段反而很小：一个合同条款任务，起初 57 个事实只活下来 41 个（72%），原因是多个 agent 互相覆盖了同一个共享页面；改成「一份合同给一个 agent、条款逐字引用」之后，57 个全部活下来（100%）。同样的模型、同样的记忆结构，只改了并发写入的粒度，结果从 72% 到 100%。
5）官方自己承认的代价与风险
这篇博客值得读的地方在于，它没有把记忆写成纯收益。它列出的限制很具体：
- 时序矛盾：会话中写的笔记立刻可用但会打断任务；dreaming 产出的东西不打断任务，但可能太晚。这个问题没有公认解法。
- 过期：笔记写的时候可能就是错的，环境一变就失效。而一条过期的规则比没有规则更容易误导。
- 成本：持续核验所有记忆不现实，dreaming 本身要烧算力。所以「多久 dream 一次」是个真问题——官方的建议是朝「容易变化或访问频繁的信息」倾斜。
- 表示层质量：wiki 会积累错误和幻觉，也可能长大到比原始语料还大，却什么也没抽象出来（那个 203 KB 就是例子）。
- 注入风险：一条坏笔记会被注入到每一次会话；而且越长的指令文件，遵守率越低。
- 任务依赖：wiki 的收益不普适，简单的单文档任务可能不值得建。
6）HN 上最尖锐的批评：四层结构绕开了根本问题
如果只看官方博客，容易以为「把四层搭好就行了」。HN 上那条讨论里，最有分量的一类批评恰恰指向框架本身：把记忆定义成「关于未来需求的预测」，等于绕开了「模型无法持续学习」这个根本问题。换句话说，四层结构管理的是外部知识，而模型本身在每一次会话之间仍然什么都没学到。
还有几条批评值得直接放进来，因为它们是用户真实踩到的坑：
- 「模型创造有用记忆的能力很差」：有读者说自己试了很久，模型写出的记忆基本没用，做不了任何跨时间累积。这对应官方那条数据——Sonnet 4.6 几乎吃不到记忆的好处。
- 「关掉记忆是我减少 WTF per minute 的最好办法」：不止一个人说，把记忆关掉之后 agent 行为稳定多了。这呼应官方那条「注入风险」：一条坏笔记会在每次会话里重犯。
- 缺少溯源：有读者指出，多数记忆系统是改写或覆盖旧记忆，而不是保留原始来源。没有溯源，冲突就无从裁决——而这正是四层结构把「原始记录」放在地基上的理由。
- 「dreaming」这个词本身被反感：不少人认为把人类的「做梦」搬到机器上是过度拟人。这个批评偏语言学，但它指向一个真实风险——拟人化的词容易让人误以为这套机制和人类的记忆巩固是同一回事。
这些批评不影响官方数字的有效性，但它们决定了你怎么用这套框架：把它当成「管理上下文的工程方案」，而不是「让模型学会东西的机制」。前者现在就能用，后者还是开放问题。
7）能直接抄走的几条做法
官方给了建议，这里挑出可以直接落地的：
- 告诉记忆是干什么用的，但别规定死规则。越强的模型越应该自己判断什么值得记；对老模型反而要明确写「回答前先读记忆」「失败后先测假设」。
- 注入层保持索引化。Claude Code 的自动记忆只读
MEMORY.md前 200 行或 25 KB，剩下的靠链接往下找。这条几乎零成本，值得直接照抄。 - 多轮增量建 wiki，别想一次建完。每轮检查链接、补缺页。官方那个补页例子：9 个指向缺失
escrow-agreement页的链接被改指到已有页，补了 3 个页面，wiki 从 38 条/225 链接变成 41 条/278 链接。 - 并发写入必须分工。一份来源给一个 agent，精度要求高的地方逐字引用原文。上面那个 72% → 100% 的差距就是这么来的。
- 按任务类型选方案。需要跨多份文档综合 → wiki + 搜索；答案基本在单份文档里 → 纯检索更划算。
小结
这篇博客真正的贡献是把「agent 记忆」从一个模糊的卖点变成了四层有成本结构的工程问题。最该记住的三条是：注入层要小、笔记会被验证或推翻、wiki 是搜索的补充而不是替代。
最该警惕的是两个数字。第一个是 Sonnet 3.7 的 97.8 万字符换 1 个徽章——记忆的量不是成就，能把记忆压成一张地图才是。第二个是「只记失败」让 Opus 5 掉 0.234 分——不是所有「记下来」都是好事，错误的归纳会变成每次会话都要背的包袱。
最后一句留白：整套框架处理的是「会话之间保留什么」，而不是「模型本身学到什么」。官方在定义里就把权重更新排除在外了。所以真正的持续学习，到这篇为止仍然是空的。
想同时跑 Claude、GPT 几家的顶级模型订阅、在自己的 agent 里对比不同记忆方案？可以看看俱乐部的 Claude Max / ChatGPT Pro 拼车方案。
参考来源
Anthropic 本周发了一篇研究博客，题目叫「agent 记忆的组成部分」。它没有发布新模型，也没有发榜，但它给了一件更实用的东西：把「Agent 记忆」这个被说烂的词拆成了四层结构，并且用几组可以复现的基准，量化了每一层的收益和代价。
其中最反直觉的一个数字是：在 Pokémon Red 上，旧模型 Sonnet 3.7 写下了 413 个文件、约 97.8 万字符的「记忆」，最终只拿到一个徽章；新模型 Fable 5 只用了 10 个文件、4.3 万字符，拿到四个。记忆的量级差了两位数，成绩反过来。
这篇把 Anthropic 给的四层结构、几组关键数字，以及它自己写明的代价，一起摊开讲清楚。同时也要说清一件官方没有明说的事：这套框架在 HN 上最尖锐的批评，是它绕开了「模型不能持续学习」这个根本问题。
一句话结论
- Agent 记忆不是「一个数据库」，是四层不同性质的东西：可搜索的原始记录、模型写的笔记、结构化的 wiki、以及每次会话预先注入的上下文。它们的成本结构完全不同，混在一起谈必然出错。
- 注入层必须小，而且越往上越危险：一条坏笔记会被注入进每一次会话。Claude Code 的自动记忆只加载
MEMORY.md的前 200 行或 25 KB，当作索引，细节往下压。 - 「只记失败」是负收益。官方数据显示，让模型只记录失败，Opus 5 掉了 0.234 分，Opus 4.7 掉了 0.150 分。
- wiki + 搜索不是万灵药：需要跨多份文档综合的任务上，wiki 87% 对纯搜索 73%；但在大部分答案就在一份文档里的任务上，wiki 没有明显增益，而且它可能长得比原始语料还大。
1）Anthropic 的四层 agent 记忆结构
先划边界。Anthropic 对「agent 记忆」的定义是：模型从交互和任务中获得、并在会话之间保留、之后能读回来的信息。它明确不包括权重更新、上下文学习（in-context learning）和上下文压缩（compaction）。这个排除很重要——它意味着这套框架处理的是「怎么管理外部知识」，而不是「怎么让模型真的学会」。
四层从上到下是这样：
- 原始记录（transcripts）：可搜索的会话事件日志。它提供原始经验，更重要的是它提供了「事实基准」——笔记写得对不对，可以回到记录里核对。这是整座塔的地基。
- 记忆笔记（memory notes）：模型在会话中或结束后写下的观察、事实、规则、警告和计划。官方对它的定义很直白：笔记是关于「未来会话需要什么」的预测。预测就会错——写的时候可能就错，环境变了之后会过期。
- 记忆表示（memory representations）：结构化产物，典型形态是 wiki——互相链接的页面，负责总结和连接知识。它的作用是「地图」，用来在一个越来越大的记忆库里导航。模型会增量地建它：合并重复、修正页面、回头核对来源。
- 注入上下文（injected context）：每次新会话预先加载的内容。它的好处是省掉搜索，代价是吃掉 token，而且会把错误一起带进每一次会话。所以这一层必须保持小。
把这四层串起来的是一个叫 dreaming 的后台过程。它做的事包括：回顾日志、拿记录去验证笔记、创建或剪掉表示层、把选中的笔记提升到注入层、把记忆收敛到某个目标上、以及填补跨越多个会话的空缺。官方在这里点了一个很实在的矛盾：在会话中写笔记能立刻抓住当时的要点，但会打断任务；把这件事挪到后台的 dreaming，就不打断任务，但结果可能来得太晚。
2）CL-Bench：记忆把分数从 0.65 拉到 0.84
第一组数据来自 CL-Bench 1.0 的数据库任务，对比「无状态基线」和「带记忆」。数字很干净：
| 模型 | 无记忆 | 带记忆 | 提升 |
|---|---|---|---|
| Opus 5.5 | 0.655 | 0.838 | +0.183 |
| Sonnet 5.5 | 0.644 | 0.833 | +0.189 |
| Opus 5 | 0.564 | 0.828 | +0.264 |
| Opus 4.7 | 0.383 | 0.700 | +0.317 |
| Sonnet 5 | 0.306 | 0.610 | +0.304 |
| Sonnet 4.6 | 0.330 | 0.364 | +0.034 |
| Sonnet 4.6（改进记忆指令后） | 0.330 | 0.641 | +0.311 |
表面看是「记忆有用」，但真正值得看的是分布：老模型 Sonnet 4.6 几乎吃不到记忆的好处（+0.034），改进记忆指令之后才跳到 +0.311。这说明记忆系统的收益不是自动的，它取决于模型会不会用。同一个记忆库、同样的任务，换个模型可能一分拿不到。
还有一个佐证：Sonnet 5 在 10 次里有 9 次会先读记忆再回答；Sonnet 4.6 则不到一半。更弱的模型需要被明确提示「先读记忆再动手」，更强的模型自己判断哪些值得记。
3）Pokémon Red：97 万字符的记忆输给 4 万字符
第二组数据更直观，也更容易被误读。Anthropic 用解《精灵宝可梦 红》做长程任务基准，比较两代模型的「记忆产物」：
| 模型 | 记忆规模 | 文件/文件夹 | 拿到徽章 |
|---|---|---|---|
| Sonnet 3.7 | 约 977,930 字符 | 413 个文件 / 225 个文件夹 | 1 个 |
| Fable 5 | 43,406 字符 | 10 个文件 / 2 个文件夹 | 4 个 |
那句「花了 17 步创建 6 个文件、删掉 9 个，没做任何游戏动作」是全篇最值得抄下来的一句话。它是「记忆变成了任务本身」的精确样本：Agent 忙着整理记忆，忘了自己在打游戏。
同一组基准里还有一处反例，专门说明「笔记会错」这件事的实际后果：带着一条错误笔记跑的 Claude，从悬崖上摔下去三次、退回 Pewter City；把那条笔记修正之后，同一个模型第 1935 步就抵达了 Cerulean City。当然，无记忆的那一组也没抵达——所以正确的读法是：实现糟糕的记忆会让事情更坏，实现得当的记忆让事情更好。
4）wiki 的真实收益：87% 对 73%，以及一个 203 KB 的教训
第三组数据回答了一个更实际的问题：结构化 wiki 到底比搜索强多少？有两个测试值得分开看。
Harvey LAB 合并任务，24 个问题，过半需要跨多份文档，其中 9 个需要判断或算术：wiki 拿到 87%，纯搜索 73%。同一个基准里另有一个 57 条标准、基本能靠单份文档答完的任务——那里 wiki 没有明显增益。同一次实验里，有个 wiki 长到了 203 KB，是原始语料的 1.77 倍。
Stainless 语料 wiki，约 35 万个文件、4.2 亿 token，25 个问题，128 次 dreaming 会话：
| 配置 | 开始 | 结束 |
|---|---|---|
| 仅 wiki | 13% | 48% |
| 仅搜索 | 53% | 53% |
| wiki + 搜索 | 54% | 61% |
这组数字该这么读：wiki 从 13% 爬到 48%，涨了三倍多，但仍然打不过纯搜索的 53%。加上搜索才到 61%。所以所谓「建 wiki 更好」是有前提的——它是在给搜索做补充，而不是替代。HN 上有读者从图里读出「wiki + 搜索比只吃 dreaming 更好、dreaming 只带来边际增益」，这个解读和上面的数字是一致的。
最有操作价值的一段反而很小：一个合同条款任务，起初 57 个事实只活下来 41 个（72%），原因是多个 agent 互相覆盖了同一个共享页面；改成「一份合同给一个 agent、条款逐字引用」之后，57 个全部活下来（100%）。同样的模型、同样的记忆结构，只改了并发写入的粒度，结果从 72% 到 100%。
5）官方自己承认的代价与风险
这篇博客值得读的地方在于，它没有把记忆写成纯收益。它列出的限制很具体：
- 时序矛盾：会话中写的笔记立刻可用但会打断任务；dreaming 产出的东西不打断任务，但可能太晚。这个问题没有公认解法。
- 过期：笔记写的时候可能就是错的，环境一变就失效。而一条过期的规则比没有规则更容易误导。
- 成本：持续核验所有记忆不现实，dreaming 本身要烧算力。所以「多久 dream 一次」是个真问题——官方的建议是朝「容易变化或访问频繁的信息」倾斜。
- 表示层质量：wiki 会积累错误和幻觉，也可能长大到比原始语料还大，却什么也没抽象出来（那个 203 KB 就是例子）。
- 注入风险：一条坏笔记会被注入到每一次会话；而且越长的指令文件，遵守率越低。
- 任务依赖：wiki 的收益不普适，简单的单文档任务可能不值得建。
6）HN 上最尖锐的批评：四层结构绕开了根本问题
如果只看官方博客，容易以为「把四层搭好就行了」。HN 上那条讨论里，最有分量的一类批评恰恰指向框架本身：把记忆定义成「关于未来需求的预测」，等于绕开了「模型无法持续学习」这个根本问题。换句话说，四层结构管理的是外部知识，而模型本身在每一次会话之间仍然什么都没学到。
还有几条批评值得直接放进来，因为它们是用户真实踩到的坑：
- 「模型创造有用记忆的能力很差」：有读者说自己试了很久，模型写出的记忆基本没用，做不了任何跨时间累积。这对应官方那条数据——Sonnet 4.6 几乎吃不到记忆的好处。
- 「关掉记忆是我减少 WTF per minute 的最好办法」：不止一个人说，把记忆关掉之后 agent 行为稳定多了。这呼应官方那条「注入风险」：一条坏笔记会在每次会话里重犯。
- 缺少溯源：有读者指出，多数记忆系统是改写或覆盖旧记忆，而不是保留原始来源。没有溯源，冲突就无从裁决——而这正是四层结构把「原始记录」放在地基上的理由。
- 「dreaming」这个词本身被反感：不少人认为把人类的「做梦」搬到机器上是过度拟人。这个批评偏语言学，但它指向一个真实风险——拟人化的词容易让人误以为这套机制和人类的记忆巩固是同一回事。
这些批评不影响官方数字的有效性，但它们决定了你怎么用这套框架：把它当成「管理上下文的工程方案」，而不是「让模型学会东西的机制」。前者现在就能用，后者还是开放问题。
7）能直接抄走的几条做法
官方给了建议，这里挑出可以直接落地的：
- 告诉记忆是干什么用的，但别规定死规则。越强的模型越应该自己判断什么值得记；对老模型反而要明确写「回答前先读记忆」「失败后先测假设」。
- 注入层保持索引化。Claude Code 的自动记忆只读
MEMORY.md前 200 行或 25 KB，剩下的靠链接往下找。这条几乎零成本，值得直接照抄。 - 多轮增量建 wiki，别想一次建完。每轮检查链接、补缺页。官方那个补页例子：9 个指向缺失
escrow-agreement页的链接被改指到已有页，补了 3 个页面，wiki 从 38 条/225 链接变成 41 条/278 链接。 - 并发写入必须分工。一份来源给一个 agent，精度要求高的地方逐字引用原文。上面那个 72% → 100% 的差距就是这么来的。
- 按任务类型选方案。需要跨多份文档综合 → wiki + 搜索；答案基本在单份文档里 → 纯检索更划算。
小结
这篇博客真正的贡献是把「agent 记忆」从一个模糊的卖点变成了四层有成本结构的工程问题。最该记住的三条是：注入层要小、笔记会被验证或推翻、wiki 是搜索的补充而不是替代。
最该警惕的是两个数字。第一个是 Sonnet 3.7 的 97.8 万字符换 1 个徽章——记忆的量不是成就，能把记忆压成一张地图才是。第二个是「只记失败」让 Opus 5 掉 0.234 分——不是所有「记下来」都是好事，错误的归纳会变成每次会话都要背的包袱。
最后一句留白：整套框架处理的是「会话之间保留什么」，而不是「模型本身学到什么」。官方在定义里就把权重更新排除在外了。所以真正的持续学习，到这篇为止仍然是空的。
想同时跑 Claude、GPT 几家的顶级模型订阅、在自己的 agent 里对比不同记忆方案？可以看看俱乐部的 Claude Max / ChatGPT Pro 拼车方案。
