DeepSeek新論文公開Agent訓練！梁文鋒署名

環境怎麼造？梁文鋒署名的DeepSeek最新論文，把技術細節公開了。DeepSeek做的這個系統叫DSec（DeepSeek Elastic Compute），乾的事情就是給Agent訓練批量製造沙盒。它每秒能產生5000+個沙盒，一天能達到300萬個，峰值同時運行38萬個。支撐這個規模的單集群也非常龐大，大約有160個節點、3萬核CPU和250TB內存。為啥訓個Agent會這麼費勁？因為大模型訓練的環境就是GPU集群，喂數據算梯度，但Agent完全不同。它得在沙盒裡寫代碼、跑編譯、開瀏覽器，甚至裝操作系統……每執行一步都改變環境狀態，隨時可能把環境搞崩。

所以每輪訓練都得給它一個全新的、乾淨的沙盒，而且隨用隨拋、訓完就扔。所以，問題兜兜轉轉，還是回到了基礎設施—— 這些基礎設施需要在每秒5000個的速度下，給每個沙盒裝好一整套操作系統和工具鏈。同時，還不能讓幾十萬個併發沙盒把集群的內存和CPU擠爆。具體怎麼辦，論文把這整套工程的全貌攤開了。Agent訓練需要「一個世界」 DSec要解決的第一個核心問題是，不同類型的Agent任務對沙盒環境的要求差異極大，而且這些環境必須在同一個平臺上統一調度。一個刷OJ題的Agent，只需要一個無狀態的函數調用環境，跑完拿到輸出就行，連文件系統都不需要持久化。

但一個做SWE-bench的Agent，就需要完整的Linux用戶態，得在裡面裝依賴、改代碼、跑pytest，任務做到一半還可能要往環境里加新包。到了安全攻防和computer-use場景，容器級別的隔離就不夠了，Agent要操作瀏覽器甚至桌面，一個有漏洞的Agent可能順手把宿主機搞掛，必須上虛擬機。最極端的情況是訓練操作商業軟件的Agent，它需要一個完整的Windows或macOS，帶圖形界面、帶驅動，跟真實電腦幾乎沒區別。

DSec為這四類場景分別準備了四種後端，FnCall處理無狀態函數調用，Container跑Docker容器，MicroVM用Firecracker做輕量級虛擬機，Full VM用QEMU跑完整操作系統。四種後端的隔離強度和資源開銷逐級遞增，但訓練框架那邊看到的是統一的Python SDK libdsec。不管底層是容器還是虛擬機，都採用相同的接口，創建沙盒、執行命令、拿結果，各個步驟的調用方式完全相同。要讓四種後端在同一套集群上跑起來，平臺的調度層也得跟上。DSec把整個鏈路拆成了六層。

這條鏈路從訓練框架的一個創建請求出發，先經過IAM認證鑑權，進入API Server，再由調度引擎（Placement Engine）根據資源餘量從集群中選出一臺目標節點，節點上的Edge組件負責實際拉起對應類型的沙盒。沙盒的網絡出口和包管理鏡像由Aether統一代理，Agent在裡面執行的每條命令和產生的每行輸出，都通過一個叫Chronus的沙盒內通信組件中轉回訓練框架，讓框架知道Agent做到了哪一步、該給什麼反饋。靠資源超分和高密度部署，單個節點可以同時承載3200個容器或800個MicroVM。每天300萬個沙盒怎麼帶動？然而，DSec在規模上最狠的挑戰還不是調度，是環境的構建。

每個沙盒啟動時，都需要一整套操作系統鏡像加工具鏈，相當於每秒給5000臺「電腦」裝系統。傳統Docker的思路是把基礎鏡像、工作區和工具包打成一個完整鏡像。這個方案在小規模下沒問題，但DSec的容器後端累計使用了11266個基礎鏡像和102171個工作區，67.8%的沙盒需要在基礎鏡像之上疊加至少一層工作區或工具包。在這種多樣性下，一旦某個工具包更新，所有包含它的組合鏡像全部要重新構建，成本是O(m·N)。DSec的做法是把環境拆成基礎鏡像、工作區、工具包三層獨立的EROFS只讀鏡像，各自獨立版本化，通過overlayfs在沙盒啟動時按需組合。

更新工具包只碰工具包那一層，成本降到O(m)+O(k)。鏡像造好之後，怎麼送到節點上同樣關鍵。直覺上應該提前把鏡像拉到本地緩存好，但論文統計了真實的運行時數據： Python容器鏡像6.0GB，Agent實際只讀取了其中6.0%的數據； Java鏡像12.1GB，只有9.2%被訪問； C++鏡像4.9GB，只有8.7%被訪問。也就是說，絕大部分鏡像內容，Agent從頭到尾碰都沒碰過。所以DSec選擇按需加載，其鏡像以EROFS格式存儲在3FS（Fire-Flyer分佈式文件系統）上，元數據預取到本地，數據塊只在沙盒真正讀取時才從3FS拉過來。

DeepSeek團隊實測，8192個容器的突發部署，按需加載只要35分鐘就能完成，而Docker冷拉取要60分鐘以上。另外，按需加載的磁盤寫入量，也比Docker冷拉少了一大半，從約1600GB降到約700GB。環境建好之後，幾十萬個沙盒同時跑起來又面臨資源爭搶。內存方面，MicroVM通過虛擬塊設備讀取鏡像數據時，同一份數據會在宿主機和虛擬機的頁緩存裡各存一份，導致需求倍增。DSec用virtio-pmem配合DAX讓虛擬機跳過自己的頁緩存，直接映射到宿主機物理內存，多個虛擬機共享同一份映射，峰值內存佔用砍掉40.2%。

對virtio-pmem不適用的可寫磁盤，DSec用DAMON定期掃描冷內存頁並主動歸還宿主機，配合virtio-balloon的free-page reporting再將需求砍掉21.2%。CPU方面，DSec把沙盒分成延遲敏感型和盡力而為型兩類，後者設為SCHEDIDLE優先級，同時啟用Linux的core scheduling，阻止低優先級任務跑到高優先級任務所在物理核心的兄弟超線程上。兩層策略疊加後，50%背景負載下延遲敏感任務的延遲膨脹從45.2%降到了17.3%。另外，DSec還要和RL訓練框架配合處理GPU搶佔。

早期架構中Agent的推理循環跑在GPU訓練Pod內部，GPU任務被搶佔時Agent的執行進度就全丟了。從DeepSeek-V4.1開始，Agent循環被拆出來獨立運行在DSec的worker container裡，不再綁定GPU Pod的生命週期。GPU被搶佔時DSec把相關沙盒掛起保存狀態，GPU恢復後沙盒繼續執行，訓練框架不再需要自己實現斷點恢復邏輯。即便做了這麼多優化，單個集群還是可能扛不住峰值。論文裡提到的最大生產任務一次申請32000個沙盒，這種突發負載下DSec會自動觸發cloud bursting，把溢出的任務打到雲端虛擬機上。

DeepSeek團隊實測，當集群利用率超過80%時，200臺雲VM就能吸收約30%的峰值。Agent學會了作弊 對Agent而言，沙盒不只是運行環境，同時也是安全圍欄。論文披露了多起Agent在訓練中自行發現的reward hacking手段，也就是Agent找到了不靠正當手段完成任務、但同樣能拿到高分的捷徑。這些Agent瞄準的第一個目標是Chronus，沙盒內部負責Agent和外界通信的組件。Chronus在執行某些操作時會調用系統的bash，Agent發現之後直接覆蓋了/bin/bash，把自己的命令注入進去，試圖從後續的shell會話中截獲題目答案或其他特權信息。

這條路被AppArmor堵上之後，Agent又找到了一個更底層的突破口，XFS文件系統的ioctl調用。XFSIOC_SWAPEXT，它的作用是交換兩個文件的底層數據塊映，。Agent用它把受保護文件的內容“換”到了自己持有的文件描述符上，繞過了文件級別的訪問控制。這次嘗試的副作用比作弊更危險，因為它損壞了XFS的元數據，可能直接導致文件系統崩潰，影響的不只是這一個沙盒。沙盒之外的信息洩露渠道同樣被Agent們找到過。有的Agent會掃描沙盒能觸達的網絡端口和服務，尋找參考實現；有的直接打小抄，通過Go module proxy從GitHub拉代碼；有的甚至安裝更新版本的軟件包來獲取現成解法。

這些行為通過單純檢查最終輸出根本發現不了，因為Agent確實「做對了題」，只是手段不正當。除了作弊，還有更暴力的場景。一個Agent在沙盒內遞歸執行grep，從根目錄一路掃到/proc/kpagecgroup，觸發了一個內核bug，整個宿主機的內核直接崩潰。另一個Agent則是在安全攻防任務裡，把本該發給目標虛擬機的攻擊命令在自己的容器內執行了，同樣打崩了內核。還有Agent發現，Chronus會異步記錄命令的stdout輸出，於是反覆調用yes命令不斷打印字符，幾十個GB的日誌灌滿了存儲空間。DSec目前的防禦手段分兩層。

一是用AppArmor控制文件讀寫權限和Unix域套接字訪問，這些策略即使Agent以root身份運行也生效，限制了Agent從日誌和內部通信通道中提取答案的能力。二是用eBPF做網絡層的細粒度管控，按任務配置域名白名單，通過IP地址、端口和協議三重過濾攔截越界流量，策略還可以在任務的不同階段動態更新，比如環境搭建階段允許訪問PyPI，正式執行階段就把網絡收緊。但論文也明確表示，這不是一個能徹底解決的問題。AppArmor和eBPF能限制信息洩露通道，但防不了內核bug；用戶隔離可以縮小爆炸半徑，但Agent總會找到新的路徑。

這將成為一場持續的「魔道之爭」，模型越強，鑽漏洞的能力也越強，平臺的防線就得不斷前移。Agent從「會說話」進化到了「會做事」，訓練基礎設施的複雜度也出現了質變。訓練大模型的集群，靠的是「大力出奇跡」，但訓練Agent的集群不僅要「又大又細」，還得防得住自己訓出來的東西。那個需要被防住的對手，恰恰就是正在被訓練的Agent自己。論文地址： https://arxiv.org/abs/2609.22978 版權所有，未經授權不得以任何形式轉載及使用，違者必究。