VenusBench-Mobile:面向真实用户场景的移动 GUI Agent 评测基准及能力诊断框架 VenusBench-Mobile: A Challenging and User-Centric Benchmark for Mobile GUI Agents with Capability Diagnostics
以用户意图驱动 + PUDAM 能力诊断重塑移动 GUI Agent 评测体系
前置知识
Mobile GUI Agent
基于视觉语言模型(VLM)的智能体,通过截屏理解移动应用界面,按自然语言指令逐步输出可执行 GUI 操作(点击、滑动、输入),完成跨应用多步任务。代表系统包括 UI-Venus、AutoGLM、Doubao AI Smartphone。
本文评测的对象就是这类智能体;理解其感知-决策-执行的链式工作流,才能看懂为何需要细粒度能力诊断。
在线评测基准(Online Benchmark)
在可交互仿真环境(如 Android 模拟器)中让 Agent 实时执行序列动作并根据环境状态变化验证成功与否,与静态离线数据集相比更接近真实部署。代表为 AndroidWorld。
VenusBench-Mobile 正是基于该范式构建的在线基准,理解其优势(可复现、闭环反馈)才能体会作者对 App-centric 在线基准的批评。
PUDAM 能力五维
本文提出的诊断框架,将 Agent 能力拆为感知(Perception)、理解(Understanding)、决策(Decision)、动作(Action)、记忆(Memory),每维分 L1-L4 四个递进难度层级。
这是本文的核心贡献之一;它替代单一成功率,把失败归因到具体能力瓶颈,是解读所有实验结论的钥匙。
能力级联失效
指 Agent 在某个能力维度上的不足会向下游决策级联传播,最终表现为任务失败的现象。本文通过 PUDAM 的层级分析揭示了 Perception/Memory 瓶颈如何拖垮整体表现。
理解级联失效机制有助于解释为什么高层决策的微小失误会引发整个任务失败,并指导后续改进方向。
研究动机
现有移动 GUI Agent 在线评测基准(如 AndroidWorld、SPA-Bench、MobileWorld 等)普遍采用「以 App 为中心、自底向上」的构建方式:先挑选 20 个左右 App,再围绕 App 自身功能设计任务。这一范式导致两大缺陷:第一,任务分布过于同质化、局限于单 App 操作,与用户真实使用手机的场景严重脱节。例如用户提出「帮我比价并预订最便宜的酒店」这种跨 App、含模糊意图的任务几乎无法被评估。第二,评测结果只给出粗粒度成功率,无法归因失败原因——当 Agent 失败时,无法判断是视觉感知出错、状态记忆丢失、决策规划失败还是操作执行错误。此外,如 Table 1 所示,AndroidDaily、SPABench 等主流基准甚至缺失 GSA(GUI 状态感知)、GUIM(视觉 GUI 操控)等核心场景。
本文的目标是本文的目标是构建一个用户意图驱动(user-intent-driven)、具有能力诊断能力(capability-oriented)的全新在线评测基准 VenusBench-Mobile,覆盖 10 大类真实用户意图共 149 个主任务 + 80 个稳定性变体任务,覆盖 27 个 App,并通过 PUDAM 五维能力体系对每个任务进行细粒度标注,使评测不仅给出总体成功率,还能定位 Agent 的具体能力瓶颈。
与已有工作不同的是,本文的独特切入角度在于「评测视角的根本性反转」:从「App 能做什么」转向「用户想做什么」,并把评测粒度从「任务级成功」细化为「能力级归因」。具体而言,作者提出 3 个区别于现有工作的设计:(1)首次引入 Vague Instructions、Multi-round Interaction、GUI State Awareness 等 6 类以往基准完全忽视的用户场景;(2)构建 Stability Evaluation 稳定性测试集,引入 Chinese/Variation/Dark/Pad 四种环境扰动;(3)提出 PUDAM 五维能力诊断框架,通过 Dimension-wise Accuracy($Acc_{dim}$)量化每个能力层级的短板。
核心方法
VenusBench-Mobile 的整体方法论围绕「评什么」(what to evaluate)和「怎么评」(how to evaluate)两条主线展开。前者采用自顶向下的用户意图驱动设计,覆盖 10 大类真实移动使用场景;后者采用 PUDAM 五维能力诊断框架,替代单一成功率指标。基础设施上,作者基于 AndroidWorld 框架扩展了 7 个新 App,加入了动态噪声注入(NR 类别)和多轮对话支持(MR 类别),并采用 MLLM-as-a-Judge 与程序化验证相结合的混合验证管线。
本文与已有方法的核心区别是「评测哲学」的转变:现有基准(如 AndroidWorld)以「App 功能完整性」为锚点设计任务,导致评测结果容易被刷分(性能饱和)且无法定位失败原因;VenusBench-Mobile 则以「真实用户意图多样性」为锚点,通过 10 大类任务覆盖真实使用场景中的功能性辅助、冲突消解、模糊指令、多轮交互、动态感知等关键能力,并借助 PUDAM 框架将任务完成度拆解为 P/U/D/A/M 五个能力维度的加权贡献。简单说,传统基准是「Agent 在某个 App 里能不能完成任务」,而 VenusBench-Mobile 是「Agent 在用户真实使用手机的复杂环境下,哪些能力是短板」。
方法步骤详情
VenusBench-Mobile 的构建与评测分四步。第一步任务设计:归纳 10 大类用户意图(FA/CF/VA/MR/GSA/GUIM/HGB/NR/BC/SE),覆盖单 App 辅助到跨 App 浏览、多约束搜索、稳定性测试的完整行为谱系。第二步能力标注:为每个任务标注其在 PUDAM 五维上的最低能力等级(L1-L4),并构造 Figure 5 热力图展示任务分布。第三步基础设施扩展:在 AndroidWorld 基础上新增 7 个开源 App,实现动态噪声注入(NR 类别,模拟来电/闪退)和多轮对话管理(MR 类别)。第四步评测执行:对 9 个主流 Agent 按 Primary SR、$ ext{Acc}_{dim}(d, ext{Tier})=?rac{Y_{d, ext{Tier}}}{X_{d, ext{Tier}}}$、SPR、TT 四个指标交叉分析。
技术新颖性
技术新颖性体现在三个层面。第一是评测视角的范式革新:首次将「用户意图」作为一等公民引入基准设计,明确区分自顶向下(用户视角)与自底向上(App 视角)两种任务构造方法,并通过 Figure 1 直观对比。第二是诊断能力的工程实现:PUDAM 框架的层级化设计(L1-L4 四级递进)与 5 维能力交叉形成 20 个细粒度能力单元,配合 $\text{Acc}_{dim}$ 公式可定位到具体瓶颈维度;这是现有基准(如 AndroidWorld 仅报整体成功率)所不具备的。第三是稳定性测试的系统化:通过 Chinese/Variation/Dark/Pad 四种扰动构造 SPR 指标,要求 Agent 在所有变体上同时成功才能得分,这种「全变体通过」的严苛设计首次系统揭示了 Agent 的脆弱性。
实验结果
实验得到三大核心发现。Finding 1:VenusBench-Mobile 显著提升难度与区分度。如 Table 3 所示,最强 Agent Gemini-3-Pro+UI-Venus-72B 的总体 SR 仅 36.9%,开源模型普遍低于 15%;相比 AndroidWorld 上同类模型 40-70% 的成功率,平均下降约 50 个百分点。新引入的 GSA(均值 2.5%)、GUIM(均值 4.2%)成为最难类别,证明既往基准忽略关键真实场景。Finding 2:PUDAM 揭示能力瓶颈。所有 Agent 在 L3-4 的 Perception 和 Decision 上普遍崩溃到个位数(多数 <5%),Memory 维度的 L3-4 在小模型上接近 0%,证明跨屏信息整合与多轮上下文维护是绝对短板。Finding 3:稳定性极差。Table 4 显示所有 Agent 的 SPR 几乎都为 0%,最强 Gemini-3-Pro 也只有 15%;Tablet(Pad)模式造成最大跌幅,验证 Agent 对垂直手机布局的严重依赖。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| Primary 149 tasks 总体成功率 | Success Rate (%) | Gemini-3-Pro+UI-Venus-72B: 36.9%;GPT-5.1+UI-Venus-72B: 26.9%;UI-Venus-72B: 15.4%;MAI-UI-8B: 12.8%;MA3: 12.1%;UI-Venus-7B: 8.1%;Qwen3-VL-30B: 8.7%;Qwen3-VL-8B/GUI-Owl-7B: 6.7% | AndroidWorld 报告同类 Agent 成功率多在 40-70% 区间 | 整体下降约 50 个百分点,开源模型下降更显著,证明新基准难度显著提升 |
| PUDAM 高难度层级(L3-L4)能力诊断 | Dimension-wise Accuracy (%) | Decision L3-4:开源模型多 <5%;Perception L3-4:开源模型多 <5%;Memory L3-4:UI-Venus-7B 与 GUI-Owl-7B 接近 0% | 传统基准仅报告单一成功率,无法定位瓶颈 | 首次提供五维细粒度诊断,揭示 Memory 为绝对瓶颈 |
| Stability Pass Rate (SPR) 稳定性评测 | SPR (%) | Gemini-3-Pro: 15%;GPT-5.1: 5%;所有开源模型:0% | 现有基准均不要求跨扰动一致通过 | 首次系统量化环境扰动下 Agent 的脆弱性 |
| 推理成本对比 | Total Tokens (TT) / Per-step Tokens (PT) | MA3(GUI-Owl-7B): 1640.0K TT, 438.7 PT;UI-Venus-72B: 850.0K TT, 153.2 PT;GPT-5.1+UI-Venus-72B: 167.5K TT, 54.6 PT | 单 Agent 基线(如 GUI-Owl-7B 单跑:373.7K TT, 146.5 PT) | 首次对比多 Agent 反射循环的开销,发现 MA3 的 token 消耗约为基线的 4.4 倍 |
局限与改进
局限性主要体现在三方面。第一,作者承认 SE(Stability Evaluation)目前只包含 20 个任务 × 4 个变体(Chinese/Variation/Dark/Pad),覆盖仍较有限;Tablet/Pad 等布局扰动构造较为简单,未涉及分辨率、字体、动态 UI 等更细致的变化。第二,PUDAM 框架的 5 维 4 级划分虽然合理,但层级之间的边界在标注时存在一定主观性,例如「跨 3 个页面整合信息」究竟算 M3 还是 M4,作者未提供充分的标注一致性验证。第三,评测仅采用纯视觉端到端(vision-only)设置,未评估带 accessibility tree 或 DOM 等额外输入的 Agent 表现,可能低估了实际部署中混合模态 Agent 的能力。此外,27 个 App 中部分为较冷门的开源应用(如 Markor、Fitbook),与真实用户高频使用的微信、抖音等商业 App 存在生态差距,结论的外推性需要谨慎对待。
独立分析的弱点
独立分析发现几个值得改进的弱点。第一,PUDAM 标注粒度仍然较粗——每个任务只能选一个最低能力等级作为标签,无法刻画同一任务对多维能力的协同需求;改进方向是引入加权多标签标注或能力向量表示。第二,混合验证管线中 MLLM-as-a-Judge 引入了 Judge Model 的不确定性,特别是 GUIM 等视觉判断任务,Judge 模型的偏差会直接影响评测公正性;改进方向是引入多人标注一致性检验或多 Judge 投票机制。第三,SE 稳定性测试的扰动类型过于规整(统一翻译、统一暗色),与真实环境噪声(如部分遮挡、动态弹窗时序变化)差距较大;改进方向是引入对抗式扰动生成或基于真实用户录像的扰动采样。第四,多 Agent 框架 MA3 的高 token 开销被作者揭示但未深入分析根因(如反射循环的触发频率、无效回滚次数),改进方向是配合详细 trace 日志做归因分析。
未来方向
作者在文末 Future Work 中明确提出三个方向:在线学习(Online Learning)、终身助手(Lifelong Assistant)、Agent 模拟用户(Agent-Simulated Users)。基于本文成果可延伸的方向还包括:(1)将 PUDAM 框架扩展为可训练的 Reward Model,用于 RL 阶段针对特定能力维度强化学习,从而把评测工具反向用于能力提升;(2)把 VenusBench-Mobile 与 AndroidWorld、SPA-Bench 等既有基准做元分析,构建跨基准的能力可比坐标系;(3)引入第一人称视频(如用户使用手机录屏)作为更真实的多模态评测输入,弥补静态截屏与真实使用之间的差距;(4)探索「能力修复」型 Agent 设计,例如在 PUDAM 检测到 Memory 瓶颈时自动调用外部记忆模块补足。
复现评估
复现性方面表现良好。作者在 https://github.com/inclusionAI/UI-Venus/tree/VenusBench-Mobile 开源了完整代码与数据,任务定义、App 配置、验证函数均已公布。Benchmark 在标准 AndroidWorld 框架上扩展,依赖开源 Android 模拟器,硬件门槛相对较低(普通 GPU 服务器即可运行开源模型),但闭源模型评估(Gemini-3-Pro、GPT-5.1)依赖 API 调用,会产生实际费用,按作者报告的 Total Tokens(~167.5K-1640K)粗略估算单次完整评测的 API 成本可控。复现难度主要在两方面:(1)Android 模拟器的多机并行启动与稳定性测试需要较长工程调优;(2)部分 App(如 Markor)的中文/英文界面一致性需要在多语言环境下反复验证。建议复现时先在 5-10 个任务的子集上 smoke test,再逐步扩展到全集。
论文图表
概览图展示了 VenusBench-Mobile 的两大核心设计支柱:左侧「评什么」强调自顶向下的用户意图驱动任务设计(10 大类、149 主任务 + 80 环境变体,覆盖 27 个 App);右侧「怎么评」展示能力矩阵(capability matrix),将失败归因到 Perception/Memory/Decision 等具体瓶颈维度。
这是全文最重要的概念图,把「评测什么 + 如何评测」两个核心创新点一次性呈现,帮助读者快速建立对 VenusBench-Mobile 整体设计的认知框架。
左侧柱状图对比多个 Agent 在 VenusBench-Mobile 与 AndroidWorld 上的成功率,VenusBench 普遍低 50 个百分点左右;右侧饼图展示按能力等级(capability level score)衡量的任务难度分布,VenusBench-Mobile 高难度任务占比明显更高。
用可视化数据直观证明 VenusBench-Mobile 比 AndroidWorld 显著更具挑战性,是支撑「Finding 1:显著难度提升」的关键证据。