Google在Cloud Next '26大会上发布了两项GKE核心更新：GKE Agent Sandbox和GKE Hypercluster。前者解决AI Agent的安全隔离问题，后者试图用单一控制平面管理百万级加速器芯片。Google Kubernetes Engine产品管理高级总监Drew Bradstock与GKE产品组经理Gari Singh在官方博客中写道："Kubernetes已迅速成为AI时代的操作系统，GKE目前为平台上所有前50大客户运行AI工作负载，包括最大的前沿模型构建商。"

这个定位背后是一组行业数据。Databricks统计显示，多Agent AI工作流近期激增327%；CNCF数据则表明，66%的组织现在依赖Kubernetes来运行生成式AI应用和Agent。Google显然想抓住这个窗口期，把容器编排的基础设施优势延伸到AI Agent层。

打开网易新闻 查看精彩图片

GKE Agent Sandbox的技术方案是用gVisor实现内核级隔离。gVisor是Google自研的沙箱技术，Gemini也在用。核心场景是"不可信Agent代码执行"——当AI Agent需要调用外部工具、执行用户上传的代码或访问敏感数据时，传统容器隔离可能不够。gVisor通过拦截系统调用、提供自己的内核实现，把Agent运行环境与宿主机进一步隔离开。

GKE Hypercluster则瞄准规模问题。单一控制平面管理"up to a million accelerator chips"，这个设计针对的是超大规模AI训练集群的运维痛点：多集群管理复杂、资源碎片化、调度延迟。Google没有公布具体技术细节，但"单一控制平面"意味着把调度范围从单个集群扩展到跨地域的芯片池，这对网络拓扑和故障域设计都是挑战。

两个产品的组合逻辑很清晰：Agent Sandbox解决"能不能安全跑"，Hypercluster解决"能不能大规模跑"。Google的赌注是，AI基础设施的竞争会从"谁有算力"转向"谁能让Agent安全、高效地消耗算力"。Kubernetes的编排能力在这里被重新包装为"AI Agent的操作系统"——不是比喻，而是产品战略。

不过落地层面还有未知数。gVisor的性能开销在通用场景已被讨论多年，AI Agent的高频I/O是否会让这个问题更突出？百万级芯片的单一控制平面，故障爆炸半径如何控制？这些Google在发布稿中没提，可能是留给后续技术文档或客户案例的叙事空间。