# coding agent数据合成-qwen调研


这篇调研聚焦 `coding agent` 训练里最关键的一环：**高质量、可验证、可复现的数据合成**。如果把近两年的主线压缩成一句话，那就是：行业正在从“纯合成题”转向“以真实软件工程活动为种子，再做自动化增强”的 `SWE-bench` 式范式。

对于 `Qwen` 这一类希望持续提升复杂编码能力的模型，这条路径的意义尤其直接：它不仅决定模型能否在 benchmark 上刷出更高分，更决定模型是否真正具备在真实仓库里定位问题、搭环境、写补丁和通过测试的能力。

<!--more-->
## 范式演进：从纯合成到“真实-合成”混合数据的转变

近年来，大语言模型（LLM）在通用编码能力方面的显著进步，很大程度上归功于一种以SWE-bench为代表的全新数据合成范式。这一范式的演进标志着领域内认知的根本性转变：从早期依赖完全人工或简单程序化生成的纯合成数据，转向以真实世界软件工程活动为基础、进行精细化处理和增强的“真实-合成”混合数据。这一转变的驱动力在于研究者们日益清晰地认识到，仅靠纯合成数据训练出的模型在面对真实世界的复杂性和多样性时，其性能会急剧下降 [[1](https://arxiv.org/html/2510.26130v2)]。早期的纯合成数据策略，如SWE-Smith和SWE-Flow等框架，主要采用测试驱动开发（TDD）等模式，在干净、可控的环境中为简单的bug修复或功能添加编写代码和测试用例 [[4](https://arxiv.org/html/2512.17419v1), [52](https://arxiv.org/pdf/2506.09003)]。这种方法虽然能够生产大量具有明确验证逻辑的训练样本，但其生成的任务往往缺乏现实世界软件中存在的噪声、模糊性、不一致性以及复杂的上下文依赖关系，导致模型学到的知识无法有效泛化到真实的编程场景中 [[4](https://arxiv.org/html/2512.17419v1)]。

SWE-bench的出现是这一范式转变的里程碑事件 [[7](https://www.swebench.com/original.html), [38](https://arxiv.org/html/2507.09108v5)]。它不再创造虚拟的任务，而是直接从GitHub平台已解决的Pull Requests (PRs) 中挖掘真实的、人类开发者已经修复的bug案例 [[7](https://www.swebench.com/original.html)]。这使得评估和训练任务能够更贴近实际的软件工程工作流。然而，原始的PR本身并不能直接用作高质量的训练或评估数据，因为它们通常缺少可复现的测试环境、明确的测试断言，甚至可能包含不完整的代码。因此，后续所有先进的合成框架，无论是学术界的SWE-Synth，还是工业界的SWE-Hub、OpenSWE和SWE-Bench++，都建立在同一个核心思想之上：以真实开源项目中的PR/Issue作为种子，通过一系列自动化和半自动化流程，构建一个完整的、可执行的、有明确验证逻辑的合成任务。这个过程本身就是一个复杂的数据工厂流水线，其产出物的质量直接决定了下游LLM编码能力的上限。

## 工业界实践：规模化、自动化的“数据工厂”模式

工业界，特别是大型科技公司的实践，代表了当前数据合成领域的最高水平，其特点是极致的规模化、高度的自动化以及端到端的工程解决方案。这些实践本质上是将数据合成视为一项生产任务，追求的是可扩展、可持续且能产生最大商业价值的成果。SWE-Universe是一个杰出的范例，它利用一个专门定制训练的builder模型，在阿里云的大规模计算集群上实现了并行处理，从超过52,000个不同的GitHub仓库中，自动生成了一个包含807,693个多语言、可验证训练实例的庞大数据集 [[51](https://arxiv.org/html/2602.02361v1)]。这种规模是纯粹学术研究难以企及的。同样，OpenSWE框架投入了约147万美元的成本，构建了包含45,320个可执行Docker环境的大规模Python数据集，并包含了用于复现的所有基础设施代码，体现了对生产级部署和可复现性的高度重视 [[50](https://arxiv.org/html/2603.13023v1)]。

工业界的数据合成系统不仅是数据生成器，更是完整的“数据工厂”，涵盖了从源头到应用的整个数据生命周期管理。首先，在**环境自动化**方面，工业界开发了复杂的流水线来自动化构建可复现的测试环境。例如，SWE-Bench++采用了模板引导的Dockerfile生成，并结合迭代反馈循环，根据构建和测试的结果不断调整和完善环境配置，从而将Python仓库的产量提升了约137% [[4](https://arxiv.org/html/2512.17419v1)]。OpenSWE则部署了一个由多个代理组成的合成管道，在64节点集群上自动化完成从仓库探索、Dockerfile生成到测试脚本编写的全过程 [[50](https://arxiv.org/html/2603.13023v1)]。其次，在**质量保障**方面，工业界引入了专门的质量保证模块。SWE-Bench Atlas框架包含一个自动化质量保证模块，确保环境的确定性，避免因环境差异导致结果不可复现 [[11](https://openreview.net/forum?id=Gxw1EDSm9S)]。最后，也是最关键的，工业界追求形成**生产闭环**。生成的高质量数据被直接用于大规模模型的训练和微调，形成“数据生成 -> 训练 -> 性能提升 -> 新数据生成”的良性循环。例如，SWE-Universe生成的数据被用于训练阿里巴巴的旗舰模型Qwen3-Max-Thinking，使其在SWE-Bench Verified基准上的得分达到了惊人的75.3%，展示了合成数据在生产级别上的巨大威力 [[51](https://arxiv.org/html/2602.02361v1)]。这种模式也意味着工业界对成本极为敏感，OpenSWE的百万美元预算清晰地表明，高质量数据合成是一项昂贵的投资 [[50](https://arxiv.org/html/2603.13023v1)]。因此，工业界更倾向于寻找高性价比的方案，例如SWE-Bench++的研究表明，用少量经过精心筛选的真实轨迹就能显著提升模型性能，显示出边际效益递减的特点，这为资源优化提供了重要指导 [[4](https://arxiv.org/html/2512.17419v1)]。

## 学术界探索：基准创新与高效合成机制的理论突破

与工业界追求规模化和生产落地不同，学术界的工作为整个领域奠定了坚实的理论基础，并不断推动着边界的拓展。学术界的贡献主要集中在三个方面：创新的基准与评估框架、对合成机制的深入理论探索，以及低成本高效的替代方案的探索。学术界是新基准的主要贡献者，他们不仅延续了SWE-bench的成功，还针对特定需求进行了扩展和深化。例如，Multi-SWE-bench专注于多语言场景下的问题解决，覆盖了Java、TypeScript、Rust等多种流行语言 [[30](https://arxiv.org/html/2504.02605v1)]；Rust-SWE-bench则致力于解决Rust生态中的特有问题 [[10](https://arxiv.org/html/2602.22764v1)]；而SWE-Bench Mobile则将评估范围延伸至移动应用开发领域 [[25](https://arxiv.org/html/2602.09540v1)]。此外，学术界也保持着批判性思维，不断反思现有基准的潜在问题。例如，有研究通过诊断性任务发现，模型在SWE-bench上的优异表现可能部分源于对训练数据的记忆而非真正的推理能力，这揭示了数据污染的巨大风险 [[9](https://www.microsoft.com/en-us/research/publication/the-swe-bench-illusion-when-state-of-the-art-llms-remember-instead-of-reason/)]。

在合成机制的理论探索方面，学术研究更深入地探讨了“如何合成”才能最有效地提升模型能力。SWE-Synth框架便是一个典型例子，它明确提出高质量的合成数据应具备四个关键特性：产生的漏洞要像人类开发者一样自然，能够扩展到大型代码库，拥有自动化的验证方式，并能提供展示开发者迭代修复过程的中间轨迹 [[33](https://arxiv.org/html/2504.14757v1)]。这一理论框架引导了合成数据不仅要“正确”，更要“像人做的”，为生成更具学习价值的数据提供了明确指引。由于资源限制，学术界也积极探索更高效的合成方法。SWE-World是其中的杰出代表，它彻底颠覆了传统的Docker化环境构建方式。该框架通过训练两个LLM代理——一个用于模拟物理环境的步进反馈（transition model），另一个用于判断最终结果是否正确的奖励模型（reward model），从而实现了完全无需物理Docker容器的训练和评估 [[28](https://arxiv.org/html/2602.03419v1)]。这种方法极大地降低了基础设施门槛，证明了高质量合成数据可以在高度抽象的虚拟环境中生成，从而极大提升了数据生产的效率和可扩展性。这种对数据质量和生产效率的不懈追求，构成了学术界推动该领域发展的核心动力。

## 技术路径详解：构建可复现软件工程任务的核心工艺

现代数据合成流水线已经形成了一套标准化的、多阶段的工艺流程，其核心目标是将一份看似普通的GitHub PR转化为一个结构完整、可执行且有明确验证标准的软件工程任务。这一过程可以解构为以下几个核心技术环节：

1.  **任务源选择与获取**：这是所有工作的起点。目前最主流的方法是从GitHub的公开Pull Requests (PRs)中挖掘 [[4](https://arxiv.org/html/2512.17419v1), [7](https://www.swebench.com/original.html)]。为了保证数据集的质量和多样性，先进的框架通常会设定一套严格的筛选标准，例如PR的大小、提交历史、仓库的活跃度和社区声誉等，以确保所选任务既有代表性又具备一定的难度 [[11](https://openreview.net/forum?id=Gxw1EDSm9S)]。
2.  **环境合成**：这是最具挑战性的一步，目标是为每个选定的PR创建一个可独立运行的、确定性的测试环境。大多数框架，如OpenSWE、SWE-Universe和SWE-Bench++，都采用在Docker容器内构建环境的方法 [[4](https://arxiv.org/html/2512.17419v1), [50](https://arxiv.org/html/2603.13023v1), [51](https://arxiv.org/html/2602.02361v1)]。这需要自动化地解析项目的依赖项、安装工具链、并编写可复现的`Dockerfile`。SWE-World则是此步骤的颠覆者，它用LLM代理学习物理环境的反馈和奖励，彻底摆脱了Docker的束缚 [[28](https://arxiv.org/html/2602.03419v1)]。
3.  **验证逻辑提取**：有了可复现的环境，下一步就是定义什么是“正确”的答案。验证逻辑通常来自于PR中包含的单元测试。SWE-Bench++引入了一种精巧的“状态差分法”作为验证引擎 [[4](https://arxiv.org/html/2512.17419v1)]。它会比较三个关键的仓库状态：父提交（Base）、合并测试文件但未应用代码变更前（Before），以及完整PR应用后的状态（After）。通过对比测试结果的变化，可以自动区分出“bug修复”（测试用例由失败变为通过）和“功能请求”（Before状态下因缺少新函数符号而无法编译，After状态下新增的测试用例能够成功通过）。这是一种非常强大的自动化分类和验证机制。此外，为了处理各种各样的测试输出格式，SWE-Bench++还采用了混合日志解析策略：先尝试使用确定性的正则表达式进行匹配，如果失败，则调用LLM生成自定义的Python解析器，并通过注入人工故障来验证其准确性 [[4](https://arxiv.org/html/2512.17419v1)]。
4.  **数据增强与轨迹合成**：这是提升数据价值的关键。对于那些模型很难解决的难题，可以通过人为提供函数签名、依赖图等“提示”来辅助合成修复轨迹，从而将原本无效的数据转化为有价值的训练样本 [[4](https://arxiv.org/html/2512.17419v1), [11](https://openreview.net/forum?id=Gxw1EDSm9S)]。SWE-Synth框架则更进一步，利用LLM Agent模拟开发者从定位错误、编写代码、调试到最终修复的全过程，生成包含中间步骤的结构化修复轨迹 [[5](https://arxiv.org/abs/2504.14757), [33](https://arxiv.org/html/2504.14757v1)]。这为模型提供了远比单纯的“输入-输出”对更丰富的学习信号。
5.  **数据清洗与过滤**：最后，必须对海量生成的数据进行严格的筛选。OpenSWE的质量中心过滤管道就是一个典型例子，它会表征每个环境的内在难度，并主动过滤掉那些过于简单或环境不可复现的实例，以最大化学习效率 [[50](https://arxiv.org/html/2603.13023v1)]。

| 核心环节 | 关键技术/方法 | 目标与作用 |
| :--- | :--- | :--- |
| **任务源选择** | 爬取GitHub Pull Requests，并基于仓库活跃度、PR大小等标准进行筛选 [[11](https://openreview.net/forum?id=Gxw1EDSm9S)]。 | 确保任务来源的真实性和多样性，为合成高质量数据奠定基础。 |
| **环境合成** | Dockerfile自动化生成、迭代反馈循环、LLM代理学习环境动态 [[4](https://arxiv.org/html/2512.17419v1), [28](https://arxiv.org/html/2602.03419v1)]。 | 创建可复现、确定性的测试环境，使代码修复能够在隔离的沙箱中被验证。 |
| **验证逻辑提取** | 状态差分法、混合日志解析策略 [[4](https://arxiv.org/html/2512.17419v1)]。 | 自动化地识别任务类型（Bug修复 vs. 功能添加），并准确判断代码修复的成败。 |
| **轨迹合成** | 提示引导合成、LLM代理模拟开发者工作流 [[4](https://arxiv.org/html/2512.17419v1), [5](https://arxiv.org/abs/2504.14757)]。 | 生成包含中间步骤的结构化修复轨迹，为模型提供更丰富的学习信号。 |
| **数据清洗** | 难度表征与过滤 [[50](https://arxiv.org/html/2603.13023v1)]。 | 剔除过于简单或无效的任务，保证训练数据的质量和学习效率。 |

## 效果评估与指标演变：量化能力提升与衡量维度深化

数据合成的最终目的是提升模型的编码能力，大量的实验研究已经证实，高质量的合成数据确实能带来显著的性能提升。多个研究报告了具体的量化结果，清晰地展示了这一趋势。例如，一项研究表明，使用SWE-Bench++框架生成的数据对Qwen2.5-Coder-7B模型进行微调，使其在SWE-bench Multilingual基准上的pass@1分数从5/300提升至11/300，性能翻倍 [[4](https://arxiv.org/html/2512.17419v1)]。在更权威的SWE-bench Verified基准上，经过大规模真实世界数据训练的模型取得了更高的成就：OpenSWE-32B模型达到了62.4%的Pass@1分数，而SWE-Universe生成的数据则帮助Qwen3-Max-Thinking模型取得了75.3%的惊人成绩 [[50](https://arxiv.org/html/2603.13023v1), [51](https://arxiv.org/html/2602.02361v1)]。这些数字有力地证明，针对性的、高质量的合成数据能够系统性地推动模型在复杂编码任务上的表现。

一个更为重要的发现是，经过真实世界合成数据训练的模型，其能力不仅能迁移到其他类似的编码基准，还能泛化到其他领域。OpenSWE的实验表明，其模型在数学推理（MATH-500）和科学问答（SuperGPQA）等非编码任务上也取得了显著的提升，幅度高达12个百分点 [[50](https://arxiv.org/html/2603.13023v1)]。这暗示着，解决真实世界软件问题所涉及的复杂推理、规划、知识整合和跨文件理解能力，可能是LLM通用智能的一个重要体现。当模型被要求处理充满噪声、文档缺失、逻辑复杂的现实代码库时，其所展现的能力远超简单的算法实现。

随着研究的深入，评估指标也在不断演变，从单一的“能否完成任务”转向“如何完成任务”。**Pass@k**（允许模型在k次尝试内成功修复任务的概率）已成为衡量LLM在SWE任务上表现的黄金标准，因为它更能反映模型在面对困难任务时的鲁棒性 [[65](https://arxiv.org/html/2602.10090v1), [136](http://lonepatient.top/2026/02/26/arxiv_papers_2026-02-26)]。然而，单一的Pass@k指标已不足以全面评估模型的高级能力。新的、更细粒度的指标开始涌现。例如，FeedbackEval基准提出的**Repair@k**指标，评估模型在经历k轮基于反馈的迭代修复后，代码通过率的变化，这更贴近开发者调试的真实过程 [[94](https://arxiv.org/html/2504.06939v2)]。Loc-Bench则专注于评估模型定位错误代码位置的能力，这对于长文件和大型项目的修复至关重要 [[138](https://arxiv.org/html/2602.19407v1)]。这些新指标的出现，反映出评估体系正在变得更加精细和全面，更加关注模型解决问题的过程和内部机制。

## 局限、挑战与未来展望：迈向更真实、智能的合成数据

尽管以SWE-bench范式为代表的数据合成方法取得了显著成效，但该领域仍面临着诸多严峻的挑战，这些挑战也为未来的研究指明了方向。当前最大的隐患是**数据污染与评估有效性危机**。有研究通过设计精巧的诊断性任务发现，模型在SWE-Bench上的优异表现可能部分源于对训练数据的记忆，而非真正的推理能力 [[9](https://www.microsoft.com/en-us/research/publication/the-swe-bench-illusion-when-state-of-the-art-llms-remember-instead-of-reason/)]。当训练数据的来源（如某个特定的GitHub仓库）与评估数据重叠时，模型可能会“作弊”，导致评估结果严重高估其真实能力。SWE-Bench++和SWE-Bench Atlas等框架通过持续摄入最新的PR来缓解这个问题，但这是一个持续的“猫鼠游戏”，对抗数据污染将成为长期存在的挑战 [[4](https://arxiv.org/html/2512.17419v1), [11](https://openreview.net/forum?id=Gxw1EDSm9S)]。

其次是**成本与可扩展性的矛盾**。构建高质量数据集的成本极高，例如OpenSWE的百万美元预算清晰地表明，这是一项昂贵的投资 [[50](https://arxiv.org/html/2603.13023v1)]。高昂的成本限制了这项技术的普及，使得只有少数拥有雄厚财力的机构才能参与其中。尽管SWE-World和SWE-Universe等方法试图通过自动化和去Docker化来降低成本，但这方面的根本性突破仍然是该领域亟待解决的问题。此外，**合成数据的真实性与多样性**依然是一个问题。虽然live PRs比TDD模式更具现实感，但它们仍然主要反映了开源社区的主流实践 [[4](https://arxiv.org/html/2512.17419v1)]。未来需要更多样化的数据源，例如考虑商业闭源代码（如果能安全合规地访问）、不同规模团队的协作模式、以及更多元的编程文化和风格，以进一步提升模型的泛化能力。

另一个显著的局限是**能力鸿沟**：目前绝大多数合成数据集中在bug修复（Automated Program Repair, APR）任务上 [[62](https://arxiv.org/pdf/2505.07372?), [127](https://dl.acm.org/doi/10.1145/3631974)]。虽然SWE-Bench++也能处理feature request [[4](https://arxiv.org/html/2512.17419v1)]，但整体上，针对更复杂的软件开发活动，如系统设计、架构演进、性能优化、安全性增强等方面的数据合成，仍然是广阔的蓝海领域。未来的趋势将沿着几个方向发展：第一，**自动化与智能化**，合成流水线将进一步自动化，LLM Agent将在其中扮演更核心的角色，从任务选择、环境构建到轨迹生成全程参与，实现更高程度的自主合成。第二，**仿真环境的成熟**，SWE-World所代表的“元宇宙”式仿真环境将成为主流，降低基础设施依赖，极大提升数据生产速度和规模。第三，**对抗性与红队测试**，合成数据将不仅仅用于正面训练，还将用于主动“攻击”模型，生成具有欺骗性或边缘性的任务，以检验和提升模型的鲁棒性 [[78](https://arxiv.org/html/2508.00923v2), [137](http://arxivdaily.com/thread/72172)]。第四，**跨领域知识迁移**，研究将更深入地探索编码能力与其他认知能力（如数学、科学、逻辑）之间的联系，利用合成数据促进模型的通用智能发展。

## 参考链接

- [SWE-bench: Can Language Models Resolve Real-World GitHub Issues?](https://arxiv.org/abs/2310.06770)
- [SWE-bench 官方网站](https://www.swebench.com/)
- [SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering](https://arxiv.org/abs/2405.15793)
- [SWE-bench Multimodal: Do AI Systems Generalize to Visual Software Domains?](https://arxiv.org/abs/2410.03859)
- [The SWE-bench Illusion: When State-of-the-Art LLMs Remember Instead of Reason](https://www.microsoft.com/en-us/research/publication/the-swe-bench-illusion-when-state-of-the-art-llms-remember-instead-of-reason/)