AI agent 在工作负载上存在明显的突发性：活跃时密集计算，空闲时长期等待，而静态分配的计算资源会在空闲期持续浪费。Google Cloud 团队在一台固定规格的 GKE 节点（n2-standard-48）上测试了 OpenClaw 框架下 agent 的部署密度。

基线测试使用微VM（Kata containers）提供硬件级隔离，但每个微VM都需要独立的客户操作系统，消耗大量内存和CPU。在该配置下，节点最多只能稳定运行 61 个 agent，超过后健康检查开始频繁失败。

第一步优化是将工作负载迁移到 GKE Agent Sandbox。它使用开源的 gVisor 沙箱，通过用户态内核（Sentry）拦截系统调用，在保持轻量级容器占用的同时提供生产级隔离。迁移后，同一节点上可部署 88 个 agent，密度提升 44%，每 vCPU 承载的 agent 数量增加超过 40%，每个 agent 的成本降低 超过 30%。GKE Agent Sandbox 在2024年5月正式可用后，四周内使用量增长超过 7 倍。

第二步优化是引入编排层的 suspend/resume 机制。GKE Pod snapshots 可以将空闲 agent 冻结（checkpoint）到持久存储，释放 CPU 和内存资源。当新任务触发时，通过轻量级控制器在毫秒级恢复 agent。这种方式允许基于不同 agent 的延迟需求进行差异化超配。测试区分了三种场景：
– 性能优化（实时编码助手，延迟敏感）：使用 Agent Sandbox warm pools 预加热沙箱，实现亚秒级启动，同一节点可运行 133 个 agent。
– 平衡模式（自主队友，可接受秒级启动）：使用 suspend/resume 按需恢复，不占用空闲资源。
– 成本优化（后台定时作业，延迟容忍）：最大程度超配，同一节点运行 274 个 agent，比基线提升 3.5 倍，启动时间保持在 5 秒以内，每个 agent 成本降低 75%。

GKE 通过不同的节点池和工作负载配置，支持在同一集群中混合部署上述模式，避免“惊群效应”带来的性能抖动。团队可以根据业务需求，在成本节省和性能保障之间调整超配比例。