论文解读：MAI-UI — 面向真实场景的 GUI Agent

基本信息

• 论文标题： MAI-UI Technical Report: Real-World Centric Foundation GUI Agents
• 作者： Hanzhang Zhou, Xu Zhang, Panrong Tong, Jianan Zhang, Liangyu Chen, Quyu Kong, Chenglin Cai, Chen Liu, Yue Wang, Jingren Zhou, Steven Hoi
• 机构： Tongyi Lab, Alibaba Group
• 链接： https://arxiv.org/abs/2512.22047
• GitHub： https://github.com/Tongyi-MAI/MAI-UI
• 骨干模型： Qwen3-VL（2B / 8B / 32B / 235B-A22B 全尺寸家族）

一、论文核心立意：四个关键挑战

MAI-UI 论文的立意非常清晰——当前 GUI Agent 在真实落地时面临四个关键挑战，这四个挑战构成了整篇论文的骨架，每个技术模块都在回应其中一个或多个挑战。

挑战 1：缺乏 Agent-User 交互能力

问题描述： 现有 GUI Agent 的训练范式假设用户指令是完整且清晰的——模型接收指令后端到端执行，不需要与用户交互。但在真实场景中，用户指令往往是模糊的、不完整的、甚至有歧义的。例如：

• “帮我订个酒店”——什么城市？什么日期？什么价位？
• “把这个发给小明”——发微信还是发邮件？发文件还是链接？
• “帮我退掉那个订单”——哪个订单？

没有追问能力的 Agent 只能"猜"或者直接失败。这不是能力问题，是交互范式的缺失。

MAI-UI 的方案：

• 扩展 Action Space，新增 ask_user 动作
• 构造专门的训练数据：故意省略关键信息的任务 + 合成用户 Agent 回复
• 让模型学会三件事：（1）识别何时信息不足；（2）精准追问缺失信息；（3）根据用户回复继续执行

深度分析： 这个挑战的本质是把 GUI Agent 从"执行器"升级为"协作者"。传统 Agent 模型是单向的（指令→执行），而真实场景中用户和 Agent 之间应该是双向对话。MAI-UI 通过在 Action Space 中增加 ask_user，用最小的架构改动实现了这个范式转换。

但也有局限：训练数据中的"合成用户"是 LLM 模拟的，和真实用户的表达习惯、耐心程度、模糊度可能有分布差异。未来可能需要真实用户交互数据来进一步校准。

挑战 2：纯 UI 操作的局限性

问题描述： 当前 GUI Agent 的操作全部限制在 UI 层面（点击、滑动、输入等），这有两个根本性问题：

1. 操作链条冗长且脆弱： 完成一个任务可能需要 10-20 步 UI 操作，每一步的错误都会累积传播。即使单步准确率 95%，20 步下来任务成功率只有 36%。
2. 能力天花板： 有些任务在 UI 层面根本无法完成。比如在手机上操作 GitHub 仓库、批量处理数据、跨应用调用 API——这些任务 UI 上没有对应的操作入口。

MAI-UI 的方案：

• 集成 MCP (Model Context Protocol) 工具调用，新增 mcp_call 动作
• MCP 工具可以将冗长的 UI 操作压缩为一两个 API 调用
• 例如：在手机上通过 MCP 调用高德地图 API 查路线，而非手动打开 APP → 输入地址 → 选择方案

深度分析： 这本质上是在问一个更深的问题：GUI Agent 的操作边界应该在哪里？

纯 UI 操作是一种"模拟人类"的路径——看到什么就操作什么。但人类自己也不是完全靠 UI 完成所有任务的，程序员写脚本、用 API、用快捷键，本质上都是在绕过 UI 层。MAI-UI 的 MCP 集成相当于给 Agent 一个"程序员的工具箱"，让它在合适的时候绕过 UI 直接调 API。

这个思路和 Step-GUI 的 GUI-MCP 有异曲同工之妙，但两者角度不同：MAI-UI 把 MCP 工具作为 Action Space 的扩展（模型自己决定何时调用），而 Step-GUI 的 GUI-MCP 更强调标准化协议和跨平台兼容。

挑战 3：缺乏端云协同部署架构

问题描述： 当前 GUI Agent 的部署只有两种极端选择：

• 纯端侧： 轻量模型（2B-8B），能力有限，遇到复杂任务束手无策
• 纯云端： 大模型（32B+），能力强但有三大问题：
  • 隐私风险（截图包含银行余额、聊天记录等敏感信息需要上传）
  • 成本高（每次操作都要调大模型 API）
  • 网络依赖（断网 = 瘫痪）

没有一个原生支持端云协同的架构来做智能路由。

MAI-UI 的方案 —— 三组件端云协同系统：

组件 1：Local Agent（端侧，身兼二职）

• 执行者角色： 作为 GUI Agent 正常执行任务
• 监控者角色： 每隔几步检查轨迹是否偏离用户指令
• 四种偏离检测：动作失败 / 重复无进展 / 输入错误 / 任务偏离
• 关键：监控能力是显式训练的，不是靠 prompt engineering

组件 2：Cloud Agent**（云端）**

• 仅在满足两个条件时才被调用：（1）Local Agent 检测到偏离；（2）当前上下文不涉及隐私数据
• 接收 Local Agent 生成的 error summary → 利用更强能力修正轨迹

组件 3：Local Unified Trajectory Memory（统一轨迹记忆）

• 端侧维护：任务指令 + 完整历史截图 + 所有模型输出
• 支持端云模型在任意时刻无缝切换，任一模型都能从当前状态继续执行

深度分析： 这个架构的核心洞察是：端侧模型不应该只是云端的"阉割版"，而应该有自己的独特能力——轨迹监控。

传统端云协同的思路是"能力分层"——简单任务端侧做，复杂任务上云。MAI-UI 更进一步：端侧模型既是执行者又是监控者，它能判断自己什么时候搞砸了、生成错误摘要帮助云端恢复。这比简单的能力分层高级得多。

效果数据：端侧性能提升 33%，云端调用减少 40%+。这说明大部分场景下端侧模型加了监控能力后就够用了，真正需要云端兜底的场景并不多。

挑战 4：对动态环境的脆弱性

问题描述： 当前 GUI Agent 的训练数据几乎全部来自静态预采集轨迹——在特定时间点、特定设备上录制的截图和操作序列。但真实 GUI 环境是高度动态的：

• APP 版本更新后 UI 布局变化
• 不同设备的屏幕分辨率、DPI、系统主题不同
• 弹窗、权限对话框、广告等不可预期的干扰
• 网络延迟导致页面加载不完全

在静态数据上训练的 Agent 很容易过拟合特定界面模式，遇到变化就失灵。

MAI-UI 的方案 —— Online RL：

• 不在静态数据上训练，而是让模型在真实动态环境中在线交互
• 构建 512 个并行 Docker 容器化环境
• 模型在动态环境中 rollout → 获得真实反馈 → 用 GRPO 算法更新
• 环境本身就是动态的，模型自然学会应对各种变化

深度分析： 这本质上是在回答一个根本性问题：GUI Agent 应该在什么数据分布上训练？

静态离线数据的分布和真实在线环境的分布之间存在分布偏移（distribution shift）。传统做法是增大离线数据多样性来弥合偏移，但这是治标不治本的。MAI-UI 的 Online RL 直接在真实分布上训练，从根本上消除了分布偏移问题。

但工程挑战巨大：512 个并行环境的搭建、维护、调度是一个复杂的系统工程。这也是为什么之前很少有人做 GUI 领域的在线 RL——不是想不到，而是做不到。MAI-UI 用了 10 台阿里云 ECS + Docker + AVD + 集中式调度器才把这套系统跑起来。

二、数据飞轮构建：自进化 SFT 数据流水线

MAI-UI 的数据流水线是论文的核心贡献之一，设计目标是解决一个老问题：如何持续获取大量高质量训练数据？

2.1 整体架构：三阶段流水线

整个流水线分为三个阶段，形成一个可迭代的闭环。

阶段 1：导航任务生成

目标： 获取多样化的、贴近真实使用场景的任务指令。

三个来源：

1. APP 使用手册： 从各种 APP 的官方使用手册中提取常见使用场景，转化为自然语言任务描述。优点是覆盖面广、场景真实，缺点是表述偏正式、缺乏口语化。
2. 人工设计： 根据用户调研和真实使用场景，由标注员设计任务。这些任务更贴近用户真实表达习惯，但成本高、量有限。
3. 开源数据集筛选： 从现有开源数据集中按复杂度和可达性过滤出合适的任务。成本最低，但需要质量控制。

阶段 2：轨迹合成（核心）

这是整个流水线最复杂的部分，包含四个关键子模块。

子模块 1：种子任务两级扩展（L1/L2）

这是 MAI-UI 数据多样性的关键来源：

• L1 级扩展（调参数）： 保持任务核心不变，修改参数值。例如：
  • “搜索明天北京到上海的高铁” → “搜索后天北京到广州的高铁”
  • “设置早上 7 点的闹钟” → “设置下午 3 点的闹钟”
  • 本质是参数空间的采样，可以大量自动生成
• L2 级扩展（换对象）： 保持场景和 APP 不变，替换核心操作对象。例如：
  • “在淘宝搜索连衣裙” → “在淘宝搜索运动鞋”
  • “在微信给小明发消息” → “在微信给小红发消息”
  • 需要理解任务结构，自动化难度更高但多样性收益也更大

子模块 2：双管道轨迹生成

两条并行管道生成轨迹数据：

• 人工标注管道： 标注员在安卓模拟器上操作，录制截图序列和动作。质量高但成本高、吞吐低。
• 模型 rollout 管道： 用多个 GUI Agent 模型（包括早期版本的 MAI-UI 和其他模型）在真实环境中自动执行任务，录制轨迹。成本低但质量参差不齐。

子模块 3：质量控制（MLLM-as-Judge）

用 MLLM 做端到端轨迹评判：

• 输入：任务指令 + 完整截图序列 + 动作序列
• 输出：成功/失败 + 失败原因分析
• 关键设计原则： 评判以截图证据为准，而非 Agent 的文本声称。避免 Agent "说自己完成了但截图上明显没完成"的情况。

子模块 4：失败轨迹复用

这是一个精巧的设计——不是简单丢弃失败轨迹，而是截取最长正确前缀：

• 一条 20 步的轨迹在第 15 步出错 → 前 14 步是有价值的正确演示
• 截取前 14 步作为部分成功轨迹加入训练集
• 大幅减少数据浪费，提升数据利用率

阶段 3：迭代拒绝采样（Iterative Rejection Sampling）

这是实现"自进化"的关键——模型和数据分布共同迭代提升。

流程：

1. 用当前模型 M(t) 在环境中 rollout，生成大量轨迹
2. 通过 MLLM-as-Judge 做质量过滤，保留高质量轨迹
3. 将新轨迹与阶段 2 合成的轨迹混合
4. 在混合数据上训练 M(t+1)
5. 回到步骤 1，用 M(t+1) 继续 rollout

为什么这能自进化？

• 拒绝采样缩小 pass@1 vs pass@N 的差距： M(t) 可能 pass@1=30%（一次尝试成功率），但 pass@16=60%（16 次尝试中至少有一次成功）。拒绝采样保留这 60% 中的成功轨迹，让 M(t+1) 学到更好的策略，pass@1 提升。
• 新合成轨迹不断提高 pass@N 上限： 阶段 2 持续引入新的合成轨迹（包括新任务、新场景），使得 M(t+1) 的 pass@N 比 M(t) 更高。
• 两个力共同作用： 拒绝采样从下方推高 pass@1，新轨迹从上方提高 pass@N，模型能力持续提升。

2.2 数据飞轮的深度分析

优点：

1. 闭环设计： 不是一次性标注完数据就结束，而是持续迭代的闭环
2. 多来源融合： 人工标注保证质量下限，模型 rollout 保证数量上限
3. 废物利用： 失败轨迹也能提取价值（正确前缀复用）
4. 自适应： 每轮迭代后数据分布自动向模型能力边界靠拢

局限与思考：

1. 知识提取不足： 失败轨迹只截取了正确前缀，但没有显式提取"为什么失败"的知识。和 Step-GUI 的 CSRS（从失败中提取 7 类结构化知识）相比，信息利用率较低。
2. 质量控制的天花板： MLLM-as-Judge 本身的评判准确率有限（论文提到和人工标注 83% 一致率），会引入噪声。
3. 迭代收敛性： 论文没有讨论迭代多少轮后收敛、是否存在过拟合风险。
4. 任务分布偏移： L1/L2 扩展本质上还是在种子任务附近的局部扩展，可能无法覆盖长尾场景。

三、GUI Grounding 训练

3.1 数据构建

Grounding 数据的独特挑战： 需要精确的 UI 元素定位标注（bounding box），不能有误差。

数据来源：

• 开源数据集（JEDI, OS-Atlas）—— 量大但质量参差不齐
• 自采数据 —— 在容器化虚拟环境中，用 MLLM 引导探索生成截图，再用 a11y tree / OmniParser V2 精确定位 UI 元素

感知数据：

• 从截图中随机选 1-3 个 UI 元素
• 让 MLLM 生成多种任务的训练数据：QA（问答）、描述生成、状态预测
• 目的：增强模型对 UI 元素的语义理解，而非仅仅学会定位

Grounding 指令生成 —— Instruction-as-Reasoning 范式：

这是来自团队前序工作 UI-Ins 的方法，核心思想是从四个人类视角生成 grounding 指令：

1. 外观视角（Appearance）： “点击蓝色的按钮” “点击左上角的圆形图标”
2. 功能视角（Function）： “点击设置按钮” “点击搜索功能”
3. 位置视角（Location）： “点击导航栏最右边的图标” “点击列表的第三项”
4. 意图视角（Intent）： “我想修改密码” “我要查看订单详情”

这四个视角由粗到细、由表层到深层，组合起来可以生成语义丰富的指令，同时作为模型推理时的显式路径。

数据质量发现： 论文指出开源 grounding 数据集约 23.3% 的指令存在质量问题（标注错误、描述模糊、定位不准），这些低质量数据会显著损害训练效果。

3.2 训练范式：SFT → RL

SFT 阶段：

• 用多视角指令作为训练目标
• 模型在预测坐标前先输出推理过程（从哪个视角理解这个元素）
• 推理过程本身也参与 loss 计算，增强模型的"想清楚再动手"能力

RL 阶段（GRPO）：

• 目标：让模型学会在不同场景下动态选择合适的推理视角
• 有些场景外观特征明显（用外观视角更高效），有些场景需要理解功能语义（用功能/意图视角更准确）

奖励设计：

• Format Reward： 输出格式是否正确（JSON 格式、坐标范围合法等），二值奖励
• Point-in-Box Reward： 预测坐标是否落在标注 bounding box 内，二值奖励
• 注意：这里用的是二值奖励（对/错），不是连续奖励（离目标多远）。相比 Step-GUI 的四次方衰减连续奖励，信号粒度较粗。

3.3 Zoom-In 推理策略（推理阶段增强）

这是一个工程简单但效果显著的推理增强方法：

流程：

1. 第一遍（粗定位）： 模型在原始分辨率截图上预测坐标
2. 裁剪放大： 以预测点为中心，裁剪 50% 区域，放大回原始分辨率
3. 第二遍（精细定位）： 模型在放大后的图片上重新预测坐标

效果：

• ScreenSpot-Pro：67.9% → 73.5%（+5.6 分）
• 特别是对于密集 UI 区域和小按钮，两阶段定位效果显著

分析：

• Zoom-In 的本质是用空间分辨率换精度。模型的视觉感知有限，小目标在原始图中只占几个 pixel，放大后特征更清晰。
• 计算成本翻倍（推理两次），但准确率提升显著，在精度要求高的场景下性价比很高。
• 这个策略可以和任何 grounding 模型组合使用，不需要额外训练。

四、移动端 GUI 导航

4.1 Agent-User 交互训练

数据构造方法：

• 从正常任务中故意删除关键信息，制造信息缺失的场景
• 例如：“帮我订酒店” → 删除城市、日期、价位等关键信息
• 模型在执行过程中遇到信息缺失 → 触发 ask_user 动作 → 合成用户 Agent（LLM）依据隐藏信息回复
• 支持单轮和多轮交互（可能需要追问多次才能收集足够信息）

训练目标：

• 模型学会在三个维度上做判断：
  • 何时追问： 信息足够就直接执行，不够才追问
  • 追问什么： 精准定位缺失信息，不问废话
  • 如何利用： 根据用户回复调整执行策略

4.2 MCP 工具使用训练

数据构造方法：

• 设计需要外部工具才能完成（或显著更高效）的任务
• 工具类型：高德地图 API、GitHub API、股票行情 API 等
• 记录完整链路：工具 schema → 参数填充 → API 调用 → 返回结果解析 → 后续 UI 操作

训练目标：

• 模型学会判断何时用 UI 操作、何时用 MCP 工具
• 学会正确构造 API 调用参数
• 学会解析 API 返回结果并据此规划后续步骤

4.3 在线 RL（核心技术贡献）

4.3.1 可扩展 GUI 环境基础设施

这是 MAI-UI 在工程上最重的贡献——搭建了一套可大规模并行的在线 GUI RL 环境。

技术架构：

• Docker 容器化： 每个环境实例是一个 Docker 容器，内含 Android 虚拟设备 (AVD) + 自托管后端服务
• 应用覆盖： 35+ 开源应用（Mattermost 通讯、Mastodon 社交、Mall4Uni 电商、Roundcube 邮件等）
• 硬件资源： 10 台阿里云 ECS 服务器
• 并行规模： 512 个并行环境实例
• 接口标准化： 每个环境暴露标准 RL 接口（reset / step / evaluate / close）
• 可复现性： AVD 快照机制保证每次 reset 回到确定性初始状态
• 集中式调度： Environment Manager 做跨机调度、容器池复用、故障自动恢复

规模化的挑战和解决：

• 环境启动慢 → AVD 快照预热 + 容器池复用
• 环境故障 → 自动检测 + 重启 + 任务重分配
• 网络瓶颈 → 压缩截图传输、批量化通信
• GPU 空等环境交互 → 异步 Rollout

4.3.2 长周期 RL 训练优化

GUI 任务的 RL 和传统 RL 有一个关键区别：轨迹极长。一个任务可能需要 30-50 步操作，每步包含一张截图（百万级 token），总共可达百万级 token 的上下文。

异步 Rollout：

• 传统做法：推理服务器 → 发动作到环境 → 等待环境返回截图 → 继续推理。GPU 大量时间在等环境交互。
• MAI-UI 做法：自定义 Agent Loop 异步调度多台推理服务器和多个环境实例。一台推理服务器在等环境响应时，其他服务器在推理其他轨迹。GPU 利用率大幅提升。

混合并行训练（TP+PP+CP）：

• 基于 Megatron 框架
• 张量并行 (TP)：单个模型层切分到多 GPU
• 流水线并行 (PP)：不同层分配到不同 GPU
• 上下文并行 (CP)：超长序列切分到多 GPU
• 三者组合使得百万级 token 的端到端训练成为可能

图片降分辨率：

• 将截图缩小到一半分辨率
• 显著降低 token 量，加速训练
• 实验证明对最终性能几乎无影响

4.3.3 任务设计与验证器

动态难度分层： 根据模型当前 pass@K（K 次尝试中至少一次成功的概率），将任务分为四个难度层级：

层级	成功率范围	策略
Frontier	0-25%	最难任务，模型几乎无法完成，少量采样
Exploration	25-50%	有一定成功可能但不稳定，重点探索区
Near-Mastery	50-75%	接近掌握，适合巩固
Exploitation	75-100%	已经很熟练，少量采样维持

自动课程学习：

• 训练早期偏向 Near-Mastery 和 Exploitation（简单任务），建立基础行为模式
• 训练后期逐步增加 Frontier 和 Exploration（困难任务），突破能力边界
• 采样比例根据模型当前 pass@K 动态调整

混合验证器：

• 规则验证器： 对于有明确终态的任务（数据库查询、表单填写），用自动化脚本验证
• MLLM-as-Judge： 对于开放式任务（信息查询、交互操作），用 MLLM 评判
• 两者混合
• 与人工标注 83% 一致率，对于 RL 奖励信号来说足够可用

4.3.4 GRPO 训练算法改进

MAI-UI 在标准 GRPO 基础上做了多项改进，每一项都针对 GUI RL 的特殊挑战。

基础设置：

• Group Size = 16（每个任务采样 16 条轨迹做组内对比）
• 奖励 = 任务完成奖励（二值：成功1/失败0）+ 动作重复惩罚

改进 1：动作重复惩罚（防 Loop）

GUI Agent 在 RL 训练中非常容易陷入无意义的重复操作循环——反复点击同一个按钮、反复滑动同一个列表。这在传统 RL 中不常见，但 GUI 环境中极为普遍，因为重复操作不会导致环境崩溃（页面还在、按钮还能点），模型没有负反馈。

解决方案：在奖励函数中加入动作重复检测——如果模型连续 N 步执行了高度相似的动作，施加负奖励惩罚。

改进 2：Clip Higher（非对称裁剪，鼓励探索）

标准 GRPO/PPO 使用对称的 clip 范围 [1-ε, 1+ε]，对新旧策略的偏离做双向限制。MAI-UI 采用非对称裁剪：

• ε_low = 0.2（限制策略向差方向偏移）
• ε_high = 0.3（放宽策略向好方向偏移的限制）

直觉：允许模型更大幅度地往好的方向更新，同时严格限制往差的方向退步。这鼓励模型探索新策略。这和 DAPO 论文的思路一致。

改进 3：Experience Replay（成功轨迹缓冲区）

这是解决 GUI RL 中一个关键问题的方案：难任务 rollout 全部失败怎么办？

• 问题：当一个任务很难、模型当前能力不足时，16 条 rollout 可能全部失败。全失败意味着组内没有正例对比，GRPO 无法计算有效梯度，这个 group 的训练信号为零。
• 方案：维护一个成功轨迹缓冲区。当某个 group 的 16 条 rollout 全部失败时，从缓冲区中采样该任务或相似任务的历史成功轨迹，注入到 group 中，恢复正例-负例对比。
• 效果：保证即使面对当前能力范围外的任务，模型也能从历史成功经验中获得学习信号。

与 Step-GUI Semi-Online 策略的对比：

• MAI-UI Experience Replay：回放旧的成功——从历史缓冲区中取出过去成功的轨迹
• Step-GUI Semi-Online + GT Hints：引导当下成功——给模型注入 Ground-Truth 提示，让它在当前 rollout 中成功
• 两者解决同一个问题（全失败无信号），但路径不同。Semi-Online 产生的是"当前模型在提示下的成功"，更贴近模型当前能力边界；Experience Replay 产生的是"过去模型的成功"，可能和当前策略分布有偏差。

五、端云协同系统详解

5.1 系统架构

端云协同是 MAI-UI 在部署层面的核心创新，目标是在隐私保护、推理成本、任务成功率三者之间取得最优平衡。

核心理念： 不是简单的"小模型做简单任务、大模型做复杂任务"的能力分层，而是端侧模型主动感知自身执行状态，在确实需要时才向云端求助。

5.2 Local Agent：执行者 + 监控者

Local Agent 是端侧部署的轻量模型（2B/8B），但它被训练成具有双重角色：

角色 1 —— GUI Agent**（执行者）：**

• 接收任务指令，在设备上正常执行 GUI 操作
• 和普通 GUI Agent 没有区别

角色 2 —— 轨迹监控器（监控者）：

• 每隔 K 步（或在关键操作后），对当前轨迹做自检
• 检测四种偏离模式：
  • 动作失败： 点击了不存在的元素、页面没有响应
  • 重复无进展： 连续多步执行相似动作但页面无变化
  • 输入错误： 输入了错误的文本、选择了错误的选项
  • 任务偏离： 操作虽然成功但偏离了用户意图（打开了错误的页面、走错了流程）

关键创新：监控能力是显式训练的

• 不是通过 prompt engineering（“请检查你的执行是否正确”）实现
• 而是在训练数据中加入了专门的监控判断样本——给模型展示各种偏离场景，训练它做二分类（正常/偏离）+ 错误类型判断 + error summary 生成
• 这使得监控判断的准确率和鲁棒性远高于 prompt-based 方案

5.3 Cloud Agent：恢复者

Cloud Agent 是云端部署的大模型（32B/235B），仅在满足两个条件时才被调用：

1. Local Agent 检测到轨迹偏离
2. 当前上下文不涉及隐私敏感数据（银行信息、聊天记录等）

输入： Local Agent 生成的 error summary + 任务指令 + 最近几步截图 输出： 修正后的操作方案

隐私保护机制： Local Agent 在决定是否调用 Cloud Agent 时，会检查当前截图是否包含敏感信息。如果包含，即使检测到偏离也不上传，而是尝试自行恢复。

5.4 Unified Trajectory Memory

端侧维护的统一轨迹记忆，记录：

• 原始任务指令
• 完整历史截图序列
• 所有模型输出（Local + Cloud 的输出都记录在同一条时间线上）

核心价值： 支持端云模型在任意时刻无缝切换。无论是从 Local 切到 Cloud，还是 Cloud 修正完切回 Local，模型都能从完整的历史上下文中恢复，不会丢失信息。

5.5 效果

指标	数值
端侧性能提升	+33%
云端调用减少	40%+

这说明：大部分任务端侧模型加了监控能力后就能独立完成，只有真正超出能力范围的少数任务才需要云端兜底。

六、MobileWorld 评测基准

MAI-UI 团队自建的评测基准，目标是补充现有 benchmark 的盲区。

6.1 设计动机

现有移动端评测基准的两个盲区：

1. 只评 GUI 操作，不评交互能力： 没有测试 Agent 面对模糊指令时能否追问
2. 只评 UI 路径，不评工具使用： 没有测试 Agent 能否在合适的时候用 API 替代 UI

6.2 基准规模与覆盖

• 200+ 任务
• 15+ 开源应用
• 覆盖领域： 电商 / 企业通讯 / 社交媒体 / 日常工具

6.3 三个评测维度

维度	评测目标	示例
常规 GUI 导航	端到端任务完成	“在 Mall4Uni 购买一件T恤”
Agent-User 交互	信息不足时追问	“帮我订酒店”（缺城市/日期/价位）
MCP 工具使用	合适时调用 API	“查一下北京到上海的高铁时刻表”（用 API 比 UI 操作高效）

6.4 关键结果

维度	MAI-UI	vs 最强 Baseline	绝对提升
总体	41.7%	超越端到端 GUI 模型	+20.8
Agent-User 交互	37.5%	—	+32.1
MCP 工具使用	51.1%	—	+18.7

分析：

• 交互维度的绝对提升最大（+32.1），说明其他模型在这个维度上几乎完全没有能力，MAI-UI 通过专门训练实现了从 0 到 1 的突破。
• 总体成功率 41.7% 说明这个基准确实很有挑战性，即使是 MAI-UI 也有大量提升空间。

七、关键实验结果

7.1 GUI Grounding

Benchmark	MAI-UI-8B	MAI-UI-32B	MAI-UI-32B+ZoomIn	说明
ScreenSpot-Pro	62.1%	67.9%	73.5%	SOTA，超越 Gemini-3-Pro (72.7%), Seed1.8 (73.1%)
ScreenSpot-V2	94.8%	96.0%	96.5%	接近饱和
OSWorld-G	67.1%	68.3%	70.9%	—
MMBench GUI L2	88.2%	90.5%	91.3%	—
UI-Vision	46.3%	47.8%	49.2%	最难的 benchmark，所有模型都较低

关键观察：

1. 模型规模从 8B → 32B 带来稳定提升（~3-5 分）
2. Zoom-In 在 32B 基础上再提升 ~2-5 分，ScreenSpot-Pro 上提升最大（+5.6）
3. 规模效应 + Zoom-In 可以叠加，说明两者作用于不同层面

7.2 移动端 GUI 导航

AndroidWorld（在线动态环境，最具代表性）：

模型	Success Rate
MAI-UI-235B-A22B	76.7%
MAI-UI-32B	73.3%
MAI-UI-8B	70.7%
MAI-UI-2B	49.1%
UI-Tars-2	— (被超越)
Gemini-2.5-Pro	— (被超越)
Seed1.8	— (被超越)

GUI Odyssey： 83.4% 成功率

关键观察：

1. 2B → 8B 有巨大跳跃（49.1% → 70.7%），说明 8B 是端到端导航的能力门槛
2. 8B → 32B → 235B 提升逐渐放缓（70.7% → 73.3% → 76.7%），边际收益递减
3. 全面超越当前 SOTA（UI-Tars-2, Gemini-2.5-Pro, Seed1.8）

7.3 RL Scaling 消融实验

实验	变量	效果
并行环境规模	32 → 512	+5.2 分
最大交互步数	15 → 50	+4.3 分

分析：

• 并行环境从 32 扩到 512 带来 +5.2 分，说明环境多样性对 RL 训练至关重要。更多并行环境 = 每个 batch 中的任务更多样 = 模型见到更多场景 = 泛化更强。
• 最大步数从 15 扩到 50 带来 +4.3 分，说明很多任务需要较长的操作序列才能完成，15 步太短导致模型被迫在不完整的轨迹上学习。

八、总结与思考

8.1 MAI-UI 的核心贡献

1. 明确定义了四个关键挑战，为 GUI Agent 的研究方向提供了清晰的路线图
2. 自进化 SFT 数据飞轮——三阶段流水线实现模型-数据共进化
3. Online RL 的工程化落地——512 并行环境 + 异步 rollout + 混合并行训练
4. Action Space 扩展——ask_user + mcp_call，从执行器到协作者
5. 端云协同系统——Local Agent 身兼执行+监控双职，隐私感知智能路由
6. MobileWorld 评测基准——首次评测交互能力和工具使用能力

8.2 技术亮点

数据层面：

• L1/L2 种子扩展是一个系统化、低成本的数据多样性方案
• 失败轨迹正确前缀复用减少了数据浪费
• 迭代拒绝采样实现了 pass@1 和 pass@N 的双向提升

训练层面：

• Zoom-In 推理策略工程简单但效果显著（+5.6 分）
• Experience Replay 解决了难任务无学习信号的问题
• 动态课程学习避免了训练崩溃

部署层面：

• 端侧模型的监控能力是显式训练的（而非 prompt engineering），鲁棒性更高
• Unified Trajectory Memory 支持端云无缝切换

8.3 局限与未来方向

1. 数据飞轮的知识提取不足： 失败轨迹只做了前缀截取，没有显式提取"为什么失败"的结构化知识。如果能像 Step-GUI 的 CSRS 那样提取 7 类知识数据，信息利用率会更高。
2. RL 奖励信号较粗： 任务完成的二值奖励 + 动作重复惩罚。相比连续的空间几何奖励（如四次方衰减函数），二值奖励提供的学习信号密度较低，可能导致训练效率不够高。
3. MLLM-as-Judge 的准确率天花板： 83% 的一致率意味着约 17% 的判断是错误的。在 RL 中，错误的奖励信号比没有信号更有害。
4. 跨平台能力有限： 论文主要聚焦 Android 平台，对 iOS / 桌面端 / Web 的覆盖不足。
5. 端云协同的隐私判断： Local Agent 如何准确判断当前截图是否包含隐私数据？这本身是一个有挑战的分类问题，误判可能导致隐私泄露或不必要的拒绝上传。
6. MobileWorld 的生态局限： 15+ 开源应用无法代表真实移动生态的复杂性。真实场景中用户使用的大多是闭源商业应用，其 UI 复杂度和变化频率远高于开源应用。