Google 的 ARTEMIS：把自然語言變成 Android 操作
Google 在 GitHub 上以 google/artemis 為名公開了 ARTEMIS 專案。依儲存庫自述，ARTEMIS 把自然語言指令轉成可靠的 Android 自動化：自動化端到端工作流、在過程中捕捉日誌，並與 Antigravity、Codex、Claude Code 等 AI 編碼助理整合；專案由 Google 的 Pixel-Test-Engineering（PTE）Fusion 團隊開發。從團隊命名就看得出它的出身——這套工具來自 Pixel 產品測試工程，而不是研究展示。
入門路徑相當直接：複製儲存庫、執行 start.sh 一鍵啟動；目錄包含 apps、artemis、config 與 mcp_server 等。截至 9 月 12 日查閱，儲存庫約有 2.6k 星、237 次 fork、119 個 commits，並開放 Discussions、累積 16 個 issues 與 29 個 pull requests——對 Android 自動化有需求的開發者顯然不少。
從工程配套看，這不是隨手丟上 GitHub 的範例：儲存庫設有 CI 工作流目錄、文件資產與設定目錄，入門文件提供 macOS 與 Linux 的啟動腳本，pull requests 也保持在活躍審視的狀態。這類配套通常出現在預期外部使用者實際參與的專案，而不是純展示用的原型。
授權段落裡的關鍵一句
這個專案真正值得細看的地方，是 README 授權段落的一句話：「本專案包含由 Minitap, Inc. 開發的原始碼」，後面連向 minitap-ai/mobile-use 儲存庫。換句話說，Google 這套 Android 自動化代理的程式碼基底，有一部分明確來自一家新創公司的開源專案，而且這件事就寫在授權段落裡，任何人都能回查。
歸屬（attribution）之所以重要，在於它讓「誰的程式碼被誰用掉」成為公開紀錄。開源授權的署名要求，通常正是靠這種段落履行：下游使用者看得到出處，原始作者的名字不會在層層轉手後消失。相較於只放一個授權檔、不說明引用了誰的程式碼的常見做法，把來源寫進 README 的授權段落，提供了清楚得多的溯源線索。至於這段署名實際涵蓋哪些檔案，頁面本身沒有展開。
mobile-use：走進 Google 工具的新創開源框架
被載明出處的 mobile-use，是 Minitap 維護的開源專案，儲存庫標語寫得直白：「AI agents can now use real Android and iOS apps, just like a human」——AI 代理可以像真人一樣操作真實的 Android 與 iOS 應用程式。專案同時支援兩大行動平台；截至 9 月 12 日約有 2.8k 星、244 次 fork，累積 881 個 commits，目錄包含 minitap/mobile_use 主套件、skills、scripts 與 tests，並設有 CITATION.cff——這種檔案的用途是提供標準的學術引用格式，顯示維護者預期這套成果會被論文引用。儲存庫同時備有 CONTRIBUTING.md、Dockerfile 與 pre-commit 設定，對外部貢獻流程與可重現環境都有基本配套，看得出是按長期維運的節奏在經營，而不是一次性的論文附件。
論文確實存在。arXiv 編號 2602.07787、2026 年 2 月上傳的一篇論文以「Do Multi-Agents Dream of Electric Screens?」為題，將 mobile-use 描述為一套多代理（multi-agent）系統。多代理的意思是：手機操作不是單一模型的單次問答，而是拆給多個各司其職的代理協作完成——這也是後來裝置操作代理的主流架構選擇。
另一個訊號出現在提交紀錄：mobile-use 最近一則文件提交以「docs: start hosted platform sunset」為題，開始處理託管平台退場的文件。把這件事與「程式碼被 Google 工具載明採用」放在一起看，這家小型團隊的開源成果正同時經歷兩個方向的變化：被大廠引用，以及自家商業服務的調整。
一句指令如何變成手機上的操作
從儲存庫結構看，ARTEMIS 把「誰來思考」與「如何操作裝置」分成兩層。模型層不綁定單一廠牌：自述可與 Antigravity、Codex、Claude Code 等編碼助理整合，目錄裡的 mcp_server 顯示它以 MCP（Model Context Protocol）這類標準工具介面，讓外部模型用呼叫工具的方式驅動 Android。執行層則把自然語言指令落成端到端工作流，並在過程中捕捉日誌——對測試工程而言，日誌是回放與除錯的基礎，這也解釋了為什麼「捕捉日誌」會被寫進專案自述的前兩句。
這個分層對使用者的意義是：換模型不必換工具。今天用 Codex、明天換 Claude Code，裝置端的自動化層可以不動。而行動裝置自動化的真正難點——畫面元素定位、跨應用流程、非固定環境——正是 mobile-use 這類框架用 881 個 commits 累積下來的工程處理。
AndroidWorld 的 99% 要怎麼讀
ARTEMIS 自述在 AndroidWorld Benchmark 上達到 99% 以上成功率。這類基準的測法，是把代理丟進真實環境、以執行結果而非模型自陳評分，與桌上環境的 OSWorld 屬於同一種測法。本站先前報導過電腦操作智能體在 OSWorld-Verified 一年內從 42% 升到 85%、跨過人類約 72% 的水準；AndroidWorld 之於 Android 手機，扮演的是類似的角色。
兩個提醒。第一，99% 以上是專案自述成績，不是獨立機構的驗證結果；技術選型時應以自家任務實測為準。第二，基準分數衡量的是特定任務集上的成功率，不等於任意口語指令的穩定度——裝置自動化在基準外的長尾情境（第三方應用改版、多語介面、非預期彈窗）一向是主要失分點，這在桌面端的電腦操作代理也一樣。
大廠工具與小型開源專案的依存
ARTEMIS 並非大廠第一次公開代理工具。Microsoft 先前開源過 MagenticLite 全棧，從應用、測試框架到模型權重一次放出。兩者的差別在於：MagenticLite 的核心是 Microsoft 自家訓練的模型，而 ARTEMIS 的程式碼基底明確包含外部新創的開源成果——後者把「誰的程式碼被誰用掉」變成攤在陽光下的公開紀錄，讓生態裡的依存關係可以被外界具體檢視。
對小型開源團隊而言，被大廠採用是雙面刃。能見度與驗證是收穫：mobile-use 的工程決策經過 Google 內部測試團隊的實際使用，等於多了一個高強度的使用者。代價則是話語權：下游專案的 README 與公開討論裡，容易被記住的名字是大廠，原始作者得靠授權段落與 CITATION.cff 這類制度性署名維持可見性。開源社群長期討論的永續問題——誰維護、誰出錢、誰得名——在這種依存關係裡被具體化了。
開發者可以怎麼用、該注意什麼
實務上有兩條取用路徑。要做 Android 端到端自動化（測試、裝置批次操作、工作流驗證）：複製 ARTEMIS、執行 start.sh，模型端接上偏好的編碼助理即可開始。要跨 Android 與 iOS 的通用行動代理框架：以 mobile-use 為基底，它的 skills、scripts 與 tests 目錄對二次開發相對友善，CITATION.cff 則讓學術引用有現成格式。導入時建議先在小範圍任務上量測成功率與每次執行的成本，再逐步擴大到關鍵流程——裝置代理的失敗模式多半來自環境變動（應用改版、權限彈窗、裝置差異），而非模型能力本身。
授權面必須自己動手查。兩個儲存庫都設有 LICENSE 檔，但授權條款的具體名稱與條件，需直接閱讀各儲存庫的授權檔與相關聲明確認；商業採用前，特別要確認歸屬與再散布義務——這正是 ARTEMIS 授權段落示範的那件事：引用了誰的程式碼，要寫清楚。
現有資料看不到的事
這些事實都取自 9 月 12 日查閱的公開頁面；頁面之外，還有幾件事目前沒有答案。ARTEMIS 內含的 mobile-use 原始碼具體涵蓋哪些檔案、占多少比例，授權段落未列明，需比對兩個儲存庫的程式碼才能回答。授權段落顯示的是查閱當時的狀態，這段署名的加入時間與歷次變動，需查 git 提交歷史才能確認。99% 以上的 AndroidWorld 成績屬專案自述，未見獨立重測。Minitap 託管平台退場的細節與時間表，僅能從一則提交訊息看出方向，後續以官方說明為準。
值得追蹤的指標有三個：兩個儲存庫的授權與署名段落是否再變動；ARTEMIS 的 issues 與 Discussions 如何處理社群對程式碼來源與授權的提問；mobile-use 在雲端服務退場後的維護節奏與方向。這三條線，決定這段大廠工具與新創開源碼的關係，最後是走向更透明的協作，還是又一次單向的取用。
