告別Docker：北大開源「迷你沙盒」，無容器也能訓練SWE Agent

本工作來自北京大學王選所趙東巖、張輝帥老師團隊，第一作者為北京大學前沿交叉學院三年級碩士袁旦龍。

AI 編程這么火，想訓練個 SWE Agent 卻沒有資源怎么辦？

最近，軟件工程智能體（后統稱 SWE Agent）由于其清晰的落地場景和巨大的應用價值受到了學術界和工業界的廣泛關注。

然而，當上手訓練 SWE Agent 時，卻發現事情并不簡單。當前 SWE Agent 的訓練都是通過容器（Docker 或 Podman）來實現運行環境的隔離和復現。但是，容器的高昂開銷卻把很多從業者拒之門外。

那么能不能做一個不依賴容器的低成本框架，讓資源不多的從業者也能訓練自己的 SWE Agent 呢？SWE-MiniSandbox 正是在這樣的初衷下開源了～

• 論文標題：SWE-MiniSandbox: Container-Free Reinforcement Learning for Building Software Engineering Agents
• 論文鏈接：https://arxiv.org/abs/2602.11210
• 代碼鏈接：https://github.com/lblankl/SWE-MiniSandbox
• 文檔鏈接：https://lblankl.github.io/SWE-MiniSandbox/
• 鏡像鏈接：https://hub.docker.com/repository/docker/lblankl/swe-minisandbox/general
• 訓練曲線 Demo 鏈接：https://wandb.ai/open_source_blank/SWE-MiniSandbox

SWE-MiniSandbox 是一個無需容器（Container-Free）的軟件工程沙盒環境。其目標是解決當前 SWE Agent 訓練中依賴容器的痛點：需要構建和維護大量的容器鏡像，并運行高性能的容器服務器集群，導致了高昂基礎設施和運維成本。因此，當擴展批量規模或提高 rollout 數量時，容器服務器承載量成為主要性能瓶頸，造成計算資源受限情況下訓練無法擴展，而缺乏容器管理權限或沒有專用編排基礎設施的從業人員則無法訓練自己的 Agent。

與容器環境相對，SWE-MiniSandbox 在實現進程和文件系統隔離的過程中繞過了對容器或重型鏡像的依賴，通過按實例劃分的掛載命名空間（mount namespaces）和基于 chroot 的文件系統隔離機制，為每個實例創建隔離的終端會話和私有目錄。

在此基礎上，SWE-MiniSandbox 實現了一套環境預緩存流水線：構建基于輕量級 Python conda+venv 的混合環境，安裝特定任務的依賴項，并在不同運行間復用壓縮的緩存產物。通過將環境和代碼倉庫打包成緩存，利用基于 Ray 的資源控制和信號量來限制并發解壓，從而實現 I/O 的精細管理。

通過直接與現有核心 SWE 工具集成 ——SWE-Rex（終端管理）、SWE-agent（任務求解）和 SkyRL（可擴展的多節點 RL），SWE-MiniSandbox 成為了 SWE Agent 任務中容器后端的一個無縫、即插即用的替代品。

在實際效果上，SWE-MiniSandbox 使環境緩存大小降低至同類基于容器方法的5%左右，將環境準備時間縮短至容器基線的25%，并且消除了對額外容器服務器的需求。

而在這樣低資源依賴下，該環境在同等數據和參數設置下訓練出的 SWE Agent 和容器環境下訓練出的 Agent 在 SWE-bench Verified 上評測效果相當，可以說，大幅降低了 SWE Agent 的入門門檻。

具體方法

I. 無容器隔離機制（Container-Free Isolation）

核心優化：Chroot + Mount Namespaces + Terminal Isolation

Chroot

• 將每個任務的根目錄（/）重定向到一個獨立的、預先配置好的目錄。
• 任務進程只能訪問該目錄下的文件，形成「虛擬根文件系統」，實現文件系統隔離。例如：任務 A 的根目錄是 /sandbox/A，任務 B 是 /sandbox/B，彼此隔離。

Mount Namespaces（掛載命名空間）

• 每個任務擁有獨立的掛載視圖。可以在不干擾宿主機的情況下，掛載宿主文件系統（如 tmpfs、dev、mnt 等）。
• 混合只讀，可寫掛載模式保證任務間不沖突。

Terminal Isolation（終端隔離）

• 每個任務分配一個獨立的偽終端，通過 SWE-Rex 進行終端會話管理。
• 支持標準輸入 / 輸出、信號傳遞（如 Ctrl+C 中斷），確保交互式執行的完整性。

? 優勢：

• 內核開銷比容器小，速度更快

II. 環境預緩存流水線（Pre-Caching Pipeline）

傳統解決方案

每個任務都需要建立獨立鏡像，并基于 conda 安裝獨立 python 環境

SWE-MiniSandbox 解決方案

1. 構建輕量級 Python 環境（conda+venv）

• 預制不同 python 版本的 conda 環境，每個任務根據需求選擇對應的 conda 版本創建 venv 虛擬環境。
• 僅包含任務所需依賴（如 numpy, requests, pytest 等），體積平均不到 100MB。
• 摒棄直接用 conda（太重，通常 >500MB）。
• 將創建出的 venv 打包成 tar 文件，再次啟動環境時直接解壓加速啟動。

2.I/O 瓶頸管理與并發控制

為解決任務高并發下磁盤隊列擁堵問題，為并發任務總吞吐量設置上界:

SWE-MiniSandbox 通過結合信號量和 ray 資源標簽機制對并發數進行控制。

III. 與現有工具鏈的集成

在 RL 分布式擴展方面，該框架基于 Ray 構建，支持多節點資源分配調度，適應大規模 RL 訓練需求。

實驗效果

I. 更小體積

傳統容器方法需要維護動輒 GB 級的容器鏡像，而 SWE-MiniSandbox 單環境僅需維護 100MB 左右輕量化 venv 緩存。例如在 SWE-smith 數據集上，SWE-MiniSandbox 環境緩存大小僅為傳統容器鏡像的 5%。

II. 相同訓練效果，更快的環境啟動時間

實驗結果顯示 SWE-MiniSandbox 框架的訓練質量（SWE-bench Verified）和傳統 Docker 框架幾乎一致，同時在環境準備時間上僅僅是 Docker 的 25% ，顯著減少了 rollout 的平均時間開銷。

III. 優秀的多節點可擴展性

在多節點訓練中 SWE-MiniSandbox 會被平均分配到各個節點上，因此在負載合理的情況下多節點的平均環境啟動速度和單節點幾乎一致。

IV. 可視化

通過拆解強化學習 rollout 的時間代價并對各部分進行可視化分析，發現 SWE-MiniSandbox 在環境準備時間（藍色）上明顯短于 Docker 環境。

除此之外，使用 1600 條數據在 SWE-Agent-LM-7B 上訓練 200 步后對比 SWE-MiniSandbox 和 Docker 環境的 Reward 曲線，發現二者走勢基本一致，從而進一步驗證了 SWE-MiniSandbox 提供的無容器環境能夠實現和傳統 Docker 環境一致的訓練效果。

未來展望

在 SWE-MiniSandbox 開源基礎上，團隊認為未來有幾個方向可以考慮：

• 在現有自動構建環境基礎上，引入 Agent 工作流，打造適配 SWE-MiniSandbox 框架的環境自動化構建流程，并擴展對更多開源 SWE 數據集的支持。
• 將 SWE-MiniSandbox 的應用生態拓展至更廣泛的任務場景，如 Terminal Bench、Skill Bench 等。
• 優化環境啟動機制，例如基于 BranchFS 實現分支隔離從而避免緩存的解壓拷貝開銷。優化強化學習的訓練機制，通過實現環境啟動與梯度反向傳播的異步重疊等方式，提升訓練效率。