谷歌云将隔离 AI 智能体执行的 gVisor，以及通过保留状态唤醒智能体的 Agent Substrate，捐赠给云原生计算基金会（CNCF）。两项技术进入 CNCF 的 Sandbox 阶段，使用 Kubernetes 的开发团队可以试用这一开放基础，在隔离不可信代码的同时保留空闲智能体的执行状态。

智能体在等待时也需要保留状态

智能体执行任务后，会等待模型推理、外部服务或人工审核。根据谷歌的公告，交互式会话中等待时间占总时长的 90~95%。此时即使不使用 CPU，执行代码的语言运行时、本地存储、正在编辑的文件和工具会话也必须保留在内存和磁盘中。

持续运行专用 Pod 可以即时响应，但在闲置时也会占用计算资源。反之，如果将无需直接管理服务器的无服务器容器缩减至 0 个，按谷歌的说明，恢复时需要克隆存储库并重新安装软件包，唤醒可能超过 20 秒。谷歌提出的目标是在保留内存和磁盘状态的同时，在不到 500 毫秒内恢复，并消除等待中的 Pod 成本。

训练和评估则有其他瓶颈。根据奖励改进行为的强化学习迭代，或比较性能的基准测试，可能在数千个任务中同时执行智能体代码。谷歌解释，为每个任务新建并删除 Kubernetes Pod，会在短时间内集中产生请求，加重存储集群配置的分布式存储 etcd 和 kube-apiserver 的负担，还可能耗尽划分 IP 地址范围的逻辑网络——子网中的 IP 地址。

分离状态与执行资源，实现复用

Agent Substrate 将持有智能体会话状态的 Actor 与执行任务计算的 Worker 分离。Actor 包含文件系统、环境变量、内存状态和网络规则，Worker 则从预先准备好的 Kubernetes Pod 共享池中提供执行资源。这样，智能体闲置时就能释放 Worker 槽位，供其他任务复用。

当请求到达已暂停的 Actor 时，代为转发请求的代理会将请求保存在内存中，并通知使实际状态符合期望状态的控制器。控制器分配空闲 Worker 槽位，在结合不同速度存储介质的分层存储中所保存的状态恢复后，转发请求。任务完成后，再次保存状态并归还槽位。谷歌表示，这种方式无需每次创建新的 Pod 对象，即可激活、暂停和恢复智能体。

这一设计旨在减少闲置 Pod 占用的计算资源，以及创建 Pod 给管理集群运作的控制平面带来的负担。不过，共享计算资源需要维护预热的 Worker 池，也需要空间来保存已暂停会话的状态。因此，成本和运维负担并非消失，而是从闲置执行转移到资源池规模和状态存储上。

gVisor 建立执行边界并协助恢复状态

智能体可以执行模型生成的代码，因此与宿主机的隔离十分重要。普通 Linux 容器共享宿主机内核。谷歌一同捐赠的 gVisor 是用 Go 编写的用户空间应用内核，它在内核之外、应用程序运行的用户空间中拦截请求操作系统功能的系统调用，将不可信代码与宿主机内核隔离。

gVisor 管理自身内存和记录运行程序信息的进程表，这一特性可用于暂停执行环境、保存内存页，然后在其他节点上恢复。根据谷歌公告，Agent Substrate 的状态恢复耗时不到 500 毫秒。谷歌表示，对于需要通过硬件创建虚拟计算机的硬件虚拟化，或向操作系统核心添加功能的自定义内核模块的任务，同一接口也支持基于 Cloud Hypervisor、体积小且启动快的微型虚拟机。

捐赠给 CNCF，让开放基础可供试用

谷歌云在举办 KubeCon North America 的盐湖城宣布，将 Agent Substrate 和 gVisor 捐赠至 CNCF Sandbox 阶段。公告也提到了 OpenRL，在谷歌提出的架构中，gVisor 负责隔离，Agent Substrate 负责智能体执行，OpenRL 负责协调训练与评估。Agent Substrate 已发布 1.0 版本，并提供试用代码和文档。

开发者可以在 ate.dev 查看指南和架构文档，并在 GitHub 的 agent-substrate/substrate 仓库查看代码。CNCF Slack 的 substrate-dev 和 substrate-user 频道也是参与社区的渠道。谷歌还介绍了 KubeCon 活动中的工作坊，用于试验 Worker 池部署和保存特定时刻状态的快照恢复，以及在 GKE 上通过资源池运行多个智能体的演示。

此次捐赠的核心，是将智能体状态保留与安全执行整合到开放的 Kubernetes 基础上，同时将运维重点转向预热资源和状态存储管理。