智能座舱 Agent 记忆怎么评：七类 Benchmark 与演进路线

---

先说结论

没有任何一项公开 Benchmark 能单独覆盖座舱 Agent Memory 的全部问题。结合七项研究，我把评测拆成三个阶段：先建立问答与检索基线，再用可观察结果定位失败，最后检查同一份记忆在长期轨迹中的变化。

本期只评记忆相关链路。 评测输入是按 Session 组织，并标明用户、时间和场景条件的交互文本；范围从历史进入记忆系统，到固定模型生成最终回答。最终回答计入整体结果；正确记忆已经提供但仍答错时，单列为回答侧问题。任务规划、工具调用和最终车辆状态不在本期范围内。

• 对所有系统，都要先评测最终回答。系统能返回本次使用的记忆内容或来源时，再评测检索结果；能返回形成、维护或调用过程的中间结果时，再做过程诊断。无法检查的过程项记为 N/A，不记 0 分，也不根据最终回答反推内部过程是否正确；同时要说明是系统不支持、接口尚未接入，还是本轮尚未建设。

• 评测关注统一的输入和可以核验的输出，不要求系统采用特定的内部实现。即使暂时不知道现有系统的具体架构，也可以先评测；后续能把原因定位到多细，取决于系统能够提供哪些中间结果。

• 实际项目还可以使用第一方座舱对话。它能提供当前产品形态下的领域分布、用户表达、Session 结构和自然干扰，使评测不必完全依赖合成对话。但如果用户尚不知道系统具有长期记忆能力，线上日志中显式的“记住、修改、忘记”会很少，也没有现成的记忆标准答案与标注。因此，日志不能代表记忆功能上线后的需求比例；它需要经过记忆边界标注和受控补充，才能成为可评分数据。

评测项目建议按以下三个阶段推进：

• 三个阶段有前后依赖。阶段 1 先建立可重复的试运行基线；阶段 2 根据失败样本缩小排查范围；阶段 3 在连续历史的多个检查点重复评测。只有设置“问题和正确状态不变、主要只增加历史或干扰”的配对题时，才能把变化解释为历史增长影响。三阶段结果分开报告，不合成一个总分。

• MemoryData 的实验控制和逐题留痕贯穿三个阶段；MemoryAgentBench 主要留作后续候选方案比较。

• 公开结果还显示，复杂系统并非总是更好。在部分任务上，简单检索或面向具体任务设计的基线并不弱于复杂系统；不同方案在精确检索、跨会话综合、信息更新和长期稳定上各有取舍。

因此，可以先用阶段 1 评测现有记忆系统，把结果作为首期试运行基线。找出主要短板后，再决定优化现有系统，还是低成本筛查其他候选方案。

首期可以选择一个确实依赖长期记忆的座舱主题，整理 30～50 条可核验用例，完成不使用记忆、简单检索、现有系统和直接提供正确来源四组对照，再输出第一版试运行结果。

---

七项研究各自解决什么

先看它们各自关注什么

下表只回答“这个项目主要研究什么”。它们的优点、局限和详细证据见后文各项目小节。

放在一起比较

七个项目的公开分数不能横向排榜，因为数据、模型、提示词（Prompt）、预算和评分方式都不同。

公开实验透露出的共同问题

这些结论来自各研究自身的数据、模型和实验设置，用于总结公开评测发现的记忆系统规律。不同 Benchmark 的分数不能横向比较，相关结果也不是本地复跑结论。

这些发现共同说明：记忆系统的效果并不只由底座模型或架构复杂度决定，还受到记忆表示、证据检索、信息更新、长期保留和场景调用等环节的共同影响。

各项目的实验设置、适用边界和不能外推的结论，分别在后文小节中说明。

这些研究如何落到评测里

七项研究怎样进入一套评测体系

目的不是在七个项目中做七选一，而是吸收适合座舱场景的方法，再组合到三个阶段中。

图中的三个阶段是建设主线。MemoryData 的跨工作负载结论用于选择题型、指标和分析维度，其实验框架贯穿全过程；候选方案比较仍等到出现明确选型需求后再做。

落地时保留四条原则

1. 没有一套 Benchmark 可以直接照搬。 每个项目只解决一部分问题，座舱评测仍要自己定义测试数据、正确答案、来源和适用条件。

2. 阶段 1 要同时看问答和基础检索。 问答看整体是否有效，检索看是否找到了回答所需信息，两者分开报告。只有记忆文本时评价内容；能指回来源时再评价来源；都不可见时记为 N/A，不从答案反推检索。

3. 只看最终答案，无法缩小排查范围。 阶段 2 使用运行前确认并冻结的各环节标准结果，沿正常链路寻找最早出现偏差的可观察结果；中间结果不可见时，对应过程项记为 N/A。

4. 长期评测关注同一份记忆怎样随时间变化。 它不是增加更多互不相关的题目，而是持续写入同一份记忆，并在多个时间点检查错误是否累积、状态变化后能否恢复。

把这些方法拼成一套评测框架

三个阶段说明评测项目怎样推进。下面三类信息用于设计题目和解释结果，两者不是一回事。

先分清三个维度

其中，形成、维护和调用是评测时的三个检查环节，不要求被评测系统内部也按三个模块实现。

形成、维护和调用分别检查什么

后文所说的“更新”是维护中的一种情况；检索结果是调用环节的可观察结果。最终回答是整体结果：已经取回正确记忆但仍然答错时，记为回答侧问题，不归入形成、维护或调用。

挑战因素只用于分组

挑战因素只用于分组，不参与总分加权*。* 它不单独创造新的评分指标。每道题可以带一个或多个挑战标签，例如“历史较长”“信息发生变化”或“多人及条件”。报告时，分别统计各组的问答、检索和严重错误结果，观察系统在哪些条件下明显下降。同一道题可以进入多个分组，因此各组成绩不能直接相加或平均。

每条测试数据统一包含：按时间排列的历史、提问时点、问题、标准答案和回答所需来源，并按题型标注不得使用的旧来源、他人来源、未来来源或无关来源。

同一批题使用“不使用记忆、简单检索、现有记忆系统、直接提供正确来源”四组对照。四组的具体定义和控制条件见阶段 1。

从公开方法到实际评测

评测数据怎么建

三个阶段回答“怎样评”，数据建设回答“拿什么评”。它是三个阶段共用的数据底座。三个阶段复用同一套事实、事件和来源底稿；进入阶段 2 的样本要在运行前补齐并冻结各环节标准结果，阶段 3 再按需要扩成长轨迹。

真实数据能提供什么、还缺什么

实际项目如果拥有第一方座舱对话，就可以从中还原当前产品形态下的主题、自然表达、Session 间隔、历史长度和无关干扰，也能找到大量“一次性指令不应被长期记住”的候选反例。

这些对话还不是现成的 Memory Benchmark。当前用户不知道系统具有长期记忆能力，很少主动说“帮我记住”；日志中也没有“该不该记、何时生效、以后怎样回答”的标准标注。因此，真实数据负责提供现有对话的表达与环境分布，以及样本种子；人工标注与受控构造负责补齐记忆行为并把它们变成可评分数据。

公开 Benchmark 的数据方法怎样借

公开 Benchmark 解决的是“怎样把题做成可判分”；线上真实对话解决的是“真实用户怎样表达、哪些场景实际存在”。这里吸收前者的组题、标注和质检方法，不照搬其合成数据分布。

“该不该长期记”以及长期、临时、一次性的边界，仍要由产品规则和人工标注确定。公开 Benchmark 无法替实际项目给出答案。

更完整的数据生成证据和使用边界见后文七项研究小节。

数据构造流程

真实数据负责提供当前对话的主题、表达与干扰，受控构造负责补齐上线后才会出现或线上低频但重要的记忆风险。

标注与质检

“把空调调到 22℃”可以标为一次性指令，“我平时喜欢 22℃”可以标为稳定偏好，“今天先用 24℃”可以标为临时例外。多次重复操作能否推断成长期习惯，如果产品口径尚未确定，首版先放入探索集，不进入核心得分。

真实衍生评测集和受控挑战集要记录数据来源与改动内容，并分开报告。前者反映真实语境，后者检查低频但重要的风险，不能把挑战集中的样本比例解释成线上真实发生率。

自动检查负责时间顺序、用户归属、新旧关系、证据存在性和未来信息泄漏。人工复核负责“该不该记”、问题是否有唯一答案以及表达是否自然。

被测系统只读取历史、必要的用户/时间/场景信息和问题；标准答案、来源及各环节标准结果必须与输入隔离。

本期仍以文本化 Session 为输入，不把 ASR 噪声作为数据变量。

---

评测项目如何演进

演进原则

三个阶段有前后依赖：先把结果测准，再建立定位问题的方法，最后验证长期使用下的稳定性。

• 阶段 1 是所有系统都要完成的基础评测。完成阶段 1 后，有稳定失败且能获得可核验过程结果的系统，再开展阶段 2 诊断。无适用失败或过程不可见时，分别记录“本轮无诊断样本”或“因不可观察未执行”，不能写成已完成过程诊断，也不影响进入阶段 3。

• 阶段 3 面向所有系统，其轨迹、标注和评测脚本可以与阶段 2 并行准备。系统能否返回中间结果，只影响失败解释的深度，不影响长期问答本身的评测。

• 阶段 1 的“小规模”不等于只测简单题。首批数据要少量覆盖多条信息、一次更新、用户与条件、干扰和无答案；阶段 3 再把这些因素扩展为同一记忆实例上的连续长期轨迹。

现有记忆系统从阶段 1 开始就是首个被测对象。MemoryData 的研究结论用于三阶段的题型选择、指标拆分和结果解释；从阶段 1 起，按其思路保留必要的实验控制和逐题记录。

是否复用 MemoryData 代码，待现有系统接口核验后决定。候选架构比较是评测体系的用途，不再作为一个阶段**。** 阶段 1 后可以做低成本路线筛查；涉及正式选型时，再使用冻结的代表性数据、盲测集和统一资源约束

阶段 1：基础问答与检索基线

要回答的问题： 现有记忆系统是否比“不使用记忆”和“简单检索”更有效？它能否提供回答所需的记录？

每条样本由一段按时间排列的 Session 历史和一个末尾问题组成，并人工标注标准答案、必要来源、提问时点；再按题型标注不得使用的旧来源、他人来源、未来来源或无关来源。

首批以真实衍生评测集为主，不按“帮我记住”筛选。显式记住、忘记和删除等线上稀少行为，进入单独的受控挑战集。

首批建议建设 30～50 条人工可核验样本，用于验证评测流程和评分方式，不作为正式验收集。每道题按需标注直接事实、信息组合、一次简单更新、不同用户或条件、信息不足等挑战标签；同一道题可以带多个标签。

同一批题完成四组对照。四组使用相同的问题、用户、时间和场景条件，区别只在于回答模型获得的历史记忆信息：

1. 不使用记忆： 回答模型只看到当前问题及必要的用户、时间和场景条件，不看到历史 Session，用于确认题目是否真的依赖历史；

2. 简单检索： 以同一 Session 内的一轮用户—助手交互为固定检索单元，预先固定检索输入的组成方式、检索器、top-k 和显式用户或场景过滤规则，直接返回原始记录，不做摘要合并、用户画像或状态更新；

3. 现有记忆系统： 按产品真实写入和查询链路运行，得到当前系统基线；

4. 直接提供正确来源： 将人工确认的必要来源直接提供给回答模型，确认拿到正确信息后能够回答。

对于可以把记忆结果接入同一回答模型的方案，四组必须固定回答模型、Prompt、解码参数、问题格式、候选历史的时间边界、允许使用的用户与场景字段、评分方式和记忆 token 预算。这样，组间差异才主要来自提供的记忆信息。

若现有记忆系统只能通过自带回答模型的黑盒接口评测，应单列为端到端结果，不能把它与固定回答模型下的无记忆、简单检索或正确来源组之间的分差解释为“记忆模块增益”。无法完全对齐的条件必须列明，同时报告质量、延迟和成本。

阶段 1 同时报告两条主要结果：

• 问答结果： 总体正确率，以及按不同挑战类型分组后的正确率；

• 基础检索结果： 取回内容是否完整、正确；能够指回原始来源时，再检查必要来源是否找齐，以及是否混入错误来源。

检索结果按系统实际能够返回的内容分三级处理：

最终答案不能代替检索结果。N/A 只用于系统接口在本轮根本不提供记忆内容或来源的情况；接口具备该类输出但某条样本返回空结果时，记为“未取回”并进入检索分母。调用超时或执行失败单列为运行失败，不能改记为 N/A。

串用其他用户的记忆、使用旧值、信息不足时编造答案等严重错误单独统计；延迟和成本单独记录。它们不与问答、检索加权成一个总分。

阶段 1 交付物： 首批人工核验数据集、四组对照结果、问答与检索对比表、逐题记录，以及代表性失败样本（如有）。

进入阶段 2 前应具备： 题目和来源已经人工确认；四组对照可以重复运行；用于记忆归因的题目在直接提供正确来源时能够答对；每个结果都能追溯到数据和版本；存在能够稳定复现且值得诊断的失败。

当前系统没有超过简单检索也是有效的试运行结果。若存在稳定失败，可以进入阶段 2；若只是需要尽早判断路线，也可以在不改变三阶段主线的前提下，对少量候选方案做低成本筛查。

阶段 2：过程诊断与改进闭环

要回答的问题： 一道题答错了，最早从哪个可观察结果开始偏离标准？

阶段 2 可以使用阶段 1 中预先标注的候选诊断样本，也可以从阶段 1 的稳定失败中筛选样本，补齐过程标注后冻结到下一数据版本。

无论样本怎样选，各环节标准结果都必须依据原始历史独立标注，并在查看系统中间结果和调试日志前冻结，包括事实、归属、新旧值、适用条件、有效时间和来源。

系统仍按正常链路接收原始 Session 和问题。评测端用隐藏标注检查系统实际产生的中间结果，不向系统写入正确记忆，也不替系统维持或修正状态。

以“24℃ 改为 22℃”为例，评测端预先标注三个结果：第一次交互后应形成 24℃；第二次交互后应以 22℃ 为当前值；提问时应取回支持 22℃ 的记忆。

这里的标准结果只描述应当成立的事实、当前有效值和来源，不规定内部存储结构，也不要求系统提供统一的数据库操作。

最早出现偏差的可观察结果，用于初步缩小排查范围：

这套做法主要借鉴 HaluMem 对记忆形成和新旧值的标注，并结合 LongMemEval、LoCoMo 对必要来源的标注。

能直接查看写入、更新或当前记忆结果时，可以检查对应环节。只能通过查询取回记忆时，只能说明“这次没有拿到正确结果”，无法区分存储错误和检索遗漏。系统只能返回最终答案时，过程项记为 N/A。

最早出现的可观察偏差只是排查起点，具体代码根因仍需日志、对照实验或调试确认。

过程检查优先使用只读导出或只读调试查询。调试接口只允许访问授权的测试用户和测试实例，并具备最小权限、访问审计和有效期控制，不提供不受限的生产用户记忆查询。

如果查询可能写回记忆，则每个检查点都从干净实例按正常链路独立重放，并只在末尾查询一次，避免评测动作改变后续结果。

阶段 2 的工作流程分三步：

1. 从阶段 1 数据中选择能够稳定复现的失败题。各环节标准结果必须已经在运行前冻结，并能对应到系统可返回的中间结果；

2. 按正常链路重放，找到第一个与标注不一致的可观察结果；

3. 修复后重跑同一条过程用例和原问题，分别检查过程结果与最终回答；如果过程已经改善但答案仍错，继续检查后续环节。

阶段 1 看整批题“总体表现如何”；阶段 2 解释代表性失败“先错在哪里”，不再生成一个新的综合分数。阶段 2 通常只包含一次受控变化；阶段 3 才让同一份记忆经历多次变化和多个检查点，观察错误是否长期累积。

阶段 2 的样本来自代表性失败，其位置分布不能外推为系统整体的过程正确率。后续如果需要过程通过率，应另建按场景和错误风险分层抽样的固定过程集。

如果首批数据只有问答和来源标注，该样本不能用于解释本轮过程结果。需要补齐各环节标准结果并冻结为下一数据版本后，再用于后续诊断与回归。

阶段 2 交付物： 过程可观测性清单、各环节标准结果已冻结的诊断用例、最早可观察偏差与代表案例、经调试确认的修复方向和回归用例。清单说明每个过程项是可检查、系统不支持、接口未接入，还是本轮尚未建设。

阶段 2 的最小完成条件： 对本轮实际开展的诊断，代表性失败能够稳定复现；可观察结果有明确标注；修复前后能够用同一条用例判断是否改善。该条件只表示诊断闭环成立，不代表不可观察环节已经通过。

如果阶段 1 暂无稳定可复现的记忆侧失败，阶段 2 记录“本轮无适用诊断样本”；如果失败存在但过程不可见，记录“因不可观察未执行”。两种情况都不阻塞阶段 3，但不能据此给出过程正确或根因已经定位的结论。

阶段 3：长期轨迹与稳定性验证

要回答的问题： 同一套记忆连续使用一段时间后，该保留的信息还能保留、该更新的信息能及时更新，回答时也能取对吗？

阶段 3 不再让每道题从空状态开始，而是在同一份记忆上持续加入新事件，中途不清空、不人工修正。同一辆车下可以包含一个或多个用户。

下面是一条最小长期轨迹。每次变化后都提问，检查系统是否使用了当时有效的信息。

轨迹中设置多个检查点。每个检查点只允许使用此前已经发生的信息，并核对当时的正确答案和必要来源；系统能够返回当前记忆状态时，再核对其状态。后续信息不得泄漏到前面的结果中。

多检查点轨迹回答“连续使用时是否还能维护和调用正确状态”。如果要进一步判断历史长度的影响，还需要保持问题、正确答案和当前有效状态不变的配对题。两类轨迹在下文分开说明。

首版中，检查点问答只读取结果，不写回记忆，以免评测本身改变后续状态。产品链路如果会写回，再单独设置一组实验，并记录实际写入内容。

阶段 3 与前两阶段的边界如下：

一条长期轨迹应同时包含两类信息：需要长期保留的稳定信息，以及应该随着新事件变化的信息。否则只能测“是否忘记”，不能同时判断“该保留的能否保留、该更新的能否更新”。

重点覆盖：稳定事实长期保留、偏好反复修改、临时条件结束后恢复、多人信息隔离、信息失效或删除、长距离多证据，以及历史增长后的干扰。

由多次行为推断习惯，在产品口径明确后再纳入正式测试；此前只作为探索项。

阶段 3 使用两类轨迹，二者分开报告：

阶段 3 不增加新的检查环节，只提高时间、规模、变化和干扰的强度。系统能返回什么，决定可以报告哪些指标：

• 所有系统都报告： 各检查点问答正确率、严重回答错误、整条轨迹正确率，以及延迟和成本随轨迹推进的变化；

• 能够返回记忆内容或来源的系统额外报告： 按阶段 1 的三级规则报告内容或来源检索结果，并检查旧值、他人来源和未来来源是否被误用；

• 能够返回当前记忆状态的系统额外报告： 稳定信息保留率、变化信息更新正确率，以及过期或已删除状态的残留率。

只有配对题满足“问题、正确答案和当前状态不变”的控制条件时，才额外报告历史长度退化曲线。否则只报告各检查点结果，不把变化解释为历史增长的因果影响。

系统接口不提供的项统一记为 N/A，不从问答结果倒推；接口具备输出但返回空结果时，按失败统计。能看到中间结果的系统出现失败时，再用阶段 2 的隔离方法判断原因。

除单个检查点成绩外，还要报告整条轨迹是否从头到尾全部正确。这样可以避免平均分掩盖某个关键时点的严重失败。

阶段 3 交付物： 连续长期轨迹数据集、多检查点报告、严重错误清单和长期回归集；具备配对控制时，再增加历史长度退化曲线。

阶段 3 完成标准： 每个检查点的答案、必要来源和时间边界可追溯；两类轨迹分开报告；能直接检查的项与 N/A 项标注清楚。若发现问题，应能稳定复现并将关键风险转成长期回归用例；若未发现问题，则记录覆盖范围和未覆盖边界。

该标准表示长期评测流程和证据可用，不表示系统已经达到产品质量门槛。

阶段 1 后可以用开发集做低成本候选筛查。正式验收或架构、供应商选型时，另建冻结的盲测集，并让候选方案在同一数据、模型、Prompt、评分规则和资源约束下比较。选型是使用评测体系，不是新的评测阶段。

开发集用于调参、分析和回归；盲测集按用户或完整事件轨迹隔离，避免同一用户、历史或事件链泄漏到两边。盲测答案、来源和逐题结果不向候选方开放，由评测方按固定配置集中运行，正式门槛和选型结论只使用盲测结果。

下一步怎么做

当前先做阶段 1：用一小批可核验数据跑通评测并形成试运行结果；出现稳定失败时，再留作阶段 2 诊断。过程诊断和长期轨迹暂不全面展开。

第一步：确定首期评测范围

首期只选一个答案明确、历史可人工核验的主题，例如温度偏好或媒体偏好。主题优先级由当前线上对话分布、用户影响、严重错误风险和对长期记忆的依赖程度共同决定，不能把当前日志比例解释成记忆功能上线后的需求比例。输入输出沿用“结论先行”中的评测边界。

不同用户、座位和场景条件作为已经确定的测试输入，不评价它们的识别过程。

第二步：把真实对话做成 30～50 条可评分用例

首批数据以真实衍生评测集为主、受控挑战集为辅。真实对话不是直接拿来跑分，而是按以下四步加工：

每条数据至少包含：按时间排列的历史、提问时点、问题、标准答案和回答所需来源；再按题型标注不得使用的旧值、他人信息、未来信息或无关来源。“暂不确定”的样本先进入探索集，不参与核心得分。

显式记住、忘记、删除等线上稀少行为，按真实表达方式构造成受控挑战集中的用例。两类数据分别统计，不能用受控挑战集的样本比例代表线上发生率。

首批样本覆盖直接事实、信息组合、一次简单更新、不同用户或条件、信息不足等典型情况，每类少量即可。同一道题可以带多个挑战标签。

这 30～50 条只用于验证评测流程并发现问题，不用于正式验收、系统定级或架构选型。

首期报告中的比较都应写成“在本主题、本批样本中观察到”。需要设定正式质量门槛或支持架构选型时，应继续扩展主题和样本，冻结独立盲测集，不能用已经参与诊断和调优的回归用例代替盲测结果。

使用真实历史前，必须确认数据准入、脱敏、访问权限、保存期限和删除方式；条件未满足时只使用人工构造数据。逐题记录按源数据同级管控，汇报只展示聚合结果或再次脱敏的案例。

真实衍生数据、原始历史、来源映射和逐题结果，不应默认发送给外部模型、LLM Judge 或候选供应商。确需离开受控环境时，应先确认授权，并按最小必要原则提供脱敏内容；权限没有确认时，使用本地或私有部署模型、人工复核或人工构造数据。

LLM Judge 只接收判分所必需的内容。能够只用问题、标准答案和系统答案完成评分时，不提供完整历史。

示例：一条可评分数据

下面是一条完全虚构的“偏好更新”样例。history 和 question 是被测系统看到的内容；其余字段只用于样本管理、分组和判分，不应暴露给被测系统。

{
  "case_id": "temperature_update_001",
  "topic": "cabin_temperature_preference",
  "data_type": "controlled_challenge",
   "evaluation_split": "pilot",
  "history": [
    {
      "session_id": "S1",
      "time": "2026-05-03T08:10:00+08:00",
      "messages": [
        {"source_id": "S1-U1", "role": "user", "user_id": "driver_A", "seat": "driver", "content": "我平时开车喜欢把空调设成 24℃。"},
        {"source_id": "S1-A1", "role": "assistant", "content": "好的，已经按你的要求调整。"}
      ]
    },
    {
      "session_id": "S2",
      "time": "2026-05-10T19:20:00+08:00",
      "messages": [
        {"source_id": "S2-U1", "role": "user", "user_id": "passenger_B", "seat": "front_passenger", "content": "我坐副驾时喜欢 20℃。"},
        {"source_id": "S2-A1", "role": "assistant", "content": "好的，已经按你的要求调整。"}
      ]
    },
    {
      "session_id": "S3",
      "time": "2026-05-20T08:05:00+08:00",
      "messages": [
        {"source_id": "S3-U1", "role": "user", "user_id": "driver_A", "seat": "driver", "content": "最近天气热了，以后我开车时改成 22℃ 吧。"},
        {"source_id": "S3-A1", "role": "assistant", "content": "好的，已经按你的新设置调整。"}
      ]
    }
  ],
  "question": {
    "time": "2026-06-01T08:00:00+08:00",
    "user_id": "driver_A",
    "seat": "driver",
    "content": "我平时开车喜欢把空调设成多少度？"
  },
  "gold": {
    "answerable": true,
    "answer": "你平时开车喜欢把空调设成 22℃。",
    "required_sources": [
      {"source_id": "S3-U1", "reason": "支持当前有效值"}
    ],
    "forbidden_sources": [
      {"source_id": "S1-U1", "reason": "已被更新的旧值"},
      {"source_id": "S2-U1", "reason": "其他用户且座位条件不同"}
    ]
  },
  "challenge_tags": [
    "信息变化/一次修改",
    "用户与条件/不同用户",
    "用户与条件/不同座位",
    "干扰与信息不足/旧值干扰"
  ],
  "diagnostic_gold": [
    {
      "after_session_id": "S1",
      "expected_memory": "driver_A 在主驾场景下的常用空调温度为 24℃",
      "supporting_sources": ["S1-U1"]
    },
    {
      "after_session_id": "S3",
      "expected_memory": "driver_A 在主驾场景下的常用空调温度已更新为 22℃",
      "supporting_sources": ["S3-U1"],
      "superseded_sources": ["S1-U1"]
    }
  ]
}

这条样例已经覆盖单题评测所需的核心字段：完整 Session、用户与助手消息、提问时点、提问用户和条件、可回答性、标准答案、必要来源、禁用来源及挑战标签。answerable 表示信息不足时是否应当拒答。

case_id 是样本唯一编号，便于追踪逐题结果；topic 是业务主题，用于按温度偏好、媒体偏好等分组。data_type 区分真实衍生数据与受控挑战数据；本例的 controlled_challenge 表示该题是为覆盖低频风险而受控构造的。

evaluation_split 表示样本用途：首批流程验证使用 pilot，日常调试与回归使用 development，正式比较使用不向候选方开放的 holdout，口径未确定的样本使用 exploration。历史中的助手回复同样保留并分配 source_id；如果回复包含事实，也要判断它能否作为答案来源。

diagnostic_gold 只在阶段 2 诊断子集中增加：它记录关键 Session 后“语义上应当形成或保持什么”，不规定系统内部的数据结构。阶段 1 的普通样本可以不包含该字段。

正式数据仓库还要保存 Schema 与数据集版本、原始数据血缘、人工改动、标注与复核状态、脱敏和访问权限。模型、Prompt、检索参数、逐题输出、延迟和成本属于实验运行记录，不混入样本定义。同一用户或完整事件轨迹只能进入一个数据划分，避免开发集与盲测集相互泄漏。

第三步：完成四组对照实验

按阶段 1 的定义，在同一批题上运行四组对照：不使用记忆、透明的简单检索、现有记忆系统、直接提供人工确认的正确来源。

对可以把记忆结果接入同一回答模型的方案，四组必须固定回答模型、Prompt、问题格式、允许使用的用户与场景字段、评分方式、可见历史范围和记忆 token 预算。黑盒系统单列端到端结果，不把它与固定回答模型对照组的分差直接解释为记忆模块增益。

正式运行前冻结中文问答与检索评分规则，包括语义等价、部分回答、拒答、错误信息混入、LLM Judge 输入和人工复核条件。各指标同时冻结分母和 N/A 处理方式；争议样本与严重错误必须人工复核并保留判定理由。

统一保存最终答案、系统能够返回的记忆或来源、数据与系统版本、延迟和成本。系统接口不提供相应结果时，检索项记为 N/A；接口返回空结果时按“未取回”统计。问答评测照常进行。

第四步：形成第一版结果报告

主报告只展示：四组对照的问答结果、不同挑战类型下的成绩，以及三到五条代表性失败案例。同一道题可归入多个挑战类型。真实衍生评测集与受控挑战集分开报告，并说明两类数据的数量与来源。

检索部分根据系统能返回的内容展示：有来源时报告来源找齐率和错误来源混入率；只有记忆文本时报告内容是否完整、正确；接口不提供相关输出时记为 N/A，接口返回空结果时按“未取回”统计。

串用其他用户的记忆、使用旧值、信息不足时编造答案等严重错误单独列出。问答、检索、严重错误、延迟和成本分别呈现，不合成一个总分。

阶段 1 的结果如何决定下一步

以下情况可能同时出现，应分别采取行动，不能只看总体正确率。

阶段 1 完成条件：评测结果可以信任

同时满足以下条件后，阶段 1 的评测流程才算完成。随后，阶段 2 按实际情况记录为“已完成本轮诊断”“本轮无适用诊断样本”或“因不可观察未执行”；后两种状态不能表述为过程诊断已经完成。阶段 3 的数据和脚本可以同步准备。

• 四组对照均已完成，重复运行结果基本稳定；

• 每道题的答案和必要来源都经过人工确认；存在旧值、他人信息、未来信息或无关来源时，禁用来源也已经确认；

• 每道题的数据来源、人工改动、数据类型和标注版本都可以追溯；

• 用于记忆归因的题目，在直接提供正确来源时回答模型能够答对；Oracle 仍答错的题保留在问答结果中，但不用于判断记忆环节；

• 每个结果能够追溯到数据、模型、Prompt 和系统版本；

• 如果发现失败，代表性失败能够稳定复现；进入阶段 2 的诊断子集，已在运行前冻结各关键 Session 后的预期记忆结果、新旧关系、适用条件和来源。若没有稳定失败，记录“本轮无适用诊断样本”，不影响阶段 1 完成。

这些条件只表示首期结果在当前主题和当前样本范围内可重复、可追溯，不表示被测系统已经达到产品质量要求，也不表示结论可以外推到全部座舱场景。当前系统没有超过简单检索，仍然可以完成阶段 1，因为这本身也是有效的试运行结果。

被测系统的质量门槛

系统是否通过，需要另行设定质量门槛，至少包括三类要求：在目标场景中相对“不使用记忆”和“简单检索”的实际增益；串用其他用户的记忆、旧值误用和无依据编造等严重错误红线；延迟和成本预算。

具体阈值应结合阶段 1 试运行结果、业务风险和版本目标确定。首批 30～50 条数据不直接作为正式验收集，也不把上述要求合成一个总分。正式验收和选型使用冻结的代表性盲测集。

前置依赖

阶段 1 启动前需要明确以下依赖：现有系统的 Session 写入、写入完成确认和查询方式；测试实例的重置或隔离方式；提问时点与事件时间的传入规则；查询是否会写回记忆；本次提供给回答模型的记忆内容或来源；合法可用的测试数据；“该记、不该记、暂不确定”的标注规则与复核人；固定的回答与评分配置。

系统能返回什么，就按阶段 1 的三级规则报告什么；无法直接检查的项记为 N/A，并注明原因。是否补充中间结果接口，作为系统接入依赖单独决策；接口若建设，必须限定测试环境、测试用户、访问角色、授权期限和审计日志。

附录

覆盖与缺口矩阵

下表只表示“项目提供了哪些可借鉴方法”。● 表示直接提供任务、标准答案、标准状态或诊断方法；○ 表示只能间接覆盖或需要改造；— 表示不直接提供该列所需的任务、标注或诊断方法。

矩阵说明了三个缺口：公开项目没有统一覆盖结果、检索和过程；只有 DynamicMem 直接提供多个时间点的标准状态；座舱中的用户、座位、车辆和条件关系仍需按实际业务定义。

---

[VehicleMemBench]

项目摘要

VehicleMemBench 是七项研究中最贴近智能座舱的一项：它不只问“Agent 是否回答正确”，而是让 Agent 根据长期多人历史调用车辆工具，再检查虚拟车辆是否达到参考状态。

论文结果来自特定模型和虚拟环境，本文未在本地复跑。三条发现值得关注：

• 任务确实依赖记忆： 最强模型无记忆时 ESM 仅 19.43，给定 Gold Memory 后达到 90.60。Gold 代表任务上限，不是可部署方案；

• 复杂系统未必优于简单基线： 同一模型下，任务定制的递归摘要达到 64.80，Mem0、MemOS、Memobase 等通用记忆系统没有稳定超过它；

• 条件绑定是主要难点： 条件约束任务比偏好冲突低约 16～23 点，说明“谁的偏好在什么条件下有效”容易在记忆形成和调用时丢失。

心智模型与例子

多人长期历史 → 记忆检索 → 识别人和适用条件 → 调用车辆工具 → 对比参考车辆与预测车辆状态

例子： Gary 要求恢复自己平常喜欢的仪表盘氛围。系统需要从三名共用车辆用户的历史中找到 Gary 在当前条件下的偏好，调用正确工具把颜色设为绿色，并保证空调、座椅等无关状态没有被修改。

全景图（摘自调研报告）：

核心指标

• Exact State Match（ESM）： 整辆虚拟车最终状态是否与参考状态完全一致；

• 字段 Precision / Recall / F1： 是否改到了正确控制字段，是否误改其他字段；

• 值级 Change Accuracy / F1： 颜色、温度、档位等具体参数是否正确；

• 负向 Accuracy / F1： 本应不变的状态是否保持不变；

• 平均调用数与输出 token： 反映执行和输出成本，不代表记忆检索质量。

数据说明

构造链路： 先设计三人共车的 persona，再生成车辆事件和背景事件，按时间组织成长对话，并由人工检查一致性；请求与工具执行结果通过车辆模拟器核验。偏好通常自然出现在对话中，不依赖“请记住”这类显式指令。

规模与边界： 公开数据包含 50 套共享车辆档案、150 个 persona 和 500 道可执行请求。它覆盖多人、条件约束、偏好变化与纠错，但属于合成数据，不是真实车机日志。

优点、局限与借鉴方式

优点： 最终状态客观、可重复；既能检查漏操作和错参数，也能检查无关副作用；Gold/无记忆/自动记忆条件有助于估计任务上限。

局限： ESM 把写入、检索、理解、规划和执行混在一起；没有官方写入与检索质量主指标；完整历史离线写入和虚拟车辆不能代表线上时序与量产安全。

可借鉴之处： 只把它作为座舱场景来源，提取多用户、身份归属、场景条件、偏好变化和用户纠正等测试素材，用于阶段 1 与阶段 3；不沿用其工具调用和车辆最终状态指标。

详细材料：[VehicleMemBench 调研报告]

---

[LongMemEval]

项目摘要

LongMemEval 的核心贡献是把长期记忆拆成两条成绩线：一条检查是否找到了正确证据，另一条检查找到证据后是否回答正确。它还通过 Oracle、Full Context 和 RAG 三种喂法帮助定位瓶颈。

它提醒我们：至少命中一条证据并不等于找齐证据。对于多证据任务，recall_any 很容易掩盖遗漏，必须重点看 recall_all。

论文结果未经本地复跑，主要说明三个问题：

• 长历史中的证据定位与阅读会造成明显损失： LongMemEvalS 中，GPT-4o 在 Oracle 设置下为 87.0%，读取约 115k token 完整历史时为 60.6%；使用 Chain-of-Note 时分别为 92.4% 和 64.0%。该差值同时包含证据定位、阅读和推理损失，不能直接等同于外部检索损失；

• 记忆粒度和检索键会影响效果： 保留“一问一答”原文，并在检索键中加入抽取事实，Recall 约提升 4%、QA 约提升 5%；

• 时间检索和证据阅读仍需单独优化： 为时间类查询补充时间范围，可提升 7～11 个百分点；回答前逐段整理证据，阅读准确率最高约提升 10 点。

心智模型与例子

问题 → top-k 检索与来源 ID → Recall/NDCG → reader 回答 → QA Accuracy → Oracle/Full/RAG 差值归因

例子： 用户问“我上周两次长途一共开了多久”。系统必须找齐两次旅程记录再求和；只找到一次时，可能满足 recall-any，但 recall-all 仍为失败。

评测全景（摘自调研报告）：

核心指标

• Recall-any@k： 前 k 个结果是否至少命中一条证据；

• Recall-all@k： 是否找齐回答所需的全部证据；

• NDCG@k： 衡量证据排序；该仓库实现中第 1、2 名同权，从第 3 名起才折损；

• QA Accuracy： 最终答案是否语义正确；

• Oracle / Full Context / RAG 对照： Oracle 检查拿到正确证据后的回答能力；Full Context 检查从完整历史中定位并使用证据的能力；RAG 检查经过外部检索后的端到端效果。三者差值用于辅助归因，不是官方单项指标。

数据说明

构造链路： 先生成问题、答案及所需证据 session，并经过人工校验；再加入无关 session，控制证据位置、时间距离和历史长度。上游造题流程没有完整开源，下游干扰拼装脚本已开源。

规模与边界： 公开数据共 500 题，每题使用独立的合成历史。S 版本约 50 个 session、115k token，M 版本约 500 个 session、1.5M token；Oracle 版本只保留答题证据。

优点、局限与借鉴方式

优点： 检索与回答可分开归因；Oracle/Full/RAG 对照清楚；Gold source ID 支持逐题审计。

局限： 完整评测要求候选系统能指回原始来源 ID；assistant 侧证据覆盖不足；数据为英文合成，QA 依赖 LLM judge。

可借鉴之处： 阶段 1 借鉴“答案与必要来源同时标注”，分别评价问答和检索，多证据题重点检查是否找全；阶段 2 加入正确来源对照，区分“没有找到”与“找到后仍答错”。

详细材料：[LongMemEval 深度调研]

---

[HaluMem]

项目摘要

HaluMem 是一套操作级记忆评测：不只看最终答案，而是把错误拆成抽取、更新和问答三层，分别判断系统是记漏了、记编了、没有更新，还是更新成了错误新值。

最值得注意的是：低 Hallucination 不一定代表系统可靠。如果系统选择不写入或不更新，Hallucination 可能很低，但 Omission 会很高，因此 Correct、Omission、Hallucination 必须一起看。

论文结果未经本地复跑，主要发现如下：

• 上游遗漏会向下游放大： 上下文从约 16 万增加到约 100 万 token 时，Mem0 抽取召回从 42.9% 降到 3.2%，问答从 53.0% 降到 28.1%；

• 写入成本和更新遗漏需要分开看： HaluMem-Medium 中，Mem0 写入耗时约为检索的 66 倍；HaluMem-Long 中，其进入更新评分的样本中，正确、错误和遗漏分别为 1.45%、0.03% 和 98.51%。公开代码只把候选记忆非空的样本送入更新评分，因此这组比例不能解释为全部应更新样本上的更新率；

• 排行榜结论需谨慎使用： HaluMem 与榜首系统 MemOS 来自同一组织且作者高度重叠。本文借鉴其评测方法，不据此采用系统排名。

心智模型与例子

顺序喂入 session → 检查记忆抽取 → 检查新旧值更新 → 检索并问答 → 分层判错

例子： 用户先说“我喜欢 24℃”，之后纠正“以后用 22℃”。评测分别检查：旧偏好是否被记录、是否正确更新为 22℃、再次询问或使用时是否仍拿出 22℃。

全景图（摘自调研报告）：

核心指标

• Extraction Recall / Weighted Recall： 该记的事实和重要事实是否记全；

• Extraction Accuracy： 系统写入的内容是否都有依据；

• Extraction F1： Recall 与 Accuracy 的综合表现；

• FMR： 是否把 assistant 的引申或诱饵误记为用户事实；

• Update C/O/H： 对已返回候选记忆的更新样本，统计更新正确、漏更新和错误更新的比例；

• QA C/O/H： 回答正确、有证据却答不出、编造错误答案的比例。

公开实现中，候选记忆为空的更新样本转入形成遗漏检查，不进入 Update C/O/H 分母。因此，内部复现时应同时报告候选返回率、相关记忆找回率和以全部更新样本为分母的结果，避免条件分母高估更新能力。

数据说明

构造链路： 先设计 persona 和事件，再生成带来源、重要度、新旧值及干扰信息的记忆点标注；随后生成多轮对话，并据此构造带答案和证据的问题。这样可以直接判断应形成什么、何时更新以及最终应答什么。

规模与边界： 数据包含 20 名虚拟用户。Medium 版约 3 万轮、160k token，Long 版约 5.35 万轮、1M token；两版均有 14,948 个记忆点和 3,467 个问题，Long 版主要增加不计分的干扰 session。

优点、局限与借鉴方式

优点： 能定位失败环节和错误类型；明确区分 omission 与 hallucination；Gold、新旧版本、诱饵和重要度均可控。

局限： 依赖 LLM judge；需要访问内部记忆接口；缺少独立 Recall@k/NDCG；英文合成数据和循环填充不能代表真实信息密度；公开论文与代码对更新分母的描述不完全一致，引用比例时必须注明代码口径。

可借鉴之处： 阶段 2 借鉴其过程拆分方法，分别检查记忆是否正确形成、旧信息是否及时维护，并同时统计遗漏与错误内容；只对可观测环节做精确归因，不要求所有系统采用相同内部结构。

详细材料：[HaluMem 调研报告]

---

[DynamicMem]

项目摘要

DynamicMem 不只保存用户说过什么，而是从长期跨 App 行为中维护用户在某个时点的属性、习惯和偏好，并进一步检查这些状态能否在当前场景中被正确使用。

它最重要的启发是：恢复当前状态和把状态用于服务是两个不同能力；系统可能知道用户当前偏好，却不会在合适场景中使用，也可能保留旧信息但更新新信息失败。

论文结果未经本地复跑，给出三条长期评测证据：

• 长期 checkpoint 上的表现会下降： 从第 1 个到第 5 个季度 checkpoint，五个系统的状态恢复累计下降 4.4～16.7 点，偏好类状态最脆弱。该变化同时伴随历史、时间和事件增加，不能单独解释为历史长度的因果影响；

• 知道不等于会用： 习惯状态的恢复率约为 53%～57%，在场景中主动使用的比例只有约 5%～10%；

• 多数失败发生在回答之前： 在论文抽样的失败分析中，“证据齐全但仍答错”约占 2%～7%，其余失败大多与记忆提供的证据有关，不能只靠更换回答模型解决。

心智模型与例子

跨域行为日志 → 按时间写入 → checkpoint 当前状态 → State Completion → Personalized Service

例子： 用户长期使用 105°座椅靠背，后来因腰部不适持续改为 110°。在新的 checkpoint，系统应恢复 110°这一当前状态；再次驾车时，也只能在身份和条件满足时建议使用，而不能继续沿用旧值。

全景图：

核心指标

• 论文主口径： State Completion 使用 Core + Detail 判断当前状态的核心语义和细节；服务题另有评分点口径；

• 当前默认运行口径： 主要读取 snapshot_holistic 和 rq3_apply_holistic；服务题 point judge 需显式开启，State Completion 还要先确认任务包确实包含 scoring_points；

• 辅助诊断指标： Evidence Precision / Recall / F1 检查证据覆盖，Snapshot Value F1 / Exact Match 检查结构化字段和值；它们不应与论文主分混为一谈。

数据说明

构造链路： 先定义用户在各时间点的标准状态，再生成会导致状态保持、变化或失效的跨 App 事件与日志，最后在多个 checkpoint 生成状态恢复题和场景使用题。

规模与边界： 数据包含 10 名合成用户、每人 15 个月的轨迹，覆盖 16 个应用、17,715 条日志和 5 个季度 checkpoint，平均约 220 万 token。真值清楚，适合受控压力测试，但不能代表真实用户遥测。

优点、局限与借鉴方式

优点： 严格按时间前缀评测；同时覆盖保留、更新、习惯归纳和偏好推断；把“知道”和“会用”分开。

局限： 用户数量少且完全合成；任务包同时携带题目和 Gold，物理隔离需要自行加强；部分配置与指标口径存在漂移，LLM judge 也带来波动。

可借鉴之处： 阶段 3 借鉴同一记忆实例、多时间检查点和当前状态评测，连续加入保留、修改、临时变化、失效与再次变化，观察系统能否使用当时有效的记忆。若要判断历史增长影响，再增加问题、正确状态不变的配对题。

详细材料：[DynamicMem 调研报告]

---

[LoCoMo]

项目摘要

LoCoMo 用跨月双人对话同时测试长期问答、事件总结和多模态续写，覆盖单跳、多跳、时间、常识、人物归属和无答案拒答。它的价值更接近“题型库”和“长程压力测试”。

公开论文结果未经本地复跑，主要发现如下：

• 多跳和时间推理是主要差距： 人类得分 87.9，最强模型为 51.6，单点回忆不是最难部分；

• 更长窗口不保证拒答更可靠： 对抗题的跨模型结果中，GPT-4-turbo（128k）得 15.7 分，Llama-3-70B（4k）为 80 分；该比较同时混有模型差异，只能说明长窗口本身不是充分条件；

• 检索更多也不一定更好： 在 RAG 对照中，使用事实句并只取 top-5 时效果最好，继续增加检索内容反而掉分；

• 长程整理仍然困难： 事件总结的最好 FactScore F1 仅 48.9。本地代码核验还发现，会话级 summary 使用较粗的来源 ID，可能使 evidence recall 偏高。

心智模型与例子

persona + 时间事件图 → 跨月双人对话/图片 → QA 测事实点 → 事件总结测时间线 → 续写测一致性

例子： 跨三次旅程记录“谁在什么条件下调整了座椅、后来为什么改变偏好”，再通过换主语的对抗题检查系统是否把副驾偏好错安到驾驶员身上。

全景图（摘自调研报告）：

核心指标

• QA Lexical F1： 最终答案与标准答案的词面覆盖；

• Adversarial Accuracy： 历史没有依据时是否拒答；

• RAG Evidence Recall： 检索结果的来源 ID 是否覆盖 Gold 轮次；

• FactScore Precision / Recall / F1： 事件总结是否编造或遗漏；

• MM-Relevance： 多模态续写与真实后续的相关性。

数据说明

构造链路： 从 persona 出发生成带时间关系的事件图，再由两个智能体生成跨月对话，最后由人工修订。常规问答同时保留标准答案和证据轮次 ID，便于分别评价回答与证据召回。

规模与边界： 发布版包含 10 段跨月对话、272 个 session、5,882 轮、1,986 道问答和 910 个带图轮次。数据规模较小，也不是真实自然对话。

优点、局限与借鉴方式

优点： 一份数据覆盖问答、时间因果、事件总结和多模态；说话人及证据坐标清楚；对抗题能够检查张冠李戴和过度回答。

局限： 仅 10 段合成对话；Lexical F1 和拒答关键词对中文语义改写较脆；图片本体和部分多模态流程难以直接复现。

可借鉴之处： 阶段 1 吸收单跳、多跳、时间、人物归属和无答案等题型；阶段 3 再扩展为跨会话、长距离证据和干扰信息压力测试，并改造成适合座舱用户记忆的中文文本用例。

详细材料：[LoCoMo 深度调研]

---

[MemoryAgentBench]

项目摘要

MemoryAgentBench 将长上下文、RAG 和 Agentic Memory 拉到相近的外部协议下，按照 Accurate Retrieval、Test-Time Learning、Long-Range Understanding 和 Selective Forgetting 四类能力形成架构画像。

它适合回答“不同架构各自擅长什么”，不适合通过 Overall 平均分宣布一个统一冠军。检索、学习、全局理解和新旧事实处理并不是同一种能力。

论文结果未经本地复跑，重点不是比较总分，而是观察架构取舍：

• 精确检索与整体理解不是同一能力： BM25 的精确检索得分为 60.5，高于长上下文 GPT-4o-mini 的 49.2；长程理解却为 19.0，低于后者的 28.9；

• 综合成绩仍会掩盖子任务短板： GPT-5-mini 的 Overall 为 60.6、Selective Forgetting 总项为 53.0，但多跳 FactConsolidation 子任务的最高成绩只有 28%；

• 新旧信息冲突必须专项评测： 偏好失效、修改和删除不能由综合分代替，也不能默认某类架构已经解决。

心智模型与例子

异质任务 → 统一 context/questions/answers → context chunks 顺序写入一次 → 集中回答多题 → 任务专属指标与资源记录

例子： 将同一驾驶员多次行程和设置记录依次写入，再分别测试能否找回温度偏好、从重复行为归纳通勤习惯、形成跨旅程整体画像，以及在偏好修改后让旧值失效。

全景图：

核心指标

• Substring Exact Match： Gold 是否作为规范化子串出现在回答中；

• Exact Match： 分类或严格格式输出是否完全一致；

• Recall@5： 推荐任务中 Gold 项是否进入前五；

• LongMemEval QA Accuracy： 由 LLM-as-a-judge 对题型化问答判分；

• ∞Bench-Sum LLM-based F1： 用于长文摘要的语义评分；

• 时间与 token： 写入和查询阶段的资源消耗。

数据说明

构造链路： 它不从零生成一套统一对话，而是收集并改造已有 QA、分类、推荐、摘要和反事实更新任务，统一为“一段历史写入一次、随后集中回答多题”的协议。当前公开仓库不能完整重建所有上游数据。

规模与边界： 公开数据卡包含 146 个“上下文包”，四个能力 split 分别为 22、6、110、8。单个包可挂 60～100 道题，因此 146 不是总题数。

优点、局限与借鉴方式

优点： 可在同一外部写入/查询协议下观察三类架构；一次建记忆、多次查询；分项能力画像有助于暴露取舍。

局限： 多任务、多评分器异构，Overall 会掩盖短板；端到端失败不能直接定位内部环节；数据、YAML、API、judge 和预算会影响公平性与复现。

可借鉴之处： 不把它作为三阶段中的建设步骤。阶段 1 后可按需做低成本候选筛查；正式选型时，再用冻结的代表性数据和盲测集，在统一模型、Prompt、评分规则与资源约束下分项比较，不用一个综合平均分选择“总冠军”。

详细材料：[MemoryAgentBench 调研报告]

---

[MemoryData]

项目摘要

MemoryData 同时包含一项跨任务比较研究和一套实验代码。研究回答“不同任务适合怎样的记忆设计”，代码负责把不同系统接入同一实验流程并保留结果。

论文把 Agent Memory 按“怎样保存、抽取、检索和更新”四个环节分析，并在 5 类工作负载、11 个数据集上比较 12 种记忆系统与 2 个参考基线。

这四个环节只是论文分析不同设计的维度，不是本文新增的评测阶段。迁移到座舱后，过程诊断仍按记忆形成、维护和调用三类检查组织。

论文的核心判断是：工作负载的主要瓶颈决定记忆设计，不存在脱离任务的通用最优架构。以下结论来自论文实验，不是本地复跑结果；其中涉及 DB-Bench 执行链路的部分不进入本期座舱评测范围。

代码框架把上述研究思路落到实验中：方法配置和数据配置定义一次比较，Loader、Adapter 和统一 runner 完成写入、查询、评分、逐题留痕和续跑。但默认预设使用的模型、服务端点和参数并不完全一致，直接运行只能说明整套预设的差异，不能自动归因于记忆机制。

心智模型与例子

业务风险 → 选择数据与切片 → 选择候选配置 → Loader + Adapter → 写入/查询 → 答案、证据、失败和成本逐题留痕

例子： 对同一批中文跨旅程记录，在相同底座模型、embedding、chunk 和 top-k 下运行 Simple RAG 与候选 memory，并列报告偏好更新结果、证据覆盖、失败率、写入/查询延迟和 token。

全局图（摘自调研报告）：

核心指标

• Exact Match / Substring Exact Match： 严格答案或关键片段是否命中；

• F1 / ROUGE-L： 开放回答的词项或序列相似度；

• Recall@K： 前 K 组检索来源是否覆盖题目所需证据；

• 写入/查询时间与 token： 质量收益对应的资源成本；

• 成功数、失败数和重试状态： 确认指标分母是否完整。

数据说明

MemoryData 不负责生成或发布新的 Gold 数据，主要解决实验组织、配置、运行和结果留痕。仓库提供 MemoryAgentBench、LoCoMo、LongBench 和 MemBench 四类 Loader/配置，但原始数据不随仓库分发。

论文实验范围大于本地仓库可直接运行范围。当前调研只核验了框架与指标代码，没有形成任何候选方案的本地成绩。

优点、局限与借鉴方式

优点： 跨任务研究能够暴露不同架构的适用条件和取舍；代码框架将 Adapter、Loader 和主循环解耦，并列保留答案、证据、失败状态和成本，便于受控比较与复核。

局限： 论文结果不是本地复跑结果，且部分任务超出本期边界；统一 runner 不自动保证公平，默认预设可能使用不同模型、endpoint 和检索预算；系统若不返回来源 ID，只能测最终结果，不能测检索 Recall。

可借鉴之处： 方法上，用跨工作负载结论为三阶段选择挑战切片，并把答案、证据和成本分开报告；工程上，从阶段 1 起轻量保存数据、模型、Prompt、评分配置、记忆输入输出、来源、版本、逐题结果、耗时与成本。评测体系成熟后，再用相同业务目标和资源约束比较候选方案。

详细材料：[MemoryData 调研报告]

---