GKE Agent Substrate 简介

Agent Substrate 可在 Kubernetes 集群上大规模运行智能体工作负载。它解决了常见的资源低效问题：交互式智能体（例如个人助理和编码智能体）通常大部分时间都在等待用户输入或外部触发。让这些闲置代理持续运行会占用 CPU 和内存，而这些资源本可以分配给活跃的工作负载。

Agent Substrate 通过暂停空闲代理并拍摄代理的活跃内存 (RAM) 和本地文件的快照来解决此问题。当暂停的代理需要再次执行操作时，系统会在不到一秒的时间内将代理的状态恢复到可用的沙盒中。

Agent Substrate 基于 Agent Sandbox 的功能构建，并通过绕过标准 Kubernetes 控制平面的瓶颈来改进 Agent Sandbox。因此，它可以在每台机器上运行更多并发代理，并大幅缩短代理启动时间。

标准 Kubernetes 部署（包括 Agent Sandbox）会将每个代理工作负载与一个专用 Pod 相关联。虽然 Kubernetes 具有高度可伸缩性，但会受到 Pod 的调度吞吐量和启动延迟时间的限制。此外，Kubernetes 不支持休眠 Pod，而让数百万个空闲代理保留在集群中会耗尽 Pod 限制和控制平面内存。为避免为闲置的计算资源付费，您必须关闭 Pod 并在外部存储空间中管理代理状态。Agent Substrate 通过将代理状态与底层 Pod 解耦来解决这些伸缩限制：它将数百万个暂停的代理快照存储在存储空间中，并根据需要将它们恢复到温暖工作器的共享池中。

Agent Substrate 是一款开源系统，可直接部署到您自己的 GKE Standard 集群上。虽然核心项目是在开源 Agent Substrate 代码库中开发的，但 Google 在 substrate-gke 代码库中为符合条件的 Google Cloud 客户提供了 GKE 优化型部署工具和脚本。

Agent Substrate 的优势

您可以使用 Agent Substrate 实现以下目标：

• 安全地运行不受信任的代码：Agent Substrate 会强制执行内核和网络隔离，以便您执行 AI 生成的代码，而不会危及更广泛的基础设施。
• 构建长时间运行的有状态智能体：智能体的工作记忆和文件可在会话之间保留。代理会从暂停的确切位置继续。
• 实时响应请求：当新请求触发暂停的代理时，系统会在极短的时间内恢复代理的状态。
• 降低计算费用：您可以通过在所有代理之间共享工作器沙盒池，在更少的机器上运行更多代理。由于空闲代理会被暂停，并且不使用 CPU 和内存，因此只有在代理主动处理任务时，您才需要支付计算费用。

使用场景

Agent Substrate 旨在以任意规模运行智能体，从数十个到数百万个并发智能体。以下是三个工作负载示例：

• 效率智能体：长期在后台运行的助理，可维持数周的上下文。由于这些助理的大部分时间都用于等待触发，因此在不使用时暂停工作负载可以降低计算费用。
• 临时沙盒：按需提供的隔离环境，用于执行不受信任的 LLM 生成的代码、运行工具调用或分析数据。 由于沙盒可在不到一秒的时间内恢复，因此系统可以为短期任务提供一次性环境，并在执行完成后释放资源。
• 编码智能体：可与开发者进行实时对话，以编写、构建和测试代码的 AI 助理。智能体在沙盒中运行终端命令并修改文件。当智能体处于空闲状态时，系统会将其暂停，直到开发者发送另一条提示。

Agent Substrate 的工作原理

Agent Substrate 基于 Kubernetes 构建，但您无需了解 Kubernetes 即可使用它。Agent Substrate 的核心概念如下：

• Actor：代理的单个运行实例。
• ActorTemplate：用于实例化 Actor 的配置蓝图（定义容器映像、环境变量和计算资源）。
• Worker：安全沙盒，用于运行有效的 Actor。
• WorkerPool：一组预先启动的空闲 Worker，可随时接收 Actor。

由于 Actor 不与特定 Worker 绑定，因此系统可以暂停空闲代理并重新使用释放的计算资源。借助此架构，系统可以在数量有限的机器上运行数百万个代理。

典型的代理生命周期遵循以下步骤：

1. 路由：来自应用的每个传入 API 请求都会指定其目标 Actor。例如，当用户在聊天界面中输入新提示时，您的应用会向管理用户会话的特定 Actor 发送请求。
2. 恢复：如果请求是针对已暂停的 Actor，系统会从 WorkerPool 中声明一个暖 Worker，并将 Actor 的快照恢复到该 Worker 上。
3. 执行：系统将请求路由到此新激活的 Worker，然后 Actor 处理任务。
4. 暂停：当 Actor 完成工作并处于空闲状态时，系统会拍摄 Actor 内存和文件的新鲜快照，将快照保存到存储空间，并将空闲的 Worker 释放回池中。

工作负载隔离和 GKE Sandbox

Agent Substrate 使用 gVisor 或 Cloud Hypervisor 在沙盒中运行每个工作负载，从而将应用代码与宿主机内核隔离开来。Agent Substrate 安装包含适用于工作器的 gVisor 运行时，因此您无需在底层 GKE 节点上配置 GKE Sandbox。

限制和要求

代理 Substrate 有以下限制和要求：

• 集群版本和 Beta 版 API：Agent Substrate 在运行 1.36 版（已启用 Beta 版标志）或 1.37 版及更高版本的 GKE Standard 集群上受支持。低于 1.36 的版本不受支持。此外，GKE 需要 Beta 版 API（podcertificaterequests 和 clustertrustbundles）。如果您在运行版本 1.36 的现有集群上启用这些 API，还必须替换现有节点，以便在这些节点上启用 Pod 证书投影。在 1.37 或更高版本中，无需替换现有节点。
• Workload Identity Federation for GKE：GKE 集群必须启用 Workload Identity Federation for GKE。Agent Substrate 使用 Workload Identity Federation for GKE 向 Google Cloud API（例如用于保存代理快照的 Cloud Storage）进行身份验证。
• 虚拟机系列：
  • 混合 CPU 架构：由于 gVisor 存在已知问题，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 存在以下限制：
  • GKE 的托管式 OpenTelemetry 目前为预览版。
  • 不支持收集器连接器，因此需要使用外部代理计量器进行遥测基准比较。
  • 收集器部署会产生内存缓存开销，该开销会随着大型集群中的 Pod 数量线性增加。
  • GKE 的托管式 OpenTelemetry 不支持 TLS。
• 存储空间：系统需要 Cloud Storage 来保存代理的快照。
• 安装环境：您无法在 Cloud Shell 中安装 Agent Substrate。Cloud Shell 的永久性磁盘存储空间上限为 5 GB，无法提供足够的磁盘空间来完成安装。您必须从具有足够磁盘空间的本地工作站或虚拟机 (VM) 安装 Agent Substrate。

后续步骤

• 了解如何在 GKE 集群上安装 Agent Substrate。

• 在 substrate-gke GitHub 代码库中探索在 GKE 上安装 Agent Substrate 的代码。