AI 代理要在多輪任務裡讀檔、執行命令、呼叫工具，再依回饋修正做法；訓練平台因此得啟動大量隔離環境、保留任務狀態，並滿足不同安全與系統需求。DeepSeek 團隊 2026 年 9 月公開的 DSec 論文，提出整合沙盒執行、映像供應和強化學習訓練生命週期的基礎設施。

一、代理訓練為什麼需要可擴展的沙盒

代理訓練需要隔離、可保留狀態的執行環境，才能讓模型透過實際操作取得任務結果與評分。 任務一多，環境啟動、資源管理和中斷復原就會成為訓練流程的一部分。

代理訓練要看模型能否完成一連串動作，例如修改程式、執行測試、讀取錯誤，再根據結果繼續操作。強化學習會從沙盒中的操作軌跡，依退出狀態、測試結果或任務驗證器計算獎勵，再更新模型。若環境不能忠實執行工具與軟體，訓練回饋就難以代表實際能力。

這些工作階段可能持續安裝依賴、改動檔案、啟動服務，後續操作都依賴累積狀態。論文指出，單一工作可要求最多 3.2 萬個沙盒。代理等待模型生成下一步時，CPU 使用率低，記憶體與檔案狀態仍占用資源；單一執行環境難以同時滿足啟動速度、隔離強度、相容性和成本。

二、DSec 如何整合四種執行後端

DSec 透過同一套 SDK 提供 FnCall、容器、microVM 和完整 VM 四種後端。 呼叫介面相近，但使用者仍要按任務所需的系統功能、隔離程度與啟動成本選擇後端。

統一入口不代表環境完全相同

FnCall 適合短小、無狀態的程式或函式工作，可透過預先準備好的執行程序降低每次呼叫的配置成本。容器啟動快、密度高，適合多數程式碼庫與一般工具操作；但容器共用主機核心，安全敏感的任務可能需要更強隔離。Firecracker microVM 提供 Linux 相容的虛擬機邊界，代價是較高的記憶體占用與啟動成本。完整 VM 則用於需要特定作業系統、圖形介面、Android 或完整系統行為的工作。

DSec 的 SDK 統一建立、操作與回收沙盒的入口，也可設定資源限制、存活時間和網路規則；使用者仍須考量作業系統需求、工作可信度、共享核心風險與隔離成本。microVM 的取捨可參照 Firecracker 原始研究；DSec 整合多種既有機制，並未提出新的虛擬化技術。

分層環境與按需讀取映像

若每種任務都從大型映像複製整套作業系統、程式碼庫和工具，更新一個套件也可能重建許多相似環境。DSec 把基礎系統、工作區和工具包拆成可分別版本管理的唯讀層，建立沙盒時再組合；執行期間的修改落在獨立可寫層。這讓多個任務能共用相同底層，也使工具包更新不必連帶重製其他層。

映像資料存放在 DeepSeek 的分散式檔案系統 3FS，內容按實際存取需求載入。使用者一開始只需要環境中一部分檔案時，不必等整份大型映像下載並解開；可寫入資料留在節點本機，避免小型而頻繁的寫入拖慢遠端儲存。這種做法把啟動與儲存設計一起考慮，也讓網路、檔案系統和節點本機磁碟都成為平台效能的一環。

作業系統、工作區與工具包唯讀層組合成沙盒，執行修改寫入獨立層，檔案由分散式儲存按需載入
唯讀層可供多個任務共用，修改另存於可寫層，檔案則按實際需求載入。

高密度執行也要處理記憶體與 CPU。DSec 透過共享主機頁面快取降低 microVM 重複資料占用，回收來賓系統暫時不用的頁面；CPU 排程則區分延遲敏感工作與可讓步的背景工作。代理等待模型產生下一個決策時，CPU 使用量可能很低，工作環境卻仍需保留。

三、沙盒生命週期如何配合強化學習

DSec 將代理操作流程與可能被中止的 GPU 訓練工作分開執行，再協調沙盒暫停、狀態保存與恢復。 這可以減少訓練資源被回收時，代理已完成的環境操作跟著丟失。

長時間 rollout 中，模型會反覆操作沙盒並累積狀態，GPU 訓練工作卻可能因資源調度而中止。若代理迴圈與訓練程序綁在一起，可能出現環境仍在、代理進度已斷的情況。DSec 將 rollout 移到沙盒平台，由控制元件管理兩邊狀態；訓練暫停時回收閒置資源，之後再恢復仍需繼續的工作階段。

論文也描述由代理協助建立任務環境的流程：代理在互動式沙盒裡配置工作區，透過增量磁碟快照保存成果，再由內部檢查程序驗證及封裝。為降低答案洩漏，環境建置者與實際解題代理使用不同帳號，打包前會清除可寫層中的殘留資料。這顯示環境管理不只關乎算力，也會影響評估是否公平。

代理可能搜尋非預期的答案來源、嘗試讀取日誌，或透過網路取得任務以外的資訊。DSec 使用檔案與通訊端存取控制，以及依任務設定的網路允許清單，限制部分作弊途徑。作者也坦言，這些控制無法阻止所有破壞性行為；系統仍須觀測代理行為並持續修補防線。沙盒能縮小影響範圍，不能讓執行風險消失。

代理在沙盒中執行任務，訓練中止後保存工作狀態並回收閒置資源，之後恢復工作階段
訓練資源暫停或回收時，保存沙盒狀態有助於代理從中斷處繼續工作。

四、論文報告了哪些部署與評估結果

作者報告，單一生產規模部署單元約跨 160 個節點，每日服務約 300 萬個沙盒，最高支援超過 38 萬個同時執行個體，建立速率超過每秒 5,000 個。 這些是研究團隊對自家部署的報告，不等同於其他環境的效能保證。

效能實驗分別檢視映像按需載入、可組合環境層、記憶體最佳化和 CPU 排程。以 10 節點測試環境中的 8,192 個容器突發建立測試為例，作者報告按需載入完成工作約需 35 分鐘，冷啟動的完整映像下載則超過 60 分鐘；按需方式累積磁碟寫入量也比完整下載少約 57%。另一組工作區映像測試比較 tar 解壓與 EROFS 分層掛載，作者報告後者完成時間約 45 分鐘，前者約 79 分鐘。

這些數字須連同測試設定閱讀。效能實驗在獨立的 10 節點 CPU 叢集執行，涵蓋內部軟體工程基準、SWE-bench、Terminal-Bench 和資安任務。作者指出，評估聚焦基礎設施機制，沒有涵蓋與強化學習框架整合的成效。生產部署數字說明作者的運行規模，測試數據則是特定設定下的比較結果，不能直接外推到任意工作負載。

「支援這些工作負載，需要的是彈性執行平台，而不是單一沙盒執行環境。」— Jialiang Huang 等，DeepSeek Elastic Compute（譯自論文摘要）

五、技術團隊該如何評估代理沙盒需求

DSec 的主要啟示是，代理開發工具的評估範圍可能從模型與編排框架，擴大到環境映像、狀態管理、隔離、排程和觀測能力。 是否需要類似平台，仍取決於任務數量、風險與現有基礎設施。

對小型團隊而言，現成容器執行環境或託管沙盒可能已足以支援原型、手動測試和少量代理工作。當任務量增長，或需要執行不可信程式、並行使用多套作業系統與工具鏈時，環境啟動、映像重複、閒置資源與中斷復原的成本才會逐漸顯現。DSec 的案例提醒工程團隊把這些成本列入整體設計；論文沒有證明所有開發團隊都必須自建同等規模的平台。

實際盤點時，可以先把任務分類：每種工作需要哪個作業系統和工具？代理操作是否可信？沙盒要保留狀態多久？任務可否暫停後恢復？啟動時間和資源上限是多少？網路連線必須開放到哪些服務？接著再觀察映像是否常重複、併發尖峰有多高、閒置期間占用多少資源，以及故障時能否從日誌追出原因。這些答案會幫助團隊判斷使用容器、microVM、完整 VM 或多後端平台。

六、研究限制與後續觀察問題

DSec 是一份大型生產平台的系統報告，公開結果仍需依不同工作負載和測試設定驗證。 評估時應留意比較基準、資源配置、實驗是否涵蓋訓練整合，以及外部團隊能否重現結果。

論文聚焦沙盒基礎設施，未完整比較其他商用服務的成本或功能，也未公開重建生產部署所需的全部條件。映像、記憶體和排程結果只反映作者選定的工作負載；隔離漏洞、運維成本、跨雲可攜性和更多代理任務仍待外部驗證。沙盒若執行代理建立的環境，也須檢查狀態清理、答案洩漏、惡意命令和資源耗盡。

後續可追蹤 DSec 是否公開更多實作介面與可重現評估、不同隔離後端在真實代理工作負載下的延遲和費用，以及訓練中斷後恢復狀態對任務正確性的影響。技術團隊可先量測自己的任務組合，再以隔離層級、狀態持久性、啟動延遲、成本和可觀測性作為比較表；當需求量與風險上升時，再判斷是否需要更完整的沙盒平台。

  • DSec 把四類執行後端、映像管理、資源排程與訓練生命週期整合在同一平台。
  • 論文報告的規模與效能來自 DeepSeek 自家部署及特定測試設定，不能直接當成其他團隊的效能預測。
  • 評估代理沙盒時，應先盤點隔離、狀態、啟動時間、資源使用和可觀測性需求。

常見問題

Q1：DSec 是 AI 代理模型或代理開發框架嗎？

DSec 是建立與管理代理執行環境的沙盒基礎設施，並和強化學習流程協調；它不是語言模型或工具編排框架。

Q2：DSec 提供的四種後端有什麼差別？

FnCall 偏向短小、無狀態工作；容器啟動快且密度高；microVM 提供較強的隔離邊界與 Linux 相容性；完整 VM 則支援需要完整作業系統或圖形介面的任務。各後端在隔離、相容性、啟動成本和資源開銷上有取捨。

Q3：論文中的部署數字能代表一般團隊使用 DSec 的預期效能嗎？

不能直接代表。數字是作者對自家生產環境和特定測試叢集的報告，其他團隊需依硬體、映像大小、任務組合、併發量和網路條件自行量測。