OmniGUI：面向全方位多模态智能手机环境的 GUI 智能体基准

首个逐动作步注入图像/音频/视频的全模态手机 GUI 智能体评测基准。

前置知识

GUI Agent

图形用户界面智能体是一类基于大模型的自主系统，能解读手机/桌面/网页的视觉界面并执行点击、滑动、文本输入等原子化操作，从而代替用户完成跨应用任务。其核心能力涵盖屏幕感知、元素定位、长期规划与错误恢复。

本文评测的对象正是 GUI Agent，而 OmniGUI 的所有指标、动作原语与协议设计都围绕这一类系统展开；理解 agent 循环（感知→决策→执行）才能读懂评测为什么采用 teacher-forcing 而非端到端 rollout。

Omni-modal Foundation Model

指能够原生同时处理文本、图像、音频、视频等交错输入的统一基础模型，例如 Gemini 系列、Qwen3-Omni、MiniCPM-o 等，区别于将各模态独立编码再拼接的传统多模态架构。它对时序对齐与同步采样要求较高。

由于尚无专门的 omni-modal GUI 框架，作者把上述模型直接当作 agent 代理；只有理解了 omni 模型能吃原始交错音视频流，才能明白 OmniGUI 协议为什么敢于把 $V_t$、$A_t$ 与 $I_t$ 一并塞进同一 prompt。

Teacher Forcing 评测

在序列决策评测中，每一步把 ground-truth 历史动作（或真实轨迹）喂给模型，只评估当前步的预测。这种做法避免了自回归 rollout 时错误累积导致的级联失败，能够单独衡量感知到决策的能力。

OmniGUI 明确采用 step-level teacher forcing（$H_t = \{a_1, a_2, ..., a_{t-1}\}$ 用真值）；这是后续讨论里区分「单步感知误差」与「端到端恢复能力」的关键。

Normalized Coordinate Action Space

把屏幕坐标统一映射到 $[0,1000] \times [0,1000]$ 的连续空间，而不依赖具体分辨率。这让模型输出能与不同设备的像素位置对齐，也使坐标误差可通过与 UI 元素的 bounding box 相交判定 Exact Match。

Table 2 的动作定义、TAP 类操作的 EM 判定，以及 TM/EM 两个指标的设计都建立在坐标归一化之上；这是阅读结果表中 EM 数值意义的必备前提。

研究动机

现有 GUI 智能体评测基准几乎全部依赖静态截图作为唯一感知输入，包括 AITW（30,378 任务）、GUI-Odyssey、AndroidWorld、Mind2Web、OSWorld、ScreenSpot 等。然而真实手机交互里，瞬时通知音、媒体播放状态、语音助手指令等与「动作发生的瞬间」强耦合的音视频信号，无法仅用一张截图捕捉。少数后续工作（如 MM-Mind2Web、GUI-World、VideoGUI、VideoWebArena）虽然引入了音频转写或任务前视频片段，但它们都把这些模态当作任务前的参考材料，而非逐动作步的同步输入。这导致：(1) 评测无法反映智能体在真实场景中边看、边听、边操作的能力；(2) 当核心决策线索必须从瞬时音效或视频时间轴里取时，模型没有可被衡量的训练/测试信号。

本文的目标是本文目标是构建 OmniGUI——首个「逐动作步」的全模态手机 GUI 评测基准，在每一步同时向智能体喂入静态截图、同步音频流与时间对齐的视频片段，并据此评估其在 709 条专家演示（2,579 个动作步、29 个应用）上的感知—决策—执行能力。具体而言，作者希望同时给出 5 个认知维度与 3 个客观多模态依赖度上的细粒度打分，并借助 TTS vs 文本、Full vs No-Audio / No-Video / No-AV 等消融，系统地暴露当前 omni-modal 模型在动态多模态环境中的具体瓶颈，从而为未来专用 omni-agent 框架的设计提供可复现的经验性参照。

与已有工作不同的是，作者的切入角度区别于以往工作有三点：(1) 在时间维度上，把多模态信号绑定到每个动作步而非仅任务开始；(2) 在标注方法上，基于「客观物理信息可获得性」抽象出 AV-Critical / AV-Supportive / AV-Present 三级多模态依赖度，而不是事后按模型表现分层；(3) 在评测机制上，承认专用 omni-modal agent 框架尚未成熟，转而用「统一 prompt + 标准化 JSON 输出 + 确定性 greedy decoding」把通用 omni 模型当作 agent 代理，从而提供可重复、可对比的基线，并设计模态消融与 TTS 指令替换实验来隔离瓶颈。

核心方法

OmniGUI 把「手机 GUI 交互」形式化为一个序列决策过程：在第 $t$ 步，环境给出一个多模态观测状态 $S_t = (I_t, V_t, A_t, H_t)$，智能体据此预测原子动作 $a_t \in \mathcal{A}$。$I_t$ 是当前高分辨率截图，$V_t$ 是自上一个动作执行结束到 $t$ 时刻的屏幕录制视频片段，$A_t$ 是与 $V_t$ 同步的音频流（含系统音效、媒体声、用户语音），$H_t=\{a_1,\dots,a_{t-1}\}$ 是历史动作轨迹。任务目标 $G$ 由自然语言给出（中文或英文，跟随 app 的原生语言）。整个基准围绕 5 个认知维度组织任务、3 个客观多模态依赖度分层、13 个原子动作空间，并通过 step-level teacher forcing 协议喂真值历史给模型以隔离单步感知能力。

核心创新有三层：第一层是观测定义——首次把「同步音频 + 时间视频 + 静态截图 + 动作历史」四元组作为每一步的强制输入；第二层是客观分层——基于「仅凭静态截图能否解出当前步」这一物理判据，得到三种严格依赖度标签，并量化了 Cohen's $\kappa=0.84$ 的标注一致性；第三层是评测协议——采用统一 prompt + 温度为 0 的 greedy decoding + 11 原子动作 + JSON 输出的标准化推理管线，让不同厂商、不同规模的 omni 模型能在统一接口下直接互比，本质上是把通用多模态大模型当作 agent proxy 的可复现「代理评测」。

方法步骤详情

构建分四步：(1) 10 名 5 年 Android 经验母语用户，按 Localization、Semantic Understanding、Cross-modal Discrimination、Temporal Reasoning、Instant Response 五维在 29 个 app 中构思 709 条任务，中英文各半。(2) 真机 30 FPS 同步录制屏幕视频、内部音频与触摸事件，得到每步时间戳前截图 $I_t$ 与 $[a_{t-1}\!\to\!a_t)$ 区间音视频 $V_t, A_t$。(3) Web 平台将触摸事件形式化为 13 类原语，坐标归一化到 $[0,1000]^2$；再按「仅凭截图能否解出当前步」判据逐集标注 AV-Critical / AV-Supportive / AV-Present。(4) 评测阶段统一 prompt + $\text{temp}=0$、$\text{do\_sample}=\text{False}$、上限 4,096 token，按 TM/EM/SR/GP 四指标逐步打分。

技术新颖性

技术新颖性集中在评测学层面：以往的 GUI 基准（AITW、Mind2Web、VideoWebArena 等）要么没有音视频，要么把音视频当作任务前参考；本文首次把交错多模态输入绑定到每一步，并在 5 维度 × 3 依赖度 × 中英 29 app 的网格里系统化。在方法学上，「客观物理可解性 + 模态消融验证」的双层标注一致性论证，以及「基础 omni 模型代理评测 + 统一 JSON 推理管线」的可复现设置，是相对已有工作的本质区别。在现象学层面，模态消融不仅验证了 AV-Critical 任务抹去音视频后 EM 下降 10.5%（Gemini 3 Pro），更首次定量暴露「无关多模态在 AV-Present 任务上反而使 EM 从 49.9% 跌到 40.8%」的跨模态干扰，以及「TTS 指令 + 环境音频双音频流导致 AV-Critical 任务 EM 普跌 5% 左右」的并发处理瓶颈，这些都是此前 benchmark 没有触及的发现。

**Fig. 1**: Overview of the OmniGUI benchmark framework

**Fig. 2**: Dataset statistics of OmniGUI (applications/language, task dimensions, modality dependency)

实验结果

Table 3 显示 Gemini 3 Pro 综合 EM 66.4% / SR 33.4%，为最强基线；Gemini 3 Flash EM 61.3% 紧随，在 Temporal Reasoning 上反超。开源最强 Qwen3-Omni 综合 EM 仅 32.3%、SR 5.1%；VITA-1.5、MiniCPM-o-4.5、Baichuan-Omni-1.5 SR $\le$ 1.1%。所有模型在 Localization 上 EM 明显高于 Cross-modal 与 Temporal （如 Gemini 3 Pro：76.2% vs 59.1% / 61.0%）。Table 4 消融显示：AV-Critical 抹去音视频后 Gemini 3 Pro EM 跌 9.0%；AV-Present 上 Gemini 2.5 Flash 出现「完整 I+A+V 39.3% < Img Only 48.3%」的跨模态干扰。Table 5 显示 TTS + 环境音频并发时 AV-Critical EM 一致跌 3–6 个百分点，AV-Present 几无变化（∆ ≈ 0.1%）。

**Table 1**: Comparison of OmniGUI with representative GUI agent benchmarks

**Table 2**: Definition of the OmniGUI Action Space

**Table 3**: Comprehensive evaluation results on OmniGUI (Overall + 5 dimensions)

**Table 4**: Modality ablation across dependency levels

**Table 5**: Impact of instruction modality (Text vs. TTS Voice)

查看结构化数据

任务	指标	本文	基线	提升
Overall Step-level Perception-Action (OmniGUI, all 2,579 steps)	EM (Exact Match)	Gemini 3 Pro 66.4%	Qwen3-Omni 32.3%	Pro 比最强开源 +34.1 个百分点
Overall Episode-level Completion (OmniGUI)	SR (Success Rate)	Gemini 3 Pro 33.4%	Gemini 2.5 Flash 12.4%	同厂商代际 +21.0 个百分点，验证 omni 推理能力与 agent 表现的耦合
Localization Dimension (Static Visual Grounding)	EM	Gemini 3 Pro 76.2%	Qwen3-Omni 42.4%	Gemini 3 Pro 在 Localization 上对开源的领先达到 33.8 个百分点
AV-Critical Task under No AV ablation	EM 下降幅度	Gemini 3 Pro -9.0% (57.9%→48.9%)	Gemini 2.5 Flash -7.2% (35.4%→28.2%)	性能退化证明多模态依赖度标注有效
AV-Present Task 跨模态干扰 (Full vs Img Only)	EM 增益 (提供 AV 反下降)	Gemini 2.5 Flash +9.0% EM 上升 (39.3%→48.3%)	Gemini 2.5 Flash 完整 I+A+V 仅 39.3%	无关音视频呈现带来 -9 个百分点干扰
TTS 双音频并发 (AV-Critical)	EM 下降幅度	Gemini 3 Pro -5.3% (57.9%→52.6%)	Qwen3-Omni -2.8% (29.4%→26.6%)	文本→TTS 同时叠加环境音导致 AV-Critical 一致掉点

局限与改进

作者明确承认两点局限：(1) 协议采用离线 step-level teacher forcing（用真值历史 $H_t$ 喂入），优化地隔离了单步感知到决策的能力，但无法评估端到端 rollout 时的错误累积与恢复；这意味着即便 SR=33.4% 的 Gemini 3 Pro，在真实自主交互下可能更低。(2) 评测目标是「与人类专家意图一致」，并非开放式自然语言生成，因此没有考察智能体在面对新任务时的语言创造性。我自己的额外观察包括：(a) 数据集中在 29 个常用 app，主要为消费娱乐与社媒类，可能对系统级设置、企业 app 的覆盖率有限；(b) GPT-4o 被明确排除，理由是其 Chat Completions API 不支持原生交错音视频、Realtime API 不支持确定性 step 评测，因此基准对当前最强的 omni 模型之一存在盲点；(c) 中英双语样本约 1:1，但仅评估了中英文本指令，TTS 实验只覆盖英文合成，对中文语音指令的并发多模态鲁棒性尚未量化。

独立分析的弱点

独立审视，本文存在以下可改进的弱点：(1) teacher-forcing 协议无法评估端到端 rollout 时的错误恢复能力，建议同时给出「全自主 rollout」与「step-level oracle history」两条曲线以分离单步能力与恢复能力。(2) 评测的 8 个模型中 4 个为 Gemini 系列，多样性不足，且 GPT-4o 因 API 不支持原生交错音视频被排除，使最强 closed-source omni 模型的金标准缺失。(3) 数据集仅 709 集 / 2,579 步，规模不到 AITW 的 1%，对智能体泛化能力的统计显著性可能不足。(4) 13 类动作空间未覆盖通知、控制中心、多指手势、语音听写等高频操作。(5) 模态消融只对比「是否存在音视频」，缺少「有视频无音频」等更细粒度分解。

未来方向

作者已展望把评测从离线 step-level 扩展到自主交互 rollout，以考察错误恢复与多步决策能力。基于本文成果，我建议的延伸方向包括：(1) 引入「事件触发」标注（如「音频 pause」「视频播放结束」）作为辅助监督信号，给模型提供弱监督对齐；(2) 探索「分通道路由」机制，让无关 AV 通道在 AV-Present 任务里被显式屏蔽以消除跨模态干扰；(3) 把 OmniGUI 扩展到桌面 / 浏览器 / IoT 控制面板等多平台，构建跨设备 omni-agent 基准；(4) 联合 OCR、ASR、VAD 作为可微前置模块，替代原生 omni 端的端到端感知，可能在长上下文与并发音频场景下更稳健；(5) 引入「指令多模态」自监督，例如只用 TTS 语音给出指令，以验证智能体能否在不依赖 OCR 文本前提下完成多步任务；(6) 探索 RL 微调策略，用 step-level oracle history 作监督信号但 rollout 用模型自身轨迹，缓解 teacher-forcing 与自主能力之间的鸿沟。

复现评估

复现性方面，本文给出较强保障：评测管线标准化到统一 prompt（系统指令 + JSON 单一输出约束）、$\text{temperature}=0$ 的 greedy decoding、最大 4,096 token 输出，作者明示「模型适配仅限 API 级 payload 格式」。数据集 709 条专家演示在 29 个真实 Android app 上以 30 FPS 录制，附录承诺公开数据集、评测管线与基线 prompt，项目页为 omni-gui.github.io。可观察的限制包括：(1) 摘要未声明完整开源协议与代码仓库地址，需访问项目页确认；(2) 真机录制的 app 数据可能涉及第三方版权与隐私审查；(3) 不同 API 厂商对原生交错音视频封装差异大，第三方复现须针对每个模型重新适配时序对齐；(4) greedy decoding 重跑完整 2,579 步 × 8 模型估计达两万美元级 API 成本。

OmniGUI：面向全方位多模态智能手机环境的 GUI 智能体基准 OmniGUI: Benchmarking GUI Agents in Omni-Modal Smartphone Environments