Gemini 3.5 Flash 把 computer use 變成預設能力，…

Google 把 computer use 內建進 Gemini 3.5 Flash 是對的，因為代理能力應該成為模型原生功能，而不是獨立實驗。

Google 這次做對了：computer use 不該掛在旁邊當一個特例，而要直接長在主模型裡。官方說法很清楚，Gemini 3.5 Flash 讓開發者能做出可在瀏覽器、手機與桌面環境中看、想、做的代理，並把長流程任務如軟體測試與企業自動化視為主要場景。這種能力只有在日常工作流裡才有價值，放在原生模型中，才符合它真正的使用方式。

第一個論點

原生整合勝過外掛式設計，先看架構就知道。Google 表示，computer use 先前只存在於獨立的 Gemini 2.5 模型，現在則原生整合進 Gemini 3.5 Flash。這不是命名差異，而是代理系統的核心差別：規劃、工具使用、動作選擇若能走同一條模型路徑，系統就少一層拼接，也少一層失真。

對開發者來說，這樣的設計直接降低摩擦。你不必再把通用模型、特殊 endpoint、額外的編排層拆開管理。若團隊要做一個能開瀏覽器、填表單、檢查桌面應用的代理，單一模型加單一安全控制，比多服務串接更容易維護。Google 這次把能力放回主幹，就是在承認代理不是附加功能，而是產品本體。

第二個論點

真正有商業價值的，是長流程與企業自動化，而不是一次性的展示。Google 明確把重點放在 continuous software testing、知識工作與專業應用之間的跨介面操作。這類任務的共同特徵是上下文會漂移，介面會切換，流程會變長。能撐過 30 分鐘的任務，才比一個漂亮 demo 更接近企業要買的東西。

官方例子也說明了這一點：3.5 Flash 可以分析 Gemini app 並回傳功能分類清單，也可以檢查自身文件的無障礙問題。這些工作都不炫，但很值錢。企業不需要一個只會贏基準測試的代理，他們要的是能在 UI 改版後仍持續減少人力的工具。若把 computer use 當成原生能力，產品方向就會自然對準這種可重複、可衡量的勞動替代。

第三個論點

這次最值得重視的不是模型有多會點按鈕，而是 Google 把安全當成產品的一部分。官方承認 computer use 會面對 prompt injection，並說已針對這類攻擊做對抗式訓練。更重要的是，它加入兩個企業級保護：敏感或不可逆操作要明確確認，偵測到間接注入時會自動停止。這表示 Google 不是把風險藏起來，而是把風險納入設計。

它的 defense-in-depth 說法也很關鍵。Google 明確要求開發者搭配安全沙箱、人工覆核與嚴格權限控制。這不是公關語，而是能不能上線的分水嶺。代理一旦進入真實軟體環境，安全就不是加分題，而是最低門檻。把 computer use 做成原生功能，反而更容易把這些控制放進同一套系統治理裡。

反方可能怎麼說

反對者的擔憂很合理：把 computer use 內建到旗艦模型，會鼓勵團隊過早自動化。代理一旦能跨瀏覽器、手機與桌面操作，錯誤不再只是回答不準，而是可能刪資料、寄出郵件、改掉設定。從這個角度看，這種能力越原生，越像在放大風險。

另一個批評是，原生整合可能讓產品訊號太強，導致團隊誤以為「模型會做」等於「系統可上線」。現實中，高風險工作流還需要監控、審批、回滾與權限分層。若大家只看到 agent 能動手，就容易忽略真正決定成敗的是周邊治理，而不是模型本身。

但這些批評不能推翻原生整合，反而證明它必須搭配限制。把 computer use 拆成獨立模型，不會自動更安全，只會讓編排更碎、責任更散。真正降低風險的，是明確確認、注入偵測、沙箱與存取控制。Google 這次至少把這些守門機制一起端上來，這才是把能力推進真實世界的正確方式。

你能做什麼

如果你是工程師或 PM，把 Gemini 3.5 Flash computer use 當成受控工作流的基礎設施，而不是自動駕駛。先從可觀察、可回滾、可重複的任務開始，例如表單填寫、測試步驟、文件檢查，再加上確認門檻、操作日誌與失敗回復。若你是創辦人，機會不在「會不會點按鈕」，而在如何把這個能力包成可靠流程；真正的價值會出現在工作流設計，而不是模型演示本身。