从本地助手到大规模执行平台
这篇文章讨论的是智能体的执行基础设施：如何为大量长期存活、频繁等待又随时唤醒的智能体提供安全环境。它介绍的 Agent Substrate 是可运行于 Kubernetes 的开源运行时，并针对 GKE 优化。
本次阅读先完成了中文翻译，没有展开个人追问。这里沿原文顺序重组要点；右栏是整理时补充的复习题与解释，不是读者在会话中的原话。
规模化暴露的四类约束
原文依次提出四个问题：不可信代码带来的安全边界；命令行、浏览器、文件系统等完整工具环境的供给；评测和强化学习 rollout 引发的大量沙箱创建；以及等待推理、工具和人工反馈时的资源闲置。
因此，平台既要应对执行高峰，也要高效保存大量暂时不执行的会话。
执行层与机器管理分开
原文的总体方案是将智能体执行从机器管理中拆开：执行层管理沙箱生命周期；底层 Kubernetes 管理承载它们的基础设施。执行层组合隔离、预热工作节点、快速激活和闲置挂起，兼容不同智能体执行框架。
原则一：内核隔离与网络控制并行
原文提供 Cloud Hypervisor 微型虚拟机和 gVisor 两条隔离路径，并通过网关控制出入站网络。出口代理还负责在智能体无法直接接触的位置注入凭证。
关键是同时约束代码能触及的宿主机资源，以及它能通过网络访问的外部系统。
原则二：为高频挂起和恢复设计专用路径
专用控制平面负责感知数据的调度，数据平面在预热的工作节点上处理高频状态切换。原文说明快照会写入本地磁盘和 Google Cloud Storage，并给出低于 500 毫秒的恢复时间，以及每秒超过 500 次挂起／恢复激活的指标。
原则三：让等待中的会话释放 CPU 与内存
智能体暂停后，运行状态保存为快照，原来占用的 CPU 和内存可用于其他智能体；新一轮交互到来时再恢复。原文称每台宿主机可容纳超过 1,000 个休眠智能体，并报告约 10 倍计算密度。
这一设计利用的是智能体执行时间与等待时间的差异。
原则四：Kubernetes 管机器，专用数据平面管高频执行
原文指出，每次短工具调用都经过标准 Pod 生命周期，会增加启动和调度开销。Substrate 将高频挂起／恢复放在工作节点的数据平面内，Kubernetes 继续负责节点自愈、扩缩容、集群可靠性和工作节点 Pod 的生命周期。
需要标准 Pod 语义的其他方案仍可并行使用。
GKE 优化：机器供给与共享工作区
Google Cloud 部分介绍自定义 ComputeClasses 对不同机型、Spot 和按需资源池的管理，以及 Axion 处理器的支持。原文报告其沙箱工作负载性价比最高提高 30%，但正文未给出完整比较配置。
对于有状态工作区，可选 Filestore 智能体卷提供 NFS、快速挂载、多读多写和 POSIX 文件锁。
采用案例与可用范围
原文以 Nous Research 的 Hermes 为早期合作案例，强调每个智能体的隔离、访问控制和计算资源节省。文中的 OpenRouter 排名是当时的使用量口径，不等于任务能力评测结论。
发布时的可用范围是：所有 GKE 客户可用于非生产工作负载，生产环境 GA 支持通过白名单提供。实际采用应以部署时的官方文档为准。