只修好 9%：为什么 Agent 框架的 Bug 最难被自动修

结论先说

一项新研究把「真实 GitHub bug 报告自动转成可运行测试」，构建出针对智能体框架的 200 个 bug 基准。结果：三个编码智能体中表现最好的只修复了 9%，而它们在常规软件 bug 上的修复率约为 40%。差距的主因不是模型不够强，而是这类任务的性质不同——它缺的不是算力，是可判定的对错标准。

事实部分

研究提出 AgentBug-Smith 方法：把真实 GitHub bug 报告自动转为可运行测试，构建出一个持续增长、共 200 个 bug 的基准。三个编码智能体中最好的仅修复 9%，远低于常规软件 bug 约 40% 的修复率。补充实验显示：向智能体提供「过往修复经验指南」后，某智能体在 79 个未见过的 bug 上，正确修复数从 1 提升到 6。

三个判断

第一，Agent 框架的 bug 多数不是「写错了」，而是「定义不清」。 常规软件 bug 通常有明确的输入输出期望；Agent 框架的缺陷常表现为状态在步骤间不一致、工具调用超时后不收敛、并发竞态，或者「符合规格但结果不对」。这类问题没有唯一正解，智能体即使改了代码，也难以自证修好了。

第二，缺乏 oracle 时，自动修复会退化成「看起来改了」。 智能体最擅长的动作是局部修改并让已有测试变绿；一旦测试没覆盖真实故障路径，它就会朝「让检查通过」而不是「让问题消失」的方向优化。9% 这个数字，正是这种错位的量化结果。

第三，「给经验指南」比「换更强模型」更有效。 从 1 到 6 的提升来自补上历史修复模式，而不是升级模型。这说明当前阶段，上下文里的「怎么修」比参数里的「多聪明」更决定成败。

对读者的实际建议

• 换个用法：让智能体先做复现与定位（生成最小复现、补断言、写出失败用例），而不是直接提交修复。定位可靠了，修不修得动是第二步。
• 建一个修复模式库：把团队历史上解决过的同类问题（竞态、超时重试、状态机收敛）整理成短条目，随任务一起喂进去。
• 给每个框架 bug 补一个失败的、可运行的检查用例。 没有红灯，就没有「修好」的定义。
• 正确解读 9%：它衡量的是端到端自动修复，不等于「智能体没用」——它在复现、日志归因、写测试上的价值已经很高。

一句话判断

把 Agent 用在「能验证的环节」，而不是「需要判断的环节」。这轮试验真正的信息是：判断力仍是瓶颈，而验证能力已经可以外包给机器。

参考来源：

• AgentBug-Smith 相关研究（经 X：Rohan Paul 转述） https://x.com/rohanpaul_ai/status/2106240755857801348