hero

城武導讀

如果你看過任何一支手機 agent 的 demo 影片，你大概看過這樣的畫面：模型看了一眼螢幕截圖，算出一個座標，點下去，app 跳到下一頁——然後所有人鼓掌。這叫「GUI grounding」，是過去兩年手機 agent 評測的標準劇本。

這篇論文做的事情很簡單，但也很殘酷：它把鏡頭往後拉，問了一個沒有人想問的問題——你點到下一頁了，然後呢？任務真的完成了嗎？ 點開 Uber app 跟真的叫到一台車，中間隔著一整個世界。PhoneHarness 是第一個認真把這個差距變成一套可量測基準的系統，而且它的核心洞察不在視覺能力，而在一個被嚴重低估的決策問題：agent 什麼時候該放下截圖、拿起 CLI。

原文摘要

PhoneHarness 由騰訊混元（Tencent Hunyuan）與中大、清華的研究團隊提出，是一套混合動作基準與執行框架（benchmark + harness），用來研究手機 agent 在可驗證的真實工作流上的表現。它將手機 agent 的問題從「能不能點對按鈕」從新定義為「任務的可觀測副作用是否真實發生」。

核心命題：Harness 與 Benchmark 的共生

論文將 PhoneHarness 拆成兩個彼此依存的構件：

  1. PhoneHarness（執行框架）：在裝置端運行 agent loop，支援 CLI + GUI + MCP-style tool 三種動作空間，結合確定性動作路由（deterministic action routing）與有限制的 GUI 委派（bounded GUI delegation），產生可審計的執行軌跡。
  2. PhoneHarness Bench（評測基準）：建立在 harness 之上的任務集，評分不依賴答案字串比對，而是透過執行軌跡驗證任務的副作用是否真實發生（檔案是否寫入、郵件是否發送、app 狀態是否改變）。

論文的核心主張：可靠的手機自動化，關鍵在於動作介面的路由決策與可驗證的執行，而不僅僅是視覺 GUI 控制能力。

Host-Device 架構

PhoneHarness 採用主機端（Host）與裝置端（Device）分離的設計，避免把所有依賴全部塞進手機： Host-Device 架構

關鍵設計原則：agent 的思考與決策迴圈留在裝置端、貼近手機環境，但 GUI 截圖、模型推論、外部工具等重型依賴全部透過 proxy 在主機端處理。這避免了「所有東西擠在手機上跑」的脆弱性，也保留了 agent 對裝置狀態的直接感知。

三種動作空間與 Deterministic-First Routing

PhoneHarness 提供三種動作 affordance，agent 必須自行判斷何時使用哪一種： 路由決策流程

三種模式的具體對照：

  • GUI or CLI 替代：當同一個操作可透過 app 互動或 shell/ADB 完成時，優先選擇更可靠的路徑。例如：開啟 app 可以用 GUI 點擊圖示，也可以透過 adb shell am start——後者確定性高、不受畫面佈局影響。
  • GUI-primary + optional CLI：以 GUI 為主，但允許 CLI/MCP 輔助。例如：在 app 中填寫表單（GUI），但用 CLI 查詢系統通知來獲取需要填入的資料。
  • GUI-only fallback：當沒有結構化路徑可用時，退回純 GUI 操作——點擊、滑動、視覺搜尋、表單填寫。

這個路由邏輯是 PhoneHarness 最核心的設計決策。消融實驗顯示：移除 deterministic-first routing 後，pass rate 從 75.0% 降到 68.2%——光是路由策略本身就貢獻了 6.8 個百分點。

Progressive Skill Disclosure

PhoneHarness 不把所有工具描述一股腦塞進 system prompt。系統提示詞中只包含一個精簡的技能索引（skill index）；agent 需要某個能力時，呼叫技能載入工具，取得該技能的使用說明與範例。這避免了「工具太多導致 agent 混淆」的常見問題。

PhoneHarness Bench：以副作用為證據的評測

Benchmark 的任務涵蓋四大類別：資訊檢索（Information Retrieval）、通訊（Communication）、文件處理（Document Processing）、多 app 複合工作流（Multi-app Workflows）。每個任務包含：自然語言指令、一組可驗證的副作用（檔案儲存、郵件發送、app 狀態變更）、基於軌跡證據的評分 rubric。

評分機制不是比對 agent 輸出的最終答案字串，而是：(1) 執行任務 → (2) 檢查執行軌跡是否有副作用發生的證據 → (3) 依照 rubric 判定 pass/fail。這將評測從「agent 說了什麼」轉移到「agent 實際上做了什麼」。

實驗結果

  • PhoneHarness：75.0% pass rate
  • 最強的非 PhoneHarness 設定：62.1%（差距 +12.9pp）
  • 移除 CLI 動作空間：降至 58.3%
  • 移除 MCP 工具：降至 64.7%
  • 移除 deterministic-first routing：降至 68.2%

錯誤分析：失敗的四種面貌

PhoneHarness 的 trace 機制讓失敗不再是模糊的「沒過」，而是可以被分類診斷。論文將失敗歸為四類：

  1. Routing 錯誤：agent 選了錯誤的動作空間（該用 CLI 卻走 GUI、該用 Tool 卻硬點畫面）
  2. Grounding 錯誤：在 GUI 模式中辨識或定位目標失敗（點錯按鈕、找不到 UI 元素）
  3. 驗證 false negative：任務實際上完成了，但 harness 的副作用檢測未能捕捉到完成訊號
  4. 理解錯誤：agent 從根本上誤解了任務的語意目標

安全設計與限制

PhoneHarness 內建安全護欄：動作白名單（禁止危險 ADB 指令）、工具輸出消毒、可審計軌跡支援事後安全審查。論文坦承目前僅支援 Android（無 iOS）、75% pass rate 仍意味著每四個任務就有一個失敗、trace-based 評分可能遺漏部分合法完成、工具集限於預定義範圍無法處理任意 app 功能。

城武觀點

1. 這個領域終於有人問了對的問題：任務完成了，還是畫面到了？

手機 agent 評測有一個很尷尬的共識：大家都在比「有沒有點對按鈕」，但沒有人比「任務有沒有真的完成」。

原因不難理解。GUI grounding 好評測——你有一張螢幕截圖、一個標註過的正確座標、算一下距離就是分數。但要驗證「Uber 真的叫到了」或「日曆事件真的建立成功了」，你需要一個比截圖更豐富的 ground truth 機制。PhoneHarness 的答案是「可觀測副作用」（observable side effects）——不是看畫面，是看狀態：系統 log、檔案系統變更、API 回傳、app 資料庫寫入。

這個轉變聽起來很直覺，但在手機 agent 領域幾乎沒有人做。原因也簡單：驗證副作用比驗證座標難一個數量級。 你需要一個真正在裝置上跑的 harness、需要對每個任務定義什麼叫「完成」的可測量訊號、需要處理任務成功但副作用訊號遺失的邊緣案例（false negative）。PhoneHarness 是第一個把這整套 infra 做出來的團隊——光是這個工程貢獻就值得一篇論文。

而這個轉變背後有一個更深層的哲學問題：當一個領域的評測指標長期停留在「proxy metric」（GUI 畫面到達率），整個領域的研究方向就被這個 proxy 綁架了。 過去兩年，手機 agent 的所有進步幾乎都發生在視覺 grounding 上——更好的螢幕理解、更準的座標預測、更強的 UI-tree parsing。這些都是重要的能力，但它們回答的是一個錯的問題：不是「任務完成了沒」，而是「畫面到了沒」。PhoneHarness 把問題拉回正軌。

2. Action Routing 才是真核心——不是視覺能力，是決策架構

PhoneHarness 最被低估的設計決策是：它把動作空間拆成三種——GUI、CLI、Tool——然後讓 agent 自己決定何時用哪一種。這件事比聽起來更根本。

現有的手機 agent 大多只有一個動作空間：GUI。模型看到畫面、輸出點擊、等待下一張畫面、再輸出點擊。這對某些任務沒問題（打開 app、填表單），但對需要「查詢—判斷—執行—驗證」的複合任務完全不夠。舉一個具體例子：

你要 agent「把昨天那封 email 裡的會議連結加到日曆」——

  • 如果只有 GUI，步驟會是：打開 Gmail app → 捲動 → 截圖 → OCR → 找到連結 → 打開日曆 app → 手動建立事件 → 貼上連結。每一步都是視覺猜測，每一步都可能出錯。
  • 如果有 CLI + Tool，步驟會是：用 CLI 查詢系統通知紀錄找到 email 摘要 → 用 Tool 呼叫日曆 API 建立事件 → 用 GUI 打開日曆 app 確認事件真的出現了（最後一步作為可選的驗證）。

PhoneHarness 的洞察是：動作空間的選擇本身就是一個需要被評測的能力。 一個好的手機 agent 不只是會看畫面點按鈕，它必須知道什麼時候不要看畫面——什麼時候該直接下指令、什麼時候該呼叫 API。這是一個決策架構問題，不是一個視覺理解問題。

消融實驗的數字非常誠實：移除 CLI 動作空間，pass rate 直接掉到 58.3%（-16.7pp）；移除 deterministic-first routing，掉到 68.2%（-6.8pp）。CLI 動作空間的貢獻甚至比 routing 策略本身更大——這表示有大量的任務根本不需要 GUI 就能完成，但如果你不給 agent CLI 這個選項，它就只能被迫用最慢、最不穩的方式硬幹。

我們花了兩年把手機 agent 的視覺能力推到極限，回頭才發現有一整類任務根本不需要視覺——它們需要的是 agent 知道什麼時候該放下截圖。

3. 75% Pass Rate 的兩面性：很好，但離「可部署」還很遠

12.9 個百分點的提升是實打實的。在一個被 GUI-only baseline 統治的領域，75% vs. 62% 是一個壓倒性的訊號。但我們也必須誠實面對另一面：還有 25% 的任務是失敗的。

在學術論文中，75% 是一個漂亮的數字。在產品中，25% 的失敗率意味著使用者每用四次就出一次錯——而且是那種「任務沒有完成」的錯，不是「按鈕點歪了但最後還是成功」的軟失誤。想像你今天請手機 agent 幫你發一封重要郵件，四次裡面就有一次它會沈默地失敗——你不會信任它。

而 PhoneHarness 最有價值的地方正在這裡：它的 trace 機制讓失敗不再是模糊的「沒過」，而是可以被解剖的。 論文把失敗拆成四個完全不同的源頭：

  • Routing 錯誤（該用 CLI 卻走 GUI，反之亦然）→ 需要更好的 action router
  • Grounding 錯誤（點錯按鈕、找不到 UI 元素）→ 需要更好的視覺模型
  • 驗證 false negative（任務完成了但 harness 沒偵測到）→ 需要更完善的副作用檢測機制
  • 理解錯誤（從根本誤解任務目標）→ 需要更強的語言理解與規劃能力

這四種失敗對應的是四個完全不同維度的工程問題。把 75% 推到 95%，需要同時解決 routing、grounding、驗證、理解四個問題——這不是單一模型升級能做到的。任何想把手機 agent 產品化的團隊，都必須面對這個現實：沒有一顆銀彈，你需要在四條戰線上同時作戰。

而這正是 PhoneHarness 作為一個基準的真正價值：它不只告訴你「過了」還是「沒過」，它提供了解剖失敗的解剖刀。傳統的 GUI 評測做不到這一點——你只會看到 agent 停在錯的畫面，但你不知道它為什麼停在那裡。

4. 「可稽核性」是手機 Agent 從研究到產品的隱形門檻

PhoneHarness 一個不太被討論但非常關鍵的設計是：auditable execution traces。

現有的手機 agent 大多是一個黑箱：輸入截圖、輸出動作。如果 agent 做了一個錯誤的操作——例如刪除了不該刪的檔案、發了不該發的訊息、把聯絡人資料洩漏到錯的 app——你無法回溯它為什麼做出這個決定，因為中間沒有任何結構化的決策紀錄。你只能看到「它在某個畫面點了一個按鈕」，但你不知道它在點下去之前「想」了什麼。

PhoneHarness 的 trace 機制——outer trace（工具呼叫與結果）加上 nested GUI traces（截圖與動作序列）——解決的不是準確率問題，是信任問題。

在手機這種高度個人化的裝置上，信任不是 optional。你可以容忍 agent 偶爾犯錯，但你不能容忍它犯錯之後你完全不知道發生了什麼——不能追溯、不能診斷、不能修正。一個黑箱 agent 在手機上的風險不是「它可能會錯」，而是「你無法知道它什麼時候會錯、錯了什麼、為什麼錯」。

這個設計對業界產品的啟示是深遠的：手機 agent 的競爭不會只發生在準確率上。 可稽核性、可中斷性、可回溯性——這些「安全基建」才是決定一個手機 agent 能不能真正部屬到使用者裝置上的關鍵。Apple 和 Google 不會讓一個無法解釋自己行為的 agent 拿到系統級權限。PhoneHarness 的 trace 機制為這個問題提供了一個具體的工程方向，而目前在這個方向上，整個領域幾乎是空白的。

城武的未解檔案——我們花了兩年把視覺 grounding 從 70% 推到 90%，這篇論文卻告訴我們：那只是入場券。真正決定手機 agent 能不能用的，是它知不知道什麼時候該放下截圖、拿起 CLI。而那失敗的 25%，每一種死法都需要一條完全不同的戰線——這不是最後一哩路，這是四條平行的一哩路。