谷歌偷偷解决了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是否有对等产品，开源社区是否会形成标准抽象。

但有一点已经清楚：把代理执行随便丢进容器的时代，正在结束。