Xiaomi-GUI-0 — 真机闭环移动 GUI Agent 的工程范式
Xiaomi-GUI-0 Technical Report — 真机闭环移动 GUI Agent
Section titled “Xiaomi-GUI-0 Technical Report — 真机闭环移动 GUI Agent”发布日期： 2026-06-30 来源： https://arxiv.org/abs/2606.31410 工程范式： 以真实设备为主体的混合基础设施 + 错误驱动数据飞轮 + 渐进式三阶段后训练（SFT → Step RL → Agentic RL）
核心约束：现有 GUI Agent 的训练和评估高度依赖离线成功轨迹、模拟环境和标准化 Benchmark，与实际部署时的真实应用界面布局、交互逻辑、异常状态分布存在本质差异。这种差异导致 Benchmark 高分与真实可用性之间的持续鸿沟。
关键洞察：GUI Agent 是顺序决策系统，每一步都会改变后续状态——错误识别、反思纠正、状态恢复能力才是实际部署的瓶颈。然而现有训练数据以离线成功轨迹为主，模型对真实环境中高频出现的故障模式几乎没有暴露。
面对这一约束，Xiaomi 团队做出了以下架构选择：
- 真实设备主导（Real-Device-Dominant）：物理设备（手机、平板、车载屏幕）作为主要执行环境，沙箱仅提供辅助支持。这与 CUA-Gym、MobileGym 等模拟器方案形成鲜明对比。
- 错误驱动数据飞轮（Error-Driven Data Flywheel）：不追求数据规模扩展，而是围绕模型自身在真实部署中暴露的错误分布来修复数据。
- 渐进式三阶段训练：SFT（建立基础操作能力）→ Step RL（修正局部错误）→ Agentic RL（优化长程轨迹），形成从密集反馈到稀疏反馈的课程。
放弃了什么：放弃了以模拟器为中心的规模化训练范式；放弃了纯离线成功轨迹的依赖；为了保证真实执行分布，接受了物理设备集群的高运维成本（数百台真机 + 沙箱混合调度）。
关键架构决策
Section titled “关键架构决策”混合基础设施（真机主导）
Section titled “混合基础设施（真机主导）”- 物理设备池覆盖近 10 个主流品牌，涵盖手机、平板、车载屏幕
- 手机覆盖 100 个最高流量商业应用，平板/车载覆盖 20 个代表性优化应用
- 沙箱池提供数百并发实例用于可复现的实验和消融
- Device-Pull 调度方案：闲置设备根据当前就绪状态从队列请求任务，而非推送分发——适应真机可能离线、登录失效、触发风控等现实情况
- 统一动作空间 + 低延迟浏览器控制通道用于人工维护
数据构造三梯队
Section titled “数据构造三梯队”- 高频任务数据（High-Frequency Task Data）：~5,000 个异常状态样本覆盖 14 类异常（登录过期、验证码、支付认证、权限弹窗、网络错误等），每类配差异化处理策略
- 高泛化数据（High-Generalization Data）：五级函数树 + 行为桶（Behavior Bucket）两轴查询合成，覆盖单应用/跨应用三种任务关系（接力、对比、并行）
- Agent 能力增强数据（Agent-Capability Enhancement Data）：五标签结构化 CoT 架构（Observation/Reflection/Plan/Decision/Memory）
错误驱动数据飞轮
Section titled “错误驱动数据飞轮”- 交互式标注：人工回放失败轨迹，定位首个关键错误（First Key Error），提供修正动作 + 错误原因
- 教师模型评分与接管：教师模型每步评分，连续低于阈值时临时接管产生恢复轨迹
- 关键原则：失败轨迹不被丢弃，而是转化为 explicit 的反思+纠正监督信号
三阶段训练管线
Section titled “三阶段训练管线”| 阶段 | 数据规模 | 损失函数 | 核心目标 |
|---|---|---|---|
| SFT | 120K 轨迹（1.2M step）+ 4.4M grounding | 下个 token 预测 | 建立基础执行能力、动作协议、结构化推理 |
| Step RL | 40K 轨迹（0.4M step） | GSPO（序列级重要性采样） | 修正局部错误（格式/参数/推理结构/记忆更新） |
| Agentic RL | 数千任务（在线生成） | GSPO + 轨迹级回报 | 长程规划、跨应用状态保持、错误恢复 |
Cascade Reward（层级触发式奖励）
Section titled “Cascade Reward（层级触发式奖励）”| 层级 | 检查器 | 失败条件 | 奖励 |
|---|---|---|---|
| L1-A | 规则解析器 | 严重格式错误或解析失败 | -1.0 |
| L1-B | 规则动作检查 | 动作/参数/工具调用无效或不一致 | -0.5 |
| L2 | 规则结构检查 | 推理字段缺失或格式错误 | -0.5 |
| L3 | LLM-as-Judge | 反思/规划/记忆与状态冲突 | -0.5 |
| L4 | LLM-as-Judge | 推理与动作描述/工具调用不一致 | -0.5 |
| Pass | 全部通过 | 所有层级通过 | 1.0 |
- MTP (Multi-Token Prediction) 模型已可用作投机解码草案模型（MiMo-V2-Flash 架构）
- 但 Xiaomi-GUI-0 本身基于 Qwen3-VL-30B-A3B，主要优化在训练而非推理
RealMobile Benchmark（自建真实设备测试集）
Section titled “RealMobile Benchmark（自建真实设备测试集）”- 100 个任务 × 14 个应用 × 4 个能力域
- 57% 任务涉及多应用，平均 1.93 个应用/任务
- 精细粒度评分（子目标分解 + 连续分值）+ Veto 机制
- Xiaomi-GUI-0 成功率达到 72.0%（完全完成比例）
AndroidWorld（公开 Benchmark）
Section titled “AndroidWorld（公开 Benchmark）”- Xiaomi-GUI-0 达到 78.9% 成功率
- 显著提升真实设备上的执行稳定性和异常状态识别
- 64 × NVIDIA H100 GPU（8 节点 × 8 GPU）
- 训练框架：verl (RL) + Megatron-Core (training) + SGLang (rollout)
| 维度 | Xiaomi-GUI-0 | 典型 GUI Agent（Mobile-Agent-v3.5, UI-TARS-2 等） |
|---|---|---|
| 执行环境 | 真机主导 + 沙箱辅助 | 模拟器/沙箱为主 |
| 训练数据 | 真实用户指令 + 真实异常状态 | 离线成功轨迹 + 简化模拟环境 |
| 错误处理 | 错误驱动飞轮 + 显式反思训练 | 错误轨迹通常被丢弃 |
| RL 训练 | Step RL → Agentic RL 两级 | 多为单阶段 SFT 或简单 RL |
| 评估 | 真实设备 Benchmark（RealMobile） | AndroidWorld 等标准模拟评估 |
| 好奇心 | 需维护数百台物理设备集群 | 运维成本低 |
| 局限性 | 中国应用生态为主，国际化有待验证 | 覆盖面更广但深度不足 |
与 MiMo-V2-Flash（同团队的纯 LLM）的关系：Xiaomi-GUI-0 专注于 GUI Agent 能力，Qwen3-VL 作为视觉骨干，两者的工程管线存在协同但模型架构独立。
截至撰写时（2026-07-12），该论文刚发表约两周，社区讨论尚未广泛展开。核心贡献（真机闭环 + 错误驱动飞轮）的工程价值已获内部验证。
可复用的工程经验
Section titled “可复用的工程经验”- 真机 Hybrid 基础设施是可落地的：数百台物理设备 + 沙箱协同的方案，虽然运维成本高，但确实能消除数据收集、训练、评估之间的分布偏差
- 失败轨迹比成功轨迹更有价值：错误驱动数据飞轮证明，围绕模型自身错误分布生成反思+纠正信号，比单纯扩展数据规模更有效
- Cascade Reward 设计是工程实用的：层级式先便宜后昂贵的检查链，既保证了奖励质量又控制了计算成本
- 结构化 CoT（五标签）模板可通用：Observation → Reflection(可选) → Plan/Replan → Decision → Memory 的格式可复用到任何长程 Agent 场景
- First-Key-Error 标注策略节省人力：只在失败轨迹中标注第一个关键错误，其余错误视为级联派生——降低标注成本但不丢失信息
- GSPO（序列级 Group Policy Optimization）+ 非对称 clip 比：适合 Agent 响应这种以完整动作为单位的优化场景