500毫秒唤醒、密度10倍，谷歌把Agent运行时捐给了CNCF

谷歌把自家跑AI智能体的底座交了出去。2026年11月6日，Agent Substrate、gVisor和OpenRL三个项目一起进入CNCF沙箱阶段，同一天Agent Substrate 1.0作为谷歌Kubernetes引擎（GKE）上的托管能力正式可用。

先看这套东西到底在解决什么。一个智能体的工作方式是循环：提出动作、跑代码或调工具、读结果，然后等——等模型推理，或者等人回话。谷歌在博客里把"等"摆到了设计问题的正中央。

标准Kubernetes Pod在这段等待里一直占着内存和CPU，什么也没干；控制面还得为舰队里每个智能体维护一个持久对象；身份又绑在一个可能早就没用的Pod上。浪费是三重叠加的。

会话被拆成两半

Agent Substrate的做法是把会话里有状态的部分和跑它的算力分开。Actor承载内存、文件和一份独立身份；Worker是从预热池里取出来的可复用沙箱。网关架在沙箱两侧，执行访问规则、注入凭证，密钥始终不进智能体的运行环境。

智能体一暂停，运行时就把它的内存和文件写进存储，Worker还给池子。请求回来时，调用先到atenet-router代理，代理发现目标Actor处于挂起状态，就把请求留在内存里并通知Substrate控制器；控制器把Actor分配到预热池的空位，状态从分层存储重新加载，进程醒来，代理把请求递进去。

谷歌给出的数字是：恢复时间低于500毫秒，每秒超过500次挂起与恢复激活，每秒数千个智能体被唤醒，全程不创建Pod对象、不压etcd。密度方面，谷歌称是标准容器运行时的10倍。项目自2026年5月开放开发以来，贡献者已超过100人。

身份模型是平台团队最先会碰到的部分。GKE文档写明，Substrate为每个Actor签发唯一的SPIFFE X.509证书和JSON Web Token，让每个会话有可归因的独立身份。出站请求命中规则时，网关验证Actor的mTLS隧道，把占位请求头替换成取回的密钥或Actor的令牌。

gVisor等了很多年的中立东家

隔离边界上，Substrate支持gVisor和Cloud Hypervisor微虚拟机两种。gVisor是用Go写的轻量应用内核，2018年开源，夹在容器和宿主操作系统之间，在用户态处理应用系统调用，让生成的代码不直接和宿主内核对话。谷歌称它每天在GKE Sandbox和Cloud Run底下跑数百万个沙箱。

捐赠之所以关键，在于它改变了内核补丁的上游路径。谷歌的博客写明：包括谷歌在内的沙箱基础设施厂商，都背着一些宿主内核补丁，这些补丁把gVisor的I/O性能拉到接近原生Linux的水平；而在项目由单一厂商拥有的时期，上游Linux维护者拒绝合并这些补丁。中立治理打开了这条路。蚂蚁集团、Modal和Tines已承诺加入gVisor维护者行列，OpenAI、腾讯和英伟达继续贡献。

对采购方来说这是个信号：一项决定什么能合进Linux内核的治理变化，带着性能后果和一个日期，证据就在维护者名单里。这个季度选隔离边界的团队得清楚，gVisor的I/O优势今天依赖树外补丁，而上游工作刚刚才变得可能。

训练和推理挤同一批芯片

OpenRL是三个项目里最年轻的，今年2月还是研究预览，现在早早进了CNCF。它的论点是：生产环境里跑智能体的沙箱，和用强化学习训练一个智能体所需的环境是同一个——数百万次多轮rollout在真实工具里跑、被打分、再折回权重。

它对外暴露四个原语：sample、forward_backward、optim_step和save_state，接口兼容Tinker，权重和数据留在运营方自己的集群上。它用Kubernetes动态资源分配切分加速器池，通过PyTorch和AutoModel训练、vLLM采样，开箱验证了Gemma和Qwen。它和已达1.0的分布式推理项目llm-d配合，把rollout按前缀路由到已持有匹配KV缓存的采样器，并在采样和训练之间对同一批GPU做时间切片。

时间切片攻击的浪费和快照空闲智能体是同一类：一套硬件闲置时另一阶段在跑，两个项目都在回收这段闲置时间，不买新卡就换回容量。

上线前要过的几道关

GKE上的托管能力有明确约束：Standard集群，控制面和节点池都要1.37或更高版本，x86 CPU工作节点。Autopilot被排除在外，因为节点代理atelet以特权DaemonSet运行；微虚拟机池需要嵌套虚拟化或裸金属。吃加速器的智能体负载走基于Pod的Agent Sandbox路径，GPU和TPU在gVisor下受支持。

恢复数字也带条件。硬件、沙箱运行时和容器镜像不变时，内存、根文件系统和卷在1秒内回来；节点硬件或运行时一变，只恢复根文件系统和卷并重启进程；Actor挂起期间更新镜像，卷会恢复到用新镜像启动的容器里。恢复延迟还随快照大小增长，所以文档建议把大工作区放到外部Filestore卷上，把数据挪出快照。

运营方仍然握着三样东西：

• 出站策略。Substrate默认封掉全部出站流量，包括到其他Actor、到Kubernetes控制面、到Compute Engine元数据服务器和到互联网的流量，也封非DNS的UDP、裸TCP连接和HTTP WebSocket升级。规则写在EgressPolicy资源里，只接受完整域名或通配主机名，不收IP地址和CIDR段。要按地址访问内部服务的舰队，得先给它安个名字。
• 容量。预热池同时决定唤醒延迟和闲置开销，10倍密度是拿Substrate和"每个智能体一个Pod"的容器运行时比的。为几百个并发会话配池子的团队，最好先在1.37的Standard集群上量出自己的比例，再对内引用谷歌那个数。
• 治理。三个项目刚进基金会的入门阶段，gVisor在通往孵化阶段的路上，智能体运行时、沙箱内核和训练回路的设计会在公开的维护者论坛里定下来。

对在自己Kubernetes资产上跑智能体负载的团队，可迁移的设计就是那个拆分本身：有状态的会话身份放一层，一次性算力放另一层，凭证由网关把关。