DockSmith: Scaling Reliable Coding Environments via an Agentic Docker Builder

1.4 论文自述的"environment construction 是 agentic capability"论证链

论文 §1 的论证逻辑值得拆开看,因为这是它和单纯"做个 SOTA"工作的区别:

1. Premise A:装环境本身是 long-horizon reasoning + tool use + failure recovery;
2. Premise B:这些技能正好是 SWE/Terminal agent 的核心 capability;
3. Hypothesis:那么用 Docker-building trajectory 训练应该会 transfer 到下游 SWE/Terminal 任务;
4. Empirical evidence:Table 8 显示 Docker:SWE 混训在 1:0.5–1:1 时,SWE.V/SWE.M/Terminal 全都涨,Terminal 涨最多 (+3.37 pp)。

这个 thesis 其实和 #29 EnvTuning(ICLR 2026)的"环境维度才是 agent 训练的真信号"互为镜像:EnvTuning 说"tune env 不 tune agent",DockSmith 说"把 env 构建当 agent 训练目标"。两者都是把 environment 当核心 supervision 源,只是切入角度相反。

2 · 方法 — DockSmith pipeline 全景

2.1 完整管线:三阶段 + 两扩展

2.2 Phase ① Data Sourcing — 三步过滤

2.3 Phase ② SWE-Factory pipeline + 两扩展

2.3.1 SWE-Factory 4 个专门 agent(继承)

2.3.2 [扩展 1] Loop-Detection Controller

论文 §2.2 原文:

"In practice, iterative multi-agent repair may devolve into a repetitive failure mode where the same subset of agents is invoked without measurable progress. We introduce a loop-detection controller that monitors recent agent-invocation traces alongside execution failure signatures. When repeated activation of an identical agent combination fails to improve outcomes for several rounds, the controller intervenes by enforcing diversification — such as activating alternative agents or strategies — to break deadlocks and reduce wasted iterations."

2.3.3 [扩展 2] Cross-Task Success Memory Pooling

论文 §2.2 原文:

"SWE-Factory maintains a memory pool of validated environment solutions. We augment this mechanism to support cross-task retrieval, enabling previously verified (Dockerfile, eval script) pairs to serve as lightweight demonstrations for new repositories."

注意三点细节:

• SWE-Factory 原版有 success memory,但只在同一任务内复用(per-task);
• DockSmith 把它扩成跨任务 retrieval — 即另一个 repo 的成功 Dockerfile 可以被 retrieve 来当 in-context demo;
• 论文没说 retrieval 用 BM25 / embedding / 还是 metadata match — 推测是简单的 metadata + 关键依赖签名匹配,因为 §1 强调"verified (Dockerfile, eval script) pairs to serve as lightweight demonstrations" — 这种 demo 注入是 prompt-level 而非权重 level。

2.4 Phase ③ Model Training — SFT only,no RL

2.4.1 Cross-Language Balancing

原文观察: 长尾语言(Rust / PHP)indiscriminate upsampling 会引起 distribution shift 反而劣化。因此采用保守平衡:保留主流语言(Python / C/C++)的核心分布,长尾在 per-language token 限额下 controlled 加入。

2.4.2 Trajectory Filtering(Acceptance Shaping)

把以下三类轨迹删掉:

• 反复调用同一 agent module 的 — 这是浪费 token + 把 noise 喂给 SFT 的元凶;
• turn 数过多的;
• message 累积过多的。

2.4.3 Complexity-Based Curriculum Sampling

这是论文里唯一的公式(eq. 1):

• L(d) — Dockerfile 非空行数
• R(d) — RUN 指令数(权重 ×5 最重)
• P(d) — 通过 apt-get / apt install 装的 distinct 包数(权重 ×3)

论文解释为什么 R/P 权重大:"additional build steps and dependencies typically introduce more failure modes and longer error chains than Dockerfile length alone"。然后按这个 Score 分 Easy/Medium/Hard,用 1:2:2 比例采样 — 故意让训练接触更多硬实例。

2.4.4 Joint Training with Coding Trajectories

这是论文 §2.3.2 提的关键 trick: 在 Docker traj 旁边混入 Nex Agent-SFT 数据集(Cai et al., 2025 - arXiv:2512.04987)的 general SWE/coding 轨迹。混合方式是 token-level mixing — SWE token 预算固定,Docker token 预算可变。结果(§3.3 + Table 8)显示:

关键 read:

• SWE.V / SWE.M 在 1:1 达到峰值(+2.25 / +2.09);
• Terminal-Bench 2.0 在 1:0.5 达到峰值(+3.37) — 即 Docker 训练对 terminal 帮助最大;
• 1:2 全线下降 — 过量 Docker 数据稀释 SWE-specific 推理信号。

2.5 Trajectory Filtering 消融(论文 Table 4)

这是控制训练预算严格相等下的消融,所有 variant 用相同 token 数 + 相同 epoch:

两者作用是互补:AS 提高单条 trajectory 质量(去冗余),CC 提高训练分布覆盖(平衡难度)。Hard bucket 在 CC 上涨幅最大(+1.13)印证 CC 的目标 — 让模型多见硬实例。

3 · Multi-Docker-Eval — 这是什么 benchmark

3.1 出处与规模

关键参数(摘自 DockSmith §4 + MDE 引文上下文):

• 39 个 repository × 9 种语言(Python / JavaScript / Java / C++ / C / Go / Ruby / Rust / PHP);
• 每个实例的任务: 模型需要 合成一个 valid Dockerfile + build 环境 + 让 repo 跑通测试;
• 已是 2025-12 才发布的"新鲜" bench — DockSmith 是早期受益者之一;
• 论文里 Multi-Docker-Eval 自报 SOTA 模型 F2P 也低于 40%("success rates often below 40%" — §4 related works);DockSmith 的 39.72% 正好是这个上界附近。

3.2 两个核心指标

3.3 还有几个 process metric

论文 Table 1 同时报告 3 个 process metric 用来评估效率 + 资源开销:

• Avg input — 平均输入 token 数(单位推测是 K,后续表里 DockSmith 是 207.68);
• Avg output — 平均输出 token 数(DockSmith 26.38);
• Avg docker — 平均 docker image 构建次数(DockSmith 1.13)。

这三项的意义是检验 DockSmith 是否"用更多算力换性能" — 数据看 DockSmith 输入 token 比基线 Qwen3-Coder-30B-A3B (150.10) 多约 38%,但 output token 反而少一半(26.38 vs 13.75 ❌等等基线是 13.75,DockSmith 高一倍),Docker 次数 1.13 也只略多。整体是可接受的 effectiveness-efficiency 平衡。

4 · 实验结果

4.1 主表:Multi-Docker-Eval 全模型横评(Table 1)

关键观察:

• 开源 SOTA 险胜 DeepSeek-v3.1(39.72 vs 37.72,+2.00 pp);超 Kimi-K2-0905 (+2.10 pp);
• vs 自己的 base Qwen3-Coder-30B-A3B-Instruct: +20.26 pp 绝对涨幅 — 这是论文最强的"训练有效"证据;
• vs 闭源最强 Claude-Sonnet-4: +4.19 pp F2P,vs GPT-5-Mini +5.59 pp;
• Commit Rate 58.28% 是表中第一,且高于 F2P 18.56 pp — 这个 gap 比其他模型都大(Kimi-K2-0905 gap 17.87, DeepSeek-v3.1 gap 15.17),表明 DockSmith 倾向提交更多 trajectory(包括不一定 F2P 通过的),即 commit 行为更激进。

4.2 语言级 F2P 拆解(Table 2)

DockSmith Python / JS / Java / Go / Ruby / Rust 全部第一;但C 反而退步(base 20.00 → DockSmith 20.00,无改善),C++ 只 +8.89 pp 涨幅有限。论文自我解释 — "low-level systems languages (C/C++, Java, Rust) remain bottlenecked by compiler toolchains and system dependencies";即编译工具链依赖丰富的语言是 Docker 构建难点,SFT 数据稀缺,模型学不到细粒度修复模式。

4.3 OOD transfer:三大 SWE/Terminal benchmark

这是 DockSmith 论文 thesis 的核心 OOD 证据 — 把 Docker traj 当 supervision 信号,看是否 transfer 到下游 agentic tasks。论文 §3.3 + Table 8 给出绝对分:

读 OOD 结果:

• SWE-bench Verified: 49.65 → 51.90(+2.25 pp 在 1:1)。注意这个绝对数字 — 51.90 不算 frontier,GPT-5 / Claude-Opus-4.5 都在 70+;DockSmith 的成绩在 30B 开源模型阵营内算训练有效而非绝对 SOTA;
• SWE-bench Multilingual: 31.83 → 33.92(+2.09 pp 在 1:1)/ 34.17(+2.34 pp 在 1:0.125)。涨幅小但稳定;
• Terminal-Bench 2.0: 10.67 → 14.04 (+3.37 pp 在 1:0.5)。绝对涨幅最大,符合论文 thesis "Docker-building trajectories function as a powerful form of agentic skill training, strengthening the model's competence in command execution, tool invocation, and long-horizon interaction"。

4.4 Docker-only vs Mixed-training 对照(Table 3)

论文 §3.3 还做了反向消融 — 加 SWE 数据对 Docker 任务有没有帮助:

结论:加 SWE 数据 所有 4 个 bench 都涨,包括 MDE 本身(+1.20 pp)。这说明 纯 Docker 训练会过拟合到 Docker-specific 行为,SWE 数据提供的 general edit-run-debug pattern 是必需的。这是和很多"专家模型"工作不同的有意思之处 — DockSmith 不是越专越好,而是专家 + 通用混合最强。

4.5 错误分析(Table 5 + Figure 3)

关注两个细节:

• Test Analysis 错误降幅最大 (−50.6%) — 即 DockSmith 在"看测试 log + 归因失败"这一最 reasoning-heavy 的阶段进步最明显。这印证论文 §3.5.2 的 thesis: Docker traj 训练 transfer 的是 dependency reasoning + failure recovery,而不是 prompt-engineering;
• Context Retrieval 错误反增 (+10.9%) — 论文坦诚说明这是因为 DockSmith "more aggressive information gathering" 会偶尔 over-infer dependencies;但下游 stage 的稳定足以补偿这点。

Figure 3 进一步把错误细分到 type level,DockSmith 最大改善:

• eval_patch_error: −79.1%(应用 eval patch 不再被 git checkout 误删)
• diag_vague_error: −71.7%(诊断更具体可执行)
• diag_loop_error: −59.8%(诊断逻辑不再震荡)
• docker_env_error: −48.7%(基础环境配置错误减少)

4.6 错误传播分析(Figure 4 + Table 6/7) — 为什么 transfer 有效

论文 §3.5.2 用一个 4 层 error taxonomy(shell / env / runtime / logic)做跨任务的错误传播矩阵。每个 entry (i, j) = 当前层 i 出错后,下一步在 j 层再出错的概率。结论:

• DockSmith 在 env / runtime 层"diagonal"概率提高: P(env→env) 0.34 → 0.40 (+6%), P(runtime→runtime) 0.38 → 0.45 (+7%)。这表示 DockSmith 不会"怕错就跳走",而是留在同一层继续修;
• 这种 "within-layer persistence" 是论文最哲学的发现:很多失败的 agent 不是因为没找到正确答案,而是因为过早放弃当前思路、乱跳到另一层;
• Table 6: logic-layer terminal rate 从 22.6% 降到 15.9%(−6.7 pp 最大降幅) — 即 logic-level 错误更可恢复;
• Table 7: High-quality response 从 34.6% → 40.4%(+5.8 pp),principled reasoning 从 27.1% → 33.0%(+5.9 pp),即修复行为从 heuristic 试错 转向 system reasoning。

5 · 与本系列既有工作的连接

DockSmith 在本仓库的 31 篇 agent 笔记里处于"环境是核心 supervision 源"这条主线上。下面用一张图把它的位置标清楚:

5.1 横向对比表

5.2 与 #29 EnvTuning 的有意思镜像

DockSmith 和 #29 EnvTuning(ICLR 2026)代表"环境视角"的两个对偶切片:

• EnvTuning:固定 agent,改造 env 的反馈信号(把 "No available route" 改成 "Invalid airport code[s]:..."),用 dense per-turn reward 训练;
• DockSmith:固定 env(Docker),把"如何造 env"本身当 agent 训练目标;
• 二者都认为 environment 维度是 agent capability 的核心 supervision 源,但 EnvTuning 是"environment as feedback shaper",DockSmith 是"environment as task itself"。

5.3 和 #20 SETA / Terminal-Bench 2.0 的细节

DockSmith 把 TB2.0 当 OOD bench 之一(#20 SETA 把 TB2.0 当主战场)。两者具体数字:

• SETA(Claude Sonnet 4.5 + CAMEL agent framework): TB2.0 46.5%(榜首);Qwen3-8B + AReaL GRPO RLVR 后裸跑 TB2.0 涨幅约 +4 task / +20.2% pass ratio;
• DockSmith: Qwen3-Coder-30B 自己跑 TB2.0,从 10.67 → 14.04(+3.37 pp 在 1:0.5 mix)。
• 核心差异: SETA 跑的是agent framework 加成的 frontier,DockSmith 跑的是裸 model OOD 泛化。两者不可直接比,但说明 Docker 训练对 TB2.0 的 transfer 信号是真实存在的(SETA 也是用 Docker 任务训练)。

6 · 开源现状 — 实地清点

6.1 论文自报的 release statement

论文 abstract 末尾说:

"Our model and Docker-building trajectories are publicly available at here." (原文 §abstract 最后一句)

注意 "at here" — 这是 LaTeX 模板里 \href{here}{here} 占位符没填,即论文里的 link 是空的。这是匿名审稿/早期 preprint 的常见痕迹。

6.2 实地搜索结果

6.3 匿名 HF 账号 8sj7df9k8m5x8 是什么

这个账号名是典型的随机字符串 — 看起来是 arXiv preprint 配套的匿名审稿账号。账号下只有这一个 model + 一个 dataset,创建时间(2026-01-27)和 v1 提交时间(2026-01-31)只差 4 天,且都直接以 "DockSmith" / "docker_building_training" 命名,极不可能是无关第三方。

6.4 数据集内部结构(根据 HF README)

从 agent_type 这个字段可以看出,数据集已经按 SWE-Factory 4 个 agent 拆分 — 即每个 sample 是单个 agent 的多轮交互而不是整条 trajectory。2,876 instance × 4 agent ≈ 11,500,论文里说 30K instance + 4 agent 应得到 ~120K trajectory — 所以 HF 上 39,719 个 sample 应该只是过滤后 SFT subset 的一部分,而非全部训练数据。这是另一个 release 不完整的信号。

6.5 复现可行性 checklist

结论: 当前状态下 "完整复现"是不可能的,但"用 Qwen3-Coder-30B-A3B + HF 上的 39K SFT subset 跑 SFT 再用现成 MDE/SWE-bench 评测"这个 lite-reproduce 路径是可行的。预期能达到 论文 39.72 F2P 的 70-80%(因为 SFT subset 不完整)。

7 · 局限 / 个人 take

7.1 论文的真实贡献是什么?

剥掉宣传性表述,DockSmith 实际贡献是 3 件:

1. 把 SWE-Factory pipeline 的输出当 SFT 数据,蒸馏到 30B-A3B 模型权重里 — 这本质是 distillation;
2. 两个 pipeline-level augmentation(loop-detection + cross-task memory)— 都是 engineering 优化,不是新算法;
3. 实验上证明装环境训练 transfer 到 SWE/Terminal — 这是论文 thesis 的原创性所在,但属于工程发现,不是新方法。

所以 DockSmith 的论文价值是系统性 + 实证性,不是算法性。它把过去散落的 intuition(装环境很重要,但又只是 preprocessing)系统化、量化、跑出来给大家看。

7.2 真正的 limitation

7.2.1 Multi-Docker-Eval 的 self-eval bias 隐患

MDE(Fu et al., arXiv:2512.06915,2025-12)和 SWE-Factory(Guo et al., arXiv:2506.10954,2025-06)虽然不是 StepFun 自家工作,但都在 SWE 训练 infra 这个小圈子里。DockSmith 直接复用 SWE-Factory pipeline 跑 MDE bench — 评测协议 alignment 自然非常完美。这不是狭义的 "self-eval bias",但确实使对比基线的劣势被放大(其他模型如 DeepSeek-v3.1 / Claude-Sonnet-4 都是 zero-shot 跑 SWE-Factory framework,而 DockSmith 是专门为这个 framework 训练的)。

更公允的对比方式应该是:把 DockSmith 接到一个不同的 Docker-building scaffold(比如 ExecutionAgent / Repo2Run / SetupAgent)上看是否还保持 SOTA。论文没做这个实验。

7.2.2 30B-A3B 的"开源"主张需要打折

论文反复强调 "open-source state-of-the-art",但实际:

• Base model Qwen3-Coder-30B-A3B-Instruct 本身是 Apache-2.0 真开源 — 这部分没问题;
• DockSmith 的训练 weight 放在匿名 HF 账号下,无正式 license 声明,无 release announcement;
• HF 上 dataset 标了 Apache-2.0,但 GitHub repo 派生数据的合规性(尤其涉及 200K PR description + Dockerfile + test log 的版权 / NOTICE 文件)未在 README 中说明;
• 训练脚本 / pipeline 实现完全缺失。

结论:DockSmith 的 "open-source" 主张当前只能算"artifact-partial" — model weight + 部分 SFT subset 可下载,但不是 reproducibility-grade open-source(对比 TOUCAN #22 的 Apache 数据 + MIT 代码 + 27 个 HF ckpt 全栈商用 friendly)。

7.2.3 Cross-task success memory — 启发式还是学到的?

论文 §2.2 只说 "previously verified (Dockerfile, eval script) pairs to serve as lightweight demonstrations",没给 retrieval 算法、没给 ablation(memory on/off 对最终结果影响多少)。这是一个明显的消融缺口:

• loop-detection的消融完全缺(Table 4 是 Acceptance Shaping + Curriculum,不是 loop-detection);
• cross-task memory的消融完全缺;
• 所以读者无法判断这两个"扩展"对最终 SOTA 贡献了多少。两个看起来都是 engineering trick,但论文是把它们当 contribution 提出的。

个人推测:cross-task memory 极有可能是简单的 metadata lookup(按主语言 + 主框架 match),不是学出来的检索器。如果是 learned retrieval,论文一定会单独 ablation 出来 sell。

7.2.4 OOD claim 的污染风险

论文 §2.1 说做了 "repository-level deduplication against all evaluation benchmarks" 防 contamination — 但这只能保证 repo 没重叠。但 SWE-Factory 的 pipeline 数据本身就是从 GitHub merged PR 拉的,而 SWE-bench / SWE-bench Multilingual / Terminal-Bench 2.0 的任务也是从 GitHub 公开仓库制定的 — 即两者数据生成过程在源数据维度有结构性同构。这种"软污染"在编程领域是普遍存在的,DockSmith 没有比同类工作做得更糟,但 +2.25/+2.09/+3.37 这种小数量级涨幅的 OOD claim 应该带着这层警觉来读:可能有一部分涨幅是源数据相关性贡献的,而不是单纯"装环境训练 transfer"。

7.2.5 SWE.V / SWE.M / TB2.0 绝对分数都不高

DockSmith 的 OOD 涨幅是百分点级而非数量级:

• SWE-bench Verified: 49.65 → 51.90 — 30B-A3B 区间内有提升,但 frontier 已经在 70+(Claude-Opus-4.5,GPT-5);
• SWE-bench Multilingual: 31.83 → 33.92 — 还低于 50%;
• Terminal-Bench 2.0: 10.67 → 14.04 — 远低于 SETA(Claude + CAMEL)的 46.5%。

即论文 OOD 部分的"transfer 信号是真实的"这个 claim 成立,但"DockSmith 是个强 SWE/Terminal agent"这个隐含 claim不成立。两者要分清。论文 §5 conclusion 措辞已较谨慎("improves out-of-distribution performance"而非"achieves SOTA"),但 abstract 的措辞容易被误读。

7.2.6 没有 RL,SFT 上限到顶了吗?

整个 DockSmith 训练管线是 纯 SFT。考虑到:

• #20 SETA 用 AReaL GRPO RLVR 在 Qwen3-8B 上跑出温和涨幅;
• #23 EnvScaler 用 Reinforce++ 在 Qwen3-Thinking 上跑出 SOTA;
• #25 MCP-Universe 内含 verl GRPO 训练栈;
• SWE-Factory 流水线天然有 exit code 作为 verifier signal,这是免费的 RLVR reward;

论文没有探索 RL — 这是一个未完成的实验维度。猜测原因有二:(1) Docker-building rollout 太长(单个 trajectory 可达 50 steps),GRPO 在长 horizon 上 sample efficiency 差;(2) StepFun 当前可能更看重蒸馏出快速可部署的 SFT 模型,RL 留作后续。但RL × Docker-building 是显然的下一步,谁先做完会拿到更大 jump。

7.2.7 C 语言 / C++ / Java 编译工具链的 systematic 失败

从 Table 2 看,DockSmith 在 C 语言上 base 已经是 20.00,DockSmith 还是 20.00(无改善),C++ 6.67 → 15.56(+8.89 pp,但绝对值还是很低),Java 6.67 → 19.05(+12.38 pp,但与 Python 的 51.28 相比还是低)。这是 Docker-building 的结构性难点: 编译工具链(gcc 版本 / glibc ABI / cmake 设置 / Maven cache / Gradle wrapper)的失败模式高度长尾,SFT 数据稀缺、修复路径多分支。这暗示Docker 训练的"语言不均衡"是固有的,加更多 C/C++ 数据未必 scale。

7.3 个人 take

7.4 待验证问题清单

1. Loop-detection controller 的具体算法(N-gram 阈值? 学习的判别器?)— 论文未给;
2. Cross-task memory 的 retrieval 算法(BM25 / embedding / metadata match?)— 论文未给;
3. Loop-detection on/off 的 ablation — 论文未给;
4. Cross-task memory on/off 的 ablation — 论文未给;
5. 正式开源 repo / 权重的 timeline — StepFun 是否会在 ICML / NeurIPS 2026 cycle 内做迁移;
6. Cai et al. (2025) "Nex-N1: Agentic models trained via a unified ecosystem for large-scale environment construction" arXiv:2512.04987 — 这是 SFT joint-training 用的 Nex Agent-SFT 数据集来源,是 StepFun 自家相关工作?需要交叉读;
7. DockSmith 是否能反过来 boost SWE-Factory 本身的数据生成 yield — 闭环验证;
8. 对 C/C++/Java 等长尾语言的极限提升路径是什么 — 加 toolchain-specific 训练 data? RL?。

笔记完成 · 2026-05-18 · 笔记 #32 · 返回 README