AI Agent 的资源曲线通常不是平滑直线：它们会集中推理、调用工具或执行代码，随后等待用户输入和外部事件。如果每个 Agent 始终占用固定 CPU 和内存，大量预算最终会消耗在空闲时间上。
一次基于 n2-standard-48 GKE 节点和 OpenClaw 工作负载模型的测试展示了三层优化效果：从每个 Agent 独占 microVM，到使用 GKE Agent Sandbox，再到通过快照、挂起和恢复复用空闲资源。最终，同一节点承载的 Agent 数量从 61 个提高到 274 个，密度超过基线的 3 倍，单 Agent 成本最多下降 75%。这些数字来自特定测试环境，不应直接当作所有工作负载的容量承诺，但背后的架构方法具有普遍价值。
microVM 的隔离很强，但每个 Agent 都在支付操作系统成本
多租户 Agent 可能执行模型生成的代码、第三方工具或者用户提交的脚本，因此进程级隔离往往不够。为每个 Agent 分配 Kata Containers 一类的 microVM，可以获得硬件级安全边界，但每个实例也需要自己的客户机操作系统。
这部分固定开销会侵占原本可以分配给 Agent 的 CPU 和内存。在测试基线中，一个标准 GKE 节点运行到 61 个 OpenClaw Agent 后，健康检查开始频繁失败，继续增加副本已经无法维持可靠性。
问题不在 Kubernetes 本身，而在隔离单元太重。当 Agent 本体不大、空闲时间又很长时，每个实例附带一套操作系统会显著拉高单位成本。
Agent Sandbox：把安全边界做轻
GKE Agent Sandbox 使用开源沙箱运行时 gVisor。gVisor 通过用户态内核 Sentry 拦截和过滤系统调用，在容器与宿主机内核之间增加隔离层，但不需要为每个 Pod 启动完整客户机操作系统。
迁移到 Agent Sandbox 后，同一测试节点可以承载 88 个 Agent，比 61 个的 microVM 基线提高约 44%。对应结果是每 vCPU 可运行的 Agent 数增加超过 40%，单 Agent 成本下降超过 30%，同时保持相近的性能表现。
下面是一个可以改造的 Kubernetes 工作负载示例。它使用常见的 gvisor RuntimeClass 名称；运行前应通过 kubectl get runtimeclass 确认集群实际提供的名称，并替换镜像、端口和健康检查路径。
apiVersion: apps/v1
kind: Deployment
metadata:
name: agent-worker
labels:
app: agent-worker
spec:
replicas: 4
selector:
matchLabels:
app: agent-worker
template:
metadata:
labels:
app: agent-worker
workload-class: interactive
spec:
runtimeClassName: gvisor
terminationGracePeriodSeconds: 30
containers:
- name: agent
image: us-docker.pkg.dev/PROJECT_ID/agents/worker:VERSION
ports:
- name: http
containerPort: 8080
resources:
requests:
cpu: 250m
memory: 512Mi
limits:
cpu: "2"
memory: 2Gi
readinessProbe:
httpGet:
path: /ready
port: http
periodSeconds: 5
failureThreshold: 3
livenessProbe:
httpGet:
path: /healthz
port: http
periodSeconds: 15
failureThreshold: 3
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: agent-worker
spec:
minAvailable: 2
selector:
matchLabels:
app: agent-worker
修改占位符后，可以这样检查并部署：
kubectl get runtimeclass
kubectl apply -f agent-worker.yaml
kubectl rollout status deployment/agent-worker
kubectl top pods -l app=agent-worker
资源 requests 决定调度器如何装箱 Pod，不能为了提高表面密度而随意压低。更稳妥的做法是采集 Agent 活跃期与空闲期的 CPU、内存分位数，再根据 OOM、限流和延迟数据逐步调整。
真正的大幅降本来自“冻结空闲 Agent”
轻量沙箱降低了运行时隔离开销，但一个空闲 Pod 仍可能保留 CPU 和内存。GKE Pod snapshots 可以把 Agent 状态检查点写入持久化存储，然后释放物理资源。新任务到达时，控制器或事件网关再恢复对应 Agent。
这种机制允许平台根据实际活跃比例超额订阅节点，而不是假设所有 Agent 会同时工作。测试给出了两种配置：
| 策略 | 单节点 Agent 数 | 适用场景 |
|---|---|---|
| microVM 基线 | 61 | 强隔离，但密度较低 |
| Agent Sandbox | 88 | Agent 持续运行，降低沙箱开销 |
| 性能优先编排 | 133 | 使用温池吸收突发流量 |
| 成本优先编排 | 274 | 可排队或错峰，启动时间低于 5 秒 |
性能优先模式使用 Agent Sandbox Warm Pools 保留预热的隔离环境，适合必须在一秒内响应的编码助手。成本优先模式允许更高超额订阅，适合定时研究、批量分析等能够等待容量的任务。介于两者之间的后台协作 Agent，则可以通过挂起和恢复换取数秒启动延迟。
关键点是不要给整个集群设置一种统一策略。可以这样划分服务等级：
realtime：不允许排队，配置温池和容量缓冲，并为突发恢复预留 CPU。interactive：允许数秒恢复时间，空闲后挂起，保留持久状态。batch：允许排队和错峰，采用更高超额订阅率，并设置并发上限。
用数据决定超额订阅比例
274 个 Agent 并不意味着节点能同时运行 274 个高负载任务。超额订阅依赖一个重要假设：任意时刻只有一部分 Agent 活跃。如果大量 Agent 同时被唤醒，就会出现“惊群”问题，带来 CPU 争抢、排队、恢复超时甚至级联失败。
容量评估至少要记录四组指标：
- 活跃 Agent 数量及其峰值分布。
- 从事件到 Agent 可服务状态的恢复延迟。
- CPU 限流、内存工作集、OOM 和健康检查失败率。
- 快照大小、写入时间、恢复失败率与持久化存储成本。
可以用下面的简化关系做第一轮估算：
所需节点容量 ≈ Agent 总数 × 单 Agent 活跃资源 × 峰值同时活跃率 × 安全系数
例如，1000 个 Agent 活跃时平均需要 0.5 vCPU，观测到的峰值同时活跃率为 12%，安全系数取 1.5，那么初始 CPU 预算约为 1000 × 0.5 × 0.12 × 1.5 = 90 vCPU。这只是容量测试的起点，不能替代真实流量压测。
落地时应检查什么
先用 Agent Sandbox 替换重型 microVM，可以获得相对直接的密度收益；随后再按延迟等级引入快照、温池、挂起和恢复。不要一开始就追求最大超额订阅率。
上线前应确认：Agent 状态能够可靠持久化；恢复操作具备幂等性；事件不会重复执行有副作用的工具调用；温池能够覆盖突发恢复量；批处理任务存在并发和速率限制；节点耗尽时有明确的排队、扩容或拒绝策略。
GKE 测试中的最高 75% 单 Agent 成本降幅，本质上来自两件事：用 gVisor 减少每个隔离环境的固定开销，以及让空闲 Agent 释放资源。前者提升稳定运行时的密度，后者利用工作负载的间歇性。只有把安全边界、恢复延迟和峰值并发一起纳入设计，这种成本收益才不会以可靠性为代价。