把 Claude Code、Codex 或 Hermes 跑在本地，和运营几十万个长期存活的 Agent，是两种基础设施问题。后者既要执行模型生成的不可信代码，又要承受突发任务，还不能让等待推理结果的沙箱持续占用 CPU 和内存。

Agent Substrate 的核心变化，是把 Agent 执行生命周期与机器管理拆开：Kubernetes 管理节点和 worker，专用执行层负责沙箱的隔离、调度、挂起与恢复。它是开源方案，可以运行在 Kubernetes 基础设施上，并针对 GKE 做了优化。

1. 不是把 Pod 启动得更快，而是绕开高频 Pod 生命周期

常规容器平台擅长管理服务，但 Agent 的运行节奏更像：

收到任务 → 执行代码 → 等待模型 → 执行工具 → 等待用户 → 继续执行

如果每次工具调用都经过完整的 Pod 创建流程，调度、镜像准备和环境启动就会进入关键路径；如果始终保留运行中的容器，又会为大量等待时间预留资源。

Agent Substrate 采用不同分工：

• Kubernetes：管理 worker Pod、节点恢复、集群扩缩容与可靠性。
• 专用控制面：进行低延迟、感知数据位置的调度。
• 专用数据面：在预热 worker 上执行高频挂起和恢复。
• 快照存储：使用本地磁盘和 Google Cloud Storage 保存状态。

根据发布摘要，它支持低于 500 毫秒的恢复操作，以及每秒超过 500 次挂起／恢复激活。这些是发布方给出的能力指标，不能直接当作任意业务负载下的延迟承诺。

尤其要区分三个数字：已保存的会话数、当前活跃的沙箱数、每秒激活次数。百万级 Agent 会话不等于百万个 Agent 同时消耗计算资源。

2. 密度来自释放空闲资源，安全来自双层边界

Agent Substrate 提供两类隔离选择：

隔离不能只停留在内核层。摘要还描述了集成网关和出口代理：控制网络访问，并在 Agent 无法直接触及的位置注入凭据。

这意味着平台设计应把两件事分开：Agent 可以请求调用服务，不代表它应该持有服务密钥。

效率方面，Agent 空闲后可以挂起，保存状态并释放 CPU、内存。摘要给出的指标是每台主机容纳超过 1,000 个休眠 Agent，并实现比传统计算方式高 10 倍的密度。

这里的关键词是“休眠”。如果负载持续编译、运行浏览器或进行 CPU 密集计算，收益不能按相同比例推算。快照存储、网络流量和恢复时的 I/O 也仍然有成本。

3. 可以这样实践：先盘点集群，再验证工作负载

摘要没有提供安装命令、Helm chart 名称或 CRD 字段，因此不应拼凑一个看似真实的部署清单。下面是可直接执行的集群盘点脚本，不是 Agent Substrate 安装脚本。

运行前，安装并配置 kubectl，把 CONTEXT 改为目标 GKE 集群的上下文名称；当前身份需要相应的集群读取权限。

#!/usr/bin/env bash
set -euo pipefail

CONTEXT="your-gke-context"

echo "== Kubernetes version =="
kubectl --context "$CONTEXT" version

echo "== Node architecture and instance types =="
kubectl --context "$CONTEXT" get nodes \
  -L kubernetes.io/arch,node.kubernetes.io/instance-type

echo "== Available RuntimeClasses =="
kubectl --context "$CONTEXT" get runtimeclasses

echo "== StorageClasses =="
kubectl --context "$CONTEXT" get storageclasses

echo "== Current workloads =="
kubectl --context "$CONTEXT" get pods --all-namespaces -o wide

这些检查帮助确认节点架构、现有隔离配置和存储条件，但不能证明 Agent Substrate 已安装或满足部署要求。实际部署应依据对应版本的官方文档。

部署测试环境后，可以围绕四组场景验收：

不要只测“恢复得快不快”。还要测“恢复后能否继续正确执行”，包括打开的文件、子进程和工具状态。

4. 上线前，算清存储账和兼容性账

GKE 优化包括通过 ComputeClasses 管理不同机型以及 Spot、按需资源池，并支持 Google Axion Arm 处理器。使用 Arm 时，应先验证浏览器、原生扩展和命令行工具是否提供兼容版本，而不是只比较机器单价。

对于跨轮次共享工作区，摘要提到可选的 Filestore agent volumes，提供 NFS、RWX 访问和 POSIX 文件锁。不过，支持文件锁不等于应用自动避免写冲突：多个 Agent 修改同一文件，仍需要锁协议、目录隔离或任务级协调。

截至这次发布：

• 开源方案可用于 Kubernetes，并针对 GKE 优化。
• 所有 GKE 客户可用于非生产工作负载。
• 生产 GA 支持需要进入允许名单。

更稳妥的采用顺序，是先选择一类等待时间长、状态需要保留的 Agent 工作负载，测量实际恢复延迟、活跃资源用量和快照成本，再逐步扩大规模。

Agent Substrate 的价值不是让所有 Agent 都跑得更快，而是让平台不再为所有 Agent 的等待时间预留同等计算资源，同时保留明确的执行与网络边界。

Agent Substrate on GKE: Resume Agent Sandboxes Instead of Keeping Them Running

Running Claude Code, Codex, or Hermes locally is very different from operating hundreds of thousands of long-lived agents. At that scale, the platform must execute untrusted generated code, handle bursts of work, and avoid reserving CPU and memory for agents waiting on inference or human input.

Agent Substrate separates agent execution from machine management. Kubernetes manages nodes and workers, while a dedicated execution layer handles sandbox isolation, scheduling, suspension, and resumption. The project is open source, runs on Kubernetes infrastructure, and includes optimizations for GKE.

1. A different lifecycle—not merely faster Pod startup

An agent session often follows this pattern:

Receive task → Execute code → Wait for model → Run tool → Wait for user → Continue

Sending every tool invocation through a complete Pod creation cycle puts scheduling, image preparation, and startup on the critical path. Keeping every container running instead reserves resources during long periods of inactivity.

Agent Substrate divides those responsibilities:

• Kubernetes manages worker Pods, node recovery, fleet scaling, and cluster reliability.
• A dedicated control plane provides low-latency, data-aware scheduling.
• A dedicated data plane performs frequent suspend/resume operations on pre-warmed workers.
• Snapshot storage preserves state on local disk and Google Cloud Storage.

The announcement reports resume operations below 500 milliseconds and more than 500 suspend/resume activations per second. These are published capability figures, not latency guarantees for every application.

Keep three measurements separate: saved sessions, active sandboxes, and activations per second. A million agent sessions does not mean a million agents consuming compute simultaneously.

2. Density comes from reclaiming idle resources; security needs two boundaries

Agent Substrate offers two isolation options:

Kernel isolation is only part of the boundary. The announcement also describes an integrated gateway and egress proxies that control network access and inject credentials outside the agents’ reach.

The platform should therefore distinguish two privileges: permission to request a service call is not permission to possess the service credential.

For efficiency, idle agents can be suspended, their state saved, and their CPU and memory released. The announcement reports more than 1,000 dormant agents per host and 10× higher density than traditional compute.

“Dormant” matters. A workload that continuously compiles code, runs browsers, or performs CPU-intensive work will not necessarily see the same benefit. Snapshot storage, network traffic, and resume-time I/O also remain part of the cost.

3. A practical starting point: inventory the cluster, then test the workload

The supplied material does not specify installation commands, Helm chart names, or CRD fields. Rather than invent a deployment manifest, start with this copyable cluster inventory script. It does not install Agent Substrate.

Before running it, install and configure kubectl, replace CONTEXT with your target GKE context, and ensure your identity has the required cluster read permissions.

#!/usr/bin/env bash
set -euo pipefail

CONTEXT="your-gke-context"

echo "== Kubernetes version =="
kubectl --context "$CONTEXT" version

echo "== Node architecture and instance types =="
kubectl --context "$CONTEXT" get nodes \
  -L kubernetes.io/arch,node.kubernetes.io/instance-type

echo "== Available RuntimeClasses =="
kubectl --context "$CONTEXT" get runtimeclasses

echo "== StorageClasses =="
kubectl --context "$CONTEXT" get storageclasses

echo "== Current workloads =="
kubectl --context "$CONTEXT" get pods --all-namespaces -o wide

These checks reveal node architectures, existing runtime isolation configuration, and storage options. They do not establish that Agent Substrate is installed or that deployment prerequisites are satisfied. Use the documentation for the version you intend to deploy.

Once a test environment is available, validate four areas:

Measure more than how quickly a sandbox resumes. Verify that it continues correctly, including its files, subprocesses, and tool state.

4. Check storage costs and compatibility before production

The GKE optimizations include ComputeClasses for managing machine shapes and Spot/on-demand pools, plus support for Google Axion Arm processors. Before choosing Arm capacity, verify that browsers, native extensions, and command-line tools have compatible builds.

For shared workspaces across turns, the announcement describes optional Filestore agent volumes with NFS, RWX access, and POSIX file locking. However, available locks do not automatically prevent application-level write conflicts. Agents editing the same files still need a locking protocol, isolated directories, or task coordination.

At the time of this announcement:

• The open-source solution runs on Kubernetes and is optimized for GKE.
• All GKE customers can use it for non-production workloads.
• Production GA support requires allowlist access.

A sensible adoption path is to begin with one workload that spends substantial time waiting and needs persistent session state. Measure resume latency, active resource usage, and snapshot costs before expanding.

The central benefit is not that every agent becomes faster. It is that the platform can stop reserving equivalent compute for every agent’s waiting time while maintaining explicit execution and network boundaries.

SEO description

Agent Substrate on GKE separates sandbox execution from cluster management, combining isolation, fast resume, and idle resource reclamation.