多智能体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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考