Google Cloud 官方於二零二六年十一月六日宣布，將 Agent Substrate、gVisor 與 OpenRL 三個源自 Google 的開源項目捐予雲端原生計算基金會（CNCF），並指三者已獲納入 CNCF Sandbox；同日公布 Agent Substrate 達 1.0，並以 Agent Substrate on GKE 形式正式可用。官方聲稱可把閒置代理工作階段快照還原至五百毫秒內，並以約十倍於標準容器運行時的密度運行數百萬級沙箱。本文已核對 Google Cloud Blog 原文，來源真實性已驗證。

Google Cloud／官方：Agent Substrate、gVisor 與 OpenRL 捐入 CNCF Sandbox——Agent Substrate 1.0 於 GKE 正式可用；閒置代理五百毫秒內還原、密度約十倍

當 AI 工作負載由「人機對話」轉向「代理人連續行動」——提出動作、拉起子代理、在沙箱執行程式或工具呼叫、再把結果餵回模型——底層平台需求已接近當年容器化對編排層的壓力。Google Cloud 於二零二六年十一月六日在官方 Blog 發表《Powering open infrastructure for autonomous agents》，說明把 Agent Substrate、gVisor、OpenRL 捐入 CNCF，並讓 Agent Substrate 1.0 在 GKE 正式可用，意圖以中立治理複製 Kubernetes 年代的開源協作節奏。本文已核對該官方博文，來源真實性已驗證。

一、核心事件：三項目入 Sandbox，Agent Substrate 1.0 上 GKE

技術細節

官方指出，上述三項目於上個月獲 CNCF Sandbox 接納，現正進行社群維護者與獨立建置基建的入駐；其中 gVisor 另標示正邁向 Incubation。同一公告的產品重點是：Agent Substrate 達成 1.0，並以 Agent Substrate on GKE 作為託管能力正式提供；開源碼亦可部署於任何 Kubernetes 叢集，橫跨 CPU、GPU 或 TPU。

三項分工大致如下：

Agent Substrate（1.0／GKE 正式可用）：把有狀態的代理工作階段與身分，從「一直佔用的運算」拆開。代理往往只執行數秒程式或測試，隨即等候模型回合、外部 API 或人類輸入；若每個活躍代理都佔用獨立 Pod，會鎖死記憶體與 CPU，並迫使控制面追蹤海量長駐物件。Substrate 以 Actor（記憶、檔案、離散身分）、Worker（從溫池抽出的可重用執行沙箱）與 Gateway（依 Actor 身分做進出站控管並注入機密，避免金鑰落在代理環境內）組成。代理暫停時，系統把記憶與檔案快照到儲存，Worker 立即退回溫池；下一請求到達時，於 五百毫秒內 把 Actor 還原到任一可用 Worker。官方稱可在約 十倍於標準容器運行時 的密度運行 數百萬 沙箱，並宣稱 1.0 可達每秒逾 五百次 暫停／恢復啟動。公開開發自二零二六年五月起，貢獻者逾一百人；隔離邊界可選 Cloud Hypervisor microVM 或 gVisor，並因跑標準 OCI 容器而可直接搭配 Agent Development Kit（ADK）等代理環境。對不想自管叢集、只要 API 式 microVM 計算的團隊，官方指 Substrate 可與 Agent Compute Engine（Titanium microVM 服務，強調快速休眠與平行環境分叉）互補。
gVisor（捐入 CNCF；邁向 Incubation）：代理人常執行未審核程式與外部套件，標準容器與其他工作負載共用主機 Linux 核心風險偏高。gVisor 以 Go 撰寫的輕量使用者空間應用核心，攔截系統呼叫，使不可信程式不直接對接主機核心。項目於二零一八年由 Google 開源，官方稱每日在 GKE Sandbox 與 Cloud Run 之下運行數百萬沙箱；文中點名 Anthropic、OpenAI 用於圍堵程式執行，Modal、Snowflake、螞蟻集團、騰訊等亦有生產使用。相對預先切好記憶體的虛擬機，gVisor 採容器式資源模型、支援 GPU／TPU 與檢查點／還原，且不需巢狀虛擬化即可在一般 Linux 節點部署。官方強調，捐入 CNCF 有助推動長期卡在單一廠商治理下、上游 Linux 未合併的 I/O 優化補丁；並指螞蟻集團、Modal、Tines 承諾加入維護者行列，OpenAI、騰訊、NVIDIA 繼續貢獻。
OpenRL（早期捐入 CNCF）：把自我託管的 Python 強化學習（RL）後訓練迴圈搬上 Kubernetes，提供 sample、forward_backward、optim_step、save_state 等原語，並標示與 Tinker 相容 API，既有 tinker-cookbook 配方可繼續使用（含 LoRA 與全參數微調）。排程面用 Kubernetes Dynamic Resource Allocation（DRA）切分加速器池；引擎可插拔，文中提及訓練用 PyTorch／AutoModel、取樣用 vLLM，Gemma 與 Qwen 已驗證，TPU 支援在路線圖。OpenRL 亦可搭配由 Red Hat、Google Cloud、IBM Research、CoreWeave、NVIDIA 等發起、近期達 1.0 的 CNCF 分散式推論／RL 項目 llm-d，做前綴感知的多回合 rollout 路由，以及在取樣與訓練之間時間切片共用實體 GPU。官方稱 OpenRL 於二月以研究預覽起步，刻意在設計定型前進入中立治理。

官方並預告十一月九至十二日於鹽湖城 KubeCon + CloudNativeCon North America 設場次與 Google Cloud 展位，並開列入門連結（ate.dev、gvisor.dev、openrl.dev 及 CNCF Sandbox 議題編號等）。

二、技術原理深度解析

這套敘事的核心假設是：代理工作負載的時間結構與傳統長駐微服務不同——「短執行、長等候」佔多數，若用「一代理一 Pod」硬套，成本與控制面都會先垮。Agent Substrate 把「身分與狀態」從「正在燃燒的 CPU／RAM」剝離，類似旅館住房而非自置物業：離開就退房，回來再拿準備好的房間；Gateway 則把機密與進出站政策掛在 Actor 身分上，降低工具呼叫鏈把長期金鑰拖進沙箱的機率。

安全面並非只靠「再多一個容器」：gVisor 提供接近容器密度的核心隔離，microVM 則提供更硬的硬體邊界，Substrate 讓兩種沙箱共用同一套生命週期操作。訓練面則主張「生產沙箱＝RL 環境」：OpenRL 在同一 Kubernetes 池上編排數百萬平行沙箱 rollout，再用 llm-d 減少重複 prefill、回收訓練／取樣交替時的加速器空轉——與 Substrate 回收閒置 CPU／RAM 是同一效率邏輯的兩端。

對架構師而言，可核對的承諾主要是：還原延遲（五百毫秒內）、密度（約十倍）、暫停／恢復吞吐（每秒逾五百次）、以及「跑在任何 Kubernetes／任何雲」的可攜性宣稱；至於實際帳單、配額與多租戶吵雜鄰居效應，仍須以 GKE 正式文件與自身壓測為準。

三、業界影響與開源治理

近月雲端與資安廠商密集把「代理人執行環境、沙箱隔離、執行期治理」產品化；Google 這次選擇把運行時（Substrate）、隔離層（gVisor）與後訓練編排（OpenRL）一併送進 CNCF Sandbox，等於把代理人時代的「Kubernetes 時刻」押在中立基金會治理，而不是只推單一託管功能。對多雲與自建叢集的買家，開源路徑降低鎖定疑慮；對只要託管的團隊，GKE 上的 1.0 GA 提供較短的導入敘事。

競爭面上，其他陣營可能強調瀏覽器／端點掛鈎、Confirm／Block／Kill 執行期攔截，或專有 microVM API；Google 則把密度、還原延遲與 RL 後訓練開源棧綁在同一篇公告。董事會層級應分開評估：Sandbox 捐贈是治理事件，GKE GA 是產品事件——前者影響生態與上游修補速度，後者影響你能否在下個季度把代理沙箱寫進正式架構標準。

四、日常應用場景

1. 開發者與技術團隊

若已在 CI 或編碼代理中大量起沙箱跑測試／工具呼叫，可評估把「閒置即快照、喚醒再掛回」寫進平台標準，避免為每個長對話常開整組 Pod。ADK、有狀態編碼環境與生產力代理若已用 OCI 容器，官方稱可直接跑在 Substrate 之上；同時應把 API 金鑰改由 Gateway 依身分注入，而不是寫進代理工作區。

2. 企業與隱私敏感行業

金融、醫療與持牌機構若允許代理人執行未審核程式，應優先定義隔離邊界（gVisor 對上 microVM）、出站政策與機密保管位置。Substrate 的 Actor 身分模型有助把「哪個代理可碰哪組工具」做成中央強制點；RL／評測管線若需大量平行環境，OpenRL 與 Agent Compute Engine 的分叉／休眠敘事值得納入 PoC，但仍須對接既有 IAM、日誌與資料出境政策。

3. 一般用戶

終端用戶未必直接部署 Substrate；受益點在於產品團隊能以更高密度、更低空轉成本運行代理人功能，從而較早把「可隔離執行」做成預設，而不是為了省錢共用高權限環境。個人開發者亦可關注 ate.dev／gvisor.dev／openrl.dev 的開源進度，在筆電或小型叢集驗證概念。

4. 香港與亞洲市場視角

香港企業正把編程代理人、內部自動化與雲端工作負載一併推進，同時要回應持牌機構對身分、日誌與供應鏈風險的期望。以 Kubernetes 為共通底層、再疊加可攜沙箱運行時，較符合本地多雲與數據主權討論；若團隊同時規劃私有模型託管、代理人工具鏈與落地架構，可參考 YSK Limited 的企業私有 LLM 與 AI 自動化服務（https://ysk.hk/services/ai-automation）。

五、專業評價與潛在考量

優勢

把「狀態／身分」與「運算」拆開，直接對應代理人「短執行、長等候」的成本結構
公開可核對數字：五百毫秒內還原、約十倍密度、每秒逾五百次暫停／恢復、貢獻者逾一百、公開開發自二零二六年五月
gVisor 捐入 CNCF 與維護者擴充敘事，對上游效能補丁與多廠商共建有明確動機
Agent Substrate on GKE 標示正式可用，開源與託管雙軌並行
OpenRL 早期進入中立治理，並點名與 llm-d 1.0、Gemma／Qwen 驗證路徑

需要留意的地方

「數百萬沙箱」「十倍密度」「每秒逾五百次」屬供應商披露的能力宣稱，須以自身工作負載壓測驗證，不宜直接寫進對外 SLA
Sandbox 接納與「捐贈／入駐進行中」並不等於所有項目已完成 CNCF 畢業；gVisor 的 Incubation 仍是路線而非當日事實
OpenRL 相對最年輕（二月研究預覽起），生產就緒度應與 Substrate 1.0 GA 分開評估
文中客戶與合作引用（如 SPIRITT、Nous Research／Hermes、Northflank 等）屬個案敘事
與同月其他 Google Cloud 代理人／資料雲更新（例如 AlloyDB Express、Agentic Data Cloud）題材相近但事件不同，採購評估應避免混為同一預覽包

結語

代理人要安全地「真的去做事」，平台就不能再用長駐容器的成本模型硬撐。Google Cloud 這次把 Agent Substrate、gVisor 與 OpenRL 送進 CNCF Sandbox，並讓 Agent Substrate 1.0 在 GKE 正式可用，等於同時丟出開源治理與託管產品兩張牌：五百毫秒級還原與約十倍密度回應空轉成本，gVisor 與 Gateway 回應不可信程式與金鑰外洩，OpenRL 則把後訓練迴圈拉回同一套 Kubernetes 敘事。香港團隊若正把編碼代理人與內部自動化推向生產，宜先在非生產叢集核對隔離邊界、還原延遲與機密注入模型，再決定是否納入平台標準。需要把私有模型、代理人工具鏈與雲端落地一併規劃時，可參考 YSK Limited 的企業私有 LLM 與 AI 自動化服務：https://ysk.hk/services/ai-automation。

參考來源

Google Cloud Blog（官方主來源）：Open infrastructure for autonomous agents comes to CNCF — https://cloud.google.com/blog/products/containers-kubernetes/open-infrastructure-for-autonomous-agents-comes-to-cncf/
Google Cloud Blog（相關深讀，同主題產品頁）：Agent Substrate available on GKE — https://cloud.google.com/blog/products/containers-kubernetes/agent-substrate-available-on-gke
Google Cloud Blog RSS（發現來源）：https://cloudblog.withgoogle.com/rss/
YSK Limited 企業私有 LLM 與 AI 自動化：https://ysk.hk/services/ai-automation