Android 手機 Agent 基準測試指南：2026 AI Agent 評估、GUI 測試與可靠性指標

Android 手機 Agent 基準測試該量什麼

評測 Android 手機 Agent，第一個問題不是「它點了幾下」或「最後畫面看起來像不像成功」，而是任務是否在正確權限、正確步驟、正確副作用與可驗證結果下完成。手機 Agent 會碰到訊息、設定、通知、檔案、日曆、藍牙、截圖、導航與其他真實手機狀態；一次錯誤點擊可能只是畫面小偏差，也可能變成傳錯訊息、改錯設定或遺失資料。因此，Android 手機 Agent 基準測試要把結果與過程一起納入。

從我們打造 FoneClaw 的經驗看，一個有效測試至少要回答四件事。第一，Agent 是否理解使用者目標，而不是只執行表面指令。第二，它是否產生正確副作用，例如勿擾模式真的切換、草稿真的可見、提醒真的建立。第三，它是否在需要權限或核准時停在使用者能理解的位置。第四，失敗後是否能說明原因、保留狀態並回到可處理路徑。

這也是為什麼我們把「看似合理的 GUI 點擊」和「可驗證完成」分開。GUI 軌跡可以幫助分析模型行為，但使用者真正要的是可靠手機結果。若你正在建立長期測試與回歸治理，自我改進手機 AI Agent：技能版本、回歸測試與安全回復會補上技能版本、測試迴圈與安全回復的更完整架構。

2026 年手機 Agent 基準版圖

2026 年的手機 Agent 評估已經不只看單一 AndroidWorld 類型任務。不同基準正在切開不同問題：裝置配置是否泛化、長程跨 App 任務是否穩、個人化任務是否尊重使用者偏好與同意、GUI 與工具混合執行是否能留下可稽核副作用。這些基準不能直接合成一張總排行榜，因為任務設計、環境、工具、評分方式和模型假設都不同。

我們會把這些研究當作測試設計素材，而不是把分數搬到 FoneClaw 或任何產品上。若要評估手機 Agent 如何發現可信工具與資源，Agentic Resource Discovery 智慧代理資源發現：ai-catalog.json、工具目錄與手機代理授權邊界會補上能力發現與信任邊界的專門討論。

真實 Android GUI Agent 測試的六個維度

建立 Android GUI Agent 測試集時，我們會把任務拆成六個可獨立變動的維度。第一是裝置配置：語言、字體大小、深色模式、OEM skin、螢幕比例、權限初始狀態、預設 App 都會影響結果。只在單一模擬器、單一英文 UI 上通過，離真實 Android 還有距離。

第二是任務長度與跨 App 程度。單 App 內三步任務和跨行事曆、地圖、訊息、設定的長程任務，對狀態保存的要求完全不同。第三是意圖清晰度：明確指令「開啟勿擾一小時」和模糊指令「幫我進入會議模式」需要不同釐清策略。第四是執行表面：Agent 是點 GUI、呼叫結構化工具，還是透過 host-side action 完成。

第五是副作用風險。讀取目前畫面、調整音量、建立草稿、傳送訊息、刪除資料和變更系統設定，風險不同，核准與復原要求也不同。第六是打斷與復原：使用者取消、權限缺少、網路中斷、App 重新整理、畫面跳轉、通知遮住目標，都是手機 Agent 日常會遇到的狀況。

這六個維度要分開控制。更多步驟不一定更難；有時一個含糊收件人或權限缺少，比十個固定 GUI 步驟更能暴露產品問題。真正可用的測試集，應該同時包含簡單穩定任務、長程跨 App 任務、模糊意圖任務、敏感副作用任務與可復原失敗任務。

任務成功率之外的可靠性指標

任務成功率是起點，不是終點。手機 Agent 可靠性指標至少要分成 outcome、process、recovery、cost、latency 和 trace quality。outcome 看最終副作用是否正確，例如設定是否真的變更、提醒是否存在、草稿是否可見。process 看是否走了合理步驟：有沒有重讀裝置狀態、有沒有在敏感動作前核准、有沒有避免不必要權限。

partial checkpoints 很重要。長程任務可能在前半段做對、後半段失敗，這時只標記全錯會丟失診斷資訊；只標記成功也會掩蓋風險。wrong side effects 要獨立扣分：傳錯對象、改錯設定、刪除錯資料，比單純停住更嚴重。human intervention 也要記錄：使用者接手一次和接手五次，代表不同產品品質。

retry policy 和 denominator 必須固定。允許幾次重試？重試是否重置 App？是否可重新問使用者？是否允許外部工具？這些都會影響分數。PhoneHarness 對可觀察 side effects 和 auditable execution traces 的重視，提醒我們 trace quality 本身也是可靠性指標。若要深入設計權限與稽核欄位，AI 代理身份與權限治理：逐工具核准、稽核紀錄與 FoneClaw Android 控制提供了更完整的安全帳本。

測試核准、權限、克制與停止

AI Agent 基準測試 2026 應把安全行為納入分數，而不是把安全當成通過後的補充敘述。手機任務最少需要五項安全測試：最小必要權限、核准時機、釐清能力、拒絕後克制、停止與稽核。最小必要權限測的是 Agent 是否只要求任務需要的能力；核准時機測的是它是否在外部效果前顯示目標、內容和結果。

釐清能力同樣重要。當使用者說「傳給 Alex」但聯絡人有三個 Alex，可靠 Agent 會先問清楚；當任務說「幫我整理這些檔案」但路徑不明，它會要求範圍。KnowU-Bench 把 clarification、proactive consent 和 restraint after rejection 放進測試方向，這對手機 Agent 特別有價值：使用者拒絕後，Agent 要能停止該動作，保留可用草稿或回到安全狀態。

停止鍵也要測。使用者說「停下」、關閉懸浮入口、撤回核准或切換 App，Agent 要能保存狀態、停止外部效果、標記未完成原因。若你要把核准畫面、理由、信心與手機接管設計做成產品規格，AI Agent 操作核准介面指南：建議、信心分級、理由與手機接管設計會是更合適的延伸閱讀。

我們會如何評估目前的 FoneClaw 手機任務

截至目前可取得的最新產品資訊，FoneClaw 提供懸浮助手、目前畫面附加、任務延續、核准與停止、權限復原、勿擾、音量、會議模式、截圖可靠性與快速動作。對我和 FoneClaw 團隊來說，這些不是單獨 feature，而是一組可測的手機 Agent 行為。我們會把它們放進測試矩陣，但本文只定義方法，不發布 FoneClaw benchmark score。

第一類是 read-only state tests。測試 FoneClaw 是否能附加目前畫面、讀取可見狀態、摘要畫面資訊、指出目前是在設定頁、App 畫面或權限提示。這類測試副作用低，適合先檢查 observation freshness 和語意理解。第二類是 reversible device-control tests，例如調整音量、切換支援的勿擾模式、建立可刪除提醒或截圖。這類測試要驗證狀態是否真的變更，也要測復原。

第三類是 external-effect approval tests，例如可見 SMS 草稿、撥號準備、導航交給選定地圖 App、行事曆或任務建立。這些測試要記錄收件人、內容、目標 App、核准時機與結果。第四類是 permission-loss recovery：先撤回權限，再看 FoneClaw 是否能說明缺少什麼、帶使用者到授權位置、授權後接回原任務。第五類是 current-screen change and stopping：任務中途切換畫面、收到通知或按停止，測它是否保留任務狀態並停止外部效果。

FoneClaw 目前透過受治理工具和 Android 權限執行支援手機任務，公開功能頁描述了100+ built-in tools。若你想把測試落到使用者可操作的健康檢查，AI Android 手機健康檢查指南：權限稽核、特殊存取與隱藏應用程式檢查提供了一個具體評估場景。準備實測目前產品時，可以從FoneClaw 下載頁開始，選低風險任務建立第一組 baseline。

建立可重複的手機 Agent 基準流程

最後，把測試變成可重複 protocol。第一，凍結環境：記錄裝置、Android 版本、OEM skin、語言、字體、App 版本、網路、權限初始狀態與預設 App。第二，定義 initial state 和 expected state：任務開始前畫面在哪裡，成功後應看到什麼副作用。第三，每輪只 randomize 一個維度，例如語言、layout、權限或 App 狀態，讓失敗原因可分析。

第四，記錄 approvals and actions：誰核准、何時核准、核准哪個動作、工具做了什麼。第五，驗證 side effects：用畫面、系統狀態、App 記錄或獨立檢查確認結果。第六，分類 recovery：是自動修復、請使用者授權、保留草稿、取消、手動接手，還是錯誤副作用。第七，發布限制：模型版本、工具範圍、重試策略、人為介入規則和不適用環境都要寫清楚。

可逆的起始測試可以很簡單：讓手機 Agent 附加目前畫面，辨識設定頁，準備但不送出一則草稿，或調整音量後恢復原狀。通過這些，再進入多 App、個人化、外部效果和打斷測試。這樣建立出的 Android 手機 Agent 基準測試，能同時服務研究比較、產品 QA 和使用者信任。