不用人工標注，GUI Agent跑數據飛輪：快手、浙大開源MobileForge

大模型驅動的手機 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/MobileForge
• Huggingface Daily Paper：https://huggingface.co/papers/2606.19930
• MobileForge 全鏈路數據：https://huggingface.co/collections/lgy0404/mobileforge-datasets
• MobileForge 全鏈路模型：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 讓這條無標注數據飛輪真正轉了起來。