北京
周三上午，一個SRE打開終端，發現他部署在Kubernetes上的智能體已經自發地調用了十幾個外部API，還順手拉了一回網頁爬蟲。這臺機器上能觸達的所有權限——數據庫憑證、云資源密鑰——那個代理都能用同樣的方式拿起來就用。就好像你只授權了一個前臺幫你收快遞，結果他順路把保險柜也打開了。
這不是假設出來的劇情，而是沒有沙箱隔離時，Agentic工作流必然會遇到的場景。代理的能力邊界一模糊，你的安全邊界也跟著模糊。行業里已經有共識，要讓這些自主行動的程序安全地跑起來，必須給它們劃一塊“隔離區”。問題是，這個隔離區該跑在什么地方，又該由誰來管？
Agent Substrate 給出的答案是：直接把它做到Kubernetes上。不是額外疊一層防護軟件，而是在集群原生能力之上，再造一個專門為代理時代設計的控制平面。它的底層用了Google開發的容器沙箱 gVisor——這也是CNCF下Agent Sandbox項目采用的同一套東西——但在硬件資源管理、延遲控制和工作流編排上，它比原生Kubernetes多走了好幾步。
Kubernetes最擅長的兩件事是編排和把工作節點聚合成CPU、GPU、內存的共享池。但這只是基礎設施層的調度。想要更高效率的資源管理，更低延遲的啟動和恢復，尤其是想要讓“運行智能體”這件事帶上隔離、認證、狀態快照這些能力，K8s的原生Pod、自動擴縮和節點集群依然非常重要，但已經不夠用了。Substrate就卡在這個位置：它不是替代K8s，而是把K8s當作底層引擎，自己在上面搭了一套管理平面。
從內部組成看，Substrate分了四個核心模塊：ate-api-server負責控制面邏輯；atenet-router充當Envoy和DNS路由；valkey存儲狀態；pod-certificate-controller管理證書。此外還有一類叫做atelet的每節點代理（以DaemonSet形式跑在每個工作節點上），它直接管著Worker Pod的啟動、回收，用runsc做檢查點/恢復，并負責把快照流式上傳到你建的GCS存儲桶里。
這些組件之間有一個硬性依賴：Pod證書。按照Google給出的說明，Pod Certificates是Kubernetes v1.34開始引入、v1.35進入Beta的一項原生能力，它能直接給運行中的Pod自動簽發短期X.509 TLS證書。Substrate就靠它來給每一個組件自動輪換mTLS身份。所有系統組件的Pod都會掛載podCertificate卷，以此保證彼此之間的通信是雙向TLS加密且身份可核驗的。
這種設計把一個令開發者頭疼的問題——微服務之間的互信和證書輪換——變成了集群自帶的功能。當你把一個Agent放進來運行時，它從啟動那一刻就帶著短期證書，來不及被濫用。即使你在GKE上跟蹤那篇部署教程去建GCS桶、配網絡策略，每一步也都是在把隔離邏輯寫進基礎設施本身，而不是事后打補丁。
過去大家聊AI安全時，注意力總在模型本身的輸入輸出過濾上。但Agentic場景下，危險的往往是“它能伸手拿到什么”。Agent Substrate的思路等于告訴開發者：別只盯著代理的大腦，要看住它那雙正在到處摸索的手。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
