Google 在 Gemini API 裡把 Computer Use 推到了更靠前的位置。簡單說,它讓模型不只會「回答」,還可以看螢幕截圖、判斷下一步要點哪裡、輸入什麼,然後把這些動作交給你的客戶端程式去執行。
這類能力適合做瀏覽器自動化 Agent,例如測試網站流程、填寫重複表單、整理網頁資訊、做簡單的跨站研究。它不是「給模型一台電腦就結束」,真正的工程重點在於:模型負責規劃動作,你的程式負責安全執行、截圖回傳和中斷控制。
官方文件入口:
|
|
它怎麼運作
Computer Use 的基本迴圈是:
- 程式把任務描述、工具配置、目前螢幕狀態發給 Gemini。
- Gemini 回傳一個動作,例如點擊、輸入、捲動、開啟頁面。
- 程式用 Playwright、行動端自動化框架或桌面自動化工具執行這個動作。
- 執行後重新截圖,把新狀態回傳給 Gemini。
- 重複流程,直到任務完成、觸發安全確認,或程式主動停止。
Gemini API 不會替你真的點瀏覽器。它回傳的是建議的介面操作,執行權在你的客戶端。
推薦模型和介面
目前官方推薦:
|
|
介面走 Interactions API,並在 tools 裡啟用:
|
|
environment 用來告訴模型它面對的是什麼操作環境。瀏覽器自動化最容易上手,因為 Playwright 已經封裝好點擊、輸入和截圖。
Python 最小範例
|
|
|
|
建議開啟 enable_prompt_injection_detection。Computer Use 會讀取螢幕內容,網頁裡可能藏有提示注入文字,這至少能多加一層保護。
接上 Playwright 才能執行
|
|
Gemini 回傳的座標通常是歸一化座標,需要換算成真實螢幕座標:
|
|
如果模型回傳:
|
|
客戶端可以執行:
|
|
執行後再截圖,把結果交給模型進入下一輪。難點不是第一條請求,而是把「模型回應、執行動作、截圖回傳、繼續請求」這條迴圈做穩。
先從小任務開始
不要一開始就讓它操作真實後台。可以先做:
|
|
或:
|
|
這些任務不涉及真實帳號和資金,也方便觀察每一步的 intent 是否合理。
安全邊界要先寫清楚
- 使用沙盒瀏覽器、容器或虛擬機,不要操作主力瀏覽器。
- 禁止讀取歷史、自動填入、已儲存密碼。
- 登入、付款、提交訂單、發訊息、發布內容、接受協議時必須讓使用者確認。
- 不要讓模型處理驗證碼或繞過人機驗證。
- 對可訪問網站做白名單或黑名單。
- 記錄提示、截圖、模型動作、安全判斷和最終動作。
瀏覽器 Agent 一旦接入真實帳號,風險就不只是點錯按鈕,還可能變成資料外洩、誤發送、誤購買或誤提交。
和普通函式呼叫的差異
普通函式呼叫像是讓模型選擇要呼叫哪個 API;Computer Use 更像讓模型看著真實介面操作。如果系統有穩定 API,優先用函式呼叫。只有必須走介面、做端到端測試或處理網頁互動時,才更適合用 Computer Use。
常見踩坑
1. 以為模型會自己控制瀏覽器
不會。模型只回傳動作,你要寫執行器。
2. 座標沒換算
視窗大小、縮放比例、截圖尺寸都要固定,否則點擊會偏。
3. 頁面狀態不乾淨
彈窗、Cookie 橫幅、通知授權、登入狀態變化都會影響模型判斷。
4. 沒做中斷條件
至少限制最大步數、最大時間和高風險動作確認。
5. 用於關鍵決策
這是預覽能力,涉及金融、醫療、政務、帳號安全或不可逆提交的任務,不適合直接放手自動完成。
實用架構
|
|
適合與不適合
適合 Web 應用端到端測試、後台重複錄入、公開網頁資訊整理、帶截圖證據的流程驗證,以及低風險內部工具自動化。
不適合自動登入敏感帳號、付款下單、繞過驗證碼、生產後台不可逆操作,以及隱私、財務、醫療等敏感資料處理。
總結
Gemini Computer Use 的價值不是讓模型隨便點電腦,而是把瀏覽器自動化從固定腳本推進到「根據螢幕狀態決定下一步」。想用好它,要固定執行環境、寫好動作迴圈,並把安全規則前置。