AI手機時代需要怎樣的Agent Harness？

過去一年，AI 與手機的關系正在被重新定義：OpenAI AI Phone / AI Agent Phone 把「AI 原生手機」推到臺前，Gemini on Android 也在把系統級助手從問答帶向跨 App、多步驟任務協助。

這些信號指向同一個趨勢：AI 不再只是聊天框里的回答者，而是正在進入手機這個最日常、最復雜、也最具狀態性的計算環境。

騰訊混元牽頭，聯合 The Chinese University of Hong Kong、The Chinese University of Hong Kong, Shenzhen、Tsinghua University等機構的最新研究 PhoneHarness:A Mixed-Action Orchestration Harness and Benchmark for Phone Agents across CLI, GUI, and MCP Tools 關注一個更基礎的問題：當 AI 真正在手機上行動，我們如何讓它真正完成任務，并驗證它確實完成了？

作者團隊給出的結論是：

• 手機 Agent 的核心不只是「更會點屏幕」，而是能根據任務選擇 CLI、GUI、MCP 工具等合適的行動面；
• 真實手機 workflow 需要可驗證的副作用：文件是否生成、設置是否改變、郵件 / 日歷對象是否真的創建，都不能只靠模型口頭回答；
• PhoneHarness 提供 mixed-action 執行 harness；PhoneHarness Bench 則用 trace、系統狀態、App 結果和安全策略評估任務是否真的完成。

• 論文地址：https://phoneharness.github.io/assets/paper.pdf
• 項目主頁：https://phoneharness.github.io/
• GitHub：https://github.com/PhoneHarness/PhoneHarness
• HuggingFace Dataset：https://huggingface.co/datasets/PhoneHarness/phoneharness-bench

先看三個執行片段：手機 Agent 不只是點屏幕

下面三個 demo 展示了 PhoneHarness 想表達的核心差異：真實手機任務往往不是一條更長的 GUI 點擊鏈，而是 CLI、GUI、MCP-style tools 與 verifier 共同組成的執行 workflow。

Demo 1｜CLI-first：先讀設備狀態，再決定是否進入 GUI

視頻鏈接：https://mp.weixin.qq.com/s/I2ztL6sFiHGxAiCfh_FTqg

Demo 2｜Mixed workflow：MCP 檢索 + GUI 執行 + verifier 復核

視頻鏈接：https://mp.weixin.qq.com/s/I2ztL6sFiHGxAiCfh_FTqg

Demo 3｜Virtual display：后臺 GUI 執行與過程留痕

先把第一個問題說清楚：手機 Agent 真的「做了」嗎？

在很多手機 Agent 評測里，任務被拆成一連串 GUI 操作。模型觀察屏幕，決定下一步點哪里、滑哪里、輸什么。如果最后 UI 狀態看起來對，就算任務完成。

這套范式當然有價值。畢竟，手機確實是一個強 GUI 環境，真實 App 的搜索、瀏覽、點擊和輸入都需要視覺 grounding。

但對于 AI 手機時代的 Agent 來說，只會 GUI 操作遠遠不夠。

傳統 GUI-centric 視角：

• 把手機任務看成 screenshot → tap /swipe/type；
• 視覺感知幾乎是所有動作執行的前置操作；
• 更適合單 App、強視覺、低副作用任務。

PhoneHarness 的 mixed-action 視角：

• 把手機任務看成跨 CLI、GUI、MCP 工具的完整 workflow；
• 評估重點不是「看起來完成」，而是副作用是否真實發生、trace 是否可審計；
• 更適合系統設置、文件、搜索、郵件、日歷和跨 App 任務。

例如，「查一個 App 內的信息，再結合網頁搜索補充背景，并整理成郵件」這類任務，不是一個更長的點擊鏈。它同時包含 App 內 GUI 交互、外部信息檢索、文本處理、郵件副作用，以及最終結果驗證。

如果評測只看最終回答，就會漏掉最關鍵的問題：模型到底有沒有查對來源、有沒有真的創建文件、有沒有真的發出郵件、有沒有繞過了應該被確認的高風險操作？

核心判斷：PhoneHarness 的出發點很直接：手機 Agent 的評測不能只問「它會不會點屏幕」，而要問「它能不能在真實手機環境里把一件事做完，并留下可驗證證據」。

PhoneHarness：讓手機 Agent 的行動空間不止 GUI

PhoneHarness 的核心不是再造一個 GUI 點擊器，而是把手機任務放進一個混合動作空間里。

關鍵區別：問題不是「純 GUI 理論上能不能做」，而是「純 GUI 是否是可靠、高效、可驗證的動作抽象」。真實手機 workflow 往往同時跨越系統狀態、App 界面、文件、網頁、郵件、日歷和安全邊界。GUI 是重要入口，但不應該是唯一入口。

因此，mixed-action 不是給 GUI agent 加幾個外掛工具，而是讓 agent 在執行過程中為不同子目標選擇合適的 action surface：能用確定性命令讀取狀態，就不必反復點設置頁；必須進入 App 內完成交互時，才交給 GUI；需要外部信息、文件處理或結果復核時，則調用 host-side tools 或 verifier。

為什么 mixed-action 比純 GUI 更穩

PhoneHarness 架構圖：host-side orchestration 與 Android device-side execution 共同構成 mixed-action harness。

在 PhoneHarness 中，agent 可以在三類行動面之間切換：CLI /device-side commands、GUI delegation、以及 MCP-style host tools。

圖解：PhoneHarness 的三類行動面

PhoneHarness 的 mixed action space：CLI、GUI 與 MCP-style tools 在同一個 phone-agent loop 中共存。

這意味著，PhoneHarness 里的 agent 不必把所有任務都硬塞進 GUI 點擊鏈。它可以判斷：什么時候該走系統命令，什么時候該交給 GUI worker，什么時候該調用搜索、文檔、郵件、日歷等工具。

這種設計更接近 AI 手機時代的真實需求。AI 手機不是「在手機里放一個聊天機器人」，而是讓智能體能在復雜手機環境里理解目標、選擇行動、執行任務，并產生可檢查的結果。

PhoneHarness Bench：如何構建并驗證手機 workflow

有了 mixed-action harness，還需要一個能真正檢驗執行結果的 benchmark。原因很簡單：對手機 Agent 來說，能行動不等于真的完成了任務。

PhoneHarness Bench 建立在 PhoneHarness 之上，不把任務寫成抽象問答題，而是寫成一段可以執行、記錄和復核的 phone workflow。Agent 在執行過程中會留下截圖、CLI / MCP 操作、文件變化、系統狀態和 App 側結果；benchmark 再通過 task-specific verifier 判斷任務副作用是否真實發生。

Bench 的關鍵：PhoneHarness Bench 不問「模型有沒有說自己做完」，而是看「任務證據鏈是否支持它真的做完」。這也是它區別于純問答式評測和純 GUI 狀態評測的關鍵。

PhoneHarness Bench 如何驗證任務完成

Bench 是怎么構建的？

每個 PhoneHarness Bench task 都包含一個用戶目標、一組可調用行動面，以及一個面向副作用的 verifier。這樣，benchmark 評估的不是單步 GUI 操作，而是完整 workflow：任務輸入、agent loop、混合動作執行、trace 記錄、結果驗證和失敗歸因。

PhoneHarness Bench 的任務分布：覆蓋 device/system、single-app GUI、tool-assisted workflow 與 cross-app workflow。

為什么這能幫助分析失敗？

這條鏈路讓失敗不再只是一個籠統的「沒做對」。我們可以進一步區分：是外層 controller 沒有規劃好，是 GUI worker 沒有點對，是工具調用失敗，是環境不穩定，還是 verifier 沒有看到預期副作用。

代表性執行軌跡：截圖、CLI / MCP 操作卡片與 verifier 信號共同構成可審計證據鏈。

實驗發現：收益來自 mixed-action routing，不是單純更會點屏幕

在論文實驗中，我們沒有把 PhoneHarness 描述成一個「所有場景都更強」的 GUI agent。相反，實驗更清楚地顯示了它的邊界和價值。

PhoneHarness 的收益主要來自那些存在確定性路徑、工具輔助路徑或可驗證副作用的任務。比如設備狀態查詢、文件處理、網頁檢索、日歷 / 郵件 / 文檔相關 workflow，以及需要跨行動面組合的手機任務。

對于純 GUI-heavy 的任務，視覺 grounding、權限彈窗、登錄狀態、廣告、搜索結果不穩定等問題仍然會帶來挑戰。

實驗解讀：這個結論反而更重要：手機智能體的未來不是「把 GUI 點擊模型做得更大」，而是要讓 agent 學會選擇合適的行動面，并讓每一步執行都能被驗證。

mixed-action affordance 任務上的行動空間拆解。

不同任務類型下的執行步數，輔助理解效率差異。

當 AI 手機真正到來，我們會看到什么新瓶頸？

OpenAI AI Phone 和 Gemini on Android 之所以值得關注，不只是因為「大廠要做 AI 手機」。更重要的是，它們共同指向了一個產品范式變化：手機正在從 App-centric device 走向 Agent-centric device。

在 App-centric 時代，用戶自己負責拆解任務：打開哪個 App、點哪里、復制什么、搜什么、確認什么。

在 Agent-centric 時代，用戶表達目標，agent 負責調度行動。

AI 手機時代的新瓶頸

PhoneHarness 的切入點正是在這里：AI 手機時代需要的不只是更強的模型，還需要能承載真實執行的 harness，以及能驗證執行結果的 benchmark。

PhoneHarness 和 PhoneHarness Bench，到底推進了什么？

PhoneHarness 與 PhoneHarness Bench 的分工

這兩個產物是相互依賴的。

沒有 harness，benchmark 很難覆蓋真實混合任務。沒有 benchmark，harness 的執行能力也很難被系統性評估。

如果說過去手機 Agent 的競爭更像「誰更會看屏幕點按鈕」，那么 AI 手機時代真正重要的問題會變成：誰能把真實手機 workflow 做完，誰能留下可信證據，誰能在安全邊界內穩定執行。

PhoneHarness 回答的是「怎么讓手機 Agent 真的行動」。PhoneHarness Bench 回答的是「怎么確認它真的做成」。

AI 手機不是簡單地把大模型塞進系統。它意味著手機從 App-centric device 走向 Agent-centric device：用戶表達目標，agent 負責選擇路徑、調用工具、操作 App，并完成可驗證的結果。

這背后的基礎設施問題，比「模型會不會點屏幕」更復雜，也更關鍵。

PhoneHarness 和 PhoneHarness Bench 想推進的，正是這一層基礎設施：讓手機 Agent 的行動空間更接近真實世界，也讓評測更接近真實完成。

一句話總結：AI 手機時代，關鍵問題不只是模型能不能理解屏幕，而是它能否在真實手機環境里選擇正確行動面、完成可驗證任務，并留下可審計的執行軌跡。

作者信息

共同一作：Jason、Zhengyao Fang、Zhengyang Tang、Pengyuan Lyu。

完整作者：Jason, Zhengyao Fang, Zhengyang Tang, Pengyuan Lyu, Xingran Zhou, Xin Lai, Fei Tang, Liang Wu, Yiduo Guo, Weinong Wang, Junyi Li, Yi Zhang, Yang Ding, Huawen Shen, Sunqi Fan, Shangpin Peng, Zheng Ruan, Anran Zhang, Benyou Wang, Chengquan Zhang, Han Hu.

機構：Tencent Hunyuan; The Chinese University of Hong Kong; The Chinese University of Hong Kong, Shenzhen; Tsinghua University.