Active-SWE — proactive bug-fixing benchmark without issue reports
Active-SWE — proactive bug-fixing benchmark without issue reports
Active-SWE 是一个评测 coding agents 主动缺陷修复能力的 benchmark。和 SWE-bench 式“给定 issue / patch 修复”不同，它要求 agent 在没有实例级 issue report 的情况下检查仓库快照和待审文件，发现潜在缺陷并完成修复。README 描述其扩展集包含 1,663 个任务，覆盖六类 bug 和八种编程语言；核心评测协议分为 Recorded、Potential、Judge 三阶段。
为什么这对用户重要
真实工程里，很多有价值的 agent workflow 不是“用户给出明确 bug”，而是从日志、测试、PR diff、监控或代码审查中主动发现问题。用户的 llm-wiki 雷达本身也是 proactive discovery：不是等用户给 URL，而是主动发现高价值知识。Active-SWE 因此补充了 Agent-Benchmarks 的一个关键维度：从被动任务完成转向主动问题发现与证据构造。
机制 / 一阶原理
Active-SWE 的评测把主动 bug fixing 拆成三层：
- Recorded：生成 code patch，评估已记录 bug。
- Potential：生成测试，用 fail-to-pass 行为验证潜在 bug。
- Judge：验证潜在 bug 与测试之间的证据连接。
这个结构的关键不是“多一组任务”，而是把 proactive repair 分成“发现可疑点 → 构造验证 → 修复并证明”的链条。没有 issue report 时，agent 必须先建立问题假设，再用测试或 judge 把假设转成可评分证据。
与已有 wiki 概念的关系
- 与 Agent-Benchmarks：补充 proactive bug discovery，区别于给定 issue 的修复评测。
- 与 Harness-Engineering：需要 harness 提供仓库快照、待审文件、容器、bridge、skills、judge 和运行 artifact。
- 与 Context-Engineering：agent 需要在大量仓库上下文中定位缺陷，而不是消费明确任务描述。
- 与 Agentic-Coding：强调编码 agent 的下一步能力是主动发现，而非只执行用户指定 patch。
对 Hermes / llm-wiki 的可执行启发
- 把“主动发现”与“主动写入”分开：无人 cron 可主动发现和保存 raw，但正式晋升页面要通过深度/来源/重复性 gate。
- 用三阶段结构设计 wiki radar：Recorded=保存候选/raw，Potential=判断候选能补充哪个概念或 workflow，Judge=检查页面是否有 wikilinks、写入记录和未入库理由。
- 主动修复任务需要假设证据链：不能只说“我发现一个可能 bug”，要有 fail-to-pass 测试、日志或可复查证据。
- skills-as-eval-runbooks：Active-SWE 同时提供 Claude/Codex skill 目录，说明 benchmark 可把评测流程包装成 agent 可执行 runbook。
失败模式 / 边界条件
- 主动发现容易奖励“制造测试来证明自己假设”的行为；Judge 必须验证测试与真实 bug 的因果关系。
- 没有 issue report 时，搜索空间大，benchmark 成本和噪音更高。
- README 的 macOS Docker 支持未完全确认；实际运行环境会影响可复现性。
- 对 llm-wiki 来说，不能把每个“可能有价值”候选都晋升为页面；主动发现必须配合 compaction policy。
写入记录
- 2026-08-08 09:00 CST：新增 Active-SWE 的 source page，强调 proactive bug discovery、三阶段证据链和 llm-wiki radar 的主动发现 gate。