告别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 瓶颈管理与并发控制

为解决任务高并发下磁盘队列拥堵问题，为并发任务总吞吐量设置上界:

其中是所有并发任务总 I/O 吞吐量上界，为第个任务消耗的平均 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 实现分支隔离从而避免缓存的解压拷贝开销。优化强化学习的训练机制，通过实现环境启动与梯度反向传播的异步重叠等方式，提升训练效率。

转载请联系本公众号获得授权

投稿或寻求报道：liyazhou@jiqizhixin.com