⛓️ 基础设施 · 架构深析
容器编排双雄共铸新基座，智能体运行时迎来第四种计算形态
谷歌于 2026 年 5 月推出 GKE Agent Sandbox 与 Agent Substrate，两项公告间接承认了一个 Kubernetes 资深人士一直不愿公开点明的事实：那个曾统治容器时代的平台并不适合作为 AI 智能体的控制平面。Agent Sandbox 为智能体提供了安全运行不可信代码的环境，Agent Substrate 则增加了一个绕过 Kubernetes 控制平面的调度层——因为 API 服务器的设计初衷从未考虑过智能体的行为模式。
综合公开信息整理•
2026-08-12•
全文约 4 分钟读完
#Agent Substrate
#Kubernetes
#智能体调度
#谷歌
#云原生
第四种
计算形态：继虚拟机、容器、无服务器之后
300个/秒
每个集群 Sandbox 分配速率
200ms
90% 的分配延迟在 200ms 内完成
- 核心矛盾：Kubernetes 为长期运行的复制服务设计，智能体却是大量休眠、短时爆发的有状态进程——两者根本性不匹配。
- 谷歌方案：Agent Sandbox 提供安全沙箱（gVisor 隔离），Agent Substrate 在 K8s 旁叠加专用调度层，实现 30 倍以上超配与亚秒级激活。
- 性能数据：预热池每秒分配 300 个 Sandbox，90% 在 200ms 内完成；空闲会话通过 Pod 快照挂起，数秒恢复。
- 框架无关：Substrate 支持 ADK、LangChain、Claude Code 等任意框架，已将隔离责任从容器边界转移到内核边界。
- 生态悬念：智能体控制平面能否像容器编排收敛到 K8s 一样走向统一，还是被超大规模云厂商各自为政地割裂？
01Kubernetes 的架构定位为什么错了？
如果将智能体比作操作系统中的进程，而不是数据中心里的服务，这种不匹配就显而易见了。现代操作系统运行着成千上万个进程，它们大部分时间都处于休眠状态。操作系统会在事件触发时唤醒它们，分配一小片 CPU 时间，然后将闲置的内存分页到磁盘。智能体的行为几乎与这些进程完全一致。
Kubernetes 最初是为了管理一组固定的、长期运行的复制服务而设计的。这种根本性的设计差异解释了为什么现在的智能体基础设施大多是在 Kubernetes 之上运行，而不是像 Deployment 或 StatefulSet 那样作为工作负载被集成到 Kubernetes 中。
Kubernetes 原生负载
固定数量的复制服务，持续运行，周期性健康检查，调度决策低频且持久。
智能体负载
大量有状态会话，长期休眠，短时爆发，调度事件高频且细粒度。
注：Kubernetes 的 API 服务器和调度器为管理数万个 Pod 而设计，而智能体场景可能涉及数百万个休眠会话，控制平面会在关键路径上成为瓶颈。
一个真实场景足以说明问题：试想一个开发者整个下午都保持打开状态的编程智能体。当提示词到达时，它运行 10 秒，然后等待 20 分钟，直到下一个提示词到达。将这个数字乘以团队中的开发者数量，你就有了成千上万个名义上“活跃”但实际在“沉睡”的会话。为每个空闲会话保留一个完整的 Pod 会浪费预留的内存和 CPU。
这就是新一代运行时将空闲会话的状态快照从计算资源中剥离的根本原因。
02智能体工作负载的三重本质
智能体是长期运行、有状态的会话，其生命周期的大部分时间处于空闲状态，被唤醒执行一阵代码后，再次归于沉寂。它执行的代码由大模型在运行时生成，运行宿主必须默认将其视为不可信的负载。每个会话都需要一个稳定的身份标识，能够在不丢失内存的情况下暂停和恢复，并且与其他会话实现硬性隔离。
🕰️ 沉睡数小时的会话
🧩 平台无法预定义的代码
💾 休眠期间必须持久留存的状态
这三个特征分别对应着 Kubernetes 架构的三个承压点：
调度策略轮询/随机放置不适应长请求、低频到达
API 服务器数百万对象超出设计规模
隔离边界容器边界不足以应对不可信代码
注：调度策略方面，K8s 集群常用的轮询在短请求且高到达率时效果不错，但智能体请求运行时间更长，糟糕的路由选择会持续存在，放大尾部延迟。
03Agent Sandbox：不可信代码的安全沙箱
Agent Sandbox 是一个基于 Kubernetes 构建的开源执行环境，为每个智能体提供了一个加固的空间来运行大模型生成的代码。在不到 5 个月的时间里，沙箱采用规模增长了约 16 倍，谷歌随后将其推向了全面可用阶段。
可以将其理解为隔离“监牢”而非普通容器。普通容器共享宿主机内核并信任工作负载会守规矩，而 Sandbox 假设工作负载具备攻击风险，并在其周围设置了安全边界。
预热池分配速率
300/s
每个集群，避免冷启动延迟
90% 分配延迟
≤200ms
预配置副本预热池保证
Sandbox 默认通过 gVisor 实现隔离边界，添加了默认拒绝的网络策略，并暴露了可插拔接口，团队可替换为 Kata Containers 实现完整内核隔离。LangChain 和 Lovable 等客户已经在上面运行了数百万个智能体。
🔒 三大核心设计 基线安全
- 预热池解决冷启动：为每个请求启动新 Sandbox 会增加数秒延迟，因此保持预配置副本预热池，保证 200ms 内完成分配。
- Pod 快照挂起空闲会话：空闲智能体通过 Pod 快照挂起，按需在数秒内恢复运行，释放底层计算资源。
- 默认内核隔离：gVisor 和网络访问限制属于出厂基线配置，假设任意智能体都可能运行它不应该运行的东西。
实践结论：安全性与性能被视作同一问题的两面，而非相互对立的目标。
04Agent Substrate：可支撑数百万闲置智能体的运行时
如果说 Agent Sandbox 是安全沙箱，那么 Agent Substrate 就是决定哪个智能体在哪里运行的运行时。它重用了 Agent Sandbox 的安全运行时和快照功能，并将它们与一个位于 Kubernetes 集群旁边的小型控制平面配对，将标准控制平面从关键路径上移除。
核心思路：将虚拟内存超分配机制运用到计算资源调度领域。操作系统允许程序寻址远超机器物理内存的内存，方法是将冷页分页到磁盘。Agent Substrate 对智能体会话采用同类思路，将大量有状态执行智能体的注册表复用到一小部分预热的工作 Pod 池上，并将空闲的会话快照进行持久化。
激活速度
亚秒级
工作 Pod 已在运行，无需等待 K8s 调度器
面向开发者的形态由两个自定义资源组成：定义就绪计算的 WorkerPool 和定义智能体的 ActorTemplate。Substrate 是框架无关的，可以将 ADK、LangChain、Claude Code 或任意 OCI 容器作为执行者运行。
Kubernetes（底层机器）
→
Agent Substrate（智能体调度层）
→
Agent Sandbox（安全沙箱）
通过 kagent（Solo.io 集成），Agent Substrate 可作为可选运行时，在统一 UI 上将类似 OpenClaw 的框架作为执行者调度到工作资源池中。架构决策在于哪一层负责哪项工作——绝大多数实际部署场景会将三者协同使用。
05对云原生生态意味着什么
运维过高负载集群的人都能轻易理解这个模式。智能体是进程，资源预热池对应一组 CPU 核心，空闲会话快照等同于内存页置换至磁盘，而资源超配背后的思路和虚拟内存机制一贯的设计逻辑如出一辙。Kubernetes 仍然是底层机器，调度智能体的层正在这个底层机器上被重建，以便更好地匹配智能体的实际运行方式。
一个诚实的注脚：
悬而未决的问题是谁会主导这一层。Agent Substrate 目前尚处于早期探索阶段，并非定型产品；kagent 也处于早期阶段。随着空闲智能体的成本成为平台团队无法忽视的开支项目，竞争对手的运行时也将陆续面世。
编辑核心判断
下一个十年，智能体基础设施层将围绕“会话即进程”这一核心抽象重新构建。开源社区与云厂商的博弈才刚刚开始——是像 K8s 一样收敛为单一标准，还是四分五裂各自为政，将直接影响智能体生态的演进成本。
▶现在就能用
Agent Sandbox 已全面可用，集成于 GKE；Agent Substrate 通过 kagent 可体验。开发者可访问 Google Cloud 控制台启用相关 API。
查看 GKE Agent Sandbox →