Android AI Agent 螢幕理解：UI 樹、截圖與混合視覺定位怎麼選
比較 Android AI Agent 使用無障礙 UI 樹、截圖或混合方法理解目前畫面的時機，包含證據品質、失敗模式、成本、隱私、驗證價值，以及 FoneClaw 如何用目前畫面資訊與截圖工具承接支援任務。
- Android AI Agent 螢幕理解應先看任務需要什麼證據：語意節點可靠時優先用 UI 樹，畫面關係或影像內容才需要截圖，兩者各有缺口時才使用混合流程。
- 無障礙樹提供文字、content description、角色、狀態、可點擊性、焦點、bounds 與階層，但節點可能缺失、過期、重複、語意不足或和實際畫面不一致。
- 截圖提供像素證據，適合處理圖片、圖表、地圖、canvas、自訂 UI 與視覺排列；它也會帶來更高資料量、隱私暴露、座標漂移與 OCR 誤判風險。
- FoneClaw 的實作方向是先用目前畫面資訊建立語意判斷，只在像素能回答真問題時加入截圖，並讓進度、必要核准、動作結果與重新驗證保持可見。
Android AI Agent 螢幕理解先選 UI 樹、截圖或混合
Android AI Agent 應使用 UI 樹還是截圖？我們在打造 FoneClaw 時採用的答案很務實：先看任務需要哪一種證據。若目標是找按鈕文字、確認 checkbox 狀態、讀取欄位標籤、選擇明確可點擊節點，優先使用無障礙樹這類語意結構。若任務依賴圖片、圖表、地圖、canvas、自訂繪製介面、視覺位置或顏色狀態，就需要截圖提供像素證據。若畫面同時有可靠節點與視覺缺口，才把兩者結合。
這不是「資料越多越好」的問題。UI 樹通常更精簡，也更接近可操作元素；截圖更接近使用者眼前畫面，但成本、隱私暴露和座標不確定性更高。多模態 Android 手機 Agent 若每次都截圖，會把不必要的畫面內容帶進推理；若只相信節點，又可能漏掉圖片裡的文字、圖表趨勢或自訂元件。
因此可用三條路徑判斷。第一，語意優先：用 UI 樹回答「這是什麼控制項、目前狀態如何、可做什麼動作」。第二，視覺補強：用截圖回答「它在畫面上長什麼樣、和其他元素的空間關係如何」。第三，混合驗證：先讀語意，再用最小必要截圖補齊視覺事實，最後用新的畫面狀態確認結果。完整手機控制迴圈可放到AI 代理控制 Android 手機指南：從意圖到確認、執行、驗證與復原中理解；本篇專注螢幕證據怎麼選。
無障礙樹能看見什麼，也會漏掉什麼
Android 無障礙樹是螢幕內容的階層式語意表示。Android 官方的Accessibility service 說明指出，無障礙服務可在使用者啟用並依服務設定授權後，透過事件取得畫面內容並代表使用者進行輔助互動；視窗內容擷取與手勢能力都需要明確設定。這類能力的定位是使用者啟用的 assistive technology，而不是繞過 App 權限的通用自動化捷徑。
在 API 層，AccessibilityNodeInfo 參考文件描述每個 node 可代表視窗內容中的一個元素。當 App 提供良好語意時，節點可能包含文字、content description、類別、狀態、可執行 action、是否 clickable、checked、focused、enabled，以及 bounds 和父子階層。這些欄位對 Agent 很有價值，因為它們能把「畫面上有什麼」轉成「哪個目標可被選取、狀態是否符合預期」。
UI 樹最適合處理結構化介面。例如表單欄位旁有標籤、清單項目有文字、設定開關有 checked 狀態、按鈕有 content description，Agent 就能用語意判斷目標，而不是只猜畫面座標。Android 的UI Automator 測試指南也展示了以 visible text、content description、resource identifier 與 hierarchy relationship 尋找 UI element 的價值；這可說明階層化互動在測試與驗證中的重要性，但不代表所有產品都採用同一套測試框架。
UI 樹的限制同樣明確。第一，某些自訂繪製內容不會拆成有用節點。第二，節點文字可能缺失、過度重複或 content description 寫得模糊。第三，畫面動畫、重新整理或彈出 overlay 會讓先前讀到的節點變舊。第四，同名按鈕、巢狀清單或隱藏狀態可能讓目標不唯一。第五，節點 bounds 可能存在，但不代表點擊一定達成使用者意圖。FoneClaw 在處理目前畫面時，會把這些訊號視為可用證據，而不是絕對真相。
什麼時候需要像素證據
截圖提供的是像素證據。它捕捉當下使用者看見的畫面：圖片、顏色、排版、圖示、圖表、地圖、廣告、canvas、遊戲畫面、自訂 UI，以及 UI 樹未提供語意的文字或視覺關係。當問題是「圖表哪一段最高」、「地圖上的目的地在哪個方向」、「這張截圖中的地址是什麼」、「畫面右上角是否有紅色警示」時，單靠節點通常不夠。
手機 Agent 何時需要截圖？第一，目標內容以圖片或自訂繪製呈現，UI 樹只顯示一個容器。第二，文字經由圖片或 canvas 顯示，需要 OCR 或視覺模型判讀。第三，任務依賴空間關係，例如「左邊那張票券」、「圖表下方的藍色按鈕」。第四，App 提供節點，但使用者關心的是實際可見結果，例如是否被鍵盤遮住、是否出現 loading、是否有浮層蓋住按鈕。
截圖也有自己的失敗模式。第一，OCR 讀到文字，不代表已理解控制項語意。第二，截圖是某個瞬間，動畫、轉場、鍵盤、通知或 loading 可能讓座標很快失效。第三，螢幕方向、解析度、縮放、分割畫面與 overlay 會影響座標。第四，截圖可能包含敏感內容，例如訊息、通知、帳戶名稱或健康資訊。第五，視覺模型可能把圖示、徽章或相似按鈕混淆。
因此，截圖應回答具體視覺問題，而不是成為每次任務的預設輸入。若 UI 樹已清楚提供「儲存」按鈕的節點與 enabled 狀態，截圖未必能提升結果。若畫面是設計稿、照片或地圖，截圖才是必要證據。需要在懸浮介面中把目前畫面交給 Agent 的使用情境，可閱讀Android 懸浮 AI 助手與目前畫面：提問、核准、執行與復原指南。
用證據品質比較 UI 樹與截圖
UI 樹與截圖不是競爭關係，而是兩種不同證據。語意節點回答「這個元素是什麼、狀態如何、可做什麼」；像素回答「使用者眼前看見什麼、位置與外觀如何」。多模態 Android 手機 Agent 的品質，通常取決於能否選擇足夠但不過量的證據。
| 比較面向 | UI 樹／無障礙節點 | 截圖／像素證據 | 採用判斷 |
|---|---|---|---|
| 文字與標籤 | 若 App 提供語意，文字和 content description 通常精簡可讀 | 可透過 OCR 補足圖片文字，但可能誤讀 | 先用節點，圖片文字再補截圖 |
| 角色與狀態 | 可提供 clickable、checked、focused、enabled 等狀態 | 只能從外觀推測，無法直接證明內部狀態 | 狀態判斷優先用節點 |
| 圖片與圖表 | 常只看到容器或替代文字 | 能看見實際圖像、顏色與空間關係 | 視覺內容需要截圖 |
| 成本與延遲 | 通常較精簡，適合快速篩選目標 | 資料量更大，可能增加處理成本與延遲 | 先讀精簡訊號，再決定是否補圖 |
| 隱私暴露 | 暴露節點文字、描述與結構 | 可能包含整個可見畫面與敏感細節 | 只在必要時擷取最小畫面脈絡 |
| 驗證價值 | 適合確認控制項狀態與新畫面階層 | 適合確認可見效果、遮擋與視覺結果 | 根據預期結果選驗證方式 |
| 典型失敗 | 節點缺失、語意錯誤、重複、過期、bounds 不準 | OCR 錯、座標漂移、隱私過量、動畫瞬間、遮擋誤判 | 低信心時停止或請使用者確認 |
這張表的實務結論很簡單：UI 樹適合行動意圖與狀態，截圖適合視覺事實與可見結果。若兩者衝突，Agent 應降低信心，重新檢查目前畫面或請使用者選擇，而不是直接操作。表單填寫尤其容易同時需要欄位語意與畫面位置；相關情境可參考Gemini 表單填寫在 Android 上能做什麼？自動填表、手機 AI Agent 與安全檢查。
建立語意加視覺的混合定位流程
行動 Agent 如何結合語意與視覺定位？我們建議用 inspect、capture、reconcile、approve、act、verify 六段流程。這比「先截圖再猜」穩定，也比「只讀節點」更能處理複雜畫面。
- 先讀目前語意狀態。使用可用的 screen information 取得目前 App、可見文字、節點階層、互動目標與狀態。若使用者要求「按下儲存」或「確認開關是否已打開」，這一步通常能提供足夠證據。
- 偵測語意缺口。若目標是圖片、圖表、地圖、自訂元件、相似按鈕、被遮住的控制項，或節點文字和使用者描述對不上，就標記為需要視覺補強。
- 只擷取必要像素。截圖應回答具體問題，例如「哪個按鈕可見」、「地址文字是否在圖片裡」、「彈窗是否擋住底部按鈕」。避免為了簡單文字按鈕擷取整個敏感畫面。
- 對齊節點與像素。用 bounds、可見文字、畫面位置和截圖中的外觀互相校正。若節點說有「提交」按鈕，但截圖顯示它被 loading 遮住，操作應延後。
- 處理衝突。節點和截圖不一致、座標低信心、目標不唯一或畫面變動時，Agent 應重新讀取狀態、請使用者指定，或提供手動接管。
- 先提出動作，再取得適用確認。低風險的畫面閱讀可以直接回報；發送、提交、購買、刪除、修改設定或分享內容，應顯示目標和內容後再執行。
- 用 fresh state 驗證。操作後重新讀 UI 樹、必要時再用截圖確認可見結果。不能因為 tap 指令成功送出，就假設使用者目標已完成。
這個流程的關鍵，是承認畫面會變。通知可能插入，鍵盤可能彈出，App 可能重排，網路延遲可能讓節點變舊。安全的 Android AI Agent 螢幕理解不追求一次看完所有東西，而是在每個關鍵轉折重新取得足夠證據。
正式評估這類能力時，也要把任務成功、低信心處理、錯誤復原與可接管性納入。若你需要更系統化的測試矩陣，可閱讀Android 手機 Agent 基準測試指南：2026 AI Agent 評估、GUI 測試與可靠性指標。
把決策套用到 FoneClaw 目前畫面任務
FoneClaw 是我們打造的 Android phone-agent runtime。使用者可以從免費預設模型開始，也可以設定相容模型；模型負責理解與規劃，FoneClaw 透過受治理的支援工具承接 Android 手機任務。在目前畫面理解上，我們的產品路徑是先用結構化畫面資訊，再在像素能回答真問題時加入截圖。
實作上，FoneClaw 會使用目前螢幕相關能力，例如 get_screen_info 與 cross_app_read_screen 取得可用的畫面狀態與語意脈絡；當使用者選擇截圖、需要重新分析擷取畫面，或任務依賴圖片與視覺排列時，再使用 screenshot_take 或 screenshot_open 這類截圖路徑。近期可用產品資訊中，FoneClaw 已改善圖片附件、擷取圖片重分析、圖片尺寸與檔案引用、多模態請求準備，以及跨 App 進度回饋。這些能力讓螢幕證據能更穩定地進入同一個可觀察流程。
我們不把截圖當成萬能答案。若使用者問「這個設定開關現在開了嗎」，節點狀態通常比畫面顏色更直接。若使用者問「這張圖裡的地址是哪裡」或「哪個區塊被紅色標示」，像素證據才重要。FoneClaw 的 100+ built-in tools 提供的是支援範圍內的 Android 動作與資訊能力；每一步仍依使用者授權、畫面狀態和適用確認推進。
對使用者來說，好的體驗應該是可見的：Agent 說明它正在讀目前畫面、是否需要截圖、準備做什麼、哪一步需要確認、結果如何驗證。需要理解支援範圍可看FoneClaw 功能頁；準備在自己的裝置上測試時，可從FoneClaw 下載頁選擇合適入口。權限和沙盒邊界的深層設計，則可延伸閱讀AI Agent 沙盒與手機權限：安全 Agent 為什麼仍需要邊界。
用可復原 Android 任務測試螢幕理解
如何安全測試螢幕理解？先選一個無害畫面，例如設定頁、備忘錄清單、測試表單或不含敏感內容的 App 頁面。使用你的實際 Android 版本、裝置與 App，因為 OEM 介面、字體大小、權限狀態和畫面方向都會影響結果。
- 先寫下預期目標與初始狀態，例如「找出 Wi‑Fi 開關是否開啟」或「辨識畫面上哪個欄位是電子郵件」。
- 先測 UI 樹路徑，觀察 Agent 是否能用文字、狀態與階層回答。
- 只在 unresolved visual fact 出現時加入截圖，例如圖片文字、遮擋、圖表或自訂 UI。
- 改變一次方向、字體大小或畫面狀態，確認 Agent 是否重新讀取目前畫面。
- 中途打斷一次，檢查它能否報告目前進度與下一步。
- 執行一個可撤銷的小動作，最後重新讀狀態或手動核對結果。
一個畫面成功不代表廣泛相容。手動接管仍是有效結果，尤其當目標不唯一、畫面含敏感資訊、節點和像素衝突，或動作會造成高影響後果。可靠的 Android AI Agent 螢幕理解，是知道何時用哪個證據，也知道何時停止。