容器时代属于 Kubernetes，智能体时代呢？谷歌押注 Agent Substrate
2026年5月，谷歌宣布 GKE Agent Sandbox 正式 GA，同时披露了一个名为 Agent Substrate 的项目。这两则公告共同承认了一个 Kubernetes 资深人士一直不愿公开点明的事实：那个曾称霸容器时代的平台，并不适合作为 AI 智能体的控制平面。
这不是一个功能缺口，而是架构层面的根本错配。
一、破题：Kubernetes 的"容器思维"错在哪
Kubernetes 诞生于2014年，设计初衷是管理一组固定的、长期运行的复制服务。一个 Deployment 有3个副本，每个副本稳定运行，流量通过 Service 负载均衡，HPA 根据 CPU 利用率自动扩缩容——这套模型完美匹配了微服务架构。
但智能体不是微服务。
不妨把智能体想象成操作系统中的进程，而不是数据中心里的服务。现代操作系统运行着成千上万个进程，大部分时间它们都处于休眠状态。操作系统会在事件触发时唤醒它们，分配一小片 CPU 时间，然后将它们闲置的内存分页到磁盘，为下一个进程腾出空间。
智能体的行为与此几乎完全一致：
- 一个编程智能体在下午打开后，用户发送提示词时它运行10秒，然后等待20分钟，直到下一个提示词到达
- 将这个数字乘以团队中的开发者数量，你就有了成千上万个名义上"活跃"但实际在"沉睡"的会话
- 每个会话需要一个稳定的身份标识，能够在不丢失内存的情况下暂停和恢复
- 它执行的代码由大模型在运行时生成，运行宿主必须默认将其视为不可信负载
Kubernetes 为每个空闲会话保留一个完整的 Pod，会浪费 Pod 预留的内存和 CPU。更致命的是，Kubernetes 的中心化 API 服务器和调度器设计假设调度决策发生频次低且决策是持久的。智能体通过生成持续不断的细粒度调度事件打破了这一假设，使控制平面本身成为瓶颈。
二、拆解：智能体作为工作负载的三个本质特征
特征一：沉睡数小时的会话
智能体会话的流量突发特性与 Web 服务截然不同。Web 服务在请求期间持续消耗 CPU，而智能体会话在两次提示词之间几乎不消耗任何资源。为每个空闲会话保留一个完整的 Pod，本质上是在为"什么都不做"付费。
新一代运行时将空闲会话的状态快照从计算资源中剥离——会话休眠时，将易失性 RAM 和文件系统状态持久化；唤醒时，在数秒内恢复运行。这直接对应操作系统的虚拟内存分页机制。
特征二：平台无法预定义的代码
智能体执行的代码由大模型在运行时生成，运行宿主无法假定负载具备良性行为。这意味着隔离责任从容器边界转移到了内核边界。普通容器共享宿主机内核并信任工作负载会守规矩，而智能体沙箱必须假设工作负载具备攻击风险。
特征三：休眠期间必须持久留存的状态
如果一个智能体每次挂起都丢失上下文，它将变得不可用。会话状态（工作内存、文件系统、工具调用历史）必须在休眠期间完整保存，并在恢复时精确还原。这超出了 Kubernetes 原生能力的设计范围。
三、建框架：Agent Substrate 的三层架构
谷歌的解决方案不是用一个平台替换另一个，而是在 Kubernetes 之上叠加一个专门为智能体设计的控制平面。整个架构分为三层：
第一层：Agent Sandbox — 安全隔离层
Agent Sandbox 是一个基于 Kubernetes 构建的开源执行环境，为每个智能体提供了一个加固的空间来运行大模型生成的代码。区别于普通容器共享宿主机内核的设计，Sandbox 默认通过 gVisor 实现内核级隔离，并添加了默认拒绝的网络策略。
关键设计亮点：
- 预热池：为每个请求启动一个新 Sandbox 会增加数秒延迟，因此 Sandbox 保持了一个预配置的副本预热池。谷歌报告显示，每个集群每秒可以分配300个 Sandbox，其中90%在200毫秒内完成分配。
- Pod 快照：空闲智能体通过 Pod 快照挂起，释放底层计算资源，而非付费让休眠会话常驻内存。
- 默认内核隔离：gVisor 和网络访问限制属于出厂基线配置，非极端安全需求的附加组件。
在不到5个月的时间里，Agent Sandbox 的采用规模增长了约16倍，LangChain 和 Lovable 等客户已经在上面运行了数百万个智能体。
第二层：Agent Substrate — 调度与运行时层
如果 Agent Sandbox 是安全沙箱，那么 Agent Substrate 就是决定哪个智能体在哪里运行的调度器。它重用了 Sandbox 的安全运行时和快照功能，并将它们与一个位于 Kubernetes 集群旁边的小型控制平面配对，将标准控制平面从关键路径上移除。
核心思路是将虚拟内存超分配机制运用到计算资源调度领域：
- 操作系统允许程序寻址远超机器物理内存的内存，方法是将冷页分页到磁盘
- Agent Substrate 对智能体会话采用同类思路：将大量有状态执行智能体的注册表复用到一小部分预热的工作 Pod 池上，将空闲的会话快照持久化
- 项目数据显示：由于事件到达时工作 Pod 已经在运行且从不等待 Kubernetes 调度器，实现了 30倍或更高的超额订阅率 和 亚秒级激活速度
Substrate 是框架无关的，可以将 ADK、LangChain、Claude Code 或任意 OCI 容器作为执行者运行。面向开发者的形态由两个自定义资源组成：WorkerPool（定义就绪计算资源）和 ActorTemplate（定义智能体）。
第三层：Kubernetes — 底层资源管理层
Substrate 并非 Kubernetes 的替代品。它仍然使用 Pod 和自动扩缩容完成资源配置，只是在上面叠加了自己的调度器。Kubernetes 管机器，Substrate 管智能体——分工明确。
正如谷歌官方博客所言："标准 Kubernetes 优化用于处理数千个长期运行的服务，而 Agent Substrate 专为处理数百万个亚秒级工具调用的喧嚣而设计——这些调用本会淹没标准控制平面。"
四、推演：第四种计算形态的诞生
超大规模云厂商已经在朝这个方向布局。这种具有会话感知能力、隔离的智能体运行时，正在成为继虚拟机、容器、无服务器计算之后的第四种计算形态。
这一趋势的底层逻辑是什么？
1. 智能体不是服务，而是进程
这是最根本的认知转变。服务是"始终在线、等待请求"，而进程是"需要时唤醒、空闲时休眠"。Kubernetes 是为服务设计的，不是为进程设计的。Agent Substrate 的架构文档对此直言不讳，承认"没有巧妙的方法能让标准控制平面容纳这么多对象"。
2. 空转成本正在成为平台团队不可忽视的支出
当智能体规模从个位数增长到数万、数百万时，为空闲会话保留 Pod 的浪费将变得不可接受。Agent Substrate 通过虚拟内存式的超分配机制，将空闲智能体的成本压缩到接近零。
3. 生态竞争：一个还是多个控制平面？
目前 Agent Substrate 仍处于早期探索阶段，并非定型产品。Solo.io 已经将 Substrate 集成到 kagent 中，提供统一 UI 调度。但悬而未决的问题是：谁会主导智能体控制平面这一层？
乐观场景：像当年容器编排赛道最终收敛到 Kubernetes 一样，收敛成一个单一的开源项目。
现实场景：各大超大规模云厂商各自推出自研方案——智能体原本想要摆脱的生态割裂问题，会向上转移到这一层基础设施再度出现。
五、落到行动：对工程团队的启示
对于正在或即将大规模部署 AI 智能体的团队，Agent Substrate 的出现提出了几个值得现在就开始思考的问题：
1. 你的智能体架构是"进程思维"还是"服务思维"？
如果当前你仍然用 Deployment + Service 的方式部署智能体，每个智能体对应一个长期运行的 Pod，那么当规模扩大到数百个时，空转成本将迅速膨胀。尽早引入会话快照和按需恢复机制。
2. 安全隔离是否是出厂默认配置？
Agent Sandbox 的设计哲学是"假设智能体具备攻击风险"。如果你的运行时环境还没有将安全隔离作为默认配置，而是作为"安全需求强烈时再添加"的选项，这个顺序需要倒过来。
3. 关注智能体运行时生态的收敛方向
Agent Substrate、AWS Bedrock AgentCore、Azure AI Foundry Agent Service、LangGraph Platform、Agyn……2026年的智能体运行时市场，就像2015年的容器编排市场一样热闹。但历史告诉我们，这个层最终会收敛。值得关注的是：Agent Substrate 是否会凭借开源生态和谷歌的背书，成为智能体时代的 Kubernetes？
Kubernetes 仍然是一个优秀的数据中心调度器，在配置底层机器资源方面仍然无可替代。但对于一大群休眠进程形态的负载而言，它并不是合适的调度器——Agent Substrate 正是为此而生。
原文参考：The New Stack: Kubernetes won the container decade. Google's Agent Substrate wants the next one. | Google Cloud Blog: Agent Sandbox on GKE is now available