远见网一、那么成本会迅速失控
1、大模型驱动的手机GUI Agent理
大模型驱动的手机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 scaling趋势、域内适配结果和MobileWorld跨域泛化结果
论文的共同第一作者为浙江大学APRIL实验室的博士生刘广义、硕士生赵鹏翔、硕士生吴高和清华大学博士生殷翊文，通讯作者为浙江大学刘勇教授。
2、论文与https
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
MobileForge全链路数据：https://huggingface.co/collections/lgy0404/mobileforge-datasets
过去一年，GUI Agent研究进展很快。
从网页、桌面到手机，越来越多模型可以根据截图和任务描述执行点击、滑动、输入、返回、打开应用等操作。
但移动端有其特殊困难。
二、不是不会点与而是不会适应
1、移动App生态极其碎片化
首先，移动App生态极其碎片化。不同App的页面结构、功能入口、交互逻辑差异很大；
2、即便是同一个App
即便是同一个App，版本更新后也可能改变按钮位置、菜单层级和任务流程。
三、移动端任务往往是长链路的
1、移动端任务往往是长链路的
其次，移动端任务往往是长链路的。
一个任务可能需要打开应用、进入某个页面、、筛选、选择条目、确认操作，甚至跨多个App传递信息。
只给最终成功 / 失败的稀疏奖励，很难判断到底是哪一步出了问题。
第三，已有 “无标注” GUI学习方法虽然减少了人工数据依赖，但通常仍存在两个断点：探索、任务生成、执行和反馈没有形成统一底座；
策略优化时，模型往往只把一次rollout当成孤立样本，依赖粗粒度奖励，难以从失败轨迹中的正确局部动作中学习。
2、研究团队提出的问题是：构建一个不依赖
论文Figure 2：已有方法的两个瓶颈以及MobileForge的解决思路
MobileForge正是围绕这两个问题设计的。
研究团队提出的问题是：能否构建一个不依赖人工任务、专家示范或奖励标签的手机GUI Agent适配系统，让任务生成来自目标App真实交互，让反馈足够细粒度，并把Agent自己采集到的经验转化为可优化的策略信号？
MobileForge = MobileGym + HiFPO
四、MobileForge由两个耦合组件组成
一是MobileGym，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功能生成多个任务变体。
论文中将一个生成任务表示为五元组：任务指令、预估步数预算、核心功能、变化类型和前置条件。
这个schema很轻量，重点不在形式复杂，而在于每个任务都必须锚定到真实观察到的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从49.1% 提升到60.3%。
这使得一个通用VLM在AndroidWorld上接近GUI-Owl-1.5-8B基座的69.0% Pass@3。
考虑到MobileForge不使用人工任务、专家演示或人工奖励标签，这个结果说明真实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。
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模型消融
第五是课程grounding。
以Broccoli任务为例，只基于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提出的不只是一种无标注适配方法，更是一套面向GUI Agent的数据飞轮：Agent在真实App中探索功能，MobileGym将交互轨迹转化为任务和层级反馈，HiFPO再把成功、失败与纠错提示沉淀为step-level策略更新信号。
在这套闭环里，数据不再依赖人工写任务、录演示、标奖励，而是来自Agent与目标App的持续交互。
每一次尝试、失败和修正，都有机会成为下一轮优化的燃料。
这也意味着，手机GUI Agent的进化路径正在从 “依赖静态数据集训练”，转向 “在动态App生态中自探索、自反馈、自优化”。
MobileForge让这条无标注数据飞轮真正转了起来。
