Active-SWE：Coding Agent 从修复问题到发现问题
现有 Coding Agent 排行榜通常从一份写得相当清楚的 Issue 开始：症状、目标行为、相关上下文甚至复现线索已经由人整理好。真实维护中最昂贵的一段工作却发生在这之前——从仓库和弱信号里判断是否真的存在缺陷、缺…
这项改变看似只是少一段文字，实际撤掉了一个强先验。论文在同一批任务的子集上比较反应式与主动式修复：Claude Opus 4.8 的解决率从 59% 降到 26%，GPT-5.5 从 57% 降到 22%，GLM-5.2 从 58% 降到 17%。模型会写补丁，并不意味着它会在没有明确线索时找到正确的问题。
基准如何从真实 PR 还原“尚未发现”的时刻
Active-SWE 从 87 个至少 1,000 星的开源仓库抓取历史 PR，覆盖 Python、Go、Rust、PHP、Ruby、JavaScript/TypeScript、Java 和 C/C++。原始 PR 必须具有关联 Issue、参考补丁、参考测试和合并时间等制品。随后由多模型标注器按六类缺陷分类，并通过共识投票剔除功能开发或 API 扩展等非缺陷变更。
可执行环境由 Setup Agent 建立。它探索仓库、生成 Dockerfile 与测试脚本、实际构建并运行，再根据错误迭代修正。测试脚本必须输出测试级结果，使参考测试可以拆成 fail-to-pass 与 pass-to-pass：前者证明补丁确实修复旧故障，后者约束补丁没有破坏既有行为。这一步决定基准能否从文字判断转成可重复执行的评测。
简单任务来自单个 PR。研究者丢弃原 Issue，只保留 PR 修改所涉及的文件作为审查范围，并回到修复发生前的仓库快照。困难任务则按合并时间使用滑动窗口，把相邻的两个 PR 聚合到更早快照，要求 Agent 在同一范围内处理至少两个已记录缺陷；只有聚合后 fail-to-pass 集合等于各 PR 集合并集时才接收，避免时间拼接制造无效任务。
最终扩展集有 1,663 个任务，其中 1,411 个简单任务、252 个困难任务，横跨六类缺陷与八种语言；主评测再精选 400 个任务，其中 300 个简单、100 个困难。困难任务窗口只设为 2，原因是更大窗口的环境整合失败率高。这既保证可执行性，也提示我们：现实中的多缺陷依赖关系可能比基准更复杂。
双轨评测为什么比“测试是否通过”更严格
第一条轨道评估历史 PR 已知的 recorded bugs。论文不只报告最终 Resolved，还把定位拆成 Localization Recall 与 Precision。参考补丁被拆成编辑 Hunk；Recall 衡量 Agent 命中了多少参考 Hunk，Precision 衡量 Agent 自己修改的 Hunk 中有多少与参考位置匹配。Resolved 只有在生成补丁应用后全部参考测试通过时才为 1。
这个拆分能区分三类失败：根本没找到位置，找对位置却修错，或通过另一条路径修好。实验中确实存在“定位未匹配参考、测试却通过”的情况，说明参考补丁不是唯一正确路径。因此定位指标用于诊断，最终行为仍由测试裁决，不能把与人类补丁相似直接等同于正确。
第二条轨道评估 Agent 声称发现的 potential bugs，因为历史 PR 没有现成 Oracle。Agent 必须为每个新缺陷生成可复现测试；Judge 判断测试与缺陷描述是否语义对应，执行器验证测试在旧代码失败、在补丁后通过。Test Validity 要求生成测试都具备 fail-to-pass 行为，Revealed 还要求这些有效测试覆盖所声称的缺陷。多写几个失败测试并不能提高可信度，测试必须证明具体补丁修复了具体问题。
这套机制仍不是完美 Oracle。测试可能只覆盖一种输入路径，Judge 也可能误判语义关联；Agent 还可能改变测试容易触达、但业务价值很低的行为。因此潜在缺陷结果适合作为“可执行候选证据”，若进入生产仍需要领域审查、影响分析和回归策略。
结果暴露的主要瓶颈是定位而非编辑
在统一 Claude Code Scaffold 下，17 个模型的最佳 recorded-bug Resolved 只有 20%，由 Claude Opus 4.8 达到；其 Localization Recall 为 29.1、Precision 为 35.0。GPT-5.5 的 Recall 为 28.8、Precision 为 24.1、Resolved 为 18.5%；Gemini-3.1-Pro 的 Resolved 为 15.8%。这说明最强系统也只处理了约五分之一任务，且修改位置的覆盖与准确度都偏低。
潜在缺陷轨道上，“生成数量”与 Test Validity 并不一致。GPT-5.5 平均生成 3.0 个测试，TV 为 87.5、Revealed 为 65.5；Claude Opus 4.8 只生成 1.2 个，TV 为 81.0、Revealed 为 75.0；GLM-5.2 的 Revealed 达到 69.0。数量高并不自动意味着证据更完整，较少但与补丁精确对应的测试更有价值。
把定位 Recall 达到 0.5 视为 Located 后，Claude Opus 4.8 有 32.8% 的任务定位成功、18.2% 最终解决；GPT-5.5 为 30.8% 与 15.8%；GLM-5.2 只有 9.8% 定位，却有 10.4% 解决，说明替代修复路径与定位指标偏差同时存在。整体趋势仍清楚：定位质量与解决率正相关。
缺陷类型也影响能力。模型更擅长 Exception Safety，较难处理 State & Lifecycle；潜在发现集中在 Logic & Computation、Reference & Data Flow，对领域工作流和跨状态错误敏感度较低。这符合仓库搜索的局部偏差：明显控制流和空值异常容易通过邻近代码与测试发现，跨时间、跨模块状态机则需要更长证据链。
附录还显示 Scaffold 设计会显著改变结果，说明排行榜不是基础模型能力的纯测量；成本与性能之间也存在取舍。对生产团队而言，应该评估“模型 + 搜索策略 + 测试生成 + 执行环境”的整体系统，而不是只根据模型标签推断主动维护能力。
从主动评测走向主动维护
把 Agent 放进代码库持续找 Bug 之前，应先限定搜索与执行边界。一次完整发现至少包含仓库版本、审查范围、缺陷假设、最小复现、影响路径、候选补丁、fail-to-pass 测试和全量回归结果。任何缺失复现证据的“潜在问题”都应进入低置信队列，避免把模型猜测直接变成改动。
搜索阶段可分层：先用静态结构、最近变更和故障日志筛出候选区域，再由 Agent 建立调用链和状态假设，最后生成最小测试。这样既减少全仓库盲扫成本，也让漏检位置可被审计。对于 State & Lifecycle、并发、权限和数据迁移等弱项，应配置专门的场景生成器与跨模块追踪，而不是依赖通用提示词。
验证阶段应由独立执行环境负责，Agent 不能自己宣称测试通过。测试先在旧版本失败，再在补丁版本通过，并运行历史回归、静态检查与安全策略；涉及外部接口或数据变更时还要检查兼容性。合并决策可依据证据强度分级：定位和复现充分的候选进入人工审查，只有静态怀疑的候选继续观察，具有不可逆影响的改动保持人工批准。
Active-SWE 把 Coding Agent 的能力边界向前移动了一步：从“按说明修复”变成“在代码中提出并证明问题”。它同时提醒我们，主动性不是给 Agent 更宽权限，而是要求它承担更完整的举证责任。会发现的系统必须比会修改的系统更克制，因为搜索空间更大，错误确信也更容易制造无效工作。