Agent Substrate on GKE 可在 Kubernetes 集群上大规模运行智能体工作负载。它解决了常见的资源效率低下问题：交互式智能体（例如个人助理和编码智能体）通常会花费大部分时间等待用户输入或外部触发。让这些非活跃代理持续运行会占用 CPU 和内存，而这些资源本可以分配给活跃工作负载。
GKE 上的 Agent Substrate 通过暂停空闲智能体并创建智能体活跃内存 (RAM) 和本地文件的快照来解决此问题。当暂停的智能体需要再次执行操作时，系统会在不到一秒的时间内将智能体的状态恢复到可用的沙盒中。
Agent Substrate on GKE 基于 Agent Sandbox on GKE 的功能构建，并通过绕过标准 Kubernetes 控制平面的瓶颈，对 Agent Sandbox on GKE 进行了改进。因此，它在每台机器上运行的并发代理数量显著增加，并且大幅缩短了代理启动时间。
标准 Kubernetes 部署（包括 GKE 上的智能体沙盒）会将每个智能体工作负载与专用 Pod 相关联。虽然 Kubernetes 具有高度可伸缩性，但它受 Pod 的调度吞吐量和启动延迟时间的限制。此外，Kubernetes 不支持休眠 Pod，在集群中保留数百万个空闲代理会耗尽 Pod 限制和控制平面内存。为避免为空闲计算资源付费，您必须关闭 Pod 并在外部存储中管理智能体状态。 GKE 上的 Agent Substrate 通过将智能体状态与底层 Pod 分离，解决了这些伸缩限制：它将数百万个暂停的智能体快照存储在存储空间中，并根据需要将其恢复到共享的热工作器池中。
Agent Substrate on GKE 是一个开源系统，可直接部署到您自己的 GKE Standard 集群上。虽然核心项目是在开源 Agent Substrate 代码库中开发的，但 Google 在 substrate-gke 代码库中为符合条件的 Google Cloud 客户提供了经过 GKE 优化的部署工具和脚本。
GKE 上的 Agent Substrate 的优势
您可以使用 GKE 上的 Agent Substrate 实现以下目标：
- 安全运行不受信任的代码：GKE 上的 Agent Substrate 会强制执行内核和网络隔离，以便您执行 AI 生成的代码，而不会危及更广泛的基础设施。
- 构建长时间运行的有状态智能体：智能体的工作记忆和文件会在会话之间保留。智能体会从暂停的确切位置继续。
- 实时响应请求：当新请求触发暂停的代理时，系统会在几分之一秒内恢复代理的状态。
- 降低计算费用：通过在所有代理之间共享工作器沙盒池，您可以在更少的机器上运行更多代理。由于空闲智能体会被暂停，不会使用 CPU 和内存，因此您只需在智能体主动处理任务时支付计算费用。
使用场景
Agent Substrate on GKE 旨在运行任意规模的智能体，从数十个到数百万个并发智能体。以下是三个工作负载示例：
- 生产力智能体：长期后台助理，可维持数周的上下文。由于这些助理大部分时间都在等待触发器，因此在不使用时暂停工作负载可以降低计算费用。
- 临时沙盒：按需提供的隔离环境，用于执行不受信任的 LLM 生成的代码、运行工具调用或分析数据。由于沙盒可在不到一秒的时间内恢复，因此系统可以为短期任务提供一次性环境，并在执行完成后释放资源。
- 编码智能体：与开发者进行实时对话以编写、构建和测试代码的 AI 助理。智能体会在沙盒内运行终端命令并修改文件。当智能体处于空闲状态时，系统会将其暂停，直到开发者发送另一个提示。
GKE 上的 Agent Substrate 的工作原理
Agent Substrate on GKE 基于 Kubernetes 构建，但您无需了解 Kubernetes 即可使用它。GKE 上的 Agent Substrate 的核心概念如下：
- Actor：智能体的单个运行实例。
- ActorTemplate：用于实例化 Actor 的配置蓝图（定义容器映像、环境变量和计算资源）。
- Worker：运行中的 Actor 所在的受保护沙盒。
- WorkerPool：一组预先启动的空闲工作器，随时准备接收 Actor。
由于 Actor 不与特定 Worker 绑定，系统可以暂停空闲智能体，并重复利用释放的计算资源。这种架构使系统能够在有限数量的机器上运行数百万个智能体。
典型的代理生命周期包含以下步骤：
- 路由：来自应用的每个传入 API 请求都会指定其目标 Actor。例如，当用户在聊天界面中输入新提示时，您的应用会向管理用户会话的特定 Actor 发送请求。
- 恢复：如果请求针对的是已暂停的 Actor，系统会从 WorkerPool 中声明一个热 Worker，并将 Actor 的快照恢复到该 Worker 上。
- 执行：系统将请求路由到这个新激活的工作器，Actor 处理任务。
- 挂起：当 Actor 完成工作并进入空闲状态时，系统会为 Actor 的内存和文件创建新的快照，将快照保存到存储空间，并将空的工作器释放回池中。
工作负载隔离和 GKE Sandbox
GKE 上的 Agent Substrate 使用 gVisor 或 Cloud Hypervisor 在沙盒中运行每个工作负载，从而将应用代码与主机内核隔离开来。GKE 上的 Agent Substrate 安装包含适用于工作器的 gVisor 运行时，因此您无需在底层 GKE 节点上配置 GKE Sandbox。
限制和要求
GKE 上的 Agent Substrate 具有以下限制和要求：
- 集群版本和 Beta 版 API：运行 1.36 版（启用了 Beta 版标志）或 1.37 版或更高版本的 GKE Standard 集群支持 Agent Substrate on GKE。1.36 之前的版本不受支持。此外，GKE 还需要 Beta 版 API（
podcertificaterequests和clustertrustbundles）。如果您在运行 1.36 版的现有集群上启用这些 API，则还必须替换现有节点，以便在这些节点上启用 Pod 证书投影。在 1.37 或更高版本中，无需替换现有节点。 - Workload Identity Federation for GKE：GKE 集群必须启用 Workload Identity Federation for GKE。GKE 上的 Agent Substrate 使用 Workload Identity Federation for GKE 向 Google Cloud API 进行身份验证，例如使用 Cloud Storage 保存智能体快照。
- 虚拟机系列：
- 混合 CPU 架构：由于 gVisor 的已知问题，GKE 上的 Agent Substrate 不支持在混合 CPU 架构（例如 E2 机器类型）上运行的通用机器系列。
- 每个 Actor 模板的虚拟机类型统一：不支持在单个
ActorTemplate（用于创建 Actor 的配置蓝图）中混合使用多种虚拟机类型。例如，如果您的集群有两个使用 C4 和 N2 虚拟机的节点池，则ActorTemplate必须包含一个指定单个虚拟机类型（例如 C4）的节点选择器，以防止该模板的 Actor 分布在不同的机器类型中。
- GPU 支持：不支持将 GPU 设备直通到 Actor 容器。指定
nvidia.com/gpu只会将 Pod 放置在启用了 GPU 的节点上，但不会将 GPU 设备传递到 Actor 容器中。此外，gVisor 无法对实时 CUDA 上下文进行快照。 - 网络：
- 出站流量政策：不支持
EgressPolicy规则（按主机名和 IP 地址进行网络控制），包括以下功能：- 默认拒绝规则
- 基于主机名的规则
- 凭据注入
- 打开的连接：智能体暂停时，打开的网络连接（例如数据库会话或与 MCP 服务器的连接）不会保留。您的智能体代码必须在智能体恢复时处理与外部服务的重新连接。
- 出站流量政策：不支持
- 可观测性和托管式 OpenTelemetry：适用于 GKE 的托管式 OpenTelemetry 具有以下限制：
- 不支持收集器连接器，这需要使用外部代理计量器进行遥测基准测试。
- 收集器部署会产生内存缓存开销，该开销会随着大型集群中的 Pod 数量线性扩缩。
- Managed OpenTelemetry for GKE 不支持 TLS。
- 存储：系统需要 Cloud Storage 来保存智能体的快照。
- 安装环境：您无法在 Cloud Shell 中的 GKE 上安装 Agent Substrate。Cloud Shell 的永久性磁盘存储空间上限为 5 GB，无法提供足够的磁盘可用空间来完成安装。您必须从本地工作站或具有足够磁盘可用空间的虚拟机 (VM) 在 GKE 上安装 Agent Substrate。
后续步骤
在 substrate-gke GitHub 代码库中探索在 GKE 上安装 Agent Substrate 的代码。