多智能体SWE-Bench代码修复：63.4%修复率实战

多智能体SWE-Bench代码修复：63.4%修复率实战

【免费下载链接】agentscopeBuild and run agents you can see, understand and trust.项目地址: https://gitcode.com/GitHub_Trending/ag/agentscope

基于 AgentScope 框架的多智能体方案在 SWE-Bench 上解决了 63.4% 的真实代码问题。数字不算惊艳，但背后的架构非常工程化：问题解决阶段由三个智能体协作产出多个候选补丁，投票决策阶段再由一个微调过的奖励模型裁决出最优解。

为什么修代码稳定需要多智能体

单个 LLM 修代码，"定位问题"和"产出稳定补丁"之间有一道明显的坎：模型大概率能判断出问题在哪，但每次跑出来的实际改动却不一样——这次可能只动一行，下次可能重写了整个函数。SWE-Bench 只看最终测试通过率，一次定胜负的产出方式，等于把每道题都押在模型当次状态上。

所以思路很直接：与其押一次，不如并行跑出多个候选补丁，再用独立组件挑最优。这就是"解决 + 投票"两阶段设计的出发点。

一次完整修复是怎么跑的 🔧

第一步：复现。复现智能体先解析 PR 描述，用思维链分析把问题该表现成什么行为梳理清楚，再落一个reproduction_test.py。这个测试必须在未修复的代码上稳定失败。这么做是为了给后面的"修"一个可验证的出口——复现不了的修复，本质上是在猜。

第二步：定位与修复。修复智能体接手，对代码做根因分析，产出 diff 补丁，同时接入 Git 版本控制，让修改过程可追溯、可回滚。补丁生成后立刻做即时验证：复现测试由红转绿才算这一步完成。

第三步：回归验证。验证智能体执行相关单元测试，确认修复没有把别处改坏；一旦有失败用例，补丁被打回做迭代优化。

第四步：裁决。并行产生的四种候选方案先做轨迹格式统一，再由奖励模型逐一评分，最高分者胜出。多智能体编排与运行沙箱的底层实现，可参考 src/agentscope/agent/ 与 src/agentscope/pipeline/。

微调奖励模型为什么比 LLM 评判更稳 ⚖️

裁决组件的选型是一次明确的 trade-off。最直觉的做法是找个大模型直接当裁判，但 LLM 判题在实践中并不稳——同一对补丁，不同调用可能给出不同结论。实际方案是基于 Qwen2.5-Coder-Instruct 做微调，训练数据来自多个专业软件工程数据集，训出来的模型能分析补丁质量、评估修复方案完整性、预测方案实际效果，打分稳定性明显优于直接让 LLM 评判。代价是训练数据准备与微调这条流水线，但在"并行多方案"的场景里，稳定性提升是划算的。

实践踩坑：约定、对称性与方差 ⚠️

踩得最大的坑是代码库特定约定理解。LLM 对通用逻辑没毛病，但接手具体仓库时跟不上它的命名习惯、目录结构和模块边界，产出的补丁经常破坏代码库的"对称性"——比如改了字段，配套的 getter/setter 忘了同步。第二类问题是复杂断言条件：复现测试要求断言写得精确，一条断言写偏，复现就失效了。

另一个观察是高方差：并行跑同一批题目结果波动大，一处一行的小改动就能让最终成绩产生显著差异。投票机制正是用来平滑这种方差的。

对应的改进方向也清晰：注入代码库特定知识（项目约定、模块文档等）、强化智能体的错误恢复机制、完善轨迹记录与分析工具，把方差变得可定位。

下一步往哪走

方向是两个：更细粒度的智能体分工，加上更强的奖励模型训练数据覆盖，同时把执行流程做成更确定、更可复现的形态。63.4% 是起点，不是上限。

【免费下载链接】agentscopeBuild and run agents you can see, understand and trust.项目地址: https://gitcode.com/GitHub_Trending/ag/agentscope