LongMemEval-V2: Evaluating Long-Term Agent Memory Toward Experienced Colleagues

原论文 · P0 · 多模态网页轨迹记忆评测。核查日期：2026-09-07。

名称说明：AgentRunbook-C不是独立论文标题，而是本篇LongMemEval-V2提出的方法之一。 搜索论文可用LongMemEval-V2或2605.12493。C表示coding agent，方法见正文§4.2和附录C.3。作者项目页与官方仓库已找到；本次补查相关代码路径，未运行系统，核查范围见末节。

0. 摘要

中文转述。LongMemEval-V2问代理是否能从大量过去网页任务中学到环境知识，回答静态事实、状态变化、操作经验和问题前提等问题。作者同时提出AgentRunbook；其中R将原始网页状态、状态变化事件和经验笔记分开保存，C使用文件与代码代理查阅历史。它是当前方案的机制参考，原评测不是同任务进行中的历史查询或GUI执行。

1. 方法动机

“记得之前说过什么”不足以覆盖网页代理历史。它可能要回答订单后来如何变化、某功能有没有用过、一个操作为什么失败。单段文本摘要容易省掉界面细节，整批截图又太大。作者提出让原始证据和抽象记录各有作用。

2. 方法设计

作者图注与上下文。原图用于定位所述流程，下面的演示例子均另外标明。

原文3：先采集网页轨迹，再提出依赖历史的问题

451个问题由人工设计与核验，历史规模从100到498条轨迹，约2500万到1.15亿token的多模态历史表示。问题包含静态状态回忆、动态状态跟踪、流程经验、容易出错的细节及前提是否成立。不是让模型当场完成451个在线网页任务，而是从已采集的经历中回答问题。

原文4.1：Runbook-R分三个证据池

原始状态池保存网页观察及邻近动作片段，包含界面图文；事件池从连续状态抽取变化；流程笔记池在轨迹层记录可迁移操作经验。自拟例子：原状态保留红色图标长相和订单金额；事件记“订单由待付款变为已付款”；流程记“订单页可筛日期”。三者互补，但经验不能替代具体订单已付款的证据。

原文4.1：问题到来后，控制器选择检索哪一池

控制器看到问题和记忆概览，产生原始状态查询以及事件、笔记查询，可跳过不需要的分支。检索后的多模态证据交给固定reader作答。它并非每次只搜一个向量库，也不是仅靠全文截图；与“短摘要指路＋原始视觉信息补细节”的方向明显重叠。

原文4.2：Runbook-C用文件和代码查历史

直观理解：给一个会查文件的代理准备历史档案和查阅工具，让它替回答模型找证据。 C指coding agent。它使用现成代码代理，主要改造文件组织、查阅流程和输出接口。正文§4.2、附录C.3

任务与replay的区别： 论文评测先插入已经采集好的多条任务轨迹，再提出历史问题。代码代理回看日志和截图，不把环境恢复到旧状态，也不照旧动作再次操作。当前项目关注同一条任务轨迹后续步骤回查此前页面；无论先用录制轨迹回放评测还是后续接入在线执行，都应与其多轨迹问答分开。它是检索机制参考，不是已经验证同任务动作收益的直接基线；机制仍可能迁移到同任务设置。

第一步：每条历史任务存成一个目录

每条轨迹包含任务目标、起始网址、结果、动作及按顺序排列的状态。状态有截图和可访问性树；树由环境提供，不能当成OCR得到的文字。截图也保留，所以底层并未被一个短摘要替代。

附录表10给出的主要路径如下，省略了一些辅助信息：

question.json                         当前问题
INSTRUCTION.md                        查资料的工作流和规则
trajectories/
  TRAJECTORY_SUMMARY_CONCISE.md        简短轨迹目录
  TRAJECTORY_SUMMARY_FULL.md           更详细的轨迹目录
  <trajectory_id>/
    trajectory.json                   本次任务的完整轨迹
    screenshots/                      各状态引用的截图
scripts/inspect_trajectory.py          查看和匹配轨迹内容的脚本
memory_module_output.json             代码代理最终写出的取证结果

这两份目录在查询时准备，提供轨迹级元数据和预览。它们不是我们设想的“每帧由3B生成一条页面概括”。本次查看官方render_trajectory_summary.py：CONCISE列出目标、结果、状态数和URL；FULL列出目标、URL、动作序列与结果，并可从界面树补充动作所指元素。该脚本直接整理已有字段，不调用LLM生成页面概括；不要把原轨迹可能保存的思考与当前脚本实际渲染的字段混为一谈。论文工作流要求从FULL目录筛候选，并未规定必须先CONCISE再FULL。

第二步：先判断问题类型，再挑少数轨迹

取值题要找到明确显示该值的状态；比较题必要时分别找两边证据；流程题优先在同类操作中查找。若问题带图，先看图并匹配对应界面。

然后依据目录中的目标、起始URL、动作序列和最终结果，选少数可能相关的轨迹。目录用于缩小查找范围，选中后还需查看具体状态验证。

第三步：用脚本按位置或文字检查细节

代码代理可以调用现成的inspect_trajectory.py，查看一条轨迹、某个状态、一段状态，或该轨迹里的文字匹配。论文列出的调用形式是：

python scripts/inspect_trajectory.py <trajectory_id>
python scripts/inspect_trajectory.py <trajectory_id> --state <i>
python scripts/inspect_trajectory.py <trajectory_id> --span <i:j>
python scripts/inspect_trajectory.py <trajectory_id> --match "<pattern>"

因此，模型不必凭空记住所有历史，也不必每次重新写一套解析程序。它决定查哪条、匹配什么、还要不要补看；脚本负责定位和展开数据。说明要求优先定点核查少数候选，避免无目的地遍历原始文件；这不是固定取top-k结果的向量检索流程。

第四步：写“证据说明＋状态位置”，交程序取回真实材料

真正输出文件是memory_module_output.json。下面采用论文规定字段，其中内容和编号是自拟示例：

{
  "memory_markdown": "订单金额与运费的证据位于指定商品详情状态。",
  "trajectory_spans": [
    {
      "trajectory_id": "task_012",
      "start_state_index": 7,
      "end_state_index": 8
    }
  ]
}

memory_markdown写简短证据说明、操作提示或反证；trajectory_spans写轨迹编号和状态范围。状态编号从0开始，首尾都包含，所有范围合计最多20个状态；每段通常不超过3个状态是工作流指导，不是每题只能查询3次。

代码代理不把大段界面树或图片复制进这个JSON。运行程序验证输出、过滤无效范围，再将对应的真实状态和截图组成记忆上下文，交给固定reader回答问题。找资料和最后回答是两个分开的职责。

自拟例子：以前那个订单总价是多少

先从轨迹目录挑出相关订单任务；在候选轨迹中匹配订单名、价格或运费；展开命中状态及必要邻近状态，核对金额是否属于同一订单；最后返回金额与运费所在的状态范围。程序把这些界面内容和截图交给reader，reader据此回答。

与当前方案相近的是“目录缩小范围→按内容或位置查明细→返回来源”。区别在于它保存轨迹级原始状态、界面树和截图，我们保存逐帧OCR与图标描述文档；它由专门的代码代理找证据给回答模型，我们让主模型在同任务逐步回放时调用读帧与搜索。它也能精确指定历史状态，不能把固定帧号本身视为新的检索机制。更根本的协议差异是：它查询前已插入完整历史，我们在第t步只能读取已出现的信息，目录也不能使用未来动作或最终结果；详见具体对照。

与Runbook-R、普通Codex基线分别是什么关系

原始状态、事件和流程笔记三池是Runbook-R的组织方式；不能直接说Runbook-C也必须先建这三池。C这里用的是原始轨迹文件、目录、脚本和工作流。

普通Codex基线已经能使用文件系统以及ripgrep、find等工具。Runbook-C加的是专用工作流、轨迹目录预览、定点检查脚本，不是首次给模型一个文件搜索工具。附录C.1/C.3采用现成Codex代理；表2的代码代理控制模型为GPT-5.4-mini，下游reader固定为Qwen3.5-9B。

3. 训练和使用边界

论文主要设计评测和运行时记忆控制，不把reader训练成新的GUI定位器。构建记忆可读取完整历史，查询时调用控制器和reader；测试题的标注支持轨迹只用于评估，不能作为正常查询的检索输入。固定reader能够减少答案模型差异，但记忆控制器仍可能不同。

4. 主表中的重要对照

表2，Qwen3.5-9B作为固定reader，Small/Medium两种历史量：

必须按原文§3.3和表注的memory查询延迟口径理解；这些不是在线GUI任务总时长。Runbook-R比简单RAG准确，却增加查询计算；Runbook-C与代码代理比较时才显示更好的准确率/查询成本。没有一个数支持“加记忆一定更快”。

5. 消融与附录

Small下R完整0.586，去掉原始状态池0.423，去事件池0.556，去笔记池0.579。原始视觉/界面状态并不是可有可无；另一方面，事件信息帮助处理变化，单张相似图不够。附录给轨迹采集工具、领域任务、问题标注、支持轨迹和haystack构建、各基线提示及分类结果。

6. 对拟议方案的作用

当前方案研究同一任务逐步回放时的记忆写入与查询。可以将C的文件查阅流程适配为只访问当前历史前缀的对照，比较逐帧OCR与3B描述文档、页面概括和原始状态的取舍，同时记录信息恢复质量与总成本。主实验不要求跨任务经验、历史裁图检索或学习策略。若下一帧仍由录制轨迹固定给出，结果只能支持相应的信息恢复或单步判断结论；真实任务成功率需另做闭环实验。

7. 来源与核查范围

原文完整表格附件保留本版本可抽取的正文及附录表；正文解释关键比较，不把异构数据集或不同模型拼为统一排行榜。

原论文：章节、图注与来源 / Original paper。章节包括：1 Introduction；2 Related Work；Long-Context and Memory Evaluation；Memory Systems for Agents；Agents as Memory Controllers；3 LongMemEval-V2；3.1 Core Memory Ability Definition；3.2 Annotation；Trajectory Collection；Question Annotation；Answer Trajectory Labeling；Haystack Creation；3.3 Evaluation Formulation；3.4 Pilot Studies；4 AgentRunbook；4.1 AgentRunbook-R；4.2 AgentRunbook-C；5 Experiments；5.1 Main Results；5.2 Accuracy and Latency Trade-off；6 Conclusion；References；Appendix A LongMemEval-V2: Further Benchmark Construction Details；A.1 Trajectory Collection；Domain and task selection.。

2026-09-07补读本地原始HTML缓存的§3.3、§4.2、§5.1、附录A.1、C.1与C.3及表10–11，并核官方在线原文。本次另查看官方仓库的评测调用顺序、C查询控制流程、文件记忆接口及目录生成脚本的相关路径，确认完整轨迹插入、查询、证据组装与reader之间的分工。未运行作者系统，也未通读整个仓库；原论文C与后续C V2更新分开讨论。