Google 在 I/O ２０２６ 把 Gemini API 往 agent 平台推了一大步：Managed Agents。
過去開發者要做一個能跑工具、讀檔案、寫程式、保留狀態的 agent，通常要自己組好幾層東西：模型 API、工具 schema、sandbox、檔案狀態、重試、權限、log、任務排程。Managed Agents 的方向是把其中一大段變成平台能力。
Google 的說法很直接：用一次 API call，就能啟動一個會推理、會使用工具、會在隔離 Linux 環境執行程式的 agent。
Managed Agents 解決什麼問題？
Agent 開發最麻煩的不是模型會不會回答，而是模型回答之後要怎麼安全地做事。
典型自建 agent stack 會遇到：
| 問題 | 自建成本 |
|---|---|
| 工具呼叫 | 要設計 schema、retry、錯誤處理 |
| 程式執行 | 要準備 sandbox、限制權限、清理環境 |
| 多輪任務 | 要保存檔案、狀態、上下文 |
| 安全 | 要管 token、檔案、網路、命令執行 |
| 觀測性 | 要記錄每一步決策與工具輸入輸出 |
| 成本 | 長任務容易反覆呼叫模型與工具 |
Managed Agents 把核心定位放在「少搭基礎設施，先把 agent 行為做出來」。
這對 developer tool、內部平台、自動化團隊很有吸引力，因為很多 prototype 卡住的地方不是 prompt，而是安全執行環境。
它和一般 Gemini API 差在哪？
一般 Gemini API 比較像模型呼叫：你給 prompt、工具定義或上下文，模型回應。
Managed Agents 則更像一個受管理的任務環境：
| 比較 | 一般 Gemini API | Managed Agents |
|---|---|---|
| 核心單位 | model response | interaction／agent task |
| 狀態 | 開發者自行保存 | 可保留檔案與環境狀態 |
| 程式執行 | 自行串接 | 內建隔離 Linux 環境 |
| agent harness | 自建 | Antigravity agent harness |
| 適合場景 | 生成、分析、工具選擇 | 多步驟任務、自動化、程式執行 |
Google 表示 Managed Agents 使用 Antigravity agent harness，並與 Gemini 3.5 Flash 共同最佳化。這代表它不是把聊天模型硬接到 shell，而是把 Google 自家 agent 產品使用的 harness 開放成 API 能力。
Persistent isolated environments 為什麼重要？
Google 強調每個 interaction 可建立持久、隔離的環境，後續呼叫能保留檔案與 state。
這對 agent 很關鍵。
假設你要做一個「讀 CSV、清資料、產生圖表、修正錯誤、輸出報告」的 agent。若每次呼叫都沒有狀態，模型就必須重新理解檔案、重新讀取、重新整理上下文，成本與錯誤率都會上升。
有持久環境後，流程可以變成：
- 上傳資料與任務說明。
- Agent 在 sandbox 中產生分析腳本。
- 執行後發現欄位格式錯誤。
- 後續 interaction 沿用同一環境修正腳本。
- 產出 CSV、圖表、Markdown 報告。
這比較接近真人開發者的工作方式：不是每一步都從零開始，而是在同一個 workspace 裡逐步修。
可以用在哪些產品？
Managed Agents 最適合先放在「邊界清楚」的工作裡。
| 場景 | 適合度 | 原因 |
|---|---|---|
| 內部資料清理 | 高 | 檔案與輸出格式明確 |
| 小型 coding assistant | 高 | 可限制 repo、指令與環境 |
| 文件轉換與摘要 | 高 | 風險較低，成果容易檢查 |
| 客服後台工具 | 中 | 需要更細的資料權限 |
| 自動改 production database | 低 | 風險過高 |
| 金流、醫療決策 | 低 | 需要 deterministic 流程與人工審核 |
Managed Agents 能降低開發門檻，但不會讓高風險流程自動變安全。
和 Antigravity ２．０ 的關係
Google 同場也介紹 Antigravity ２．０ desktop app、Antigravity CLI、Antigravity SDK，以及 Antigravity 與 Gemini Enterprise Agent Platform 的整合。
可以把它看成三層：
| 層級 | 對象 | 功能 |
|---|---|---|
| Antigravity app／CLI | 開發者個人 | 建立與操作 coding agents |
| Antigravity SDK | 平台開發者 | 定義 agent 行為並部署到自有基礎設施 |
| Gemini API Managed Agents | API 開發者 | 用受管理環境快速啟動 agent |
這三個產品不是彼此取代，而是同一個 agent harness 在不同入口的呈現。
導入前要先設計的 ５ 件事
１．權限邊界
Agent 能跑程式，就一定要限制它能碰什麼。
最基本要定義：
- 能讀哪些檔案。
- 能寫哪些目錄。
- 能不能連外網。
- 能不能呼叫內部 API。
- 能不能存取憑證。
- 產出是否需要人工 review。
２．狀態保存與資料保留
Persistent environment 很好用，但也代表狀態會留下來。
要先確認：
- 檔案保存多久？
- 任務結束後是否自動清除？
- log 裡是否有敏感資料？
- 是否能匯出完整執行紀錄？
- 是否符合公司資料保留政策？
３．成本上限
Agent 任務很容易變成長回合，尤其遇到錯誤時會反覆嘗試。
建議每個任務都設定：
- 最大執行時間。
- 最大模型呼叫次數。
- 最大工具呼叫次數。
- 最大輸出檔案大小。
- 超過上限時轉人工處理。
４．可預測 fallback
不是所有流程都該交給 probabilistic agent。
例如發票驗證、資料庫更新、權限變更、金流操作，應該把 agent 放在建議層，而不是直接執行層。
好的設計是：
- Agent 產生方案。
- 系統用 deterministic validation 檢查。
- 人或規則批准後才執行。
５．觀測性
Agent 做錯事時，最糟的是不知道它為什麼做。
至少要記錄：
- 使用者原始指令。
- 每次模型決策。
- 工具輸入與輸出。
- 檔案變更。
- 錯誤與重試。
- 最終交付結果。
沒有這些紀錄，就很難把 Managed Agents 放進企業 production 流程。
適合誰現在試？
最適合先試的是：
- 平台工程團隊。
- 內部工具團隊。
- AI product prototype 團隊。
- 需要快速驗證 agent feature 的新創。
- 已經在用 Gemini API、Google AI Studio、Antigravity 的開發者。
暫時保守看待的是：
- 需要嚴格 deterministic output 的流程。
- 強合規產業的正式客戶資料處理。
- 無法接受 agent 自動寫檔或跑程式的環境。
- 尚未建立 audit log 與人工審核的組織。
結論
Gemini API Managed Agents 的意義，不只是 Google 多了一個 API，而是 agent infrastructure 開始平台化。
過去要把 agent 做到能穩定跑任務，開發者必須自己補 sandbox、state、tools、retry、log。Google 現在把這些能力往 Gemini API 裡收，讓開發者更快測試「能做事的 AI」。
但 Managed Agents 越強，治理就越重要。它適合從低風險、自動化、可回復的任務開始，不適合一開始就接上不可逆的 production 操作。