主流的议题解决框架主要依赖商业模型，导致高昂成本和隐私问题。现有的议题解决训练方法在泛化能力方面表现不佳，未能充分利用开源开发资源。我们提出了 S ubtask- o riented R einforced F ine- T uning（ SoRFT ），一种新的训练方法，以增强大语言模型（LLM）的议题解决能力。我们将议题解决分解为结构化的子任务：文件定位、函数定位、行定位和代码编辑生成。SoRFT包含两个训练阶段：（1） 拒绝采样监督微调 ，使用真实标签对链式思维（CoT）数据进行过滤后再对LLM进行微调，以及（2） 基于规则的强化学习 ，利用基于真实标签的奖励机制应用PPO。我们在SWE-Bench Verified和SWE-Bench Lite上评估了SoRFT训练的模型，达到了开源模型中的最佳性能（例如，在SWE-Bench Verified上，SoRFT-Qwen-7B解决了21.4%的问题）。实验结果表明，SoRFT显著增强了议题解决性能，改善了模型的泛化能力，并提供了一种成本效益更高的替代方案。
大型语言模型（LLMs） (OpenAI 2023; Touvron et al. 2023) 在广泛复杂的现实世界任务中表现出色 (Y. Li et al. 2022; J. Li et al. 2024; Wu et al. 2023) ，特别是在软件开发 (Jimenez et al. 2024; Zhao et al. 2024; Z. Ma, An, Xie, et al. 2024) 中表现尤为出色。目前主流的自动化软件开发系统主要使用商业模型 (OpenAI 2023; “Introducing the Next Generation of Claude” 2024) 。然而，商业模型的API调用费用高昂且存在隐私泄露风险，限制了其在行业开发过程中的应用。
基于规则的文件定位子任务奖励示例。LLM根据给定的议题生成CoT数据，然后根据提取的答案和真实答案计算采样的CoT的奖励。
研究社区尝试对开源LLM进行微调 (Q. Team 2024; Guo et al. 2024; “CodeQwen1.5-7B-OpenDevin” 2024; Touvron et al. 2023; Hui et al. 2024; Lozhkov et al. 2024) 以提高其在议题解决任务中的性能。现有方法 (Pan et al. 2024; Z. Ma, An, Lin, et al. 2024; C. Xie et al. 2025; Y. Ma et al. 2024) 使用LLM采样链式思维（CoT） (Wei et al. 2022) 数据，然后根据真实数据进行负样本过滤，并对模型进行微调。虽然这些方法提高了LLM的议题解决能力，但仅依赖监督微调（SFT）可能导致泛化能力差，使模型更容易出现幻觉和事实错误。
最近的研究 (Luong et al. 2024; Guo et al. 2025; Zeng et al. 2025; T. Xie et al. 2025; Mu et al. 2024; K. Team et al. 2025) 探索了基于规则的强化学习以提高复杂任务（如数学）上的模型性能。基于规则的强化学习需要真实标签进行评估，但构建数学问题的真实标签是劳动密集型的。在开源社区中，有大量的已解决问题附带真实补丁。这引发了一个自然的问题： 我们能否利用这些（问题，补丁）对进行基于规则的强化学习，以提高语言模型的议题解决能力？
本文中，我们提出 S ubtask- o riented R einforced F ine- T uning ( SoRFT )， 充分利用正负样本信息以提高模型在议题解决任务中的性能。鉴于议题解决任务的复杂性 (Jimenez et al. 2024) , 构建端到端训练数据具有挑战性。受Agentless (Xia et al. 2024) 的启发，我们将议题解决分解为多个子任务：文件定位、函数定位、行定位和代码编辑生成——并从与问题相关的拉取请求中派生每个子任务的真实答案。然后我们对这些子任务进行强化微调 (Luong et al. 2024) 。
SoRFT 包含两个训练阶段： 拒绝采样监督微调 （SFT）和 基于规则的强化学习 （RL）。在 SFT 阶段，我们使用教师 LLM 为每个子任务生成 CoT 数据，并根据真实答案过滤负样本。然后进行监督微调，以帮助模型掌握子任务结构、潜在推理机制和对议题解决至关重要的输出格式。在 RL 阶段，由于每个子任务都有对应的真实标签，我们采用基于规则的近端策略优化（PPO） (Schulman et al. 2017) 进行训练。具体来说，我们根据每个子任务的真实标签定义评分规则，并使用基于奖励的优化更新 LLM 的参数。此过程进一步提升了模型的议题解决性能。SoRFT 训练的 LLM 在 SWE-Bench Verified 和 SWE-Bench Lite 上实现了最先进（SOTA）的表现，证明了 SoRFT 在增强议题解决能力方面的有效性。本文的主要贡献如下：
- 我们引入了面向子任务的强化微调（SoRFT），为每个议题解决子任务设计了基于规则的奖励，并通过强化微调增强了 LLM 的议题解决能力。
- 我们将在 Agentless 框架内应用 SoRFT 并验证其有效性。
- 我们研究了不同奖励规则对 PPO 训练的影响，提供了设计更稳健奖励规则的见解。
2 背景
本节简要介绍 SWE-Bench、议题解决框架和强化学习算法。
2.1 SWE-Bench
SWE-Bench (Jimenez et al. 2024) 是一个用于评估语言模型解决实际软件问题（如 GitHub 上的 Bug 报告和功能请求）能力的基准。基于 LLM 的编程助手会收到一个问题描述和整个仓库，并被期望生成能够解决问题的代码编辑。SWE-Bench Lite (S.-B. Team 2024) 是 SWE-Bench 的精选子集，专注于评估功能性 Bug 修复。而 SWE-Bench Verified (OpenAI 2024c) 是一个人工验证的子集，旨在解决 SWE-Bench 中的质量问题，如模糊的问题描述。本文中的所有议题解决实验都在 SWE-Bench Lite 和 SWE-Bench Verified 上进行。
2.2 议题解决框架
议题解决框架大致可以分为两类：基于代理的和基于管道的。Openhands (Wang, Li, et al. 2024) 是一个纯粹的 React 风格 (Yao et al. 2022) 的基于代理的框架，用于软件开发任务。 C. Xie et al. (2025) 提出了 SWE-Fixer，一个两阶段的基于管道的系统。 Y. Ma et al. (2024) 提出了 SWE-SynInfer，一个结合管道设计与基于代理的方法的混合框架。此外， Xia et al. (2024) 提出了 Agentless，一个多阶段的基于管道的框架，旨在充分利用 LLM 的推理能力进行议题解决。值得注意的是，Agentless 是 SWE-Bench 领导榜上最先进的（SOTA）基于管道的框架，已被 OpenAI (OpenAI 2024b) 和 DeepSeek (Guo et al. 2025) 用于评估其模型在软件工程任务中的性能。构建议题解决框架的训练数据需要为框架采样 CoT 数据并过滤掉负样本。评估代理框架中间步骤的准确性具有挑战性，而基于管道的框架则能更清晰有效地评估每个阶段的推理准确性。本文基于 Agentless 设计训练子任务，并在实验中采用 Agentless 3 作为推理框架。
2.3 强化学习
在标准的 PPO 算法 (Schulman et al. 2017) 中，使用预训练的奖励模型对响应进行评分。然而，最近的研究 (Guo et al. 2025; K. Team et al. 2025) 表明，依赖奖励模型可能导致奖励欺骗，而采用更客观的评分方法可以有效缓解这一问题。由于议题解决任务可以轻松收集真实标签，我们设计了一套评分规则，专门用于评估议题解决任务的响应。我们将在第 3.3 节介绍奖励规则。
3 方法
如图 [fig:approach] 所示，SoRFT 包含三个部分：（1）议题解决子任务构造，（2）拒绝采样监督微调，和（3）基于规则的强化学习。
3.1 议题解决子任务
为了应对构建端到端训练数据的挑战，我们创建了分阶段的子任务训练数据。如图 [fig:approach] (1) 所示，受高级议题解决框架 (Xia et al. 2024; Y. Ma et al. 2024) 设计模式的启发，我们将议题解决分解为四个子任务：文件定位、函数定位、行定位和代码编辑生成。这种结构化分解使每个任务阶段的训练更加有针对性和高效。
3.1.0.1 文件定位。
文件定位训练增强了 LLM 对仓库高层架构的理解，使其能够根据问题描述初步粗略定位相关文件。我们使用问题和仓库结构作为输入，将 PR 中修改的文件全名作为输出。为了提高训练数据的质量，我们排除了输入和输出中的非 Python 文件和测试脚本。关系可以表示为：
3.1.0.2 函数定位。
函数定位训练可以改进 LLM 在基于代码功能特征的细粒度定位上的表现。在函数定位中，问题和由函数名称组成的文件骨架作为输入，而 PR 中修改的函数名称作为输出。这种关系可以表示为：
3.1.0.3 行定位。
行定位训练增强了 LLM 精确识别需要修改的代码行以解决议题的能力。行定位以问题描述和函数内容为输入，以 PR 中修改的行作为输出。这可以表示为：
3.1.0.4 代码编辑生成。
代码编辑生成训练可以增强 LLM 根据问题修改代码片段的能力。代码编辑的输入包括问题和局部代码片段，输出是相应 PR 的代码编辑。根据先前的工作 (Xia et al. 2024; Yang et al. 2024) ，我们采用 搜索/替换 编辑格式。 搜索/替换 格式包括两个主要部分：1) 搜索：需要修改的目标代码片段；2) 替换：编辑后的代码片段。这种关系可以表示为：
所有子任务都基于开源项目中的已解决问题构建，真实答案从相应的拉取请求中提取。子任务的提示在附录 12 中提供。
3.2 拒绝采样监督微调
我们使用拒绝采样的 CoT 数据对 LLM 进行微调，以增强其对每个子任务格式和推理过程的理解。如图 [fig:approach] (2) 所示，我们使用 LLM 采样 CoT 数据，然后根据真实答案过滤 CoT 数据。具体来说，对于三个定位子任务，我们过滤掉与真实文件、函数或行无重叠的样本。对于代码编辑生成子任务，我们过滤掉与真实编辑修改的行无重叠的样本。最后，我们将所有子任务的 CoT 数据整合起来对 LLM 进行微调，使其能够理解任务格式及其底层推理机制。
3.3 基于规则的强化学习
4 实验
在本节中，我们将介绍我们的评估基准、指标、模型、基线和实现细节。
4.1 基准
我们在两个议题解决基准上进行实验：SWE-Bench Verified 和 SWE-Bench Lite。
SWE-Bench Verified (OpenAI 2024c) 是 SWE-bench (Jimenez et al. 2024) 的手动验证子集，包含 500 个实例。每个实例是一个与 Docker 4 环境中可执行测试用例相关的问题。议题解决框架 (Xia et al. 2024; C. Xie et al. 2025; Wang, Li, et al. 2024; Y. Ma et al. 2024) 被要求理解问题和仓库，生成补丁并通过所有测试用例，提供对其议题解决能力的可靠评估。
SWE-Bench Lite (S.-B. Team 2024) 是 SWE-Bench 的子集，包含 300 个实例，专注于评估功能性 Bug 修复。
4.2 指标
为了评估使用 SoRFT 训练的 LLM 在议题解决框架上的性能，我们应用了两个指标： %Resolved 和 %Applied 。
%Resolved 是应用生成的代码编辑成功通过所有测试用例的样本比例。
%Applied 是议题解决框架成功生成有效代码编辑并可应用于仓库的样本比例。该指标评估框架生成实用和可执行解决方案的能力。
4.3 框架和模型
我们在议题解决框架中应用 Agentless (Xia et al. 2024) 并使用 Qwen2.5-Coder (Hui et al. 2024) 系列作为基础模型。Agentless 是一个先进的开源议题解决框架，被 OpenAI (OpenAI 2024b) 和 DeepSeek (Guo et al. 2025) 用于评估模型在软件工程任务上的性能。对于基础模型，我们使用 Qwen2.5-Coder-7B-Instruct 和 Qwen2.5-Coder-32B-Instruct (Hui et al. 2024) , 这是开源 coder instruct 模型中的最新成果 (Touvron et al. 2023; Guo et al. 2024) 。
4.4 基线
由于议题解决任务需要使用基于代理或基于管道的框架，现有的微调方法通常是为特定框架设计和优化的。在本文中，我们将我们的方法与三个基线进行比较：（1）OpenHands with SWE-Gym-Qwen，（2）SWE-Fixer with SWE-Fixer-Qwen，以及（3）SWE-SynInfer with Lingma-SWE-GPT。
4.4.0.1 Openhands with SWE-Gym-Qwen (Pan et al. 2024) .
Openhands (Wang, Chen, et al. 2024) 是一个纯粹 React 风格 (Yao et al. 2022) 的基于代理的框架，配备了文件查看和 bash 命令执行等工具。该框架使模型能够以 React 方式自主调用这些工具，迭代推理和行动以解决问题。他们收集了 Openhands 调用 GPT-4o (OpenAI 2024a) 和 Claude-3.5-Sonnet ( “Introducing the Next Generation of Claude” 2024) 进行议题解决任务的轨迹，过滤掉失败的轨迹，然后对 Qwen2.5-Coder 模型进行微调以作为 SWE-Gym-Qwen 模型。
4.4.0.2 SWE-Fixer with SWE-Fixer-Qwen (C. Xie et al. 2025) .
SWE-Fixer 是一个两阶段的基于管道的框架。首先，它使用结合 BM-25 和 LLM 的检索器定位要修改的文件，然后使用 LLM 生成对这些文件的代码编辑。他们利用 GPT-4o (OpenAI 2024a) 收集 CoT 训练数据，并对 Qwen2.5-Coder 模型进行微调以作为 SWE-Fixer-Qwen 模型。
4.4.0.3 SWE-SynInfer with Lingma-SWE-GPT (Y. Ma et al. 2024) .
SWE-SynInfer 是一个结合管道设计与基于代理功能的混合框架。在第一阶段，模型依次分析仓库结构、文件骨架和代码片段，生成详细的修改计划。然后，它提供文件查看等工具，允许模型以反应方式调用这些工具并生成最终的代码编辑。类似于 Openhands (Wang, Chen, et al. 2024) , 他们收集了 SWE-SynInfer 调用 GPT-4o (OpenAI 2024a) 进行议题解决任务的轨迹，过滤掉失败的轨迹，然后对 Qwen2.5-Coder 模型进行微调以作为 Lingma-SWE-GPT 模型。
4.5 实现细节
在本小节中，我们将介绍数据构建细节、微调细节和强化学习细节。
4.5.0.1 数据构建。
为了构建我们的训练数据集，我们从 seart-ghs 5 中精选了一组高质量的开源 Python 项目，并应用了一套严格的标准。具体来说，我们选择了满足以下条件的仓库：（1）至少有 1,000 个问题，（2）至少有 1,000 个拉取请求（PR），（3）至少有 100 个星标，（4）包含适当的许可证，（5）排除 forked 仓库，（6）不在 SWE-Bench 测试数据集中以防止数据污染。通过这一严格的筛选过程，我们确定了最终的 660 个仓库。从这些仓库中，我们进一步选择了 100 个仓库来生成 SFT CoT 数据。我们从这些仓库中提取了 30,000 个（问题，PR）对，并制定了相应的子任务。我们使用 Claude-3.5-Sonnet ( “Introducing the Next Generation of Claude” 2024) 采样 CoT 数据，并过滤掉最终答案不符合子任务真实标签的实例，保留了 60k 个训练样本。我们还爬取了剩余仓库的（问题，PR）数据并构建了相应的子任务。在强化学习阶段，我们随机选择 30k 个样本进行训练。
4.5.0.2 微调。
我们使用 FastChat (Zheng et al. 2023) 框架，采用全分片策略和 Pytorch FSDP 实现的 CPU 卸载策略对我们的 7B 模型进行微调，并使用 DeepSpeed (Rasley et al. 2020) 对我们的 32B 模型进行微调。训练过程在 4x8 96G H20 GPU 上进行。我们还使用 flash-attention-2 (Dao 2024) 减少内存开销并加速训练过程。我们将全局批量大小设置为 128 并训练 2 个周期。我们应用余弦学习率衰减，最大学习率为 1e-5，预热步骤为 3%。
4.5.0.3 强化学习。
我们使用 OpenRLHF (Hu et al. 2024) 框架实现 PPO (Schulman et al. 2017) 。训练过程在 4x8 96G H20 GPU 上进行。我们还使用 ray (Moritz et al. 2018) , DeepSpeed (Rasley et al. 2020) , flash-attention-2 (Dao 2024) 和 vllm (Kwon et al. 2023) 来减少 GPU 内存开销并加速训练过程。我们将温度设置为 1.0 以对每个提示进行采样。
5 结果与分析
5.0.0.1 SoRFT 在开源 LLM 中实现了最先进（SOTA）性能。
表 [tab:RQ1] 展示了 SoRFT 和经过微调的开源 LLM 在 SWE-bench Verified 和 SWE-bench Lite 的议题解决任务上的性能。我们根据参数规模将开源模型分为两类：（1）7-14B 开源 LLM，和（2）32-72B 开源 LLM。经过 SoRFT 训练的 LLM 在同参数规模的模型中实现了最先进（SOTA）性能，甚至略微优于一些较大的模型。在 SWE-bench Verified 上，SoRFT-Qwen-7B 优于 SWE-Gym-Qwen-32B（21.4 vs. 20.6）。SoRFT-Qwen-32B 甚至优于 Lingma-SWE-GPT-72B（30.8 vs. 30.2），尽管后者具有显著更多的参数。
虽然 OpenHands 使用专有模型实现了最佳性能，但专门针对 OpenHands 细调的 SWE-Gym 模型表现不如其他模型。这种差异可能源于在代理框架中构建中间步骤监督信号的挑战，而基于管道的框架可以为不同阶段建立监督信号。这允许更细粒度地过滤 CoT 数据并更精确地计算奖励。
5.0.0.2 SoRFT 的准确率高于仅依赖监督微调。
5.0.0.3 奖励规则的鲁棒性对强化学习至关重要。
5.0.0.4 SoRFT 还增强了通用代码任务的性能。
我们还在两个通用代码任务上进行了评估：LiveCodeBench (Jain et al. 2024) 和 RepoQA (Liu et al. 2024) 。LiveCodeBench 关注自包含代码生成场景，而 RepoQA 评估 LLM 从长上下文代码内容中提取信息的能力。表 [tab:RQ4] 的结果表明，SoRFT 也有潜力增强代码相关任务的性能。开源社区中有大量未被当前 LLM 训练过程利用的开发过程数据。像 SoRFT 这样的方法有可能利用这些数据进一步提升代码 LLM 的能力。
6 相关工作
6.0.0.1 LLM 训练用于议题解决。
为了增强开源 LLM 的议题解决能力，几项研究工作 (Y. Ma et al. 2024; C. Xie et al. 2025; Z. Ma, An, Lin, et al. 2024; Pan et al. 2024) 尝试使用开源社区的软件开发资源构建训练数据并对开源 LLM 进行微调。 Pan et al. (2024) 爬取了开源仓库，并使用闭源模型（例如，GPT-4o (OpenAI 2024a) 和 Claude-3.5-Sonnet ( “Introducing the Next Generation of Claude” 2024) ) 生成 Openhands (Wang, Chen, et al. 2024; Wang, Li, et al. 2024) 代理轨迹，并通过单元测试过滤它们。然后他们使用这些轨迹对 Qwen (Hui et al. 2024) 模型进行微调，使其作为 Openhands 的基础模型。 Y. Ma et al. (2024) 使用 GPT-4o 生成代理轨迹以处理开源仓库中的问题，并使用过滤后的轨迹对开源模型进行微调。 Pan et al. (2024) 使用 GPT-4o 生成编辑生成任务的 CoT 数据，并对开源模型进行微调以应用于 SWE-Fixer RAG 管道。以上所有工作都使用 SFT 对模型进行微调。据我们所知，我们是第一个使用强化微调 (Luong et al. 2024) 增强 LLM 议题解决能力的工作。
6.0.0.2 基于规则奖励的强化学习。
自从 OpenAI 发布 o1 (OpenAI 2024b) 模型以来，许多努力试图通过基于规则的强化学习增强 LLM 的长形式推理能力。DeepSeek 的 R1 (Guo et al. 2025) 模型使用基于规则的 GRPO (Shao et al. 2024) 进一步展示了基于规则奖励的潜力。 K. Team et al. (2025) 发布了 Kimi-k1.5，也经过基于规则的强化学习训练。研究社区 (Zeng et al. 2025; T. Xie et al. 2025) 也在尝试复制基于规则的强化学习过程。 Pan et al. (2025) 使用 PPO (Schulman et al. 2017) 在 Countdown 任务上训练了一个 3B 模型，并观察到 " Aha moment " (Guo et al. 2025) 现象，与 R1 的行为非常接近。 Zeng et al. (2025) 使用 PPO 在 Math 任务上训练了一个 7B 模型，并观察到响应长度最初减少然后增加（类似于图 [fig:f3_score] 中的趋势）。以前的工作主要集中在数学任务上，其中奖励可以根据真实标签轻松计算。在本文中，我们通过面向子任务的基于规则的强化学习改进了开源模型在议题解决框架中的性能。
7 结论
在本文中，我们提出了 SoRFT，一种面向子任务的强化微调方法，以增强 LLM 的议题解决能力。通过基于规则的强化学习，SoRFT 在提高性能的同时确保了更好的泛化能力。我们的结果证明其作为商业模型成本效益更高的替代方案的有效性。
8 局限性
8.0.0.1 基于规则奖励的假阴性。
正确的问题解决方案往往不是唯一的。仅依赖于将 LLM 的响应与单个真实标签进行比较的基于规则的奖励可能会错误地将有效解决方案分类为失败。为了解决这一局限，未来的工作可以结合单元测试执行结果，作为更客观和公平的代码编辑质量衡量标准。
8.0.0.2 实验仅在 Python 仓库中进行。
由于缺乏多语言 SWE-Bench 测试集，我们的实验仅限于 Python 仓库。然而，由于 SoRFT 是一个语言无关的框架，我们相信它有潜力提升其他语言中 LLM 的议题解决能力。
这是论文《SoRFT：面向子任务的强化微调解决议题》的附录。
9 评估细节
所有评估实验都在 4 个 96G H20 GPU 上使用 vllm (Kwon et al. 2023) 框架进行。我们使用 SWE-Bench 仓库提供的官方评估脚本对 SWE-Bench Verified 和 SWE-Bench Lite 进行评估。在 LiveCodeBench (Jain et al. 2024) 上，我们在 code_generation_lite releave_v4 版本上进行评估，该版本包含 2023 年 5 月至 2024 年 9 月发布的 713 个问题。在 RepoQA (Liu et al. 2024) 上，我们在 Python 仓库上进行评估， 相似度阈值=0.9 。
PPO 训练步骤中的奖励变化。
10 PPO 训练细节
为了支持基于规则的 PPO 训练，我们在 OpenRLHF (Hu et al. 2024) 框架中实现了一个自定义奖励函数，以取代原始奖励模型评分函数。我们将训练批大小设置为 64，演员模型的 Adam 学习率为 5e-7，评论家模型的 Adam 学习率为 9e-6。如图 2 所示，使用我们设计的奖励规则，奖励随训练步骤稳步增加。
11 额外推理示例
我们观察到，经过 SoRFT 训练后，7B 模型倾向于进行额外推理，这与 DeepSeek 在 R1 训练过程中观察到的 "aha moment" 现象有些类似。在示例 [exmp:additional_thought] 中，在得出结论之前，SoRFT-Qwen-7B 主动探索是否遗漏了任何潜在的答案，并成功识别出黄金函数 sql_flush 。
12 子任务提示
我们根据 Agentless (Xia et al. 2024) 各阶段使用的提示设计了不同子任务的数据生成提示。每个子任务的提示包括四个部分：子任务描述、问题、上下文和输出格式说明。LLM 需要分析问题描述，从上下文中选择符合子任务描述的内容，并根据指定的输出格式提供最终答案。示例 [exmp:file_localization] - [exmp:code_edit] 是用于生成每个子任务 CoT 数据的提示。
13 SoRFT 在议题解决子任务上的有效性
我们使用 SWE-Bench Verified 数据集详细评估了 SoRFT 对各种议题解决子任务的影响。具体来说，我们测量了模型在三个子任务上的命中率：文件定位、函数定位和行定位。表 [tab:hit_result] 的结果显示，SoRFT 训练提升了模型在这几个子任务上的性能。
不同训练策略下模型的性能。
14 训练数据消融
额外推理示例 additional_thought 输入：
识别所有需要检查或编辑的位置以修复问题。
问题： 简化 DatabaseOperations.execute_sql_flush() 方法签名
...
输出：
### 思考：
问题是关于将 execute_sql_flush 方法的签名从 (self, using, sql_list) 简化为仅 (self, sql_list)。
...
此外，存在一个 sql_flush() 方法（第 401 行） 与此功能相关，可能也需要更新。
...
### 答案：
django/db/backends/base/operations.py
类: BaseDatabaseOperations
函数: sql_flush
...
文件定位提示 file_localization 请浏览以下 GitHub 问题描述和仓库结构，并提供一份需要编辑以修复问题的文件列表。
### GitHub 问题描述：
{issue}
### 仓库结构：
{repository_structure}
请逐步思考，提供最多 5 个文件的完整路径，并按重要性从高到低排序。
返回的文件应以新行分隔。
例如：
` ` `
file1.py
file2.py
` ` `
您的推理应以 "### 思考:" 开始，答案应以 "### 答案:" 开始。
函数定位提示 func_localization 请浏览以下 GitHub 问题描述和相关文件的骨架。
识别所有需要检查或编辑的位置，包括直接相关区域以及任何可能相关的全局变量、函数和类。
对于每个位置，提供类名、方法名或函数名。
### GitHub 问题描述：
{issue}
### 相关文件的骨架：
{file_skeleton}
请提供完整的定位集合，包括类名、函数名或变量名。
注意，如果您包含一个类，则不需要列出其具体方法。
您可以包含整个类或不包含类名而包含类中的具体方法。
例如：
` ` `
full_path1/file1.py
函数: my_function_1
类: MyClass1
方法: MyClass2.my_method
` ` `
请逐步思考后再返回位置。
您的推理应以 "### 思考:" 开始，答案应以 "### 答案:" 开始。
行定位提示 line_localization 请审阅以下 GitHub 问题描述和相关文件，并提供一组需要编辑以修复问题的位置。
位置可以指定为类名、函数或方法名或需要修改的确切行号。
### GitHub 问题描述：
{issue}
### 文件内容：
{file_contents}
请提供需要编辑的类名、函数或方法名或确切行号。
例如：
` ` `
full_path1/file1.py
行: 10
类: MyClass1
行: 51
` ` `
请逐步思考后再返回位置。
您的推理应以 "### 思考:" 开始，答案应以 "### 答案:" 开始。
代码编辑生成提示 code_edit 您将获得一个解释需要解决的问题的议题陈述和部分代码库。请首先根据议题陈述定位 Bug，然后生成 *SEARCH/REPLACE* 编辑以修复问题。
### GitHub 问题描述：
{issue}
### 代码内容：
{code_content}
请首先根据议题陈述定位 Bug，然后生成 *SEARCH/REPLACE* 编辑以修复问题。
每个 *SEARCH/REPLACE* 编辑必须使用此格式：
1. 文件路径
2. 搜索块开始： < < < < < < < SEARCH
3. 在现有源代码中搜索的连续行块
4. 分隔线： =======
5. 替换到源代码中的行
6. 替换块结束： > > > > > > REPLACE
例如：
` ` ` python
### mathweb/flask/app.py
< < < < < < < SEARCH
from flask import Flask
=======
import math
from flask import Flask
> > > > > > > REPLACE
` ` `
请注意， *SEARCH/REPLACE* 编辑需要正确的缩进。如果您想添加一行 ’ print(x)’，您必须完整写出该行，包括所有前面的空格！将 *SEARCH/REPLACE* 编辑用代码块 ` ` ` python... ` ` ` 包围。
您的推理应以 "### 思考:" 开始，答案应以 "### 答案:" 开始。
- 该工作在字节跳动实习期间完成。 ↩︎
- 对应作者。 ↩︎
- 我们使用的是 Agentless 1.0。 ↩︎
- https://www.docker.com/ ↩︎
- https://seart-ghs.si.usi.ch/ ↩︎
- https://pytorch.org/docs/stable/fsdp.html ↩︎
- https://github.com/swe-bench/SWE-bench ↩︎
原论文：https://arxiv.org/pdf/2502.20127
扫一扫
737
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
