Mobilerun 是 droidrun 開源的行動裝置自動化框架，目標是讓 LLM agent 可以用自然語言控制 Android 和 iOS 裝置。它提供行動端原生工具，讓智能體能夠檢查 UI 狀態、理解截圖、點擊、滑動、輸入、規劃多步任務，並透過 CLI 或 Python API 返回結果。
這個專案的定位很清楚：它不綁定某一家模型，而是做行動裝置與智能體之間的執行層。README 中列出的模型來源包括 OpenAI、Anthropic、Gemini、Ollama、DeepSeek、OpenRouter 以及 OpenAI-compatible providers。對開發者來說，這比「只支援一個模型的展示專案」更實用。
它解決什麼問題
行動端自動化最麻煩的地方，是自然語言任務和真實裝置操作之間隔著很多層。模型需要知道目前打開了什麼 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 側也有自己的接入流程。真正跑穩定，還要處理模型配置、裝置狀態、權限彈窗和任務失敗恢復。
我的判斷
Mobilerun 的價值在於把行動裝置控制做成了可程式化、可觀測、可替換模型的 agent 框架。它承認行動自動化不是一個模型問題，而是模型、裝置、執行器、日誌、工具和雲端基礎設施共同組成的系統問題。
短期看，它適合開發者搭建行動端自動化原型和內部工具；長期看，這類框架可能會成為「手機上的 AI 工作流引擎」。如果 GUI agent 要進入真實業務，像 Mobilerun 這樣把本地運行、雲端裝置、結構化輸出和追蹤能力放在一起的專案會越來越重要。
專案連結：droidrun/mobilerun