一文讲解，Trae 如何在 SWE-bench Verified 中达到 70.6% 的求解率

资料来源：火山引擎-开发者社区

在近期的 SWE-bench Verified 上，Trae 国际版拿到了 70.6% 的求解率分数，这是 Claude 4 发布前夕的最高成绩，目前在榜单上也仅次于 Claude 4 + Tools。下文将详细分享我们的实验过程，也期待未来我们可以做得更好。

单次 Patch 生成

我们为 Agent 提供了以下四种工具：

• str_replace_editor: 使 Agent 能够浏览文件、编辑代码等。

• Bash: 允许 Agent 执行任意命令。

• ckg_tools: 为代码库构建知识图谱（CKG），使 Agent 能高效执行类搜索和函数搜索操作，如 search_class 和 search_function 。

• sequential_thinking_tool: 辅助 Agent 进行分步逻辑推理。

我们对比了不同的模型在一次求解机会的端到端生成上的表现，图 1 展示了实验结果。

• Claude 3.7 Sonnet 的求解率在 60.6% 到 62.6% 之间

• Gemini 2.5 Pro 0506 的求解率 在 52.4% 到 55%之间

• OpenAI o4 mini 的求解率 在 54.4% 到 55.8% 之间

在一次机会的端到端求解中，模型的表现为 Claude 3.7 Sonnet > OpenAI o4 mini > Gemini 2.5 Pro 0506.

图 1

多次采样的 Patch 选择

LLM-as-a-Selector

我们首先尝试了一个简单的选择的方法。首先我们集成了 Agentless 的回归测试模块，对于没有通过回归测试的候选 patch，不会参与到后续的选择流程中，然后我们使用 Agument Code 开源的选择方式使用 OpenAI o1 进行选择。我们称这种方式为 LLM-as-a-Selector。

图 2 展示了随着采样空间（候选 patch 的数目）的增大，LLM-as-a-Selector 的成功率和 Optimal Rate（直接求并集）的变化。我们可以有如下观察：

• LLM-as-a-Selector 确实能提升一次机会的效果，这印证了 test-time scaling law 的存在。

• 即使 Optimal Rate 在稳步上升，但是 LLM-as-a-Selector 的效果在采样空间为 5 和 6 时达到顶峰，随之开始下降，采样次数为 8 和 9 时，甚至不如在采样空间为 3 或者 4 上的表现。

图 2

基于上述发现，我们的目标是在增大采样空间的同时，维持 test-time scaling law 的作用，于是我们构造了如下选择的方式。

Selector Agent

图 3

如图 3 所示，我们的方法主要包含了三个阶段：

1.Generation stage： 在该阶段，我们利用 Coder agent 针对输入的 issue description 生成候选 patch。为了保证生成的候选 patch 的多样性，我们使用了多种流行的 LLMs（Claude 3.7 Sonnet、Gemini 2.5 Pro 和 o4 mini）作为 Coder。

2.Filtering stage： 受启发于 Agentless，我们也设计了一个类似的 Tester agent ，利用 regression test 过滤无法通过测试的 patch。

• 具体来说，Tester agent 会自动地从 project codebase 中检索到一部分与 issue solving 相关的 regression tests。需要注意的是，我们完全遵守 SWE-bench 的提交要求，并未使用任何隐藏的 SWE-bench test knowledge（例如，PASS_TO_PASS 和 FAIL_TO_PASS）。

然后，Tester agent 会利用检索到的 regression tests 对原始 codebase 进行测试，以保证其在原始 codebase 上可以正确运行。

最后，Tester agent 对候选 patch 进行测试，并且从中剔除未通过 regression test 的 patch，其余候选 patch 将进入下一阶段。

需要注意的是，由于 regression test 也可能需要修改，因此通过所有的 regression test 并不等价于 patch 是正确的，并且正确的 patch 可能并没有通过 regression test，然而在我们的实验过程中通过全部 regression test 的 patch 有更大可能性是对的，因此我们使用了 regression test 策略。此外，若全部候选 patch 均未通过 regression tests，则保留全部候选 patch 进入下一阶段。

3.Voting stage： 最后，过滤后的候选 patch 将会被输入给 Selector agent 以输出最终的 patch。为了详细地说明 Selector agent 的一些细节，我们提供了其内部的具体的工作流程（如图 4 所示）。

• 首先，Selector agent 会先执行 syntax-based voting，按照语法等价性对这些 patch 进行聚类，并选择聚类数量最多的 patch 作为潜在的解决方案。这是因为如果多个 Coder agent 生成了严格语法等价的 patch，则说明这些 Coder agent 在解决当前的问题上达到了一致性，这类高度一致的候选 patch 更有可能是正确的 patch。

具体来说，为了比较不同 patch 之间的语法等价性，我们将这些的 patch 分别应用到原始的 codebase 中，分别得到对应的 updated code，接着利用程序分析工具 tree-sitter 将所有的 updated code 转化为 AST，并删除其注释。

然而这个投票结果说明，当前返回的 patch 在不同的 Coder agent 中一致性较高，更可能具备正确性，因此我们还增加了基于 Selector agent 的双重验证，Selector agent 会利用上下文（issue description 和 project codebase）和四个 tools（str_replace_editor、Bash、ckg_tools 和 sequential_thinking_tool）对当前的 patch 的正确性进行验证，如果通过了双重验证则作为最终 patch。如果当前单一的 Selector agent 并不能确定当前 patch 的正确性，则放弃当前的 Syntax-based voting 的投票结果，而利用下一步的 multi-selection voting。

• 在 multi-selection voting 模块中，为了进一步压缩候选 patch 的空间，我们首先使用了上一步骤中的 AST 对剩余的候选 patch 进行了去重，只保留了语法不等价的 patch。

这是因为，当这些 patch 被输入到 Selector agent 的时候，由于这类重复的 patch 在候选 patch 中占比较大，Selector agent 在选择的时候可能会存在 bias 而选择此类 patch，并且过多重复的 patch 会增大 input token length。接着，每个 Selector agent 会从去重后的候选 patch 中选择出最可能正确的 patch，然后我们会综合多个 Selector agent 的选择结果，选出票数最多的 patch，作为最终结果返回。

图 4

结果：我们的最优解决方案，将 SWE-bench Verified 整体求解率推高至 70.6%。令人期待的是，当前方法具备巨大的潜力，随着单个模型求解率的提升，我们的系统将会进一步获得更高的求解率。

下一步工作

我们的后续研究将聚焦以下方向：

• 提升单次修复成功率： 探索增强 Agent 在单次尝试中成功解决问题的策略。

• 扩展采样空间： 研究增大采样空间能否帮助模型发现更多正确解决方案。

• 选择器 Agent 优化： 随着样本空间规模增长，我们将优化选择器 Agent 的性能，以精准定位最佳补丁。

和我们在 FSE 与 ACL 交流

我们将参加 FSE 2025，展示我们的论文：AEGIS: An Agent-based Framework for General Bug Reproduction from Issue Descriptions 并于 6 月 27 日组织一个 AI-IDE workshop 。你可以在注册处附近找到我们的展台。

我们的文章 SoRFT: Issue Resolving with Subtask-oriented Reinforced Fine-Tuning 已经被 ACL 2025 的 Main Track 接收，我们将在于维也纳举办的 ACL 会议上展示这个工作，欢迎对软件工程和强化学习感兴趣的与会学者来和我们交流。