破题：K8s 很好，但它是为另一个时代设计的
如果你在过去一年跑过 AI Agent 的生产环境，大概已经隐约感觉到：Kubernetes 不太对劲。
不是它不好——Kubernetes 是云原生时代最成功的调度系统。它解决了容器编排的问题，让微服务可以在成千上万个节点上稳定运行。但问题恰恰在于：Agent 不是微服务。
一个 Agent 会话的生命周期是这样的：你发出一个 Prompt，它跑 10 秒，然后等 20 分钟，直到下一个事件到达。乘以团队中的开发者数量，你就有成千上万个名义上"活跃"但实际在"沉睡"的会话。
Kubernetes 的 API Server 和 Scheduler 是为长期运行、固定副本数的服务设计的。当 Agent 以百万级数量、频繁挂起/恢复的形态出现时，控制平面就变成了瓶颈——而不是调度仲裁者。
2026 年 5 月，Google 在 Cloud Next '26 上正式推出 GKE Agent Sandbox（GA） 并介绍了 Agent Substrate 项目。这两个公告间接承认了 K8s 资深人士一直不愿公开点明的事实：那个曾称霸容器时代的平台，并不适合作为 AI Agent 的控制平面。
拆解：Agent 作为"进程"而非"服务"
要理解为什么 K8s 不适合 Agent，需要先理解 Agent 工作负载的本质。
Google 的架构文档用了一个非常精准的类比：把 Agent 想象成操作系统中的进程，而不是数据中心里的服务。
| 维度 | 传统服务（K8s 擅长） | AI Agent（K8s 不擅长） |
|---|---|---|
| 生命周期 | 长期运行，持续在线 | 短时爆发，大部空闲 |
| 状态 | 无状态 / 外部存储 | 强状态，会话上下文 |
| 调度粒度 | 分钟级 Pod 调度 | 毫秒级事件唤醒 |
| 隔离需求 | 容器边界 | 内核边界（不可信代码） |
| 数量级 | 千级 Pod | 百万级会话 |
这种差异解释了为什么现在的 Agent 基础设施大多是在 Kubernetes 之上运行，而不是像 Deployment 或 StatefulSet 那样作为工作负载被集成到 Kubernetes 中。
建框架：Google 的三层架构
Google 的方案用三层架构来解决这个问题，每一层解决一个核心矛盾：
第一层：Agent Sandbox — 安全隔离
Agent Sandbox 是一个基于 K8s 构建的开源执行环境，为每个 Agent 提供一个加固的运行空间。
核心特性：
- 默认内核隔离：通过 gVisor 实现，默认拒绝网络策略。这不是为极端安全附加的组件，而是出厂基线。假设任意 Agent 都可能运行它不应该运行的东西。
- 预热池（Warm Pool）：每个集群每秒可分配 300 个 Sandbox，90% 在 200ms 内完成。解决冷启动问题。
- Pod 快照：空闲 Agent 通过 Pod 快照挂起，数秒内恢复，释放底层计算资源。
LangChain 和 Lovable 等客户已经在上面运行了数百万个 Agent。
第二层：Agent Substrate — 超大规模调度
Agent Sandbox 解决了隔离问题，但百万级空闲会话的调度问题依然存在。这就是 Agent Substrate 要解决的问题。
Agent Substrate 的核心思路：将虚拟内存的超分配机制应用到计算资源调度领域。
操作系统的虚拟内存允许程序寻址远超物理内存的空间，将冷页分页到磁盘。Agent Substrate 对 Agent 会话采用同类思路：将大量有状态执行 Agent 的注册表复用到一小部分预热的工作 Pod 池上，空闲会话快照持久化。
关键数据：30 倍或更高的超额订阅率，亚秒级激活速度。
Agent Substrate 并不是替代 Kubernetes。它使用 Pod 和自动扩缩容完成资源配置，然后在上层叠加自己的调度器，处理 K8s 难以胜任的 Agent 调度决策。
第三层：Kubernetes — 底层资源管理
K8s 仍然管理底层节点。架构决策在于：哪一层负责哪项工作。
在实践中，大规模运行编程 Agent 的团队会：Sandbox 化代码 → 通过 Substrate 调度 → 让 Kubernetes 配置两者之下的节点。
推演：Agent 控制平面会收敛吗？
Kubernetes 在 2014 年开源时，容器编排赛道群雄逐鹿（Mesos、Swarm、Nomad……），最终 K8s 胜出成为事实标准。Agent Substrate 现在处于类似的位置——但有几个关键不同：
看多因素
- Google 的背书：Tim Hockin（K8s 核心贡献者）直接参与 Agent Substrate 设计，历史经验无法复制但可以借鉴。
- 开源策略：项目在 GitHub 上以开源方式启动，邀请社区共同设计——这和当年 K8s 的策略一模一样。
- 框架无关：Agent Substrate 可以运行 ADK、LangChain、Claude Code 或任意 OCI 容器，不绑定 Google 生态。
- Solo.io 集成：kagent 已将 Agent Substrate 作为可选运行时，通过统一 UI 调度框架。
看空因素
- 竞争格局更复杂：AWS、Azure、Cloudflare 都已推出各自的 Agent Sandbox 方案，每家的实现方式不同。生态割裂可能向上转移到这一层基础设施。
- Agent 基础设施的形态仍在快速演进：Kimi K3 这样的国产模型在 48 小时内被订阅挤爆，说明需求端的爆发速度远超供给端——这种环境下，技术标准尚未固化。
- 开源社区的态度：GCC 和 Linux 内核最近对 AI 生成代码的限制态度，说明基础软件领域对 AI 生态的信任仍在建立中。
一个更可能的走势
Agent Substrate 很可能不会像 K8s 那样一家独大，而是催生出一个"Agent 控制平面"的标准化接口层，底层实现由各家云厂商差异化竞争。就像 Kubernetes 定义了 Pod 和 Service 的抽象，Agent Substrate 定义了 Session 和 Snapshot 的抽象——但真正落地时，Google Cloud 和 AWS 的实现在性能调优上会有显著差异。
落到行动：这对开发者意味着什么？
如果你正在构建或计划构建 Agent 产品，现在就可以开始关注：
- 理解 Agent 的"进程模型"：不要再把 Agent 当微服务来部署。会话状态管理、空闲资源回收、亚秒级唤醒——这些是你架构设计时必须考虑的核心指标。
- 关注 Agent Substrate 的发展：项目已在 GitHub 上开源（github.com/agent-substrate/substrate），可以关注它的 API 设计和社区讨论。
- K8s 不会消失，但它的角色在变化：K8s 仍然是优秀的底层资源管理器，但 Agent 调度层会在它上面生长。如果你是平台团队，现在就应该开始思考你的 Agent 基础设施分层策略。
- 成本是下一轮竞争的焦点：空闲会话的算力浪费将成为平台团队无法忽视的开支。Agent Substrate 的 30 倍超额订阅指向一个明确的方向——谁能在不牺牲延迟的前提下实现更高的密度，谁就赢。
Agent 时代的计算基础设施正在经历从"容器"到"进程"的范式转移。Kubernetes 统治了容器十年，但下一个十年的控制平面，现在才刚刚开始投票。
参考来源：The New Stack | Google Cloud Blog