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