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

Paper: arXiv:2605.12493 Code: xiaowu0162/LongMemEval-V2 Code reference: main @ 8e8b92a3 (2026-05-12)

1. Motivation (研究动机)

现有 long-term memory 评测很难回答一个关键问题：一个 agent 在某个定制化 Web 环境里反复工作后，是否真的学到了像“有经验同事”一样的环境经验。论文指出，许多已有 benchmark 主要覆盖长文档、用户聊天历史、短 trajectory，或者只用下游任务成功率间接评估 memory；这些设置无法单独检查 memory module 是否掌握了 UI affordance、状态变化、常见 workflow、反复出现的 gotcha，以及“这个环境里前提是否成立”。

Figure 1 解读：图中把同一类 ServiceNow / WorkArena 历史轨迹转成多种问题：有的问题问固定页面差异，有的问题问状态从 Assess 到 Closed 后字段如何变化，有的问题问去重 workflow 中哪些字段最关键，还有的问题故意带入另一个环境才成立的前提。它说明 LME-V2 不是简单的 needle-in-haystack，而是在问 agent 是否能把多次交互中学到的环境经验迁移到新的问答场景。

本文要解决的具体问题是：如何构造一个可复现的评测，让 memory system 在插入大量历史 agent trajectories 后，只返回 compact evidence/context，再由固定 reader model 回答问题。这样可以把“记忆是否找对证据”与“agent 是否会规划、点击、执行任务”分离开来。LME-V2 最终包含 451 个手工问题、两个 haystack tier、最多约 498 条 trajectory / 114.8M tokens 的历史上下文，并覆盖 static state recall、dynamic state tracking、workflow knowledge、environment gotchas、premise awareness 五类能力。

这个问题值得研究，因为长期 agent 系统如果每次都重新探索环境，会浪费 token、时间和操作成本；但如果能沉淀环境经验，就能像熟悉内部系统的同事一样复用以前见过的页面结构、流程技巧和失败模式。LME-V2 的价值在于把这种“经验化”能力变成可测量目标，并暴露出当前 RAG / coding-agent memory 的准确率与延迟取舍。

2. Idea (核心思想)

核心 insight：长期 agent memory 不应只被看作“从历史里找相似片段”，而应被看作把大量交互轨迹组织成可查询的环境经验；好的 memory module 要能在问题出现时提供足够证据，让固定 reader 像询问一位有经验同事一样得到答案。

关键创新有两层。第一，LME-V2 用 context gathering formulation 评估 memory：memory system 只能消费历史轨迹并返回 evidence context，最终答案由固定 Qwen3.5-9B reader 给出。第二，论文同时提出两个初始强 baseline：AgentRunbook-R 用结构化 RAG 将 raw states、state transition events、procedure / hint notes 分池索引；AgentRunbook-C 则把轨迹存成文件，把查询时证据收集交给 coding agent，在沙箱里通过 manifest 和 helper script 定位 evidence。

与 LongBench、LongMemEval、Locomo、Needle-in-a-Haystack 等 benchmark 的根本区别是，LME-V2 的历史不是单篇长文本或个人聊天，而是 multimodal web-agent trajectories；问题也不是只考事实回忆，而是考定制化环境中的状态、流程、坑点和错误前提。与普通 RAG baseline 相比，AgentRunbook 的区别在于它显式拆分“可见 UI evidence / 状态转移 / 可复用过程知识”或直接赋予 coding agent 文件系统探索能力，而不是把所有 history 压成同一类向量检索条目。

Figure 2 解读：451 个问题来自 WorkArena-ServiceNow、WebArena-OneStopShop、WebArena-CMS、WebArena-Reddit 四类环境；问题类型混合 static、dynamic、workflow、gotchas 和 abstention，答案格式也覆盖 multiple-choice、short answer、free-form answer。这个分布让 benchmark 同时检验“看到过某个 UI 元素”和“理解一个流程为什么会失败”这两种不同难度的记忆。

Figure 3 解读：左侧显示 oracle evidence 平均只需 1.39 条 trajectory、39.3 个 states、310.8K tokens，但 small / medium haystack 分别扩大到 100 / 498 条 trajectory、2.5K / 14.9K states、25.6M / 114.8M tokens。右侧显示 answer-bearing trajectories 在 haystack 中仍然稀疏；因此任务难点不是 reader 的单次推理长度，而是 memory module 能否从巨大历史中找到稀疏证据。

3. Method (方法)

3.1 LME-V2 的评测对象：五类“有经验同事”记忆

论文把环境经验拆成五类能力：

Static State Recall：记住页面 landmark、layout、模块 affordance，以及不同状态之间细微的 UI 差别。
Dynamic State Tracking：像 environment world model 一样理解 action 如何改变页面、字段、弹窗、流程状态。
Workflow Knowledge：知道定制环境里完成常见任务需要哪些步骤和导航路径。
Environment Gotchas：知道反复出现的失败模式、隐藏限制、容易误点或误解的地方。
Premise Awareness：能识别“在另一个环境成立、但当前环境不成立”的错误前提，并在需要时 abstain。

构造流程分四步：先从 WebArena、WorkArena、WorkArena++ 收集 trajectory；再由人工 annotator 按上述能力写问题；然后标注所有 answer-bearing trajectories；最后组装 shared haystack。最终轨迹池包含 599 条 WebArena trajectory 和 941 条 WorkArena / WorkArena++ trajectory，总成功率 52.0%，平均每条 trajectory 28.1 个 states。为了避免 parametric knowledge 直接答题，作者用 Gemini-3-Pro、GPT-5.2、Grok-4.1-thinking、Claude-Opus-4.6 做人工检查，并要求至少两个强模型答错。

3.2 Context gathering formulation

对每个问题 $q_{i}$ 和 gold answer $y_{i}$ ，memory system 接收一个有序 trajectory haystack $H_{i} = {h_{i, 1}, \dots, h_{i, m_{i}}}$ 。系统只需要实现两个 API：Insert(h) 和 Query(q)。形式上： $M_{i, j} = Insert (M_{i, j - 1}, h_{i, j}), c_{i} = Query (M_{i, m_{i}}, q_{i})$ 固定 reader model $R$ 再从问题和截断后的 memory context 中输出答案： $\overset{y}{^}_{i} = R (q_{i}, Trunc (c_{i}))$ 这种设计的直觉是：如果 reader 固定，那么不同 memory module 的差异主要体现在它们是否把足够、正确、紧凑的证据放进 $c_{i}$ 。因此 LME-V2 不把浏览器执行、task planning 和 answer generation 混在一起，而是直接评估 memory 作为“证据收集层”的质量。Accuracy 用结构化答案的 normalized string matching 和 free-form / abstention / gotchas 的 LLM judge 计算；同时报告 query latency。

3.3 AgentRunbook 总体框架

Figure 5 解读：左半部分是 AgentRunbook-R：插入 trajectory 时生成 raw state、event、note 三类 memory pools，查询时由 LLM controller 生成多路 query，再从各池检索证据。右半部分是 AgentRunbook-C：插入时把 trajectory、截图和摘要文件写入文件系统；查询时给 coding agent 一个沙箱、问题、workflow instruction、manifest 和 helper script，让它像程序员查文件一样找出 evidence spans。

论文的 intuition 是：agent history 中的信息粒度并不统一。一个静态 UI 字段可能要靠 screenshot / AXTree 片段回答；一个 dynamic 问题需要比较前后 state；一个 workflow 或 gotcha 可能只需要 procedure note。AgentRunbook-R 通过专门 memory pool 避免“所有 evidence 都进一个向量库”的粒度混淆。AgentRunbook-C 则利用 coding agent 擅长文件搜索、脚本调用、局部读取和验证的能力，把 memory retrieval 变成受约束的 evidence-gathering 程序。

3.4 AgentRunbook-R：三池结构化 RAG

插入阶段，AgentRunbook-R 对每条 trajectory 生成四类条目：

Raw state slice pool：每个 state 产生一个 radius-1 local window，包含局部 UI observation、相邻 action、完整 task goal、局部 action sequence 和中心 state screenshot。它负责回答具体 UI / text / image evidence。
State transition event pool：每个相邻 state transition 由 controller LLM 从 pre-state、post-state 和 action trace 中生成一个简短 event，描述 action 造成的页面变化。它负责 dynamic tracking。
Procedure note pool：每条 trajectory 生成一个 procedure note，总结可复用 workflow。
Hint note pool：每条 trajectory 生成一个 hint note，记录 durable UI facts、gotchas、disambiguation rules。

查询阶段，Qwen3.5-9B controller 根据问题和当前 memory summary 生成 JSON query bundle：raw_state_queries 最多 5 条，event_query 一条，note_query 一条。系统分别用 Qwen3-Embedding-8B 做 dense retrieval：raw state 每条 query 取 top-6 后按预算合并，event 取 top-6，procedure / hint notes 各取 top-3。最终 context 先渲染 notes，再渲染 events，最后渲染 raw state slices，并保留可用截图。

class AgentRunbookRMemory:
    def insert(self, trajectory):
        prepared = prepare_trajectory_insert(trajectory)
        raw_state_entries = build_radius_one_state_slices(prepared.states)
        event_entries = [
            controller_llm_json(EVENT_PROMPT, pre_state=s0, post_state=s1, action=a)
            for s0, a, s1 in adjacent_transitions(prepared)
        ]
        procedure_note, hint_note = controller_llm_json(NOTE_PROMPT, trajectory=prepared)
 
        self.raw_state_pool.extend(raw_state_entries)
        self.event_pool.extend(event_entries)
        self.procedure_pool.append(procedure_note)
        self.hint_pool.append(hint_note)
 
        self.raw_state_embeddings.append(embed([x["slice_axtree_text"] for x in raw_state_entries]))
        self.event_embeddings.append(embed([x["description"] for x in event_entries]))
        self.procedure_embeddings.append(embed([procedure_note["note_text"]]))
        self.hint_embeddings.append(embed([hint_note["note_text"]]))
 
    def query(self, question, question_image=None):
        bundle = controller_llm_json(
            QUERY_PROMPT,
            question=question,
            memory_summary=self.render_runtime_query_summary(),
        )
        raw_blocks = [
            search(self.raw_state_pool, self.raw_state_embeddings, q, top_k=6)
            for q in bundle["raw_state_queries"][:5]
        ]
        raw_results = merge_without_duplicates(raw_blocks, budget=6, per_query_cap=2)
        event_results = search(self.event_pool, self.event_embeddings, bundle["event_query"], top_k=6)
        procedure_results = search(self.procedure_pool, self.procedure_embeddings, bundle["note_query"], top_k=3)
        hint_results = search(self.hint_pool, self.hint_embeddings, bundle["note_query"], top_k=3)
        return render_context(notes=procedure_results + hint_results, events=event_results, states=raw_results)

3.5 AgentRunbook-C：文件化 trajectory + coding-agent 检索

AgentRunbook-C 的插入阶段不把轨迹压缩成 embedding pool，而是把每条 trajectory materialize 到 workspace：trajectory JSON、screenshots、procedure notes、concise / full manifest 等都以普通文件存在。查询时，系统创建 isolated sandbox，写入 question.json、INSTRUCTION.md，把 trajectories/ symlink 进去，并复制 scripts/inspect_trajectory.py。coding agent 被明确要求“不是最终答题模型，而是 memory retrieval module”。它必须输出 memory_module_output.json：

{
  "memory_markdown": "## Support Analysis\n...\n\n## Relevant Procedure and Hint Notes\n...",
  "trajectory_spans": [
    {"trajectory_id": "...", "start_state_index": 0, "end_state_index": 0}
  ]
}

trajectory_spans 使用 zero-based inclusive index，总 span budget 为 20 states。系统会验证 JSON、过滤非法 spans，把选中的 states 和 screenshots 渲染成 memory context，再交给固定 reader。相对于直接给 Codex 一个文件夹，AgentRunbook-C 的关键 scaffold 是：workflow instruction 限定角色和输出 schema；manifest artifacts 帮它先 shortlist 可能相关 trajectory；helper script 支持“看一条 trajectory / 一个 state / 一段 states / 在某条 trajectory 中文本匹配”等常用操作，从而减少盲目 find / rg / ad-hoc scan。

class AgentRunbookCMemory(CodexMemory):
    def insert(self, trajectory):
        trajectory_dir = self.workspace / "trajectories" / trajectory["id"]
        materialize_trajectory_json_and_screenshots(trajectory, trajectory_dir)
 
    def query(self, question, question_image=None):
        attempt_dir = next_attempt_dir(question_id=question.id)
        sandbox = attempt_dir / "sandbox"
        write_json(sandbox / "question.json", build_question_payload(question, question_image))
        write_text(sandbox / "INSTRUCTION.md", AGENTRUNBOOK_C_INSTRUCTION)
        ensure_trajectory_summaries(
            concise="TRAJECTORY_SUMMARY_CONCISE.md",
            full="TRAJECTORY_SUMMARY_FULL.md",
        )
        symlink(self.workspace / "trajectories", sandbox / "trajectories")
        copy_file("inspect_trajectory.py", sandbox / "scripts" / "inspect_trajectory.py")
 
        run_codex_exec(
            cwd=sandbox,
            model="gpt-5.4-mini",
            reasoning_effort="xhigh",
            timeout_seconds=1800,
            prompt=AGENTRUNBOOK_C_QUERY_PROMPT,
        )
        payload = validate_json(sandbox / "memory_module_output.json")
        spans = filter_valid_spans(payload["trajectory_spans"], max_total_states=20)
        return render_memory_context(payload["memory_markdown"], spans)

3.6 代码锚点与 paper-code 对齐

Code reference: main @ 8e8b92a3 (2026-05-12) — pseudocode and mapping based on this commit

Paper Concept	Source File	Key Class/Function
Memory backend API: `Insert` / `Query` / context items	`memory_modules/memory.py`	`Memory`, `register_memory`, `build_memory`
Evaluation runner and actual config defaults	`evaluation/run_eval.py`	`build_memory_config`, CLI args for reader/controller/embedding/Codex
Harness that inserts haystack, queries memory, calls reader, records metrics	`evaluation/harness.py`	main evaluation loop, per-question outputs, reader prompt construction
Baseline RAG pools	`memory_modules/rag.py`	`RagMemory.insert`, `RagMemory.query`
AgentRunbook-R structured pools	`memory_modules/agentrunbook_r.py`	`AgentRunbookR.insert`, `_generate_structured_query_bundle`, `_search_*`
Coding-agent baseline and output validation	`memory_modules/codex.py`	`CodexMemory`, `validate_memory_module_output_payload`, `_run_query_attempt`
AgentRunbook-C scaffold	`memory_modules/agentrunbook_c.py`	`AgentRunbookC`, `_ensure_trajectory_summary`, `_populate_sandbox_scripts`
Trajectory materialization and screenshot linking	`memory_modules/trajectory_store.py`	`prepare_trajectory_insert`, `materialize_prepared_trajectory`
Public data preparation	`data/download_data.py`, `data/prepare_data.py`, `data/public_data.py`	dataset download / runtime haystack materialization
Leaderboard packaging and latency-aware scoring	`leaderboard/compute_lafs.py`, `leaderboard/build_submission_step_*.py`	LAFS / submission validation

论文公式与 released code 实现差异：本次检查没有发现会改变主结论的显式冲突；代码实现基本对应论文中的 context gathering API、AgentRunbook-R 三池检索、AgentRunbook-C 沙箱检索。需要注意的是，AgentRunbookC._build_question_payload 在写 question.json 前会移除 question_id 和 question_type，这是减少 query-time agent 泄漏 benchmark metadata 的实现选择；论文正文未展开这一细节。

4. Experimental Setup (实验设置)

数据集与规模

LME-V2 来自 WebArena、WorkArena、WorkArena++ 的 OneStopShop、CMS、Reddit、ServiceNow 环境。最终问题数为 451：WorkArena-ServiceNow 211 个、WebArena-OneStopShop 66 个、WebArena-CMS 83 个、WebArena-Reddit 91 个。问题类型包括 Static 134、Static abstention 55、Dynamic 41、Dynamic abstention 32、Workflow 86、Workflow abstention 29、Gotchas 74；答案格式包括 multiple-choice 156、short answer 226、free-form answer 69。

历史轨迹池包含 599 条 WebArena trajectories 和 941 条 WorkArena / WorkArena++ trajectories，整体成功率 52.0%，平均每条 28.1 states。评测使用两个 tier：LME-V2-Small 每题共享 100 条 trajectories，平均 2.5K states / 25.6M tokens；LME-V2-Medium 每题约 498 条 trajectories，平均 14.9K states / 114.8M tokens。作为对照，oracle answer evidence 平均只含 1.39 条 trajectories、39.3 states、310.8K tokens。

Baselines 与 ablations

比较方法分三组：

No retrieval：不返回 memory context，检验 reader 是否能靠问题本身回答。
RAG family：RAG: query → slice；RAG: query → slice + notes；AgentRunbook-R；以及去掉 raw slice pool、event pool、note pool 的 ablation。
Coding-agent family：vanilla Codex；AgentRunbook-C；以及去掉 workflow instruction、manifest artifacts、helper functions 的 ablation。

Figure 4 解读：无 context 的 frontier LLM 在非 abstention 问题上最高也只有约 14.1% accuracy；而 oracle trajectories、oracle slices + notes、Codex oracle trajectory files 能显著提高直接 QA。这说明 benchmark 不是靠常识或模型参数就能解决，而是真的需要从历史轨迹中取证。

指标与实际配置

主指标是 answer accuracy 和 query latency。Accuracy 对结构化答案使用 normalized string matching；对 free-form、abstention、gotchas 等更语义化的答案使用 LLM judge。Latency 记录 memory query 过程，不把固定 reader 的答案生成混入 memory module 的证据收集能力。

实际配置来自 released code 和论文 Appendix C：evaluation/run_eval.py 将 reader 设为 Qwen/Qwen3.5-9B，默认 temperature=0.6、top_p=0.95、top_k=20、max_completion_tokens=20000、CLI 参数 --memory-context-max-tokens / 字段 memory_context_max_tokens=200000，reader thinking 默认启用。RAG / AgentRunbook-R 使用同一个 Qwen/Qwen3.5-9B controller 和 Qwen/Qwen3-Embedding-8B embedding model；memory_modules/agentrunbook_r.py 与 evaluation/run_eval.py 中的实际检索配置为 raw-state slice radius 1、max_raw_state_queries=5、raw-state top-6、event top-6、procedure / hint notes 各 top-3、raw-state merge budget 6、per-query cap 2、默认不启用 rerank。Coding-agent methods 在 memory_modules/codex.py / memory_modules/agentrunbook_c.py 中使用 gpt-5.4-mini、xhigh reasoning effort、timeout 1800 秒、最多 3 次 attempt，输出 span 总预算 20 states。论文说明 embedding 和 generation models 通过 vLLM 在本地 Nvidia A100 GPU 机器上服务，但未详细说明 GPU 数量。

5. Experimental Results (实验结果)

主结果：AgentRunbook-C accuracy 最高，AgentRunbook-R 是 RAG family 最强

Method	Small Overall	Small Latency	Medium Overall	Medium Latency
No retrieval	0.013	0s	0.013	0s
RAG: query → slice	0.428	0.1s	0.381	0.1s
RAG: query → slice + notes	0.510	0.2s	0.459	0.3s
AgentRunbook-R	0.586	26.9s	0.570	25.8s
Codex	0.699	177.2s	0.687	185.8s
AgentRunbook-C	0.749	108.3s	0.701	139.9s

AgentRunbook-R 相比最强 simple RAG baseline（query → slice + notes）在 Small 上从 0.510 提升到 0.586，在 Medium 上从 0.459 提升到 0.570。AgentRunbook-C 是全表最高：Small 0.749、Medium 0.701，平均为 72.5%；它超过 vanilla Codex 的 0.699 / 0.687，同时 latency 更低（Small 108.3s vs 177.2s；Medium 139.9s vs 185.8s）。

Figure 6 解读：图中横轴是 query latency，纵轴是 accuracy。RAG 系列延迟很低但准确率上限明显；coding-agent 系列准确率更高但成本更大。AgentRunbook-C 相比直接 Codex 把点推向更好的 Pareto frontier：它仍然慢于普通 RAG，但在相近或更低 latency 下比 vanilla coding agent 更准。

分能力结果与 ablation

AgentRunbook-R 的能力分布显示，raw slice pool 对 static 问题很关键：去掉 raw slice 后 Small static 从 0.661 降到 0.286，Medium static 从 0.630 降到 0.233。去掉 event pool 会伤害 static、dynamic、gotchas（例如 Medium overall 从 0.570 降到 0.484）；去掉 note pool 对 workflow 更明显（Small workflow 从 0.528 降到 0.481，Medium workflow 从 0.472 降到 0.396）。这支持论文的三池设计：不同问题需要不同粒度的 memory。

AgentRunbook-C ablation 中，去掉 workflow instruction 后 Small overall 从 0.749 降到 0.701，Medium 从 0.701 降到 0.641，说明“把 coding agent 约束成 memory module”本身很重要。去掉 manifest artifacts 对 accuracy 影响较小但 latency 明显变差：Small latency 从 108.3s 变成 155.0s，Medium 从 139.9s 变成 211.6s。去掉 helper functions 后 Small overall 降到 0.714，但 Medium overall 反而到 0.718；论文因此认为 helper 对性能影响 mixed，但总体能减少昂贵 ablation 的延迟。

Figure 7 解读：错误分解把 incorrect answers 分成 major / minor retrieval miss、reading error、gotcha reading、premise / abstention 等类别。AgentRunbook-R 相比 RAG + notes 减少 retrieval 和 reading 错误，但对 abstention 的帮助有限；AgentRunbook-C 和 Codex 进一步减少 retrieval miss，而 AgentRunbook-C 因为 prompt 明确要求识别前提冲突，在 premise awareness 上更有优势。

Tool-calling 行为：scaffold 让 coding agent 少做盲搜

Figure 8 解读：作者把 coding agent 的 shell commands 分成 setup/read task、harness-guided retrieval、raw trajectory exploration、visual inspection、output/other。AgentRunbook-C 把更多命令转移到 manifest / helper script 引导的检索中，而不是让 Codex 直接在 raw trajectory 文件中大范围搜索。

Figure 9 解读：前 8 轮命令中，两个方法都会先读任务和环境，但 AgentRunbook-C 很快进入 harness-guided retrieval；Codex 则在后续 early rounds 中更常退回 raw trajectory exploration。论文给出的 Medium 统计是：Codex 平均每题 21.8 个 raw trajectory-exploration commands；AgentRunbook-C 平均每题 18.0 个 harness-guided retrieval commands，且只有 1.2 个 raw trajectory exploration commands。

限制与结论

作者明确列出几个限制：LME-V2 只覆盖 customized browser environments，不代表 coding agents、computer-use agents 或其他 enterprise agents 的全部 memory 需求；评测使用 pre-collected trajectories，而不是在线执行中持续学习；context gathering 只衡量 memory module 能否给固定 reader 返回证据，不直接衡量端到端任务成功率；AgentRunbook 本身是 retrieval、file organization 和 coding-agent evidence inspection 的实践性设计，不是新模型架构或训练方法，性能依赖 trajectory representation、retrieval model、prompts 和 coding agent 行为。

总体结论是：LME-V2 把“长期 agent memory 是否形成环境经验”变成了一个可复现、可量化、超长上下文且 multimodal 的评测；AgentRunbook-R 证明结构化 memory pools 比简单 RAG 更好，AgentRunbook-C 证明 coding agent 可以作为强 memory controller，但仍有明显 latency 成本。后续研究空间在于更低延迟的 evidence gathering、更稳健的 premise awareness、更安全的 persistent memory，以及把 memory、planning、execution 更紧密地集成起来。

Paper Notes

探索

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

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

1. Motivation (研究动机)

2. Idea (核心思想)

3. Method (方法)

3.1 LME-V2 的评测对象：五类“有经验同事”记忆

3.2 Context gathering formulation

3.3 AgentRunbook 总体框架

3.4 AgentRunbook-R：三池结构化 RAG

3.5 AgentRunbook-C：文件化 trajectory + coding-agent 检索

3.6 代码锚点与 paper-code 对齐

4. Experimental Setup (实验设置)

数据集与规模

Baselines 与 ablations

指标与实际配置

5. Experimental Results (实验结果)

主结果：AgentRunbook-C accuracy 最高，AgentRunbook-R 是 RAG family 最强

分能力结果与 ablation

Tool-calling 行为：scaffold 让 coding agent 少做盲搜

限制与结论

目录