内容摘要：大模型驱动的手机 GUI Agent 已具备理解屏幕、执行点击、输入文本及完成复杂移动端任务的能力。然而，在真实应用场景中，一个核心痛点日益凸显：手机 App 生态庞大且迭代迅速，功能与界面变化频繁。

大模型驱动的不用标注手机 GUI Agent 已具备理解屏幕、执行点击、人工输入文本及完成复杂移动端任务的跑数能力。然而，据飞在真实应用场景中，轮快一个核心痛点日益凸显：手机 App 生态庞大且迭代迅速，大开功能与界面变化频繁。不用标注若每次适配新 App 均需人工编写任务、人工录制专家轨迹及标注奖励信号，跑数成本将呈指数级增长。据飞

针对这一难题，轮快来自浙江大学 APRIL 实验室、大开快手主站技术部及清华大学的不用标注研究团队提出了 MobileForge。该方案旨在将手机 GUI Agent 的人工适配过程重构为一个“无标注、自探索、跑数自反馈、自优化”的闭环系统。

论文题为 MobileForge: Annotation-Free Adaptation for Mobile GUI Agents with Hierarchical Feedback-Guided Policy Optimization。其核心逻辑可概括为：让 Agent 在目标 App 中自主探索，自动生成可执行任务，对执行过程进行分层评估，并将反馈转化为策略优化信号。

关键实验成果：
* 仅使用自动生成的无标注数据，MobileForge 将通用视觉语言模型 Qwen3-VL-8B在 AndroidWorld 上的 Pass@3 提升至 67.2%，逼近闭源数据训练的 GUI 专用模型 GUI-Owl-1.5-8B（69.0%）。
* 基于 GUI-Owl-1.5-8B 适配得到的 ForgeOwl-8B，在 AndroidWorld 上达到 77.6% Pass@3，并在未参与训练的 MobileWorld GUI-only 任务中取得 41.0%的成功率。

论文 Figure 1：AndroidWorld 扩展趋势、域内适配结果及 MobileWorld 跨域泛化结果

作者信息：
* 共同第一作者：浙江大学 APRIL 实验室博士生刘广义、硕士生赵鹏翔、吴高，清华大学博士生殷翊文。
* 通讯作者：浙江大学刘勇教授。

开源资源：
MobileForge 实现全链路开源，涵盖代码、数据、模型及训练/评测 Pipeline。
* 论文：https://arxiv.org/abs/2606.19930
* 项目主页：https://mobile-forge.github.io/
* Github：https://github.com/kwai/MobileForge
* Huggingface Daily Paper：https://huggingface.co/papers/2606.19930
* 全链路数据：https://huggingface.co/collections/lgy0404/mobileforge-datasets
* 全链路模型：https://huggingface.co/collections/lgy0404/mobileforge-models

手机 GUI Agent 的核心瓶颈：从“操作能力”到“适应能力”

过去一年，GUI Agent 研究从网页、桌面延伸至移动端，模型已能根据截图和指令执行点击、滑动、输入等操作。但移动端场景存在三大特殊挑战：

1. 生态碎片化严重：不同 App 的页面结构、功能入口及交互逻辑差异巨大；同一 App 的版本更新也可能导致按钮位置、菜单层级及任务流程发生剧烈变化。
2. 长链路任务复杂：单一任务往往涉及多步操作（如打开应用、导航、搜索、筛选、跨 App 交互）。仅依赖最终成功/失败的稀疏奖励，难以定位中间环节的具体错误。
3. 现有“无标注”方法的断点：虽减少了人工依赖，但探索、任务生成、执行与反馈未形成统一底座；策略优化时，模型常将单次 Rollout 视为孤立样本，依赖粗粒度奖励，难以从失败轨迹中提取有效的局部动作信号。

论文 Figure 2：现有方法的两大瓶颈与 MobileForge 的解决思路

MobileForge 旨在回答：能否构建一个不依赖人工任务、专家示范或奖励标签的适配系统，使任务生成源于真实交互，反馈足够细粒度，并将 Agent 采集的经验转化为可优化的策略信号？

架构解析：MobileForge = MobileGym + HiFPO

MobileForge 由两个紧密耦合的核心组件构成：

1. MobileGym：交互与评估底座

MobileGym 负责在目标 App 中探索可达状态，挖掘可执行任务，并对 Agent 的完整执行过程进行细粒度分层评估。

2. HiFPO：层级反馈引导的策略优化

Hierarchical Feedback-Guided Policy Optimization (HiFPO) 负责调度多次尝试，复用前次失败的纠错提示，筛选高价值任务与步骤，最终通过 hint-contextualized step-level GRPO更新模型策略。

Figure 3：MobileForge 总体流程

MobileForge 构建了一条从“真实 App 交互”到“策略更新”的自动化流水线：
目标 App 探索 → 任务课程生成 → 多次 Rollout → 分层评估 → 任务/轨迹/步骤过滤 → 带纠错提示的 GRPO 训练

该链路完全去除了人工编写任务、专家演示及人工奖励标签。

MobileGym：在真实 App 中挖掘“可学内容”

MobileGym 解决了数据来源问题，包含三个关键阶段：

第一阶段：目标 App 探索
MobileForge 结合 APK 结构信息（如 Activity 声明）与当前截图，生成面向功能的探索目标。采用类似深度优先遍历的方式，当需分支时恢复父状态继续探索。
* 注意：探索轨迹并非专家示范，而是用于发现真实可达页面、可操作控件及实际功能，防止模型“幻觉”。
* 证据池构建：记录操作前后的截图、动作、目标元素、元数据及自然语言摘要。

第二阶段：MobileGym-Curriculum（任务生成）
将探索证据转化为可执行任务。系统判断轨迹连贯性及目标完成情况，围绕同一功能生成多个任务变体。
* 任务 Schema：五元组（任务指令、预估步数预算、核心功能、变化类型、前置条件）。重点在于任务必须锚定于真实观察到的 App 行为。

第三阶段：MobileGym-Critic（分层评估）
不训练传统奖励模型，而是使用 Agentic Hierarchical Evaluator 对完整 Rollout 进行分层评估，输出三类反馈：
1. 轨迹级 Outcome Label：任务最终是否完成？
2. 步骤级 Process Label：每一步是否合理？原因何在？
3. 纠错 Hint：总结失败原因、避免行为、替代策略及关键洞察。

Figure 4：移动端 GUI Agent 无标注适配基座 MobileGym

分层反馈至关重要。传统方法将 Rollout 简化为成败，而 MobileGym-Critic 能拆解长链路任务，从失败轨迹中识别正确局部步骤，从成功轨迹中剔除冗余动作。

HiFPO：将“失败经验”转化为训练信号

HiFPO 负责将反馈转化为策略更新，包含四个步骤：

步骤一：带提示的多次尝试（K-times Rollout）
对每个任务，让当前策略连续尝试 K 次。
* 首次尝试无额外提示。
* 若失败或出现不合理步骤，MobileGym-Critic 生成纠错 Hint。
* 后续尝试将 Hint 追加至任务指令，帮助模型避免重复犯错。
* 核心逻辑：Agent 在同一任务上积累经验，前次失败转化为下次尝试的上下文。

论文 Figure 6：纠错提示改善 Rollout 的案例

步骤二：任务过滤
计算任务的经验成功率 SR(x)。
* 移除：全部成功的任务（模型已掌握，训练价值低）。
* 保留：全失败或部分成功任务。
* 反直觉洞察：失败轨迹中可能包含正确的导航、搜索或识别步骤，只要步骤级反馈能提取合理动作，失败即可转化为有效学习材料。

步骤三：轨迹与步骤选择
* 若有成功轨迹，选择步骤质量最高的轨迹。
* 若全失败，选择局部合理步骤比例最高的轨迹。
* 筛选：仅保留 Critic 判定为合理的局部步骤，将长链路轨迹转化为密集的 Step-level 训练样本，避免强化错误动作。

步骤四：Hint-Contextualized Step-level GRPO
改造 GRPO 的使用方式。每个 Step-level 样本包含任务、截图、交互历史及当时的纠错提示。模型在带 Hint 的状态下采样多个候选动作，通过规则化 GUI Action Reward 进行组内比较。

实验设置：AndroidWorld 域内适配与 MobileWorld 跨域测试

基准测试：
* AndroidWorld（域内）：在 AndroidWorld App 生态中探索、生成任务、收集 Rollout 并训练，在 116 个任务上评测 Pass@1/2/3。
* MobileWorld GUI-only（域外）：在 117 个任务上测试，训练过程完全不使用任何 MobileWorld 数据。

基础模型：
* 通用模型：Qwen3-VL-8B
* GUI 专用模型：GUI-Owl-1.5-8B

数据规模：
生成 3249 个 AndroidWorld 候选任务（来自 20 个 App、527 个源轨迹），分别使用 200、400、900 个任务子集进行扩展性研究。

结果一：通用 8B 模型逼近闭源 GUI 专用基座

论文 Table 1：AndroidWorld 域内适配与 Scaling 结果

• Qwen3-VL-8B：基线 Pass@3 为 55.2%。经 900 个自动生成任务适配后，ForgeQwen3-8B Pass@3 提升至 67.2%（Pass@1: 40.5%→50.9%, Pass@2: 49.1%→60.3%）。
• 对比：接近 GUI-Owl-1.5-8B 的 69.0% Pass@3。这证明真实 App 交互中的无标注反馈可有效转化为能力提升。
• GUI-Owl-1.5-8B：基线 Pass@3 为 69.0%。适配后 ForgeOwl-8B 达到 77.6%（Pass@1: 56.0%→67.2%）。
• 难度分析：MobileForge 对 Easy/Medium 任务提升稳定；在 Hard 任务上，GUI-Owl-1.5-8B 单次成功率从 19.3% 提升至 29.8%。

结果二：域内适配实现跨域泛化

论文 Table 2：MobileWorld GUI-only 跨域泛化结果

• ForgeOwl-8B：在 MobileWorld GUI-only 上达到 41.0%成功率，高于基线 GUI-Owl-1.5-8B（37.6%），并优于多个 Open-Data Mobile GUI Agent。
• ForgeQwen3-8B：从 Qwen3-VL-8B 的 7.6% 提升至 10.3%。
• 启示：跨域泛化能力强烈依赖基础模型的 GUI 理解力。MobileForge 能组织和强化已有能力，但若基座对移动 UI 理解较弱，迁移收益受限。

消融实验：数据飞轮的动力来源

论文通过多组消融实验验证各模块有效性：

1. 纠错提示（Hint）的关键作用
* 在 200 个生成任务上，无 Hint 多次尝试总成功率 52.0%；加入 Hint 后提升至 77.0%。
* Pass@3 从 49.0% 提升至 72.5%，平均步数从 18.4 降至 17.2。
* 结论：多次尝试的有效性源于反馈在任务间的累积，而非随机采样。

论文 Table 3：纠错提示 Rollout 消融

2. 训练目标选择
* 比较 No-Hint SFT、Hint SFT 及 Hint-Contextualized GRPO。
* No-Hint SFT 效果最弱；Hint-Contextualized GRPO 表现最佳（900 任务时 Pass@1 达 50.9%）。

论文 Table 4：训练目标消融

3. 任务过滤策略
* 最佳策略是移除已掌握任务（全成功），保留全失败和部分成功任务，利用步骤级反馈恢复合理局部动作。
* 有效任务成功率范围：[0.0, 0.9]。

论文 Table 5：任务级成功率过滤消融

4. 评价器模型鲁棒性
* 使用 Gemini 2.5 Pro 效果最佳，但替换为 Qwen3-VL-8B 仍能显著提升性能（Pass@1: 40.5%→44.8%, Pass@3: 55.2%→60.3%）。
* 结论：反馈优化闭环不依赖特定闭源评价器。

论文 Table 6：MobileGym-Critic 模型消融

5. 课程 Grounding 方式
* 以 Broccoli 任务为例，仅基于 Landing Screen 生成任务会导致功能覆盖单一（如菜谱删除占 27.3%）。
* 基于探索轨迹的 MobileGym-Curriculum 能覆盖购物清单、设置、媒体分享等更广泛功能。

论文 Table 7：不同任务挖掘方法功能覆盖对比（以 Broccoli 为例）

案例研究：在重复 UI 流程中保持任务意图

案例：Pro Expense 多支出删除
* 任务：删除 Streaming Services、Unexpected Expenses 和 Pet Supplies 三项支出。
* 基线问题：Qwen3-VL-8B 能进入删除流程，但在删除早期项目后丢失任务流，反复开关侧边栏，无法完成剩余删除。
* MobileForge 改进：ForgeQwen3-8B 能沿同一 App 的删除模式连续处理多个项目，最终完成全部删除。

论文 Figure 7：AndroidWorld ExpenseDeleteMultiple2 案例对比

分析：
MobileForge 提升的并非单次点击能力，而是在 App 特定流程中保持任务意图、复用操作模式、避免重复错误的能力。

失败率分析：
MobileForge 在 verification、search、complex UI、screen reading、repetition、information retrieval 等与 App Grounding 强相关的能力上提升显著。但在 game-playing、multi-app、memorization、math-counting 等任务上仍具挑战，表明系统在长程状态管理、跨 App 协调及非标准规则方面仍有改进空间。

论文 Figure 8：AndroidWorld 不同任务标签下失败率下降热力图

结语

MobileForge 不仅是一种无标注适配方法，更是一套面向 GUI Agent 的数据飞轮：
1. 探索：Agent 在真实 App 中探索功能。
2. 转化：MobileGym 将交互轨迹转化为任务和层级反馈。
3. 优化：HiFPO 将成功、失败与纠错提示沉淀为 Step-level 策略更新信号。

在此闭环中，数据不再依赖人工标注，而是源于 Agent 与目标 App 的持续交互。每一次尝试、失败与修正，都成为下一轮优化的燃料。这标志着手机 GUI Agent 的进化路径正从“依赖静态数据集训练”转向“在动态 App 生态中自探索、自反馈、自优化”。MobileForge 让这条无标注数据飞轮真正运转起来。