AI 自動用手機哪家強？MobiAgent、Mobile-Agent、Mobilerun 和 mobile-use 對比

最近連續整理了四個行動端 GUI 智能體專案：MobiAgent、Mobile-Agent、Mobilerun 和 mobile-use。它們都和「讓 AI 操作手機或行動 App」有關，但定位並不一樣。

簡單說：MobiAgent 更像可客製化的手機智能體研究系統；Mobile-Agent 是通義實驗室圍繞 GUI agent 的系列工作集合；Mobilerun 更偏向可落地的本地/雲端行動裝置控制框架；mobile-use 則強調真實 App 操作、任務拆解、資料抽取和 AndroidWorld 評測。

基本資訊對比

MobiAgent

MobiAgent 來自 IPADS-SAI，定位是一個可客製化的手機智能體系統。它不是只提供一個執行腳本，而是把 MobiMind 模型家族、AgentRR 動作記錄與回放、MobiFlow 評測基準、手機 runner、資料採集和 Android app 放到同一套體系裡。

它的特點是研究系統比較完整。MobiAgent 關注真實手機任務中的準確率、效率、記憶和可複用動作序列。README 中提到的使用者畫像記憶、經驗記憶、動作記憶，以及多任務執行，都說明它在嘗試處理長期任務和重複任務。

它的門檻也相對高。完整運行需要裝置、ADB、模型部署、依賴環境、可選的向量資料庫和圖資料庫配置。更適合研究或工程實驗，不太像面向普通使用者的「安裝即用」手機助手。

它解決什麼問題

手機 GUI 智能體比網頁或桌面自動化更麻煩。它需要理解截圖、識別控制項、決定下一步操作，還要透過 ADB 或行動端運行環境執行點擊、輸入、返回、切換應用等動作。真實任務往往不是單 App 內的一次操作，而是跨越搜尋、購物、社交、支付、地圖等多個應用的連續流程。

MobiAgent 的價值在於把這些環節系統化：

• 用 MobiMind 承擔任務規劃、決策和介面定位等能力。
• 用 runner 連接手機，透過 ADB 執行預定義任務並記錄軌跡。
• 用 AgentRR 複用成功動作序列，降低重複任務的推理與操作成本。
• 用 MobiFlow 評測真實行動場景中的任務完成情況。
• 透過資料採集、標註和處理工具，降低行動 GUI 任務資料建構成本。

這讓它更像一個行動智能體實驗平台，而不是只能跑展示的模型專案。

最近更新值得關注

專案 README 顯示，MobiAgent 在 2025 年 8 月開源，之後持續補齊模型、Runner、記憶系統和端側運行能力。2025 年 12 月開始，專案支援在手機上進行純端側推理，並發布了統一 GUI agent runner，可配置 MobiAgent、UI-TARS、AutoGLM、Qwen-VL、Gemini 等多種模型。

到 2026 年 3 月，專案又發布了 GUI-based mobile “claw” MobiClaw，以及新的 MobiMind-1.5-4B 模型。這說明它的方向不只是論文復現，而是在繼續把行動端執行、模型能力和操作工具鏈往產品化方向推進。

記憶系統是關鍵補丁

MobiAgent 支援使用者畫像記憶、經驗記憶和動作記憶。使用者畫像記憶用於給規劃提供偏好上下文；經驗記憶用於檢索類似任務的執行經驗；動作記憶則透過 AgentRR 快取和複用成功動作序列。

這很重要，因為手機任務天然帶有重複性。比如使用者常用某個 App 搜尋商品、打開固定聯絡人、在特定頁面填寫資訊。如果每次都從零開始看圖、規劃和點擊，成本高且容易出錯。記憶模組可以把一部分「已經學會的流程」沉澱下來，讓後續任務更快、更穩定。

不過，記憶也會帶來新的治理問題。使用者偏好、歷史任務、應用路徑和操作軌跡都可能包含敏感資訊。真正落地時，專案需要明確哪些內容進入記憶、保存多久、如何刪除，以及是否允許模型在不同任務之間複用這些上下文。

適合誰關注

如果你只是想找一個現成的手機自動化 App，MobiAgent 目前仍更偏研究和工程框架。它需要配置模型服務、行動裝置、ADB、依賴環境和任務檔案，完整跑起來有一定門檻。

但如果你關注行動 GUI agent、端側智能體、多模型 runner、任務軌跡複用或智能體評測，MobiAgent 很值得跟蹤。它把模型、執行、評測和資料流水線放在一起，能幫助研究者和開發者更完整地觀察行動智能體的真實短板。

Mobile-Agent

Mobile-Agent 來自 X-PLUG/通義實驗室。這個倉庫已經從早期手機操作智能體，擴展成一個 GUI 智能體家族：Mobile-Agent-v1/v2/v3/v3.5、Mobile-Agent-E、PC-Agent、GUI-Critic-R1、UI-S1、GUI-Owl、ToolCUA 等都在同一條技術線上。

它的特點是跨度大。Mobile-Agent 不只關心手機，還覆蓋桌面、瀏覽器、雲手機、雲桌面、GUI 感知、grounding、錯誤診斷、強化學習和 GUI/工具路徑編排。GUI-Owl 系列模型讓它更像一個跨平台 GUI agent 基礎模型路線，而不是單一行動自動化專案。

它的不足也來自這個跨度：倉庫更像研究成果集合，使用者需要先判斷自己要跑哪個子專案、哪個模型和哪個場景。它適合跟蹤技術演進和復現實驗，不一定是最快接入業務流程的選擇。

它解決什麼問題

GUI 智能體面對的不是標準 API，而是應用介面。它需要看懂螢幕、定位控制項、規劃步驟、執行點擊或輸入，並在失敗時修正路徑。行動端場景尤其複雜，因為任務往往跨多個 App，介面狀態也會隨著登入、權限、彈窗、網路和個性化推薦變化。

Mobile-Agent 系列把這個問題拆成了幾個方向：

• 用 Mobile-Agent-v1/v2 探索手機 GUI 的視覺感知與多智能體協作。
• 用 PC-Agent 把多智能體操作擴展到 PC 場景。
• 用 Mobile-Agent-v3 和 v3.5 推進多平台 GUI 智能體框架。
• 用 GUI-Owl 系列模型提供跨平台 GUI 感知、定位和端到端操作能力。
• 用 GUI-Critic-R1、UI-S1、ToolCUA 等工作補足錯誤診斷、強化學習和 GUI/工具路徑編排。

這讓它不像一個單點 demo，而更像一條圍繞「電腦使用智能體」的研究和工程路線。

v3.5 的重點

倉庫 README 顯示，Mobile-Agent-v3.5 已經可以透過 ModelScope 線上 Demo 和阿里雲百煉線上 Demo 體驗，百煉上也提供了 v3.5 API。2026 年 3 月，v3.5 還上線了阿里雲無影雲手機，面向雲端 Android 環境提供行動使用體驗。

這說明專案正在把「本地跑實驗」之外的使用方式也補上。對於 GUI 智能體來說，雲手機和雲桌面很重要：它們能提供更穩定、更可復現的運行環境，減少本地裝置、系統版本、解析度和 App 狀態帶來的差異。

如果你想評估這類智能體，穩定環境往往比模型本身更容易被低估。沒有可控的執行環境，就很難判斷一次失敗是模型能力不足、介面變化、裝置問題，還是任務定義不清。

GUI-Owl 是底層變化

Mobile-Agent-v3 之後，GUI-Owl 成了這條路線裡的關鍵模型層。README 中把 GUI-Owl 描述為具備 GUI 感知、grounding 和端到端操作能力的多模態跨平台 GUI VLM。到 GUI-Owl-1.5，模型系列已經覆蓋 2B、4B、8B、32B、235B，並支援桌面、行動端和瀏覽器自動化。

這類模型的意義在於，它不只是回答「螢幕裡有什麼」，還要把自然語言目標、截圖內容、介面元素位置和下一步操作連起來。對 GUI agent 來說，視覺理解、座標定位、操作規劃和狀態記憶缺一不可。

當然，模型越通用，工程邊界也越重要。真實部署時仍然需要執行器、權限控制、任務日誌、回滾機制和人工確認。尤其是涉及支付、帳號、檔案、訊息發送等高風險操作時，GUI agent 不能只追求自動完成，還要能清楚說明自己準備做什麼。

ToolCUA 暗示的新方向

2026 年 5 月，專案新聞裡提到 ToolCUA，定位是面向 GUI 與工具最優路徑編排的端到端 Computer Use Agent。這個方向很有意思，因為它承認了一個現實：不是所有任務都應該靠點螢幕完成。

有些事情適合 GUI 操作，比如登入後台、處理複雜表單、讀取沒有 API 的應用狀態；有些事情更適合調用工具，比如檢索、計算、解析檔案、訪問結構化介面。真正可用的電腦使用智能體，需要學會在兩者之間切換。

這也是 Mobile-Agent 系列比早期手機自動化專案更值得看的地方。它不再只問「智能體能不能像人一樣點 App」，而是在問「智能體什麼時候該看螢幕，什麼時候該用工具，什麼時候該停下來確認」。

適合誰關注

如果你只是想找一個開箱即用的手機自動化助手，Mobile-Agent 仍然偏研究和工程框架。它涉及模型、運行環境、評測任務和具體執行器，完整跑通通常需要一定配置成本。

但如果你關注下面幾類問題，它很值得跟蹤：

• 行動端 GUI agent 如何從展示走向穩定執行。
• 桌面、瀏覽器和手機自動化能否統一到同一套智能體框架裡。
• GUI 模型如何處理 grounding、反思、記憶和錯誤診斷。
• 智能體如何在 GUI 操作與工具調用之間選擇路徑。
• 雲手機、雲桌面是否會成為 GUI agent 的重要運行環境。

這些問題會直接影響個人助理、企業流程自動化、遠端桌面操作、應用測試和無 API 系統整合。

Mobilerun

Mobilerun 來自 droidrun，定位更工程化：讓 LLM agent 透過自然語言控制 Android 和 iOS 裝置。它提供 CLI、TUI、Docker、Python API、Portal-based control、vision mode、reasoning mode、結構化輸出、自訂工具、app cards、執行軌跡和雲端裝置服務。

它最突出的地方是模型無關和部署形態清楚。開發者可以接 OpenAI、Anthropic、Gemini、Ollama、DeepSeek、OpenRouter 或 OpenAI-compatible providers；也可以選擇本地框架或 Mobilerun Cloud。對真實團隊來說，這種「裝置控制層和模型層解耦」的設計很重要。

它也有行動端自動化常見的門檻：Android 需要開發者選項、USB 偵錯和 Portal app；iOS 需要單獨流程；複雜任務還要處理權限彈窗、頁面變化、失敗重試和日誌排查。它更適合願意把 mobile agent 當成工程元件接入的人。

它解決什麼問題

行動端自動化最麻煩的地方，是自然語言任務和真實裝置操作之間隔著很多層。模型需要知道目前打開了什麼 App、頁面有哪些控制項、是否需要截圖補充視覺資訊、下一步該點哪裡，以及執行失敗後如何繼續。

Mobilerun 把這些能力整理成一套框架：

• 透過 CLI 和 TUI 運行一次性自然語言任務、檢查裝置、回放巨集和偵錯流程。
• 透過 Python API 建構自訂行動自動化工作流。
• 支援 Android 和 iOS，Android 透過 Portal app 和無障礙能力控制裝置，iOS 走單獨的 Portal 流程。
• 同時使用 accessibility tree 和截圖，讓模型既能讀結構化 UI，也能看視覺畫面。
• 支援 --vision、--vision-only 和 --reasoning 等模式，應對不同複雜度的任務。
• 支援結構化輸出、app cards、自訂工具、憑據和執行軌跡追蹤。

這讓 Mobilerun 更像一個「行動端 agent runtime」，而不是單純把截圖發給大模型再模擬點擊。

本地框架和雲端服務

Mobilerun 把本地框架和 Mobilerun Cloud 分得比較清楚。本地框架適合開發者在自己的機器和裝置上運行 agent，拿到更強的程式碼級控制；Cloud 則面向託管裝置、REST API、SDK 和規模化工作流。

這個分層很重要。很多行動自動化場景開始時只是「幫我在手機上跑一個任務」，但一旦進入團隊使用，就會遇到裝置管理、並發、日誌、失敗重試、權限和 API 調用的問題。Cloud 不是替代本地框架，而是把裝置運維和工作流接入往後端服務方向推進。

README 中還區分了幾類雲端裝置：使用者自己的硬體、託管雲手機、託管實體手機。這裡的差別不只是成本，也涉及應用風控、身份可信度和任務穩定性。對電商、社交、金融或本地生活類 App 來說，真實裝置和虛擬裝置的表現可能完全不同。

為什麼 LLM 無關很關鍵

行動 GUI agent 還處在快速變化階段，很難說哪一家模型長期最好。不同任務對模型的要求也不一樣：有的更依賴視覺理解，有的更依賴長鏈路規劃，有的更看重工具調用，有的則需要低成本批量執行。

Mobilerun 選擇模型無關的框架路線，價值在於把裝置控制、任務執行、日誌追蹤和模型選擇拆開。開發者可以先穩定裝置側流程，再根據任務成本、準確率和延遲切換模型。

這對實際落地很有幫助。企業不會只因為一個模型展示效果好就重寫裝置控制層；更合理的方式是保留統一執行框架，把模型當成可替換元件。

適合哪些場景

Mobilerun 當前適合幾類需求：

• 行動 App QA 和回歸測試。
• 從原生 App 中抽取資料並返回結構化結果。
• 自動執行重複性的手機任務。
• 為非技術使用者封裝自然語言行動操作流程。
• 在多台裝置上運行自動化任務。
• 把日程、通知或自訂觸發器接入行動端工作流。

不過，它也不是「安裝後立刻替你管手機」的消費級助手。Android 側需要 ADB、開發者選項、USB 偵錯和 Portal app；iOS 側也有自己的接入流程。真正跑穩定，還要處理模型配置、裝置狀態、權限彈窗和任務失敗恢復。

mobile-use

mobile-use 來自 minitap-ai，目標是讓 AI agent 使用真實 Android 和 iOS App。它支援自然語言控制、UI-aware automation、資料抽取、不同 LLM 配置，並強調 AndroidWorld 基準表現。README 中還提到專案是首個在 AndroidWorld benchmark 上達到 100% 的 agentic framework。

它的亮點是任務拆解和結構化抽取。比如從 Gmail 中找未讀郵件，並按指定 JSON 格式返回寄件者和主題，這類任務比「打開設定看看電量」更接近真實生產需求。它把行動 GUI agent 從「會操作」推進到「能把 App 裡的資訊整理出來」。

它的限制主要在裝置支援和運行環境。Android 可以用實體手機或模擬器；iOS 目前主要支援 macOS 上的模擬器，物理 iOS 裝置還不支援。Docker 快速啟動也主要面向 Android。評估它時，要先確認目標裝置和 App 場景能否被當前執行通道覆蓋。

它和普通手機自動化有什麼不同

傳統手機自動化通常依賴腳本、座標、控制項 ID 或固定流程。它適合穩定頁面，但遇到介面變化、彈窗、搜尋結果、列表滾動和跨 App 操作時，很容易失效。

mobile-use 的路線是讓 AI agent 直接處理自然語言目標和 UI 狀態：

• 使用者用自然語言描述任務，不必預先寫死每一步。
• 框架讀取行動端介面，並結合模型判斷下一步操作。
• 可以從 App 中抽取資訊，並按指定格式返回，比如 JSON。
• 支援不同 LLM 配置，包括 OpenAI API compatible providers。
• Android 可以透過實體手機或模擬器運行，iOS 目前主要面向 macOS 上的模擬器。

這類框架更適合「半結構化」的行動任務：目標明確，但每次頁面狀態、資料內容和路徑不完全一樣。

AndroidWorld 結果值得注意

mobile-use README 中提到，專案在 AndroidWorld benchmark 上達到 100% 完成表現，並連結了對應論文。無論具體評測細節如何，這都說明專案團隊把「任務拆解」和「可評測執行」放在了很高的位置。

這點比單純展示更關鍵。GUI agent 最容易出現的問題是：一個影片裡看起來很聰明，但換一個任務、裝置或初始狀態就不穩定。基準測試不能完全代表真實使用，卻能逼迫系統面對一組標準化任務，並暴露規劃、定位、恢復和狀態理解能力。

README 中的論文題目也點出了方向：透過任務拆解提升 AndroidWorld 準確率。對行動端智能體來說，複雜任務往往不能靠一個大提示詞直接完成，而需要拆成可執行子任務，並在每一步檢查狀態。

資料抽取是實用入口

mobile-use 的一個現實場景是從原生 App 中抽取資料。很多資訊並不暴露在 API 中，只能在 App 介面裡查看，比如郵件列表、訂單狀態、社交內容、營運後台、訊息通知等。

README 給出的示例是打開 Gmail，找到未讀郵件，並把寄件者和主題整理成 JSON。這個方向很實用，因為它把行動 GUI agent 從「幫我操作一下」推進到「幫我把 App 裡的資訊結構化拿出來」。

不過，這也帶來邊界問題。資料抽取涉及帳號、隱私、平台條款和訪問權限。真正使用時，應該明確裝置歸屬、任務授權、資料保存方式和輸出範圍，不能把手機介面當成無限制的資料源。

部署門檻和限制

mobile-use 支援從平台快速開始，也支援從原始碼運行。原始碼方式需要配置 .env、LLM 配置和依賴環境；Android 側可以使用實體手機或模擬器，Docker 快速啟動目前主要面向 Android；iOS 側需要 macOS、Xcode 和 Facebook 的 iOS Development Bridge，README 也說明物理 iOS 裝置暫不支援。

這些限制並不意外。行動端自動化比瀏覽器自動化更依賴裝置、系統權限和偵錯通道。尤其是 iOS，系統封閉性更強，能穩定接入模擬器已經有價值，但離「任意真實 iPhone 自動化」還有距離。

因此，評估 mobile-use 時不要只看模型效果，還要看自己的目標裝置、App 類型、運行環境和合規邊界是否匹配。

適合誰關注

mobile-use 適合幾類人關注：

• 想研究 AndroidWorld、行動 GUI agent 和任務拆解方法的研究者。
• 想把自然語言行動操作接入內部工具的開發者。
• 需要從原生 App 抽取結構化資料的團隊。
• 做行動 App QA、回歸測試或探索式測試的人。
• 想比較 mobile-use、Mobilerun、Mobile-Agent 等不同行動端智能體路線的人。

如果目標是一個面向普通使用者的手機助手，它目前還偏工程和研究框架；如果目標是驗證行動端 agent 的可行性，它提供了一個很好的開源起點。

功能對比

優缺點對比

MobiAgent 的優點是系統完整，適合研究手機 GUI agent 的模型、記憶、加速和評測閉環；缺點是部署鏈路長，工程配置重，普通開發者上手成本較高。

Mobile-Agent 的優點是技術路線最寬，能看到 GUI agent 從手機走向桌面、瀏覽器、工具調用和基礎模型的演進；缺點是專案族複雜，想直接落地某個具體場景時，需要先做較多篩選。

Mobilerun 的優點是工程介面清晰，模型無關，本地框架和雲服務分層明確，適合把行動裝置自動化接入產品或內部工具；缺點是仍然要面對行動裝置權限、環境、App 狀態和雲端成本問題。

mobile-use 的優點是聚焦真實 App 使用、任務拆解和結構化資料抽取，AndroidWorld 方向也讓它更容易評估；缺點是 iOS 物理裝置支援有限，完整使用仍然需要配置模型、裝置和運行環境。

適用範圍建議

如果你要做行動智能體研究，優先看 MobiAgent 和 Mobile-Agent。前者更聚焦手機端系統閉環，後者更適合觀察 GUI agent 的跨平台演進。

如果你要做行動 App 自動化、QA、資料抽取或內部工作流，優先看 Mobilerun 和 mobile-use。Mobilerun 更像可接入工程系統的運行框架，mobile-use 更適合驗證自然語言 App 操作和結構化抽取。

如果你關注未來個人助手形態，四個都值得跟蹤。MobiAgent 代表手機 agent 的系統化研究，Mobile-Agent 代表跨平台 GUI agent 路線，Mobilerun 代表裝置控制基礎設施，mobile-use 代表真實 App 任務拆解和評測驅動路線。

我的判斷

這四個專案的差異說明，行動端 GUI agent 已經不只是「讓模型看截圖點按鈕」。真正的問題變成了：模型如何理解介面，執行器如何穩定控制裝置，任務如何拆解和評估，雲端裝置如何管理，結果如何結構化返回，風險如何被限制。

短期內，最現實的落地場景會是 QA、資料抽取、內部流程自動化和受控裝置池。長期看，誰能把裝置控制、模型能力、權限邊界、日誌追蹤和使用者確認機制做穩，誰就更接近真正可用的行動端 AI 助手。