對於許多剛接觸 Kubernetes (K8s) 的工程師來說，Pod 是最基本的部署單位。我們習慣於將一個微服務（Microservice）部署在一個或多個 Pod 中，並透過 Service 和 ServiceAccount 來定義其身份與網路權限。然而，當我們將這套邏輯套用到 AI Agent（AI 代理）時，會發現 AI Agent 的行為模式與傳統微服務截然不同。
本文將探討為什麼在 AI Agent 的場景下，我們需要將 Pod 的角色從「部署單位」重新定義為「執行工人（Worker）」。
背景：AI Agent 與傳統微服務的差異
在傳統的雲原生架構中，微服務通常被設計為「持續可用」的狀態。它們啟動後會一直運行，等待請求並回應。但 AI Agent 的工作模式具有以下特點：
生命週期不穩定（Bursty & Short-lived）：一個 Agent 可能在被分配任務時才「喚醒」，執行幾秒或幾分鐘後便進入閒置狀態。 動態擴展（Dynamic Spawning）：為了完成複雜任務，一個主 Agent 可能會臨時產生多個子 Agent（Sub-agents）來平行處理子任務。 非同步等待（Indefinite Pausing）：Agent 在執行過程中可能需要等待人類的審核或批准，這會導致其處於長時間的暫停狀態。
如果我們沿用傳統做法，為每個潛在的 Agent 分配一個專屬的 Pod，將會造成極大的資源浪費，因為大部分時間這些 Pod 都在閒置。
技術演進路徑：從 Pod-per-Agent 到 Agent Substrate
為了在 K8s 上運行 AI Agent，開發社群（如 kagent 專案）嘗試了兩種主要的實作路徑。
方案一：將 Agent 視為一等公民工作負載 (Pod-per-Agent) 最初的簡單做法是將每個 Agent 封裝成一個獨立的 K8s 工作負載，包含自己的 Pod、Service 和 ServiceAccount。
優點： * 強隔離性：利用容器層級實現進程隔離。 * 原生整合：直接使用 K8s 的 ServiceAccount 進行身分驗證與授權。 * 精準控制：可以針對單一 Agent 套用網路策略（Network Policy）和准入控制（Admission Policy）。 * 可觀測性：日誌、指標（Metrics）和追蹤（Traces）能直接對應到特定的 Pod。 缺點：如前所述，面對短暫且爆發性的 Agent 需求，這種一對一的映射關係導致資源利用率極低且調度開銷過大。
方案二：引入控制平面 (Agent Substrate 模式) 為了克服上述問題，Google 提出了 Agent Substrate 概念（並與 Agent Sandbox 配合使用）。這個方案的核心在於：在 Kubernetes 之上建立一個專屬的控制平面。
在這種模式下，K8s 依然負責底層的計算、儲存與網路，但 Agent 的生命週期管理則移交給 Agent Substrate。
核心技術機制與名詞對照 為了讓平台工程師快速理解，Agent Substrate 採用了類比 K8s 的抽象層：
Agent Substrate 概念 K8s 類比 定義與功能 :--- :--- :--- WorkerPool NodePool 一組可用於執行 Agent 的資源池。 Worker Node 對應到 K8s 中的一個單一 Pod，作為實際的執行環境。 ActorTemplate Pod Spec 定義 Agent 如何啟動的宣告式規格。 Actor (Logical Unit) 真正的 AI Agent 邏輯實體。它不是 Pod，而是一個可被調度到 Worker 上的「角色」。
運作流程： K8s 維護一組長久運行（Long-lived）的 Worker Pods。 當有任務到達時，Agent Substrate 將一個 Actor（邏輯 Agent）調度到其中一個 Worker 上。 任務完成後，Actor 可以被暫停、恢復或移除，而底層的 Worker Pod 保持不變，隨即可以承接另一個 Actor。
實際影響與工程挑戰
將 Pod 定位為 Worker 而非 Agent，會帶來一系列連鎖反應，工程師在實作時必須重新考慮以下面向：
身份識別（Identity）的移轉 在傳統模式下，身份綁定在 Pod 的 ServiceAccount 上。但在 Substrate 模式中，一個 Actor 可能在不同的 Worker 之間遷移。因此，身份必須與 ActorTemplate、命名空間（Namespace）、租戶（Tenant）或版本綁定，而非綁定在特定的 Pod 上。
權限與網路策略 存取控制（Access Control）和執行時權限（Runtime Permissions）不能再簡單地依賴 Pod 標籤，而需要定義在 Template 層級，並允許針對單一 Actor 進行覆寫（Override）。
可觀測性與計費（Observability & Billing） 這是最具挑戰的部分。由於執行環境（Pod）與邏輯實體（Actor）不再是一對一，日誌和追蹤記錄必須跟隨「邏輯 Agent」移動。工程師需要建立一套機制，將分散在不同 Worker Pod 中的日誌，重新關聯回同一個 Actor 的生命週期中，才能進行正確的審計與計費。
實務判斷與適用情境
適用情境 大規模 Agent 部署：需要運行數千個但非同步觸發的 Agent。 資源敏感型環境：無法承受為每個 Agent 預留固定記憶體與 CPU 的場景。 複雜工作流：Agent 經常需要產生子 Agent 或長時間等待人工介入。
不適用情境 少數長駐型 Agent：如果你只有幾個固定運行的 AI 服務，傳統的 Pod-per-Agent 模式更簡單且直接。 極高隔離需求：雖然 Agent Sandbox 提供了隔離，但若法律要求物理級別的強隔離，一對一的 Pod 映射仍是較直觀的選擇。
總結
Kubernetes 依然是目前處理大規模推論工作負載與微服務的工業標準，但 Pod 作為「部署單位」的定義在 AI Agent 時代遇到了瓶頸。
最終的工程判斷是：Pod 依然是極其優秀的「執行環境（Execution Environment）」，但它不適合直接作為 AI Agent 的「生命週期抽象（Lifecycle Abstraction）」。透過引入像 Agent Substrate 這樣的中間層，將 Pod 降級為 Worker，我們才能在維持 K8s 強大基礎設施能力的同時，獲得應對 AI Agent 動態特性的靈活性與效率。