MemoryData：把记忆方法放进统一评测流水线

调研对象：MemoryData 代码仓库，以及配套论文《Are We Ready For An Agent-Native Memory System?》（arXiv:2606.24775v1，2026-06）。 材料来源：配套论文全文、仓库 README、4 类数据加载器、统一执行入口、指标实现与代表性 YAML 配置（索引见附录）。 贯穿全文的样例：config/hybrid_simplemem.yaml 与 benchmark/locomo/config/Locomo_qa_4cat_600_dist.yaml 这对配置。它代表“用 SimpleMem 方法做 LoCoMo 长对话评测”的一次实验定义；本文只解析其配置与执行路径，没有把它误写成已经跑出的实验结果。

摘要

MemoryData 的价值不在于提出一种新的记忆算法，而在于把记忆增强 Agent 的比较组织到同一条实验流水线中：4 类基准族、22 个方法预设和一个 main.py 入口。Agent YAML 定义记忆方法、底座模型、检索与写入参数，Dataset YAML 定义数据、切片、上下文和题目数量；运行器负责写入记忆、提问、评分、保存与续跑。

这套统一解决的是实验编排和产物留痕，不是线上记忆服务，也不会自动产生一个可信的“总冠军”。论文的核心判断是，没有一种记忆架构能在所有工作负载上稳定获胜。证据分散、事实更新、会话变长、噪声增加和成本约束，会暴露不同的短板；选型应从业务的失败代价出发，再决定怎样表示、抽取、检索和维护记忆。

使用现成配置前，需要先处理三类可比性问题：

• 默认配置并不自动公平：现成预设使用的模型、endpoint、检索和上下文参数并不完全一致；直接横比默认分数，测到的可能是整套预设组合，而非单独的记忆机制。

• 统一入口不等于统一总分：EM、F1、Recall@K、格式准确率和写入/查询成本衡量不同能力，不能随意平均成一个“记忆分”。

• 材料不等于复现实验：仓库不附带原始数据，调研环境也没有可用模型服务。本文可以核对论文与代码，但不会把论文图表或构造样例写成已完成的本地实验。

MemoryAgentBench、LoCoMo、LongBench 和 MemBench 在这里仍是语义与指标不同的基准，MemoryData 只是让多种方法能在这些基准上以相近的运行方式留下可审计产物。它适合多方法复现和选型；如果需要线上记忆 SDK、无需解释的总排名，或没有条件准备数据和模型服务，它并不能直接解决问题。

---

1. 它到底是什么：解决的不是“记忆算法”，而是比较问题

核心判断。 MemoryData 要解决的是“比较无法对齐”，而不是“大家还缺一种记忆算法”。带记忆的 Agent 一边依赖底座 LLM，一边依赖“记什么、怎么压缩、怎么查、旧信息怎样更新”的机制。不同方案都能回答历史问题，但强项未必来自同一个地方：有的保留原始证据，有的组织结构化关系，有的优先追求低成本检索或旧事实更新。

难点不只在“做出一个方法”，还在“怎么判断两个方法谁更适合”。若 A 在长对话题上使用 128K 上下文和 GPT-4o-mini，B 使用 32K 上下文和本地 7B 模型，即使 A 分数更高，也不能直接归因于 A 的记忆设计。过去很多比较正是被数据版本、模型、输入格式和指标差异切碎的。

MemoryData 用两份 YAML 把一次实验明确定义出来：一份选考生，一份选试卷；main.py 负责加载、写入记忆、提问、计分、保存结果。这里的“统一”是实验组织层的统一，而不是让所有记忆系统内部实现相同。

表 1　MemoryData 提供的是一套比较底座：它把“谁来考、考什么、怎样留痕”拆开配置

下面这张全局图把“中心型”的含义画完整：左侧是可替换的考生和试卷，中间是 MemoryData 固定的适配、执行和留痕协议，右侧才是可以被审阅的成绩单。只有左侧条件写清楚，右侧差异才值得解释。

图 1　MemoryData 全局图：方法配置与数据配置进入同一协议，经过加载、记忆、作答和计分，产出能按基准、切片和成本复核的实验记录。

这个定位也回答了一个常见误解：MemoryData 当然是 benchmark suite（基准测试套件），但它的主角不是某一张新试卷，而是“多张试卷 + 多种考生 + 同一考场规则”的组合。它是中心型的评测基础设施。

---

2. 一次实验长什么样：一对配置怎样定义一次考试

先说明缺口。 按完整调研规范，这一节应展示真实数据样本、字段和题目 ID；但当前仓库没有数据目录，本文不能把配置示例冒充成数据样本。为保持诚实，以下改用 README 给出的 SimpleMem + LoCoMo 配置对，展示一次实验怎样被定义。

[!NOTE] 这对 YAML 是“实验报名表”，不是成绩单。它足以解释框架怎样组织一次测试，却不足以证明任何方法的性能；真实样本、输出和指标手算需在数据与模型服务到位后补验。

python main.py \
  --agent_config config/hybrid_simplemem.yaml \
  --dataset_config benchmark/locomo/config/Locomo_qa_4cat_600_dist.yaml

这条命令的形式很简单，但两份 YAML 承担的责任完全不同。前者定义“考生是谁、怎样记忆”，后者定义“拿到哪份题、题目怎么切”。执行入口的这两个参数也正是命令行的核心参数。参数定义在此

表 2　贯穿全文的配置对：它定义了一次 LoCoMo 评测，不代表任何已跑出的分数

这份 LoCoMo 配置把数据路径指向 datasets/LoCoMo/...json，并将样本上限设为 10；因此它是仓库内的可控实验预设，而不是无需准备即可复现的公开成绩。

这个例子说明了 MemoryData 的评测对象：它不是单独调用 LLM 回答问题，而是先把一段长对话加工成记忆，再让同一套记忆方案回答相关问题。LoCoMo Loader 会把原始会话切成带 source_ids 的 context chunks，同时保留问题、标准答案、类别和 evidence；后续才能用 Recall@K 检查检索结果是否覆盖题目真正需要的证据。

这个配置本身不能证明方法效果。调研环境没有配套原始数据和可用模型服务，因此本文不会展示虚构的 sample_id、答案或手算分数。实际使用时应先完成一题冒烟测试，再从生成的结果 JSON 中选择真实样本核验指标。

---

3. 评测怎么跑：从上下文到结果文件

机制主线。 MemoryData 的主线可以概括为五步：读取两份配置，按数据集 Loader 取出上下文和问答对，把上下文写入待测记忆系统，对每个问题调用该系统，再按数据集规则评分并持续落盘。它不是“把全文塞给模型后问一次”的简单脚本；记忆写入、检索与问题回答都在循环中留下记录。

表 3　统一运行器的五步：每一步都对应可检查的中间对象，便于定位“分数来自哪里”

第 2 步是统一运行设计的关键。MemoryAgentBench、LoCoMo、LongBench、MemBench 的原始数据形状不同，但加载器最终都将其整理为上下文与问答对，使后续 Agent 调用循环无需针对每类数据重写。入口函数先调用 create_agent_and_fetch_data，再逐个 context 执行；代码按题保存结果，而不是只在末尾一次写入，因此支持中断恢复。

这里需要分清两种“统一”：

• 统一的是调用协议与产物布局。每个方法都按“接收上下文、形成记忆、回答问题”的方式被调度。

• 不统一的是记忆内部。RAG、长上下文、图结构、摘要、外部记忆服务各自的写入和检索逻辑仍不同，这恰恰是要比较的对象。

从工程视角看，这样的拆法很实用：新增一种方法时，重点是做 Agent 适配；新增一种数据时，重点是做 Loader 和数据集专属的评分元数据。两类变化不会都挤进主循环。

---

4. 怎么打分：统一入口，不等于一把总分尺

先给结论。 MemoryData 有统一的评分入口，但没有把所有任务粗暴折成一个“记忆总分”。这是正确的设计：答对题目、找回关键证据、遵守多选题格式、更新旧知识、花了多少时间，衡量的不是同一件事。真正可信的成绩单应按基准族、切片和指标并排阅读。

通用文本评分函数会在多个标准答案中取最优匹配，输出 exact_match、f1、substring_exact_match、rougeL_f1 和 rougeL_recall。实现见此 但具体数据集还会进入自己的 post_process 分支，补充不同指标。

下面这张图补足“评测方法”本身：一条作答不会只看最终文本，而是把答案正确性、证据覆盖与运行开销拆成三条线；它们最终汇成逐题记录，再按基准和切片聚合，而不是混成一个总分。

图 2　MemoryData 的评测方法：同一条作答被拆成答案、证据和成本三类判断；只有在同一实验条件下，这些成绩才可比较。

表 4　主要指标不是同义词：答案正确、证据找回和成本必须分开读

4.1 Recall@K：为什么它是记忆系统的重要“体检项”

端到端 F1 只能告诉我们“最后回答像不像标准答案”；如果答错了，仍不知道是没记住、没找到，还是找到了却推理错了。Recall@K 给了一条更靠前的诊断线索：把前 K 组检索到的 source_ids 合并，看看其中覆盖了多少题目 evidence。

代码中的公式是：

Recall@K = |前 K 组检索来源 ID ∩ 题目要求的来源 ID| / |题目要求的来源 ID|

LoCoMo 与 MemBench 调用同一套严格的 source-ID 覆盖逻辑，默认可报告 @1、@5、@10 以及请求的 K 值。

这个指标很有价值，但有硬门槛：待测方法必须把检索结果能追溯到原始来源 ID。若一个方法只能给出一段无来源的摘要，最终 F1 仍可被计算，它却无法得到可信的检索 Recall。这不是指标偏见，而是评估对象不同——一个在测“答案”，另一个在测“记忆检索是否找回证据”。

4.2 为什么本文没有伪造“一遍手算”

按调研标准，最好的做法是从一次真实运行的结果 JSON 中挑出一个题目，带着它的真实 question_id、evidence、retrieved IDs 和输出复算上表指标。本工作区缺少原始数据和运行结果，无法完成这一验证；因此没有用虚构样本凑出看似精确的 0.67 或 1.00。这个缺口会影响我们对“当前默认配置是否正确”的判断，但不影响对指标定义与代码路径的判断。

实际补验时，只需要从首次冒烟结果中拿一题：核对题目 evidence、检索来源 ID、Recall@K 字段和上述公式是否一致；再对照原始答案检查 EM/F1。这是把“框架读懂”升级为“本地实验可信”的最低成本步骤。

---

5. 四类试卷分别考什么

四类基准不是重复出题。它们各自把记忆失败的不同侧面放大：有的看长对话事实回忆，有的看冲突更新，有的看长文本选择题，有的故意加入噪声、知识变化和多会话行为。把一类试卷的高分外推为“记忆全面优秀”，正是 MemoryData 希望避免的事。

表 5　四类基准族考察的重点不同；选题应从业务风险倒推，而非从“哪个分数好看”出发

图 3　四类试卷不是替代关系，而是从不同业务风险反推的选择关系；先定位失败方式，再决定要跑哪一类评测。

本地 README 已明确列出上述四类数据的默认路径与任务切片。基准范围与预期输入见此 其中有两个特别值得在选型时保留：

• 如果产品最怕“旧信息没改掉”，不要只跑普通长对话问答；至少要加入冲突消解或 knowledge_update。

• 如果产品必须解释“为什么答出这个答案”，不要只看最终 F1；应优先选择能保留 evidence/source IDs 的任务，并报告 Recall@K。

这也解释了“MemoryData 是考 Agent，还是考记忆系统”的说法为什么容易绕。它最终观察的是 记忆增强 Agent 的端到端表现；但通过不同试卷和部分检索指标，尽量把差异归因到记忆机制。它不是直接脱离 LLM、孤立测一个数据库，也不是只测裸 Agent 的推理能力。

---

6. 论文究竟得出了什么结论

论文的主张。 应把 Agent memory 看成一个数据管理系统，而不是“给模型多塞一段历史文本”。作者将其拆成四个模块——记忆表示与存储、信息抽取、检索与路由、维护与更新——并在 5 类工作负载、11 个数据集上评估 12 个记忆系统与 2 个参考基线。这里的数字是论文实验范围，不等同于本地仓库当前可直接加载的全部内容。

图 4　论文把记忆表示划为显式文本、隐式向量、图/树拓扑和异构复合四类。这只是四个核心模块中的“表示与存储”，却足以说明不同方法并非在做同一件事。来源：配套论文 Figure 2。

它没有得出“某一个记忆系统永远最好”的结论，反而提出了一条更能指导工作的规则：工作负载的瓶颈，决定该看哪一种记忆设计。

表 6　论文五个研究问题汇成一条判断原则：先识别任务瓶颈，再选记忆机制

换成普通语言，论文是在说：记忆系统没有“万能收纳盒”。有些任务最难的是从很多旧信息里找对证据，有些最难的是把已经过期的事实改掉，有些最难的是在很长的历史中不被噪声带跑。不同难题需要不同的收纳、检索和维护方式。

发现一：没有跨工作负载的总冠军。 下图汇集论文在 LongMemEval、LoCoMo 和 DB-Bench 上的端到端结果。不同颜色代表不同记忆范式；读图的关键不是找最高柱，而是看最高柱在不同子图中不断换人。这正是“不能只用一张榜单选架构”的直观证据。图中数值来自论文实验，不是本地仓库的运行结果。

图 5　不同任务、不同指标下的领先方法会切换；论文借此得出“任务匹配比单一通用表示更重要”。来源：配套论文 Figure 7，也是仓库 README 的结果概览。

发现二：检索不是“排得靠前”这么简单。 当证据散落在多个会话、并且和问题相隔更远时，单靠局部相似度往往不够；需要能把相关证据重新组织或组合的检索策略。图 6 左侧比较不同方法在 Recall@K 下的覆盖，右侧显示证据距离加大时各方案的 Recall 变化。它支持的不是“某方法永远第一”，而是“检索设计要匹配证据分散程度”。

图 6　检索表现需要同时看 K 和证据距离：早期命中、跨会话汇集和远距离稳定性是不同能力。来源：配套论文 Figure 8。

发现三：时间跨度会换掉难题的重心。 历史越长，挑战就越不是“模型能不能读更多 token”，而是记忆表示能否保住事件、实体和时间之间的联系。图 7 将三种长期压力放在一起：LongBench 的上下文长度、LongMemEval 的历史会话数，以及 LoCoMo 的证据距离。它解释了为什么“无限堆上下文”并不能替代专门的记忆维护与索引设计。

图 7　长期稳定性不是一个单一尺度：长度、会话数和证据距离会让不同记忆机制以不同方式退化。来源：配套论文 Figure 10。

发现四：更新与维护本身也是设计对象。 同一条事实变了，不只是“把新文本写进去”这么简单：旧版本怎样保留或失效、容量满了删除什么、摘要何时合并、是否让 LLM 以 CRUD 方式操作记忆，都会改变更新正确性与成本。下图将这些维护策略放在一起，也解释了论文为什么主张保守的维护与局部操作。

图 8　记忆维护的四类做法：版本化、淘汰、语义合并与持续优化。它们分别对应“事实更新后怎样避免旧信息干扰”与“怎样控制长期成本”。来源：配套论文 Figure 6。

论文还给出了一组较一致的工程方向：保留足够可追溯的原始证据，不要过早过度压缩；抽取时优先保证覆盖；检索时平衡不同信号；维护时对删除与改写保持保守。它们并不是某个具体算法的配方，而是使用 MemoryData 做实验时值得验证的假设。

本报告的统一判断。 论文给的是“不要迷信统一最优架构、要让记忆设计匹配工作负载”的研究结论；MemoryData 代码给的是把这个结论落到实验上的工具。前者告诉你该问什么，后者帮助你把不同回答放到同一张实验表里检验。

---

7. 适用边界与复现注意事项

MemoryData 的价值很实在，但它并不是“下载后点一下就得到公正排名”的产品。以下几条会直接影响结论是否成立，应在实验开始前处理。

表 7　会改变比较结论的边界：其中前两条必须在正式横评前处理

图 9　公平比较的判断链：MemoryData 让控制变量和结果留痕成为可能，但不会自动替研究者完成控制变量。

第一条是当前最现实的限制：README 明确说明仓库不分发数据，四类数据需要按指定路径准备。数据要求见此 这意味着仓库本身足够解释“框架怎样组织”，却不能单独证明“某方法在真实样本上好多少”。

第二条是本调研最重要的独立判断：统一的 runner 不等于已控制的实验。比如 SimpleMem 预设使用 Qwen3-8B，Zep 预设写的是 Qwen2.5-7B，EverOS 预设写的是 gpt-4o-mini；这些差异能直接改变输出质量与延迟。三个预设可交叉核对 Zep 预设 EverOS 预设 因而，未控制模型条件的结果应叫“预设组合比较”，不能直接叫“纯记忆机制比较”。

第三条涉及报告口径。MemBench 的汇总同时记录 accuracy、Recall@K、写入与读取操作、写入和查询时间、输入输出 token；作者没有把质量和成本压缩进一个分数。这种指标矩阵更接近实际选型：有些产品愿意用少量 F1 换取显著更低的写入延迟，有些场景则不能接受这种交换。

---

8. 怎样把它用成一次可信的选型实验

正确用法不是“把所有 YAML 都跑一遍，然后看谁最高”，而是把业务问题翻译为一份受控的考试计划。下面是一条足够实际的路径。

表 8　从业务问题到实验结论：每一步都在减少“分数很好但不能说明问题”的风险

以本文的 SimpleMem + LoCoMo 配置为例，合理的下一步不是立即宣称它强，而是：

1. 先确认 LoCoMo 数据版本和 10 条样本上限是否符合目的；若要正式分数，改为预先声明的完整范围。

2. 用一题检查输出中是否保留 retrieved_source_id_groups；没有它，就不要把 Recall@K 的缺失误读为 0 分。

3. 换一个同模型、同 embedding、同 chunk 预算的基线方法，在相同 LoCoMo 切片上重复运行。

4. 再加入冲突或知识更新切片，判断它的优势是否只是“会答长对话”，还是确实能处理事实变化。

5. 最终把 F1、Recall@K、写入时间、查询时间和失败率并列，而不是只摘一个最高数字。

这也是 MemoryAgentBench 在这里的正确位置：它是一类被接入的试卷与任务集合，而不是 MemoryData 的对立面。MemoryData 的增量价值，在于把它与其他类型试卷、其他方法预设放进同一套实验编排和产物规范中；单个基准则负责把某一类能力测得更细。

---

9. 结论与适用场景

MemoryData 的本质是一套面向记忆增强 Agent 的实验中台：它把“不同数据集、不同记忆方法、不同指标和不同产物”组织成可重复执行的比较体系。它并不替你发明一个必胜的记忆算法，也不替你替所有业务选择唯一冠军。

论文真正想告诉我们的，是一个很朴素但常被排行榜掩盖的事实：记忆系统是为具体信息工作负载服务的。事实会更新，就考更新；证据分散，就考检索覆盖；历史很长，就同时看稳定性和成本。先定义失败代价，再选择试卷和记忆设计，才是这套框架最有价值的使用方式。

适合使用 MemoryData 的场景。

• 需要在相同实验协议下复现或对比多种记忆方法，避免为每个方法重写数据加载与评测脚本。

• 需要给记忆方案做选型，且业务风险能映射到长对话、冲突、更新、噪声或多会话等题型。

• 需要把最终答案、检索证据和成本一起留档，供后续排错与决策复核。

不适合直接使用它下结论的场景。

• 只想获得一个无需解释的“记忆系统总排名”。

• 没有统一模型、数据版本和检索预算，却要把预设分数解释为算法优劣。

• 需要的是线上记忆存储服务或产品 SDK；MemoryData 是评测与研究框架，不是生产记忆引擎。

所以，对“它到底是做什么的”最简洁的回答是：它是在帮我们把记忆系统的比较，从各说各话的单项考试，变成一套能说明“什么方法适合什么任务”的统一考试体系。

---

10. 附录：术语、最小命令、代码索引与资料

10.1 术语速查

10.2 最小冒烟命令（未在本环境执行）

python main.py \
  --agent_config config/hybrid_simplemem.yaml \
  --dataset_config benchmark/locomo/config/Locomo_qa_4cat_600_dist.yaml \
  --max_test_queries_ablation 1

执行前需要准备对应的 LoCoMo JSON，确保 YAML 指向的 LLM 和 embedding 服务可访问，并通过环境变量提供所用服务要求的凭据。这条命令只验证链路，不能产生可用于横向排名的正式结论。也不要为“重跑”而轻率追加 --force，该参数会清理已有运行状态。

10.3 关键代码索引

10.4 参考资料

1. 配套论文：Are We Ready For An Agent-Native Memory System?

2. 本地 README（中文）

3. SimpleMem 代表性方法配置

4. LoCoMo 代表性数据集配置

---

调研时间：2026-07-12。验证方式：通读配套论文；静态核对 README、执行入口、4 类 Loader、指标实现与代表性配置；未运行模型和完整数据评测。本文的独立判断是：MemoryData 的统一运行接口是有价值的实验基础设施，但只有在模型、数据与预算受控时，才能把它用于“记忆方法优劣”的因果判断。