關於 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 的核心概念如下：

  • 執行者：代理程式的單一執行例項。
  • ActorTemplate：設定藍圖 (定義容器映像檔、環境變數和運算資源)，用於例項化 Actor。
  • 工作人員：安全沙箱，用於執行有效 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 安裝作業包含 Worker 的 gVisor 執行階段，因此您不必在基礎 GKE 節點上設定 GKE Sandbox。

限制與需求

Agent 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 會使用 GKE 適用的工作負載身分聯盟，向 Google Cloud API 進行驗證，例如用於儲存代理程式快照的 Cloud Storage。
  • VM 系列：
    • 混合 CPU 架構：由於 gVisor 有已知問題，Agent Substrate 不支援在混合 CPU 架構 (例如 E2 機型) 上執行的通用機型系列。
    • 每個 Actor 範本的 VM 類型必須一致：系統不支援在單一 ActorTemplate (用於建立 Actor 的設定藍圖) 中混用 VM 類型。舉例來說，如果叢集有兩個使用 C4 和 N2 VM 的節點集區，則 ActorTemplate 必須包含節點選取器，指定單一 VM 類型 (例如 C4)，防止該範本的 Actor 分散到不同機型。
  • GPU 支援：系統不支援將 GPU 裝置傳遞至 Actor 容器。指定 nvidia.com/gpu 只會將 Pod 放置在啟用 GPU 的節點上，但不會將 GPU 裝置傳遞至 Actor 容器。此外，gVisor 無法擷取即時 CUDA 環境的快照。
  • 網路：
    • 輸出政策：不支援 EgressPolicy 規則 (依主機名稱和 IP 位址控管網路)，包括下列功能：
      • 預設拒絕規則
      • 以主機名稱為準的規則
      • 憑證注入
    • 開啟連線：代理程式暫停時，系統不會保留開啟的網路連線 (例如資料庫工作階段或與 MCP 伺服器的連線)。代理程式恢復運作時，代理程式碼必須處理重新連線至外部服務的作業。
  • 可觀測能力和代管 OpenTelemetry：GKE 適用的代管 OpenTelemetry 有下列限制：
    • GKE 適用的代管 OpenTelemetry 目前為預先發布版。
    • 系統不支援收集器連接器，因此需要使用外部 Proxy 計量器進行遙測基準測試。
    • 在大型叢集中，Collector Deployment 會產生記憶體快取負擔，並隨著 Pod 數量線性擴充。
    • GKE 的代管 OpenTelemetry 不支援 TLS。
  • 儲存空間：系統需要 Cloud Storage 才能儲存代理程式的快照。
  • 安裝環境：您無法在 Cloud Shell 中安裝 Agent Substrate。Cloud Shell 的永久磁碟儲存空間上限為 5 GB，不足以安裝。您必須從本機工作站或虛擬機器 (VM) 安裝 Agent Substrate，且該工作站/VM 須有足夠的磁碟空間。

後續步驟