Google向CNCF捐赠Agent Substrate与GVisor

作者：Mofi Rahman，Google Cloud 开发者关系工程师；Brandon Royal，Google Cloud 产品经理

十二年前 Google 推出 Kubernetes 时，Pod 成为了云上默认的计算单元。这一设计假定了一条直截了当的生命周期：程序启动、绑定端口、对外服务流量，然后一直运行，直到你将其停止。

AI agent 的工作方式则有着根本性的不同。

运行在机器上的 AI agent 会执行不受信任的代码、命令和工具调用，因此必须与宿主机及其网络资源隔离。与此同时，这些 agent——无论它是交互式编码助手、SRE 故障排查器，还是多轮评估循环——都不是持续运行的。它们执行一步操作、调用一次语言模型，然后等待。在等待模型流式输出 token 或等待人工审查 pull request 的这段时间里，agent 大多数时候什么都不做。正如当年 Kubernetes 为满足容器化应用的需求而生，我们推出了 Agent Substrate，作为面向新兴 agentic 应用的新型编排器。它默认安全、高度高效，并为数百万 agent 的规模而构建。

Agent Substrate 从设计之初就围绕 AI agent 的安全性与密度展开，它将 Kubernetes 最优秀的部分与一套全新的控制面和数据面结合在一起，提供完全隔离、超低延迟的沙箱化计算与存储。不断壮大的 Agent Substrate 社区一直在快速构建核心能力并稳定 API，最终促成了最新的 1.0 版本发布。

本周在盐湖城举行的 KubeCon North America 上，Google Cloud 将以 Sandbox 状态把 Agent Substrate 和 gVisor 捐赠给云原生计算基金会（CNCF），一同捐赠的还有 OpenRL。

本文解释了传统方案为何难以应对有状态 agent、Agent Substrate 如何解决这一问题、它如何与 Google Kubernetes Engine（GKE）上的企业治理衔接，以及在 KubeCon NA 2026 上何处可以看到它的实际演示。

AI agent 带来了两个标准 Kubernetes 从未设计处理的基础设施瓶颈：空闲资源浪费和控制面过载。

在一次典型的交互式会话中，agent 可能有 90% 到 95% 的时间都在等待模型推理、外部 API 或人工审查。

在这段等待时间里，agent 不消耗任何 CPU。但你又不能简单地把容器杀掉。agent 在内存和磁盘中持有大量关键状态：活跃的语言运行时、本地 Git 仓库、尚未提交的文件改动以及工具会话。

使用标准 Kubernetes，平台工程师面临两个都不理想的选项：

平台团队需要的是能在 500 毫秒以内唤醒、且内存和磁盘状态完整无损的 agent——同时不必在 agent 空闲时为运行中的 Pod 付费。

相反的问题出现在训练或评估 agent 时。强化学习循环和基准测试套件需要在同一时刻跨数千个任务运行不受信任的 agent 代码。

如果每个沙箱都需要一个完整的 Kubernetes Pod，控制面很快就会不堪重负。每分钟调度、创建和销毁数千个短生命周期 Pod，会让 etcd 过载、使 kube-apiserver 饱和，并耗尽子网 IP 地址。Kubernetes 是为管理稳定的应用拓扑而构建的，并不是作为微秒级沙箱分配器来使用的。

Agent Substrate 在 Kubernetes 之上增加了一套基于 actor 的控制面和数据面。它通过将 Actor 与 Worker 解耦，解决了空闲资源的问题：