Agent Compute Engine：每個 AI 代理人一台隔離虛擬機

過去兩年，AI 的話題大多繞著模型本身打轉：誰的參數多、誰的推理快、誰的價格低。但當模型開始被包成「代理人」（agent），能自己開終端機、自己開瀏覽器、在一個迴圈裡連續工作好幾天，問題就從「模型夠不夠聰明」變成了一個很古典的系統工程問題：這些東西該跑在哪裡？

Google Cloud 在 Linux Foundation 舉辦的 AGNTCon+MCPCon 上給出的答案，叫做 Agent Compute Engine（簡稱 ACE）。它的核心主張只有一句話：每一個代理人工作階段，都應該拿到一台自己的、硬體層級隔離的微型虛擬機。

Photo by Shane on Unsplash

Agent Compute Engine 到底是什麼

簡單說，ACE 是 Google 把自家內部跑代理人的基礎設施，包裝成對外販售的雲端服務。這不是一個全新寫出來的產品：依 Google 的說明，Gemini 的代理人功能、開發工具 Antigravity，以及自家的模型訓練流程，目前都跑在同一套東西上。Google 內部把它描述為「Google 統一的代理人運算平台」，現在打算把同樣的平台開放給 Google Cloud 客戶。

它提供的不是一個函式執行環境，而是一台完整的電腦：有 root 權限、可以執行 shell script、可以開無頭瀏覽器、可以讓一段程式在迴圈裡跑上好幾週。對一個需要「邊做邊試、試錯再來」的代理人來說，這跟只能跑一次、回傳結果就結束的無伺服器函式，是兩種完全不同的東西。

為什麼不是容器，也不是傳統虛擬機

這是整件事最值得細看的部分。Google 的理由分成兩邊：

傳統虛擬機太慢。 代理人的工作型態是斷斷續續的——送出一個工具呼叫，然後等模型回覆，然後等使用者確認。真正在用 CPU 的時間可能只佔整段工作階段的一小部分。如果每次啟動、暫停、恢復都要走完整台虛擬機的開關機流程，成本與延遲都撐不住。

容器的隔離不夠。 代理人會執行它自己寫出來的程式碼，而這些程式碼的內容在執行前沒有人看過。容器共用主機核心，缺少某些代理人情境需要的核心層與 root 級隔離。

ACE 的做法是走中間路線：用 microVM。每個工作階段跑在 Cloud Hypervisor（一個開源的虛擬機監控器）上，擁有自己的 guest kernel、自己的 root、自己的 Hyperdisk 儲存。Google 給它的定位是「虛擬機等級的隔離，加上接近容器的速度與密度」。

閒置處理的設計也很直接：沙箱在一次工具呼叫結束時會發出訊號，主機隨即對這台閒置的 microVM 做快照檢查點，讓它不再佔用任何運算資源；下一次呼叫進來時，再從快照恢復。除此之外，這套架構還支援複製、快照分叉、倒帶與回滾——對做評測迴圈或強化學習的團隊來說，這幾個動作比「開一台機器」本身更重要。

把密鑰放在沙箱外面

Photo by Jens Aber on Unsplash

ACE 的安全模型建立在一個相當悲觀的前提上。Google 工程團隊把設計原則寫得很白：假設攻擊者控制了沙箱裡的一切。

這句話帶出的設計，比 microVM 本身更有意思。這些 microVM 沒有標準的網路介面，沒有預設閘道，也不能直接連到 VPC。所有流量都透過 virtio-vsock 走到一個本地 proxy，再送往沙箱外部的 Agent Gateway。閘道會先確認使用者的授權委派與沙箱身分是否相符，通過政策檢查之後，才在沙箱外面把真正的後端憑證加上去。

也就是說，沙箱裡從頭到尾不存任何密鑰，記憶體裡沒有，磁碟上也沒有。它唯一持有的身分，是一組短期、綁定該工作階段的憑證，透過每台虛擬機專屬的本地監聽端口送進去。Google 在這套架構裡定義了四種身分，而真正用於沙箱對外流量的，只有其中一組短效的工作負載身分。

這個設計要處理的，正是代理人時代最尷尬的一種風險：如果提示詞注入成功了，被攻陷的沙箱裡究竟有什麼東西值得被偷走？在 ACE 的設計下，答案是「幾乎沒有」。另外，呼叫模型的那層（harness）完全跑在沙箱外，只透過明確的指令把工作送進去，這也進一步縮小了被攻陷的範圍。主機端則是無狀態設備，root 檔案系統唯讀、以 dm-verity 強制，硬體與韌體在每次開機時都會經過加密驗證，背後靠的是 Google 的 Titan 晶片與 Titanium IPU。

密度：這門生意的成本在哪裡

Photo by Aakash Dhage on Unsplash

給每個工作階段一台虛擬機，聽起來很貴。ACE 用幾個技巧把成本壓下來：預熱過的快照映像以 DAX 方式映射，多個 microVM 透過寫入時複製共用基礎作業系統與函式庫的記憶體頁面，只有被改寫的頁面才會真正佔用私有記憶體。儲存則分成三層——可丟棄的暫存層、共用的唯讀磁碟區，以及放在 Hyperdisk 上的持久工作區。

Google 沒有公布 ACE 本身的密度數字，但公布了它的開源手足 Agent Substrate 的測試結果。這是一套 Apache-2.0 授權、Kubernetes 原生的執行環境，自 9 月 15 日起在 GKE 上提供，非正式環境開放所有 GKE 客戶使用，正式環境的 GA 則採白名單制。Google 表示，在一項二十萬個代理人的基準測試中，Agent Substrate 達到每秒 500 次喚醒、暫停與恢復低於 500 毫秒、單台主機可容納超過一千個休眠代理人，整體運算密度最高可達傳統做法的十倍。

要注意的是，這些數字屬於 Agent Substrate，Google 並未宣稱 ACE 會有相同表現。但方向是清楚的：這門生意真正的競爭點，不在「能不能隔離」，而在「隔離之後還能塞多密、醒得多快」。

市場上已經有人在做同一件事

代理人沙箱不是 Google 獨有的題目。AWS 的 Bedrock AgentCore 同樣為每個工作階段配置專屬 microVM，也有自己的身分服務；Azure 使用 Hyper-V 沙箱，但在冷卻期過後會直接銷毀工作階段；新創公司 E2B 走的是 Firecracker 路線，支援暫停並保存檔案系統與記憶體；此外還有 Daytona 等選手。Google 自己在 GKE 上也早有一套託管的 Agent Sandbox。

幾家的差異，主要落在「閒置時怎麼算錢」與「憑證放在哪裡」這兩件事上。ACE 把閒置狀態檢查點到零資源、把憑證完全移出沙箱，是目前描述得最極端的一套。而在開源這一欄，只有 Agent Substrate 打勾——這一點在企業評估時往往比效能數字更有份量，因為它決定了日後搬不搬得走。

還沒公布的部分

ACE 目前仍只有預覽登記表單，Google 說的時間是「今年稍晚」或「未來幾個月」，沒有確切日期。更關鍵的是，定價、開機時間、密度數字、SDK 與 API 細節、單次工作階段的長度上限，全部尚未公開。對照之下，AWS 的 microVM 工作階段上限標示為 8 小時，而 ACE 宣稱支援「跑上好幾週」的迴圈——這兩個數字之間的差距，最後會以什麼樣的計價方式呈現，是觀察這項服務時最該盯住的一欄。

觀察與評論

把這則消息放回更大的脈絡來看，它其實標誌著一個轉向：雲端業者開始把「代理人」當成一種新的運算單位來設計基礎設施，而不是把它當成應用層的一個功能。過去十五年，雲端的計價單位從虛擬機走到容器，再走到函式；現在冒出來的是第四種單位——一個會自己思考、會停下來等、可能一等就是幾個小時的工作階段。

傳統的計價模型對這種型態並不友善。一個代理人若有九成時間在等模型回覆，按機器開機時間收費顯然不合理；但按呼叫次數收費，又無法反映它持有的那份狀態。ACE 用「閒置時檢查點到零資源」給出一個答案，而這個答案要到定價公布那天，才知道對客戶是不是真的划算。

另一個值得注意的訊號是安全模型的語氣。「假設攻擊者控制了沙箱裡的一切」這種前提，通常出現在多租戶託管、惡意程式分析這類場景。把它套用在企業自己部署的代理人上，等於承認了一件事：當代理人執行的是它自己即時生成、沒有人事先審閱過的程式碼時，它在信任模型裡的位置，其實更接近外部程式碼，而不是內部員工。這個觀點目前還沒有成為業界共識，但 ACE 的設計是朝這個方向走的。

對一般企業而言，這類基礎設施短期內不會是採購清單上的項目——多數團隊的代理人還停在「串幾個 API、跑個幾分鐘」的階段，用不到硬體隔離的微型虛擬機。但這套服務的輪廓透露了大廠對未來兩年的判斷：他們預期會有大量、長時間執行、具備真實系統權限的代理人出現，而且多到需要專門的運算層來承接。值不值得現在就跟進是一回事，知道大廠正在為什麼樣的場景鋪路，則是另一回事。