rdp-cli

Android AI Agent 控制:USB、Wi-Fi、螢幕擷取與實際操作

AI Agent 可以規劃工作,但如果目標是 Android 手機,只有規劃還不夠。它必須讀取目前螢幕、執行操作,並確認介面發生了什麼變化。

對於 Android 12 及以上版本,實用的控制層應該同時支援 USB 和 Wi-Fi,能夠處理常見觸控動作、檔案操作,並把螢幕擷取結果回傳給 Agent。

AI Agent 控制 Android 需要什麼

  • 點擊螢幕指定位置
  • 在目前輸入框中輸入文字
  • 透過滑動完成捲動和手勢
  • 在操作前後取得螢幕擷取
  • 上傳和下載檔案
  • 按需安裝 APK
  • 透過 USB 或 Wi-Fi 維持穩定的裝置工作階段

關鍵是回饋迴圈。不要讓 Agent 根據猜測的座標連續點擊,而應該先取得畫面、找到目標、執行一次操作,再次取得畫面並驗證結果。

一個簡單的操作記錄可以是:

{
  "action": "tap",
  "x": 420,
  "y": 780,
  "observation": "SCREENSHOT_ID"
}

觀察 ID 可以把操作與 Agent 實際看到的螢幕關聯起來。

USB 還是 Wi-Fi?

USB 通常適合首次連線:速度快、穩定,而且不要求手機和電腦位於同一網路。Wi-Fi 更適合把手機放在測試支架、另一個房間,或用於長時間測試實驗室。

可以用 USB 完成初始配對和故障恢復,裝置穩定且位於可信任網路後再使用 Wi-Fi。不要把 Android 偵錯連接埠直接暴露在公網上。

可靠的 Agent 操作迴圈

每個重要步驟都可以遵循以下順序:

  1. 透過 USB 或 Wi-Fi 連線到 Android 12+ 裝置。
  2. 取得最新螢幕擷取。
  3. 根據畫面辨識目標控制項。
  4. 傳送一次點擊、文字輸入、滑動、檔案操作或 APK 操作。
  5. 再次取得螢幕擷取。
  6. 確認結果後再繼續。

這樣可以發現載入畫面、權限彈窗、鍵盤變化和意外跳轉。

Android 控制與 ADB 的差別

ADB 是 Android 偵錯橋接工具,適合安裝 APK、複製檔案、啟動 Activity 或執行 shell 命令等明確操作。

但 ADB 本身不是完整的視覺 Agent 工作流程。Agent 仍然需要讀取目前畫面、選擇安全操作,並在輸入後驗證結果。

可以把 ADB 理解為低階命令通道,把 Android AI Agent 控制理解為圍繞裝置建立的觀察與操作迴圈。

Android MCP 不等於螢幕控制

Android MCP 工具可以用結構化方式向 AI Agent 暴露裝置操作,方便發現和呼叫工具。但它仍然需要可靠的裝置後端。

完整方案應該同時提供動作和觀察結果:螢幕擷取、裝置狀態、輸入結果和清楚的錯誤資訊。Android MCP 負責結構化工具存取,裝置控制層負責 USB 或 Wi-Fi 工作階段及經過驗證的螢幕互動。

適合哪些情境

這種方式適合測試 Android 應用程式、在多台裝置上重複操作、上傳測試檔案、安裝 APK 建置版本、每次發佈後檢查行動介面,以及操作不在 Agent 身邊的 Android 手機。

原則很簡單:連線、觀察、操作一次、驗證結果。如此一來,面向 AI Agent 的 Android 遠端控制就不再是脆弱的巨集,而是一個可以除錯的自動化流程。