1. 從標(biāo)題拆解DSec 到底想解決什么問題第一次看到 DeepSeek Elastic Compute (DSec) A Sandbox Infrastructure for Effective Agentic Training at Scale 這個(gè)標(biāo)題我腦子里蹦出來的第一個(gè)念頭是終于有人把 Agentic RL 訓(xùn)練里最臟最累的那塊活兒單獨(dú)拎出來講了。標(biāo)題里三個(gè)關(guān)鍵詞——Elastic Compute、Sandbox Infrastructure、Agentic Training at Scale——每一個(gè)都踩在當(dāng)前大模型后訓(xùn)練post-training最痛的神經(jīng)上。先說 Agentic Training。傳統(tǒng)的 RLHF 或者 PPO 訓(xùn)練環(huán)境基本是靜態(tài)的給一個(gè) prompt模型生成一個(gè)回答reward model 打個(gè)分完事。但 Agentic 場景完全不是這么回事。Agent 要調(diào)工具、要執(zhí)行代碼、要讀寫文件、要跟外部環(huán)境多輪交互每一步的 action 都會(huì)改變環(huán)境狀態(tài)reward 往往是稀疏的、延遲的、甚至帶隨機(jī)性的。這就意味著訓(xùn)練框架必須能同時(shí)跑幾千上萬個(gè)環(huán)境實(shí)例每個(gè)實(shí)例都是一個(gè)獨(dú)立的、隔離的、可執(zhí)行代碼的沙箱。再說 at Scale。小規(guī)模玩 Agentic RL你開幾個(gè) Docker 容器手動(dòng)管管就行了。但一旦上到千卡集群、上萬并發(fā)環(huán)境問題就爆炸了容器生命周期管理、資源碎片、冷啟動(dòng)延遲、狀態(tài)回收、故障隔離、安全邊界……這些在傳統(tǒng)訓(xùn)練框架里根本不是一等公民。DSec 這個(gè)標(biāo)題里的 Elastic Compute 就是在說算力要能像橡皮筋一樣隨訓(xùn)練負(fù)載伸縮環(huán)境要能按需創(chuàng)建、用完即焚。最后是 Sandbox Infrastructure。這個(gè)詞是整篇論文的題眼。Sandbox 不是簡單的 Docker 容器它要滿足幾個(gè)硬性條件強(qiáng)隔離Agent 執(zhí)行的代碼不能污染宿主或其他實(shí)例、快啟動(dòng)RL 訓(xùn)練對 rollout 吞吐極其敏感環(huán)境啟動(dòng)慢一秒整體訓(xùn)練就慢一拍、可觀測要能拿到 Agent 在沙箱里的完整軌跡用于訓(xùn)練、可復(fù)現(xiàn)同樣的 seed 和 action 序列要能復(fù)現(xiàn)同樣的環(huán)境狀態(tài)。這四點(diǎn)缺一個(gè)Agentic RL 的訓(xùn)練效率就會(huì)大打折扣。所以 DSec 的定位很清晰它不是又一個(gè)訓(xùn)練框架而是訓(xùn)練框架底下的環(huán)境執(zhí)行層。你可以把它理解成 Agentic RL 的操作系統(tǒng)——上層是 PPO/GRPO 這類算法下層是物理機(jī)/容器編排DSec 夾在中間負(fù)責(zé)把環(huán)境這個(gè)抽象變成可調(diào)度、可擴(kuò)展、可觀測的實(shí)體。適合讀這篇論文的人我建議是這幾類正在做 Agent 后訓(xùn)練但被環(huán)境管理拖垮的算法工程師、想搞清楚 Agentic RL 工程棧長什么樣的研究者、以及需要給內(nèi)部 Agent 平臺做沙箱隔離的基礎(chǔ)設(shè)施同學(xué)。2. 核心設(shè)計(jì)思路為什么是彈性而不是固定池2.1 傳統(tǒng)沙箱池方案的三個(gè)死穴在 DSec 之前業(yè)界做 Agentic RL 沙箱的主流做法是預(yù)分配容器池訓(xùn)練開始前先起好 N 個(gè)容器訓(xùn)練過程中從池子里借、用完還回去。這個(gè)方案在小規(guī)模下能用但一上規(guī)模就暴露三個(gè)死穴。第一個(gè)死穴是資源錯(cuò)配。Agentic 任務(wù)的執(zhí)行時(shí)間方差極大有的 action 就是查個(gè)表幾十毫秒返回有的 action 要跑一段 Python 做數(shù)值計(jì)算幾秒甚至幾十秒。固定池子里慢任務(wù)會(huì)把容器占死快任務(wù)排隊(duì)等GPU 在旁邊干等著 rollout 數(shù)據(jù)利用率直接掉到 30% 以下。我見過最夸張的案例一個(gè) 8 卡節(jié)點(diǎn)跑 Agentic PPOGPU 利用率長期在 25% 上下晃瓶頸全在環(huán)境側(cè)。第二個(gè)死穴是冷啟動(dòng)稅。容器池?cái)U(kuò)容時(shí)新容器要拉鏡像、裝依賴、初始化運(yùn)行時(shí)。一個(gè)帶完整 Python 科學(xué)計(jì)算棧的鏡像冷啟動(dòng)動(dòng)輒十幾秒。RL 訓(xùn)練里 rollout 是高頻操作每個(gè) step 都要幾千次環(huán)境交互這個(gè)冷啟動(dòng)稅累積起來非?？植?。更麻煩的是Agentic 任務(wù)往往需要帶狀態(tài)的環(huán)境比如一個(gè)持續(xù)運(yùn)行的 REPL不能簡單地用完就殺。第三個(gè)死穴是故障域不隔離。固定池子里一個(gè)容器被 Agent 寫崩了比如 OOM、死循環(huán)、文件系統(tǒng)寫滿可能連帶影響同節(jié)點(diǎn)的其他容器。Agentic RL 里 Agent 會(huì)執(zhí)行任意代碼這種自傷概率遠(yuǎn)高于傳統(tǒng)推理場景。池子越大故障傳播的風(fēng)險(xiǎn)越高。2.2 DSec 的彈性思路按需創(chuàng)建 分層復(fù)用DSec 的核心思路我概括成一句話把沙箱從預(yù)分配的靜態(tài)資源變成按需創(chuàng)建的彈性資源同時(shí)用分層緩存把冷啟動(dòng)成本攤薄。具體拆成三個(gè)機(jī)制。機(jī)制一按需創(chuàng)建On-demand Provisioning。DSec 不再維護(hù)固定大小的容器池而是維護(hù)一個(gè)沙箱模板 快速克隆的能力。訓(xùn)練側(cè)需要環(huán)境時(shí)向 DSec 發(fā)一個(gè)創(chuàng)建請求DSec 在毫秒級從模板克隆出一個(gè)新沙箱。用完即銷毀資源立刻歸還。這樣資源利用率不再受池子大小限制而是跟著實(shí)際負(fù)載走。機(jī)制二分層鏡像與寫時(shí)復(fù)制。冷啟動(dòng)問題的解法是分層基礎(chǔ)層OS 運(yùn)行時(shí)預(yù)烘焙在節(jié)點(diǎn)本地中間層Python 依賴、常用庫做節(jié)點(diǎn)級緩存最上層任務(wù)特定代碼才在創(chuàng)建時(shí)注入。配合寫時(shí)復(fù)制Copy-on-Write克隆一個(gè)沙箱只需要復(fù)制最上層的差異部分啟動(dòng)時(shí)間從十幾秒壓到百毫秒級。這個(gè)思路其實(shí)借鑒了容器鏡像分層的經(jīng)典做法但 DSec 把它用在了 RL 訓(xùn)練的高頻創(chuàng)建場景里。機(jī)制三狀態(tài)快照與恢復(fù)。Agentic 任務(wù)經(jīng)常需要回滾——比如 Agent 走錯(cuò)一步訓(xùn)練算法想從某個(gè)中間狀態(tài)重新 rollout。DSec 支持對沙箱做輕量快照記錄文件系統(tǒng)差異和進(jìn)程狀態(tài)需要時(shí)快速恢復(fù)。這對tree search 類 RL 算法比如 MCTS 增強(qiáng)的 Agent 訓(xùn)練是剛需沒有快照能力樹搜索根本沒法高效實(shí)現(xiàn)。2.3 為什么這個(gè)設(shè)計(jì)對 Agentic RL 特別關(guān)鍵我想強(qiáng)調(diào)一點(diǎn)DSec 的彈性設(shè)計(jì)不是為了彈性而彈性而是被 Agentic RL 的訓(xùn)練特性逼出來的。Agentic RL 的 rollout 有兩個(gè)鮮明特點(diǎn)高并發(fā)同時(shí)幾千個(gè)環(huán)境在跑和高異構(gòu)每個(gè)環(huán)境的執(zhí)行時(shí)間、資源需求、狀態(tài)復(fù)雜度都不一樣。固定池方案在這兩個(gè)特點(diǎn)面前必然低效只有彈性方案才能讓環(huán)境側(cè)跟上 GPU 側(cè)的節(jié)奏。從影響范圍看DSec 這類基礎(chǔ)設(shè)施一旦成熟會(huì)直接改變 Agentic RL 的訓(xùn)練經(jīng)濟(jì)學(xué)?，F(xiàn)在很多團(tuán)隊(duì)不敢上大規(guī)模 Agentic RL不是因?yàn)樗惴ú粫?huì)而是因?yàn)榄h(huán)境成本太高——環(huán)境側(cè)的開銷經(jīng)常是 GPU 開銷的 2 到 3 倍。DSec 把環(huán)境成本壓下來之后Agentic RL 的規(guī)模天花板會(huì)被顯著抬高。這也是為什么我覺得這篇論文值得細(xì)讀它講的不是某個(gè) trick而是整個(gè)訓(xùn)練棧的底座。3. 核心細(xì)節(jié)解析沙箱隔離、調(diào)度與可觀測性3.1 隔離級別怎么選從 namespace 到 microVM沙箱隔離是 DSec 最底層的技術(shù)選擇也是最能體現(xiàn)工程權(quán)衡的地方。隔離級別從弱到強(qiáng)大致有這么幾檔進(jìn)程級隔離namespace cgroup、容器級隔離Docker/containerd、microVM 級隔離Firecracker/Kata、硬件級隔離獨(dú)立物理機(jī)。每一檔的隔離強(qiáng)度、啟動(dòng)延遲、資源開銷都不一樣。DSec 的選擇我理解是分層策略默認(rèn)用容器級隔離對高風(fēng)險(xiǎn)任務(wù)比如 Agent 要執(zhí)行不可信代碼升級到 microVM。為什么不全用 microVM因?yàn)?microVM 啟動(dòng)雖然比虛擬機(jī)快但相比容器還是有幾十毫秒到百毫秒的額外開銷在萬級并發(fā)下這個(gè)開銷會(huì)被放大。而容器級隔離對大多數(shù) Agentic 任務(wù)Agent 執(zhí)行的是訓(xùn)練側(cè)自己寫的工具代碼已經(jīng)夠用。這里有個(gè)實(shí)操細(xì)節(jié)值得說namespace 的粒度選擇。DSec 給每個(gè)沙箱獨(dú)立的 PID namespace、mount namespace、network namespace但共享內(nèi)核。共享內(nèi)核意味著如果 Agent 觸發(fā)了內(nèi)核漏洞理論上可以逃逸。所以 DSec 在容器層之上加了 seccomp 過濾和 capability 裁剪把危險(xiǎn)系統(tǒng)調(diào)用比如ptrace、mount、reboot直接禁掉。這個(gè)組合在隔離強(qiáng)度和性能之間取得了不錯(cuò)的平衡。提示如果你自己在搭 Agent 沙箱別一上來就追求最強(qiáng)隔離。先問清楚 Agent 執(zhí)行的代碼來源——如果是訓(xùn)練側(cè)可控的代碼容器級隔離 seccomp 足夠如果是用戶提交的不可信代碼才需要上 microVM。隔離強(qiáng)度和性能是直接 trade-off 的過度隔離會(huì)讓 rollout 吞吐掉一大截。3.2 調(diào)度器設(shè)計(jì)怎么讓環(huán)境側(cè)不拖 GPU 后腿DSec 的調(diào)度器要解決的核心問題是讓環(huán)境創(chuàng)建/銷毀的延遲對訓(xùn)練循環(huán)透明。理想情況下訓(xùn)練側(cè)發(fā)一個(gè)我要 N 個(gè)環(huán)境的請求DSec 應(yīng)該在訓(xùn)練側(cè)還沒意識到等待的時(shí)候就把環(huán)境準(zhǔn)備好了。這需要調(diào)度器做幾件事。第一是預(yù)測性預(yù)熱。RL 訓(xùn)練的 rollout 請求有很強(qiáng)的周期性——每個(gè) training step 開始時(shí)集中爆發(fā)一批環(huán)境需求。DSec 的調(diào)度器會(huì)根據(jù)歷史負(fù)載預(yù)測下一個(gè) step 的環(huán)境需求提前把模板預(yù)熱到節(jié)點(diǎn)本地。這樣真正創(chuàng)建時(shí)只需要做最上層的克隆延遲極低。第二是親和性調(diào)度。沙箱創(chuàng)建請求會(huì)盡量調(diào)度到已經(jīng)緩存了對應(yīng)鏡像層的節(jié)點(diǎn)上避免跨節(jié)點(diǎn)拉鏡像。這個(gè)思路跟 K8s 的 image locality 調(diào)度類似但 DSec 做得更激進(jìn)它會(huì)把鏡像層緩存作為調(diào)度的第一優(yōu)先級甚至高于 CPU/內(nèi)存的負(fù)載均衡。因?yàn)閷?RL 訓(xùn)練來說環(huán)境啟動(dòng)延遲比節(jié)點(diǎn)負(fù)載均衡重要得多。第三是批量創(chuàng)建與批量銷毀。單個(gè)創(chuàng)建請求的開銷網(wǎng)絡(luò)往返、調(diào)度決策在萬級并發(fā)下不可忽略。DSec 支持批量 API一次請求創(chuàng)建幾百個(gè)沙箱調(diào)度器內(nèi)部并行處理。銷毀同理訓(xùn)練 step 結(jié)束后批量回收避免逐個(gè)銷毀的 overhead。3.3 可觀測性Agent 軌跡怎么完整落盤Agentic RL 訓(xùn)練離不開軌跡數(shù)據(jù)——Agent 在沙箱里做了什么、看到了什么、reward 是多少這些都要完整記錄用于訓(xùn)練。DSec 在可觀測性上做了兩層設(shè)計(jì)。第一層是系統(tǒng)級指標(biāo)每個(gè)沙箱的 CPU/內(nèi)存/IO 使用、生命周期事件、創(chuàng)建銷毀延遲。這些指標(biāo)用于監(jiān)控和調(diào)度決策。第二層是應(yīng)用級軌跡Agent 的每一步 action、環(huán)境返回的 observation、執(zhí)行的命令和輸出。這一層是訓(xùn)練數(shù)據(jù)的來源必須完整、有序、可關(guān)聯(lián)。這里有個(gè)容易踩的坑軌跡落盤的 IO 開銷。如果每個(gè) action 都同步寫盤在高并發(fā)下 IO 會(huì)成為瓶頸。DSec 的做法是異步批量落盤 內(nèi)存緩沖同時(shí)保證崩潰時(shí)最多丟失一個(gè) batch 的軌跡。這個(gè)取舍在訓(xùn)練場景下是合理的——丟一個(gè) batch 的軌跡對訓(xùn)練影響很小但同步寫盤會(huì)拖垮整個(gè) rollout 吞吐。注意軌跡的順序性比完整性更重要。Agentic RL 訓(xùn)練時(shí)如果軌跡的 action 順序錯(cuò)亂reward 分配就會(huì)錯(cuò)位訓(xùn)練直接崩。DSec 給每個(gè)沙箱的軌跡打了單調(diào)遞增的序號落盤時(shí)按序號排序確保訓(xùn)練側(cè)拿到的軌跡是有序的。4. 實(shí)操視角如果我要復(fù)現(xiàn)一套類似的沙箱設(shè)施4.1 技術(shù)選型對照表假設(shè)你現(xiàn)在要從零搭一套 Agentic RL 的沙箱設(shè)施我整理了一張選型對照表把關(guān)鍵維度和常見方案列出來方便你按自己的場景取舍。維度輕量方案中等方案重量方案隔離技術(shù)namespace cgroupcontainerd seccompFirecracker microVM啟動(dòng)延遲毫秒級百毫秒級百毫秒到秒級隔離強(qiáng)度弱中強(qiáng)適用場景可信代碼、快速迭代大多數(shù) Agentic RL不可信代碼、多租戶運(yùn)維復(fù)雜度低中高單節(jié)點(diǎn)密度高高中我的建議是從中等方案起步。containerd seccomp 的組合能覆蓋 80% 的 Agentic RL 場景啟動(dòng)延遲和隔離強(qiáng)度都夠用。等真的遇到不可信代碼或者多租戶需求再局部升級到 microVM。一上來就上 Firecracker運(yùn)維成本會(huì)讓你懷疑人生。4.2 關(guān)鍵參數(shù)計(jì)算并發(fā)數(shù)怎么定沙箱并發(fā)數(shù)不是拍腦袋定的要跟 GPU 側(cè)的 rollout 吞吐匹配。給一個(gè)粗略的計(jì)算框架。假設(shè)你有 8 張 GPU 做訓(xùn)練每個(gè) training step 需要 rollout 出 B 條軌跡每條軌跡平均需要 E 次環(huán)境交互每次交互平均耗時(shí) T 秒。那么單個(gè) step 的環(huán)境側(cè)總工作量是B × E × T秒。如果希望環(huán)境側(cè)不成為瓶頸環(huán)境側(cè)的總并發(fā)能力 C 應(yīng)該滿足C ≥ B × E × T / S其中 S 是單個(gè) step 的期望墻鐘時(shí)間。舉個(gè)例子B1024E10T0.5 秒S30 秒。那么C ≥ 1024 × 10 × 0.5 / 30 ≈ 171。也就是說你至少需要能同時(shí)跑 171 個(gè)沙箱?？紤]到任務(wù)執(zhí)行時(shí)間的方差實(shí)際并發(fā)數(shù)建議留 1.5 到 2 倍余量也就是 250 到 350 個(gè)沙箱。這個(gè)計(jì)算的關(guān)鍵洞察是環(huán)境并發(fā)數(shù)跟 GPU 數(shù)量沒有直接關(guān)系而是跟 rollout 的工作量和時(shí)間預(yù)算有關(guān)。很多團(tuán)隊(duì)按每卡配 10 個(gè)沙箱這種經(jīng)驗(yàn)值來配結(jié)果要么不夠要么浪費(fèi)。按工作量算才是靠譜的。4.3 一個(gè)最小可跑的沙箱創(chuàng)建流程下面給一個(gè)基于 containerd 的最小沙箱創(chuàng)建流程偽代碼級別幫你理解 DSec 這類系統(tǒng)在做什么。# 沙箱創(chuàng)建的核心步驟偽代碼 def create_sandbox(template_id, task_code): # 1. 從模板克隆基礎(chǔ)層節(jié)點(diǎn)本地緩存毫秒級 base local_cache.get(template_id) # 2. 寫時(shí)復(fù)制出可寫層 writable_layer cow_clone(base) # 3. 注入任務(wù)特定代碼 inject_code(writable_layer, task_code) # 4. 配置隔離參數(shù) config { namespaces: [pid, mount, network, ipc], seccomp_profile: agent_default, capabilities: [CAP_NET_BIND_SERVICE], # 最小權(quán)限 memory_limit: 2G, cpu_quota: 200000, # 2 核 } # 5. 啟動(dòng)沙箱 sandbox runtime.start(writable_layer, config) # 6. 注冊到軌跡采集器 tracer.register(sandbox.id) return sandbox這個(gè)流程里第 1、2 步是性能關(guān)鍵路徑必須做到毫秒級。第 4 步的隔離配置是安全關(guān)鍵路徑capability 一定要按最小權(quán)限原則給別圖省事給CAP_SYS_ADMIN那等于沒隔離。4.4 實(shí)操心得三個(gè)我踩過的坑坑一別用 Docker daemon 做高頻創(chuàng)建。Docker daemon 在高頻創(chuàng)建銷毀場景下會(huì)成為單點(diǎn)瓶頸而且它的 API 有全局鎖。DSec 這類系統(tǒng)都是直接對接 containerd 或者更底層的 runtime繞開 daemon。我早期用 Docker SDK 做沙箱池QPS 上到幾百就開始抖換成 containerd 直連后穩(wěn)如老狗?？佣募到y(tǒng)用 overlayfs 要小心 inode 耗盡。overlayfs 的寫時(shí)復(fù)制會(huì)產(chǎn)生大量小文件高頻創(chuàng)建銷毀場景下 inode 消耗極快。我遇到過一次節(jié)點(diǎn) inode 打滿所有沙箱創(chuàng)建全部失敗。解法是給 overlayfs 的 upperdir 單獨(dú)掛一塊盤并且定期清理僵尸沙箱的殘留目錄?？尤W(wǎng)絡(luò)隔離別用默認(rèn) bridge。Docker 默認(rèn)的 bridge 網(wǎng)絡(luò)在幾千個(gè)容器下會(huì)有 ARP 表爆炸和 iptables 規(guī)則膨脹的問題。DSec 這類系統(tǒng)一般用獨(dú)立的 network namespace 輕量 CNI或者干脆讓沙箱共享宿主網(wǎng)絡(luò)但用 seccomp 限制網(wǎng)絡(luò)系統(tǒng)調(diào)用。具體選哪種取決于你的 Agent 是否需要真實(shí)網(wǎng)絡(luò)訪問。5. 常見問題與排查技巧實(shí)錄5.1 沙箱創(chuàng)建慢從請求到就緒的全鏈路排查沙箱創(chuàng)建慢是最常見的問題排查要按鏈路走。我整理了一張速查表?，F(xiàn)象可能原因排查方法解決方向創(chuàng)建延遲 1s鏡像層未緩存跨節(jié)點(diǎn)拉取看節(jié)點(diǎn)本地緩存命中率預(yù)熱模板、親和性調(diào)度創(chuàng)建延遲波動(dòng)大節(jié)點(diǎn)負(fù)載不均看各節(jié)點(diǎn) CPU/IO 水位調(diào)度器加負(fù)載感知批量創(chuàng)建時(shí)部分超時(shí)調(diào)度器單點(diǎn)瓶頸看調(diào)度器 QPS 和延遲調(diào)度器水平擴(kuò)展創(chuàng)建成功但 Agent 起不來依賴缺失或權(quán)限不足看沙箱內(nèi) stderr檢查鏡像層和 capability創(chuàng)建后立即被 OOM kill內(nèi)存 limit 太小看 cgroup 內(nèi)存事件調(diào)大 limit 或優(yōu)化任務(wù)排查的核心思路是分段計(jì)時(shí)把創(chuàng)建過程拆成調(diào)度決策、鏡像準(zhǔn)備、運(yùn)行時(shí)啟動(dòng)、代碼注入四段每段打點(diǎn)看時(shí)間花在哪。我見過最多的瓶頸是鏡像準(zhǔn)備段尤其是跨節(jié)點(diǎn)拉取。解法就是前面說的預(yù)熱 親和性調(diào)度。5.2 軌跡丟失或錯(cuò)亂數(shù)據(jù)側(cè)的排查軌跡問題比創(chuàng)建問題更隱蔽因?yàn)樗灰欢▓?bào)錯(cuò)但會(huì)悄悄毀掉訓(xùn)練。典型癥狀是訓(xùn)練 loss 異常波動(dòng)、reward 曲線不收斂。排查要點(diǎn)檢查軌跡序號連續(xù)性每個(gè)沙箱的軌跡序號應(yīng)該是 1、2、3……連續(xù)的。如果有跳號說明落盤丟了數(shù)據(jù)。檢查 action-observation 配對每個(gè) action 后面應(yīng)該跟一個(gè) observation。如果配對錯(cuò)位說明落盤順序亂了。檢查沙箱 ID 關(guān)聯(lián)軌跡要能正確關(guān)聯(lián)回沙箱和 training step。如果關(guān)聯(lián)錯(cuò)了reward 會(huì)分配到錯(cuò)誤的軌跡上。提示軌跡采集器一定要做端到端校驗(yàn)——訓(xùn)練側(cè)拿到的軌跡條數(shù)應(yīng)該等于環(huán)境側(cè)產(chǎn)生的軌跡條數(shù)。這個(gè)校驗(yàn)看起來笨但能第一時(shí)間發(fā)現(xiàn)數(shù)據(jù)丟失。我在一個(gè)項(xiàng)目里就是靠這個(gè)校驗(yàn)發(fā)現(xiàn)落盤器在高負(fù)載下會(huì)靜默丟數(shù)據(jù)查了三天才定位到是異步隊(duì)列滿了沒做背壓。5.3 資源泄漏沙箱銷毀不干凈怎么辦沙箱銷毀不干凈會(huì)導(dǎo)致資源緩慢泄漏跑幾個(gè)小時(shí)節(jié)點(diǎn)就滿了。常見泄漏點(diǎn)僵尸進(jìn)程、殘留的 mount point、未釋放的 network namespace、overlayfs 的 upperdir 殘留。排查方法是定期對賬節(jié)點(diǎn)上實(shí)際存在的沙箱資源應(yīng)該等于 DSec 記錄的活躍沙箱數(shù)。如果實(shí)際多于記錄說明有泄漏。解法是加一個(gè)兜底清理器定期掃描孤兒資源并強(qiáng)制回收。這個(gè)清理器一定要有因?yàn)樵賴?yán)謹(jǐn)?shù)匿N毀邏輯也可能因?yàn)檫M(jìn)程崩潰、網(wǎng)絡(luò)分區(qū)等原因漏掉。5.4 隔離逃逸安全側(cè)的底線檢查隔離逃逸是低頻但高危的問題。Agentic RL 里 Agent 執(zhí)行的是代碼理論上存在逃逸可能。底線檢查清單seccomp 是否禁掉了ptrace、mount、unshare等危險(xiǎn)調(diào)用capability 是否按最小權(quán)限給有沒有多余的CAP_SYS_ADMIN是否禁用了 privileged 模式內(nèi)核版本是否及時(shí)打了安全補(bǔ)丁是否有沙箱間的網(wǎng)絡(luò)隔離防止橫向移動(dòng)這幾條是底線任何一條不滿足隔離就形同虛設(shè)。我個(gè)人的經(jīng)驗(yàn)是安全配置要做成模板強(qiáng)制項(xiàng)不允許任務(wù)側(cè)覆蓋。否則總有人圖方便把隔離關(guān)掉最后出事。6. 這套設(shè)施對 Agentic RL 生態(tài)的影響6.1 訓(xùn)練經(jīng)濟(jì)學(xué)的改變DSec 這類沙箱設(shè)施最直接的影響是把 Agentic RL 的環(huán)境成本從不可控變成可控。在彈性沙箱成熟之前環(huán)境側(cè)的成本模型是預(yù)分配 N 個(gè)容器無論用不用都占著資源成本是固定的、跟負(fù)載脫鉤的。彈性沙箱之后成本跟實(shí)際負(fù)載掛鉤閑時(shí)資源歸還忙時(shí)按需擴(kuò)展。這個(gè)改變讓 Agentic RL 的規(guī)模天花板顯著抬高。更深遠(yuǎn)的影響是訓(xùn)練迭代速度。環(huán)境創(chuàng)建從十幾秒壓到百毫秒意味著研究者可以更快地試錯(cuò)——改一版 reward 函數(shù)幾分鐘就能看到 rollout 結(jié)果而不是等半小時(shí)。這種迭代速度的提升對 Agentic RL 這種高度依賴實(shí)驗(yàn)的領(lǐng)域價(jià)值可能比單純的成本節(jié)省更大。6.2 對算法設(shè)計(jì)的反向影響基礎(chǔ)設(shè)施的能力會(huì)反向塑造算法設(shè)計(jì)。DSec 支持狀態(tài)快照和快速恢復(fù)之后一些之前因?yàn)楣こ坛杀咎叨鴽]人做的算法變得可行了。比如基于樹搜索的 Agent 訓(xùn)練——MCTS 需要頻繁地前進(jìn)到某狀態(tài)、探索、回滾沒有快照能力根本做不了。再比如多輪交互的 credit assignment——需要精確記錄每一步的環(huán)境狀態(tài)才能把最終 reward 合理分配到中間步驟。我甚至覺得未來 Agentic RL 的算法創(chuàng)新會(huì)越來越多地依賴基礎(chǔ)設(shè)施能力。算法研究者和基礎(chǔ)設(shè)施研究者的邊界會(huì)變模糊——你不懂沙箱怎么工作就沒法設(shè)計(jì)出高效的 Agentic 訓(xùn)練算法。這個(gè)趨勢在 DSec 這類工作出現(xiàn)之后會(huì)越來越明顯。6.3 落地時(shí)的組織建議最后說點(diǎn)落地的組織層面建議。搭這類設(shè)施別讓算法團(tuán)隊(duì)和基礎(chǔ)設(shè)施團(tuán)隊(duì)各干各的。我見過太多案例算法團(tuán)隊(duì)抱怨環(huán)境慢基礎(chǔ)設(shè)施團(tuán)隊(duì)抱怨需求變來變?nèi)?。正確的做法是讓兩邊一起定義接口——環(huán)境創(chuàng)建/銷毀的 API、軌跡數(shù)據(jù)的格式、狀態(tài)快照的語義這些接口一旦定下來兩邊就能并行推進(jìn)。另外先做最小可用版本再逐步加隔離和彈性。一上來就追求 DSec 論文里的完整能力大概率會(huì)陷入過度工程的泥潭。我的建議是先用 containerd 把按需創(chuàng)建 軌跡采集跑通驗(yàn)證訓(xùn)練側(cè)能用起來再逐步加預(yù)熱、快照、microVM 隔離。基礎(chǔ)設(shè)施的價(jià)值在于被用起來而不是在于功能全。我個(gè)人在實(shí)際搭這類系統(tǒng)時(shí)的體會(huì)是最難的不是某個(gè)技術(shù)點(diǎn)而是讓環(huán)境側(cè)和訓(xùn)練側(cè)的節(jié)奏對齊。環(huán)境側(cè)追求穩(wěn)定和隔離訓(xùn)練側(cè)追求吞吐和低延遲這兩個(gè)目標(biāo)天然有張力。DSec 的價(jià)值就在于它把這組張力處理得比較優(yōu)雅——用彈性調(diào)度吸收負(fù)載波動(dòng)用分層緩存壓低延遲用分層隔離平衡安全和性能。這套思路我覺得不只適用于 Agentic RL任何需要大規(guī)模、短生命周期、強(qiáng)隔離執(zhí)行環(huán)境的場景都能借鑒。