曾称霸容器时代的Kubernetes，如今被16倍增长的AI智能体抛弃？

谷歌在2026年5月悄悄打出了一张新牌。伴随GKE智能体沙箱的推出，一个名为智能体底层的项目也一同浮出水面。这两个公告间接承认了一个Kubernetes资深人士不愿公开点明的事实：那个曾称霸容器时代的平台，并不适合作为AI智能体的控制平面。

智能体沙箱为智能体提供了一个运行不可信代码的安全环境。智能体底层则增加了一个调度层，直接绕过了Kubernetes控制平面。核心原因很简单，控制平面的API服务器在设计之初从未考虑过智能体的行为模式。

如果把智能体比作操作系统中的进程，而不是数据中心里的长驻服务，这种不匹配就一目了然。现代操作系统运行着成千上万个进程，它们绝大部分时间都处于休眠状态。操作系统在事件触发时将其唤醒，分配一小片CPU时间，然后把闲置内存分页到磁盘，为下一个进程腾出空间。智能体的行为几乎与此完全一致。

Kubernetes诞生之初，是为了管理一组固定的、长期运行的复制服务。这种根本性的设计差异，解释了为什么现在的智能体基础设施大多是在Kubernetes之上运行，而非像Deployment或StatefulSet那样被集成进Kubernetes内部。

智能体更像“休眠进程”，而非“常驻服务”

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

试想一个编程智能体，开发者整个下午都让它保持打开。当提示词到达时，它运行10秒，之后等待20分钟直至下一条指令。将这个场景乘以团队中的开发者数量，就得到了成千上万个名义上“活跃”、实质上“沉睡”的会话。

为每个空闲会话保留一个完整的Pod，无疑会浪费预留的内存和CPU。于是，新一代运行时选择了另一条路：将空闲会话的状态快照从计算资源中剥离。

流量突发、不可信代码、持久状态：三大死穴

Kubernetes控制平面面临的压力来自多个维度。首先是调度策略。智能体的请求运行时间更长，但到达频率更低。轮询或随机放置这种在短请求高并发场景下见谁怼谁的策略，到了智能体这里就失效了——糟糕的路由选择会持续存在，放大尾部延迟，让排在后面的用户苦不堪言。

第二个承压点正是API服务器本身。将每个活跃或空闲的智能体都存为Kubernetes对象，意味着在一个从未为此规模设计的系统中产生数百万个资源实例。智能体底层项目的架构文档对此直言不讳：没有巧妙的方法能让标准控制平面容纳这么多对象。于是，运行时将大多数智能体直接排除在控制平面之外。路由也采用了绕行方案，使用专用网络层将请求直接发送到正确的会话，若休眠则立即唤醒。

更本质的矛盾在于，平台根本无法预定义智能体要跑的代码——那些代码是大模型在运行时生成的。运行时不能再假定负载是良性的。隔离责任从容器边界，被直接推到了内核边界。

同样致命的是状态持久化。智能体每次挂起都丢失上下文，它将变得完全不可用。运行时必须在休眠期间保存其易失性RAM和文件系统状态，并在瞬间恢复。这对一个为长时间运行、数量适中的Pod而设计的调度系统而言，完全是陌生的命题。

智能体沙箱：隔离“监牢”而不是普通容器

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

可以把它理解为“监牢”，而非普通容器。普通容器共享宿主机内核并信任工作负载，该沙箱则假设负载天生具备攻击风险，并围绕其设置安全边界。默认通过gVisor实现这一边界，添加了默认拒绝的网络策略，并暴露出可插拔接口，允许团队替换为Kata Containers来实现完整的内核隔离。

LangChain和Lovable等客户已经在上面运行了数百万个智能体。这种规模倒逼团队进行性能优化，最终打造出的运行时将安全性与性能视作同一问题的两面，二者不再是需要艰难取舍的对立目标。

为解决冷启动延迟，该沙箱维持了一个预配置的副本预热池。谷歌的报告显示，每个集群每秒可分配300个沙箱，其中90%的分配在200毫秒内完成。空闲智能体则通过Pod快照挂起，可按需在数秒内恢复。