记忆基准测试：LoCoMo、LongMemEval、BEAM

最常被引用的三个 agent 记忆基准测试是 LoCoMo、LongMemEval 和 BEAM。它们测的都是"系统能否回答关于一段超长聊天记录的问题"，而且都由 LLM 裁判打分，所以厂商报出来的分数，很大程度上取决于用了哪个裁判模型、哪个回答模型、哪套检索流程。在同一套配置下，它们适合用来比较聊天记忆系统；但对编码 agent 真正关心的东西——跨工具交接、启动开销、能不能打开正确的记忆文件——几乎没有覆盖。

三个基准一览

LoCoMo

LoCoMo 用带人设的 agent 和时间事件图生成超长的双人对话。多数记忆厂商只报它的问答部分。比如 Mem0 的论文用了 10 段对话、每段平均约 200 道题，并排除了对抗类问题，理由是"没有标准答案"（arXiv:2504.19413）。连数据规模的描述都不一致：原论文说每段对话平均约 9K token，Mem0 论文则说它评测用的对话每段约 26,000 token。看到 LoCoMo 分数时，先问清楚保留了哪些题型、用的是哪版数据。

LongMemEval

LongMemEval 把 500 道精选题嵌进带时间戳的用户—助手对话历史里。题型包括单会话里用户/助手说过的事实、偏好、时间推理、知识更新、跨会话推理，还有"应当拒答"的题。作者报告：商用助手和长上下文模型在持续交互中记忆信息时，准确率下降约 30%。

BEAM

BEAM（"Beyond a Million Tokens"）把长度推得更远：128K、500K、1M、10M token 四档。论文的结论是，即使是 1M 窗口的模型，无论加不加检索，对话越长表现越差。它按十项能力分别打分，而不是给一个总分。

怎么打分，以及分数为什么会漂

开放式问题没法做字符串匹配，所以三者都靠 LLM 裁判（LLM-as-a-judge）：让一个模型读题目、参考答案和系统答案，判定对错。LongMemEval 的评测脚本用 GPT-4o 当裁判。Mem0 论文里，答案由 GPT-4o-mini 生成，再由另一个裁判模型打分。

这就产生了三个"不改记忆系统也能改分数"的旋钮：

1. 裁判模型。 严一点或松一点的裁判，对同一个输出会打出不同的分。
2. 回答模型。 同样的检索结果，交给更强的模型去回答，答对的题就更多。
3. 后处理。 在检索和回答之间加一步重排序或其他 LLM 处理，分数能明显上去。

Mem0 自己的 2026 基准综述 对此说得很坦白："这些数字没有一个是在相同的模型栈、裁判模型或检索配置下得出的。"同一篇文章列出：Zep 自称 LoCoMo 94.7%，第三方测试只有 75.1%；ByteRover 测出 Mem0 为 66.9%，对应的是 Mem0 旧版算法，而 Mem0 现在自报 92.5%。任何跨厂商排行榜都只能当阅读清单，不能当排名——包括上榜厂商自己发布的表。

Mem0 论文到底说明了什么

很多 LoCoMo 对比都出自 Mem0 论文，这张表值得完整看一遍。在 LLM 裁判指标上，Mem0 得 66.88%，图记忆变体 68.44%，领先其他被测的记忆系统——Zep 65.99%、LangMem 58.10%、OpenAI 记忆 52.90%。但全量上下文基线（直接把整段对话塞进提示词）得了 72.90%，是全表最高，论文自己也写明了这一点。

记忆换来的是成本和速度：每次查询约 1,764 token，对比全量上下文的 26,031；p95 延迟 1.44 秒，对比 17.12 秒。这才是聊天记忆的真实取舍——准确率略低，换来少一个数量级的上下文。读任何记忆基准时都应该带着这个框架。

Letta 的纯文件方案：74.0%

2025 年 8 月，Letta 在完全不用记忆服务的情况下跑了 LoCoMo。对话被放进一个文件，挂给一个跑 GPT-4o mini 的 agent，它只能用 grep、search_files、open、close 和 answer_question 这几个工具，并通过工具规则强制"先搜再答"。结果是 74.0%，高于 Letta 引用的 Mem0 最佳图变体 68.5%。

Letta 的结论才是重点："agent 记忆的质量，往往更取决于底层 agent 系统管理上下文和调用工具的能力，而不是记忆工具本身。"这个数字同样只是一次实验、一个模型、一套裁判配置，但它说明：纯文件加一个会搜索的 agent，是一个有竞争力的基线，而不是玩具。

这些基准没测什么

LoCoMo、LongMemEval、BEAM 测的是聊天记忆：系统能不能想起某人说过什么、什么时候说的、后来有没有变。编码 agent 的记忆问题不一样：它主要承载规则、项目状态和过往决定；要跨工具、跨机器工作；而且很大一部分成本在启动时就付出了，那时还没有人提问。三个基准里都没有"Claude Code 里定下的规则，在另一台笔记本的 Codex 里被遵守了吗"这一项。

编码 agent 该看的指标

如果你在为编码 agent 挑记忆方案，建议在自己的环境里测这些：

作为参考，nestwork 的 scripts/maintenance/measure-context.py 在作者自己的 nest 上（10 台机器、30 多个 agent 实例，用 o200k_base 计 token）给出了前三项：2.x 式全量启动读 37 个文件，约 69,600 token；3.x 协议的常驻启动约 640 token；一次读取常驻层、主题索引和一个主题文件的 git 任务约 3,600 token；整个 nest 共 180 个记忆文件，约 369,000 token。这是一个人的实测，不是基准。nestwork 没有公布路由准确率数据；如果你启用了主题记忆，这正是你该自己追踪的指标。

常见问题

哪个 agent 记忆基准最可靠？

单独看哪个都不可靠，因为裁判和回答模型对结果影响最大。LongMemEval 的评测流程最固定（公开脚本，GPT-4o 当裁判）；BEAM 测的上下文最长，而且分十项能力报告。最可靠的对比，是你自己把所有系统放在同一套模型栈上跑一遍。

为什么在 LoCoMo 上全量上下文反而赢过记忆系统？

在 Mem0 论文的设置里，LoCoMo 一段对话约 26,000 token，现代上下文窗口装得下。全部装得下时，就不存在检索丢失。记忆系统赢在 token 和延迟上；等历史再也装不下时它才成为必需——这正是 BEAM 的 1M 和 10M 档在测的。

Letta 的 74.0% 说明文件比向量记忆好吗？

它说明：一个能干的 agent 搜纯文件，在一个基准、一个模型上表现有竞争力。它不能证明文件处处都赢，但确实说明检索工具和 agent 行为至少和存储引擎一样重要。

有没有针对编码 agent 记忆的基准？

我们没能核实到被广泛采用的。在那之前，就在自己的仓库和工具上测交接、启动开销、任务期加载和路由准确率。

相关阅读

• AI agent 记忆：四种类型与取舍
• agent 记忆工具对比
• 主题记忆与按需加载
• 长期记忆的实践