Skip to content
Published on

AI 智能体的记忆实际上是怎么做出来的 — 四种设计，以及基准测试实际证明了什么

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
分享
Authors

引言 — 「记忆」不是一种东西

「给 AI 智能体加上了记忆」这句话，几乎不传递任何信息。因为这个词可能指的设计至少有四种，彼此的成本和失败方式都不一样。把备忘写进文件、对话变长后用摘要替换并丢掉前半部分、抽出事实做成嵌入每次提问再取出来、把实体和关系堆成图谱 — 这四样全都被叫作「记忆」，但并不是同一种东西。这个词已经过载到了这种程度：2026 年 1 月发布的一篇综述(arXiv:2602.06052)写道，仅今年一年，关于记忆的论文就出了数百篇。

所以本文要先回答的问题是这个 — 每种设计实际在做什么，以及「哪种更好」的证据是否真的被测量过。先把结论摆出来。每种设计做什么，产品文档里写得清清楚楚。相反，「哪一边更准确」的公开证据，比想象中弱得多。直接去读被引用最多的那篇比较论文的表格，会发现表里的第一名不是任何记忆系统，而是「把整段对话原样全部贴进提示词」的方式。而只要亲手打开那个基准测试数一数 token，为什么会这样也就说得通了。本文就把这个过程一步一步核实下来。

本文不会重复上下文工程那一篇讲过的设计模式。这里要做的是证据审计(audit) — 哪个数字是由谁、在什么条件下、和什么相比测出来的。

四种设计各自在做什么

先把术语固定下来。下面四种并不互斥，实际产品通常是混着用的。

1. 草稿板(scratchpad) / 文件记忆。智能体把备忘写进文件，之后再读。Anthropic 的 memory tool 正是这个形状 — 按官方文档的说法，它在 /memories 目录下创建、读取、修改、删除文件。重要的是，这完全是客户端侧的。用文档的表述，Claude 只是请求文件操作，执行则由你的应用程序对着你的存储来做。文档把这个模式称为 just-in-time 的上下文召回 — 不是预先全部装载，而是把学到的东西记下来，需要时再读。

2. 摘要 / compaction。对话变长后，把前半部分换成一段摘要。Anthropic 的服务器端 compaction 就是这个。按文档的说法，当输入 token 触及设定的阈值时，API 会把对话总结成一个 compaction 块，并在之后的请求里自动丢弃该块之前的所有内容块。beta 标头是 compact-2026-01-12，策略名是 compact_20260112。文档给出的理由很有意思 — 不单是为了不超上限，而是因为「对话变长后响应质量会下降」，所以要把活跃上下文保持在小的状态。

3. 向量召回。从对话里抽出事实做成嵌入，每次提问时把相似的取出来。Mem0 的基础配置就属于这一系。它在技术上和生产环境 RAG 模式里的检索流水线是同一种东西，区别只在对象不是文档而是对话。

4. 知识图谱。把实体和关系堆成图谱。Zep 的 Graphiti 是代表，它把时间信息挂在边上，处理「从什么时候到什么时候为真」。图谱怎么抽取、把什么当作实体，本身就是个大话题，动手构建知识图谱和把领域知识建模为本体两篇里另行讲过。查询语料库那一侧的故事，在 Graph RAG 一篇里。

研究侧的谱系值得点一笔：常被引用为这个领域出发点的 MemGPT(arXiv:2310.08560，2023 年 10 月)，从操作系统的分层内存借来点子，提出了「虚拟上下文管理」。想法是在快内存和慢内存之间搬运数据，让系统看起来拥有一块大内存。如今产品里的文件记忆和 compaction，就在这条谱系之上。

已上市的产品和研究论文在哪儿分岔

第一个重要的区分在这里出现。

已上市的产品实际主推的是第 1 种和第 2 种。这可能出乎意料。看 Anthropic 的文档，context editing 页面是这么引导的 — 对大多数用例来说，服务器端 compaction 是长对话的主要策略，context editing 的细粒度策略群，则是留给需要更精细控制删除内容的特定场景。compaction 的文档也说同样的话：它是长时间运行的对话和智能体工作流所推荐的策略。

也就是说，商用平台默认推荐的「记忆」既不是向量也不是图谱，而是摘要后丢弃 + 写进文件。最简单的两种。

研究界和创业公司竞争的是第 3 种和第 4 种。Mem0、Zep、LangMem、A-Mem 这些系统都在这里，争论也全部发生在这里。那么，说这一边更好的证据到底有多扎实呢。

哪种设计更准确 — 直接读被引用最多的那张表

关于这个问题，被引用得最广的证据是 Mem0 论文(Chhikara 等，arXiv:2504.19413，2025 年 4 月 28 日提交，ECAI 2025)。摘要的头条是这样的 — 在 LLM-as-a-Judge 指标上相对 OpenAI 有 26% 的相对提升，使用图记忆比基础配置的分数再高约 2%，以及相对全上下文低 91% 的 p95 延迟和 90% 以上的 token 成本节省。

然而把论文正文的 Table 2 原样搬过来，是下面这样。全部是作者自测，以 LoCoMo 基准测试为准，J 是 LLM-as-a-Judge 分数。

方式记忆 token检索 p95总 p95J 分数
全上下文 (整段对话原样投入)26,031—17.117s72.90% ± 0.19
Mem0 图—0.476s (p50)2.590s68.44%
Mem0 (基础)1,7640.200s1.440s66.88%
Zep3,9110.778s2.926s65.99% ± 0.16
LangMem12759.82s60.40s58.10% ± 0.21
OpenAI4,437—0.889s52.90% ± 0.14
A-Mem2,5201.485s4.374s48.38% ± 0.15

头条数字在算术上是对的。我亲手验算过 — 66.88 除以 52.90 等于 1.264，所以相对 OpenAI 26% 的相对提升没错。1 减去(1.440 除以 17.117)等于 91.6%，所以相对全上下文低 91% 的 p95 也没错。68.44 减 66.88 是 1.56 个百分点，所以「高约 2%」也没错。没有任何数字被捏造。

问题出在同一张表的最上面一行。全上下文以 72.90% 排在第一。把整段对话原样贴进提示词、甚至都称不上记忆系统的方式，赢过了所有记忆系统。论文也没有隐瞒这一点 — 正文写着，把约 26,000 token 整个放进去的全上下文依然拿到最高的 J 分数(约 73%)，并明确写道 Mem0 图「只输给计算上难以承受的全上下文」。

所以准确地说是这样：26% 这个头条，是以 OpenAI 的 52.90% 为基准量出来的。那是表里最弱的比较对象。表里最强的基线没有被任何一个记忆系统打败，而摘要对这个事实只字未提。没有谎言，但取景是挑过的。这篇论文真正在卖的价值不是准确率，而是成本 — 用 1,764 token 做到 26,031 token 方式 92% 水平的准确率。这确实是有用的结果，说句实在话，结论本该是它。

再多看一眼这张表，还有别的东西扎眼。LangMem 的记忆是 127 token，检索 p95 却是 59.82 秒。60 秒的检索在任何生产环境里都不是正常配置。这是一个信号，说明把别人的系统跑在最优配置上有多难 — 而这个信号正好引出下一段故事。

全上下文为什么赢了 — 我直接打开了基准测试

要知道全上下文为什么赢，得先看 LoCoMo 是什么。

LoCoMo 本来是会话记忆基准测试(Maharana 等，arXiv:2402.17753，2024 年 2 月 27 日)。论文 Table 1 记述的数据集是这样的 — 50 个对话，每个对话平均 304.9 轮、平均 19.3 个会话、平均 9,209.2 token。问题分成五个类别：single-hop、multi-hop、temporal、commonsense/world knowledge，以及 adversarial。

然而 Mem0 论文写的是，全上下文放入了 26,031 token。9,209 和 26,031 差了接近三倍。为了确认哪边是对的，我直接下载了公开数据集来数。

公开仓库(snap-research/locomo)里实际放着的文件是 locomo10.json。顾名思义，10 个对话 — 不是论文记述的 50 个。用 tiktoken 的 cl100k_base 只统计对话正文(发言文本与图像描述)的结果如下。

locomo10.json  (直接测量，tiktoken cl100k_base，发言文本 + BLIP 图像描述)
  对话数:          10           (论文 Table 1 记述的是 50 个)
  每对话 token:    最小 12,218 / 最大 23,406 / 平均 20,034 / 中位数 21,387
                               (论文 Table 1 是平均 9,209.2)
  每对话会话数:    平均 27.2 (最小 19，最大 32)   (论文是平均 19.3)
  每对话轮数:      平均 588.2                     (论文是平均 304.9)

  问题总数:        1,986
    类别1 single-hop      282
    类别2 multi-hop       321
    类别3 temporal         96
    类别4 open-domain     841
    类别5 adversarial     446   <- 446 个中 444 个没有 `answer` 字段
                                   (只有 `adversarial_answer` 字段)

也就是说，所有人都拿来跑基准的这份公开文件，长度大约是论文所记述数据集的两倍。我的测量值 20,034 token 与 Zep 主张的「16,000~26,000 token」区间一致，与 Mem0 的 26,031 token 方向上也对得上(Mem0 那边很可能把时间戳、观察字段之类的脚手架也算了进去)。与论文摘要的「平均 9K token」对不上。

这就是全上下文获胜的原因。一段对话 2 万 token，塞进如今模型的上下文窗口毫无压力。这不是一场对长期记忆施压的考试，而是一场全部塞进去就行的考试。Zep 在自家博客里指出的那句话很准确 — 如果全部塞进去比专门的记忆系统效果更好，那说明这个基准测试并没有在测量真实智能体所承受的记忆压力。

类别 5 也值得注意。446 个问题里有 444 个压根没有 answer 字段(里面放的是 adversarial_answer)。因此 Mem0 和 Zep 都把这个类别排除在了评估之外。这意味着全部问题的 22.5% 实际上处于不可用状态，而这次排除，正是下一章那场事故的起因。

厂商之间数字对不上会怎样 — Mem0 对 Zep 的记录

最能展示这个领域里「被测量的」与「被主张的」之间鸿沟的事件，以公开形式留在了 2025 年 5 月。按时间顺序整理如下。

2025 年 4 月 28 日。Mem0 论文上线，把 Zep 报告为 65.99%，并主张 SOTA。

2025 年 5 月 6 日。Zep 发博客反驳(Daniel Chalef、Preston Rasmussen)。要点是：Mem0 把 Zep 实现错了，然后拿着错误的实现去测量。具体列了三条 — 给对话的两个参与者都赋了 user 角色，弄得单一用户的身份仿佛每条消息都在换人；时间戳没有写进 Zep 的 created_at 字段，而是被拼接在消息正文里；检索不是并行而是串行地跑，把延迟灌大了。在此基础上，Zep 主张正确实现的话自己是 84%。

2025 年 5 月 9 日。Mem0 的 CTO Deshraj 在 Zep 的仓库开了 issue(getzep/zep-papers 第 5 号 issue)。反驳的核心是算术 — Zep 的 84%，是把大家都同意排除的类别 5 的正确答案计入分子、却从分母中剔除的算法。把这一点纠正过来，就不是 84%，而是 58.44%。也就是主张有约 25.56 个百分点被灌了水。

2025 年 5 月 12 日。Zep 的 Chalef 承认了计算错误。不过修正后的值不是 58.44%，而是 75.14% ± 0.17(10 次运行的平均)。而其余的批评 — 即 Mem0 的实验设定和选用 LoCoMo 这件事本身就有问题的主张 — 并没有撤回。Zep 也在博客上挂出了更正启事，那段文字至今还留着。

2025 年 5 月 19 日。issue 以「不活跃」为由被关闭。

这里重要的是一个事实：两个阵营的数字从头到尾就没有一致过。Mem0 说 Zep 是 58.44%，Zep 更正之后仍说是 75.14%。同一个基准测试，同一个系统，差 17 个百分点。哪边是对的，本文不做判定 — 因为能用来判定的证据没有公开。

算术上是否自洽，倒是可以核对。按我数出来的，类别 1~4 共 1,540 题，类别 5 是 446 题。把类别 5 的正确答案计入分子、分母保持 1,540 不动，要灌出 25.56 个百分点，需要类别 5 里约 394 题(446 题的 88%)被判为正确。Mem0 所主张的机制和规模之间并不矛盾。不过这只是对主张内部自洽性的核对，不是对哪边分数正确的证明。

从业者要从这件事带走的教训，不是「谁是坏人」。而是把竞品跑在最优配置上去测量，就算出于善意也非常困难，所以厂商就他人产品报告的数字，默认就是弱证据。前面看到的 LangMem 的 60 秒检索也是同一类信号。Zep 的 65.99% 也好，Zep 亲手测出的 75.14% 也好，各自都挂着各自的利害关系。

更难的基准测试上情况如何 — LongMemEval

如果嫌 LoCoMo 太容易，还有更难的：LongMemEval(Wu 等，arXiv:2410.10813，2024 年 10 月 v1，2025 年 3 月 v2，ICLR 2025)。

设计明显更有攻击性。共 500 个问题，标准设定有两个 — LongMemEval_S 每题约 115k token，LongMemEval_M 是 500 个会话、约 150 万 token。和 LoCoMo 的 2 万 token 差着数量级。而且它明确考察 LoCoMo 没有的能力：信息抽取、多会话推理、时间推理、知识更新(事实发生变化的情形)，以及弃权(不知道就说不知道)。

论文报告的结果是这样。摘要写的是「商用聊天助手和长上下文 LLM 表现出 30% 的准确率下降」，但正文写得更精确，是 30%~60% 的性能下降。而关于商用系统的那句话，带着一个必须原样保留的限定 — 在人工评估中，最新的商用系统只拿到 30%~70% 的准确率，但那是在比 LongMemEval_S 简单得多的设定下得到的。也就是说，那不是商用系统在真实难度下的分数。

Zep 在自己的论文(arXiv:2501.13956，2025 年 1 月)里表明偏好 LongMemEval，并报告最多 18.5% 的准确率改进和 90% 的延迟降低。前面挂着「最多(up to)」的限定语，而且是作者自测。同一篇论文还在 DMR 基准上报告了相对 MemGPT 的 94.8% 对 93.4%，拿 1.4 个百分点的差距来讲 SOTA，这本身就单薄。

这里有必须诚实说出来的一点。在 LongMemEval 上把 Mem0、Zep、文件记忆、compaction 放在同一条件下并排跑的独立第三方比较，在我确认过的范围内，并没有公开存在。有的只是各家厂商在自己的流水线上、用自己的提示词量出来的数字。没有共同的基准，厂商 A 的自测和厂商 B 的自测就无法摆在一起比较 — 这就是本文不做那种表格的原因。

Anthropic 的 39% 测的是什么

商用侧的数字也得用同一把尺子来量才算公平。

Anthropic 在 2025 年 9 月 29 日发布 context editing 和 memory tool 时公开的数值是这样的 — memory tool 与 context editing 一起用，相对基线有 39% 的性能提升，context editing 单独使用则是 29% 的提升。并且在 100 轮网页搜索评估中，把一个如果没有 context editing 就会因上下文耗尽而失败的工作流跑完了全程，同时把 token 消耗减少了 84%。

挂在这些数字上的条件，原样搬过来是这样。第一，基准是面向智能体搜索的内部评估集(internal evaluation set)。厂商自测，外部无法复现。第二，基线的绝对分数没有公开。39% 的提升是从 40 分到 55.6 分，还是从 70 分到 97 分，无从得知。第三，三个数字各测各的 — 39% 和 29% 是准确率一系，84% 是 token 消耗。

还有一条，是随时间推移产生的错位。那个 39%，是 2025 年 9 月对 context editing + memory tool 组合测出的数字。而现在 Anthropic 文档推荐作为长对话主要策略的，是服务器端 compaction — 一个 beta 标头为 compact-2026-01-12 的后来才有的功能。也就是说，被广泛引用的 39% 并不是对当前推荐默认值的测量。这不是说 Anthropic 做错了什么，而是说数字老去的速度赶不上产品移动的速度。引用厂商数值时，应当把它测的是哪个时点的哪个配置一并写上。

没被测量的东西 — 失败方式

有一些失败不会出现在准确率表格里。这一侧大体上不以基准测试的形式存在，而只以文档警告文的形式存在。

记忆污染与提示词注入。如果智能体把读到的内容写进记忆，之后又信任地读回那份记忆，那么一次被污染的输入就会跨越会话持续存在。Anthropic 文档对 memory tool 明确警告了路径遍历攻击 — 像 /memories/../../secrets.env 这样的路径可能触及记忆目录之外的文件，所以必须校验所有命令的所有路径。执行主体是你的应用程序，所以防御也是你的活儿。

敏感信息写入。原样搬运同一份文档的表述：Claude 大体上(usually)会拒绝把敏感信息写进记忆文件。想要更强的保证，文档的建议是自己加一道校验，让 handler 在写入文件之前把敏感数据筛掉。不能把「大体上」这个限定语升格成「不会」来读。

知识更新。用户换了工作，旧公司的信息就成了错的。LoCoMo 里压根没有考察这一点的问题(这一点是 Zep 指出的，与我核对类别分布的结果一致)。LongMemEval 把知识更新明确列为五项能力之一 — 所以它是更好的考试。

无限增长与过期。Anthropic 文档建议给文件大小设上限，并定期删除长期未被访问的记忆文件。也就是说，你需要一套关于「忘掉什么」的策略，而把这部分自动解好的公开证据，目前没有。

关于这些失败，公开的定量比较实际上不存在。所以选记忆系统时只看准确率表格，看的可能是错误的轴。

那么该用什么 — 决策规则

把证据的现状纳入考量，决策规则如下。我不会用「视情况而定」来收尾。

1. 对话或任务装得进上下文窗口，就不要接记忆系统。直接全部放进去。Mem0 论文自己的表格支持这个结论 — 在 2 万 token 的 LoCoMo 上，全上下文以 72.90% 赢过了所有记忆系统。这是基准测试的弱点，但同时，如果你的情形和那个基准相似，这就是可以原样套用的结论。

2. 装不进去，就先从 compaction 和文件开始。商用平台把这两样作为默认推荐，这个事实本身就是信号。服务器端 compaction 不需要客户端摘要代码就能工作，文件记忆则由你掌控存储。两者的实现面都小，失败时可以调试(文件打开看看就行)。向量和图谱，是在这里确认到失败之后才拿出来的工具。

3. 跨会话的事实召回被确认为真实的失败点时，再上向量。这里卖的不是准确率，是成本。诚实地读 Mem0 的表，这个系统的价值在于用 1,764 token 做到 26,031 token 方式约 92% 的准确率。如果这正是你需要的权衡，它就是好选择；不是，就不是。

4. 需要处理随时间变化的关系时，再上图谱。「从什么时候到什么时候为真」「这个人现在属于哪个团队」这类问题。不过 Graph RAG 一篇里整理过的索引成本和更新负担，会原样跟过来。

5. 无论选什么，都用你自己的查询来评估。这不是套话，而是从本文核实过的事实里直接得出的结论。公开基准之一的论文与公开文件的统计对不上；在它之上，两家厂商为 17 个百分点争执而未能达成一致；商用数值则是无法复现的内部评估。在这种状态下，相信别人的排行榜来选架构，是没有依据的选择。一套 20~50 题的自建评估集，比本文出现的所有数字对你都更有用。

什么时候不该用

这是需要诚实写下的部分。

  • 对话很短。大多数聊天机器人会话只有几千 token。没有理由接记忆基础设施。
  • 错误的记忆比正确的记忆更贵。医疗、法律、金融这类错误个性化会造成损失的领域，不记忆反而更安全。如前所见，关于污染和更新失败并没有定量证据。
  • 处理的是受监管的数据。记忆按定义会让个人数据持续存在。如果还没有设计好删除请求权和保留策略，就不要接。
  • 还没有确认到失败。因为「以后大概用得上」而接记忆，是本文所见证据不支持的选择。

结语

归纳起来是这样。「智能体记忆」是把至少四种设计笼统打包的说法，每一种做什么，产品文档里写得明明白白 — 文件草稿板、compaction、向量召回、知识图谱。商用平台默认推荐的是前两种，也是最简单的两种。

相反，「哪种更准确」的公开证据是弱的。被引用最多的那张比较表里，第一名不是记忆系统而是全上下文(72.90% 对 68.44%)，而亲手打开那个基准一看，一段对话平均 2 万 token，本来就是一场压不到长期记忆的考试。在这之上，两家厂商互相反驳对方的测量，一方承认了计算错误，两个数字却始终没有会合。更难的基准测试是存在的，但其上的独立第三方比较没有公开。

这不是说这个领域是假的。管理上下文的问题真实存在，compaction 和文件记忆也实际出货并在运转。只是，「接上记忆就会变好」这句话，目前还没有挂上支持它的公开测量。所以请从你的失败出发，而不是从排行榜出发。先确认什么不行，从最简单的开始接，用你自己的查询来测。先有失败，才有工具。

参考资料

Discuss on Twitter • View on GitHub