谷歌偷偷解決了AI代理最頭疼的隔離難題

你的AI代理剛剛決定運行一段代碼。可能是執行工具調用，可能是啟動子進程解析文件，也可能是你寫系統提示時沒預料到的操作。

什么在阻止它執行rm -rf /？

這個問題讓每位真正部署過AI代理的工程師夜不能寐。谷歌在Cloud NEXT '26的260多項發布中，悄悄藏了一個可能改變行業游戲規則的答案。

那個沒人愿意承認的真相

當前AI代理的狀態用一個詞概括：失控的信任。

代理執行工具調用時——運行shell命令、寫文件、調用API、生成子進程——這段代碼總得在某處運行。大多數現有方案里，這個"某處"是你同時用于其他任務的容器。更糟的是直接跑在虛擬機（VM）上。

隔離策略本質上是："我們相信模型不會干壞事。"

演示Demo這么玩沒問題。生產環境這么玩是災難。

問題在幾個場景下急劇惡化：

多租戶代理應用：一個用戶的代理理論上能干擾另一個用戶的執行環境

自主代理：運行越久、人類監督越少，執行的代碼越多，任何錯誤的波及范圍就越大

第三方工具：你運行的不只是自己的代碼。代理調用外部工具、MCP服務器、返回任意載荷的API

每個認真做代理的團隊都有過這種對話："原型我們很愛。但讓用戶真實使用？怕得要死。"

從"筆記本里能跑"到"拿飯碗擔保上線"的鴻溝，幾乎全是信任和隔離問題。

谷歌到底發布了什么

NEXT '26大會上，谷歌宣布GKE Agent Sandbox正式商用（Generally Available）。

一句話總結：為AI代理專門設計的隔離、一次性執行環境，運行不可信代碼和工具調用，同時確保碰不到不該碰的東西。

但細節才見真章。

隔離層基于gVisor，在內核層面攔截系統調用，阻止其到達宿主機。這是谷歌用來保護Gemini本身的同款技術。不是新實驗，是久經沙場的基建被重新用于代理工作負載。

規模數字：每集群每秒啟動300個沙箱；首次指令執行時間低于1秒；每個沙箱有狀態（stateful）。

這些數字意味著代理可以頻繁、快速地生成隔離環境，同時保持執行上下文。不是"跑完就扔"的無狀態容器，而是能承載復雜代理工作流的臨時安全艙。

谷歌把自家保護大模型的基礎設施開放給了所有人。這本身就是信號。

為什么現在才有人做

隔離執行環境不是新概念。容器、虛擬機、沙箱技術存在多年。

但AI代理的需求組合是新的：

啟動速度要快（代理不能等幾十秒環境就緒）

隔離要徹底（不可信代碼必須真·隔離）

要有狀態（代理需要記住剛才做了什么）

要可擴展（每秒數百個沙箱）

傳統方案在這幾點的權衡上總是顧此失彼?？斓牟话踩踩牟粔蚩?，能擴展的沒狀態。

谷歌的解法是把gVisor的輕量級虛擬化與GKE的編排能力結合，再針對代理場景優化啟動路徑。不是通用沙箱的重新包裝，是從頭為"LLM生成代碼執行"這個特定模式設計的。

這解釋了為什么"隔離代理執行"這個顯而易見的需求，直到2026年才有大廠拿出生產級方案。問題不是技術不存在，是要把正確的技術以正確的方式組合，并愿意承擔支持它的長期成本。

誰該關心這件事

如果你在做任何讓LLM執行代碼的系統，答案是你。

具體場景包括：

代碼生成工具（Copilot類產品的執行層）

數據分析代理（讓LLM跑Python/R處理用戶上傳文件）

自動化工作流（代理調用API、操作數據庫、部署服務）

多租戶SaaS（一個平臺托管多個客戶的代理，必須嚴格隔離）

這些場景的共同點：代碼來源不可信（LLM生成），執行環境必須可信（不能讓用戶A的代理看到用戶B的數據）。

谷歌的方案不是唯一路徑。你可以自己用gVisor搭，用Firecracker，用各種開源組合。但"正式商用"意味著SLA、支持、文檔、持續維護——這些是企業生產決策的真正成本。

更重要的是，它驗證了方向：代理隔離是基礎設施問題，不是應用層能湊合的。

沒說完的部分

原文發布時GKE Agent Sandbox剛GA，具體定價、與Vertex AI的集成深度、多云支持策略等細節尚未完全公開。谷歌的典型節奏是先推核心能力，再逐步擴展生態。

已知的是技術底座：gVisor的syscall攔截、GKE的編排、每秒300沙箱的啟動能力。未知的是市場會多快跟進——AWS和Azure是否有對等產品，開源社區是否會形成標準抽象。

但有一點已經清楚：把代理執行隨便丟進容器的時代，正在結束。