当前手机上的GUI Agent确实已经具备较强的执行能力，能够识别屏幕内容、完成点击和文字输入，甚至跑通一些端到端的任务流程。然而，当尝试将这些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 scaling 趋势、域内适配结果和 MobileWorld 跨域泛化结果

论文的共同第一作者包括浙江大学APRIL实验室的博士生刘广义、硕士生赵鹏翔、硕士生吴高，以及清华大学博士生殷翊文，通讯作者为浙江大学的刘勇教授。目前，MobileForge已实现全链路开源，相关代码、数据、模型、训练及评测流程均已开放。

论文：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
MobileForge 全链路数据：https://huggingface.co/collections/lgy0404/mobileforge-datasets
MobileForge 全链路模型：https://huggingface.co/collections/lgy0404/mobileforge-models

手机 GUI Agent 的瓶颈：并非操作能力不足，而是缺乏适应能力

过去一年里，GUI Agent领域的发展确实十分迅速。从网页到桌面再到手机，越来越多的模型已经能够依据截图和任务描述，执行点击、滑动、输入、返回以及打开App等操作。但移动端自有其独特的难题。

首先，移动端App生态极其碎片化。不同App的页面布局、功能入口以及交互逻辑差异巨大；即便是同一个App，一旦更新版本，按钮位置、菜单层级甚至任务流程都可能发生彻底改变。

其次，移动端的任务流程通常较长。一项任务可能涉及打开App、进入特定页面、执行搜索、筛选、选取条目、确认操作，甚至还可能需要跨多个App协同完成。在这种情况下，如果仅提供一个最终成功或失败的稀疏奖励信号，将很难定位具体是哪个环节出了问题。

再次，现有的一些“无标注”GUI学习方法，虽然减少了人工数据依赖，但普遍存在两个瓶颈：一是探索、任务生成、执行和反馈未能形成一个完整的闭环；二是在策略优化过程中，模型往往将单次执行路径视为孤立的样本，依赖粗粒度奖励，难以从失败轨迹中蕴含的正确局部动作中真正学到有价值的信息。

论文 Figure 2：已有方法的两个瓶颈以及 MobileForge 的解决思路

MobileForge正是针对这两个问题而设计的。

研究团队提出了一个直接的问题：能否构建一套专为手机GUI Agent打造的适配系统，使其不依赖于人工任务、专家演示或奖励标签，而是让任务从目标App的真实交互中自然生成，反馈足够精细，同时将Agent自身采样的经验全部转化为可供优化的策略信号？

MobileForge = MobileGym + HiFPO

MobileForge由两个相互耦合的组件构成。

首先是MobileGym，它是交互与评估的基石。它负责探索目标App中所有可达的状态，基于真实的交互轨迹挖掘可执行的任务，并对Agent的完整执行过程进行细粒度的分层评估。

其次是HiFPO，全称为Hierarchical Feedback-Guided Policy Optimization，即层级反馈引导的策略优化。它负责调度多次尝试、复用前一次失败经验中产生的纠错提示、筛选有价值任务和步骤，最后通过hint-contextualized step-level GRPO来更新模型。

Figure 3：MobileForge 总体流程

我们可以将MobileForge想象成一条从“真实App交互”到“策略更新”的全自动化流水线：

目标App探索 → 任务课程生成 → 多次rollout → 分层评估 → 任务/轨迹/步骤过滤 → 带纠错提示的GRPO训练。

这条流水线中，无需人工编写任务、无需专家演示，也无需人工标注奖励信号。

MobileGym：首先在真实App中发现“可以学习什么”

MobileGym解决的问题是数据来源：既然没有人工任务和示范，Agent究竟该学习什么？

它包含三个关键阶段。

第一阶段是目标App探索。MobileForge直接进入目标App，结合APK中声明的activity等结构信息以及当前截图，生成面向功能的探索目标。探索过程类似于深度优先遍历，当需要从某个父状态分支到一个新目标时，系统会先恢复这个父状态，再继续向下探索。

这里生成的探索轨迹并不被视为专家示范。其作用在于发现真实App中究竟有哪些页面是可达的、哪些控件是可操作的、哪些功能是实际存在的——从而避免模型凭空幻想某个App应该支持什么。

每个被探索到的状态转移，都会记录操作前后的截图、执行的动作、目标元素、执行元数据以及自然语言摘要。这些记录被存入一个“证据池”，供后续任务生成使用。

第二阶段是MobileGym-Curriculum。它将探索证据转化为可执行的任务。针对每一条探索轨迹，系统首先判断这段行为是否连贯、原始目标是否完成，然后围绕同一个App功能生成多个任务变体。

论文将一个生成任务表示为五元组：任务指令、预估步数预算、核心功能、变化类型和前置条件。这个模式非常轻量，重点不在于形式上的复杂，而在于每个任务都必须锚定到真实且被观测到的App行为上。

第三阶段是MobileGym-Critic。这里不训练一个单独的奖励模型，而是采用agentic hierarchical evaluator对一个完整的rollout进行分层评估。给定一次任务执行，Critic会输出三类反馈：轨迹级outcome label、步骤级process label，以及一个纠错hint。

轨迹级标签回答“这个任务最终是否完成”；步骤级标签回答“每一步是否合理，如果合理或不合理，原因是什么”；纠错提示则总结失败原因、需要避免的行为、建议的替代策略以及关键任务洞察。

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

这套分层反馈机制非常关键。传统做法通常将一次rollout简化为成功或失败，但在长链路的手机任务中，失败的轨迹可能包含正确的局部步骤，成功的轨迹中也可能存在冗余甚至偶然的动作。MobileGym-Critic的作用，就是将它们细致地拆分开来。

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

MobileGym负责生成任务和反馈，而HiFPO则负责将这些反馈转化为策略更新。

论文 Figure 5：HiFPO 流程图

它的第一步是带提示的多次尝试。对于每个任务，HiFPO会让当前策略连续尝试K次。第一次尝试没有额外提示；如果失败，或出现了不合理的步骤，MobileGym-Critic就会生成一个纠错hint。第二次尝试时，这个hint会被追加到指令中，帮助模型避免重复犯错。

换句话说，Agent并非简单地多采几次样，而是在同一个任务上“积累经验”。前一次失败会成为下一次尝试的上下文语境。

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

第二步是任务过滤。HiFPO会计算同一任务多次尝试的经验成功率SR(x)。如果一个任务的所有尝试都成功了，说明当前策略已经掌握，训练价值不大，因此被过滤掉。反之，那些全部失败的任务和部分成功的任务，都会被保留下来。

这与许多直觉不同。MobileForge并不简单地将失败任务丢弃，因为失败的轨迹中很可能包含正确的打开App、导航、搜索或识别步骤。只要步骤级反馈能够将合理动作挑选出来，失败同样可以转化为有效的学习材料。

第三步是轨迹与步骤选择。对于保留下来的任务，如果存在成功的轨迹，系统会选择步骤质量最高的那一条；如果全部失败，则选择局部合理步骤比例最高的那一条。随后，训练集只保留那些被Critic判定为合理的局部步骤。

这样一来，长链路的轨迹被拆解为密集的step-level训练样本，同时也避免了将失败轨迹中的错误动作也强化进去。

第四步是hint-contextualized step-level GRPO。HiFPO并未发明一个全新的优化器，而是改造了GRPO的使用方式。每个step-level样本都包含任务、截图、交互历史，以及当时可用的纠错提示。模型在同一个带hint的状态下采样多个候选动作，再通过规则的GUI action reward进行组内比较。

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

实验基于两个基准。

AndroidWorld是域内设置。MobileForge在AndroidWorld的App生态内进行探索、生成任务、收集rollout并训练，最终在116个AndroidWorld任务上评测Pass@1、Pass@2和Pass@3。

MobileWorld GUI-only是域外设置。论文在其117个任务划分上进行测试，但训练过程中不使用任何MobileWorld的rollout、任务或反馈。

基础模型包括两个8B规模的instruct agent：通用模型Qwen3-VL-8B和GUI专用模型GUI-Owl-1.5-8B。

MobileForge共生成了3249个AndroidWorld侧的候选任务，这些任务来自20个App、527个源轨迹。为研究扩展效果，论文分别采用了200、400和900个任务子集进行训练。

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

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

在AndroidWorld上，Qwen3-VL-8B基线的Pass@3为55.2%。经过900个自动生成任务的适配之后，ForgeQwen3-8B的Pass@3提升至67.2%，Pass@1从40.5%跃升至50.9%，Pass@2也超过了60%。

这意味着，一个通用VLM，在不依赖任何人工标注的情况下，已经逼近了那些在闭源数据上精心训练过的GUI专用模型——后者基线的Pass@3为69.0%。这个结果说明，真实App交互中的无标注反馈，确实能够转化为实实在在的能力提升。

性能更强的GUI专用模型同样能继续受益。GUI-Owl-1.5-8B基线在AndroidWorld上的Pass@3为69.0%；经过MobileForge适配，ForgeOwl-8B达到了77.6%的Pass@3，Pass@1也从56.0%提升至67.2%。

按任务难度来看，MobileForge对easy和medium任务的提升非常稳定；在GUI-Owl-1.5-8B上，hard任务的单次成功率也从19.3%提升到了29.8%。

结果二：仅使用 AndroidWorld 适配，也能迁移至 MobileWorld

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

跨域测试是更具说服力的验证：它能说明适配不仅仅是“记住了训练过的App”。论文在MobileWorld GUI-only上评估时，没有使用任何MobileWorld上的任务、轨迹或反馈进行训练。

结果显示，ForgeOwl-8B在MobileWorld GUI-only的117个任务划分上取得了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的理解较弱，迁移的收益也将有限。

消融实验：MobileForge 的数据飞轮究竟如何运转？

论文进行了多组消融实验，分别验证了纠错提示、训练目标、任务过滤、评估器选择以及课程生成方式各自的作用。

首先是纠错提示。使用Qwen3-VL-8B在200个生成任务上进行rollout，如果不加入前一次失败的hint，多次尝试的总成功率为52.0%；加入纠错提示后，总成功率直接跃升至77.0%。Pass@3也从49.0%提升至72.5%，平均每次尝试的步数从18.4降至17.2。

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

这说明，多次尝试之所以有效，并非是因为模型随机多采了几次样，而是因为反馈在同一任务的多次尝试之间得以积累，形成了可复用的经验。

其次是训练目标。论文比较了no-hint SFT、hint SFT和hint-contextualized GRPO。结果显示，no-hint SFT效果偏弱，甚至可能低于基线；加入了hint的SFT有所提升，但带hint上下文的GRPO在200和900任务两种设置下均表现最佳。在900任务时，hint-contextualized GRPO达到了50.9%的AndroidWorld Pass@1。

论文 Table 4：训练目标消融

第三是任务过滤。论文发现，最佳策略并非移除失败任务，而是移除当前模型已经完全掌握的“mastered tasks”，保留那些全部失败和部分成功的任务，再通过步骤级反馈从中恢复合理的局部动作。对应的成功率范围是[0.0, 0.9]。

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

第四是评估器模型。MobileGym-Critic中的final-decision model使用Gemini 2.5 Pro时效果最好。但即便换成Qwen3-VL-8B作为决策模型，仍然能将基线的Pass@1从40.5%提升至44.8%，Pass@3从55.2%提升至60.3%。这表明MobileForge的反馈到优化的闭环，并不完全依赖于某一款特定的闭源评估器。

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

第五是课程基础。以Broccoli这个App为例，如果仅基于landing screen生成任务，结果高度集中于菜谱创建、编辑和删除这些首页可见功能，其中菜谱删除就占了27.3%。而基于探索轨迹的MobileGym-Curriculum则能够覆盖购物清单、烹饪助手、膳食计划、设置、媒体分享等更广泛的功能。

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

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

论文提供了一个AndroidWorld上的案例。任务要求在Pro Expense里删除三项支出，分别是Streaming Services、Unexpected Expenses和Pet Supplies。

基础版的Qwen3-VL-8B能够进入删除确认的流程，但在删除了早期的一个项目之后，就会丢失任务流，反复打开和关闭侧边栏，无法继续完成剩下的删除操作。经过MobileForge适配后，ForgeQwen3-8B能够沿着同一个App的删除模式，连续处理多个项目，最终完成了全部删除。

论文 Figure 7：AndroidWorld ExpenseDeleteMultiple2 案例对比

这个案例非常典型。MobileForge提升的其实并非单次点击的能力，而是在一个App的具体流程中保持任务意图、复用操作模式、避免重复犯同一个错误的能力。

论文还进行了一项tag-wise failure-rate reduction分析。结果显示，MobileForge在verification、search、complex UI、screen reading、repetition、information retrieval这些与App grounding强相关的能力上提升明显。同时，game-playing、multi-app、memorization、math-counting这类任务仍然偏困难，说明当前系统在长程状态、跨App协调和非标准任务规则方面仍有改进空间。

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

结语

MobileForge的价值，不仅在于它提供了一种无标注的适配方法，更在于它展示了一套真正能够运转的数据飞轮：Agent在真实App中探索功能，MobileGym将交互轨迹转化为任务和层级反馈，HiFPO再把成功、失败与纠错提示沉淀为step-level的策略更新信号。

在这套闭环中，数据不再依赖于人工编写任务、录制演示、标注奖励，而是源于Agent与目标App的持续交互。每一次尝试、失败和修正，都有机会成为下一轮优化的燃料。

这也意味着，手机GUI Agent的进化路径，正在从“依赖静态数据集训练”转向“在动态App生态中自探索、自反馈、自优化”。而MobileForge，恰好让这根无标注的数据飞轮，真正地转动了起来。