Google ARTEMIS 開源：程式助理用自然語言操作 Android 真機

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

Google 在自家的 GitHub 組織開源了 ARTEMIS，一個把自然語言指令變成 Android 操作的測試代理。它連上開啟 USB 偵錯的真機或模擬器之後，讓 Claude Code、Codex 這類程式助理把手機當成可呼叫的設備：派任務、收截圖、讀系統紀錄（Logcat），最後交出測試報告。官方在 AndroidWorld 基準上報告 99% 以上任務完成率，repo 到 2026 年 10 月中累積超過 1.2 萬個星標。

先講判斷。這個專案值得注意的訊號，是測試工作的介面正在換位置：過去手機自動化多半是把操作寫成腳本或規則（例如把跳廣告與重複操作做成規則引擎的 Android 工具），介面一改腳本就失效；ARTEMIS 走的路是把整支手機包成 MCP 工具（Model Context Protocol，一種讓 AI 助理透過共同介面呼叫外部工具的協定，想認識這個生態可以看我們先前實測的 mcp-use 開源庫與 MCP 伺服器目錄整理），畫面判斷交給模型，證據收集變成流程內建的一環。截圖、Logcat、執行軌跡到最終報告，都是代理流程跑完自然留下的產物，測試結束後不需要人工再補附件。

動手前也有幾件事實要先看清楚：repo 公開約兩個月還沒有任何版本號；畫面截圖與任務內容會送往你自帶金鑰的雲端模型服務；99% 是模擬器基準上的官方報告值。下面逐項拆開。

Pin

把手機包成 MCP 工具，證據鏈跟著代理走

ARTEMIS 內建一個原生 MCP 伺服器（同類做法像讓 AI 自己操作 Blender 的 MCP 外掛），從官方給的整合設定範例看得到它對程式助理暴露的工具面：派任務（mobile_run_task）、管理任務（mobile_manage_task）、查裝置狀態（mobile_get_device_state）、檢視執行軌跡（mobile_inspect_trace）、診斷問題（mobile_diagnose）。這份清單的含義比項目本身重要：在 IDE 裡工作的助理，可以把「把最新變更打包成 APK、裝到連線的手機、用測試帳號開到登入頁、檢查登入後有沒有預期外的彈窗、回傳最終畫面截圖」這類請求直接派給手機，拿回結構化的結果。官方文件列出的安裝對象涵蓋 Antigravity、Claude Code、Codex、Cursor、Windsurf、VS Code 與 Cline 等主流環境，啟動腳本會偵測已安裝的 IDE 並掛上設定。

這對測試工作的意義在於證據。畫面停在載入中，截圖只能證明使用者看到什麼；Logcat 裡的網路失敗或程式例外才回答「為什麼」。ARTEMIS 把兩種證據綁進同一條任務軌跡，失敗時你面對的是可回查的過程紀錄，不會只剩結尾一句結論。診斷也有對應工具：檢視軌跡與診斷兩個 MCP 工具讓助理自己回看執行紀錄，把「剛剛那步為什麼失敗」變成代理可以回答的問題，工程師不必先人工整理紀錄再餵給它。

官方還隨附一份給 AI 代理的行為規則檔（rules.md），把「先主動探索再動手」、「Flash 與 Pro 的分流時機」、「延遲補償」與「優先動態定位、座標當後備」這類資深測試工程師的紀律寫成規則，掛進各 IDE 的規則設定後，助理照這套思維行事，降低憑空捏造畫面互動的機率。接入方式有懶人與手工兩條：跑 uv run artemis mcp --install all 一次把偵測到的 IDE 全設好，或用 --generate-config 印出設定片段自己貼，官方文件連 Codex 的 ~/.codex/config.toml、Claude Desktop 的 JSON 設定檔都給了現成範本。專案提供中英雙語 README（中文版為簡體）與 Discord 社群，入門文件的完整度在同類開源代理裡屬於前段。

官方展示的完整工作流以 Antigravity 為例：在對話裡描述測試情境與目標指標，助理先產出逐步測試計畫供人審視，接著驅動真機執行、導覽介面、側錄效能，最後交付結構化的稽核發現、指標表格與原始資料集。計畫在人審視過後才動手，這個順序對測試場景很重要，因為自動化出錯的成本比聊天場景高得多。文件裡各處列出的 IDE 名單略有出入：重點摘要點名 Antigravity、Claude Code 與 Windsurf，repo 簡介寫的是 Antigravity、Codex 與 Claude Code，安裝腳本的支援清單又更長。對使用者的實際含義是主流環境都在支援範圍，但展示資源明顯集中在 Google 自家的 Antigravity 上，跨 IDE 的成熟度要自行驗證。

裝置端的定位方式也是同一套哲學：能用畫面元素的結構索引就優先用，遇到 Canvas、Compose、Flutter 這類自繪介面再退回座標與視覺辨識，兩層互相補位。官方展示的跨應用例子，是在 Google Maps 排好路線算完總時間，接著切到 YouTube 播一首 Coldplay 的歌，任務脈絡跨畫面維持。跨 App 也代表變數變多，每個服務的載入時間、登入狀態與權限提示都可能讓後續步驟失去前提，這是它與單畫面自動化本質上的差別。

破萬星標的專案，還沒有第一個正式版

時間軸先對齊。google/artemis 建立於 2026 年 8 月 13 日，最早可見的 commit 出現在 8 月 19 日；到 10 月 19 日累積 121 個 commits、12,854 個星標，授權 Apache-2.0，需要 Python 3.12 以上。releases 頁面至今是空的，沒有任何 tagged release 可以鎖定版本，最後一次推送停在 10 月 1 日。

對照討論熱度，這個狀態本身就是最重要的資訊。星標說明關注是真實的，零版本號說明 Google 還沒把它當成有穩定介面的產品在發。現在導入的人要接受 pre-release 現實：設定檔格式、指令列介面與行為都還可能變動。沒有版本號可鎖，實務上退而求其次把評估環境釘在某個 commit 雜湊上，升級時才有可比較的基準；從八月至今的 121 個 commits 裡，九月十二日有一次補齊授權標頭與文件的整理，對重視合規的團隊是值得知道的節點。

受影響的範圍也比星標數字窄。Android 開發與測試團隊多了一個可評估的代理框架；做 agent 整合的工程師多了一份 Google 官方組織維護的 MCP 伺服器實作，從工具命名到錯誤回報都可以當範本讀；一般手機使用者短期內不會在生活中遇到它，因為它需要開發連線與測試機才動得起來。repo 裡連網頁主控台的原始碼都一起公開，想審視它到底對手機做了什麼，可讀性比多數黑箱商業方案好得多。

門檻倒是具體可估。git clone 之後跑 ./start.sh，腳本會自動偵測並安裝 ADB、scrcpy、FFmpeg 與 Python 相依，開出 localhost:8000 的網頁主控台，提供即時畫面投影、提示詞沙盒、任務佇列與執行重播，代理運作時的畫面感知、目標座標與結構化結果會以即時訊息流呈現，看著它怎麼判斷畫面比讀文件更快建立直覺；也有 CLI 一行指令（例如讓它打開設定、找到電池頁、回報電量）、可直接跑 AndroidWorld 基準的開發者模式，與可接 pytest、CI 管線的 Python SDK；SDK 回傳的是強型別結果，附帶裝置序號與軌跡編號，斷言寫起來跟一般測試框架同一套手感。你要準備的是一台開 USB 偵錯的測試機或模擬器，加上一家模型的 API 金鑰。README 的定位句寫得直白：讓 AI 助理與測試套件像人一樣使用真手機。SDK 與 CLI 就是後半句的落地，不必掛在 IDE 對話裡，照樣能把任務派進既有管線。

Flash 與 Pro：速度換的是證據等級

兩種執行檔的差別，可以理解成「你要留下什麼等級的證據」。

Flash 是反應式迴圈：一個模型看畫面、想、動作，官方典型速度是每步 3 至 5 秒，適合例行、確定性高的介面任務。代價官方明列：沒有任務計畫與筆記、沒有執行前安全檢查、沒有檢查點驗證與最終報告，也不能用 ADB shell。它靠一套頗有巧思的設計維持長任務：舊截圖折疊成視覺摘要、完成步驟壓縮成可檢索的歷史區塊，需要的時候再召回或重播，甚至能把操作錄影交給影片分析工具回看。壓縮後的歷史以任務時間軸為座標，舊步驟折成可搜尋的區塊，除錯長任務時能回頭找「某個時間點畫面上是什麼」，省去從幾百張截圖裡翻找的功夫。但失敗發生時，你手上就是這些壓縮摘要。處理稍縱即逝的介面（自動淡出的控制列、快閃提示）它把連續點擊綁成一個動作序列發出，避免等到下一輪模型回應時按鈕已經消失。另一個要注意的預設：Flash 的迴圈上限預設是無限（max_turns 為 0），靠歷史壓縮而非截斷來控制長度，這代表任務走偏時它可能跑很久，導入時自己加上限是必要防護。

Pro 是完整的規劃與驗證結構，典型每步 15 至 40 秒。規劃者（Planner）維持一份帶里程碑與驗證項目的任務計畫；操作者（Operator）執行，每個動作先過執行前安全網，安全網分兩層比對：先看畫面結構樹，對不上再退回像素層確認，避免對著過期畫面下判斷，被擋下或失敗的動作會以事件形式留在執行脈絡裡，由代理自己在後續步驟恢復，沒有另外的修復代理；檢查者（Checker）驗證計畫檢查點並做收尾複查，驗證強度有四段可調：關閉、只做最終覆核（預設）、逐檢查點驗證、最嚴格模式，對應不同的信任需求，正式驗收建議至少開到檢查點等級。它可跑超過百步的長流程、持續監控式的巡檢任務，並可選擇產出書面報告。一個容易忽略的細節：探索模式由使用者設定檔決定，代理自己不能挑，這是把行為邊界留在人手上的設計。

時間感可以先算起來：官方區間換算，Pro 跑百步流程大約落在 25 到 67 分鐘之間，Flash 同樣步數約 5 到 8 分鐘，兩者的證據密度不同，等待時間差了好幾倍。選擇標準因此很實際：煙霧測試與重複性的例行檢查用 Flash 換速度；長流程、容易出錯的穩定性測試用 Pro 換計畫、安全網與報告。

99% 完成率的量尺，先看它量了什麼

官方報告的完成率是 99.1%（README 統稱 99% 以上），量測基準是 AndroidWorld，Google Research 的手機代理基準。照基準 repo 自己的定義：116 個手工設計的任務、20 個應用程式，在持續運作的 Android 模擬器上執行，任務參數每次動態生成、起始環境依任務重新建立，基準以可復現為設計目標；2024 年 11 月起，每個任務的步數上限調整為約人類平均完成時間的兩倍，給代理足夠餘裕。

Pin

把條件排開，99.1% 能說明的是：在這 20 個應用、這種寬鬆步數、模擬器環境裡，ARTEMIS 有競爭力。它不能換算成任何一支真機、任何一個自家產品上的成功率；真機有品牌客製、版本差異、語言、登入狀態與權限提示等額外變數。這個數字也是 Google 自己報告的，目前還沒有看到獨立第三方的重現結果。官方 README 附了一張 AndroidWorld 排行榜對照圖，ARTEMIS 以 99.1% 排第一，榜上還畫了一條 80% 的人類表現參考線，乍看像代理贏過人類，但那條線的量測條件與代理不同軌，和測試工作的品質更是兩回事；榜上成績也多為各方法作者自行報告，模型與條件未必對齊，看名次要帶著這層警覺。還有一個容易被忽略的條件：基準跑在模擬器上，ARTEMIS 本身支援真機，想在自家環境重現相近數字，至少要把裝置條件、App 版本與測試資料固定下來，混著跑得到的完成率沒有比較意義。合理的讀法是把 99.1% 當試用理由，不是免驗收理由：先在自己的環境重跑一條可比較的流程，再決定它能不能接手某一段人工操作。

Pin

截圖送往雲端，結構讀取留在本機

資料流向要拆兩層看，兩層的答案不一樣。

手機上這層：第一個任務執行時，ARTEMIS 會在手機安裝一個無障礙服務（Accessibility Helper），負責讀取畫面結構，而且不佔用 UiAutomation 連線，避免與其他測試工具打架。通知欄與設定應用程式內會出現可見條目，官方說明它只在手機本機運作、不對外傳送；環境變數可以關掉自動安裝、改用 UIAutomator2，或任何時候解除安裝。裝置連線端也留了參數：ADB 主機與連接埠可指定，也能用序號鎖定特定裝置，對多機測試檯的團隊來說不用改程式碼就能分流。若 helper 中途失效，系統會退回 UIAutomator2，並在任務時間軸、管理工具狀態與最終報告裡明說，把降級也留下紀錄，對需要審計軌跡的團隊是加分設計。

模型端那層就不同了。環境設定要求至少填一家供應商的 API 金鑰，可選 Gemini、Google、OpenAI、Anthropic、OpenRouter、xAI；預設組合是 Google 的 gemini-3.8-flash，設定檔裡也備好 GPT-4o、省錢的 flash-lite，以及本地 Ollama 的 llama3.2-vision 等預設方案。設定檔對每個角色有獨立參數：規劃者用高強度思考等級，操作者中等並保留推理過程，影片分析則在 Gemini 系走原生檔案串流、其他模型走抽取關鍵影格的另一條路。這代表畫面截圖與任務內容會離開手機，送往你所設定的模型服務；在裝置上跑輕量視覺模型的隱私優先路線，目前只出現在 Roadmap，還沒落地。另外環境變數預設會讓手機保持喚醒，官方也提醒日常用的私人手機應該關掉這項。

所以「開源」與「資料不出門」是兩回事。程式碼 Apache-2.0，可自由查看、修改、商用；模型運算按供應商計費，畫面內容按你的設定流動。官方沒有提供每任務的成本數字，實際帳單取決於模型選擇與步數，用 Pro 跑百步長流程時開銷會比 Flash 可觀，試跑階段先在供應商端設用量上限是基本動作。測試機與日常使用的私人手機必須分開，測試帳號也要有固定的初始資料，上一輪留下的狀態會讓下一輪看起來成功，這一條在任何導入評估裡都該排在前面。

現在跟進的分流判斷

Roadmap 上還有幾項值得追蹤：Android Studio 原生整合、iOS 平台支援、裝置端輕量視覺模型、即時語音互動。第三方成分也誠實標明：third_party 目錄收了來自 Minitap 的 mobile-use 專案部分程式碼，同樣是 Apache-2.0。

分流建議照你的條件走。已經有測試機、驗收條件寫得清楚、願意保存執行證據的 Android 團隊，現在就值得挑一條小流程試跑：Flash 驗證速度是否符合期待，Pro 驗證那份報告值不值每步多等的十幾到幾十秒。還在用私人手機、需要穩定 API 承諾，或沒有力氣跟 pre-release 變動的團隊，等第一個 tagged release 再進場不吃虧。回查點也明確：正式版釋出、第三方 AndroidWorld 重現結果出現，或 iOS 支援落地，任何一件發生，這些判斷都值得重新檢視一遍。平時要判斷專案體質，看 issues 與 Discord 的回應節奏，會比星標數字誠實。把時間軸拉長，這個專案代表的是代理工具化的標準件正在補齊：檔案系統、瀏覽器之後，手機也進了可組合的清單，這個趨勢比任何單一專案的星標數值得追蹤。