Anthropic是如何设计Agent记忆的，对我们有何启发

前不久，Anthropic 的工程团队在 11 月 6 日发了一篇文章《The components of agent memory》。里面有一个非常有意思的观察：很多被精心设计过的知识wiki或者Agent Memory准确率有时候还不如直接搜索原始文档高。但换个场景，过多的原始信息塞给模型，有时候也同样会让检索的准确率暴跌。

比如，在需要跨多份文档综合的并购问答里，整理过的 wiki 更强：用 wiki 得分 87%，纯搜索只有 73%。

但在另一个法律任务里，答案基本都在单个文档中、一搜就能找到，wiki 没有任何明显收益。

还有一项法律任务中，整理出来的 Wiki 甚至比原始文档还大，说明整理本身未必能有效压缩信息。

再换个场景到企业知识库，实验里结论则彻底反过来：只用 wiki 最高只有 48%，直接搜索反而有 53%。不过两者结合能到 61%，每题还省约 2 万 token。

那么问题来了：既然全量记录和重度概括都有不足，Agent 到底该怎么记、写错了怎么改，又该如何跟原始文本检索配合？

01 全量记录和重度摘要，为什么会拉低表现？

先看在线记录过多的问题。研究者让 Claude 玩《宝可梦 红》，并提供一个可自由读写的记忆目录。跑到约 10,000 步时，Claude Sonnet 3.7 和 Claude Fable 5 的表现差异如下：

Sonnet 3.7 保存了大量不断变化的游戏状态，但之前写下的信息很快就可能过期。随着文件不断累积，它花在查找和维护记忆上的精力也越来越多。到了第 10,000 步附近，它开始建立第四个“主记忆”文件夹，接下来的 17 步中又新建了 6 个文件、删除了 9 个文件，却没有执行任何游戏操作——记录和整理记忆本身，也可能挤占完成任务的时间。

再看离线整理文档的情况。Anthropic 使用今年 5 月收购的软件公司 Stainless 的内部语料——约 35 万份文件、4.2 亿 token——让 Claude Opus 5 通过多轮离线会话，逐步构建、修订带有交叉链接的 Wiki。

在 25 道评测题上，随着整理会话从 2 次增加到 128 次，仅依靠 Wiki 回答问题的评分从 13% 提高到 48%，但仍低于直接搜索原始文档的 53%——整理改善了 Wiki 的可用性，却没有让它完全替代原文检索。

在模拟法律与企业并购的 Harvey LAB 基准测试中，研究者进一步观察到了几种不同结果：

跨文档综合时，Wiki 有优势。在一组并购问答中，对于需要综合多份文件、进行判断或计算的问题，使用 Wiki 得分为 87%，直接搜索为 73%。

单文档检索时，Wiki 未必带来收益。在一项法律文书任务中，多数评分要求涉及的信息可以直接从单份文档检索到，提前生成 Wiki 没有显示出明显的表现收益。

整理可能造成体积膨胀。另一项法律任务中，10 份原始文档被整理成 68 个 Wiki 页面，文本体积达到原文的 1.77 倍，未能实现有效压缩。

概括和并发写入可能丢失关键事实。在一项考核 57 项合同事实的收购简报任务中，多个 Agent 同时向共享表格写入条款摘要，出现了概括不佳、条款遗漏和互相覆盖的问题。最终生成的简报只覆盖了 41 项评分事实，即 72%。后来改成每份合同单独建页、由单个 Agent 写入，并逐字保留关键条款，评分标准覆盖率提高到了 100%。

02 什么内容才值得写进记忆？

从这些案例中，我们不难提炼出一个原则：优先保存后续可能反复需要、重新获取或推导成本较高的信息；对随时可读取、又不断变化的状态，减少重复记录。

比如，在《宝可梦》中，玩家当前有多少钱、站在哪里，可以从当前游戏画面读取，重复写入文件容易产生冗余和过期信息。相比之下，当前目标、路线计划，以及模型从经历中总结出的策略，如果没有保存，就可能在新会话中丢失。

因此，Fable 5 会按照这样的思路组织记忆：顶层 global.md 保存当前目标、道馆计划和记忆使用规则，locations 目录保存路线计划，gameplay 目录保存游戏策略。

例如，连续扔出 7 个精灵球仍未抓到鲤鱼王后，Claude 尝试改变菜单操作之间的按键时序，随后捕获成功，并记下“连续失败时可以尝试改变时序”的经验。这是模型从一次经历中总结出的策略。Opus 5.5 也采用了维护小型记忆目录、持续更新目标和下一步计划的方式，最终通关游戏。

此外，能否把经历转化成可靠规则，还与模型验证猜想的能力有关。

在 CL-Bench 1.0 的数据库问答任务中，每道题都在新会话中启动。模型答题后会得到正确答案，并可以写入记忆，供后续题目使用：

这里的数值是该任务的平均奖励得分，不是通常意义上的准确率。

提示词的作用也因模型而异。对 Sonnet 4.6，明确提醒它答题前读取记忆、主动验证猜想后，得分提高到了 0.641。而对于 Opus 4.7 和 Opus 5，仅仅告诉它们“有一个记忆文件夹可用”，就足以带来明显收益。

研究者还测试了更具体的写入限制。如果规定“只记录失败”，Opus 4.7 和 Opus 5 从记忆中获得的收益反而明显减少。

因此，对尚不能稳定使用记忆、验证猜想的模型，明确引导可能有效；对已经具备较强判断能力的模型，简单说明记忆用途、保留选择空间，可能比预设狭窄的写入规则更合适。

03 

记忆写错了或者太碎，怎么修正和检索？

模型在会话中写下的记忆，也可能从一开始就是错的。如果后续会话继续相信它，错误就可能反复影响决策。

在《宝可梦》的月见山路段，Claude 就栽在了自己写的错误笔记上：

写错地标方位：月见山入口在西侧、出口在东侧，入口旁有宝可梦中心和单向跳台。Claude 误把入口处的宝可梦中心记在了东侧，走出大门就以为自己已经穿过了山洞，把笔记改成了 Mt Moon DONE。

陷入死循环：往前走几步掉下单向跳台回到原路后，因为导航工具不显示掉落动作，它依然坚信记忆没错，判断自己是往西走过了头。整局测试里它连续 3 次掉下同一个跳台，第 3 次后写下准备停止以免继续死循环，退回前一个城镇直到结束也没能过山。

离线核对原始日志修复：Anthropic 在会话空闲期引入了名为 Dreaming 的离线整理机制，让模型拿记忆笔记去和底层的原始会话日志（Session Transcripts）逐条对账。由于原始日志记录了真实的每一步操作，模型核对后发现了方位错误并重写了笔记，下一局在第 1,935 步顺利穿过月见山。

这也引出了 Anthropic 最终给出的四层记忆使用方法：

顶层强制预加载控制在 200 行以内：每次会话开头直接注入上下文的记忆（如 Claude Code 的 MEMORY.md）被严格限制在前200 行或 25 KB。因为注入内容每回合都在消耗 Token，且指令过长会降低模型遵循度，这一层只放目录索引，告诉模型知道什么、去哪个文件找。

中间层表征（Wiki/笔记）必须与底层原文搜索联合使用：回到前面 35 万份文件（4.2 亿 Token）的测试，单独用 Wiki 准确率为 48%，单独搜原文为 53%；而把Wiki 与原文搜索结合使用，准确率升至61%，同时每道题平均节省约 20,000 Token。

Wiki 的作用是提供跨文档的导航线索，帮模型省去在 35 万份文件里盲目翻找的轮次；而一旦定位到具体文档，仍需回到原始文本去拿准确细节。

04 

落地这套记忆架构， Milvus 3.0有何价值？

在生产实践中，摘要也就是Agent Memory通常需要与原文配合使用，并保留两者之间的明确关联。摘要用于概括一段记忆，原文则保留具体事实和细节；两者同时被检索，这样，即使某个细节没有进入摘要，Agent 仍有机会直接从原文中找到它，并回查对应的完整记录。

除此之外，Agent Memory在内的很多检索场景还有一个矛盾：检索的匹配粒度是文本片段，但供给大模型推理的上下文单元，有时候必须是具备完整语义边界的原始记录。

比如，当用户询问某一类故障的处置方案时，检索会命中历史工单里的子片段，例如 “将超时时间调整为 60 秒”。但仅靠这一句孤立文本，Agent 无法判断该方案是否适用于当前问题，方案的适用前提、约束条件、后续回滚要求都承载在对话中的整条工单记录中。

此外，如果我们把每一个子片段都独立作为一条向量实体入库，还会引发召回分布倾斜：Top20 结果里，大量命中片段都来自同一份历史工单。看似召回了很多候选，实际覆盖的独立案例非常有限。上层应用需要额外实现分组、去重、扩召回等后处理逻辑，才能拿到足够多元的历史参考。

Milvus 3.0中的 StructArray 就是用来解决这类矛盾的。我们可以将一份完整的问题处置记录作为顶层 Entity，在实体内部嵌套存储拆分后的子片段、对应向量、片段序位等属性。结合 MAX_SIM 这类实体级检索算子，实体内部全部子向量均可参与相似度打分，但检索排序与返回的对象，始终是完整顶层实体。

这种模式下，同一份记录内的多个相关子片段会共同贡献实体相似度，不会各自占用独立的召回席位；上层拿到实体后，可按需读取实体内部全部原文，组装成完整上下文交付给 Agent。

作者介绍

Zilliz黄金写手：尹珉

文章来自于"Zilliz"，作者 "尹珉"。