本地跑得动，不等于规模跑得起
开发者已经习惯在本机运行各类编码智能体与 harness。这与同时运行数十万个长期存活、会生成代码、调用工具并驱动自动化执行的并发智能体，是完全不同量级的问题。Google 在 GKE 上开放了一套名为 Agent Substrate 的智能体执行运行时，开源、默认安全，官方给出的目标是以比标准容器运行时高 10 倍的密度运行数百万个沙箱。
这套系统面向的正是从原型走向规模这段路上的基础设施约束。官方把约束归为四类：模型能够即时生成并执行任意代码，形成不透明的信任边界；智能体需要完整的计算机环境才能调用命令行、无头浏览器与文件系统；harness、基准测试与强化学习 rollout 可以在每分钟创建数千个沙箱；以及自主智能体绝大多数时间在休眠，为闲置容器预留 CPU 与内存会造成浪费。
这四项里最容易被低估的是最后一项。前三项是安全与性能问题，有明确的技术路径可走；第四项是成本结构问题，它决定了大规模智能体集群在财务上能不能持续。把一个长期空闲的容器一直挂着，等于为「等待」支付全额算力费。
架构选择：把执行与机器管理解耦
平台团队面对这类需求时，通常只有两个都不理想的选择：牺牲控制与隔离换取效率，或者用虚拟机换取隔离但承受高延迟与低利用率。Agent Substrate 的做法是不在这两者之间选，而是把智能体执行从机器管理中拆出来。
具体实现上，高频的挂起与恢复直接跑在本地预热 Worker 上，由专用数据面处理；与此同时，Kubernetes 负责管理机器，承担节点自愈、集群自动扩缩与集群可靠性，并驱动 Worker Pod 自身的生命周期。这样避免了把每一次亚秒级工具调用都送进标准 Pod 生命周期——后者会给每个请求增加数秒延迟。
对仍需要标准 Pod 语义的工作负载，既有原语如 Agent Sandbox 与内核隔离 Pod 可以并行使用。这一点值得留意：它承认新执行层不是要取代 Kubernetes 的既有模型，而是为特定形态的工作负载开一条旁路。Agent Substrate 本身构建在此前已在 GKE 上可用的 Agent Sandbox 安全运行时与快照能力之上，只是把 Kubernetes 控制面移出了热路径。
隔离与凭证：两道默认安全线
隔离方面提供两种选择。硬件隔离的 Cloud Hypervisor microVM 提供完整的 Linux 内核兼容性；开销更低的 gVisor 则提供沙箱化的内核隔离。两者都针对「运行人类从未审查过的代码」这一前提设计，目标是限制宿主逃逸、凭证窃取与数据外泄。
比隔离方式更值得关注的是凭证处理。Agent Substrate 的集成网关管理所有出站与入站请求，出口代理负责执行细粒度网络策略，并在智能体无法触及的位置注入凭证。这条设计的含义可以这样理解：智能体的上下文、日志与文件系统里不会出现长期有效的密钥，即使模型被提示注入引导去读取环境变量，也拿不到可以直接使用的凭据。
把凭证注入点从沙箱内移到网络边界，是目前智能体安全设计里被认为较难绕过的一种做法。它的代价是集成的复杂度上升——每个需要调用外部服务的工具都要经由代理配置，而不是在代码里读一个环境变量了事。
零空闲经济模型与密度从哪来
密度的来源是资源回收机制。智能体暂停时，系统把 guest hypervisor 的状态快照写入本地磁盘与 Google Cloud Storage，释放 RAM 与 CPU 去运行其他智能体，同时保持状态完整。下一轮对话或工具调用到来时，沙箱环境可在不到 500 毫秒内恢复到先前状态，再次空闲后也能立即重新挂起。
官方给出的数据是每台宿主机上可打包超过 1000 个休眠智能体，计算密度比传统计算高 10 倍，每秒可处理 500 次以上挂起与恢复激活。这个模型被概括为零空闲计算：只为活跃的部分付费。
这类收益对不同负载的意义差别很大。对强化学习 rollout 与批量评测，休眠比例高、切换频繁，收益最直接。对长时间等待人类反馈的对话型智能体，休眠时间长，节省更明显。对持续调用工具的密集执行型负载，能节省的比例就有限——它的账要按实际的活跃占比重算，而不是按标称倍数去推算。
有状态工作区：多智能体协作的写冲突
跨轮次共享文件系统是多智能体协作的常见需求，也是写冲突的高发区。这套方案提供了一个可选的 Filestore agent 卷控制器，通过持久 NFS 存储支持在毫秒级挂载与卸载，让智能体近乎瞬时启动或恢复；同时原生支持 Read-Write-Many 访问与 POSIX 兼容的文件锁，以便多个智能体安全协作、避免写冲突。
文件锁这一项看似琐碎，实则是多智能体系统里最难绕开的一致性问题之一。当两个智能体同时改同一个文件，最终状态取决于写入顺序，而顺序在并发环境下不可预测。把互斥语义放在文件系统层，比在每个智能体的提示词里约定「不要同时改同一个文件」可靠得多——后者属于流程约定，前者属于机制约束。
硬件、成本与可用性边界
在底层基础设施上，GKE 上的 Agent Substrate 支持通过自定义 ComputeClasses 动态管理不同规格与系列的机器池，包括 Spot 与按需池。这包括对 Google 自研 Arm 处理器 Axion 的原生支持，官方称对沙箱工作负载可提供比竞品云产品更好一档的性价比。Spot 实例与休眠快照的组合，指向的是一种把成本压到接近存储费用的运行形态。
可用性方面有明确边界：Agent Substrate 开源，面向所有 GKE 客户开放用于非生产工作负载；生产环境的正式可用支持目前通过白名单提供，企业需要走私有通道获取。部署侧有版本要求，需要 GKE Standard 而非 Autopilot，集群版本为 1.36 或 1.37 以上，并依赖 Workload Identity Federation 与 Cloud Storage 承载快照。开源仓库提供控制面、数据面与 GKE 的快速开始入口，架构文档解释了如何把 Kubernetes 控制面移出热路径。
与任何 harness 的兼容性是另一项设计目标，官方列出了 Claude Code、OpenClaw 与 Hermes 等。在生态侧，Nous Research 是其早期设计伙伴，官方称 Hermes 按 OpenRouter 用量统计在生产力、编码、个人助手与 CLI 等类别中排名居前，并引述其商务负责人对「平台层同时解决每智能体隔离与可扩展访问控制」的评价。
竞争位置与需要观察的问题
把这套动作放进近期同类发布里看，能看出一个共同节奏：基础设施厂商正在争夺智能体的执行层。云厂商之外，围绕容器、边缘运行与安全审计的开源智能体工具也在同期出现。这类发布的共同点是把参考实现开源，以此设定标准并扩大开发者基础——历史上 Kubernetes 就是这样把编排层商品化，从而在更上层获得价值。
需要观察的问题有三项。一是生产白名单的放开节奏与门槛，这决定了它从可评估变成可用之间的距离。二是快照中是否包含敏感上下文，以及快照存储侧的加密与生命周期管理细节，官方公告未展开说明。三是这套执行层的性能与成本，需要在真实负载上与既有容器方案做对照，而不是依赖标称密度倍数。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
结语
这套系统的意义在于它把智能体基础设施的关注点从「能不能跑」推进到「跑得省不省」。当智能体从少数几个变成几万个，成本结构会取代功能清单成为选型的主要依据；而降低成本最直接的手段，往往不是买更便宜的算力，而是不再为闲置的部分付费。这也是它对自建智能体平台团队的启示：先把休眠与恢复这条路径设计好，再谈扩容。