一個客體核心先被搬了進來：Agent Compute Engine，把代理的執行邊界設計成一頁可驗收的介面

2026 年 10 月 22 日，APPI News 刊出一篇整理 Agent Compute Engine 的整合指南。Google 將這項服務描述為代理專用、具硬體隔離的微型虛擬機（microVM）執行環境，預計稍後開放預覽。訊息本身很短，但短訊裡有一個值得停下來看的設計動作：把「代理會跑不可信程式」這件事，從散落各處的風險，收攏成一個有邊界、有生命週期的執行單位。

隔離落在哪一層，決定了介面長什麼樣

代理任務的工作方式很雜：規劃、執行命令、讀寫檔案、等待回應，還會在多個工作階段之間暫停與恢復。若多個任務共用作業系統核心，一個設定錯誤或程式漏洞就可能跨工作空間外溢。微型虛擬機的做法是給每個代理一個自己的客體核心，讓核心與執行狀態被硬體虛擬化隔開。

這裡的設計語彙是「邊界」。容器以主機核心提供隔離，啟動快、工具鏈成熟，適合程式來源可控的高密度服務；微型虛擬機多了一層客體核心，代價是記憶體、映像與維運成本都可能上升。來源整理的比較表把差異放在核心邊界、啟動資源、相容性與維運四個面向，但結論很節制：實際隔離效果仍須依配置與工作負載驗收，不能只憑方案名稱判斷。這句話本身，就是一份誠實的介面說明。

值得注意的是，Google 自家就有一組名字相近的方案：Agent Executor 是開源分散式 runtime，Agent Substrate 是 GKE 執行層、可選微型虛擬機或 gVisor 並以閘道管理網路請求，Gemini Enterprise Agent Platform 也有自己的沙箱。來源特別提醒，這些是不同方案的功能，不能套作 Agent Compute Engine 的規格。對導入者來說，這是命名系統的設計問題：名字相近的產品線，各自的介面承諾並不相通。

沙箱畫得出邊界，畫不出判斷

隔離設計有一條清楚的上限。沙箱能縮小程式錯誤波及主機或其他租戶的範圍，卻不會判斷代理指令是否合理。持有高權限憑證或任意網路出口的代理，照樣可能刪除資料或把內容傳出去。指南把這一點寫得很直白：執行隔離、授權、工具政策與監控必須共同設計。

憑證是最具體的一環。若祕密值直接放進代理可讀的環境，沙箱隔離本身無法阻止代理透過輸出或連線把它帶出去。指南建議由沙箱外的閘道代送認證、限制憑證可用端點、保留輪替與撤銷能力，並先畫出資料流：代理代表誰、讀哪些資料、呼叫哪些 API、結果寫到哪裡。Google 的 Managed Agents 文件也描述了類似做法，其 MCP 認證標頭只傳給設定的對象。這與我們先前觀察的Muse Gadgets 配對介面有同樣的設計直覺：權限的形狀，決定了硬體或代理能碰到什麼。

同樣的分層思考也出現在其他代理設計的討論裡。把「模型不準瞎編」從提示詞升級成協議層契約的rea 協議設計，與這裡的憑證閘道方向一致：信任問題最終都會被設計成某種可檢查的邊界，而不是留在模型的善意裡。

「硬體隔離」四個字，不能當成測試報告

指南最有價值的部分，是它對行銷語言的保留。目前公開的產品說明仍有限，整合方式、區域、計價與服務條款都要等預覽後才能確認；「硬體隔離」屬於產品設計描述，不能當成獨立安全測試結果。導入前仍要界定威脅模型，盤點資料、工具與網路權限，並確認幾個具體問題：隔離單位是代理、工作階段、任務還是租戶？環境重用後，檔案、快照或記憶體是否殘留狀態？

Agent Compute Engine 還沒開放預覽，能看到只有一份設計意圖：把代理最危險的部分，放進一個畫好邊界的盒子。這個方向是對的，但介面的誠實度要到預覽時才見真章。一個好的沙箱產品，最終交付的應該是可驗收的證據清單，而非「硬體隔離」四個字本身。在那份清單出現之前，這項服務值得觀察，還不值得信任。