2026 年 5 月，谷歌在 Cloud Next 大会上做了两件事：正式发布 GKE Agent Sandbox，并首次公开了 Agent Substrate 项目。这两个公告背后，藏着一个 Kubernetes 资深人士一直不愿公开点明的事实——那个曾统治容器时代的平台，并不适合作为 AI 智能体的控制平面。
破题：为什么 Kubernetes 和智能体「八字不合」？
如果将智能体比作操作系统中的进程，而不是数据中心里的服务，这种不匹配就显而易见了。
现代操作系统运行着成千上万个进程，它们大部分时间都处于休眠状态。操作系统会在事件触发时唤醒它们，分配一小片 CPU 时间，然后将它们闲置的内存分页到磁盘，以便为下一个进程腾出空间。智能体的行为几乎与这些进程完全一致。
而 Kubernetes 最初是为了管理一组固定的、长期运行的复制服务而设计的。这种根本性的设计差异解释了为什么现在的智能体基础设施大多是在 Kubernetes 之上运行，而不是作为 Deployment 或 StatefulSet 那样被集成到 Kubernetes 中。
这种不匹配不是小修小补能解决的。它涉及到三个核心问题：
- 工作负载的本质不同：智能体是长期运行、有状态的会话，生命周期大部分时间空闲，被唤醒执行一阵代码后再次沉寂。它执行的代码由大模型在运行时生成，运行宿主必须默认将其视为不可信负载。
- 资源消耗模式不同：一个开发者下午一直打开的编程智能体，当提示词到达时运行 10 秒，然后等待 20 分钟直到下一个提示词到达。将这个数字乘以团队中的开发者数量，你就有了成千上万个名义上「活跃」但实际在「沉睡」的会话。
- 调度粒度不同：智能体通过生成持续不断的细粒度调度事件打破了 Kubernetes 的假设——Kubernetes 的调度器是为数量适中、长时间运行的 Pod 而设计的。
拆解：Agent Sandbox 和 Agent Substrate 分别解决什么问题
谷歌的这两个项目不是替代品，而是分层设计，各司其职。
Agent Sandbox：安全沙箱
Agent Sandbox 解决的是隔离性问题。它是一个基于 Kubernetes 构建的开源执行环境，为每个智能体提供了一个加固的空间来运行大模型生成的代码。
可以将其理解为隔离「监牢」而非普通容器。普通容器共享宿主机内核并信任工作负载会守规矩，而 Sandbox 假设工作负载具备攻击风险，在其周围设置了安全边界。
关键设计点：
- 默认通过 gVisor 实现内核隔离，并暴露可插拔接口，可替换为 Kata Containers 实现完整内核隔离
- 预热池解决冷启动问题：每个集群每秒可分配 300 个 Sandbox，90% 在 200 毫秒内完成
- Pod 快照挂起空闲会话，释放底层计算资源，无需为休眠会话付费
- 默认拒绝的网络策略，出厂基线即假设任意智能体都可能运行它不应该运行的东西
在不到 5 个月的时间里，沙箱采用规模增长了约 16 倍，谷歌随后将其推向了全面可用阶段。LangChain 和 Lovable 等客户已经在上面运行了数百万个智能体。
Agent Substrate：可支撑数百万闲置智能体的运行时
如果 Agent Sandbox 是安全沙箱，那么 Agent Substrate 就是决定哪个智能体在哪里运行的调度层。它重用了 Agent Sandbox 的安全运行时和快照功能，并将它们与一个位于 Kubernetes 集群旁边的小型控制平面配对，将标准控制平面从关键路径上移除。
其核心思路与虚拟内存超分配机制异曲同工：
- 智能体是进程，资源预热池对应一组 CPU 核心
- 空闲会话快照等同于内存页置换至磁盘
- 资源超配背后的思路和虚拟内存机制一贯的设计逻辑如出一辙
Agent Substrate 将大量有状态执行智能体的注册表复用到一小部分预热的工作 Pod 池上，将空闲的会话快照进行持久化。数据显示，由于事件到达时工作 Pod 已经在运行且从不等待 Kubernetes 调度器，实现了 30 倍或更高的超额订阅率和亚秒级激活速度。
更重要的是，Substrate 是框架无关的，可以将 ADK、LangChain、Claude Code 或任意 OCI 容器作为执行者运行。
建框架：智能体运行时是第四种计算形态
超大规模云厂商已经在朝这个方向布局。这种具有会话感知能力、隔离的智能体运行时已成为继虚拟机、容器和无服务器计算之后的第四种计算形态。
让我们从历史视角梳理一下这四种计算形态的演进：
| 计算形态 | 核心抽象 | 调度粒度 | 隔离方式 | 典型代表 |
|---|---|---|---|---|
| 虚拟机 | 完整的 OS | 分钟级 | 硬件级 | VMware, EC2 |
| 容器 | 进程组 | 秒级 | 内核级（cgroup） | Docker, Kubernetes |
| 无服务器 | 函数 | 毫秒级 | 运行时级 | Lambda, Cloud Functions |
| 智能体运行时 | 有状态会话 | 亚秒级+休眠 | 内核级（gVisor/Firecracker） | Agent Substrate, E2B |
智能体运行时的独特性在于：它需要同时处理长时间空闲和突发爆发两种极端模式，这是前三种计算形态从未面对过的场景。
推演：这场架构变革意味着什么
1. Kubernetes 仍然是基础设施，但不再是「控制平面」
Kubernetes 仍然负责底层机器资源配置（Pod、自动扩缩容），但控制智能体调度的逻辑正在被抽离到上层。这不是取代，而是分层——Kubernetes 做它擅长的事（管理节点资源），Agent Substrate 做它擅长的事（管理智能体生命周期）。
2. 智能体基础设施正在快速收敛
目前 AWS、Google Cloud、Azure、Cloudflare 都推出了各自的 Agent Sandbox 方案，但实现方式各不相同：Cloudflare 使用容器隔离 + V8 isolate，E2B 使用 Firecracker 微 VM，谷歌使用 gVisor。这个领域面临着与当年容器编排赛道同样的「收敛问题」——最终会像 Kubernetes 统一容器编排一样，出现一个主导的开源智能体运行时吗？
3. 对开发者的影响：从「部署服务」到「管理会话」
当智能体成为主流计算负载后，开发者需要考虑的不再是「如何部署一个服务」，而是「如何管理百万个有状态会话的休眠与唤醒」。这需要全新的监控、日志、调试和成本管理工具。Solo.io 已经将 Substrate 集成到 kagent 中，提供了统一的 UI 管理界面。
落到行动：你可以做什么
- 如果你是平台团队：关注 Agent Substrate 的开源进展，评估智能体运行时的成本模型。对于超过一定规模的智能体部署，Kubernetes 原生调度可能已经不够用了。
- 如果你是 AI 应用开发者：理解「智能体是进程，不是服务」这个思维模型。不要在 Kubernetes 层面强行模拟智能体行为，而是利用现成的 Agent Sandbox 方案。
- 如果你是架构师：关注智能体运行时的收敛方向。目前还处于早期阶段，但一旦形成标准，整个 AI 应用的基础设施栈将重新洗牌。
谷歌的 Agent Substrate 目前尚处于早期探索阶段，并非定型产品。但它的设计思路已经指明了方向——智能体不是一种「服务」，而是一种「进程」。当这个认知被基础设施层充分吸收时，我们才能真正释放 AI 智能体的规模化潜力。
毕竟，Kubernetes 统治了容器十年，但下一个十年属于智能体。而智能体需要自己的运行时。
参考来源：The New Stack / Google Cloud Blog / InfoQ 中文站