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