Google 的 ARTEMIS 將 Android 自動化開源：AndroidWorld 所稱的 99% 究竟涵蓋了什麼

最新的提交在 google/artemis 上不是一項功能。它是一行署名——「fix: 依照 Apache 2.0 要求補齊 README 與相關檔案標頭」，於 2026 年 9 月 12 日推送，就在 Minitap 發表一篇題為 我對 Google 有更高的期待。Google 的 ARTEMIS 是該公司最新開源的 Android 自動化代理：它將純英文指令轉化為在實體 Android 裝置或模擬器上的真實點擊、滑動、輸入和驗證，並沿途擷取日誌和螢幕截圖，在 Google Research 的 AndroidWorld 基準測試中報告 99%+ 的任務完成率。它於今年八月由 Google 的 Pixel Test Engineering Fusion 團隊在 Apache 2.0 下發布，而且它確實值得你花一個下午來研究。截至九月中旬，它也是一場開源歸屬權之爭的中心，這場爭議所揭示的關於行動代理如何建構的資訊，比基準測試數字還要多。這兩個故事都是真實的。只有其中一個是該儲存庫最後一次提交是授權修正的原因。

實際發佈的內容

ARTEMIS 不是模型，也不是聊天機器人的包裝層。它是一套控制框架——一個 Python 3.12+ 系統，介於視覺語言模型與真實手機之間。你用英文給它一項任務；它會觀察螢幕、決定動作、透過 ADB 執行、檢查發生了什麼，然後繼續下去。盒子裡附了五樣東西：

• 一支命令列工具與一套 Python SDK。 code>./start.sh/code> 會初始化 ADB、scrcpy、FFmpeg 與 uv 環境；code>uv run artemis run "…" --profile flash/code> 會以無介面方式執行任務；而 code>artemis-client/code> SDK 則包裝了同樣的呼叫，供 pytest 與 CI 使用，並回傳 code>succeeded/code>、code>status/code>、code>device_serial/code>，以及一組你之後可以追查的 code>trace_id/code>。

• 一個網頁主控台。 code>uv run artemis ui/code> 會在 code>localhost:8000/code> 上架設視覺化測試主控台，讓你逐步觀看迴圈的運作過程。

• 原生 MCP 伺服器。這就是讓它能廣為流傳的部分。code>uv run artemis mcp --install all/code> 會將code>mobile_run_task/code>、code>mobile_manage_task/code>、code>mobile_get_device_state/code>、code>mobile_inspect_trace/code> 與 code>mobile_diagnose/code> 提供給任何支援 MCP 的助理，並內建 Antigravity、Claude Code 與 Codex 的一等公民級安裝路徑，還能為 Cursor、Windsurf、VS Code 與 Cline/Roo 產生設定檔。對已連接該伺服器的助理來說，「建置 APK、安裝它、開啟設定、切換飛航模式、將結果截圖」不再是腳本，而是一句話。

• 無障礙輔助工具。第一個工作會安裝 Artemis Accessibility Helper，它會在不持有 UiAutomation 連線的情況下讀取螢幕版面配置——這是刻意如此設計，好讓同一部裝置上其他以 UiAutomator 為基礎的工具不會遭到抑制。它在手機上執行，不會把任何資料傳送出去，並在無法附加時改用 UIAutomator2，這項後備機制會顯示在工作時間軸上。

• 日誌與追蹤擷取。崩潰堆疊、關鍵影格截圖與診斷報告皆會自動收集，而非由呼叫端另行加裝——這正是它可作為迴歸測試套件、而不只是示範範例的原因。

Flash 與 Pro 是兩個不同的產品，卻共用一個名稱。

在將 ARTEMIS 與任何事物進行基準比較之前，你必須理解的最重要一件事是：code>--profile flash/code> 與 code>--profile pro/code> 並非同一個代理上的速度設定。它們是兩個不同的代理。

• Flash — 一種反應式的「觀察—行動」迴圈，每一步約 3–5 秒，沒有計畫、沒有筆記、沒有執行前安全檢查、沒有檢查點驗證、沒有最終報告，也不使用 ADB shell。此迴圈預設為無界，因為歷史是被壓縮而非累積。

• Pro — 多代理圖，每步大約 15–40 秒，由下列部分組成：一個 Planner，維護一份持續更新的 Markdown 計畫，其中包含明確的 code>verify/code> 和 code>assert/code> 項目；一個具備完整工具集的 Operator；以及一個唯讀 Checker，會驗證檢查點並執行結束審查。 code>--verification-level/code> 可接受 code>off/code>、code>final/code>（預設）、code>checkpoints/code> 或 code>strict/code>。

對相同的任務描述而言，這是五到十倍的延遲差異，也是煙霧測試與 100 多步探索性執行之間的差別。Google 自己的說法是，Pro 適用於長時程工作與持續code>[Loop:continuous]/code> 監控；Flash 則適用於例行、確定性的 UI 雜務。如果你讀到一篇評論引用了步驟計時，卻沒有告訴你這些計時是由哪個設定檔產生的，那它什麼也沒告訴你。

定位策略才是真正的工程

大多數行動自動化框架都死在選擇器上。ARTEMIS 以動態優先為核心設計：當無障礙元素索引存在時，它就使用該索引；當它不存在時——例如 Canvas、Compose 介面、Flutter 檢視、遊戲——它便退回使用座標與視覺辨識。沒有需要維護的 XPath 層，也沒有會過期失效的 ID，這點至關重要，因為你最想測試的應用程式，正是那些每週都發布新組建版本的應用程式。

Pro 方案新增了安全網：每個動作都會先經過執行前檢查，以 XML 為主、像素為後備，能攔截即將吃掉你點按的系統彈出視窗。失敗時會開啟一項「執行事故」，並留在上下文中，直到之後的成功將其解決，而不是另外啟動一個修復代理。長時間工作階段會被壓縮——舊的螢幕擷取畫面變成視覺摘要，已完成的步驟被分塊成可召回的時期，code>search_history/code> 和 code>replay_steps/code> 可以把它們拉回來——這正是讓 100 步的上下文不至於變得難以負擔的關鍵。

排行榜上的 99.1%，以及發布貼文跳過的但書

ARTEMIS 最引人注目的主張，是其在 AndroidWorld 上達到 99% 以上的完成率；AndroidWorld 是 Google Research 的基準測試，涵蓋 20 多個應用程式中的 116 項擬真任務，並以 Pass@1 計分。截至 2026 年 9 月 11 日，AndroidWorld 排行榜列出 ARTEMIS 為 99.1%，Minitap 的 mobile-use 為 91.4%，而人類表現為 80%。就表上數據而言，這是公開回報結果中最頂尖的水準。

那個數字旁邊還需要補充兩件事。首先，AndroidWorld 排行榜明確不獨立驗證提交內容——其上每一個數字，包括 ARTEMIS 的，都是由產出該結果的團隊自行回報，而一項穩健性分析顯示，單是任務變異就可能大幅改變代理的得分。請把 99.1% 視為在公開、可查核基準上的一項強力廠商宣稱，這是真實且有用的事，而不是經審計的測量，因為它並不是。其次，比較的形態很重要：該基準是一組固定的任務，而據報導，ARTEMIS 公布的比較圖表省略了 mobile-use，卻納入了其他項目。一個圖表上缺少最強先前結果的基準，其主張會比原始百分比所暗示的更弱。

這場爭議，才是本月真正的新聞

在其部落格以及該儲存庫的一則公開 issue 中，Minitap——一家行動測試新創公司，其開源mobile-use專案為 Android 與 iOS 執行同樣的工作——指控 ARTEMIS 的 229 個檔案中有 228 個與自家檔案完全相同。它公布的細節異常具體：Android 裝置連線程式碼與其實作相符、逐字照搬一個名為「Hopper」的 agent 的指令，以及一個向 Alice、Bob 和 Charlie 發送新年訊息的 WhatsApp 範例，連註解、清理步驟和同一個 bug 都如出一轍。它進一步指稱，一個載有三名 Minitap 作者姓名——Pierre-Louis Favreau、Jean-Pierre Lo 與 Nicolas Dehandschoewercker——的檔案，在 8 月遭人以強制推送（force-push）取代，姓名被移除，並換上另一位作者。

授權問題並不模糊。mobile-use 採用 Apache 2.0，而 Apache 2.0 正好允許這類再利用——商業性、衍生性、閉源——只要你保留著作權聲明並說明自己做了哪些修改。它不允許的是在移除這些聲明的情況下散布程式碼。自從這些指控浮上檯面以來，該儲存庫便一直載有「本專案包含 Minitap, Inc. 所開發的原始碼」這一行，並連結至 minitap-ai/mobile-use，而完成這項姓名標示的 9 月 12 日提交，在撰寫本文時是 code>main/code> 上最新的變更。Minitap 並未公布任何證據，將其姓名標示的移除與自家未獲回應的排行榜提交串連起來，而 Google 也未發布詳細的公開回應。誠實的解讀是：被分享的程式碼是合法的，且一直以來都獲允許；文書作業則曾有一段時間不合規，如今已獲得修正。

沒有人算進成本的那一塊：模型帳單

ARTEMIS 出廠時帶有一枚標示「Multi-Model — Gemini | Claude | GPT-4o | Qwen-VL」的徽章，而它位於 code>config/artemis.jsonc/code> 的設定檔，正是你把它指向任何你持有憑證的視覺模型的地方。在那個檔案裡，沒有任何東西是真正面向使用者的，直到你在真實的工作流程中執行 Pro，並親眼看著一個長時間運行的代理究竟要花費多少成本。

算一算這些設定檔的帳。一次 100 步的 Pro 執行，以每步 15–40 秒計算，實際時間大約落在 25 分鐘到剛過一小時之間，而其中每一步至少都是一次附帶螢幕截圖的視覺模型呼叫。Flash 每步較便宜，但更容易反覆迴圈，而且因為它的上下文是壓縮而非截斷，它會樂於跑超過你原本以為是上限的回合限制。無論你選哪個設定檔，模型才是會隨你的測試套件規模增減的支出項目，而不是授權或硬體。

這正是路由層不再只是抽象概念的地方。一個驅動長時間 Android 工作階段的視覺模型，是一種帶有兩個棘手特性的工作負載：它生命週期長，而且無法容忍在第 74 步中途遇到供應商出狀況，因為這次執行的情境脈絡就落在該供應商的端點上。把 ARTEMIS 指向單一 OpenAI 相容的基礎 URL，並讓我們的容錯移轉把這次執行轉移到同一模型的其他供應商，就是不穩定測試與白白損失一個下午之間的差別。Qwen3.8-Flash 是值得優先嘗試的有趣候選者——一個具備 1M 詞元情境、6B 活躍參數的多模態 MoE，列在我們的目錄中，每百萬輸入詞元 $0.15、每百萬輸出 $0.47，快取讀取為 $0.018、快取寫入為 $0.230。這裡真正相關的是快取讀取的價格，因為 Pro 執行會在每一步重新讀取不斷增長的情境。

不過，對於那代表什麼，請務必精確：Qwen3.8-Flash 不在 ARTEMIS 已測試的後端清單上，該清單列出的有 Gemini、Claude、GPT-4o 與 Qwen-VL。它是個合理契合該測試框架的模型，而該框架明確就是為了接受這類模型而打造。沒有人發表過那樣的配對基準測試，若有人聲稱有，你應該認定那是他憑空捏造的。

路線圖，以及其中有多少是承重的

已發布的藍圖上有四個項目：與 Android Studio 整合，可在編輯器內除錯、測試錄製與裝置控制；支援 iOS；裝置端輕量視覺語言模型，可實現低延遲、隱私優先的工作；以及即時雙工語音互動。

第一個是值得相信的那個，因為它是 Pixel 測試工程團隊自然而然的下一項產出，而且不附帶任何研究風險——代理程式已經能驅動裝置，只差 IDE 裡的一個面板。iOS 是一項比從外表看起來大得多的主張：整個定位策略都倚賴 Android 的無障礙服務，而 iOS 並沒有具備相同權限模型的對等介面，所以預期會是感知層的重寫，而非移植。裝置端 VLM 那一項是值得密切關注的，因為它是清單上唯一能移除目前主導大型測試套件之逐步 API 成本的項目——而且它暗示的是一個小型、快速、具備視覺能力的模型，能維繫一項 UI 任務，這比「一個擅長工具使用的小型模型」是狹窄得多的目標。

這週要怎麼處理它

複製它，執行 code>./start.sh/code> 對一個模擬器執行，並給 Flash 一個你現有 Espresso 套件已涵蓋的任務。這會在一小時內告訴你，動態優先定位器能否在你的應用程式 Compose 介面上存活，而這個問題決定了其餘任何事是否重要。接著在 Pro 上執行相同任務並比較兩份追蹤記錄——每步 3–5 秒與 15–40 秒之間的差距，就是你的預算所在，沒有它你無法推斷 ARTEMIS 的成本。

當你在閱讀程式碼時，也讀一下標頭。那筆在 9 月 12 日加入 Minitap 署名的提交，是儲存庫中最新的一筆，這表示你正在閱讀的檔案標頭已經有四天之久，而這個專案正公開地積極修復中。這不是避開它的理由。這反而是個理由，讓你在簡報投影片中引用成功率之前，先確認自己手上拿的是哪個版本的故事。

把 ARTEMIS 指向單一相容 OpenAI 的 base URL，並讓我們的容錯移轉把這次執行移到同一模型的其他供應商，這就是測試時好時壞與白白浪費一整個下午之間的差別。