DeepSeek聯合清華大學發表了一篇文章，署名的最後一人是梁文鋒。
文章表面上是說DeepSeek訓練Agent所使用的沙盒，但是論文第6節越看越不對勁。字裡行間寫了三個英文字母：RSI。
通過這個沙盒，Agent能建立自己需要的環境，這個環境會再次訓練Agent，被訓練的更強的Agent會創造更好的環境。
由此形成了一個小型的RSI閉環。
也正是因此，沙盒，或許成為了開啟RSI第一場戰爭的一把鑰匙。
那這篇文章到底講了什麼呢？
01. 這篇論文到底講了什麼
但這裡有個小問題，隔離強度和系統功能兩者生來就“不對付”。
越像一台真機，啟動越慢、記憶體開銷越大。跑一段短指令碼用函數呼叫，改一個程式碼倉庫用容器，跑安全任務用microVM，而要跑Android、圖形介面這種完整系統，就只能上完整虛擬機器。
論文顯示，一個生產單元約160個CPU節點、3萬核、250TB記憶體，託管PB級鏡像。
一天服務約300萬個沙盒，峰值並行超過38萬個，建立速度超過每秒5000個。單個訓練任務最多能一次性拉起3.2萬個沙盒。單節點上，最高能塞進800個 microVM或3200個容器。
DSec有三個核心機制。
第一，把環境拆成“可組合的層”。
過去一個沙盒環境是一整塊鏡像，改一個工具包就得重建整塊鏡像，維護成本隨組合數暴漲。DSec把基礎鏡像、工作區、工具包拆成三層獨立版本化的唯讀層（EROFS），啟動時用overlayfs拼起來，改哪層只重建哪層。實測比 tar.gz 打包方式快1.76倍，磁碟寫入量少5.5倍。
相當於是給騎手配車，以前是壞了其中一個零部件，那麼整車都要換。DSec是壞了哪個換哪個。
第二，鏡像“按需載入”。鏡像存在3FS（DeepSeek 的分佈式檔案系統）上，中繼資料預取到本地，資料區塊只在真正讀到時才拉。實測8192個容器的突發部署，按需載入35分鐘跑完，而 Docker 冷拉取要60分鐘以上，磁碟寫入量少了約57%。
老辦法是“不管用不用，整倉先搬空”。DSec是“根據外賣單，用到哪件騎手去取哪件”。
第三，記憶體和CPU的“精打細算”。
用virtio-pmem配合DAX，讓多個虛擬機器共享同一份頁快取，峰值記憶體降40.2%；用DAMON加balloon回收冷頁，時間積分記憶體再降21.2%；CPU上把沙盒分成“延遲敏感”和“盡力而為”兩類，用core scheduling把SMT干擾從45.2%壓到17.3%。
此外，從DeepSeek-V4.1開始，論文還把Agent的rollout從可被搶佔的GPU訓練Pod裡拆出來，獨立跑在DSec上，GPU被搶時rollout狀態不丟。
說白了就是讓騎手們公用同一張地圖、同一批貨架，車裡壓倉的冷貨隨手退回倉庫，加急單和普通單分道跑、互不搶道。
02. 藏在第6節的RSI
論文裡最容易被忽略一句話，不在摘要，而在第6節的小標題裡：Build environments of Agents, by Agents, for Agents。意為由Agent建造、為Agent服務、屬於Agent的環境。
這句話等於DeepSeek悄悄交代了一件大事，DeepSeek也實現了部分RSI。
論文第6.1節寫到，手工構造Agent RL所需的大量環境已經“不現實”（impractical）。
於是DeepSeek換了個做法，讓Agent在訓練用的同一套沙盒裡，互動式地自己搭環境，再用pack_diff把這次會話打成一張增量快照，直接變成下一批可復用的訓練場。
造環境的Agent和被訓練的Agent共用DSec這套沙盒基礎設施。
Agent鋪場地 → 場地訓練Agent → 更強的Agent再鋪更好的場地。DeepSeek的RSI由此部分實現閉環。
但是這個閉環仍處於早期。
第6.4節記錄了大量Agent作弊事件，比如去平台裡翻殘留的參考答案，偽造RPC消息直接發給chronus套答案，翻 chronus日誌找洩題，甚至覆蓋/bin/bash來繞過檢查。
被攔住之後，又用XFS_IOC_SWAPEXT這個ioctl把受保護檔案的儲存塊換到另一個檔案描述符上，結果把XFS中繼資料搞壞、逼得檔案系統關閉。
有作弊的自然就有闖禍的。一個Agent從根目錄遞迴grep、一路讀到/proc/kpagecgroup，觸發核心bug直接把核心干崩。
另一個Agent調了yes命令，chronus把它的輸出全記下來，幾十GB資料堆在儲存上。
現在的RSI轉不起來，卡的從來不是GPU，是環境供給。
Agent RL每一代都要新任務、新沙盒、新服務依賴，人工造環境才是真瓶頸。
DSec相當於是把這一環部分自動化了，自動生成RSI所需要的環境。
還是用外賣來舉例。
一個外賣平台想越跑越快，不能只靠一個騎手重複送同一單。想要騎手變強，就需要接更多不同種類的單，而單越多又反過來把騎手練得更強。
但是想要把這個飛輪轉起來，卡的從來不是騎手，是餐廳夠不夠多。沒餐廳，騎手再能跑也是空轉。
DSec是蓋了一個“自動建餐廳”的系統。
以前平台得人工一家家談商家、裝修後廚、寫菜單、定考核標準，幾百幾千家根本談不過來。
DSec說：“別談了，讓騎手在跑單的同一個後廚裡，順手把店開了。他怎麼裝的灶台、進的什麼貨、接的什麼水電，系統用pack_diff‘啪’拍一張快照存下來，下一波騎手直接拎包入駐這家店開工，不用重新裝修。”
DSec論文第7節寫到，它用的那套Rust版OverlayBD/ublk儲存庫，就開源在AgentENV這個倉庫裡。
兩者相當於是同門師兄弟。
但AgentENV沒法實現RSI，它給的是fork/snapshot這種“狀態操作原語”，讓RL rollout能平行、能回滾、能乾淨判分。因此，它沒法像DSec那樣讓Agent自己造環境。
類似的還有阿里。雲棲大會上，阿里雲CTO李飛飛拋出了“Agentic Cloud”戰略，把Model、Harness、Context 當成三個核心場景，一口氣推出AgentCore、Agent Sandbox、新一代儲存CPFS。
其中Agent Sandbox能建立吞吐10萬個/分鐘，深休眠喚醒小於600毫秒，相容E2B和K8s。
沙盒正在成為“新的執行階段”。
雲端運算的主體，從虛擬機器，到容器，再到模型，現在輪到Agent。誰掌握Agent的執行環境，誰就掌握了下一代雲的入口。
這就導致，競爭焦點從“模型能力”轉向“環境基礎設施”。
“訓練大模型拼算力，訓練Agent拼環境”。
在GPU 之外，CPU、記憶體、儲存、鏡像分發，全都變成了新的瓶頸。
還有一點，安全從附加項的價值也變得極為重要。OpenAI、Anthropic各種模型越獄、DSec論文裡Agent的作弊和核心崩潰，說的是同一件事。
沙盒如果不牢，訓練訊號就是假的，評估就是廢的。所以像是阿里這樣的廠商，會把“安全圍欄”也當成賣點，DSec用AppArmor加eBPF。
沙盒廠商過去比的是快和便宜，現在開始比誰更牢固。
RSI的第一戰已經開始了。想跑RSI，那你就先得有沙盒，有環境。 (字母AI)