谷歌：为自主智能体打造开放基础设施

10 个关键问题 Q&A

1. Q：谷歌本次向 CNCF 捐赠哪三个项目？ A：Agent Substrate（ate.dev）、gVisor、OpenRL，三者均入选 CNCF 沙箱。
2. Q：Agent Substrate 1.0 核心价值是什么？ A：解耦智能体状态与计算资源，空闲智能体快照休眠，恢复低于 500ms，提升资源密度至普通容器 10 倍。
3. Q：Agent Substrate 里 Actor、Worker、Gateway 分别承担什么？ A：Actor 保存智能体记忆、身份；Worker 是可复用执行沙箱；Gateway 管控访问、注入密钥。
4. Q：gVisor 用来解决什么痛点？ A：安全隔离智能体自动生成、未经审核的不可信代码，规避共享宿主机内核带来的风险。
5. Q：gVisor 和普通虚拟机相比优势在哪？ A：无需嵌套虚拟化，内存弹性伸缩，保持容器密度，原生支持 GPU、TPU 和快照恢复。
6. Q：OpenRL 定位是什么？ A：基于 K8s 的自托管强化学习后训练框架，提供简洁 Python 原语，支持 LoRA 与全参数微调。
7. Q：OpenRL 为什么要和 llm-d 搭配使用？ A：llm-d 提供 KV 缓存前缀路由、GPU 分时复用，让采样与训练轮询共享加速卡，减少闲置。
8. Q：这套智能体基础设施可以跑在哪些环境？ A：任意 Kubernetes 集群、任意云，支持 CPU、GPU、TPU，兼容标准 OCI 容器。
9. Q：gVisor 归入 CNCF 最重要的长期收益是什么？ A：在中立治理下推进 IO 性能相关内核补丁合入 Linux 主线，所有用户开箱获得接近原生性能。
10. Q：谷歌推动这套栈进入 CNCF 的底层目标？ A：打造厂商中立的开放底座，联合硬件、云、AI 社区共建，复刻 Kubernetes 带动容器生态的效果，规模化支撑自主智能体负载。

作者：德鲁・布拉德斯托克（Drew Bradstock）谷歌云编排与 Kubernetes 产品线副总裁

2026 年 11 月 6 日

Agent Substrate、gVisor、OpenRL 三个项目正式入选 CNCF 沙箱；Agent Substrate 1.0 版本发布，并在 GKE 上正式商用

AI 正在从人机协作规模走向智能体规模，从记录型系统转向行动型系统，从简单指令升级为复杂的智能体工作流，平台底层承载的工作负载也随之彻底改变。智能体运行在持续、有状态的循环链路中：提出行动方案、生成子智能体、在沙箱内执行代码或调用工具，再将结果回传给大模型，开启下一轮交互。要规模化运行这套链路，就需要一套开放底座与中立治理机制 —— 正如 2010 年代 Kubernetes 与云原生计算基金会（CNCF）为容器带来的变革。

今天，我们宣布将三个源自谷歌的开源项目：ate.dev（Agent Substrate）、gvisor.dev、openrl.dev 捐赠给 CNCF，这三个项目已于上月获批加入 CNCF 沙箱。为了让这套开放技术栈落地托管生产环境，并在 TPU、GPU 上加速落地，我们同步发布消息：Agent Substrate 迎来 1.0 里程碑，现已在 GKE（谷歌 Kubernetes 引擎）正式商用。

目前三个项目正在 CNCF 沙箱内完成社区接入，由社区维护者负责独立构建流水线；其中 gVisor 已经朝着孵化级项目推进。这套方案可部署在任意 Kubernetes 集群、任意云平台，兼容 CPU、GPU、TPU，核心能力如下：

• Agent Substrate（ate.dev，现已 1.0、GKE 商用）：规模化部署隔离智能体环境，消除闲置算力开销。智能体执行代码或测试仅需数秒，之后会等待模型推理结果、外部 API 返回或者人工输入。如果全程保留容器运行，会持续占用内存与算力。Agent Substrate 将有状态智能体会话、身份与活跃计算资源解耦，把空闲智能体快照持久化存储，恢复耗时低于 500 毫秒，可支撑数百万沙箱实例，容器部署密度提升 10 倍。
• gVisor（gvisor.dev）：在沙箱中隔离不可信代码。智能体经常自动生成并运行未经审核的代码、第三方包，而标准容器共享宿主机 Linux 内核，存在安全风险。gVisor 是轻量用户态应用内核，在普通 Linux 节点上实现容器级部署密度，隔离生成代码。
• OpenRL（openrl.dev）：高效分布式后训练与推理。基于强化学习训练智能体时，开发者可以在数百万并行沙箱交互样本中迭代优化。OpenRL 依托 Kubernetes，用原生 Python 编排自托管强化学习后训练流程。

借助 Substrate 规模化部署全隔离智能体环境

智能体需要独立计算资源、严格访问边界，但大部分时间都处于等待状态：代码执行仅几秒，随后暂停，等待模型推理或人工反馈。同时智能体需要独立身份标识、统一管控点，保证只能访问授权工具与服务，且敏感密钥不能暴露在运行环境中。

在原生 Kubernetes 中，为每一个活跃智能体单独分配 Pod，会导致智能体空闲时持续占用内存、CPU；控制平面需要维护海量长期对象，这并非它的设计目标；并且身份标识直接绑定 Pod，权限与密钥管控的复杂度呈指数级上升。

Agent Substrate 的核心思路：把有状态智能体和底层计算资源解耦

• Actor（实例主体）：保存智能体的记忆、文件、独立身份；
• Worker（执行工作单元）：从预热 Kubernetes 资源池中取用的可复用沙箱；
• Gateway（网关）：基于 Actor 身份管控进出流量、注入密钥，敏感密钥不会进入智能体运行环境。

当智能体暂停，等待模型输出或者工具返回结果时，Agent Substrate 会把智能体内存、文件快照存入存储，Worker 立刻归还到预热资源池。收到下一条请求时，系统在500 毫秒内把 Actor 恢复到任意可用 Worker 上，继续执行任务。可以理解为酒店客房，而不是自有住房：不用的时候不占用房间，下次回来可以快速分配一间可用客房。

Agent Substrate 将有状态 Actor、策略网关，和 Kubernetes 预热 Worker 池解耦，空闲会话恢复速度低于 500 毫秒。

该项目自 2026 年 5 月对外开源以来，贡献者已经超过 100 人。早期合作客户已经落地，同时它也支撑 kagent.dev 等其他 CNCF 项目。

1.0 版本的发布，标志 Agent Substrate 可以承载百万级沙箱生产负载，部署密度达到标准容器运行时的 10 倍，每秒支持 500 次以上的挂起 / 恢复操作。

底层可选用 Cloud Hypervisor 微虚拟机或者 gVisor 作为隔离边界，无需修改智能体生命周期管理逻辑。由于兼容标准 OCI 容器，它开箱支持 Agent Development Kit（ADK）开发的智能体、有状态代码环境、生产力智能体。

本次在 GKE 正式商用后，你既可以在谷歌云以托管能力运行这套运行时，也可以把开源代码部署在任意 Kubernetes 集群。如果团队希望通过 API 直接使用微虚拟机计算服务、免去集群运维，Agent Substrate 可以搭配 Agent Compute Engine 使用：这是谷歌基于 Titanium 芯片的微虚拟机服务，支持快速休眠、并行环境克隆，适配评估和强化学习流水线。

SPIRITT 公司正在 GKE 上基于 Agent Substrate 搭建 SPIRITT 工作空间平台：智能体自主完成实际工作，人类协同把控方向。
“在 SPIRITT，每位客户都拥有一套自主 AI 工作空间，单个或集群智能体在企业内独立搭建、运行、交付各类工作，覆盖开发、营销、运维全链路。GKE 上的 Agent Substrate 既提供安全隔离，让智能体安全执行代码，又支持自定义运行时扩展，还能以极高密度低成本承载海量客户智能体。”
——SPIRITT 首席执行官 Tamir Magen

使用 gVisor 隔离智能体生成的不可信代码

当智能体从记录系统进化为行动系统，会自动执行生成的 Shell 命令、未审核软件包。标准容器和节点上其他负载共享宿主机 Linux 内核，运行不可信代码风险很高。硬件微虚拟机隔离能力强，Agent Substrate 原生支持；但很多团队需要强隔离能力，同时保持容器密度，并且可以跑在普通 Linux 实例上 —— 不依赖裸金属、嵌套虚拟化。

gVisor 由 Go 语言编写，是轻量应用内核，正好满足这个需求。它运行在容器和宿主机操作系统之间，在用户态拦截、处理应用系统调用，不可信代码无法直接访问宿主机内核。gVisor 于 2018 年由谷歌开源，如今在 GKE 沙箱、Cloud Run 下每天支撑数百万沙箱实例。除谷歌以外，Anthropic、OpenAI 都用它隔离代码执行；Modal、Snowflake 基于它搭建执行沙箱；蚂蚁、腾讯也大规模在生产环境落地。

三大特性让 gVisor 非常适合大规模智能体集群：

1. 容器密度与弹性内存：不像虚拟机预先分配固定内存，gVisor 保留容器进程模型，内存随负载动态伸缩，单节点可以部署更多智能体，降低单智能体成本；
2. 原生支持 GPU、TPU 与快照：原生支持 GPU、TPU 直通以及快照 / 恢复能力，智能体可以在沙箱内访问加速卡，空闲时挂起；
3. Linux 全平台兼容：不需要嵌套虚拟化，在任意云、本地 Linux 节点上部署方式一致。例如 Northflank 在无法开启嵌套虚拟化的环境下，依靠 gVisor 搭建 GPU 沙箱。

把 gVisor 捐赠给 CNCF，扫清了社区长期面临的性能瓶颈。包括谷歌在内的沙箱基础设施厂商，都维护了宿主机内核补丁，让 gVisor IO 性能接近原生 Linux；但在项目归属单一厂商时，上游 Linux 主线拒绝合入这些补丁。转入 CNCF 中立治理后，这些内核优化有机会合入上游，所有开发者都能开箱即用获得接近原生的性能。OpenAI、腾讯、NVIDIA 也会持续贡献代码。

在 Kubernetes 上借助 OpenRL 规模化开展强化学习后训练

智能体生产环境所用沙箱，和强化学习训练智能体所需环境完全一致。当前前沿模型能力提升大多来自强化学习后训练：在真实工具环境中跑上百万轮多轮交互样本，评估结果，更新模型权重。自研这套链路通常需要魔改单体强化学习框架，在调试分布式权重传输上耗费大量精力，迟迟无法聚焦训练算法本身。

OpenRL 为 Kubernetes 集群提供简洁、可自托管的 Python 后训练链路：

• 极简 Python 原语：基于兼容 Tinker 的 API，只用四个基础原语（sample 采样、forward_backward 前向反向、optim_step 优化步、save_state 保存状态）编写训练循环，权重、数据保存在自有集群；现有 tinker-cookbook 样例无需改动，支持 LoRA 适配器与全参数微调；
• 可插拔引擎 + Kubernetes 调度：依托 Kubernetes 动态资源分配（DRA）切分加速卡资源，在共享卡池上调度强化学习任务；架构可插拔，原生支持 PyTorch/AutoModel 训练、vLLM 采样，Gemma、Qwen 模型开箱验证，TPU 支持在规划路线中。

OpenRL 还可以和 llm-d（CNCF 分布式推理与强化学习项目，由红帽、谷歌云、IBM 研究院、CoreWeave、NVIDIA 联合发起）搭配使用，充分利用加速卡资源，覆盖强化学习两大阶段：

• 前缀感知样本路由：路由组件把多轮交互样本分发到已经缓存对应 KV 缓存前缀的采样器，减少重复预填充计算；
• 训练 / 采样 GPU 分时复用：强化学习流程里，采样进程和训练进程交替运行，总有一部分加速卡闲置。OpenRL 搭配 llm-d 的强化学习分时组件，同一块 GPU 交替承载采样、训练任务，盘活闲置算力，如同 Agent Substrate 回收闲置 CPU 与内存。

OpenRL 在 Kubernetes 上运行原生 Python 强化学习循环，样本交互跑在 Agent Substrate 沙箱中，llm-d 负责样本路由与加速卡分时调度。

OpenRL 是这套技术栈里最年轻的项目，今年 2 月才发布技术预览版。我们选择在早期就把它交给 CNCF，目标愿景是：一套训练方案，适配任意模型、任意加速硬件，这无法由单一公司独立完成。需要加速卡厂商（NVIDIA、AMD、Intel、TPU）、推理引擎团队（llm-d、vLLM、SGLang）、训练框架、开源模型社区（Gemma、Qwen）共同参与。在架构定型前就采用 CNCF 中立治理，给各方留出协同共建的空间。

为什么选择 CNCF？为什么是现在？

智能体的安全与效率提升，需要运行时、调度器、编译器、芯片协同设计。过去一年，行业对低成本隔离沙箱、开放后训练基础设施的需求已经非常明确。将 Agent Substrate、gVisor、OpenRL 捐赠 CNCF，再次印证谷歌拥抱开放协作、联合投入的路线。中立归属意味着云厂商、硬件厂商、独立软件企业可以平等参与智能体负载生态的建设。

我们相信，这批项目将像当年 Kubernetes 推动容器生态一样，加速智能体工作负载的落地与普及。

快速上手入口：

• 查看 CNCF 沙箱申请：gVisor、Agent Substrate、OpenRL，同期入组项目还有 KubeRay
• 项目主页：ate.dev、gvisor.dev、openrl.dev
• GKE 部署文档：Agent Substrate 介绍、沙箱 Pod 概念
• 深度技术博客：Agent Substrate GKE 详解、gVisor 加入 CNCF 公告、OpenRL 开源介绍

发布板块：容器与 Kubernetes 专栏

术语对照表

• Autonomous agents：自主智能体
• Agent Substrate：智能体底座（ate.dev）
• Sandbox：沙箱
• CNCF Sandbox：CNCF 沙箱项目阶段
• GKE：Google Kubernetes Engine，谷歌 Kubernetes 引擎
• gVisor：用户态内核隔离运行时
• OpenRL：开源强化学习后训练框架
• Actor：智能体实例主体
• Worker：执行工作单元
• Gateway：访问网关
• OCI：开放容器标准
• LoRA：低秩适配微调
• DRA：Dynamic Resource Allocation，K8s 动态资源分配
• KV cache：键值缓存（大模型推理）
• Rollout：交互样本 / 推演回合（RL）
• Tinker：OpenRL 配套 API 规范
• llm-d：分布式推理 & RL 开源项目