daVinci-Dev：面向软件工程的智能体原生中期训练 daVinci-Dev: Agent-native Mid-training for Software Engineering
用GitHub PR数据和真实执行轨迹做智能体中期训练，在SWE-Bench上刷新开源方案SOTA。
前置知识
中期训练（Mid-training）
中期训练是介于大规模预训练（pre-training）和后训练（post-training，包括SFT和RL）之间的一个阶段。它通过在精心策划的领域数据上进行持续训练，来调整模型的能力分布。不同于SFT（教会模型特定行为），中期训练作用于知识层面，为后续微调建立更强的基础能力。这一范式已在数学推理（如OctoThinker）和代码领域证明了其价值。
本文的核心贡献就是首次系统性地研究了面向软件工程智能体的中期训练，理解中期训练与SFT/RL的区别是读懂全文的前提。
SWE-Bench Verified
这是一个评估代码智能体解决真实GitHub issue能力的基准测试。它包含来自知名开源项目的实际bug修复任务，每个任务给出仓库状态、issue描述和测试用例，智能体需要在仓库中定位问题、编写修复代码并通过测试。Pass@1是核心指标，代表单次尝试的解决率。
本文所有核心实验结果都在SWE-Bench Verified上报告，理解该基准的任务形式和评估方式对于衡量本文贡献至关重要。
智能体脚手架（Agentic Scaffold）
智能体脚手架是指围绕LLM构建的工具调用框架，如SWE-AGENT和OpenHands。它定义了模型可以使用的工具（搜索文件、读取代码、编辑文件、运行测试等）以及交互协议。脚手架将LLM从纯文本生成器转变为能与代码仓库环境交互的智能体，模型通过生成结构化的工具调用请求来执行操作，环境返回观察结果。
本文使用SWE-AGENT脚手架进行评估，且强调其方法与不同脚手架的兼容性。理解脚手架的作用有助于理解'智能体原生数据'的设计动机。
分布不匹配（Distribution Mismatch）
传统训练数据（如静态代码文件、已合并的commit）展示的是最终产物，而智能体在部署时需要经历多步交互过程（定位→读取→编辑→测试→修正）。训练数据的分布与实际部署时的分布之间存在根本性差异，这就是分布不匹配问题。模型在训练时从未见过工具调用的观察结果、测试失败的错误信息和迭代修正的过程。
这是本文提出的核心问题。作者认为现有中期训练数据不是'智能体原生'的，正是因为它没有保留智能体部署时经历的动作-观察循环结构。
SWE-AGENT
SWE-AGENT是一个广泛使用的软件工程智能体框架，由Yang等人提出。它定义了标准的工具集（bash命令、文件搜索、代码查看、补丁应用等）和交互协议，被多个开源智能体训练方案采用。SWE-smith是配套的训练数据集，包含用Claude 3.7 Sonnet等模型生成的智能体轨迹。
本文的SFT基线数据DSWE-smith来自SWE-smith，评估也在SWE-AGENT脚手架上进行，理解该框架是理解实验设置的关键。
研究动机
现有构建代码智能体的主流方法是后训练（post-training），包括SFT在精选轨迹上微调和RL从执行反馈中学习。但这一范式存在根本性瓶颈：首先，可用于训练的仓库数量受限——很多仓库的README文件指令不清晰，且需要GPU等资源构建可执行环境，导致可转化为可执行环境的仓库非常有限。其次，在大多数情况下只有正确的轨迹才能用于训练，而高质量的人工标注轨迹价格昂贵，复杂的智能体系统只能解决一小部分issue，大量环境在训练前就被过滤掉了。更根本的是，后训练受限于基础模型的内在能力，某些智能体推理能力可能无法通过后训练单独学会。这促使作者思考：能否在训练流水线的更早阶段——中期训练阶段——就注入基础的智能体行为？然而，现有的中期训练数据（如KIMI-DEV采用的方案）主要采用分解式方法：将定位和编辑作为独立的原子能力分别合成数据，没有保留智能体在实际部署中经历的过程性上下文和动作-观察循环。这导致训练数据与部署环境之间存在严重的分布不匹配。
本文的目标是本文的目标是首次系统性地研究面向软件工程的大规模智能体中期训练。具体而言，作者希望：（1）建立有效的智能体中期训练数据合成原则和方法论；（2）构建大规模的智能体原生数据集，保留真实软件工程中完整的信息流和环境动态；（3）验证中期训练能在少于已有方案一半的token量下（73.1B vs 约150B tokens），实现超越已有开源方案的性能。在SWE-Bench Verified上，目标是达到或超过此前最强开源中期训练方案KIMI-DEV的表现。
与已有工作不同的是，本文的独特切入点在于提出了'智能体原生数据'（agent-native data）的概念。作者敏锐地观察到，现有中期训练数据的核心问题不是数量不够，而是结构不对。以一个典型的GitHub Pull Request为例：commit历史展示了哪些文件被修改了，但隐藏了开发者（或智能体）如何发现这些文件、在编辑前检查了什么上下文、以及测试反馈如何影响后续修正。即使大规模训练这样的静态快照，也无法让模型为真实的交互式开发做好准备。本文的关键洞察是：智能体不应该分别学习导航、检索上下文、生成编辑、应用更改和运行单元测试，而应该将这些技能协调成一个连贯的、迭代的问题解决循环，每一步的反馈都影响下一步的动作。这一视角将问题从'如何获取更多数据'转变为'如何构建正确的数据结构'。
核心方法
本文的方法可以用一个类比来理解：传统的代码模型训练就像只看建筑图纸来学盖房子——你能看到最终的结构，但不知道工人是怎么一步步施工的。而本文的方法就像让学徒同时看完整的施工日志（包含每一步的决策和原因）和实际工地的实时监控录像（包含真实的工具使用和错误反馈）。技术路线上，作者从GitHub Pull Requests出发构建两种互补的训练数据：上下文原生轨迹（Contextually-native Trajectories）从PR的静态信息中重建完整的开发工作流，提供广度和多样性；环境原生轨迹（Environmentally-native Trajectories）在真实的可执行环境中运行智能体收集轨迹，提供深度和交互真实性。这两类数据分别从'覆盖范围'和'执行真实性'两个互补角度解决分布不匹配问题。训练流水线分为两个阶段：先在大规模智能体原生数据上进行中期训练（MT），再在精选轨迹上进行监督微调（SFT）。
本文最核心的创新是提出'智能体原生数据'这一概念，并设计了两种互补的数据类型来实现它。与已有方法（如KIMI-DEV）的本质区别在于：已有方法将PR数据分解为独立的子任务（定位和编辑分别训练），这破坏了数据的因果结构——编辑决策应该依赖于定位阶段收集的上下文。本文坚持将完整的工作流保留在单个训练样本中：issue描述、相关文件内容、LLM生成的摘要和编辑操作按因果顺序组织在一起，完整模拟智能体在部署时的信息流。对于环境原生轨迹，作者的关键设计决策是不过滤失败轨迹——非通过轨迹（测试失败）同样提供有价值的调试场景学习信号。这与SFT阶段只使用正确轨迹的做法形成互补，在中期训练阶段让模型接触到更丰富的执行反馈模式。
方法步骤详情
方法分为两个主要数据构建流水线。第一步是上下文原生轨迹构建：（1）数据收集——通过GitHub REST和GraphQL API收集PR元数据，包括issue描述、base commit的文件内容和完整commit序列及diff；（2）过滤——在仓库级别，Dctxgen从top 10,000个最多star的仓库中选取，Dctxpy关注至少5个star的Python仓库；在PR级别，只保留已合并的PR，排除机器人创建的PR，Python子集要求修改的Python文件数在1-5个之间；（3）重建——用Qwen3-235B生成PR摘要和精炼commit消息，通过反向工程分析symmetric diff提取修改文件集，将所有信息组织成结构化模板（仓库上下文→Issue→PR→相关文件→摘要→编辑），丢弃超过32k token的样本，并去除SWE-Bench Verified相关的数据以防泄漏。第二步是环境原生轨迹构建：（1）从真实PR构建可执行Docker环境（遵循SWE-REBENCH方法）；（2）部署GLM-4.6在SWE-AGENT框架中，每个任务生成最多4条轨迹；（3）记录完整的动作-观察序列，丢弃超过128k token的轨迹；（4）按最终测试结果分为通过轨迹（0.7B tokens，18,500条）和非通过轨迹（2.4B tokens，55,500条），共计3.1B tokens。
技术新颖性
本文的技术新颖性体现在三个层面。首先，在概念层面，'智能体原生数据'是一个全新的数据设计范式，它不是简单地追求数据量，而是强调数据的结构要匹配智能体的部署分布。这与现有工作（如StarCoder 2、KIMI-DEV采用的分解式方法）形成鲜明对比。其次，在数据构建层面，上下文原生轨迹的重建过程将PR的静态diff转化为上下文丰富的轨迹，保留了定位→读取→编辑的自然耦合；环境原生轨迹不过滤失败轨迹的设计充分利用了非成功执行中的调试信号。两种数据类型的协同设计——PR数据建立通用软件工程先验，验证轨迹特化智能体行为——是一个精巧的架构选择。最后，在训练策略层面，作者证明了在中期训练阶段暴露模型于轨迹数据（即使SFT阶段也会用到类似数据）仍有价值，这种'双重使用'能更深入地让模型内化执行环境的动态特性，为最终对齐阶段提供更好的初始化。
实验结果
本文在SWE-Bench Verified上进行了全面的实验验证。最核心的发现是：智能体原生中期训练在各种设置下都能带来稳健的性能提升。在72B模型上，仅用Dctx（68.6B tokens）进行中期训练，在弱SFT设置下就将性能从38.0%提升到46.4%（+8.4%），在强SFT设置下从56.6%提升到58.2%（+1.6%）。加入环境原生轨迹后（Dctx + Denv，73.1B tokens），daVinci-Dev-72B达到58.5%的SOTA水平。在32B模型上，daVinci-Dev-32B达到56.1%，同样是该规模使用智能体脚手架的开源方案中最强。值得注意的是，这些结果是从非代码专用的Qwen2.5-Base模型出发取得的，而同类工作通常使用Qwen2.5-Coder或更新的Qwen3系列。在token效率方面，本文仅用73.1B tokens就超越了KIMI-DEV需要约150B tokens才能达到的性能，效率提升超过一倍。零样本实验（无SFT）揭示了一个重要发现：仅用环境原生轨迹训练的模型在72B上达到47.1%，但混入上下文原生数据后飙升到54.8%（+7.7%），证明上下文原生数据提供了不可或缺的知识基础。在泛化能力方面，中期训练还带来了代码生成和科学推理的意外收益：HumanEval从64.27%提升到76.73%（72B），GPQA-Main从43.30%提升到44.87%，SuperGPQA从37.76%提升到39.27%。Scaling实验显示训练步数与性能呈强对数线性关系（R²≈0.90），表明性能尚未饱和，进一步扩大数据规模仍有提升空间。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| SWE-Bench Verified (72B, SWE-AGENT) | Pass@1 | 58.5% | KIMI-DEV 48.6%（SFT+RL） | +9.9%，且仅用SFT无需RL，token量减半 |
| SWE-Bench Verified (32B, SWE-AGENT) | Pass@1 | 56.1% | FrogBoss 54.6%（Qwen3-32B） | +1.5%，使用更弱的Qwen2.5-32B-Base基础模型 |
| SWE-Bench Verified (72B, 弱SFT) | Pass@1 | 46.4%（Dctx MT） | 无MT基线 38.0% | +8.4% |
| HumanEval (72B) | Pass@1 | 76.73% | Qwen2.5-72B-Base 64.27% | +12.46% |
| HumanEval (32B) | Pass@1 | 81.42% | Qwen2.5-32B-Base 58.16% | +23.26% |
| EvalPlus (72B) | Pass@1 | 69.45% | Qwen2.5-72B-Base 56.04% | +13.41% |
| GPQA-Main (72B) | Accuracy | 44.87% | Qwen2.5-72B-Base 43.30% | +1.57% |
| SuperGPQA (32B) | Accuracy | 35.94% | Qwen2.5-32B-Base 33.85% | +2.09% |
| SciBench (32B) | Accuracy | 20.49% | Qwen2.5-32B-Base 18.46% | +2.03% |
局限与改进
作者在论文中坦承了几个局限性。首先，在数据隐私和归属方面，通用子集Dctxgen没有明确移除开发者标识符，可能存在隐私问题和贡献者姓名被记忆的风险。其次，评估敏感性方面，部分结果依赖于修补过的评估工具，修复了少量基准问题的ground truth patch无法通过测试的情况，这引入了额外的方差来源。第三，研究范围有限，本文只在一个基础模型系列（Qwen2.5）和一个基准（SWE-Bench Verified）上进行了主要实验，泛化到其他模型家族和更多真实世界智能体任务有待验证。从我的观察来看，还有几个值得注意的局限：（1）环境原生轨迹使用的智能体（GLM-4.6）和评估智能体（基于Qwen2.5）不同，可能存在能力分布的不匹配；（2）论文没有报告RL阶段的结果，仅用SFT虽然简洁但可能未充分释放模型潜力；（3）Dctxgen与Dctxpy有重叠（Python仓库），重叠部分的影响未被分析。
独立分析的弱点
从独立分析的角度，本文存在几个值得关注的弱点。首先，上下文原生轨迹的构建高度依赖LLM生成的PR摘要和精炼commit消息（使用Qwen3-235B），但论文没有系统性地评估这些LLM生成内容的质量对下游性能的影响——如果摘要质量不佳，可能引入噪声。改进方向是对LLM生成的内容进行质量过滤或用多个模型交叉验证。其次，环境原生轨迹的规模（3.1B tokens）相比上下文原生轨迹（68.6B tokens）小了一个数量级，这可能限制了模型对真实执行反馈的学习深度。当前的可执行环境构建依赖Docker镜像，成本高昂且覆盖的仓库有限，未来可以探索更轻量级的环境模拟方案。第三，训练中对Denvpass进行了3倍上采样，但没有分析不同的上采样比例对性能的影响，这个超参数的敏感性未知。第四，论文的scaling实验（Figure 4）使用的是Dctxpy + Denv混合数据，但最终模型使用的是Dctx + Denv，两种配置的scaling行为可能不同。
未来方向
作者提出了几个明确的未来方向。在数据扩展方面，作者指出当前Dctxgen只使用了top 10,000个star最多的仓库，而GitHub上有约3亿个PR分布在约10亿个公开仓库中，扩展语言覆盖和放宽过滤条件可以显著扩大语料库。在可执行监督扩展方面，SWE-REBENCH已经展示了将PR数据自动转化为带Docker环境和单元测试的可执行任务的可行性，随着仓库覆盖的扩展，这一方向有巨大潜力。基于本文成果可延伸的方向包括：（1）将智能体原生中期训练范式扩展到其他领域（如数据科学、DevOps），验证'智能体原生数据'概念的通用性；（2）探索中期训练与RL的深度结合，当前结果仅用SFT就很强，加上RL可能进一步突破；（3）研究不同基础模型系列（如Llama、Mistral）上的效果，验证方法的普适性；（4）引入更复杂的多轮交互场景（如多issue协作、跨仓库依赖），提升模型处理真实复杂开发任务的能力。
复现评估
本文在复现性方面做出了显著贡献。作者承诺将开源大量数据构建代码、训练配置和模型检查点，这在该领域是非常有价值的——很多先前工作（如KIMI-DEV）的中期训练检查点并不公开。数据方面，上下文原生轨迹的构建流程详细描述了数据源（GitHub API）、过滤条件（star数、PR状态、文件数量）和重建步骤（LLM增强、文件识别、模板组织），并提供了具体的prompt模板。环境原生轨迹的构建遵循SWE-REBENCH的公开方法。训练方面，超参数（batch size、学习率、warmup比例、epoch数）都有明确记录。复现的主要挑战在于算力需求：中期训练涉及73.1B tokens的训练，需要多GPU集群；环境原生轨迹的收集需要在Docker环境中运行智能体，计算开销也不小。此外，使用Qwen3-235B生成PR摘要也增加了复现门槛。整体而言，对于有充足算力的研究团队，复现是可行的；对于资源有限的团队，可以直接使用作者开源的检查点进行后续研究。
论文图表