谷歌悄悄解决了一个没人敢碰的硬骨头

你刚上线的AI助手决定执行一段代码。可能是解析文件，可能是调用工具，也可能是你写系统提示时完全没预料到的操作。

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

答案是：你的祈祷。

这是每个做AI Agent的人都不愿承认的焦虑——你把基础设施的钥匙交给一个大模型，然后说"请小心"。这不是安全策略，这是赌博。

Google Cloud NEXT '26的260多项发布里， buried在Gemini新闻海啸下的GKE Agent Sandbox，可能是唯一一个解决"Agent落地"真正 blocker 的基础设施。

几乎没人讨论它。

现状：我们在给Agent权力，却没有安全的笼子

Agent执行工具调用时——跑shell命令、写文件、调API、开子进程——那段代码总得有个去处。

今天的常见方案？一个你也用来跑其他服务的容器。或者直接上虚拟机。隔离策略基本等于："我们相信模型不会使坏"。

演示没问题。生产环境灾难。

每个认真做Agent的团队都经历过这段对话："原型我们很爱，但不敢给真实用户用。"

从"笔记本里能跑"到"我愿用饭碗担保它上生产"，差距几乎全是信任和隔离问题。

谷歌的解法：为Agent量身定做的"一次性牢房"

GKE Agent Sandbox的核心设计很直白：隔离、一次性的执行环境，专门让AI Agent跑不受信任的代码和工具调用，且碰不到不该碰的东西。

但细节才是重点。

隔离层基于gVisor——内核级沙箱，在系统调用到达宿主机之前拦截。这是谷歌用来保护Gemini本身的同款技术。不是新实验，是 repurposed 的实战基础设施。

成本方面，跑在Google Axion N4A实例上，价格比性能比声称比主流超大规模云厂商竞品高30%。谷歌还强调，目前主流超大规模云厂商里，这是唯一的原生Agent沙箱服务。

谁在真用：每天20万项目的压力测试

Lovable，那个AI应用构建工具，用户每天生成20万+新项目，用GKE Agent Sandbox跑AI生成的代码。原因很明确：快速启动 + 大规模安全隔离。

不是benchmark，是生产流量。

为什么这事被低估

Agent基础设施的叙事被模型能力抢走了全部注意力。但模型越聪明，它需要的"笼子"就越关键。

谷歌把保护Gemini的同款技术开放出来，等于说：我们赌Agent执行安全会成为标配需求，而不是可选插件。

这个判断本身，比技术细节更值得注意。