GKE 上的 Agent Substrate 可在 Kubernetes 叢集大規模執行代理工作負載。這項功能可解決常見的資源效率不彰問題：互動式代理 (例如個人助理和程式設計代理) 通常會花費大部分時間等待使用者輸入或外部觸發條件。如果讓這些閒置代理程式持續運作，會耗用 CPU 和記憶體，而這些資源原本可以分配給使用中的工作負載。
GKE 上的 Agent Substrate 可解決這個問題，方法是暫停閒置的代理，並擷取代理有效記憶體 (RAM) 和本機檔案的快照。當暫停的代理需要再次執行動作時，系統會在 1 秒內將代理的狀態還原至可用的沙箱。
GKE 上的 Agent Substrate 以 GKE 上的 Agent Sandbox 功能為基礎，並繞過標準 Kubernetes 控制層的瓶頸，進一步提升 GKE 上的 Agent Sandbox。因此，每部機器可執行的並行代理數量大幅增加，代理啟動時間也大幅縮短。
標準 Kubernetes 部署作業 (包括 GKE 上的代理程式沙箱) 會將每個代理程式工作負載與專屬 Pod 建立關聯。雖然 Kubernetes 具備高度擴充性，但會受限於 Pod 的排程處理量和啟動延遲時間。此外，Kubernetes 不支援休眠 Pod，在叢集中保留數百萬個閒置代理程式會耗盡 Pod 限制和控制層記憶體。為避免支付閒置運算資源的費用，您必須關閉 Pod，並在外部儲存空間管理代理狀態。GKE 上的 Agent Substrate 可將代理狀態與基礎 Pod 分離，解決這些擴充限制：將數百萬個暫停的代理快照儲存在儲存空間中，並視需求還原至共用的暖工作站集區。
GKE 上的 Agent Substrate 是開放原始碼系統，可直接部署至您自己的 GKE Standard 叢集。雖然核心專案是在開放原始碼 Agent Substrate 存放區中開發，但 Google 會在 substrate-gke 存放區中，為符合資格的 Google Cloud 客戶提供 GKE 最佳化部署工具和指令碼。
在 GKE 使用 Agent Substrate 的優點
您可以在 GKE 使用 Agent Substrate，達成下列目標：
- 安全執行不受信任的程式碼：GKE 上的 Agent Substrate 會強制執行核心和網路隔離，因此您可以執行 AI 生成的程式碼，不必擔心更廣泛的基礎架構。
- 建構長時間運作的有狀態代理：代理的工作記憶和檔案會跨工作階段保留。代理會從暫停的確切時間點繼續執行。
- 即時回應要求：當新要求觸發暫停的代理時，系統會在幾分之一秒內還原代理的狀態。
- 降低運算成本：在所有代理程式之間共用 Worker 沙箱集區，即可在較少機器上執行更多代理程式。閒置的代理程式會暫停，不會使用 CPU 和記憶體，因此只有在代理程式主動處理工作時，您才需要支付運算費用。
用途
GKE 上的 Agent Substrate 旨在執行任何規模的代理，從數十個到數百萬個並行代理。以下是三個工作負載範例：
- 效率提升代理：長期在背景運作的助理，可保留數週的脈絡資訊。由於這些助理大部分時間都在等待觸發條件，因此在不使用時暫停工作負載，可降低運算成本。
- 暫時沙箱：隨選、隔離的環境，用於執行不受信任的 LLM 生成程式碼、執行工具呼叫或分析資料。沙箱不到一秒就能還原，因此系統可為短期工作提供拋棄式環境，並在執行完畢後釋出資源。
- 程式設計代理：AI 助理，可與開發人員即時對話，編寫、建構及測試程式碼。代理會在沙箱中執行終端機指令及修改檔案。代理閒置時，系統會將其暫停，直到開發人員傳送其他提示。
Agent Substrate on GKE 的運作方式
GKE 上的 Agent Substrate 是以 Kubernetes 為基礎建構，但您不需要瞭解 Kubernetes 也能使用。GKE 上的 Agent Substrate 核心概念如下：
- Actor：代理的單一執行個體。
- ActorTemplate：設定藍圖 (定義容器映像檔、環境變數和運算資源)，用於例項化 Actor。
- Worker：執行中的 Actor 所在的沙箱，可確保安全。
- WorkerPool：一組預先啟動的閒置 Worker，隨時準備接收 Actor。
由於 Actor 不會繫結至特定 Worker，系統可以暫停閒置的代理，並重複使用釋出的運算資源。這種架構可讓系統在有限數量的機器上執行數百萬個代理程式。
一般代理生命週期包含下列步驟：
- 轉送：應用程式傳入的每個 API 要求都會指定目標 Actor。舉例來說，當使用者在對話介面輸入新的提示時，應用程式會傳送要求，導向管理使用者工作階段的特定 Actor。
- 繼續：如果要求是針對已暫停的 Actor，系統會從 WorkerPool 宣告暖 Worker，並將 Actor 的快照還原至該 Worker。
- 執行：系統將要求轉送至這個新啟用的 Worker，Actor 則處理工作。
- 暫停：Actor 完成工作並進入閒置狀態時，系統會擷取 Actor 記憶體和檔案的新快照，將快照儲存至儲存空間，並將空白 Worker 釋回集區。
工作負載隔離和 GKE Sandbox
GKE 上的 Agent Substrate 會使用 gVisor 或 Cloud Hypervisor，在沙箱中執行各項工作負載，將應用程式程式碼與主機核心隔離。在 GKE 上安裝 Agent Substrate 時，會一併安裝 Worker 適用的 gVisor 執行階段，因此您不必在基礎 GKE 節點上設定 GKE Sandbox。
限制與需求
GKE 上的 Agent Substrate 有下列限制和需求：
- 叢集版本和 Beta 版 API：GKE 上的 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。GKE 上的 Agent Substrate 會使用 Workload Identity Federation for GKE 向 Google Cloud API 進行驗證，例如用於儲存代理快照的 Cloud Storage。
- VM 系列：
- 混合 CPU 架構：由於 gVisor 的已知問題，GKE 上的 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 有下列限制：
- 不支援收集器連接器，因此必須使用外部 Proxy 計量器進行遙測基準測試。
- 部署收集器會產生記憶體快取負擔，在大型叢集中，這項負擔會隨著 Pod 數量線性增加。
- GKE 的 Managed OpenTelemetry 不支援 TLS。
- 儲存空間：系統需要 Cloud Storage 才能儲存代理的快照。
- 安裝環境：您無法在 Cloud Shell 的 GKE 上安裝 Agent Substrate。Cloud Shell 的永久磁碟儲存空間上限為 5 GB，不足以安裝。您必須從本機工作站或磁碟空間充足的虛擬機器 (VM)，在 GKE 上安裝 Agent Substrate。
後續步驟
如要查看在 GKE 上安裝 Agent Substrate 的程式碼，請前往 substrate-gke GitHub 存放區。