谷歌于2026年5月推出GKE Agent Sandbox和Agent Substrate项目，标志着Kubernetes在智能体控制方面的重大突破。

--91likeyou---

那个曾称霸容器时代的平台并不适合作为 AI 智能体的控制平面。Agent Sandbox 为智能体提供了一个运行不可信代码的安全环境。Agent Substrate 则增加了一个调度层，绕过了 Kubernetes 控制平面，因为 API 服务器的设计初衷从未考虑过智能体的行为模式。

如果将智能体比作操作系统中的进程，而不是数据中心里的服务，这种不匹配就显而易见了。现代操作系统运行着成千上万个进程，它们大部分时间都处于休眠状态。操作系统会在事件触发时唤醒它们，分配一小片 CPU 时间，然后将它们闲置的内存分页到磁盘，以便为下一个进程腾出空间。智能体的行为几乎与这些进程完全一致。Kubernetes 最初是为了管理一组固定的、长期运行的复制服务而设计的。这种根本性的设计差异解释了为什么现在的智能体基础设施大多是在 Kubernetes 之上运行，而不是像 Deployment 或 StatefulSet 那样作为工作负载被集成到 Kubernetes 中。

智能体作为工作负载的本质

智能体是长期运行、有状态的会话，其生命周期的大部分时间处于空闲状态，被唤醒执行一阵代码后，再次归于沉寂。它执行的代码是由大模型在运行时生成的。运行宿主必须默认将其视为不可信的负载。每个会话都需要一个稳定的身份标识，能够在不丢失内存的情况下暂停和恢复，并且与其他会话实现硬性隔离。

不妨把智能体想象成分时操作系统中的进程。就像调度器挂起一个休眠进程并在键盘输入到达时立即恢复它一样，智能体运行时环境也必须在会话空闲时将其休眠，并在恢复时保持其工作内存完好无损。唤醒链路直接决定用户等待时长，因此路径上的每一毫秒延迟都能被感知到。

试想一个开发者在一下午都保持打开状态的编程智能体。当提示词到达时，它运行 10 秒，然后等待 20 分钟，直到下一个提示词到达。将这个数字乘以团队中的开发者数量，你就有了成千上万个名义上“活跃”但实际在“沉睡”的会话。

超大规模云厂商已经在朝这个方向布局。这种具有会话感知能力、隔离的智能体运行时已成为继虚拟机、容器和无服务器计算之后的第四种计算形态。

沉睡数小时的会话

智能体会话的流量突发特性与 Web 服务截然不同。为每个空闲会话保留一个完整的 Pod 会浪费 Pod 预留的内存和 CPU，这就是为什么新一代运行时会将空闲会话的状态快照从计算资源中剥离。

平台无法预定义的代码

由于智能体执行的代码由大模型生成，运行时无法假定负载具备良性行为。它必须能够运行一个能够执行任何操作的进程，这将隔离责任从容器边界转移到了内核边界。

休眠期间必须持久留存的状态

如果一个智能体每次挂起时都丢失上下文，它将变得无法使用。因此，运行时必须在休眠期间保存其易失性 RAM 和文件系统状态，并在恢复时还原它们。

为什么 Kubernetes 控制平面的架构定位是错的

Kubernetes 通过中心化 API 服务器和为数量适中长时间运行的 Pod 而设计的调度器来调度作业。这种设计假设调度决策发生频次低且决策时持久的。智能体通过生成持续不断的细粒度调度事件打破了这一假设，使控制平面成为瓶颈而不是调度仲裁者。

调度策略最先面临压力。研究智能体调度的研究人员已经证明，Kubernetes 集群中常见的轮询和随机放置策略在请求短且到达率高时效果很好，因为错误的决策会被迅速摊销。智能体请求运行时间更长且到达频率更低，因此糟糕的路由选择会持续存在，放大被困在后面的用户的尾部延迟。

第二个承压点正是 API 服务器本身。将每个智能体（无论活跃还是空闲）都存储为 Kubernetes 对象，这意味着在一个从未为此规模设计的系统中会有数百万个资源实例。Agent Substrate 的架构文档对此直言不讳，承认没有巧妙的方法能让标准控制平面容纳这么多对象，因此运行时将大多数智能体排除在外。路由也采取了类似的绕行方式，使用专用的网络层将每个请求直接发送到正确的会话，如果处于休眠状态则将其唤醒。

Kubernetes 是一个优秀的数据中心调度器，在配置底层机器资源方面仍然很有用。但对于一大群休眠进程形态的负载而言，它并不是合适的调度器。

Agent Sandbox：不可信代码的安全沙箱

Agent Sandbox 用于解决隔离性问题。它是一个基于 Kubernetes 构建的开源执行环境，为每个智能体提供了一个加固的空间来运行大模型生成的代码。在不到 5 个月的时间里，沙箱采用规模增长了约 16 倍，谷歌随后将其推向了全面可用阶段。

可以将其理解为隔离“监牢”而非普通容器。普通容器共享宿主机内核并信任工作负载会守规矩，而 Sandbox 假设工作负载具备攻击风险，并在其周围设置了安全边界。Agent Sandbox 默认通过 gVisor 实现这一边界，添加了默认拒绝的网络策略，并暴露了一个可插拔接口，以便团队可以替换为 Kata Containers 来实现完整的内核隔离。

LangChain 和 Lovable 等客户已经在上面运行了数百万个智能体，这迫使团队进行性能优化。最终打造出的这套运行时将安全性与性能视作同一问题的两面，而非相互对立的目标。

解决冷启动问题的预热池

为每个请求启动一个新的 Sandbox 会增加数秒的延迟，因此 Agent Sandbox 保持了一个预配置的副本预热池。谷歌的报告显示，每个集群每秒可以分配 300 个 Sandbox，其中 90% 的分配在 200 毫秒内完成。

空闲会话的 Pod 快照

空闲智能体通过 Pod 快照挂起，可按需在数秒内恢复运行，这样可以释放底层计算资源，而不是付费让休眠会话常驻内存。

默认的内核隔离

这种隔离并非为极端安全需求额外附加的组件。gVisor 和网络访问限制属于出厂基线配置，假设任意智能体都可能运行它不应该运行的东西。

Agent Substrate：可支撑数百万闲置智能体的运行时

如果 Agent Sandbox 是安全沙箱，那么 Agent Substrate 就是决定哪个智能体在哪里运行的运行时。它重用了 Agent Sandbox 的安全运行时和快照功能，并将它们与一个位于 Kubernetes 集群旁边的小型控制平面配对，将标准控制平面从关键路径上移除。

这个方案的核心思路是将虚拟内存超分配机制运用到计算资源调度领域。操作系统允许程序寻址远超机器物理内存的内存，方法是将冷页分页到磁盘。Agent Substrate 对智能体会话采用同类思路，将大量有状态执行智能体的注册表复用到一小部分预热的工作 Pod 池上，并将空闲的会话快照进行持久化。该项目的数据显示，由于事件到达时工作 Pod 已经在运行且从不等待 Kubernetes 调度器，因此实现了 30 倍或更高的超额订阅率和亚秒级激活速度。

面向开发者的形态由两个自定义资源组成：定义就绪计算的 WorkerPool 和定义智能体的 ActorTemplate。Substrate 是框架无关的，可以将 ADK、LangChain、Claude Code 或任意 OCI 容器作为执行者运行，这使其能够托管完整的智能体框架而不仅仅是单个智能体。

位于 Kubernetes 旁边的控制平面，而非内部

Substrate 并非 Kubernetes 的替代品。它使用 Pod 和自动扩缩容完成资源配置，并在上层叠加自己的调度器，处理 Kubernetes 难以胜任的智能体调度决策。

通过 kagent 走向生产

Solo.io 已经将 Substrate 集成到 kagent 中，将 Agent Substrate 作为可选运行时，因此可以在统一的 UI 上将类似 OpenClaw 的框架作为执行者调度到工作资源池中。

选择智能体运行的位置

这两个项目不是竞争对手，也不会取代底层的集群。架构决策在于哪一层负责哪项工作，绝大多数实际部署场景会将三者协同使用。

在实践中，大多数团队不会只选择其中一个。一个大规模运行编程智能体的团队可能会沙盒化代码，通过 Substrate 进行调度，并让 Kubernetes 配置两者之下的节点。

这对云原生生态系统意味着什么

运维过高负载集群的人都能轻易理解这个模式。智能体是进程，资源预热池对应一组 CPU 核心，空闲会话快照等同于内存页置换至磁盘，而资源超配背后的思路和虚拟内存机制一贯的设计逻辑如出一辙。Kubernetes 仍然是底层机器，调度智能体的层正在这个底层机器上被重建，以便更好地匹配智能体的实际运行方式。

悬而未决的问题：谁会主导这一层？Agent Substrate 目前尚处于早期探索阶段，并非定型产品；kagent 也处于早期阶段，随着空闲智能体的成本成为平台团队无法忽视的开支项目，竞争对手的运行时也将陆续面世。接下来值得关注的是，这个智能体控制平面能否像当年容器编排赛道最终收敛到 Kubernetes 一样收敛成一个单一的开源项目。另一种可能性则是各大超大规模云厂商各自推出自研方案，智能体原本想要摆脱的生态割裂问题会向上转移到这一层基础设施再度出现。

：

🔥 热词：#google kubernetes engine · #谷歌容器技术 · #谷歌承认k8s太复杂了 · #谷歌okrs · #google开源的容器集群管理系统 · #google based if · #谷歌docker · #谷歌 contractor