你的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是否有对等产品，开源社区是否会形成标准抽象。
但有一点已经清楚：把代理执行随便丢进容器的时代，正在结束。
热门跟贴