为解决这一痛点[pain point]，我们提出了SWE-smith------一个用于大规模生成软件工程训练数据的新型流水线[a novel pipeline for generating software engineering training data at scale]。对于任意Python代码库，SWE-smith能够自动构建对应的执行环境，并自动合成数百至数千个任务实例[task instances]，这些实例会导致代码库中已有的测试用例失败。借助SWE-smith，我们构建了一个包含5万条实例、来源于128个GitHub仓库的数据集，规模比此前所有工作大一个数量级。
语言模型（LM）智能体，如SWE-agent（Yang et al., 2024a）和OpenHands（Wang et al., 2024），在自动化软件工程[automating software engineering]（SE）任务方面取得了显著进展，这一进展由SWE-bench（Jimenez et al., 2024b）等基准测试持续追踪。
然而，最有效的智能体仍依赖于专有语言模型，因为构建面向软件工程的开源语言模型仍受制于大规模、高质量训练数据的匮乏。为确保开源研究在该领域持续保持竞争力，开发可大规模收集软件工程训练数据的基础设施至关重要。
当前开源生态系统为训练软件工程语言模型提供了两类数据来源。一种简单的方法是从GitHub仓库中爬取拉取请求（pull requests, PR）和议题（issue）。然而，由于缺乏执行环境或测试用例，这些实例无法对生成的解决方案进行可靠验证，语言模型只能从代码的表层形式[the surface form of code]中学习（Xie et al., 2025a），或依赖基于表面字符串相似度的奖励信号[rewards based on superficial string similarity]（Wei et al., 2025）。
相比之下，SWE-bench通过对提出的解决方案运行 单元测试[unit tests]，提供了可靠的验证机制。另一类工作则将SWE-bench的数据收集策略[SWE-bench collection strategy]直接扩展到新的代码仓库，用于训练目的（Pan et al., 2024）。这为训练和蒸馏语言模型智能体提供了灵活的环境，因为我们可以生成智能体轨迹[agent trajectories]并根据单元测试结果对其进行过滤。
然而，该方法的可扩展性受到SWE-bench数据收集策略本身局限性的严重制约。SWE-bench的过滤流程最终只保留了少量[pull requests]PR------这些PR不仅需要解决一个GitHub议题，还需要对单元测试进行有实质意义的修改。此外，为每个实例配置执行环境需要大量的人工干预。
本文介绍了SWE-smith工具包，它将SWE-bench灵活的执行环境与可扩展的实例收集方法有机结合（见图1）。
Figure 1: Scaling task instances (left) and performance (right) for SWE-agent's with SWE-smith. Using SWE-smith, we can create 100s to 1000s of instances for any Python codebase,
enabling us to train SWE-agent-LM-32B which achieves 40.2% on SWE-bench Verified.
SWE-smith集成了多种在现有GitHub仓库中自动合成缺陷的技术，包括：（1）利用语言模型生成函数的错误重写[errant rewrites of functions]；（2）以程序化方式修改函数的抽象语法树（abstract syntax tree, AST）；（3）[undoing]撤销已有PR；（4）组合多个缺陷[combining bugs]。
Figure 2: SWE-smith creates training data for software engineering agents by crafting bugs
into real codebases. Given a codebase, we employ several strategies to create task instances
that break existing tests. Using SWE-smith, we create 50k+ task instances with execution
environments from 128 real world repositories.
The scope handling functions in `oauthlib.oauth2.rfc6749.utils` are producing incorrect results. When converting between scope lists and strings, the order is getting reversed and some edge cases are not handled properly.
Steps/Code to Reproduce
python复制代码
from oauthlib.oauth2.rfc6749.utils import list_to_scope, scope_to_list, params_from_uri
# Test scope list to string conversion
scope_list = ['read', 'write', 'admin']
scope_string = list_to_scope(scope_list)
print(f"Expected: 'read write admin', Got: '{scope_string}'")
# Test scope string to list conversion
scope_string = "read write admin"
result_list = scope_to_list(scope_string)
print(f"Expected: ['read', 'write', 'admin'], Got: {result_list}")
# Test None handling
none_result = scope_to_list(None)
print(f"Expected: None, Got: {none_result}")
# Test URI parameter parsing
uri = 'http://example.com/?scope=read+write&other=value'
params = params_from_uri(uri)
print(f"Expected scope as list, Got: {params}")
The scope conversion functions are not working as expected - the order is reversed and None values are handled incorrectly. This breaks OAuth2 token parsing and request preparation.
--- a/oauthlib/oauth2/rfc6749/utils.py
+++ b/oauthlib/oauth2/rfc6749/utils.py
@@ -15,8 +15,8 @@ def list_to_scope(scope):
"""Convert a list of scopes to a space separated string."""
if isinstance(scope, str) or scope is None:
return scope
- elif isinstance(scope, (set, tuple, list)):
- return " ".join([str(s) for s in scope])
+ elif isinstance(scope, (tuple, list)):
+ return " ".join(str(s) for s in reversed(scope))
else:
raise ValueError("Invalid scope (%s), must be string, tuple, set, or list." % scope)
@@ -24,17 +24,18 @@ def list_to_scope(scope):
def scope_to_list(scope):
"""Convert a space separated string to a list of scopes."""
if isinstance(scope, (tuple, list, set)):
- return [str(s) for s in scope]
+ return [s for s in scope]
elif scope is None:
- return None
+ return []
else:
- return scope.strip().split(" ")
+ return scope.split()
def params_from_uri(uri):
params = dict(urldecode(urlparse(uri).query))
if 'scope' in params:
- params['scope'] = scope_to_list(params['scope'])
+ params['scope'] = scope_to_list(params['scope'][-1])
+ params['timestamp'] = None
return params
@@ -50,11 +51,11 @@ def host_from_uri(uri):
sch, netloc, path, par, query, fra = urlparse(uri)
if ':' in netloc:
- netloc, port = netloc.split(':', 1)
+ port, netloc = netloc.split(':', 1)
else:
- port = default_ports.get(sch.upper())
+ port = default_ports.get(sch.lower())
- return netloc, port
+ return port, netloc
def escape(u):
简而言之，SWE-smith提出了如图2所示的任务创建工作流程。给定一个代码库[codebase]，我们使用SWE-agent（Yang et al., 2024a）自动构建相应的执行环境。在此环境中，我们利用上述技术自动合成数百至数千个任务实例。最后，我们借助语言模型自动生成真实感强的议题描述[issue descriptions]。
反转PR（即"PR镜像"）[Invert PRs (or "PR Mirror")]： 针对每个仓库，我们收集所有修改Python文件的PR。对于每个PR，我们尝试在当前版本的仓库中撤销其修改。为此，我们将PR的代码变更（.diff纯文本）提供给语言模型，提示其对每个受影响的文件进行重写，使PR的编辑被还原。与SWE-bench不同，我们不检出PR的基础提交[PR's base commit]，因为上一步骤确定的安装规范可能与仓库的旧版本不兼容。
Table 8: The 13 procedural modification techniques we use to create bugs in a codebase. The
"Criteria" column contains indices referencing the corresponding filter defined in Table 7 .
There are four informal categories --- Class, Control Flow, Expressions, Removal --- which
indicates the general type of modification being made.
Execution-based validation of candidates.基于执行的候选验证。
How difficult are SWE-smith task instances?SWE-smith任务实例的难度如何？
为评估SWE-smith生成的任务实例是否真实且具有挑战性，我们基于Chowdhury et al.（2024）提供的1,699条人工标注（任务，标签）数据对Qwen 2.5 32B模型进行训练，使其能够将任务评定为（简单、中等、困难）三个难度级别。为量化难度，三个难度标签分别对应数值1/5/9。该模型在测试集上达到75.3%的准确率。
随后，我们对SWE-smith和此前SWE-bench风格数据集（Chowdhury et al., 2024; Jimenez et al., 2024b; Pan et al., 2024; Yang et al., 2024b）中的任务实例进行难度评估。SWE-smith任务实例涵盖了广泛的难度范围，与SWE-bench和SWE-gym相近。SWE-smith的平均难度得分（各缺陷生成策略介于5.27至5.72之间）与SWE-bench（5.01）和SWE-gym（5.62）相当。
与SWE-bench为每个任务实例创建一个Docker镜像的做法不同，SWE-smith采用了更简洁的设计------同一仓库的所有任务共享同一执行环境[tasks from the same repository share the same environment]，从而显著降低了存储开销，如表2所示。
Table 2: Comparison of open source training datasets for software engineering tasks.
Relative to existing datasets, SWE-smith has multiple times the number of task instances,
repositories, and environments at a fraction of prior storage costs. SWE-fixer and SWE bench-train task instances do not have execution environments, so "Env. Size" is blank.
这一方案不仅使大规模扩展任务实例的成本更加可控，还使SWE-smith比现有数据集更易于获取和维护。我们估计，若使用SWE-bench的方式创建同等数量（5万条）的任务实例，仅执行环境就需要50至150TB的存储空间，是SWE-smith的500倍。
为探究SWE-smith在训练软件工程智能体方面的实用价值，我们采用拒绝 采样微调[sampling fine-tuning]（Yuan et al., 2023）作为基于SWE-smith提升基础语言模型的主要方法。我们的实验流程如下。
首先，我们从SWE-smith任务实例中筛选出一个子集[a subset of SWE-smith task instances]。接着，我们使用专家模型驱动的智能体系统在该子集上运行。在此步骤中，每次运行对应的轨迹会被完整记录下来。然后，我们使用成功解决问题的实例所对应的轨迹，对基础模型（即"学生"模型）进行微调。最后，我们在独立的测试集上评估由学生模型驱动的智能体系统的表现。
Models.模型
作为专家模型，我们使用claude-3-7-sonnet-20250219（Anthropic, 2025）。为与先前工作（Pan et al., 2024）进行公平比较，我们还使用了claude-3-5-sonnet-20240620和gpt-4o-2024-08-06。我们采用Qwen-2.5-Coder-Instruct（Hui et al., 2024）的7B和32B系列作为基础模型。
Agent system.智能体系统
我们使用SWE-agent（Yang et al., 2024a）作为智能体系统，该系统专为解决**GitHub议题[GitHub issues]**而设计。SWE-agent为基础语言模型提供了一个智能体计算机接口（Agent Computer Interface, ACI），使其能够更高效地与代码库进行交互。
在每一步，SWE-agent提示语言模型生成ReAct（Yao et al., 2023b）风格的**（思考，行动）对[(thought, action) pair]** ，其中**行动[action]**为编辑文件或执行Shell命令之一。我们选择SWE-agent的原因在于，在撰写本文时，搭载Claude 3.7 Sonnet的SWE-agent是SWE-bench上表现最优的开源方案。在使用专家模型生成轨迹时，我们将SWE-agent的运行步数上限设为75步，费用上限设为2.00美元。在学生模型的推理阶段，我们同样设置75步的上限，并将温度参数固定为0.0。
Evaluation metrics.评估指标
我们在SWE-bench的Lite和Verified（Chowdhury et al., 2024）子集上进行评估。SWE-bench通过让AI系统解决来自12个真实GitHub仓库的软件问题，来评估其能力。Lite子集包含300条实例，被筛选为难度较低、运行成本较小的评估集。Verified子集是由人工筛选的500条实例组成的子集，以问题描述更清晰、评估结果更可靠为筛选标准。
Figure 9: An overview of pipelines in SWE-smith. Scripts/functions and manual steps
are highlighted in blue . Artifacts that are also the inputs and outputs of these scripts are
in orange . SWE-smith fits in seamlessly with the SWE-bench and SWE-agent ecosystem.
Use SWE-smith to construct execution environments and generate task instances. Use SWE-
agent to generate expert trajectories on SWE-smith task instances and run inference with
models trained on these trajectories. Use SWE-bench to evaluate how good your models are
at resolving GitHub issues and performing software engineering tasks.
The scope handling functions in oauthlib.oauth2.rfc6749.utils are producing incorrect results. When converting between scope lists and strings, the order is getting reversed...
- elif isinstance(scope, (set, tuple, list)):
- return " ".join([str(s) for s in scope])
+ elif isinstance(scope, (tuple, list)):
+ return " ".join(str(s) for s in reversed(scope))
Table 3: Resolve rates for existing solutions on SWE-bench Lite and Verified, collected
from Jimenez et al. ( 2024a ), compared to models fine-tuned on SWE-smith. All performance
numbers are pass@1. We do not compare against systems that use verifiers or multiple
attempts at test time.
表3对比了在5,016条SWE-smith轨迹上微调的Qwen 2.5 Coder Instruct模型（7B和32B）的性能表现。我们将其分别称为SWE-agent-LM-7B和SWE-agent-LM-32B，其中后者达到了当前最优水平。最终包含5,016条训练样本的数据集按如下方式筛选得到。
我们收集大量专家轨迹作为候选池。首先，我们完成了第4.1节中的所有消融实验，得到初始的5,105条轨迹。接着，基于我们观察到 **PR镜像[PR Mirror]**和LM Rewrite类型的任务实例能产生最有效的专家轨迹（详见下文），我们对所有此类任务实例运行专家模型，将总数提升至6,457条任务实例。最终，我们尝试为8,686个唯一任务实例生成专家轨迹，占SWE-smith数据集总量的17.3%。与第2.2节难度评估结论相印证，我们观察到SWE-smith任务实例对当前顶尖智能体系统而言并非易事。最终的6,457条轨迹，对应于针对8,686个任务实例共17,906次尝试中36%的解决率。
接下来，我们对该集合进行小幅过滤。与Pan et al.（2024）的报告一致，我们同样观察到"较简单"的轨迹------即在多次运行中被反复解决的任务实例------会降低模型性能。因此，我们将任意一条SWE-smith任务实例在训练集中出现的轨迹数量上限设为3条。由此得到最终包含5,016条样本的训练集。
Performance improves with more data points.训练数据量增加有助于提升性能
延续Jain et al.（2025）和Pan et al.（2024）中的类似图示，图1展示了随轨迹数量增加性能持续提升的趋势。
Comparison at the same training set size.相同训练集规模下的对比
为与先前工作（Jain et al., 2025; Pan et al., 2024）进行对比，我们使用SWE-agent搭配Claude 3.5 Sonnet（800条）或GPT-4o（200条）在1,000个随机SWE-smith任务实例上生成专家轨迹。随后，我们在500条成功轨迹上对32B模型进行微调，这一训练集规模与上述两项工作保持一致。
我们的模型在SWE-bench Verified上达到28.2%的解决率，相较于Pan et al.（2024）提升8.2%，相较于Jain et al.（2025）提升0.7%。
