GUI Agent会操作，却记不住：MemGUI-Bench揭开长程交互的“记忆盲区”

如果未来的 GUI Agent 要从一次性操作工具走向真正的长期数字协作者，它需要处理的不只是一个页面或一条指令，而是一项持续推进的复杂工作。

在多个软件中收集和核验信息，维护不断变化的任务状态，完成一份可交付的结果；收到反馈后继续修改；下一次面对相似任务时，还能复用此前验证有效的流程，并避开已经出现过的错误路径。

这背后依赖两类相互补充的记忆能力。

短期记忆决定 Agent 能否在一次长程任务中，持续保留关键事实、界面变化、中间结果和子任务进度。

长期记忆则决定 Agent 能否跨越多次尝试和不同会话积累经验：从成功执行中提取可复用的操作模式，从失败中识别错误路径、应用限制和常见陷阱，并据此改善后续决策。

当前 GUI Agent 已经越来越擅长识别界面和执行点击、滑动、输入等操作。但当任务链条被拉长、关键信息离开当前界面，或者后续尝试需要真正利用此前经验时，其表现仍然不够稳定。

问题因此不再只是 “现在应该点击哪里？”，还包括：在当前任务中，我此前做过什么、看到了什么？以及：在过去的任务和尝试中，我学到了什么？

针对这一长期存在的评测缺口，来自浙江大学、南开大学、香港中文大学多媒体实验室、上海交通大学和 vivo AI Lab 的研究团队提出了 MemGUI-Bench，系统评测 GUI Agent 在动态环境中的短期信息保持与跨会话学习能力。

论文共同第一作者为浙江大学博士生刘广义、硕士生赵鹏翔和博士生梁耀臻，浙江大学刘勇教授为通讯作者。该工作已被 ACM Multimedia 2026 接收。

论文地址：

https://arxiv.org/abs/2602.06075

Leaderboard地址：

https://memgui-bench.github.io/

〓 图1. MemGUI-Bench 从记忆分类、任务环境、自动评测到基线实验，构建了一套完整的 GUI Agent 记忆评测体系。 

最新结果

〓 图2. MemGUI-Bench Leaderboard（v260812）前 13 名。

MemGUI-Bench 公开 Leaderboard 已从论文初版的 11 个 Agent 扩展至 26 个系统。最新结果表明，尽管新一代模型取得了明显进步，当前 GUI Agent 的记忆能力仍远未达到稳定可靠的水平。

以 GUI-Owl-1.5-32B-Instruct 为例。该模型在 AndroidWorld 上的成功率达到 69.8%，但在 MemGUI-Bench 上，同为单次尝试口径的 p@1 仅为 10.9%，下降了 58.9 个百分点，表现仅约为前者的六分之一。

即使是能力更强的 Gemini-3.1-Pro-Preview，其成功率也从 AndroidWorld 上的 70.7% 降至 MemGUI-Bench 上的 43.8%，下降 26.9 个百分点。

这说明，更强的基础模型虽然能够缩小差距，但仍难以将常规 GUI 操作能力完整迁移到需要跨步骤信息保持、任务进度追踪和多应用协同的长程场景中。

为什么需要一场专门的“记忆考试”？

多模态大模型已经能够识别界面元素、理解指令，并执行点击、滑动和输入等操作。但“会操作”并不等于“会完成长程任务”。

许多现有 benchmark 的关键信息始终存在于任务指令或当前页面中，Agent 无需精确保留历史。而在真实长程任务中，它必须持续回答两个问题：

以及：

前者对应短期记忆，后者对应长期记忆。

〓 图3. 现有 GUI Agent 记忆机制分析。

短期记忆：在一次任务中保持信息和目标

短期记忆，即 in-session memory，指 Agent 在一次任务中保留动作历史、页面变化、中间结果和任务进度的能力。

例如，一个跨四应用的房源分析任务，需要 Agent 先读取地址和租金，再查询公司位置、计算通勤时间并生成笔记。早期获取的信息必须在应用切换后继续可用。

论文将现有短期记忆实现归纳为五类：

• Memory Agent：使用独立模块整理历史；

• Action-Thought：保留动作及对应推理；

• Multi-turn Context：通过多轮上下文保存历史；

• Rule-based Aggregation：按照固定规则压缩或拼接记录；

• No History：只根据当前界面决策。

长期记忆：从过去的成功和失败中学习

长期记忆，即 cross-session memory，关注 Agent 能否把过去的执行经验转化为可复用知识。

它既包括从成功轨迹中提取快捷流程，也包括分析失败路径和应用限制，避免在后续尝试中重复犯错。

现有 benchmark 在这两类能力上主要存在三个缺口：

• 记忆任务不足。记忆相关任务通常只占 5.2%—11.8%；

• 缺少跨尝试评测。多数基准只检查一次执行结果，不支持 pass@k；

• 长轨迹难以自动评估。规则评测扩展成本高，直接输入完整截图轨迹又容易造成信息过载。

因此，传统 benchmark 更多是在问：

而 MemGUI-Bench 进一步追问：

〓 图4. 现有 GUI Agent 采用了多种短期和长期记忆机制，但此前 benchmark 在记忆任务、多次尝试和记忆专项指标等方面仍存在明显缺口。

MemGUI-Bench：从任务、环境到指标，重新定义“怎么考”

MemGUI-Bench 并非简单延长任务轨迹，而是从任务设计、执行环境和指标体系三个层面构建记忆评测。

任务不只是更长，而是信息依赖更强

MemGUI-Bench 包含 128 个任务、26 个真实应用和 68 类场景。

参考轨迹长度从 3 步到 160 步不等，平均为 36.2 步；78.1% 的任务需要跨应用传递信息。Easy、Medium 和 Hard 任务分别占 37.5%、32.8% 和 29.7%。

〓 图5. MemGUI-Bench 任务长度、难度、应用数量和场景分布。

其中，115 个任务为记忆密集型任务，另外 13 个标准任务用于衡量基础操作能力，以区分“不会操作”和“不会记忆”。

任务要求 Agent 跨步骤保留价格、地址、文本、页面状态和中间计算结果。部分任务长达 160 步，还需要在多个应用间反复传递信息。

此外，128 个任务被组织成 64 组镜像任务对。每组任务具有相似的应用组合和认知流程，但具体目标不同，用于评估经验能否迁移到相关任务。

环境恢复到原点，Agent 的经验可以留下

评测长期记忆时，多次尝试必须面对一致的初始环境，但 Agent 已形成的经验又不能随环境一起清除。

MemGUI-Bench 为此构建了基于 Android Snapshot 的执行框架。

〓 图6. MemGUI-Bench 通过环境快照和多次尝试机制支持短期与长期记忆评测。

每次尝试前，模拟器恢复到预设快照；任务失败后，环境自动重置，但 Agent 的失败总结、经验提示或外部知识库可以继续保留。

默认情况下，每个任务最多执行三次，即采用 pass@3 协议。框架还提供统一接口，并支持多模拟器并行运行。

失败也要区分“差一点”和“完全没记住”

对于记忆任务，成功或失败的二元结果并不足够。

如果任务要求记录九项信息，一个 Agent 写对八项，另一个一项都没记住，两者不应被视为相同水平。

因此，MemGUI-Bench 设计了覆盖短期记忆、长期学习与执行效率的 7 类指标：

• Pass@1：第一次尝试成功率；

• IRR（Information Retention Rate）：正确保留并使用的信息比例；

• MTPR（Memory-Task Proficiency Ratio）：记忆任务相对标准任务的熟练度；

• Pass@k：多次尝试内的成功率；

• FRR（Failure Recovery Rate）：从首次失败中恢复的能力；

• 此外还记录步骤、时间和成本等效率指标。

MemGUI-Bench 不只判断任务是否完成，还进一步测量 Agent 记住了多少、能否从失败中恢复，以及为此付出了多少计算成本。

MemGUI-Eval：长轨迹不能只看最后一张截图

记忆任务的最终页面通常不足以证明任务完成。

例如，Agent 在笔记中写下了一组商品价格，评测器还需要确认这些价格是否与早先看到的页面一致。只看最后一张截图证据不足，但一次性输入几十张截图又容易造成信息过载。

〓 图7. 长程 GUI 任务现有评估方法的局限性。

现有方法主要分为两类：

• 规则式评测器较精确，但每个新应用和任务都可能需要重新编写规则；

• 基于大模型的评测器扩展性更好，但完整长轨迹中包含大量重复和无关截图。

为此，作者提出 MemGUI-Eval，采用三阶段的 Progressive Scrutiny，即渐进式审查。

〓 图8. MemGUI-Eval 先进行低成本初筛，再进入完整语义分析，最后按需请求历史截图，在评测质量和成本之间取得平衡。

第一阶段：用最少证据完成低成本初筛

Triage Judge 只接收任务描述、动作日志和最后三张截图。

只有证据能够明确证明所有要求均已满足时，它才判断成功；否则返回“Uncertain”，进入下一阶段。该阶段不直接判断失败，以避免因证据不足误判复杂轨迹。

〓 图9. MemGUI-Eval 第一阶段案例。

第二阶段：把完整操作过程转化为语义轨迹

若初筛无法得出结论，Step Descriptor 会为每一步生成动作和界面描述。Semantic Judge 再结合任务目标、完整语义轨迹和最后三张截图进行判断。

对于包含多个信息单元的失败任务，IRR Analyzer 会进一步计算 Agent 实际保留的信息比例。

〓 图10. MemGUI-Eval 第二阶段案例。

第三阶段：只回看真正决定成败的历史截图

如果语义轨迹仍不足以判断，Semantic Judge 会返回 required steps，指定需要重新查看的历史截图。

Visual Judge 随后只接收这些定向证据，而不是完整视觉轨迹：

在验证实验中，MemGUI-Eval 的高精度配置在 SPA-Bench 轨迹上达到 99.0% F1；兼顾质量与成本的配置达到 95.9% F1，单条轨迹评测成本约为 0.03 美元。跨应用任务上的 F1 达到 94.1%—100%，明显高于对比评测器。

〓 图11. MemGUI-Eval 第三阶段案例。

六个研究问题，勾勒出 GUI Agent 的真实记忆能力

论文初版系统评测了 11 个代表性 GUI Agent，包括 Agent-S2、M3A、T3A 等 Agentic Workflow，以及 UI-TARS、GUI-Owl、UI-Venus 和 CogAgent 等端到端模型。

所有任务最多执行三次，并由 MemGUI-Eval 统一判定。作者围绕六个研究问题展开分析。

RQ1：当前 GUI Agent 在记忆密集型任务上究竟表现如何？

〓 图12. 主流 GUI Agent 在 MemGUI-Bench 上的表现。

在论文初版中，单次尝试表现最好的 M3A 成功率为 32.8%；Agent-S2 为 27.3%，T3A 为 22.7%。端到端模型的 Pass@1 仅为 0%—6.2%。

即使允许三次尝试，最佳 Pass@3 也只有 49.2%。

〓 图13. 相同 Agent 在 MemGUI-Bench 和 AndroidWorld 上的表现比较。

GUI-Owl-7B 的成功率从 AndroidWorld 的 66.4% 降至 MemGUI-Bench 的 6.2%；UI-Venus-7B 从 49.1% 降至 5.5%；Agent-S2 从 54.3% 降至 27.3%。

多数系统的 MTPR 低于 0.1，说明现有常规 benchmark 可能掩盖了约 4—10 倍的记忆能力差距。基础操作能力和长程记忆能力并不是同一件事。

RQ2：记忆机制究竟是必要条件，还是可选模块？

作者在 MemGUI-Bench-40 子集上对记忆模块进行了消融。

〓 图14. GUI Agent 的记忆能力消融。

移除 M3A 的 Memory Agent 后，其单次成功率从 32.5% 降至 2.5%，IRR 从 35.1% 降为 0。

Agent-S2 同时移除短期和长期记忆后，成功率从 27.5% 降至 5.0%，IRR 同样归零；只移除长期记忆时，Pass@3 则从 45.0% 降至 25.0%。

RQ3：跨应用复杂度会怎样影响记忆？

MemGUI-Bench 包含 28 个单应用任务、56 个双应用任务、34 个三应用任务和 10 个四应用任务。

随着应用数量增加，Agent 需要在更多界面和任务阶段之间保持信息一致。

〓 图15. GUI Agent 在不同应用数量任务上的表现。

领先 Agent 从单应用任务过渡到四应用任务时，成功率下降 16—40 个百分点。Agent-S2 的 Pass@1 从 50.0% 降至 10.0%，大量系统在四应用任务上的成功率直接归零。

真正困难的并非单次界面切换，而是离开一个应用后，Agent 是否仍能保留信息，并知道这些信息接下来应该如何使用。

RQ4：更长的上下文窗口能否解决问题？

标准 M3A 的 Pass@1 为 32.8%。当 Gemini 2.5 Pro 使用完整的 1M token 多轮上下文后，Pass@1 提升至 51.6%，增加 18.8 个百分点；Pass@3 从 47.7% 提升至 68.0%。

长上下文确实能够提升表现，但历史越长，冗余操作、无效探索和过时界面也越多。问题不仅是“上下文够不够长”，还包括“上下文是否被有效管理”。

RQ5：长期记忆能否带来真正的跨会话学习？

〓 图16. GUI Agent 的长期记忆表现。

Agent-S2 从 Pass@1 的 27.3% 提升到 Pass@3 的 49.2%，增加 21.9 个百分点，FRR 达到 21.5%。

多数没有显式长期记忆的系统，FRR 只有 0.8%—4.4%。长期记忆能够帮助 Agent 分析失败并调整策略，但论文初版的 11 个系统中，只有 2 个实现了跨会话长期记忆。

RQ6：更强的记忆能力，需要付出多少计算代价？

〓 图17. 相同 token 和步骤预算下不同 Agent 的表现。

Agent-S2 平均每步消耗约 41760 个 token。在统一 token/episode 预算下，其 Pass@3 从 49.2% 降至 0。

M3A 平均每步消耗约 12960 个 token，相同限制下 Pass@3 从 47.7% 降至 21.9%。轻量模型的 token 消耗更低，但绝对成功率也相对有限。

这表明，部署级 GUI Agent 必须在能力、延迟和成本之间取得平衡：

Agent 到底忘在了哪里，下一步又该往哪里走？

排行榜能够显示 Agent 是否成功，却不能解释它为什么失败。

研究团队使用 MemGUI-Eval 对 1265 次任务执行进行了系统分析。

〓 图18. 失败模式分析。

执行超时占全部失败的 72.3%。在进一步分析的 343 个非超时失败案例中，三类记忆幻觉平均占比达到 58.9%。

第一类：部分记忆幻觉

Agent 获取了部分信息，却在后续步骤中遗漏或错误回忆其他内容。

例如，在计算 NVIDIA 和 Apple 股票持仓价值时，Agent 正确记住 NVIDIA 股价，却把已经看到的 Apple 股价 226.91 美元错误回忆为 143.92 美元。

〓 图19. 部分记忆幻觉示例。

第二类：过程记忆幻觉

Agent 没有忘记某个数字，而是忘记完整任务尚未结束。

在图表分析任务中，Agent 找到目标图表后便提前停止，遗漏了提取数据、打开 Joplin 和创建笔记等后续步骤。

〓 图20. 过程记忆幻觉示例。

第三类：输出记忆幻觉

Agent 已访问全部信息页面，也基本完成任务流程，却在最终输出时漏掉部分内容。

这三类错误分别对应：

论文还区分了两类非纯记忆问题：

• 知识缺陷：Agent 记住了信息，但缺乏应用或操作知识；

• 意图误解：Agent 找到了事实，却错误理解了用户要求的最终动作。

〓 图22. 输出记忆幻觉示例。

从失败模式出发，五条仍待探索的方向

基于实验和失败分析，论文总结了五个方向：

第一，多粒度、结构化的记忆缓冲区。

价格、地址、页面状态和长文本应采用不同的保存方式，而不是全部压缩为同一种摘要。

第二，层级任务分解与持久化目标追踪。

Agent 需要持续记录任务阶段、已完成子目标和下一步计划。

第三，对长上下文进行战略性管理。

长上下文需要配合压缩、去重、重要性判断和按需调用。

第四，建立真正的跨会话长期记忆。

成功和失败轨迹应进一步转化为可检索、可迁移的经验知识。

第五，探索兼顾能力与效率的混合架构。

未来系统需要结合 Agentic Workflow 的记忆能力与端到端模型的执行效率。

这些方向也说明，MemGUI-Bench 更像一个研究起点，而不是问题终点。

一条后续探索：让 Agent 主动决定“记什么、忘什么”

在 MemGUI-Bench 之后，团队围绕长程执行中的上下文膨胀和关键信息丢失进一步提出了 MemGUI-Agent。

其核心方法 Context-as-Action（ConAct）将上下文管理纳入 Agent 的动作策略，让同一个端到端模型同时决定：

• 哪些历史需要压缩；

• 哪些事实必须保留；

• 哪些信息已经可以删除。

团队还构建了包含 2956 条长程轨迹的 MemGUI-3K，并训练了 MemGUI-8B-SFT。

〓 图22. MemGUI-Agent 通过 ConAct 主动压缩历史并保存关键 UI 信息，在控制上下文增长的同时改善长程任务表现。

在论文实验中，MemGUI-Agent-235B 在 MemGUI-Bench 上达到 37.5% Pass@1 和 62.5% Pass@3；MemGUI-8B-SFT 达到 23.4% Pass@1 和 35.9% Pass@3。

这些结果验证了主动上下文管理的潜力，但并不意味着长程 GUI 记忆问题已经解决。小模型如何学习记忆操作、长期经验如何跨任务迁移，以及系统如何兼顾可靠性与成本，仍有大量空间。

MemGUI-Agent 相关资源：

论文地址：

https://arxiv.org/abs/2606.19926

项目主页：

https://memgui-agent.github.io/

结语：衡量一个 Agent，不能只看它会不会点击

过去，GUI Agent benchmark 更多关注：

MemGUI-Bench 则进一步追问：

论文初版揭示了 GUI Agent 在信息保持、跨应用传递、失败恢复和计算成本上的明显短板。持续更新的 Leaderboard 则显示，前沿模型正在快速进步，但不同系统仍分别擅长不同记忆能力。

因此，MemGUI-Bench 的价值不只是让 Agent “考得更难”。

它更像一张持续更新的记忆体检表：帮助研究者看清 Agent 究竟忘在了哪里，也让不同技术路线能够在同一个坐标系中被持续比较。