Scaling Reliable Coding Environments via an Agentic Docker Builder

训练和评测 SWE agent 有一个很容易被低估的前提：仓库必须先能跑起来。在我们做数据 scaling 的过程中，最先遇到的瓶颈往往不是模型能不能修 bug，而是 GitHub 上的仓库能不能被稳定地 Docker build 起来。

依赖声明不完整、系统包缺失、编译链复杂、测试入口不清晰、README 里的环境假设早已过时——这些问题让大量本来有价值的仓库停在了执行之前。

我们做 DockSmith 的出发点就是：环境构建不只是 SWE pipeline 的前置预处理，它本身就是一种核心的 agentic capability。

我们用 agent 来专门解决 Docker building 任务。一方面，它可以把更多静态仓库转化为可执行的 SWE 环境，扩大可训练、可验证数据的规模；另一方面，训练模型成为更好的 Docker builder 时产生的大量 execution-grounded trajectories，本身也是高质量的 agentic supervision。把这些轨迹和 SWE-solving trajectories 一起训练后，Docker building 和更一般的 SWE/terminal 任务都能从中受益。

现在主流的 SWE 数据管线会从 GitHub 收集大量真实 PR 和 issue，然后把仓库、测试和历史修改组织成可执行的训练样本。这个过程的关键不是”下载代码”，而是把一个静态仓库真正变成可运行、可测试、可复现的 Docker 环境。

实际操作下来，这一步非常脆弱：

依赖文件经常缺失或不完整
语言版本、系统库、编译工具链之间容易冲突
CI 配置和本地测试命令往往不一致
测试入口分散在脚本、Makefile、文档和 workflow 各处
不少环境假设只存在于维护者的经验中，没有写进文档

一旦 Docker 环境构建失败，后续的执行反馈、测试验证、轨迹收集都无法进行。大量仓库虽然包含真实的软件工程信号，却因此无法进入可训练数据集。

所以环境构建并不是边角杂务，而是 SWE data pipeline 的核心瓶颈。

DockSmith

DockSmith 的核心思路是：把 Docker 环境构建本身定义为一个可验证、可训练、可迁移的 agentic task。

我们没有让模型一次性生成 Dockerfile 就结束，而是把环境构建做成了一个有执行反馈的多 agent 闭环。整个 pipeline 包含四类 agent：

Context Retrieval Agent —— 读取仓库中的 dependency manifest、CI 配置、build script、测试入口等环境线索。
Dockerfile Agent —— 根据仓库上下文和失败日志生成或修补 Dockerfile。
Eval Script Agent —— 生成实际运行环境、安装依赖和触发测试的 eval script。
Test Analysis Agent —— 执行 Docker build / test，并把原始日志整理成下一轮可用的结构化失败信号。

这四类 agent 在执行反馈下不断迭代：读取更多上下文、修改 Dockerfile、调整 eval script、分析新的失败日志，直到环境能够完成构建并支持后续测试。

在 SWE-Factory 的 pipeline 基础上，我们还加入了两个关键机制：

Loop detection controller：监控 agent 的调用序列和失败模式，一旦发现重复的无效修复就主动打断循环，切换新的修复策略。agent 陷入无效循环是实践中非常常见的问题，这个机制对提升成功率很关键。
Cross-task success memory：复用已经验证成功的 Dockerfile / eval script 组合，让类似仓库可以从过去的成功经验中启动，避免从零开始试错。

最终，我们从真实 GitHub 仓库和带测试验证的 PR 中收集、过滤、压缩出大规模 Docker-building trajectories，训练了一个 30B-A3B 的专用 Docker-building 模型。

不只是”搭环境”

DockSmith 更重要的观点不是”让 Dockerfile 写得更好”，而是把环境构建重新定义为一种可迁移的通用 agent 能力。

一个强 Docker-building agent 需要学会：

读懂仓库结构和构建约定
从不完整的线索中推断依赖关系
决定安装、编译、测试的执行顺序
在长日志中定位关键的失败信号
根据真实执行反馈逐步修复问题
识别重复失败，避免在无效尝试中空转

这些能力不只服务于 Docker 构建。SWE agent 在真实仓库里修 bug、跑测试、分析失败、迭代 patch 时，需要的也是同一套能力。

因此，environment construction supervision 有两层价值：

扩大数据规模：更多仓库可以被构建、执行和验证，更多真实 PR 可以变成可用的训练样本。
训练通用 agent 能力：长链条工具调用、依赖推理、执行规划、failure recovery，这些在 Docker-building trajectories 中自然出现，不需要额外构造。

实验结果

在 Multi-Docker-Eval 上，DockSmith 达到了开源 SOTA：

39.72% Fail-to-Pass
58.28% Commit Rate

其中 Fail-to-Pass 衡量的是环境配置后能否让原本失败的测试通过；Commit Rate 衡量 agent 是否提交了可评测方案，更多反映模型在构建过程中的稳定性和信心。

更值得关注的是混合训练的结果。把 Docker-building trajectories 和 SWE-solving trajectories 混合训练后：

SWE-bench Verified 最多提升 +2.25
SWE-bench Multilingual 最多提升 +2.09
Terminal-Bench 2.0 最多提升 +3.37

不同任务的最佳 mixing ratio 也有差异：

SWE.V / SWE.M 在大约 1:1 的 SWE:Docker token 比例附近效果最好
Terminal-Bench 在 1:0.5 时增益最大

这个结果表明，Docker-building trajectories 带来的不只是”如何写 Dockerfile”的知识。更准确地说，它在教模型一种通用的工作模式：先读懂环境，形成假设，执行验证，从日志中定位失败原因，再调整策略重试。这种基于执行反馈的长链条修复能力，在 SWE 任务和终端操作中同样适用。

SWE 数据反过来也能帮 Docker Build

我们还做了反方向的实验：只用 Docker trajectories 训练，和 Docker + 0.5 SWE 混合训练进行对比。

加入 SWE 数据后，各项指标都有提升：

Docker Building / MDE：34.43 → 35.63
SWE.V：33.50 → 47.45
SWE.M：18.25 → 31.00
Terminal：7.16 → 10.11

这说明 Docker 数据和 SWE 数据不是替代关系，而是互补关系：

Docker 数据强化的是环境理解、依赖推理、执行和恢复能力
SWE 数据强化的是任务级验证、代码修改和 bug-fixing pattern

两类轨迹放在一起训练时，模型学到的不是某一种固定技能，而是更通用的 execution-grounded problem solving。

环境构建不是开始真正任务前必须忍受的一段流程。对 SWE agent 来说，它本身就是真正任务的一部分——而且是被严重低估的那部分。

Citation

@article{zhang2026docksmith,
  title={DockSmith: Scaling Reliable Coding Environments via an Agentic Docker Builder},
  author={Zhang, Jiaran and Ma, Luck and Li, Yanhao and Wan, Fanqi and Qi, Di and Zhao, Xu and Hou, Jieyi and Xie, Zhe and Ren, Mengqiang and Wu, Xin and Huang, Zhewei and Chen, Liangyu and Ma, Yingwei and Han, Qi and Zhang, Xiangyu},
  journal={arXiv preprint arXiv:2602.00592},
  year={2026}
}

DockSmith

不只是”搭环境”

实验结果

SWE 数据反过来也能帮 Docker Build

Links

Citation