谷歌捐出 Agent Substrate 与 gVisor：智能体沙箱 500 毫秒唤醒，闲置不再烧钱

原文信息：本文译自 Google 开源博客《Sandboxing Untrusted AI Agents at Scale: Google Donates Agent Substrate and gVisor to the CNCF》，作者 Mofi Rahman（开发者关系工程师）、Brandon Royal（产品经理，Google Cloud），发布于 2026 年 11 月 5 日。原文链接：https://opensource.googleblog.com/2026/11/sandboxing-untrusted-ai-agents-at-scale.html 。原文未注明许可信息。本文为翻译，译者在文末补充了译者注；原文配图请见原文链接。

译者导语：昨天那篇讲的是推理引擎怎么更快启动，今天这篇讲的是跑在 Kubernetes 上的智能体怎么既安全又省钱地“活着”。两者其实是同一件事的两面：AI 工作负载正在改写 Kubernetes 的使用方式——Pod 那套“启动、监听端口、一直跑到你叫停”的老假设，对动不动就要等模型、等接口、等人工确认的智能体已经不适用了。谷歌这次把 Agent Substrate、gVisor 和 OpenRL 一起捐给 CNCF，等于把这套智能体基础设施的底座交给了中立社区，值得跑 Kubernetes 的团队认真读一读。

Pod 的老假设，碰上了智能体的新活法

谷歌十二年前推出 Kubernetes 时，Pod 成了云上默认的计算单元。它背后的假设很直接：程序启动、绑定端口、提供服务，一直跑到你叫停为止。

AI 智能体的工作方式完全不同。

一个在机器上跑的智能体要执行不可信的代码、命令和工具调用，必须跟宿主机和网络资源隔离开。同时，无论是交互式编程助手、排障助手，还是多轮评测循环，智能体都不是连续运行的：它执行一步、调用一次语言模型，然后就等着。大部分时间里，智能体什么都不干，只是在等模型吐 token，或者等人工来审一条 PR。正如 Kubernetes 当年是为容器化应用而生的，谷歌推出 Agent Substrate，是为正在兴起的智能体应用打造的新一代编排器：默认安全、高效、面向百万级智能体规模。

Agent Substrate 从一开始就是为 AI 智能体的安全和密度设计的，它把 Kubernetes 最精华的部分和一套全新的控制面、数据面结合起来，提供完全隔离、低延迟的沙箱化计算与存储。社区围绕 Agent Substrate 的建设进展很快，核心能力不断成型、API 逐步稳定，最终推出了 1.0 版本。

本周，在盐湖城举行的 KubeCon North America 大会上，Google Cloud 把 Agent Substrate 和 gVisor 捐给云原生计算基金会（CNCF），进入 Sandbox（沙箱）阶段，同批捐赠的还有 OpenRL。

这篇文章要讲清楚：传统做法为什么搞不定有状态的智能体，Agent Substrate 是怎么解决的，它如何接入 Google Kubernetes Engine（GKE）上的企业治理，以及在 KubeCon NA 2026 上哪里能看到它的实际演示。

大规模跑智能体，卡在哪两处

AI 智能体给基础设施带来两个瓶颈，都是标准 Kubernetes 当初没考虑过的：闲置资源浪费和控制面过载。

（原文配图：标准 Kubernetes 专属 Pod 与 Agent Substrate 有状态 Actor 运行时的对比图，分层存储，见原文链接）

第一道坎：闲置资源

一次典型的交互会话里，智能体有 90% 到 95% 的时间都在等模型推理、外部接口或人工审核。等待期间它几乎不消耗 CPU。但你不能直接把容器杀掉——智能体在内存和磁盘里攥着关键状态：正在跑的语言运行时、本地 Git 仓库、还没提交的文件修改、工具会话。

用标准 Kubernetes，平台工程师只剩下两个都不理想的选择：

1. 让一个专属 Pod 全天开着：智能体随叫随到，因为它本来就是热的；但闲置算力的账要 24 小时照付。一万个活跃用户，集群成本就扛不住了。
2. 用 Serverless 容器缩容到零：智能体闲着的时候不花算力的钱，但从冷存储恢复时，要重新克隆仓库、重装依赖、重建内存，唤醒延迟超过 20 秒，交互体验直接垮掉。

平台团队真正想要的，是智能体能在 500 毫秒以内醒来、内存和磁盘状态完好无损，同时闲置时不用为跑着的 Pod 付钱。

第二道坎：控制面过载

反过来的问题出现在训练和评测智能体的时候。强化学习循环和基准测试套件需要在同一时刻、成千上万个任务上跑不可信的智能体代码。

如果每个沙箱都要一个完整的 Kubernetes Pod，控制面很快就会被拖垮：每分钟调度、创建、销毁成千上万个短命 Pod，会压垮 etcd、打满 kube-apiserver、耗尽子网 IP 地址。Kubernetes 是为管理稳定的应用拓扑设计的，不是为当微秒级沙箱分配器设计的。

Agent Substrate 是怎么解的

Agent Substrate 在 Kubernetes 之上加了一个基于 Actor（行动者）的控制面和数据面。它解决闲置资源问题的办法，是把 Actor 和 Worker 解耦：

• Actor 负责持有状态：一个 Actor 就是一次独立的智能体会话，自带文件系统、环境变量、内存状态和网络规则。
• Worker 负责提供算力：Worker 是共享池（WorkerPool）里预热好的 Kubernetes Pod，配有容器运行时和沙箱边界。

（原文配图：Agent Substrate 架构图，请求经 atenet-router 路由、ateapi 控制器放置 Actor、分层存储与共享 Worker 池，见原文链接）

一次智能体轮次的生命周期

1. 请求暂存：来电先到 atenet-router 这个七层代理手里。如果目标 Actor 正处在挂起状态，代理把请求暂存在内存里，同时通知 Substrate 控制器。
2. 快速放置：控制器把 Actor 分配到热 Worker 池里的一个空闲槽位。
3. 亚秒级恢复：Actor 的内存和磁盘状态从分层存储恢复，进程醒来，代理把请求递过去。智能体在 500 毫秒以内、从暂停的地方原地继续。
4. 闲置即挂起：一轮结束，Substrate 把 Actor 的状态快照到分层存储，Worker 槽位腾出来给别的工作负载。

因为 Substrate 直接管理 Actor 的状态，成千上万个智能体每秒钟都能激活、挂起、恢复，而不用新建 Pod 对象，也不会给 etcd 增加压力。

用 gVisor 和微虚拟机保障安全执行

智能体经常要执行模型生成的、不可信的代码。标准 Linux 容器与宿主机共享内核，在多租户节点上，这个风险不可接受。

Agent Substrate 搭配 gVisor（runsc）——谷歌用 Go 写的开源应用内核。gVisor 在用户态拦截系统调用，把不可信代码和宿主机内核隔离开。因为 gVisor 自己虚拟化了内存和进程表，Substrate 可以冻结一个正在运行的环境，把内存页写进存储，再在另一台节点上、500 毫秒以内恢复出来。

对于需要硬件虚拟化或自定义内核模块的工作负载，Substrate 在同一套统一 API 之下也支持 Cloud Hypervisor 微虚拟机。

为什么要捐给 CNCF

过去两年，整个行业的工程团队都撞上了同样的智能体扩展边界。没有共享的开放标准，每个组织最后都得自己在虚拟机上搭定制调度器，或者绕着 Kubernetes 打补丁。

把 Agent Substrate 和 gVisor 捐给 CNCF，是给云原生社区一个中立的、与厂商无关的底座，可以跑在任何兼容的 Kubernetes 集群上。

它们和社区项目合起来，构成智能体基础设施的开放技术栈：

• 第一层：安全隔离（gVisor）：用用户态内核隔离和快速内存检查点，把不可信代码的执行关进沙箱。
• 第二层：智能体运行时（Agent Substrate）：把有状态的 Actor 复用到热 Worker 池上，亚秒级唤醒。
• 第三层：训练编排（OpenRL）：协调 Kubernetes 原生的强化学习循环和评测沙箱。

在 KubeCon NA 2026 上哪里能看到它

KubeCon + CloudNativeCon North America 2026 于 11 月 9 日至 12 日在盐湖城举行，相关活动包括：11 月 9 日星期一的 Agent Substrate Day（ATEcon）、Agentics Day 上“加固 Kubernetes 运行时”专场和 GKE Day；11 月 10 日星期二的旗舰炉边谈话“Kubernetes 第二幕：AI 智能体如何改变底层逻辑”；11 月 11 日星期三的“在 GKE 上构建与治理 Agent Substrate”上手工作坊；11 月 10 日至 12 日，122 号 Google Cloud 展位有智能体集群演示、NVIDIA 合作演示和 Filestore 智能体卷演示。

上手试用

Agent Substrate 已经开源，可以直接试用：

• 文档：指南与架构说明见 ate.dev，见原文链接。
• 代码：运行时代码在 GitHub 的 agent-substrate/substrate 仓库，见原文链接。
• 社区：加入 CNCF Slack 上的 #substrate-dev、#substrate-user 频道，见原文链接。

盐湖城见！

译者注

1. 和昨天那篇是同一条技术线：昨天那篇讲推理引擎启动加速，提到了 Kubernetes 的容器检查点（KEP-2008）、Pod 级检查点恢复（KEP-5823）和 CRI 的 CheckpointPod/RestorePod 接口；今天这篇的 gVisor 检查点、快照恢复走的是同一条路，只不过落点从“推理引擎”换成了“智能体沙箱”。两篇合起来看，能看到一个清晰的趋势：检查点与恢复正在从实验功能变成 AI 工作负载的标准基础设施。
2. 落地前先分清成熟度：500 毫秒唤醒、百万级沙箱是谷歌对 1.0 版本的宣称，Agent Substrate 刚进 CNCF Sandbox，API 和生态都还在稳定过程中；gVisor 则是 2018 年就开源的老项目，早已跑在 GKE Sandbox 和 Cloud Run 下面，成熟度要高得多。想跟进的话，建议先在非生产环境小范围试点，别直接把生产智能体押上去。
3. 和华为云的结合点：在华为云 CCE 上跑编码助手、智能体这类负载时，同样会遇到闲置 Pod 的成本问题和多租户隔离问题。Agent Substrate“状态与算力分离、闲置快照、亚秒唤醒”的思路，对应到平台侧就是安全容器、检查点恢复和热实例池能力；gVisor 的用户态内核隔离思路也值得对照 CCE 的安全容器方案来跟踪。

相关阅读（同方向旧文，纯文本链接）： - OpenTelemetry 版本策略调整：补丁版本也能发安全修复，升级前要查什么：https://bbs.huaweicloud.cn/blogs/f237a6c452924797bb2a3555c4c00e58 - OpenTelemetry eBPF 插桩 OBI 1.0 发布：零代码采集指标与 Trace，配置和部署接口有了兼容承诺：https://bbs.huaweicloud.cn/blogs/cee4b9102b0a4f5285cdb1dc71aedf59

原文：Sandboxing Untrusted AI Agents at Scale: Google Donates Agent Substrate and gVisor to the CNCF，Mofi Rahman、Brandon Royal（Google Cloud），Google 开源博客，2026-11-05。原文链接：https://opensource.googleblog.com/2026/11/sandboxing-untrusted-ai-agents-at-scale.html