Google太狠了！要統治幾十億手機

在上月底舉辦的三星 Galaxy S26 發佈會上，三星和Google官宣將在 Galaxy S26 上首發基於 Gemini 的 Screen Automation（螢幕自動化）的能力。

簡單來說，就是 Gemini 可以直接在手機螢幕上操作應用：打開 APP、識別螢幕、點選滑動、輸入文字……完成一連串 UI 操作，最後再把確認步驟交給使用者。

沒錯，聽起來就和努比亞 M153（坊間俗稱「豆包手機」）上的豆包手機助手一樣，都是能替代人類在手機上進行「代理」操作，實現一句話點外賣、叫車、網購等需求。

從海外媒體和論壇的反饋來看，這項功能終於在最近的測試版更新中上線了。

不過我們也發現，Google並沒有全盤學習豆包手機助手的做法。雖然在技術實現路徑上同樣基於 GUI 的 Agent，但 Gemini 會基於 Android 開啟一個本地的虛擬沙盒，同時還主動限制了首批開放 Gemini「操作」的 APP，僅限少數一批應用。

這種處理方式與國內廠商顯然不太一樣。甚至可以對比字節的豆包手機助手和阿里的千問，Google選擇了一條看起來既激進、又保守的路線。

讓 AI 作業系統，而不是接管手機

只看功能表面，Gemini 的「螢幕自動化」很容易被理解為另一種「豆包手機助手」。它同樣可以替你點外賣、叫車、下單，看起來也像一個能替人操作手機的 AI 代理。

但如果把視角往下再挖一層，就會發現Google的方案其實完全不是一回事。

豆包手機助手的邏輯很簡單：AI 讀取螢幕像素，像人眼一樣識別按鈕和輸入框，然後模擬手指點選。這種方式最大的優點就是通用——理論上任何 APP 都能操作，因為 AI 看到的只是螢幕。

Gemini 明顯更「保守」。在實際執行任務時，Gemini 並不會直接在你的手機桌面上操作應用，而是會在 Android 系統裡開啟一個本地的虛擬沙盒窗口，讓 AI 在這個環境裡運行目標 APP。

整個過程是可見的，使用者可以隨時終止任務，也可以在任何一步接管操作。

簡單來說，Gemini「螢幕自動化」在產品定位上並不是一個可以隨意操控手機的萬能代理，而是一個被系統嚴格約束的自動化能力。

Google還主動限制了第一批支援自動化的應用數量。目前開放的主要是打車、外賣和餐飲類服務，僅支援 Lyft、Uber、GrubHub、DoorDash、Uber Eats 和星巴克。

也限制了「使用者範圍」。目前除了三星 Galaxy S26 系列已經可以在測試版中體驗，Google也僅規劃了 Pixel 10 系列支援，同時 Gemini 免費使用者每天僅有 5 次使用額度、Plus 會員 12 次、Pro 會員 20 次、Ultra 會員 120 次。

這裡既有算力的考量，也在於使用者對 AI「亂動手機」的擔憂，尤其是在歐美市場。所以Google做了權限隔離、關鍵步驟必須要使用者手動操作、可以即時中斷 AI 操作等。

但說到底，這只是過渡階段，Google的野心絕不止是讓 Gemini 僅僅能夠操作幾個特定 APP。

很多人注意到 Gemini 的 GUI 操作能力，卻忽略了 Android 在系統層面正在發生的一件事情。

就在三星 Galaxy S26 系列發佈會前夕，Google官方發佈了一篇博文名為《智能作業系統：讓 AI 代理對Android應用更有幫助》，並正式推出了一套新的應用能力介面體系——AppFunctions，允許 APP 主動向系統聲明自己可以被 AI 呼叫的功能。

舉個例子，一個外賣 APP 可以告訴系統：支援搜尋餐廳、加入商品、提交訂單這些能力。當使用者對 Gemini 說「幫我點一份披薩」時，AI 並不一定需要逐步點選介面，它可以直接呼叫這些能力完成任務。

如果把這套機制理解成 AI 的「函數呼叫」，事情就變得非常清晰了。在Google的設計裡，AI 代理其實有兩條路徑可以執行任務，一種是通過系統介面直接呼叫應用能力，另一種才是通過識別螢幕介面來進行 GUI 自動化。

前者效率更高、穩定性更好；後者則是為了相容那些沒有適配新介面的應用。

這意味著 Gemini 未來的裝置自動化能力，本質上並不是單純的「AI 看螢幕操作手機」，而是一種系統 API 與 GUI 混合的架構。

這個差異聽起來有點技術化，但它背後的產品邏輯其實非常簡單。相比豆包手機助手讓 AI 像人一樣使用手機，Google想做的事情是讓 AI 像系統一樣調度應用。

當 AI 只是讀取螢幕像素時，它始終站在系統之外，只能模仿人的操作邏輯；但一旦 AI 被放進作業系統內部，它就可以直接協調應用之間的能力。

從這個角度看，Gemini Screen Automation 的真正目標或許並不是點外賣、叫車這些場景。Google真正想建立的，是一種新的 Android 運行邏輯和生態。從這裡出發，我們也能在一定程度上明白，為什麼Google要和高通聯手推動「Android電腦」（非 Chromebook）。

也解釋了為什麼 Gemini 的方案看起來既激進又保守。

激進的地方在於，它試圖把 AI 變成 Android 的調度中心；保守在於，Google並不打算讓 AI 隨意接管整個手機，而是通過系統介面、權限控制和應用白名單，一步一步推進這種變化。

相比「萬能 AI 代理」的想像，這種路線顯然更慢，也更克制。但對於一個擁有數十億裝置的作業系統來說，Google可能也沒有太多激進試錯的空間。

豆包向左，千問向右，Gemini 走中間

相比Google在手機上的做法，去年底亮相的豆包手機助手選擇了最簡單、也最激進的一種方式：讓 AI 像人一樣使用手機。

在這套方案裡，AI 讀取螢幕像素，識別按鈕、輸入框和頁面結構，然後模擬手指點選完成操作。無論是點外賣、比價購物還是下單支付，AI 都是在手機介面上一步步執行。

這種方式最大的優勢就是通用。因為 AI 看到的只是螢幕，它不需要任何 APP 的介面支援，也不需要平台授權。理論上，只要是人能操作的應用，AI 都可以完成同樣的操作。

這也是為什麼很多人第一次體驗豆包手機助手時，會覺得它像一種「真正的 AI 手機」。

但問題也同樣明顯。當 AI 可以讀取整個螢幕並操作所有應用時，權限和安全問題就不可避免。同時，很多網際網路平台也並不歡迎這種自動化行為，因為它繞過了平台自身的入口和推薦體系。

簡單說，豆包的路線技術上非常直接，但也天然會和應用生態產生摩擦。

相比之下，阿里的千問走的是另一條思路，利用阿里自己的服務生態，讓 AI 成為一個調度中心。在這套體系裡，使用者的一句話會被拆解成具體任務，然後分別呼叫淘寶、支付寶、高德、飛豬等服務來完成。

比如搜尋商品、下單支付、規劃路線，都是直接呼叫真實業務能力，而不是模擬介面操作。因為所有操作都發生在生態內部，AI 不需要繞過應用權限，也不會觸發平颱風控，又因為直接呼叫服務介面，執行效率往往也更高。

但問題同樣清晰：生態邊界。千問能夠調度的服務，本質上還是阿里系應用。一旦使用者需求涉及其他平台，能力就會明顯下降。

從這個角度看，豆包和千問其實代表了兩種非常典型的 AI 代理路徑。前者試圖讓 AI 接管手機本身，追求的是通用能力；後者則通過生態整合，讓 AI 接管服務流程，追求的是業務深度。

而Google的 Gemini，某種程度上站在二者之間。在當前階段，Gemini 依然保留了 GUI 自動化能力，這意味著它在必要時也可以像豆包一樣，通過識別介面來操作應用。但與此同時，Google又在 Android 系統裡引入了新的應用能力介面，讓 APP 主動向系統開放可以被 AI 呼叫的功能。

如果應用支援這些介面，Gemini 就不需要再逐步點選介面，而是可以直接呼叫應用能力完成任務。換句話說，Google的方案其實是一種混合路徑：

系統介面優先，GUI 自動化兜底。

從短期來看，這種方式顯然沒有豆包那樣驚豔，也不像千問那樣能夠迅速整合成熟生態。但它的好處在於，既避免了和應用生態的正面衝突，又保留了足夠的通用性。

寫在最後

把視角再拉遠一點，其實不難理解三種路線為什麼會分化成現在這樣。

字節沒有作業系統，也沒有本地生活生態，所以只能讓 AI 直接接管手機；阿里擁有龐大的服務體系，於是讓 AI 去調度自己的業務網路；而Google真正擁有的，則是 Android 這個覆蓋數十億裝置的作業系統。

因此，Gemini 的目標從一開始就不是做一個更強的手機助手，而是把 AI 變成系統的一部分，讓 Android 從「運行應用的平台」慢慢變成「調度應用的智能系統」。從這個角度看，Gemini 的克制並不是保守，而更像是一種平台級公司的必然選擇。 (雷科技)