大模子驱动的手机 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 让这条无标注数据飞轮真正转了起来。。。。。。
