OpenMobile-2:以可扩展环境与应用原生工具构建通用移动智能体 OpenMobile-2: Building Versatile Mobile Agents with Scalable Environments and App-Native Tools

第一步,环境构建。输入是源应用的功能范围,输出是 35 个高保真模拟客户端:先写行为规范,把核心工作流表示为页面节点和有意义 UI 状态构成的图,每个改变状态的交互都指明 UI 元素、动作 ID、预期状态效果(如 stateChange: cart.items += item)和状态检查;再按规范实现路由与动作;交付前执行两项检查——覆盖检查把声明的交互 ID 映射到实现绑定,回放检查确认代表性转换产生声明的状态变化。第二步,任务与数据合成。对模拟器应用通过探索发现屏幕、动作与转换(感知相似的截图合并为代表状态),对模拟应用直接从后端规范导出全局/局部视图;Gemini-3.1-Pro-Preview 基于视图生成以用户目标措辞的指令(不点名控件、工具或验证器字段),过滤低质与高相似任务;教师模型逐任务执行,模拟器侧用视觉语言裁判判成败,模拟环境侧用程序化验证器;成功轨迹再做步级过滤,删除无意义动作循环和状态不变的动作。第三步,SFT:GUI-only run 用 9,869 条轨迹(106,488 步),Hybrid run 用 11,643 条(118,582 步,含 1,774 条混合轨迹);每步一个样本(指令+历史+最近 3 张截图+Thought+单次工具调用),截图以 1080×2400 原生分辨率输入,坐标归一化到 999×999 空间,共训 5 个 epoch,学习率 $5\times10^{-6}$,视觉塔冻结,8 卡 GPU。第四步,RL:从 Hybrid SFT 检查点出发,在 MobileGym++ 的 512 个任务上训练,每组 8 条 rollout,DAPO 非对称裁剪 $\epsilon_{low}=0.2,\ \epsilon_{high}=0.28$,KL 系数 0.01,LoRA rank-64(视觉塔冻结),32 张 H800 跑 150 步;奖励 $r = v\cdot m_{\text{tool}}\cdot\ell - 0.2\,n_{\text{fmt}} - 0.2\,f_{\text{succ}}$,其中 $v\in\{0,1\}$ 是宽松状态验证器,$m_{\text{tool}}=2$ 当轨迹含至少一次 app-native 工具调用否则为 1,$\ell$ 是长度因子(12,000 token 内为 1,至 28,672 线性降到 0.5),$n_{\text{fmt}}$ 是格式错误轮数,$f_{\text{succ}}$ 标记虚报成功。

技术新颖性体现在四个方面。(1) 应用构建配方:以往模拟环境要么从 API 出发(AppWorld,9 个应用、无手机 GUI),要么应用少且无扩展方法(MobileGym 仅 12 个商业应用);本文给出'规范先行—实现—双重检查'的可复制流程,让商业应用复刻可以规模化,新应用达到旧应用 1.48 倍交互动作与 1.91 倍页面转换。(2) 状态级验证:不同于 AndroidWorld 等依赖设备级信号或模型裁判的方案,MobileGym++ Bench 检查应用业务对象的前后 diff,不检查轨迹与截图,判分确定且对 GUI 动作与工具调用一视同仁,这对 RL 训练尤为关键——奖励信号必须是可靠且不可被策略钻空子的。(3) App-native 工具与受控比较:300+ 工具覆盖 50+ 应用,与应用共享状态;同一套 215 个任务、相同初始状态和检查器同时用于 GUI-only 与混合评估,这是移动领域第一个能干净度量'GUI 之外工具通道增益'的设定,此前的 MAS-Bench 用快捷方式、MobileWorld 用外部 MCP,都无法保证语义等价。(4) 全栈开源:环境、11.6K 轨迹、2,475 个可执行 RL 任务、完整超参配方与 9B/27B 模型全部开放,而开源权重竞品(UI-Venus-1.5、GUI-Owl-1.5、MAI-UI)普遍不开训练环境和数据生产管线。

独立分析以下弱点。第一,工具奖励塑形可能学成'工具偏好'而非'工具判断':$m_{\text{tool}}=2$ 直接让含工具调用的轨迹奖励翻倍,智能体可能为了拿加成而滥用工具,尤其当工具调用更省事时。改进方向是把工具加成改为条件化的——只有当工具路径确实更短或更成功时给奖励,或在优势层面做小偏置而非奖励翻倍。第二,训练与评估的同源风险:Bench 的验证器、初始状态和 RL 任务出自同一套环境基础设施,虽然指令级相似度分析很干净(超 0.7 的仅 2.25%),但应用与业务对象的分布是重叠的,MobileGym++ 上 67.0 的数字可能高估真实泛化。改进是引入完全独立构建的第三方商业应用做 held-out 评估。第三,教师单一:数据生成与轨迹采集全靠 Gemini-3.1-Pro,其风格偏差和错误模式会被蒸馏进 1.2 万条轨迹。改进是多教师混合加一致性过滤。第四,真实部署链路缺失:论文没有展示在真机上接入真实 MCP 或无障碍服务工具的实验,'混合能力能否落地'仍是悬而未决的问题,可以在真机上用 MCP 桥接少量真实应用做小规模验证。第五,长时程与记忆:SFT 只保留最近 3 张截图(旧的替换为占位文本),RL 最多 32 张,多应用长任务中早期信息会丢失,而 4 应用任务只有 5 个,长时程能力未被充分压力测试,可以引入显式笔记/记忆机制并扩充深度跨应用任务。

作者提出或暗示的方向:继续扩大应用覆盖与领域广度,因为'环境规模化提升泛化'已被控制变量实验证实;深化混合 GUI-工具设定,包括工具覆盖从 50+ 应用继续扩展。基于本文成果可以自然延伸的研究:(1) 把 RL 从 512 个任务扩展到全部 2,475 个并做多轮迭代,同时研究更精细的工具激励形式,例如比较'奖励塑形'与'代价感知'两种方案;(2) 把 app-native 工具推广到真实 MCP 生态,研究工具检索、工具可信度评估与副作用管理,让混合策略走出沙盒;(3) 跨平台迁移——把 Android 上学到的商业工作流经验迁到 iOS 或桌面 GUI,检验'工作流知识'是否平台无关;(4) 利用 MobileGym++ 的程序化验证器训练过程奖励模型(process reward model),摆脱稀疏的 0/1 结果奖励,给 RL 提供更稠密信号;(5) 显式研究 GUI 与工具的自动路由策略——何时该点、何时该调——当前完全靠模型从数据中隐式学习,可以引入显式决策头或开销感知规划;(6) 多智能体协作处理超长跨应用工作流,以及把用户偏好和持久记忆纳入环境状态。

开源情况:论文声称所有资源都在 OpenMobile-2 链接开放——MobileGym++ 环境(63 个模拟客户端)、OpenMobile-Data-v2(11,643 条 SFT 轨迹 + 2,475 个 RL 任务)、MobileGym++ Bench(215 任务)、完整训练配方(含全部超参和系统提示词)以及 9B/27B 模型权重,开放程度在同类工作中属第一梯队(对比 UI-Venus、GUI-Owl 均不开环境与数据生产管线)。算力需求分两档:SFT 用 8 张 GPU(张量并行 4)、bf16、视觉塔冻结,单机即可复现;RL 是最重的部分,需要 32 张 H800(4 节点)、LoRA rank-64、150 步,中小团队难以原样复现,但可以把任务数从 512 缩到 128 左右降低门槛。环境是浏览器托管的模拟应用,每个节点跑一个模拟器实例、64 个并行浏览器页面,推理侧需要 vLLM 引擎;评估 AndroidWorld/MobileWorld 需要 Android 模拟器集群,SPA-Bench 需要物理真机。数据附带完整验证器,复现数据生产管线的主要依赖是 Gemini-3.1-Pro API(任务生成与教师执行)和人工对照校验。总体评估:结果复现容易(模型和 bench 齐备,评测脚本开源),训练复现中等偏难(RL 算力门槛),数据生产复现中等(需要教师模型 API 与标注人力)。