你让一个刚读完编程教材的人接手真实项目，他可能认识每一行代码，却不知道该先查哪个文件、怎样看报错、改完后如何测试。今天的代码智能体也有类似断层：预训练让模型读过大量文字和代码，后训练再教它使用工具，但两者之间缺少一段面向真实工作环境的系统准备。这篇论文把长期隐身的“中训”摆上台面，并公开了一套具体配方。
这里的中训（midtraining），指通用预训练结束后、面向任务的后训练开始前追加的一段训练。预训练像读完一座图书馆，主要学习语言、知识和代码规律；监督微调（SFT）则用“输入—理想输出”范例，教模型照着完成任务。问题在于，真实软件工程既不像读书，也不像做几道标准例题。智能体需要在整个代码仓库里来回查找，调用工具，阅读构建日志，并连续执行许多步。
论文作者在两种 Nemotron 模型上测试了这套方案。下文数字均为作者在特定训练与评测协议下报告的单一信源结果，尚无外部交叉验证。
先让模型见过真实工地
这套配方的核心不是再堆一批问答，而是把真实软件项目的工作材料搬进训练。
训练使用 256K 的上下文长度——也就是一次能放进模型“工作台”的文本规模——持续数千亿 token。Token 是模型处理文字时使用的基本片段。数据主体包括完整代码仓库、pull request（开发者提交的一组代码修改）、commit 历史、构建与持续集成日志，以及一小部分智能体操作轨迹。
其中最大的两块是 issue—PR 数据和代码仓库，分别占训练混合数据的 40.8%和 20%。作者从公开 GitHub 项目中整理出 1210 万个 PR，并把问题描述、代码上下文、评审讨论和修改过程串在一起。仓库也不是把文件随手拼接：团队为 14 种编程语言建立文件之间的 import 依赖图，只保留存在一定内部关联的项目，再把相关文件放在相邻位置。这样，模型看到的不只是孤立代码，而是“这个文件调用了另一个文件里的什么东西”。
另一类关键材料是代码变化过程。论文把修改前后的多个关联文件，以及一个文件经历多次真实提交后的状态变化，整理成连续样本。它训练的不是“写出一段看起来合理的代码”，而是更朴素也更困难的能力：记住项目此前是什么样，并让新修改与旧状态保持一致。
智能体轨迹不能喧宾夺主
自然项目材料能教模型理解软件系统，却不会完整展示智能体如何调用工具、测试修改、遭遇失败后重试。因此，配方中还有约 10%的智能体轨迹：超过 100 万条操作过程、约 50 万个不同查询和 3000 万次工具调用，覆盖十多种 agent scaffold。
Agent scaffold 可以理解为包在模型外面的“工作框架”：它规定模型有哪些工具、怎样读取文件、如何执行命令。作者刻意混入多种框架，因为从单一框架学到的操作习惯，可能换个外壳就失灵。
但轨迹占比被限制在 10%至 15%。作者担心，如果中训过于像 SFT，就等于提前做了一场很长的范例教学，可能削弱模型以后通过强化学习（RL）继续探索的空间。强化学习不是让模型照抄标准答案，而是根据行动结果获得奖励，逐渐找到更有效的策略。
还有一个很实用的选择：工具返回内容不参与预测损失。文件全文、测试日志和错误堆栈是环境给模型看的，不是模型自己应该生成的。作者的对照实验中，让模型同时预测这些工具响应，SWE-bench Verified 的 pass@1 从屏蔽响应时的 37.8降到27.5。Pass@1 表示只给一次尝试时成功解决任务的比例。这说明，至少在该设置下，逼模型背诵环境噪声会挤占学习行动策略的能力。
提升不只出现在一张榜单
作者给有无中训的模型安排了相同的完整 SFT，再比较结果。这样至少能控制后续范例教学这一环节，不过仍不能证明所有差异只来自中训。
在 Nemotron 3.5 Lightning 上，500B、即 5000 亿 token 的中训把 SWE-bench Verified 从 60.7提高到64.5，把 Multilingual 从55.8提高到62.8，把难度更高的 Pro 从32.0提高到35.5。SWE-bench 是让模型处理真实软件问题的一组评测；不同版本覆盖经过核验的任务、多语言项目或更困难的样本。这里最持续的改善来自 Multilingual：其他两项的大部分增益在前100B token 已经出现，它则一直改善到500B。
在更大的 Nemotron 3.5 Super 上，280B token 中训后，长流程任务评测 DeepSWE 从11.7升到15.7，SWE-bench Verified 从72.9升到74.3。但结果并非全面上涨：完整 SFT 后，Multilingual 和 Pro 分别比基线低1.1和2.1分，作者没有把它们解释为稳定收益。
中训还降低了模型对工作框架的依赖。作者报告，两种模型在所测试的每种 harness 上都有改善。Harness 是实际驱动智能体读文件、调用终端和提交答案的运行外壳。以 Super 的短 SFT 实验为例，65B token 中训后，不同 harness 上的 SWE-bench Verified 平均提高8.6分，Terminal-Bench 平均提高6.8分。它提示中训学到的可能不只是某一种工具格式。
真正重要的是评估方式
这篇工作的另一个价值，是承认“底座看起来更会做题”未必能预测后训练后的智能体表现。作者测试了代码压缩效率、跨文件建模和文件状态重建等代理指标。它们会随中训改善，却不能可靠指导配方选择。
团队因此采用短而固定的 SFT 作为快速体检：给不同中训版本完全相同的33B token 微调，再观察真实智能体任务；主要结论则使用100B token 的完整 SFT复核。这个过程更昂贵，却更接近真正想回答的问题——这块底座经过后训练后，到底能不能更好地干活。
为什么值得关注
过去，讨论常集中在预训练规模、SFT 数据和强化学习算法。中训则像一段被省略的课程：它决定模型进入后训练前，是否已经见过长项目、真实修改历史和工具交互。论文最有价值之处，不是宣布一种万能配方，而是把数据来源、混合比例、过滤方法和关键对照实验公开出来，让这一环节第一次变得较容易讨论和复查。
它也给出一个克制的判断：自然软件数据负责建立项目结构和状态变化的底子，智能体轨迹负责补上行动模式；两者不能简单互相替代。训练时还要回放20%的预训练数据，避免模型在适应新工作时过快忘掉通用能力。
局限与未知
- 所有主要效果都来自作者自报的单次实验。智能体评测本身噪声较大，论文也承认一两分差异可能来自运行波动。
- 研究只验证了 Nemotron 模型，重点集中在代码智能体；它没有比较把同等 token 用于更长预训练或更长 SFT 会怎样，也没有充分验证强化学习阶段的收益。
- 256K 是中训时的上下文长度，不等于模型在实际推理中必然能有效使用同样长的内容。配方提高了部分长上下文指标，但仍需要后续长上下文训练。