AutoGLM For Android：自然語言操控 Android 的雲端 GUI Agent

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

「AutoGLM For Android」這個名字，過去半年在 GitHub 上至少被 4 個 Kotlin App 與幾個把 Python 搬上手機的變體拿來用，每一個都說自己是「純 Android 端的 Open-AutoGLM」。它們都做同一件事：讓你不用帶筆電、不用接 USB，直接在手機上用一句自然語言指揮手機完成點擊、滑動、搜尋、開 App 這一連串動作。但這個「手機上跑」的承諾只覆蓋到操作層，真正決定動作該怎麼執行的 AI 視覺模型，依舊是 Open-AutoGLM 官方那份要連電腦、要插 USB、要打 ADB 指令的 Python 框架預設呼叫的雲端 API。換句話說，這款 App 把「桌機＋傳輸線」那一段拿掉了，把「雲端模型推論」這一段留下來了。

本篇把這個名字背後的官方框架、社區變體、雲端依賴與 v0.0.x 階段的風險拆清楚，讓你在動念安裝以前，能判斷自己願不願意把整支手機的操作流程交給中國雲端模型，加上一個還在 0.0.6 版、半年沒有新 commit 的社區 App。

「AutoGLM For Android」到底指哪一個專案

先把名字拆開。智譜 AI（Zhipu／Z.ai，中國 AI 模型公司）官方推出的，是 2025 年 12 月 8 日開源的 zai-org/Open-AutoGLM。這是一份 2 萬 5 千多顆星、Apache-2.0 授權的 Python 模型加框架，README 把它定位為「Open Phone Agent Model & Framework」，背後的模型是 HuggingFace 與 ModelScope 上都看得到的 AutoGLM-Phone-9B（9B 參數，另有 Multilingual 多語版）。它「官方」的形式只到這裡，是一份要在電腦上跑 main.py、透過 USB 線與 ADB 指令控制手機的開發框架。

「For Android」那個 App 不是智譜官方出的。GitHub 搜尋「AutoGLM android」會撈出一片社區變體，每個都把 Open-AutoGLM 那套「桌機跑 Python＋ADB 控手機」的架構，改寫成一支獨立 Android App，並各自取了相似的名字：

光是這張表就回答了一個讀者下載前最該問的問題：「我裝的到底是哪一個 AutoGLM For Android？」授權從最寬鬆的 MIT、到衍生作品必須也開源的 GPL-3.0、到根本沒寫授權的 NOASSERTION 都有，維護節奏也落差很大，有人 7 月還在推 commit，有人 1 月就停了。想實際安裝，得自己確認下載到的是哪個 repo 的哪個版號。 除了上表四個直接打包成 Android App 的變體，社群還有兩條完全不同的技術路線。eraycc/AutoGLM-TERMUX 走的是 Termux 路徑，等於在你手機上裝一個 Linux 終端機環境，再把官方那份 Python 框架原封不動跑進去，所以你得自己會在手機上打指令。airp2018/Open-AutoGLM-SIGI 則把 Python 嵌進 Android 原生行程，讓 Agent 直接在 App 裡跑。這兩條路線處理的是同一個問題（怎麼把 Open-AutoGLM 從桌機搬到手機），但實作層次完全不同，所以當你看到「AutoGLM Android 版」這個說法時，它可能是指一支純 Kotlin App、一個 Termux 部署、或一支內嵌 Python 的混合 App，三者的安裝門檻與風險輪廓差很遠。

接下來的架構說明，會以星星最多、文件最完整 Luokavin/AutoGLM-For-Android 為主要參考，必要時標出其他變體的差異。

桌面框架與手機變體，架構差在哪一層

Open-AutoGLM 官方 README 把「啟動模型服務」切成兩條路：選項 A 是接第三方雲端 API（智譜 BigModel 的 autoglm-phone，或 ModelScope 的 ZhipuAI/AutoGLM-Phone-9B），選項 B 是自己用 vLLM 或 SGLang 把 9B 模型架在配 NVIDIA GPU 的伺服器上跑。注意，這兩條路都沒有把模型推論擺進手機裡，9B 參數的視覺語言模型本來就不是手機晶片能順暢吃的尺寸。手機在官方架構裡，從頭到尾都只是「被控制」的那一端。

Luokavin 的手機變體把架構比較表直接寫進 README，比大多數同類變體誠實一截。它列出的架構欄位（節譯自 Luokavin README）包括「執行環境：手機」「裝置連接：無需連接，獨立運作」「權限取得：Shizuku 服務」「文字輸入：內建 AutoGLM Keyboard」「截圖方式：Shizuku shell 命令」，把官方桌機版要用的 Python、ADB、ADB Keyboard 全部換掉。但這張表刻意沒有列「模型推論在哪跑」這一欄，只在系統需求裡用一行帶過：「網路連接：需要連接到模型 API 服務（支援任何 OpenAI 格式相容的視覺模型）」。也就是說，手機端獨立出來的只有「控制層」，AI 視覺理解與動作規劃這個最吃資源的「推論層」，還是走 Open-AutoGLM 官方那套雲端 API。

「免電腦」這三個字的真正意思是：你不用再開筆電跑 main.py、不用接 USB 線、不用打 ADB 指令。代價是那條本來在電腦與手機之間的實體連線，換成了手機與雲端模型 API 之間的網路連線，每次截圖、每次判畫面、每次決定下一步都要上雲端走一趟。這個取捨本身沒有絕對好壞，但你得知道自己在換什麼。 要理解手機變體為什麼非得靠 Shizuku 與自製輸入法不可，關鍵在 Android 的權限設計。官方桌機版用 ADB 時，等於借用開發者層級的 shell 權限去送 input tap、screencap 這類系統指令，這條路只有在手機開了 USB 偵錯時才通。手機變體沒有 ADB 可用，就得靠 Shizuku 這個中間人：它本身也是透過無線偵錯或 Root 取得一個常駐的特權服務，再以 binder 把那個特權借給其他 App 使用，所以 Luokavin 變體才能用 Shizuku shell 命令做到原本 ADB 才做得動的截圖與點擊。至於文字輸入，Android 系統只讓目前的輸入法送文字進欄位，於是變體就內建一個「AutoGLM Keyboard」當預設輸入法，靠它把模型想打的字塞進當前焦點欄位，官方版用的 ADB Keyboard 是同一個思路的桌機版前身。換句話說，手機變體在 Android 系統裡搬了好幾道手腳，才能用 App 身份做到原本只有開發者工具能做的事，這也是它一定要你啟用 Shizuku、一定要你切換輸入法的原因。 另一個容易被「OpenAI 格式相容」這句話掩蓋的事實是，能填進 App 設定頁的模型其實很有限。Open-AutoGLM 官方在 README 明列它訓練的是 AutoGLM-Phone-9B 這個針對中文手機介面優化的模型，另有 AutoGLM-Phone-9B-Multilingual 處理英文等場景，這兩個才是被實際訓練來讀手機畫面、規劃 GUI 動作的模型。你當然可以把 base_url 指向任何 OpenAI 相容的視覺模型端點，但通用視覺模型並沒有受過「點手機第幾個按鈕、座標落在哪」這類 GUI 決策訓練，實際跑起來的辨識準確度會落差很大。所謂的「多模型支援」真正能用的範圍，是智譜 BigModel 與 ModelScope 這兩個代管 AutoGLM-Phone-9B 的 API，不是「任何 GPT-4V 都能直接替換上」。

Pin

三個讀者最常問的問題

它真的「在手機上」跑 AI 嗎

沒有。手機負責的只有截圖（透過 Shizuku shell 命令）、把截圖往 OpenAI 相容格式的視覺模型 API 送、再執行模型回傳的點擊或滑動指令。模型推論發生在雲端，確切地點是你填進 App 設定的那個 base_url 對應的伺服器，最常見的是智譜 BigModel 或 ModelScope 的 API 端點。這個設計不是 Luokavin 獨有，整個 Open-AutoGLM 生態的官方預設也是這樣，差別只在官方版那層「雲端」是顯性的（你會在電腦上看 main.py 呼叫 API），手機變體把它收進 App 設定頁讓你比較無感。如果你的使用情境對「畫面離開手機就上雲端」很敏感，這款工具的整個決策核心就踩在你的紅線上。

那我要裝哪一個變體

這得看你介意哪種風險。Luokavin 版本數最高、Stars 最多、README 最完整、走 MIT 授權，是入門理解架構最清楚的樣本，但它最新 release 停在 v0.0.6（2026 年 1 月 4 日），main 分支最後一次 commit 是 2026 年 1 月 15 日，到現在已經半年沒新進度，其中一則 commit message 直接寫「WIP code sync, incomplete features」，也就是作者自己標註功能未完成。0.0.x 的版號搭配半年停滯，是很標準的「早期 alpha，不要拿來當依賴」訊號。xinzezhu 版本到了 2026 年 7 月還在推 commit，但走 GPL-3.0，任何你想拿它做商業衍生產品的人都要連帶開源。sidhu-master 版本檔案最大（APK 超過 200MB），懷疑包了 binary 進去，而且授權欄是 NOASSERTION，等於授權狀態未明確，商業使用風險最高。butlanys 版本自稱「完全本地化」，但前面提過，模型推論仍走雲端 API，「本地化」指的是控制層而非推論層，這個用詞容易誤導。

它跟站上介紹過的 OMG-Agent 差在哪

站上之前寫過的 OMG-Agent，定位是用自然語言操作 Android 的「桌面原型」，而且授權嚴格說是 source-available，不是真正的開源。AutoGLM For Android 變體則反過來，把「桌面」拿掉、把手機端獨立出來，授權部分 Luokavin 是真 MIT、xinzezhu 是 GPL-3.0、butlanys 是 Apache-2.0，多數比 OMG-Agent 寬鬆。同樣是 Android GUI Agent，一個走桌面原型路線、一個走手機獨立 App 路線，兩者適合的是不同使用情境：你想在自己的電腦上做實驗與開發，OMG-Agent 那條路比較透；你想隨身帶著用手機點任務，AutoGLM 變體才踏進你的情境，但代價就是前面講的雲端依賴。

裝之前要先接受的四個限制

這款工具能不能用，取決於你能不能接受它目前這組很現實的邊界：

• 整支手機的畫面會持續截圖往雲端送。任務執行當下，你畫面上的所有內容（含聊天、銀行、郵件、照片）都會變成圖檔傳給你設定的那個模型 API，因此模型營運方等於能看見這些畫面。Luokavin 雖然提供「日誌導出，自動脫敏」功能，但脫敏只覆蓋你導出的除錯日誌，不覆蓋往雲端送的那批截圖。
• Shizuku 啟動條件本身就有但書。變體 README 把 Shizuku 啟動分成三條路：無線偵錯（Android 11 以上，重新啟動後要重新配對）、ADB 連接（這條還是要電腦）、Root 授權（要已 root）。換句話說，「免電腦」只有在無線偵錯或 Root 這兩條路才成立；想用 ADB 啟動 Shizuku 的人，依然要在電腦上跑一次 adb shell。
• 模型計費與可用性跟著智譜與 ModelScope 走。autoglm-phone 目前對外描述為「限時免費開放」，這個「限時」什麼時候結束、何時改收費、收多少，以智譜官方公告為準， App 端無法控制。Open-AutoGLM 官方 README 也明列它只是「第三方模型服務」選項之一，沒有為這個計費條件背書。對長期使用的人來說，這是一條隨時會變動的成本變數。
• 整個生態還在很早的階段。Open-AutoGLM 官方框架本身是 2025 年 12 月才開源的專案，Luokavin 變體 2025 年 12 月 27 日才開第一個 commit，多數變體最新版號都還停在 0.0.x，等於你裝的是一份大家還在摸石頭過河的實驗品。對日常依賴穩定生產力工具的人，現在投入的風險報酬比並不值得。

Pin

適合誰，不適合誰

這款工具目前最對口的受眾，是會自己讀 Kotlin 原始碼、能分辨雲端與本地推論差異、並且對「畫面上雲端」這件事有充分自覺的 Android 自動化愛好者。對這群人，社區變體把 Open-AutoGLM 那套要連電腦的框架縮成一支手機 App，是很值得動手玩一遍的工程展示，也能當作理解 GUI Agent 架構的教材。

反過來，如果你屬於下面任何一種情境，現在還不是動手的時機：你的手機上有不能離開視線的敏感資料（金融、醫療、企業帳密）；你期待的是「裝完就能穩定跑」的生產力 App；你希望 AI 推論完全在手機上發生不外送；或者你打算把它當成日常商業流程的依賴工具。對你來說，真正 on-device 的替代方案（例如把瀏覽器操作流程留在本機跑的 WebGPU 本地 RPA 這類工具），會是更貼合「資料不出本機」訴求的選擇；如果你只是想理解 Android GUI Agent 的設計思路，OpenCyvis 這類同類工具也提供另一個參考點。

把「AutoGLM For Android」當成一個名字、而不是一個產品來讀，會比較接近它現在的真實狀態：它是一群社區開發者把智譜官方 Open-AutoGLM 框架的手機端控制層，各自打包成 App 的集合現象，不是智譜官方出品的手機版，模型推論不在手機上，多數變體還在 v0.0.x 階段。能不能裝來玩，答案因人而異，但玩之前得先把這幾件事放在眼前。