11 月 10 日，鹽湖城，KubeCon 北美站。輝達把 OpenShell 捐給了 CNCF 沙箱——一個給智慧體用的隔離執行時，Apache 2.0 許可。五天前，谷歌把三個專案一起捐了：Agent Substrate、gVisor、OpenRL。
四件東西，沒有一件是模型。三件是籠子，一件是訓練場——都不生產智能，只管智能在哪跑、能碰什麼。
Google 雲端負責 AI 智慧體與基礎設施的產品經理 Brandon Royal 在台上講得很直：任何智慧體都需要被完全隔離，不論是存取工具、操作電腦還是開瀏覽器，「沒有例外」。他把這件事講成了一個帳單問題——智慧體 90% 到 95% 的時間什麼都不幹，在等模型回話，或者在等人點那一下核准。等的時候佔著的 CPU 和記憶體，都是錢。
把這兩件事放在一起，能看出企業 AI 今年真正換的那塊地基：治理的落點，從應用裡的一個審批按鈕，挪到了叢集裡的一個沙箱。
一、一週兩筆捐贈，籠子成了公共設施
谷歌的三個專案是 11 月 5 日宣布捐給 CNCF 沙箱的，一個月前已被接納。Agent Substrate 的 1.0 版本已經在 GKE 上正式可用，谷歌自家的 Gemini Managed Agents 就跑在它上面。
輝達的 OpenShell 晚五天，11 月 10 日在 KubeCon 現場宣布。它做的是核心隔離沙箱，策略用宣告式 YAML 寫，管檔案系統、網路、行程和模型供應商憑證四類存取；憑證只在發往已批准端點的請求裡注入；策略變更在批准之前，先跑一遍形式化驗證，看會不會給出高風險的新權限。
輝達給的說法是：數百家組織用過，不到一年收到數萬條貢獻。專案正在遷往 ai-openshell 組織，遷移期間程式碼和 issue 還留在 NVIDIA 名下。
| 項目 | 捐贈方與時間 | 許可 | 解決什麼 | 當前狀態 |
|---|---|---|---|---|
| 代理基質 | Google，11-05 | 開源 | 有狀態執行時：會話與算力解耦 | 1.0 已在 GKE GA |
| gVisor | Google，11-05 | 開源 | 使用者態核心沙箱 | 已入 CNCF 沙箱 |
| OpenRL | Google，11-05 | 開源 | 在 K8s 上做強化學習後訓練 | 2 月起預覽 |
| OpenShell | NVIDIA，11-10 | Apache 2.0 | 核心隔離＋策略＋認證資訊控制 | 遷往 ai-openshell |
這兩筆捐贈的共同點，是把「智能體怎麼被關住」從一家公司的產品特性，變成了基金會託管的公共件。對採購的意義很直接：過去你只能在 ERP 的審批流裡加一道「確認」，現在你可以要求供應商說明它的智能體跑在哪個執行環境、隔離做到哪一層、策略誰改。
二、95% 的時間在等，等的就是錢
傳統容器的假設是「開機就一直幹活」。為網站後台設計的調度器，碰到智慧體這種負載會很難受：它可能只花半秒執行一條命令，接下來九成以上的時間在等模型回話、等人核准、等下部工具回傳，而手裡還攥著改了一半的狀態，不能隨便關。
不關，資源就一直佔著；關，狀態就丟，下次要重來。多數團隊的做法是留餘量，餘量就是帳單。
Agent Substrate 的解法不複雜：把「智能體會話」和「幹活的計算」拆開。叢集裡維持一小池熱的工作節點，智能體閒置時，把它連同記憶體和檔案系統狀態快照出去、落盤、釋放節點；需要繼續時再恢復回來。
空閒會話恢復時間（Google 自述，GKE 生產環境）；同一套機制下容器密度提升 10 倍
這裡有個容易被忽略的因果：隔離做得越徹底，冷啟動越貴；冷啟動越貴，越沒人敢做隔離。所以「隔離」和「帳單」從來不是兩個問題，是同一個架構決定的兩面。谷歌雲近期還推出了 Agent Compute Engine，把智能體託管單獨做成一個產品位——這說明智能體正在被當成一種新的工作負載類型，而不是「帶了個 API 的應用」。
三、憑據不進沙箱：四層防線，四個問題
谷歌的高級工程師 Benjamin Elder 講得更具體：所有流量都經過一個執行策略、識別身分的網路層，智慧體碰不到任何沒有被明確授權的東西；憑證不給沙箱，「不要把憑證暴露給沙箱，不要讓智慧體碰到憑證」，要做決定就在沙箱外面做，憑證在鏈路上注入。
這句話值得抄下來貼在架構評審的牆上。提示注入之所以危險，不是因為模型會「被騙」，而是因為被騙之後它手裡有憑證、有網路、有寫入權限。把憑證從沙箱裡拿走，攻擊面就從「一把能開門的鑰匙」降級成「一個只能在指定門縫裡遞東西的窗口」。
| 防線 | 這道防線防什麼 | 這批項目怎麼做 | CIO 要問供應商什麼 |
|---|---|---|---|
| 身分 | 誰在呼叫 | 網路層識別身分、執行策略 | 智能體有沒有獨立身份，能不能被單獨停用 |
| 憑據 | 密鑰被讀走、被帶出 | 憑據不進沙箱，在鏈路注入 | 它能拿到哪些憑證，注入點在哪，誰能改 |
| 策略 | 越權動作、策略被悄悄放寬 | 宣告式 YAML，變更前形式化驗證 | 誰能改策略，改完誰批，有沒有驗證記錄 |
| 會話 | 狀態殘留、跨環境漂移 | 閒置快照落盤，按需恢復 | 會話存在哪、存多久、跨不跨境、怎麼清除 |
為什麼要強調「變更前驗證」？因為智能體給自己做的檢查基本不管用。「開源之道」11 月 5 日的日刊引用過兩項研究，裡面有兩個數字：讓智能體預判自己引入的缺陷，漏網率在 6.13% 到 24.53% 之間；讓它判斷自己是否做對，正確率只有 53%。該日刊的結論很克制——自檢幫助很小，核驗的價值來自「不是它自己」。
別把預覽當成可用。OpenRL 今年 2 月才進入 research preview；Agent Substrate 的 API 仍在變動，GPU 支援正在圍繞 Kubernetes 動態資源分配重建，部分 Dynamo 整合還是實驗狀態；輝達同期公開的 NVKE / NVKR 明確標註 public preview、不建議用於生產。用它們做架構驗證可以，寫進 SLA 還早。
這一段對 CIO 的意義是：你審的不是「智慧體聰不聰明」，而是「策略誰能改、改完誰驗證」。這和 ERP 裡寫入操作必須人工確認是同一個問題的兩個層——應用層管「這一筆要不要人點頭」，執行時層管「它根本能不能碰到這個介面」。
四、為什麼是捐，不是賣
谷歌給出的捐贈理由，比技術細節更值得讀。gVisor 要讓 I/O 接近原生 Linux，需要一串宿主機內核補丁；但在「專案由單一廠商擁有」期間，上游 Linux 維護者拒絕合併這些補丁。捐給基金會之後，螞蟻集團、Modal、Tines 加入成為維護者。
「開源之道」在 11 月 7 日的日刊裡把這件事點得很透：這不是因為「相信開放」，而是因為「所有權擋住了合併」——同一份代碼，產權歸屬一換，協作成本就下來了。
這段話對國內做信創和開源選型的團隊同樣成立：一個項目掛著開源許可證，不等於它的關鍵能力能被生態共用。許可證解決「能不能用」，治理結構解決「能不能一起改」。
同期披露的兩個效能數字也值得記一下，但要看清楚是誰測的：OpenRL 在 Harvey 的法律智能體基準（24 個執業領域）上，把 Gemma 4 的準確率從監督微調的約 50% 提到 70%；llm-d 1.0 用前綴快取感知的路由，把 KV 快取命中率從 35% 提到 70%，多輪智能體負載的中位首字延遲下降 70% 到 85%。兩個數字都來自谷歌自家生產負載，屬於廠商口徑，不能直接當你的基線。
三個別搞混：開源不等於免費（運維、升級、合規驗證都是錢）；預覽不等於可用（API 會變）；廠商跑分不等於你的負載（你的提示詞長度、工具數量、並發形態都不一樣）。
給 CIO 的三條
第一，把執行環境寫進採購與驗收清單。不要只問「支援哪些模型、能做哪些場景」，要問四件事：隔離在哪一層、憑證進不進沙箱、策略誰能改、會話狀態存哪。四個問題裡有一個答不上來，這套東西就還停在示範階段。
第二，把「策略變更」當變更管理，不當作配置修改。誰能改、誰批、改完怎麼驗證、回滾要多久——這四項進 CAB 流程。運行時策略的一次放寬，風險和 ERP 裡放開一個權限組是同一量級，但它通常不會走同樣的審批。
第三，用外部核驗，不用自檢。智能體給自己補的測試幾乎不改變漏網率。真正有效的核驗來自另一套權限、另一個人、另一條流水線。
回到開頭那個比喻。籠子這週被開源了，材料、圖紙、鎖芯都擺在了檯面上，誰都能拿去用。但鑰匙不在圖紙裡——它在你的策略變更流程、你的憑據管理和你的審計日誌裡。
資料來源：Google Cloud Blog《Open infrastructure for autonomous agents comes to CNCF》與 Google Open Source Blog《Sandboxing untrusted AI agents at scale》（2026-11-05，含 Agent Substrate 1.0 GA on GKE、gVisor 與 OpenRL 捐贈、Gemini Managed Agents 運行其上）；CNCF 沙箱接納（2026-10，早於捐贈公告一個月）；NVIDIA 於 KubeCon + CloudNativeCon North America（鹽湖城，2026-11-09 至 12）宣布向 CNCF Sandbox 捐贈 OpenShell（2026-11-10，Apache 2.0，宣告式 YAML 策略、憑證僅注入已批准端點、策略變更形式化驗證、遷移至 ai-openshell）；Unite.AI《NVIDIA Donates OpenShell to CNCF and Adds Open-Source AI Factory Tools》（2026-11-10）；AI Frontier Post《Google Cloud's open AI-native Kubernetes stack》（2026-11-10，含 llm-d 1.0 與 OpenRL 基準數據）；「開源之道」日刊（2026-11-07，含捐贈動因、維護者名單與 Foresight-SWE、BOBA 數據）；KubeCon 現場發言經網易號技術報導（2026-11-11）轉述。
資料口徑說明：500 毫秒恢復、10 倍容器密度、KV 快取命中率與首字延遲、Gemma 4 基準提升均為 Google 自述、在其自有生產負載測得，非第三方審計；OpenShell 的「數百家組織、數萬條貢獻」為 NVIDIA 自述；OpenRL 仍為 research preview，NVKE / NVKR 為 public preview 且廠商不建議用於生產。
眾諦資訊（Zodioo）· 企業數位化觀察 · 2026-11-12
