大模子驱动的手机 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 实验室的博士生刘广义、硕士生赵鹏翔、硕士生吴高和清华大学博士生殷翊文，，，，通讯作者为浙江大学刘勇教授。。。 。。MobileForge全链路开源，，，，代码、数据、模子、训练 / 评测 pipeline 都已开放。。。 。。
论文：https://arxiv.org/abs/2606.19930项目主页：https://mobile-forge.github.io/Github：https://github.com/kwai/MobileForgeHuggingface Daily Paper：https://huggingface.co/papers/2606.19930MobileForge 全链路数据：https://huggingface.co/collections/lgy0404/mobileforge-datasetsMobileForge 全链路模子：https://huggingface.co/collections/lgy0404/mobileforge-models
手机 GUI Agent 的瓶颈：不是不会点，，，，而是不会顺应
已往一年，，，，GUI Agent 研究希望很快。。。 。。从网页、桌面到手机，，，，越来越多模子可以凭证截图和使命形貌执行点击、滑动、输入、返回、翻开应用等操作。。。 。。但移动端有其特殊难题。。。 。。
首先，，，，移动 App 生态极其碎片化。。。 。。差别 App 的页面结构、功效入口、交互逻辑差别很大；；；；；即即是统一个 App，，，，版本更新后也可能改变按钮位置、菜单层级和使命流程。。。 。。
其次，，，，移动端使命往往是长链路的。。。 。。一个使命可能需要翻开应用、进入某个页面、搜索、筛选、选择条目、确认操作，，，，甚至跨多个 App 转达信息。。。 。。只给最终乐成 / 失败的希罕奖励，，，，很难判断究竟是哪一步出了问题。。。 。。
第三，，，，已有 “无标注” GUI 学习要领虽然镌汰了人工数据依赖，，，，但通常仍保存两个断点：探索、使命天生、执行和反馈没有形成统一底座；；；；；战略优化时，，，，模子往往只把一次 rollout 当成伶仃样本，，，，依赖粗粒度奖励，，，，难以从失败轨迹中的准确局部行动中学习。。。 。。
论文 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。。。 。。
论文 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 让这条无标注数据飞轮真正转了起来。。。 。。
