OpenMobile：通过任务与轨迹合成构建开源移动智能体 OpenMobile: Building Open Mobile Agents with Task and Trajectory Synthesis
解耦探索与任务生成，策略切换采样错误恢复轨迹，让开源数据追平闭源 70% AndroidWorld。
前置知识
视觉语言模型 (VLM) 与 GUI Agent
VLM 是同时理解像素图像和自然语言的多模态基础模型。GUI Agent 把 VLM 当作决策大脑，输入屏幕截图与历史，输出点击/输入等动作完成手机/网页任务，代表如 Qwen-VL、UI-TARS。
OpenMobile 整篇工作都建立在用 VLM 做端到端移动代理之上，没有 VLM 基础就理解不了它如何同时当任务生成器和策略执行器。
AndroidWorld / AndroidLab / MobileWorld 动态评测
这是一类基于 Android 模拟器、参数化生成任务变体、用确定性检查器打分的动态基准，区别于静态轨迹数据集（如 AndroidControl）。任务涉及真实 App、跨 App 长链路，必须执行完才知道对错。
论文主表 Table 1 全部指标都跑在这三个动态基准上，且专门强调静态集不能反映错误恢复能力——读懂主结果和消融都依赖此概念。
模仿学习与专家蒸馏 (Expert Distillation)
模仿学习让 student 模型去拟合 expert 模型在状态 $o_t$ 下产生的动作 $\pi_e(\cdot|I, o_t, h_t)$。在 GUI Agent 场景下常用强 VLM（GPT、Gemini、UI-TARS）做 expert 收集轨迹，再 SFT 学生。
OpenMobile 把 expert distillation 作为基线之一批评——它无法让学生看到自己会犯的错，这是引入 policy-switching 的动机。
感知哈希 (Perceptual Hash) 与屏幕聚类
感知哈希把截图压缩成短二进制指纹，相似的界面会得到相近或相同的 hash。本文用它把多条探索轨迹中的相同/近似屏幕聚合为唯一节点 $\mathcal{S}=\{s_1,\dots,s_N\}$，形成图结构。
这是构建「全局环境记忆」的关键前置步骤，没有屏幕聚类就无法做长程/短程记忆的检索式任务生成。
短期记忆 / 长期记忆 (Short-/Long-term Memory)
类比人类使用 App 的认知模式：从邻近界面（短程）容易自然串联，从语义相关但距离远的界面（长程）需要联想。形式化上，$\mathcal{M}_S(s_i)$ 取自 $\mathcal{N}(s_i)$，$\mathcal{M}_L(s_i)$ 通过功能嵌入的相似度检索得到。
这是解耦式任务合成的核心抽象，决定了 VLM 看到的上下文 $C(s_i)$，直接决定指令多样性与复杂度。
研究动机
过去一年工业界把移动智能体在 AndroidWorld 上的任务成功率推到接近 70%（Step-GUI 67.7%、UI-Venus-1.5 73.7%、MobileAgent-v3.5 71.6%），但这些系统全部闭源——任务指令怎么写、轨迹怎么滚、错误如何恢复都完全不公开。与此同时，开源社区只能用 AndroidControl、AMEX 这类带噪声的人工标注数据训练，ScaleCUA-7B、UI-S1-7B 等代表模型在 AndroidWorld 上只能做到约 30%，比 Qwen3-VL-8B 基线 47.6% 还要低。现有开源合成方法还存在两个更具体的问题：(1) OS-Genesis、NNetNav 这类「交互驱动」方案把任务生成绑死在单条探索轨迹上，导致指令多样性受限于局部观察；(2) 纯专家蒸馏得到的轨迹全是「完美演示」，student 在测试时一旦走偏就不知道怎么回滚，性能天花板被 expert 演示分布钉死。
本文的目标是OpenMobile 的目标是公开一整套可复现的合成 pipeline，让开源研究者只用 7B–8B 量级的 VLM 就能在三大动态基准上跑到接近闭源 SOTA 的水平。具体指标上要实现 Qwen2.5-VL-7B 在 AndroidWorld 上 51.7%、AndroidLab 22.7%、MobileWorld 14.8%；Qwen3-VL-8B 在 AndroidWorld 上 64.7%、AndroidLab 51.5%、MobileWorld 17.7%，并且要在数据规模、合成方式、消融分析上给出透明可复现的细节。
与已有工作不同的是，作者从两个独特角度切入。其一是「解耦」的范式：把环境探索与任务生成分开做，先用随机游走扫遍 20 个 App 的状态空间，再据此构建一张统一的功能地图；任务合成本身用短程+长程记忆检索式召回，避免被单条轨迹限制。其二是「policy-switching」：在轨迹 rollout 阶段让 student（早期 SFT checkpoint）和 expert（Gemini-3.1-Pro-Preview）交替出场，并设计一种 monitor 触发的 error-intervention 切换，让轨迹天然带「犯错-被纠错」的监督信号，弥补纯蒸馏的盲区。两者结合是过去开源数据合成工作都没系统做过的组合。
核心方法
直觉上，OpenMobile 在做两件事——造数据和采轨迹。造数据部分模仿人学新 App 的过程：先漫无目的地随便点，把每个 App 的「功能地图」画出来；之后再从这个地图上取一个当前屏幕、它的邻居屏幕、以及语义上相关但距离远的屏幕三路信息，让 VLM 写出有意义的复杂任务。采轨迹部分则借鉴「双教练」思路：让一个稍弱但已经具备 GUI 能力的 learner 去试错，当一个 monitor 看到它明显跑偏就立刻切换成 expert Gemini 接管纠错，但只保留 expert 步骤作为训练监督。技术路线上，造数据用感知哈希聚类 + VLM 标注功能 + 嵌入检索三步搭起全局环境记忆 $\mathcal{M}=\{\mathcal{S},\mathcal{N},\{F(s_i)\}\}$；采轨迹用策略切换 + 错误介入 + CoT 重写，最终产出 2.8K 指令 / 34K 动作 / 20 个 App 的数据集。
与已有方法的本质区别有两条。第一条是「解耦 vs 耦合」：OS-Genesis 这类方法把单条随机游走轨迹直接喂给 LLM 反推任务，指令多样性被局部观察钉死；OpenMobile 先用多轮探索把同一屏幕的不同到达路径汇总成图节点 $\mathcal{S}=\{s_1,\dots,s_N\}$，再对每个节点的三层记忆 $C(s_i)=(s_i, \mathcal{M}_S(s_i), \mathcal{M}_L(s_i))$ 做检索式生成，单条轨迹无法触达的「跨功能」组合也能被写出。第二条是「policy-switching vs 单一来源」：expert distillation 只产生零错误轨迹、self-evolution 学得太慢、random switching 又因多解性太吵，OpenMobile 的 error-intervention 让 monitor 在检测到 learner 偏离「有效推进」时立即切回 expert，天然得到含错误恢复经验且任务可完成的轨迹，并把平均错误恢复次数从 0.42（纯蒸馏）提升到 1.56。
方法步骤详情
方法分两大阶段共五步。Scalable Task Synthesis：(1) 用随机游走在 AndroidWorld 模拟器对 20 个 App 收集屏幕-动作序列；(2) 感知哈希聚类得唯一屏幕集 $\mathcal{S}$，聚合转移得邻居 $\mathcal{N}(s_i)$，VLM 为每屏标注功能集 $F(s_i)$ 并建嵌入索引；(3) 对每个候选屏 $s_i$ 构造上下文 $C(s_i)=(s_i, \mathcal{M}_S(s_i), \mathcal{M}_L(s_i))$，$\mathcal{M}_S$ 取邻居、$\mathcal{M}_L$ 语义检索远端屏，VLM 生成候选指令后过滤去重。Policy-Switching Rollout：(4) 给定指令 $I$、expert $\pi_e$、learner $\pi_l$，每步 $z_t\in\{e,l\}$ 决定 $a_t\sim \pi_{z_t}(\cdot|I,o_t,h_t)$，monitor $\mathcal{O}$ 在 learner 偏离「有效推进」时切到 expert；(5) 只保留 expert 步 SFT 但保留含错完整历史，expert 把 CoT 重写成 ~129 词。最终 LLaMA-Factory、batch=32、lr=$1e^{-5}$、3 epoch 在 Qwen2.5-VL-7B/8B 上 SFT。
技术新颖性
技术新颖性体现在三处。其一是首次明确提出 decoupled task synthesis 的两阶段范式，并通过 Table 2 的消融数据展示其在 AndroidWorld 上 48.3% 超过 OS-Genesis 34.1% 和耦合基线 45.3%，且人类评估在「复杂度」维度上 0.68 的胜率证明生成的指令确实更复杂。其二是 error-intervention 切换策略在 Table 3 中带来 1.56 平均错误恢复次数（远超 random switch 的 0.64 和 self-evolve 的 0.10），直接推动 AndroidWorld Pass@1 从纯蒸馏的 44.8% 升到 48.3%。其三是 Figure 4 揭示「功能覆盖率」与成功率的耦合关系，把数据合成的质量从直觉性的「看起来多样」转化为可量化的覆盖率指标，并证明 broad functionality coverage（而非数据量本身）才是性能提升的关键驱动——这是把移动 Agent 数据工程从经验工艺推向可分析范式的贡献。
实验结果
Table 1 展示 OpenMobile 在三大动态基准的统治级表现：Qwen2.5-VL-7B 从 25.5% 提到 AndroidWorld 51.7%（+26.2）、AndroidLab 22.7%（+12.1）、MobileWorld 14.8%（+7.1），均超 ScaleCUA-7B（27.2/30.0/7.7）；Qwen3-VL-8B 进一步推到 64.7%/51.5%/17.7%，在 AndroidWorld 和 AndroidLab 上超 Qwen3-VL-8B 基线 17.1 与 8.0 个绝对点，逼近闭源 Step-GUI-8B（67.7%）与 MobileAgent-v3.5-8B（71.6%/33.3%）。Table 2 显示 1.5K 轨迹预算下 OpenMobile 48.3% 击败 OS-Genesis 34.1% 和耦合流水线 45.3%。Table 3 显示 expert distillation 44.8%、self-evolution 33.8%、random switch 45.1%，error-intervention 拿到 48.3%，错误恢复次数从 0.42–0.64 提升到 1.56 直接转化为下游性能。Figure 3 给出数据污染分析：相似度 >0.7 的合成指令仅 3.5%。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| AndroidWorld Pass@1 | % 任务成功率 | 51.7 (Qwen2.5-VL-7B) / 64.7 (Qwen3-VL-8B) | Qwen2.5-VL-7B 基线 25.5 / Qwen3-VL-8B 基线 47.6；ScaleCUA-7B 27.2；UI-S1-7B 34.0 | +26.2 / +17.1 相对各自基线；超过 UI-Venus-7B 49.1 约 2.6–15.6 点 |
| AndroidWorld Pass@3 | % 任务成功率 | 68.1 (7B) / 78.0 (8B) | Qwen2.5-VL-7B 基线 34.9；Qwen3-VL-8B 基线 62.1；ScaleCUA-7B 36.2 | +33.2 / +15.9 相对基线；逼近 Step-GUI-8B 80.2 |
| AndroidLab Pass@1 | % 任务成功率 | 22.7 (7B) / 51.5 (8B) | Qwen2.5-VL-7B 基线 10.6；Qwen3-VL-8B 基线 43.5；ScaleCUA-7B 30.0 | +12.1 / +8.0 相对基线；8B 超过 UI-Venus-7B 41.3 约 10.2 点 |
| AndroidLab Pass@3 | % 任务成功率 | 37.0 (7B) / 62.3 (8B) | Qwen2.5-VL-7B 基线 15.2；ScaleCUA-7B 37.7 | +21.8 相对基线；8B 接近 Step-GUI-4B 75.8 的开源参考 |
| MobileWorld Pass@1 | % 任务成功率 | 14.8 (7B) / 17.7 (8B) | Qwen2.5-VL-7B 基线 7.7；Qwen3-VL-8B 基线 9.4；ScaleCUA-7B 7.7 | +7.1 / +8.3 相对基线，7B 与 8B 都较 ScaleCUA 翻倍以上 |
| MobileWorld Pass@3 | % 任务成功率 | 21.4 (7B) / 24.8 (8B) | Qwen2.5-VL-7B 基线 10.3；ScaleCUA-7B 8.6 | +11.1 相对基线，7B 翻倍以上 |
局限与改进
作者显式承认几点局限：(1) RL 实验（step-level 与 trajectory-level agentic RL）均未显著超过 SFT，说明合成数据虽多但奖励信号稀疏问题在动态基准上仍然突出；(2) 数据集 2.8K 指令 / 34K 步仅覆盖 20 个 App，远小于工业级闭源系统规模；(3) error-intervention 的 monitor 依赖人工定义的「有效推进」启发式，没有理论保证；(4) 借助 AndroidWorld 环境合成数据，虽通过 3.5% 相似度证明无明显泄漏，但 AndroidLab/MobileWorld 与训练环境部分 App 重叠，跨基准泛化是否反映未见功能仍是开放问题。本人额外观察：Figure 1 的 Error Correction 面板未给数值化指标；Table 1 中 OpenMobile 在 MobileWorld 上仍远低于 MobileAgent-v3.5-8B 的 33.3%，说明长链跨 App 任务对当前数据规模依然是硬骨头。
独立分析的弱点
本人独立分析了几点可改进的弱点。其一是规模与覆盖剪刀差：2.8K 指令在功能覆盖率上仍存在长尾遗漏，Table 1 显示 MobileWorld 上即便 8B 也只到 17.7%，改进方向是把指令按功能组合数分层采样、显式提升跨 App 长链指令比例。其二是 monitor 的启发式粗糙：error-intervention 是整套方法的「灵魂」，但作者未详细定义「偏离有效推进」的判定准则，改进方向是引入轻量分类器对 learner 与 expert 的「意图」对齐度打分，或直接复用任务完成度的中间信号。其三是评估只覆盖三大公开基准且与训练环境部分 App 重叠，改进方向是补充未在 AndroidWorld 出现的 App（银行、出行类）做 held-out 评测。其四是可复现性方面，expert 用的是 Gemini-3.1-Pro-Preview 这种带版本号的服务端模型，行为漂移让结果不可复现，改进方向是发布所有 prompt 与随机种子并提供 OSS expert 替代。
未来方向
作者明确提出了两个方向：(1) 把 policy-switching 的思想推广到 RL 阶段，构造带错误恢复的偏好数据做 DPO/RLHF；(2) 把功能覆盖率作为合成阶段的显式优化目标，自动搜索「下一个最有价值的指令」而不仅是随机采样。基于成果可延伸的方向还有：在多模态基础模型层面，把 error-intervention rollout 生成的「错误-纠正」对训练成 reflection token，让模型在解码时主动判断是否需要回滚；在系统层面，把 monitor 替换为可微的 verifier，从 IMITATION 走向 verifier-guided MCTS 的离线蒸馏；在数据层面，把合成 pipeline 推广到 WebArena、OSWorld 等非移动环境，验证 decoupled 范式的跨域通用性。
复现评估
OpenMobile 在可复现性上做得相当到位：(1) 作者声明会开源全部数据和代码到 OpenMobile 仓库；(2) 训练用 LLaMA-Factory 公开工具链，batch=32、lr=$1e^{-5}$、3 epoch 等超参全部列出；(3) 2.8K 指令 / 34K 步、20 App、平均轨迹 12.2 步、129 词 CoT 等数据统计透明披露；(4) 评测用三大公开动态基准并提供 Pass@1/Pass@3 双重指标。但复现难度中等偏高：(a) expert 是 Gemini-3.1-Pro-Preview 闭源服务，调用成本与数据私密性都是障碍；(b) 训练需 7B/8B VLM 多卡 GPU（按 batch=32 估计 8×A100 80G）；(c) AndroidWorld 模拟器依赖特定 Android 镜像，环境准备有门槛。完整复现至少需 1-2 名熟悉 VLM 训练和 Android 模拟器的工程师耗费 2-3 周。
论文图表
Figure 1 由三个子图组成。左图是三大动态基准的条形对比，OpenMobile-8B 在 AndroidWorld 64.7% 接近 Step-GUI-8B 67.7%，在 AndroidLab 51.5% 超过所有列出的开源方法；中图是 AndroidWorld Pass@1 随合成指令规模 0.5K→2.8K 上升的曲线，显示收益存在对数式饱和；右图是 Error Awareness / Diagnosis / Correction 三维的能力雷达对比，OpenMobile 训练后模型在三个错误恢复维度上明显外扩。
这是论文的「面子图」，把性能、可扩展性、错误恢复三件事用一张图说清，是读者快速建立 OpenMobile 价值判断的第一入口。