Agent Substrate on GKE 简介

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

GKE 上的 Agent Substrate 允许应用暂停空闲智能体，从而解决了这个问题。当应用暂停代理时，系统会创建代理的活跃内存 (RAM) 和本地文件的快照。当暂停的智能体需要再次执行操作时，系统会在一秒内将智能体的状态恢复到可用的沙盒中。

Agent Substrate on GKE 以 Agent Sandbox on GKE 的功能为基础，并通过绕过标准 Kubernetes 控制平面的瓶颈，对 Agent Sandbox on GKE 进行了改进。因此，与 GKE 上的 Agent Sandbox 相比，GKE 上的 Agent Substrate 每台机器可运行更多并发智能体，并且启动智能体的速度更快。如需比较 GKE 上的 Agent Substrate 与 GKE 上的 Agent Sandbox，并为 AI 智能体工作负载选择架构，请参阅为 GKE 上的 AI 智能体工作负载规划架构。

标准 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 的工作原理

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

  • Actor：智能体的单个运行实例。
  • ActorTemplate：用于实例化 Actor 的配置蓝图（定义容器映像、环境变量和计算资源）。
  • Worker：运行活跃 Actor 的沙盒。
  • WorkerPool：一组预先启动的空闲工作器，随时准备接收 Actor。

由于 Actor 不与特定工作器绑定，因此系统可以重复使用 Actor 在应用将其挂起时释放的计算资源。这种架构使系统能够在有限数量的机器上运行数百万个代理。

典型的代理生命周期包含以下步骤：

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

工作负载隔离和 GKE Sandbox

GKE 上的 Agent Substrate 使用 gVisor 或 Cloud Hypervisor 在沙盒中运行每个工作负载，从而将应用代码与主机内核隔离开来。GKE 上的 Agent Substrate 安装包含其自己的 Worker gVisor 运行时。请勿在运行 Agent Substrate on GKE 的节点池上启用 GKE Sandbox，因为 Agent Substrate on GKE 无法在这些节点上运行。您仍然可以将 GKE Sandbox 用于其他工作负载，包括 GKE 上的 Agent Sandbox。

限制和要求

GKE 上的 Agent Substrate 具有以下限制和要求：

  • 集群模式、版本和发布渠道：GKE 上的 Agent Substrate 支持控制平面和节点池运行 1.37 或更高版本的 GKE Standard 集群。不支持 Autopilot 集群和 1.37 之前的版本。在 1.37 版及更高版本中，GKE 会提供 podcertificaterequests 和 clustertrustbundles Kubernetes API，并允许节点将 Pod 证书和信任包装载到 Pod 中，因此您无需自行启用这些 API 的 Beta 版。不过，安装程序会在其创建或配置的每个集群中启用 Beta 版。由于扩展发布渠道不支持明确启用的 Beta 版 API，因此您无法将安装程序与在扩展发布渠道中注册的集群搭配使用。

  • Workload Identity Federation for GKE：GKE 集群必须启用 Workload Identity Federation for GKE。GKE 上的 Agent Substrate 使用 Workload Identity Federation for GKE 向 Google Cloud API 进行身份验证，例如使用 Cloud Storage 保存代理快照。为了保存和恢复快照，系统会使用名为 ate-snapshot-transfer 的专用服务账号。每次保存或恢复操作的凭据只能访问一个 Actor 的快照。因此，您无需向 GKE 节点授予对快照存储桶的访问权限。安装程序会创建 ate-snapshot-transfer 服务账号，并向其授予对快照存储桶的访问权限。如果您自行设置权限，请授予以下 IAM 角色：

    • 在快照存储桶上，向 ate-snapshot-transfer 服务账号和 ate-api-server Kubernetes 服务账号授予 Storage Object Admin (roles/storage.objectAdmin) 和 Storage Bucket Viewer (roles/storage.bucketViewer) 角色。
    • 在 ate-snapshot-transfer 服务账号上，向 ate-api-server Kubernetes 服务账号授予 Service Account Token Creator 角色 (roles/iam.serviceAccountTokenCreator)。ate-api-server 服务账号会模拟 ate-snapshot-transfer 服务账号，为每个 Actor 颁发凭据。
    • 如果您使用 microVM 运行时，请向 atelet Kubernetes 服务账号授予资源存储桶的 Storage Object Viewer 角色 (roles/storage.objectViewer)。

    如需查看绑定和等效 gcloud 命令的完整列表，请参阅 setup-gcp README 中的 create iam 实际授予的内容。

  • 虚拟机系列：

    • 混合 CPU 架构：由于 gVisor 中存在已知问题，GKE 上的 Agent Substrate 不支持在混合 CPU 架构（例如 E2 机器类型）上运行的通用机器系列。
    • 每个 Actor 模板的虚拟机类型统一：您通过一个 ActorTemplate 创建的所有 Actor 都必须在同一虚拟机类型上运行。ActorTemplate 不是 Kubernetes 资源，也没有节点选择器。相反，ActorTemplate 的 workerSelector 字段会按标签选择 WorkerPool 资源。每个 WorkerPool 都可以使用其 spec.template.nodeSelector 字段为其工作器选择节点。例如，如果您的集群具有使用 C4 虚拟机和 N2 虚拟机的节点池，请将每个 WorkerPool 配置为仅选择一种虚拟机类型的节点。然后，设置 ActorTemplate 的 workerSelector 字段，使其仅匹配使用 C4 虚拟机的 WorkerPool 资源。
    • 适用于 microVM 运行时的嵌套虚拟化或裸机：microVM 运行时在自己的虚拟机中运行每个沙盒，因此使用此运行时的 Worker 需要能够运行虚拟机的节点。这些节点必须使用 x86 CPU 架构，而不是 Arm。安装程序创建集群时，它创建的节点池会启用嵌套虚拟化。如果您在现有集群中的 GKE 上安装 Agent Substrate，或为 microVM Worker 添加自己的节点池，请使用已启用嵌套虚拟化或使用 x86 裸金属机器类型的节点池。您只能在创建节点池时启用嵌套虚拟化。如需查看哪些机器系列支持嵌套虚拟化（例如 C3、C4、N2 和 N4），请参阅机器系列比较。

  • GPU 支持：不支持将 GPU 设备直通到 Actor 容器。指定 nvidia.com/gpu 只会将 Pod 放置在启用了 GPU 的节点上，但不会将 GPU 设备传递到 Actor 容器中。此外，gVisor 无法对实时 CUDA 上下文进行快照。

  • 打开的网络连接：智能体暂停时，打开的网络连接（例如数据库会话或与 MCP 服务器的连接）不会保留。您的智能体代码必须在智能体恢复时处理与外部服务的重新连接。

  • 可观测性和托管式 OpenTelemetry：适用于 GKE 的托管式 OpenTelemetry 具有以下限制：

    • 不支持收集器连接器，这需要使用外部代理计量器进行遥测基准测试。
    • 收集器部署会产生内存缓存开销，该开销会随着大型集群中的 Pod 数量线性扩缩。
    • Managed OpenTelemetry for GKE 不支持 TLS。

  • 存储：GKE 上的 Agent Substrate 使用以下 Cloud Storage 存储桶，如果这些存储桶不存在，安装程序会创建它们：

    • 快照存储桶：存储集群中所有代理的快照。此存储桶为必填项。
    • 素材资源存储桶：存储 microVM 运行时所需的文件，例如 Linux 内核和根文件系统。microVM 运行时使用这些文件在各自的虚拟机中运行每个沙盒。此存储桶的名称是快照存储桶的名称，后跟 -assets。例如，如果您的快照存储桶名为 example-snapshots，则资源存储桶名为 example-snapshots-assets。如果您不使用微虚拟机运行时，此存储桶将保持为空。

  • 高沙盒密度的内核设置：在一个节点上运行大约 800 个以上的并发沙盒会超出 Linux 内核中文件系统监控 (inotify) 和地址解析协议 (ARP) 邻居表的默认限制。如果没有更高的限制，沙盒可能无法启动，网络可能会停滞。安装程序会将所需的内核设置应用于其创建的集群。如果您在现有集群中的 GKE 上安装 Agent Substrate，或添加自己的节点池，则必须自行应用这些设置。如需了解所需值，请参阅集群要求和为 GKE 上的 Agent Substrate 设计基础设施。

  • 安装环境：您无法在 Cloud Shell 中的 GKE 上安装 Agent Substrate。Cloud Shell 的永久性磁盘存储空间上限为 5 GB，无法提供足够的磁盘可用空间来完成安装。您必须从具有足够磁盘可用空间的本地工作站或虚拟机 (VM) 在 GKE 上安装 Agent Substrate。

后续步骤