代码 Agent 后训练闭环：从基础模型到 SWE-bench SOTA
TL;DR
代码 Agent 的 SWE-bench 数字背后是 5 个阶段的训练闭环：
- 数据合成 — DeNovoSWE：4,818 条 Doc→Repo 长程任务（arXiv:2606.10728）
- 长视野 SFT — daVinci-Dev：68.6B 上下文 + 3.1B rollout 轨迹（arXiv:2601.18418）
- 决策点对齐 — SEAlign：<1k 条样本解决空 patch / 卡死（ICSE 2026 Distinguished Paper）
- RL + 推理时扩展 — SWE-Master：串行优先→并行的 TTS 策略（arXiv:2602.02380）
- 无 Docker 评估 — SWE-World：环境代理 + TTC 并行模拟（arXiv:2602.03419）
- 漏掉任何一级的代价 — 数据量翻倍但 SWE-bench 不动；SOTA 模型在大规模并行评测下露出短板
写给正在训模型的工程师
“为什么我的代码模型训了 100 万条数据，SWE-bench 数字还是不动？”
这是 2026 年每个做 Coding Agent 团队都会撞到的问题。答案不是”数据再多一点”，是漏掉了训练闭环里的某一级。
2026 年 H1 出现 5 篇代表性论文，把代码 Agent 的训练拆成了 5 个根本不同的阶段。它们不是在”同一个问题上的不同解法”，而是在5 个不同问题上的不同答案：
| 阶段 | 解决的问题 | 谁缺这一级会出事 |
|---|---|---|
| 数据合成 | “训什么任务” | 数据没覆盖仓库级长程能力 |
| 长视野 SFT | “怎么学因果链” | 模型会改 diff 但不会先定位 |
| 决策点对齐 | “怎么学行为分布” | 空 patch / 卡死在循环里 |
| RL + TTS | “怎么训出泛化” | 测试集过拟合、新仓库崩 |
| 无 Docker 评估 | “怎么测得动” | 评测是训练瓶颈 |
💡 Key Insight
评估代码 Agent 训练成熟度的最好问题不是”训了多少数据”，而是”五个阶段是不是每一级都不漏“——漏掉任何一级，SWE-bench 数字都是虚的。
5 个阶段：一张图一张表
| # | 阶段 | 锚点论文 | 核心解法 |
|---|---|---|---|
| 1 | 数据合成 | DeNovoSWE（AweAI Team, RUC） | 4,818 条 Doc→Repo 长程任务 + D&C 标注管线 |
| 2 | 长视野 SFT | daVinci-Dev（SII / SJTU / GAIR） | 68.6B 上下文 + 3.1B rollout，因果链对齐 |
| 3 | 决策点对齐 | SEAlign（北大, ICSE 2026） | <1k 条决策点样本，空 patch 52%→22.8% |
| 4 | RL + TTS | SWE-Master（开源框架） | 串行优先→并行，generative scorer |
| 5 | 无 Docker 评估 | SWE-World（Hugging Face 等） | 学习型环境代理 + TTC 并行模拟 |
5 个阶段不是升级路径，是前后依赖的漏斗。上一级没做，下一级没数据。
阶段 1：数据合成 — DeNovoSWE
你在这一阶段的特征
- 已有基础代码模型，但 SWE-bench 数字卡在某个瓶颈
- 团队发现：模型会修 bug，但不会从零搭一个仓库
- 想要”Doc→Repo”长程训练数据
核心问题
代码 Agent 的下一道墙不是 bug 修复速度，是从零搭出一个仓库的能力。
传统 SWE-bench 任务是”修一个文件里的 bug”，但真实工程是”读 50 页文档 + 设计架构 + 写 20 个文件”。DeNovoSWE 给出 4,818 条 Doc→Repo 长程任务，配套 Divide & Conquer + Critic & Repair 标注管线。
实证结果：Qwen3-30B-A3B-Instruct 在 BeyondSWE-Doc2Repo 上从 5.8% → 47.2%，NL2RepoBench 从 4.3% → 23.0%。
阶段 1 的退出条件
当你已经有了”修 bug”和”搭仓库”两类任务的训练数据，但模型空 patch 率仍然 >40%，进入阶段 2。
💡 Key Insight
DeNovoSWE 的核心贡献不是数据集，是任务合成的工程化管线——Divide & Conquer 把长程任务拆成子任务，Critic & Repair 用 LLM 标注每一步的质量。没有这条管线，数据量翻倍但任务分布不会变。
阶段 2：长视野 SFT — daVinci-Dev
你在这一阶段的特征
- 已有 Doc→Repo 训练数据，但模型训练后行为不像”工程师”
- 团队发现：模型会一口气改完整个文件，不先读上下文
- 想要”localize → read → edit”的因果链
核心问题
模型要学会的不是改 diff，是 localize → read → edit 的因果链。
daVinci-Dev 用 68.6B 上下文原生 + 3.1B 环境 rollout 轨迹做中期训练，强制模型分三步：
- Localize —— 先定位需要改的文件
- Read —— 读上下文（包括非修改文件的依赖）
- Edit —— 再下 diff
实证结果：SWE-Bench Verified 32B 达 56.1%、72B 达 58.5%；数据量仅为 Kimi-Dev 一半就达到同等水平。
阶段 2 的退出条件
当你发现模型已经会三步走，但仍然出”空 patch”（不修改任何文件就交差）或”卡死在循环里”（同一错误反复重试），进入阶段 3。
💡 Key Insight
daVinci-Dev 的反直觉发现：数据量不是关键，因果链结构才是。同样 3.1B 轨迹，按 localize→read→edit 顺序训练 vs 随机顺序训练，SWE-bench 差距是 10+pp。
阶段 3：决策点对齐 — SEAlign
你在这一阶段的特征
- 模型能正确执行三步，但行为分布有问题
- 团队发现：空 patch 率 >40%，卡死率 >25%
- 想要”显式约束关键节点的行为”
核心问题
99% 的代码 Agent 对齐数据在解决错的问题。
SEAlign（ICSE 2026 Distinguished Paper）的诊断：传统 SFT 数据教模型”怎么写 patch”，但 SWE Agent 失败的主因是关键决策点的行为分布错了——比如”判断任务该放弃还是该重试”、”判断 patch 该打回还是该提交”。
SEAlign 用 <1k 条决策点感知样本 SFT，显式约束 agent 在 patch 生成 / 文件定位等关键节点的行为分布：
- 空补丁率 52% → 22.8%
- 卡死率 27.8% → 15.6%
- SWE-Bench-Verified 14B 模型从 2.8% → 21.8%
阶段 3 的退出条件
当决策点行为分布已经稳定，但模型在新仓库上泛化差（SWE-bench 测试集过拟合），进入阶段 4。
💡 Key Insight
SEAlign 的核心发现：1k 条决策点样本 > 100k 条普通 SFT 样本。这不是因为决策点样本更”优质”，是因为前者改的是行为分布，后者改的是输出表面。这与 [agent-skills] 的”反借口表格”哲学一致——少做事比多做事更有效。
阶段 4：RL + 推理时扩展 — SWE-Master
你在这一阶段的特征
- SFT 后模型在测试集表现良好，但泛化差
- 团队发现：换一个仓库就崩；改一个 API 文档就不行
- 想要”训练阶段扩展 + 推理阶段扩展”
核心问题
怎么用 RL 提升泛化，又不丢掉推理时的灵活性？
SWE-Master 给出一个完整后训练框架：
- 数据合成（与阶段 1 重叠）
- 长视野 SFT（与阶段 2 重叠）
- RL 阶段 —— 用 PPO / MAPPO 在 SWE-bench 任务上做 RL
- 推理时扩展（TTS） —— 串行优先→并行
TTS 策略的具体做法：
- 先串行扩 rounds（让 agent 多尝试几次）
- 再并行选优（多个候选 patch 取最好的）
关键创新：generative scorer 优于 regression scorer —— 用 LLM 判断 patch 质量比用规则判断更准。
阶段 4 的退出条件
当 RL + TTS 都做了，但评估本身的成本成为训练瓶颈（一次完整 SWE-bench 评测要几小时），进入阶段 5。
💡 Key Insight
SWE-Master 的核心反直觉：串行优先于并行。直觉上”并行 4 个 patch 选最优”应该更快更好，但实测先串行扩 rounds 再并行选优显著优于直接并行。原因是串行让模型从错误中学习，并行只让模型从结果中选。
阶段 5：无 Docker 评估 — SWE-World
你在这一阶段的特征
- 已有完整训练流程，但每次 SWE-bench 评测要几小时
- 团队发现：Docker 容器启动 + 测试运行成本占训练闭环 60%+
- 想要”可大规模并行的评估基础设施”
核心问题
没有可大规模并行的评测，训练闭环跑不起来。
SWE-World 用学习型环境代理模型替代物理 Docker 容器：
- 环境代理模型：接收代码 patch → 预测测试结果
- TTC（测试时扩展）：多次采样取共识
- 环境与 Agent 解耦 → 大规模并行评估
实测：Qwen2.5-Coder-32B 在无 Docker 框架下从 6.2% → 52.0%；加入 TTS 达 68.2%。
阶段 5 的退出条件
这一步是基础设施，没有”退出条件”——它让训练闭环能转起来。
💡 Key Insight
SWE-World 的核心洞察：评估基础设施是训练闭环的隐藏瓶颈。很多团队的代码 Agent 训练”卡在某个数字不动”，根本原因不是模型不够好，是评估太慢导致没法做大规模 RL 探索。这与 [loop-engineering] 的”反馈循环要快”是同源思路。
漏掉任何一级的代价
很多团队会犯的错误：只做其中一两个阶段，期待 SWE-bench 数字线性提升。
| 漏掉的阶段 | 表面症状 | 根因 |
|---|---|---|
| 阶段 1（数据） | 数据量翻倍但 SWE-bench 不动 | 任务分布没覆盖长程能力 |
| 阶段 2（SFT） | 模型会改 diff 但不会先读 | 因果链没训练 |
| 阶段 3（对齐） | 空 patch / 卡死 | 关键节点行为分布错了 |
| 阶段 4（RL+TTS） | 测试集过拟合，新仓库崩 | 训练阶段扩展缺失 |
| 阶段 5（评估） | 训练 1 周，评测 3 天 | 评估成为训练瓶颈 |
更合理的混合是：
| 你的问题 | 推荐起点 | 缺什么补什么 |
|---|---|---|
| “基础模型训不动” | 阶段 1（数据）+ 阶段 2（SFT） | 缺决策点对齐 |
| “模型会改但改错” | 阶段 2 + 阶段 3（对齐） | 缺 RL 提升泛化 |
| “测试集过拟合” | 阶段 4（RL+TTS） | 缺评估基础设施 |
| “评测是瓶颈” | 阶段 5（评估） | 闭环才能转 |
结尾
代码 Agent 后训练不是单一阶段，是 5 个前后依赖的漏斗。
阶段 1（数据合成）让模型见过仓库级长程任务； 阶段 2（长视野 SFT）让模型学会 localize→read→edit 因果链； 阶段 3（决策点对齐）让模型在关键节点做出正确行为； 阶段 4（RL + TTS）让模型从错误中学习并提升泛化； 阶段 5（无 Docker 评估）让训练闭环跑得动。
每一种解法都有自己的前提假设与适用场景。没有”最好的训练路线”，只有”漏斗里每一级都不漏的训练路线”。
读 5 篇锚点论文各 15 分钟（总共 75 分钟），比你乱试 3 个月高效得多。
💡 Key Insight
代码 Agent 训练的最常见错误是”追数据量不追结构”——以为数据多 SWE-bench 就涨，结果数据翻倍数字不动。结构对了，数据量减半也涨；结构错了，数据量翻倍也跌。
延伸阅读
- AI Agent 记忆系统巡礼：4 种范式 — 代码 Agent 训练完后的运行时记忆
- agent-skills 的反直觉设计 — 阶段 3 决策点对齐的同源哲学
- Loop Engineering — 阶段 5 评估基础设施的母框架
- Context Engineering Field Guide — 推理时扩展的 context 侧讨论
Published on 2026-07-03 深度阅读时间：约 10 分钟（5 篇论文合计约 75 分钟）
Coding Agents 子系列 —— 代码 Agent 后训练闭环
💬 评论
💡 使用 GitHub 账号登录 即可参与讨论