MemoryAgent​Bench：在统一交互协议下比较四类记忆能力

调研对象：MemoryAgentBench，ICLR 2026 论文 Evaluating Memory in LLM Agents via Incremental Multi-Turn Interactions，arXiv:2507.05257（v4，2026-06）。 材料来源：论文全文与附录、当前仓库的运行入口/数据适配/评分代码/配置、Hugging Face 公开数据卡及实际样本 eventqa_full_no0。HaluMem 与 LongMemEval 仅用于 §8 的边界比较。 贯穿全文的样例：eventqa_full_no0。它要求 agent 在一本长小说的上下文中，根据已发生的事件，从六个候选事件里选出紧接着发生的一件。

摘要

MemoryAgentBench 不是单任务数据集，也不是新的 memory implementation。它把异质长上下文任务统一成“逐块注入、一次建记忆、多次提问”的交互协议，并从准确检索（AR）、测试时学习（TTL）、长程理解（LRU）和选择性遗忘（SF，仓库中称 Conflict_Resolution）四个维度比较不同 Agent。

公开数据把 146 条上下文样本分入 4 个 split，每条样本下挂 60 到 100 道问题，因此同一段长文本可以反复查询，不必为每道题重新写入记忆。数据卡显示，Accurate_Retrieval 包含 22 个 context，Long_Range_Understanding 包含 110 个；这里统计的是上下文包，而不是题目数量。

它统一的是输入时序和运行协议，而不是题目语义或评分器。文档 QA、事件续写、分类、推荐、摘要、小说推理和事实冲突本来就是不同问题，所以评测同时使用字符串匹配、Recall@5 和 LLM-as-a-judge。把这些分数简单平均成一个“记忆能力”会丢失重要差异，结果应按能力维度分别阅读。

复现时还要留意三项限制：

• 工程边界：仓库更接近实验 harness，而不是通用框架。它将多种外部 agent 实现和数据任务装进 AgentWrapper，便于研究比较，但复用和二次开发的边界并不清晰。

• 配置漂移：论文、README 与当前 YAML 并不完全一致。论文附录将 FactConsolidation 列为 512-token chunk、LongMemEval (S*) 的输出上限列为 100；当前示例 YAML 分别是 4096 和 50。复现论文时不能只运行“看起来相近”的配置。

• 裁判条件：LongMemEval 和摘要的正式分数还要调用外部 LLM judge，因此不是纯离线、完全确定的指标。成本、模型版本与 judge prompt 都应作为实验条件记录。

这套基准适合横向比较长上下文、RAG 和 agentic memory 在不同能力上的取舍。若目标是定位 memory store 在抽取或更新的哪一步产生幻觉，HaluMem 更直接；若只关注聊天助手对用户历史的记忆，LongMemEval 的任务边界更集中。

---

1. 它要解决什么问题：为什么不是又一个长文本 QA

一段很长的文本并不自动等于“长期记忆”。对 memory agent 而言，输入通常是逐步到来的：它先收到前一段信息，形成或更新记忆；过一会儿再收到新段落；最后才面对问题。只把全文一次性塞进模型，考到的是长上下文阅读能力，未必考到记忆的写入、压缩、检索和更新。

MemoryAgentBench 的回答是：把不同来源的数据统一表达成三组对象：

c1, c2, ..., cn   连续到来的 context chunks
q1, q2, ..., qm   在所有 chunks 注入后提出的问题
a1, a2, ..., am   每道问题的标准答案

每个 chunk 都被包装成一轮“请记住这段内容，稍后会提问”的 User--Assistant 对话；全部写入后，再连续发出多道问题。这是它所谓的 inject once, query multiple times。论文的目标不是让所有 agent 使用相同内部算法，而是让它们接受相同的记忆输入和任务提示。

图 1　MemoryAgentBench 的全局框架：统一的是数据外形、交互时序和评分入口；不统一的是题型语义与各方法的内部记忆实现。

表 1　四项能力不是四个指标，而是四种不同的“记住之后还要会做什么”

表里的关键不是名称，而是互相冲突的能力需求：检索适合找局部证据，摘要和侦探推理需要全局整合，冲突消解则要求主动压低旧信息的影响。一个系统能在其中一项很强，并不意味着其他三项也强。

---

2. 一个完整样例：数据怎么长成多轮记忆题

先看真实样例，才能理解这个 benchmark 不是把“问题”和“上下文”简单配对。公开数据集 Accurate_Retrieval split 的第 3 条记录来源为 eventqa_full，其第一个题目 ID 是 eventqa_full_no0。它的上下文以小说章节开头，题面给出一条此前事件及 6 个候选后续事件，标准答案要求只输出正确事件。

{
  "context": "Part One\nCHAPTER I\nDEBBIE O'KERRY ...",
  "questions": [
    "已发生事件：Debbie 与 Stuart、Brent 坐在 Tara 的门廊。\n"
    "请从 6 个候选事件中选择随后发生的一项。"
  ],
  "answers": [["Debbie waited for her father at the end of the driveway."]],
  "metadata": {
    "source": "eventqa_full",
    "previous_events": ["1. Debbie sat with Stuart and Brent Tarleton on the porch of Tara."],
    "qa_pair_ids": ["eventqa_full_no0"]
  }
}

图 2　`eventqa_full_no0` 的最小闭环：同一段小说先被写入，之后才依据已发生事件选择下一件事；一个 context 还可继续挂 99 道问题。

这里有三个层次，别混在一起：

1. context 是完整的长文本；它要被切块并顺序注入。

2. previous_events 是题目显式给出的已发生事件，帮助界定“下一件事”的时间位置；它不是另一个独立记忆库。

3. qa_pair_ids 是结果文件与外部 judge 重新对齐数据的锚点；它不是模型可见的答案提示。

2.1 从原始任务到统一样本

论文并未用一个合成器从零生成所有数据，而是做了“收集、重组、再包装”。主要来源和改造方式如下：

• 文档 QA：从已有长文档 QA 中抽取问题，去重短文档、打乱并拼接成更长的上下文，同时保留 gold passage。

• LongMemEval (S*)：把多个历史会话按时间顺序拼为 5 段约 355K token 的长对话，并配 300 道问题，以提高“同一份记忆”的查询利用率。

• EventQA：从 5 本 ∞-Bench 小说里找主要角色，用 LLM 抽取事件；每题以真后续事件配 5 个干扰项，要求根据最多 5 条先前事件判断后续。

• TTL：把分类样本写成 sentence + label 的历史示例并打乱；推荐任务则合并、去重大量电影推荐对话。

• LRU：采用小说摘要与 Detective QA，分别要求摘要全局叙事和回答需跨全书推理的问题。

• FactConsolidation：使用 MQUAKE 的反事实编辑对。旧事实编号较小、较新冲突事实编号较大，按编号拼成长上下文；题目要求以较新事实为准。

2.2 当前数据集的真实边界

当前 Hugging Face 数据卡显示默认配置共有 146 行：Accurate_Retrieval 22、Test_Time_Learning 6、Long_Range_Understanding 110、Conflict_Resolution 8。每行的 questions/answers 列表长度可达 60--100。这个“146 行”不能被解读成“只有 146 道题”，也不应与论文里按 sequence:QA 报告的任务规模直接混比。

运行时，load_eval_data 从 Hugging Face 的四个 split 加载数据，按 metadata.source 筛选 sub_dataset，再把单值字段标准化为列表。随后 ConversationCreator 取出 context、将问题和答案组成 (query, answer, qa_pair_id)，并把 context 切为 chunks。

---

3. 评测怎么跑：三类 agent 如何被拉到同一赛道

MemoryAgentBench 不要求被测方法实现同一个 Memory 接口。它把方法分成三类，只要求它们都接收连续 chunks，并在全部 chunks 后回答同一批问题。

表 2　三类方法的差别在“记忆放在哪里”，共同点在“先记后答”的外部协议

统一入口是 AgentWrapper.send_message。memorizing=True 表示写入 chunk，memorizing=False 表示回答查询。对 Long-Context Agent，写入只是把包装后的文本追加到 self.context；对 RAG，写入会保留 chunks；对不同 agentic memory，分派到各自实现。

这种设计的好处是，比较时能控制“看到了什么、何时被问、任务如何表述”。代价是，系统内部的 memory construction 并不相同：有的 agent 每块就更新索引，有的在首个查询才建向量库，有的在回答阶段还会反复检索。因此相同的“memory construction time”字段只能当实验记录，不能机械地视作同一种成本。

图 3　统一评测的边界：统一输入、query 和 rubric；不统一各方法内部的存储、检索和重写步骤。

3.1 主程序的两段阶段

主程序 main.py 的逻辑可压缩为五步：

1. 加载 agent YAML 和 dataset YAML，解析 chunk_size、context_max_length、generation_max_length、max_test_samples 等条件。

2. 加载并标准化 context、questions、answers、metadata；每个 context 被切成句子边界尽量不被破坏的 token chunks。

3. 为每个 context 初始化一个 agent；若已有保存状态则直接加载，否则依次调用 agent.send_message(chunk, memorizing=True) 并保存状态。

4. 对该 context 的每道题调用 agent.send_message(query, memorizing=False)，立刻做本地评分。

5. 每题都将原始输出、解析后的输出、gold、token 数、建记忆时间、查询时间和当前指标写回 JSON；中断后会读取已有结果尝试续跑。

图 4　两趟评测方法：将“记忆是否写好”和“查询是否答对”分开记录；同一 context 的多题共享已建好的记忆。

要注意，论文描述的是“增量多轮交互”，而当前基准的典型执行并不是在每个 chunk 后立刻考试：多数任务是 先把一个 context 的所有 chunks 都喂完，再集中回答它的多道题。这依然是增量写入，但更准确地说是“顺序建记忆 + 批量回忆”。

3.2 提示词并非无关紧要

不同任务有不同的 memory 和 query 模板。例如 EventQA 的 query 明确要求从候选事件中选后续事件；分类要求只输出数字 label；FactConsolidation 明说“编号更大的是新事实”；推荐要求输出 20 部电影。模板定义在 utils/templates.py。

这意味着评测不仅考系统的内存，还考 instruction following。尤其是 Exact Match 任务里，答案内容正确但格式多出 label: 之类的前缀，仍可能失败。README 已将这一点明确列为严格解析的注意事项。

3.3 上下文与输出的系统限制

AgentWrapper 将可用输入预算计算为：

input_length_limit - buffer_length - generation_max_length

Long-Context Agent 在特定条件下会只保留最近的 token；RAG 的检索上下文则受 retrieve_num 和 chunk size 影响。以当前 gpt-4o-mini 配置为例，名义 input_length_limit 为 128000、buffer_length 为 4000，实际任务还会扣除答案预算。对比方法时必须报告模型窗口、chunk size、top-k 和生成上限，否则“方法优劣”会混入预算差异。

图 5　系统限制不是背景参数：长上下文会面临历史截断，RAG 受 top-k 与 chunk size 约束，agentic memory 还会产生额外的写入与检索成本。

---

4. 指标与一遍手算

评分器首先按 sub_dataset 分流，然后在 calculate_metrics 计算基础指标。对多个标准答案，代码取所有 gold 中的最大得分，而不是要求同时命中全部写法。最后 metrics_summarization 将任务指标和系统指标一并记录。

表 3　主指标映射：同名“accuracy”在不同任务中不是同一件事

图 6　评分路由：统一的结果文件不意味着统一的指标；同名 “accuracy” 在不同任务里的含义可能不同。

4.1 用 eventqa_full_no0 手算

该样例的标准答案是：

Debbie waited for her father at the end of the driveway.

假设模型严格按提示输出同一句，或输出：

The next event is Debbie waited for her father at the end of the driveway.

那么代码先执行英文小写、去标点、去冠词、压缩空白的归一化；gold 是预测的子串，因此 substring_exact_match = 1。该样例的 answer list 只有一个元素，eventqa_recall 也计算为 1 / 1 = 1，表示所有答案元素都出现。

如果模型选了另一个候选事件，例如“Debbie paced in the garden...”，归一化后并不包含 gold：substring_exact_match = 0，eventqa_recall = 0。这正是 EventQA 作为多选事件续写题的最小判分单元。

但不要因此误以为 EventQA 只会输出一个分数。当前代码同时记录 Exact Match、token F1、ROUGE-L、substring_exact_match 和 eventqa_recall；README 把前者中的 substring_exact_match 定义为该任务的论文“Accuracy”口径。读结果时应先选定报告字段，不能挑最有利的一列。

4.2 两类外部裁判

LongMemEval 的正式评测脚本会先用 question_id 对齐 reference 与 hypothesis，再让 GPT-4o 根据题型判回答是否满足要求；时间推理允许某些 off-by-one 情形，知识更新允许回答中带有旧信息，只要更新值正确。实现见 llm_based_eval/longmem_qa_evaluate.py。

摘要评测则让 judge 分别打 fluency、关键点 recall 和逐句 precision，并计算：

Recall    = 覆盖的关键点数 / 关键点总数
Precision = 被专家摘要支持的模型句数 / 模型句子数
F1        = Fluency(0 或 1) × 2 × Precision × Recall / (Precision + Recall)

这也是为什么 LongMemEval 与摘要任务的分数不能与纯字符串 Exact Match 当作同样稳定的测量。

---

5. 四种能力具体在考什么

四项能力共享“先写入、后提问”的节奏，却在要求 agent 保留什么、忽略什么以及如何答题上彼此不同。把它们拆开看，才能知道某个系统的失分究竟是在检索、归纳、全局建模还是冲突更新。

图 7　能力地图：AR、TTL、LRU、SF 不是一条由易到难的刻度，而是“找证据、学规则、建全局模型、更新状态”四种不同工作。

5.1 Accurate Retrieval：找到，而不是概括

SH/MH-Doc QA 要从超长、多文档上下文取回短事实；LongMemEval (S*) 要从时间排序的聊天历史中找回正确会话；EventQA 则要求从小说中判断事件链的下一步。它们的共同点是答案通常依赖少量关键证据，RAG 的 top-k 选择和 query formulation 在这里最重要。

5.2 Test-Time Learning：从示例归纳规则

多分类任务把大量 sentence → label 示例打乱写入，最终问题要求输出新样本的数值 label；推荐任务则从历史推荐对话中归纳偏好，并给出 20 部电影。它们不只是“找回最相近的一条”，而是要从多条示例抽取一个隐含映射或偏好模式。

5.3 Long-Range Understanding：形成全局模型

∞Bench-Sum 要整理一本小说的剧情和人物，Detective QA 要跨很长叙事链做推理。局部证据即使正确，也可能不足以支撑完整摘要或解释性推断；这也是论文中简单 RAG 在 LRU 上明显落后的原因。

5.4 Selective Forgetting：让旧事实真正失效

FactConsolidation 故意把旧事实放在前、较新的冲突事实放在后，并对 single-hop 和 multi-hop 分开出题。它考的不是“是否检索到两个事实”，而是 agent 能否让回答反映最新状态；多跳版本还要求先沿关系推导，再处理其中被更新的节点。

---

6. 论文结果与真正能得出的结论

论文表 3 的总体结果支持三个方向性的结论，而不是“某一类方法全胜”。下列数字均为论文报告，非本次复跑。

图 8　代表性结果画像：BM25 的 AR 高于 GPT-4o-mini，却在 LRU 落后；GPT-5-mini 的提升也未消除多跳 SF 的困难。

6.1 检索任务里 RAG 有优势，但优势不外推

以 GPT-4o-mini 为共同参考，论文中其 AR 平均分为 49.2；BM25 为 60.5，HippoRAG-v2 为 65.1。说明在“从长文本找局部证据”的任务上，检索确实能弥补短上下文或注意力稀释。

但同一张表中，BM25 的 LRU 平均分是 19.0，低于 GPT-4o-mini 的 28.9；RAG 取到的局部片段未必能重建全书剧情、人物关系或概念全貌。这个差异比“哪一个 Overall 分更高”更有解释力。

6.2 长上下文更适合学习和全局理解，但不是万能记忆

GPT-5-mini 的论文结果为 AR 74.4、TTL 48.6、LRU 56.3、SF 53.0，Overall 60.6，是表中最强的综合结果之一。它说明更强的长上下文与推理能力可以跨多个任务受益。

不过“长窗口”并不自动解决记忆：如果上下文被截断、任务需要精确局部检索，或新旧事实需要多跳传播，模型仍会失败。MemoryAgentBench 的价值在于把这些失败拆到不同能力列中，而不是把它们藏在一条平均 accuracy 里。

6.3 多跳冲突消解仍是硬问题

FactConsolidation 的单跳比多跳容易得多。论文指出所有方法在多跳 SF 上最高仅 28%（GPT-5-mini）；这说明“选较新事实”不是简单的 recency heuristic。一旦问题要先沿多条关系推导，再判断其中哪个节点被更新，局部检索和线性覆盖都容易失效。

---

7. 限制与复现注意事项

7.1 它是综合 benchmark，不是单一诊断工具

MemoryAgentBench 将多种原生数据形态、评分器和 agent 实现置于一个 repo。优点是覆盖面广；缺点是失败定位很粗：某方法在 EventQA 差，究竟是事件抽取错、存储错、检索没取到、还是生成时选错，主结果通常不能直接回答。若研究问题是“memory 在哪个操作阶段出现幻觉”，应把 HaluMem 等操作级评测并列使用。

7.2 当前代码不是完整的数据生成管线

仓库运行时加载 ai-hyz/MemoryAgentBench 的已处理数据；论文描述的“选文档、去重、拼接、用 NER/LLM 构造 EventQA、合成反事实编辑对”等工作不在当前代码中完整重现。换言之，代码可以复跑评测，但不能单靠本仓库从原始基准无损再生成全部 benchmark。

公开数据也曾更新：数据卡记录过删除高成本样本、加入 keypoints、修复 qa_pair_ids 等变更。因此报告实验时应记录 dataset revision、配置文件和结果文件名，而不只写“MemoryAgentBench”。

7.3 论文设置与当前 YAML 有漂移

这是会直接改变结果的真坑：

• 论文附录表 14 将 LME(S*) 的最大输出列为 100；当前 Longmemeval_s_star.yaml 为 50。

• 论文附录表 15 将 FactConsolidation 归在 512-token chunk；当前 Factconsolidation_sh_32k.yaml 为 4096。

• README 以 Conflict Resolution 命名第四维，论文更常用 Selective Forgetting。二者本文视作同一能力，但写作和聚合脚本应统一术语。

因此，当前仓库更适合“按当前配置比较方法”；若要声称复现论文，应回到论文对应 revision，逐项核对模型版本、chunk size、top-k、输出上限和数据版本。

7.4 seed 并未使 Hugging Face 子样本随机化

load_data_huggingface 接收 seed，但当 max_test_samples 小于筛选结果数时，代码调用的是 select(range(max_samples))，即取筛选后的前 N 条，而非 shuffle 后采样。这个问题不必然使结果错误，却会使“随机种子 42”给人一种并不存在的随机抽样印象。小样本 ablation 应显式保存所用的 qa_pair_ids。

7.5 外部 judge、API 与 agent 状态影响可复现性

LongMemEval 和摘要会调用 OpenAI judge；主评测也依赖被测模型、embedding 模型或商业 memory API。除此之外，agent state 会保存在 ./agents/，RAG 还可把检索上下文写入 ./outputs/rag_retrieved/。重跑前若未隔离目录，就可能加载旧状态而不是重新建记忆。

---

8. 和 LongMemEval、HaluMem 的区别

三者不是简单的“新旧替代关系”，而是从不同角度规定“记忆是什么”。这决定了数据形态、能否定位错误、以及适合评什么系统。

表 4　三种 benchmark 的根本差异：对“memory object”的假设决定评测粒度

图 9　选 benchmark 的起点是研究问题：三者可组合使用，而不是互相替代。

LongMemEval。 它聚焦聊天助手的五项长期记忆能力：information extraction、multi-session reasoning、temporal reasoning、knowledge updates 和 abstention。它的历史会话、时间戳和 evidence ID 是核心资产；如果你要测“助手是否记得用户何时说过什么”，它的任务定义最直接。

HaluMem。 它关心的是记忆操作本身会不会产生 fabrication、error、conflict、omission。它把抽取、更新、问答拆开分别评分，因此能说“答错是因为漏记、改错还是回答时编造”。代价是被测系统要暴露更多内部接口。

MemoryAgentBench。 它不试图像 HaluMem 那样定位操作根因，也不只测聊天历史；它把 LongMemEval 的重组版本作为 AR 的一项，再加入文档 QA、事件链、学习、推荐、摘要和冲突事实。它是套件与协议，最适合问“这个架构在哪些 memory 能力上有取舍”。

选型上可以很直接：只做 chat memory 先用 LongMemEval；要诊断 memory store 的幻觉加 HaluMem；要发布一个声称“通用 memory agent”的方法，再用 MemoryAgentBench 证明它不只会检索。

---

9. 结论与适用场景

MemoryAgentBench 的贡献不是发明了一种统一内存，而是给异质 memory 方法规定了一场共同考试：同样按序收到 chunks，同样在写入后接收问题，并以任务匹配的指标记录质量、token 与时间。它让研究者能看到一个朴素但重要的事实：检索、学习、全局理解和冲突更新无法由单一技巧同时解决。

把它当作 多能力压力测试 很有价值；把它当作 单一、公平、可完全诊断的排行榜 则要谨慎。最稳妥的实验策略是：

1. 用 MemoryAgentBench 报告四项能力的分项结果，不以 Overall 掩盖失败维度；

2. 固定并公开数据 revision、YAML、模型、chunk size、top-k、输出上限和 judge 条件；

3. 如果研究对象是抽取改写型 memory，再用 HaluMem 补上错误定位；如果目标是个人助理，再用 LongMemEval 补上真实会话历史能力。

---

10. 附录：术语、最小复现、代码索引与参考资料

10.1 术语速查

10.2 最小复现路径

运行前需要按 README 配置依赖与模型 API 环境；不要把真实 key 写入报告或提交到仓库。一个最小运行命令形如：

python main.py \
  --agent_config configs/agent_conf/Long_Context_Agents/Long_context_agent_gpt-4o-mini.yaml \
  --dataset_config configs/data_conf/Accurate_Retrieval/EventQA/Eventqa_64k.yaml

结果写入 agent 配置的 output_dir 下，包含 data（逐题记录）、metrics（原始指标数组）、averaged_metrics 和 time_cost。LongMemEval 与摘要的正式 judge 还需分别运行 llm_based_eval/ 下的脚本。

10.3 代码索引

10.4 参考资料

• 论文：arXiv:2507.05257 · ICLR 2026 页面

• 当前代码库：HUST-AI-HYZ/MemoryAgentBench

• 公开数据：Hugging Face ai-hyz/MemoryAgentBench

• 对照基准：LongMemEval · HaluMem

---

调研时间 2026-07-12。本文基于论文、配套代码、Hugging Face 数据卡与公开实际样本交叉核对；未运行完整 pipeline，未复算论文结果。论文数字、当前代码行为和本文判断已在正文分层标注。