Qwen-UI-Agent：把 GUI Agent 的战场从模拟器搬到 100 台真机上

移动端 GUI agent 的论文有一个长期存在的错位：模型在 AndroidWorld、MobileWorld 这类沙箱里刷到八九十分，装到一台真手机上跑，成功率立刻掉一大截。原因不神秘——沙箱里的 App 是精简版，界面干净、状态可复位、弹窗被设计者剔除掉了，因为不剔除就没法做可重复评测。可真机上的中文 App 生态恰好相反：超级 App、深层入口、开屏广告、登录过期、权限弹窗、验证码，还有滚轮和日期选择器这类需要闭环调节的控件。

Qwen-UI-Agent（arXiv:2607.28227，阿里 MAI-UI 团队，2026-07-30）没有绕开这个错位，而是把它当成主要工程对象：搭一套 100 台以上物理手机、150 多个 App 的真机运行时，把它同时用于任务设计、轨迹采集、在线强化学习和最终评测。

这张头图值得先看一眼，因为它已经暴露了这篇报告的真实形状：移动端三项大幅领先，桌面端 OSWorld-Verified 排第二，ScreenSpot-Pro 只比 Seed 2.1 Pro 高 0.8 个百分点。这是一篇 mobile-first 的模型报告，“foundation GUI agent” 的招牌在桌面侧撑得比较勉强。

目录

1. 为什么这篇论文值得关注
2. 背景与问题定义
3. 核心思路
4. 方法设计拆解
5. 训练与系统细节
6. 实验结果与结论
7. 对 APP 自动化测试 / Mobile QA 的启发
8. 局限性与点评
9. 总结
10. 参考链接

一、为什么这篇论文值得关注

过去一年，把 GUI agent 往真机上推的尝试不少，小米的 GUI-0 是一例。但多数工作停在”我们在真机上也测了”这一层——租几台设备、跑一批任务、报个数。Qwen-UI-Agent 的不同之处在于，它把真机当成一套需要调度、需要容错、需要区分故障来源的基础设施来做，并且把这套基础设施同时接进了训练回路，而不只是评测末端。

具体到可迁移的部分，有三件事在这篇报告里被讲清楚了，而且和 APP 自动化测试的工程问题高度重合：

• 真机的健康调度。100 台手机跑长时任务，设备会掉线、账号会失效、网络会抖、App 会被风控。论文给的方案是健康感知调度器加动态黑名单，把不健康的 runtime 临时摘出路由。
• 执行失败与环境失败的分离。真机上一条轨迹跑挂了，可能是模型判断错，也可能是弹了验证码。不把这两者分开，成功率这个数字就是噪声。
• 一张真机失败归因表。论文把一个强基线模型在真机上的全部失败轨迹逐条复核，归成六类可观测的行为模式。这六类几乎就是 UI 自动化脚本的经典脆弱点清单。

二、背景与问题定义

论文自己把目标拆成六个转变，其中和技术判断相关的是前四个：从模拟环境到真机执行、从单一域到跨平台工作流、从纯 GUI 动作到 GUI+CLI 混合与批量动作、从短程任务到长程可靠完成。剩下两个（AutoResearch 式的能力获取、从被动执行到主动服务）更接近产品设想。

沙箱和真机的差异，论文的表述是：沙箱无法覆盖演化中的应用状态、权限约束，以及执行时的意外中断。中文移动生态把这个差距进一步放大——超级 App、密集界面、频繁弹窗，这些执行路径在沙箱里复现不出来。

这个判断不是拍脑袋来的。论文在第 4 章做了一个反向验证：把 Qwen 3.7 Plus（一个在各类榜单上都很强的前沿模型）在 MobileWorld-Real 和 AndroidDaily 上的全部失败轨迹拿出来逐条归因。

52.0% 的失败来自”真实场景挑战”——也就是沙箱为了保证可复现而刻意排除掉的那些东西。这个比例本身就是对”沙箱训练够不够”这个问题的回答。

其中 UI 语义误读 24.7% 是单项最大。论文给的典型例子很具体：模型把灰色的 placeholder 提示文字当成用户已经输入的内容，于是反复尝试清空它，而不是直接覆盖输入。做过 Appium 断言的人对这个坑应该很熟——getText() 在很多控件上会把 hint 一起返回。

(f) 物理控件操控这一类（9.1%）也很典型：滚轮、滑块、日期选择器需要”观察当前值 → 调整滑动幅度”的闭环调节，而沙箱里这些值通常是直接文本注入或单次点击设定的。模型于是用固定幅度滑动，在目标两侧来回过冲，永不收敛。

三、核心思路

一句话概括：用真机基础设施填补模拟器缺失的那部分经验分布，同时把动作空间从纯 GUI 扩到 GUI+CLI+API，用批量动作压缩交互轮数。

动作空间的设计比较克制，一共十二个动作：

类别	动作
GUI	click、double_click、long_press、type、open、drag、system_button、wait
CLI	cli_command
API	api_call
交互与控制	ask_user、terminate

ask_user 是这里唯一一个不产生环境变化的动作，用途是补齐缺失信息、或在涉及敏感数据与支付前拿到明确确认。真机场景下这个动作不是可选项——遇到验证码时必须能把控制权交回人手。

四、方法设计拆解

4.1 环境基础设施

沙箱侧有一个值得注意的工程决定：移动沙箱基于 MobileWorld，但底层从 KVM 模拟器换成了 redroid——把 Android 作为容器跑在宿主机内核上，不用 QEMU 也不用嵌套 KVM。这个改动的直接收益是完整的”设备 + 后端”环境可以在普通容器主机上复制，从而支撑到 1 万个隔离沙箱并行。用过 Android 模拟器集群的人应该能理解这个差别有多大——嵌套虚拟化是横向扩展的硬天花板。

4.2 真机运行时

三个设计点：

健康感知调度。 调度器持续跟踪每台设备、每个 App、每个账号、每条网络连接和每块显示区的健康状态。任务进队列时选一个可用执行目标，把资源租给这个任务，出故障时改路由到另一个目标。不健康的设备进动态黑名单，人工检修后才恢复路由。

虚拟屏并行。 借 scrcpy 的虚拟显示机制，一台手机同时承载多个 App session，各占一块独立显示区。运行时控制器把每块虚拟屏绑到对应的 agent session，保证观测送对了 agent、动作打到了对的屏。论文报的收益是：整个真机集群的 rollout 吞吐提高约 20 倍。

User Agent 接管。 专门的 User Agent 负责补齐缺失信息、对敏感与支付操作取得确认、遇到验证码这类必须人工介入的场景把控制权交出去，完成后任务从更新后的环境状态继续。

4.3 GUI+CLI 混合动作空间

桌面环境里，每个动作被派发给 VM 内的轻量执行服务：GUI 动作翻译成原生输入事件，cli_command 在非交互 shell 里直接跑，不需要模型去视觉定位一个终端窗口再往里敲字。stdout、stderr 和退出码作为结构化观测，和动作后截图一起返回。

有几个细节说明作者踩过坑：命令执行有超时预算（给依赖安装这类慢操作留了余量）；非零退出和超时作为错误观测返回而不是直接中断 episode，让模型在同一条轨迹里诊断和恢复；执行过的命令写进 shell history，这样检查终端状态的校验器也能认可 CLI 路径的解法。最后这条尤其务实——很多校验器只认 GUI 留下的痕迹，会把命令行解法误判为失败。

4.4 Agent 驱动的数据飞轮

冷启动阶段用强基础模型分析各领域所需的知识与能力，生成初始任务池和环境上下文，多轮拒绝采样后汇成 SFT 语料。之后开始迭代：失败分析定位模型弱点 → 映射成下一轮的目标 → 指导生成新任务、环境配置和任务专属校验器 → 通过的轨迹进训练语料。

论文对这套东西的自我评价相当诚实，在 limitation 里写了：当前基础模型还没法可靠地管理整个流程，所以这条流水线是 agent 驱动而非全自动，仍需要相当程度的人工监督和纠错。

五、训练与系统细节

5.1 SFT

三个设计里有两个值得记：

领域专家训练 + 模型合并。 移动、桌面、Web、DeepSearch 各训一个专家，每个专家以本领域数据为主、混入受控比例的跨域数据，最后把各专家 checkpoint 合并成统一模型。跨域混合的作用是保留可迁移能力、减少对本域的过拟合。

用”模型已经会做”的数据保能力。 为了不在 GUI 专项训练中把通用推理和 agentic 能力练掉，作者攒了一个覆盖问答、数学、代码、视觉理解、搜索、工具调用的查询池，用起始模型自己采样，只保留验证正确的样本，少量混进 SFT。关键发现是：起始模型能做对的样本，比它做不对的难样本更有效。前者用贴合模型自身输出分布的目标去复习已有能力，后者会把训练推向能力获取，引入相互竞争的优化信号。

滑窗长轨迹训练。 轨迹切成 n=5 步的窗口，步长 4，相邻窗口留一步重叠。重叠那步的 loss 被 mask（前一个窗口已经监督过），但它留在上下文里，保证每个新窗口的第一个被监督动作至少能看到两张截图。当前窗口之前的截图从视觉输入里丢掉，文本历史保留。

5.2 Action RL：修局部动作错误

作者先归纳了六类反复出现的动作错误：相似元素误定位、排序与排名理解错、数量与多目标完整性不足、过早宣告完成、重复动作循环、长尾动作选择失败（该用 open / ask_user / long_press 时退回到 click）。

这些模式的重要性和它们在自然采集轨迹里的频率不成正比——罕见但致命的模式会被常见动作淹没。所以数据构造上做了两件事：从历史轨迹里定位每类失败的起始动作（重复行为用视觉判定器区分无效循环和有目的探索），对历史覆盖不足的模式让 agent 主动去环境里探索、围绕相关界面结构造任务、采新 rollout。

奖励是动作级的结构化设计：

$$r_t = F_t \left( w_{type} C_t + w_{arg} C_t Q_t - \lambda_{sens} S_t - \lambda_{rep} L_t \right)$$

其中 $F_t \in \{0,1\}$ 是格式合法性，$C_t$ 是动作类型正确性，$Q_t$ 用像素距离、词法相似度、标签匹配或 LLM 判定来衡量参数质量，$S_t$ 惩罚错误的敏感动作，$L_t$ 惩罚动作历史里的重复。注意 $Q_t$ 项乘了 $C_t$——动作类型错了，参数质量再高也不给分。

训练中观察到 token 熵下降、推理链逐渐变短，作者加了熵正则并对推理长度设上下界，防止策略坍缩的同时避免无谓啰嗦。

重复动作循环提升 9.5 个百分点，是五项里最大的。这个方法论——不造一个大 benchmark，而是给每类已知失败模式造一个小专项集单独度量——比结果数字本身更值得借鉴。

5.3 Online RL：学长程决策

Action RL 管局部正确，但一个局部看起来合理的动作可能把界面推进一个后续无法完成任务的状态。Online RL 用 GRPO 的一个 GUI 变体优化端到端成功率：对每个任务采 K 条完整轨迹，校验器判定最终环境状态给二值奖励，算组内相对优势。

$$r_i = v_x\left(s_{final}^{(i)}\right) \in \{0, 1\}, \quad \hat{A}_i = \frac{r_i - \bar{r}_x}{\mathrm{Std}(r_1, \dots, r_K) + \epsilon}$$

规模上：约 1 万条经过执行验证的任务—校验器对，1 万个并发沙箱，轨迹超过 100 轮。任务—校验器对的生成本身是三段式的——编码 agent 分析沙箱代码库、蒸馏出可复用的数据注入技能，用这些技能构造跨多个 App 一致的初始环境状态（论文给的例子是”一个准备论文投稿的 CS 博士生”，手机里的邮件、照片、文件、日程、社交记录互相自洽）；再基于这个状态生成不同难度的任务，独立 LLM 判定可行性；最后编码 agent 自主拉起沙箱、注入状态、写任务专属的代码校验器，用多个模型的 rollout 验证校验器，再由 VLM 判定校验器输出和观测证据是否一致。

模型自适应课程是这里的另一个设计。GRPO 下全成功或全失败的任务没有奖励方差，学不到东西；但永久剔除难任务会错过它进入学习前沿的时刻。所以任务分成活跃池和监控池：中等成功率的进活跃池拿全额 rollout 预算，当前解不了的留在监控池小预算观察，一旦开始出现成功 rollout 就升到活跃池；已掌握的任务同样小预算监控，性能回落就重新激活。

Online RL 之后涌现的三个行为变化，比训练配方本身更有信息量：

• 从假定完成到验证完成。 训练前策略常在最后一个状态变更动作之后直接终止，不检查效果。训练后包含至少一次验证动作的轨迹比例增加 14.7%，false-stop 率（自称成功但没过最终校验器的比例）下降 11.2%。
• Bash 当手，GUI 当眼。 训练后 GUI 动作占比升 6%，同时用 GUI 和 Bash 的轨迹比例升 10.6%。在没有任何模态协调目标的情况下，涌现出一个模式：用 Bash 高效执行状态变更，用 GUI 检查效果。“状态变更 Bash 动作 → 只读 GUI 检查”这种执行—验证转移的轨迹占比从 40.2% 升到 52.4%。
• 长程约束保持。 满足指令全部约束的任务比例在 OSWorld 上升 8.6%、BrowseComp-ZH 上升 7.5%。

六、实验结果与结论

6.1 MobileWorld-Real：真机评测集

409 个端到端任务、104 个 App、7 个域（内容消费、生活服务、生产力、电商、系统设置、金融服务、社交通讯），每个任务来自真人贡献者的日常需求。

有一个设计取舍需要点出来：为了让评测可重复，MobileWorld-Real 回避了依赖特定历史订单、购物车状态、银行卡等无法可靠设置或恢复的任务。这提高了结果稳定性，代价是把真机上最难的一类状态耦合任务排除在外了。

AutoJudge 是配套的轨迹级评测器：五个独立 VLM 判定器看同一条轨迹（每个动作对齐其截图），各给一个结果标签加简短理由，多数投票定最终结果。结果分三类——pass、failed、env_error，环境错误单独报告并排除在成功率分母之外。

整体 92.8% 看着不错，但按类拆开就有话说了：env_error 这一类的 class agreement 只有 76.0%——25 条里有 6 条判错。而这一类恰恰决定成功率的分母。后面会展开这点。

6.2 移动端结果

50 步预算下 82.1%，放宽到 100 步升到 85.5%。专用 GUI 模型这一栏的分数（43.9%、39.7%、17.1%）值得单独看一眼——它们在 grounding 榜上都不弱，但在长程跨 App 任务上和通用大模型有代差。这印证了一个反复出现的结论：grounding 精度不等于任务完成能力。

这张表里更有意思的是下半部分：专用 GUI 模型在真机上的崩塌幅度远大于在沙箱上。UI-Venus-1.5-30B-A3B 在 MobileWorld 沙箱是 17.1%，真机 33.0%；GUI-Owl-1.5-32B 沙箱 43.9%，真机 32.4%。而 GELab-Zero-4B 在 MobileWorld-Real 只有 31.3%，AndroidDaily 却有 73.4%——两个真机评测集之间的差距比模型之间的差距还大。这说明”真机 benchmark”本身也不是一个统一口径的东西，AndroidDaily 覆盖的高频日常场景明显更容易。

6.3 桌面与 grounding

OSWorld-v2 这张表把动作模式单列出来，是个有用的对照：用单动作模式的三个模型（MiniMax M3、Kimi K2.6、Qwen 3.7 Plus）步数分别是 326.7、179.3、173.5，partial 分数都在 22% 上下；用批量模式的三个模型步数在 95–136 之间，partial 分数 40%–55%。这和 OSWorld 2.0 原论文的观察一致——批量动作在同等模型下稳定优于单动作。

grounding 这块是实打实的领先，尤其 UI-Vision 的 70.0% 比第二名 Qwen 3.7 Plus 的 68.0% 高 2pp，比其他专用 grounding 模型高一大截（UI-Venus-1.5-30B-A3B 54.7、MAI-UI-32B 47.1）。不过头图里的 ScreenSpot-Pro 81.5% 用的是 zoom-in 口径，no-zoom 是 76.6%——两个口径混着看容易误判差距。

6.4 GUI+CLI 混合执行的实测占比

这张表是轨迹统计而非设计主张，所以更可信。几个读数：

• CLI 出现在 92%–98% 的桌面任务里。混合动作空间不是偶尔用一下的备选，而是主力通道。
• 批量动作平均 3.1 个原语，意味着交互轮数压到约三分之一。这直接对应延迟——每一轮都是一次截图 + 一次模型推理 + 一次环境转移。
• 从 OSWorld-Verified 到 OSWorld-v2，混合 GUI+CLI 批次从 11.0% 升到 20.3%（+9.3pp），GUI-only 批次从 75.8% 降到 64.7%。任务越长越复杂，跨模态协同用得越多。

七、对 APP 自动化测试 / Mobile QA 的启发

这篇报告里最可迁移的东西不是模型，是真机执行基础设施的几个判断。下面按可落地程度排序。

7.1 把 env_error 变成 CI 的一等公民

大多数 APP 自动化测试的 CI 只有两种结果：pass 和 fail。真机上跑，失败原因里很大一部分是设备掉线、账号过期、网络抖动、验证码、后端服务不可用——这些和被测代码无关，混进失败率就让这个指标失去了归因价值。

AutoJudge 的三分类（pass / failed / env_error）加上”环境错误不进成功率分母”这个规则，可以直接搬。落地形态：

• 失败轨迹先过一道环境健康检查（设备在线？账号有效？目标服务可达？页面是否是已知的风控页/验证码页？），命中则打 env_error，不计入回归通过率，直接进维护队列。
• env_error 的比例本身当成基础设施健康度指标单独监控。这个数字涨了，说明该修的是设备池不是用例。
• 注意 AutoJudge 在 env_error 类上只有 76.0% 一致性——判定规则要尽可能确定性，别全指望模型判。设备心跳、HTTP 状态码、logcat 里的特定异常这些硬信号优先。

7.2 健康感知的设备调度与动态黑名单

大部分团队的真机 CI 还是把用例固定绑到设备上，一台手机出问题，绑在它上面的用例全红。论文的做法是资源租约 + 动态路由 + 动态黑名单：任务进队列时才选设备，故障时改路由到别的目标，不健康的设备摘出路由池、人工检修后恢复。

设备、App、账号、网络、显示区分别跟踪健康状态这一点也值得学——账号维度尤其容易被忽略，一个被风控的账号会让所有用到它的用例连续失败，但设备本身是健康的。

7.3 虚拟屏提高单机利用率

Android 的多显示区机制让一台手机同时跑多个 App session，论文报的是集群吞吐约 20 倍提升。对真机 CI 的意义是设备成本可以降一个量级。

需要提醒的是适用边界：这个机制对有前台检测、有屏幕录制限制、或者强依赖真实触控事件的 App 不成立，金融和直播类 App 尤其容易踩。上之前先做一批兼容性摸底。

7.4 六类失败模式当成对抗性回归清单

Table 10 的六类模式，翻译成 APP 自动化测试的用例设计，是一份现成的脆弱点清单：

论文的失败模式	对应的测试场景设计
深层入口探索失败（19.5%）	低频功能的深层路径用例：三级以上菜单、需要先切 Tab 再进二级页的入口
无效动作循环（14.3%）	点击无响应、页面加载失败后的重试与退避逻辑；断言”状态未变化”的检测能力
执行状态丢失（6.5%）	跨 App 跳转、前后台切换、来电/推送打断后回到原流程的状态恢复
UI 语义误读（24.7%）	placeholder 与真实输入的区分、动态刷新列表、预填搜索词
弹窗干扰（18.2%）	开屏广告、付费墙、权限弹窗、验证码、白屏页的恢复路径
物理控件操控（9.1%）	滚轮、滑块、日期选择器的闭环调节精度

第四类值得单独展开。灰色 placeholder 被当成已输入内容这个具体错误，在传统脚本里的等价形态是 getText() 返回 hint 文本导致断言假阳性——Android 上 EditText 的 getText() 和 getHint() 是两个方法，但 uiautomator dump 出来的 text 属性在部分实现里会混。iOS 的 XCUIElement.value 在有 placeholder 时同样会返回 placeholder。这类断言假阳性排查起来很费时，值得在框架层统一封一个”输入框是否真的有内容”的判定。

7.5 「Bash 当手，GUI 当眼」映射到移动端

Online RL 后涌现的这个模式，在移动端有直接对应：用 adb / dumpsys / ContentProvider / 应用 SQLite / logcat 做状态变更与取证，GUI 只做视觉确认。

论文给的量化收益是 false-stop 率下降 11.2%——也就是”自称成功但实际没过校验”的比例。这个指标在自动化测试里就是假阳性通过率，是最伤信任度的一类问题：用例报绿但功能其实坏了。

具体做法：在每个状态变更操作后加一步只读验证，验证渠道优先选屏幕之外的：

• 业务状态：应用 SQLite、SharedPreferences / plist、ContentProvider 查询
• 系统状态：dumpsys activity、dumpsys notification、dumpsys package 权限位
• 网络：抓包或 mock 服务端的请求记录
• 异常：logcat 里的 crash / ANR / 特定 error tag

GUI 截图作为视觉确认的补充，而不是唯一证据。这和昨天 IRA 那篇的 propose-then-verify 思路是一致的，两篇从不同方向指向同一个结论：GUI agent 的 oracle 不应该建在截图上。

7.6 专项错误集而非大 benchmark

Action RL 那套方法论——为六类已知失败模式各造一个小的专项测试集，单独度量、单独优化——比造一个大而全的回归套件更实用。理由很简单：大套件的通过率是个聚合数字，掉了 2% 你不知道掉在哪；专项集直接告诉你是弹窗恢复退化了还是深层导航退化了。

配套的数据构造技巧也可以借：从历史失败轨迹里定位触发失败的那一步动作（而不是整条轨迹），对覆盖不足的模式主动去环境里探索造例。前者能把回归用例的粒度做细，后者解决”罕见但致命”的模式在自然数据里被淹没的问题。

八、局限性与点评

8.1 真正的贡献

第一，把真机从”评测末端”变成了”训练回路的一部分”。 这是和多数”我们也在真机上测了”的工作的根本区别。100 台设备、150 个 App、健康调度、虚拟屏并行、User Agent 接管——这套东西同时服务于任务设计、轨迹采集、在线 RL 和评测。第 4 章那份失败归因是这个投入的直接产物，也是全文信息密度最高的部分。

第二，把环境故障从成功率里剥出来。 三分类判定加上”环境错误不进分母”这个规则，是真机评测能不能重复的关键工程决定。这个做法比它在论文里占的篇幅重要得多。

第三，GUI+CLI 混合执行给出了实测占比而非设计主张。 CLI 出现在 92%–98% 的桌面任务里、批量动作平均 3.1 个原语——这些是从轨迹里统计出来的，可以直接拿来做架构决策的依据。

第四，online RL 后的行为变化被量化了。 false-stop 下降 11.2%、执行—验证转移从 40.2% 升到 52.4%，这两个数字说明”加一步验证动作”是有实测收益的，不是直觉。

8.2 可能被高估的部分

MobileWorld-Real 的 92.2% 是三重自评。 自建真机环境 + 自建 benchmark + 自建评测器，基线模型是通过 harness 接进来在别人的地盘上跑的。92.2% 对 Seed 2.1 Pro 的 88.7%，3.5 个百分点的差距，完全落在 AutoJudge 7.2% 的错误率区间里。论文对此的处理是”对所有系统用同一套 AutoJudge 协议”，这确实保证了一致性，但一致的偏差仍然是偏差——如果 AutoJudge 的判定标准和 Qwen-UI-Agent 的行为风格更契合（比如对某种终止方式更宽容），这个偏差是系统性的。

env_error 类 76.0% 的一致性没有被追问方向性。 这一类决定成功率的分母。把环境错误误判成模型失败会压低分数，反过来会抬高。论文报了整体 92.8%，报了分类 agreement，但没说这些错判在各个被测模型上的分布是否均衡。真机环境的故障率本身可能和模型行为相关——一个探索更激进的模型更容易触发风控和验证码，从而拿到更多 env_error，进而被从分母里移除。这是一个结构性的隐患，值得后续版本量化。

“foundation GUI agent” 在桌面侧撑得不足。 OSWorld-Verified 79.5% 排第二，OSWorld-v2 partial 40.0% 排第三、落后 Opus 4.8 的 54.8% 有 14.8pp。头图上写的 “leading or competitive” 里，“competitive” 承担了不少工作量。这是一篇优秀的 mobile agent 报告，桌面和浏览器更接近”没有明显短板”。

真机 benchmark 已经接近天花板，区分度在下降。 92.2% 和 97.5% 这样的分数意味着剩余空间很小。更能说明问题的是 27B 和 35B-A3B 两个变体的对比：MobileWorld 沙箱上是 82.1 对 65.0，差 17.1pp；MobileWorld-Real 上是 92.2 对 87.4，只差 4.8pp。真机 benchmark 对模型能力的区分度反而低于沙箱。如果拿它当训练信号或选型依据，分辨率是不够的。这一点论文没有讨论，但对想复现的人很关键。

失败归因做的是基线模型，不是自己。 Table 10 归因的对象是 Qwen 3.7 Plus 的失败轨迹。Qwen-UI-Agent 自己剩下那 7.8% 的失败分布是什么样，论文没给。对读者来说，这份归因是”沙箱训练的模型会怎么错”，而不是”真机训练之后还剩什么错”——后者信息量更大。

AutoResearch 的自动化程度打折。 论文在 limitation 里明确写了当前基础模型没法可靠管理全流程，流水线是 agent 驱动而非全自动，仍需大量人工监督。这条自陈很诚实，但和摘要里 “with minimal human effort” 的表述有落差。

ScreenSpot-Pro 的口径。 头图的 81.5% 是 zoom-in 口径，正文表里 no-zoom 是 76.6%。有意思的是 no-zoom 口径下的领先幅度反而更大（76.6 对 Seed 2.1 Pro 的 65.3），zoom-in 口径下只有 0.8pp。对比模型也都用 zoom-in，所以口径是统一的，算不上问题，但读者需要知道有两个数。

8.3 可复现、可落地的建议

直接可搬（成本低、收益明确）：

1. CI 的三分类判定，env_error 不进成功率分母，单独当基础设施健康度指标监控。
2. 设备、App、账号、网络四个维度分别做健康跟踪 + 动态黑名单 + 资源租约式调度。
3. 每个状态变更操作后加一步屏幕外的只读验证（dumpsys / SQLite / ContentProvider / logcat），把假阳性通过率当成核心指标跟踪。
4. Table 10 的六类失败模式做成六个独立的对抗性专项集，分别度量。
5. 框架层封装”输入框是否真的有内容”的判定，规避 placeholder / hint 导致的断言假阳性。

值得评估（有前置条件）：

6. 虚拟屏并行提高单机利用率，上线前先做 App 兼容性摸底（前台检测、录屏限制、真实触控依赖）。
7. redroid 容器化替代 KVM 模拟器——如果你的模拟器集群卡在嵌套虚拟化的扩展天花板上，这个方向值得试。
8. 从失败轨迹里定位”触发失败的那一步”来构造细粒度回归用例。

不建议复现： 100 台真机的规模、1 万并发沙箱、GRPO 长轨迹训练。这些是有基建投入门槛的，中小团队复现方法论比复现规模划算。

九、总结

Qwen-UI-Agent 的价值不在于 92.2% 这个数字，而在于它把”真机执行”从一句口号做成了一套有调度、有容错、有故障归因的系统，并且把这套系统接进了训练回路。第 4 章那份对前沿模型真机失败的逐条归因，以及 GUI+CLI 混合执行的轨迹统计，是全文最耐读的两部分——它们是观测结果，不是设计主张。

需要保持清醒的是评测的自证性质。自建环境、自建 benchmark、自建评测器，三者叠加之后，3.5 个百分点的领先幅度落在评测器自身的误差范围内。更值得留意的是真机 benchmark 的区分度问题：92.2% 和 87.4% 之间只有 4.8pp，而同样两个模型在沙箱上差 17.1pp。真机评测集在验证”能不能用”上是有效的，在区分”哪个更强”上分辨率已经不够。

对做 APP 自动化测试的人来说，这篇报告能拿走的东西比大多数 GUI agent 论文多：三分类判定、健康感知调度、屏幕外取证、六类失败模式的专项集。这些和模型训练无关，是纯工程判断，今天就能用。

十、参考链接

• 论文：Qwen-UI-Agent Technical Report: Toward Next-Generation Real-World Centric Foundation GUI Agents，arXiv:2607.28227
• arXiv 页面：https://arxiv.org/abs/2607.28227
• 项目主页：https://tongyi-mai.github.io/Qwen-UI-Agent
• 前作 MAI-UI：Zhou et al., 2025
• 相关：OSWorld 2.0（arXiv:2606.29537）、MobileWorld（Kong et al., 2026）、AndroidDaily（Sui et al., 2026）
• redroid：https://github.com/remote-android/redroid-doc