很多 Coding Agent benchmark 从完整仓库和 issue 描述开始。Failure Map 选择了更小的评价单元：行为合同、违反合同的实现、一次看似合理但仍然失败的修复，以及可执行边界检查。
2026.09.5 版本声明提供 20,168 个开放 Python 调试任务，覆盖 254 类软件失败。数量本身很醒目，方法论更值得关注，因为它明确区分了机制与变体、公开检查与隐藏评测、记录过的执行与一般正确性。
一个开放任务实际包含什么
公开 gzip 导出包含 Prompt、broken source、代表失败修复的 hard negative、Python 环境合同、evaluation group 和边界检查奖励元数据。开放层的 reference solution 为 null。
导出文件开头的几个案例对应常见边界错误：按事件身份去重，同时保留数值相同的不同事件；把有效期定义为左闭右开；分页时比较完整排序键，包括唯一记录 ID。
程序很短，测试的却是最容易穿过 happy path 的语义差异。
方法页进一步说明，完整档案有 100,840 个 variants，对应 20,168 个 distinct mechanisms；同一 family 中五个编号案例共享合同。项目方还报告，302,520 个实现分别在独立 Python 进程中执行，并记录 stdout、stderr、退出状态、耗时、边界观察和源码哈希。
这些属于数据提供方公开且可检查的方法说明。它们提高了工件可审计性，并不自动证明任何模型更强。
公开 checks 不是隐藏 benchmark
Failure Map 最重要的说明非常直接：recorded checks 不是独立隐藏 benchmark。
模型看到 checks 后，可以直接围绕它们优化。通过只能证明补丁满足这些 fixtures，无法证明它覆盖更广输入、集成条件或未见变体。
可以把证据分成四级：任务可在声明环境中执行；补丁通过公开 fixtures；补丁通过与模型隔离的未见测试；补丁在仓库集成、非功能约束和真实工作流中仍然有效。
把第二级结果写成第四级，就是 benchmark 膨胀。
Family 不分组，答案就会泄漏
当多个变体共享合同、解法模式或 evaluation group 时，随机按行切分会造成近邻泄漏。模型可能在训练集中见过同族任务，在测试集中修复另一个近重复案例，分数很高，却没有证明它能迁移到新的失败机制。
Failure Map 明确要求 related families 和共享 evaluation_group 留在同一个 split 中。可靠切分至少满足：一个机制 family 只属于 train、validation 或 test 之一；共享 evaluation group 不跨集合；隐藏 fixtures 只存在于评测基础设施；reference repair 对模型不可见。
报告结果时还要同时给出机制覆盖和变体数量。两万行数据仍可能只包含更少的独立思想。
六步构建可复现评测
1. 冻结任务版本
记录数据版本、导出校验和、Python 版本、依赖和 task ID。持续变化的 catalog 无法支持稳定比较。
2. 先做分组切分
在任何模型接触数据前，按机制 family 和 evaluation group 切分；再审计跨 split 的 Prompt 与源码近重复。
3. 隔离执行
每个候选补丁进入一次性进程或容器，并限制 CPU、内存、时间、文件系统和网络。模型生成代码应按不可信输入处理。
4. 分开可见与隐藏检查
可见测试支持开发，隐藏测试支持评价。合同允许时，补充 property-based、metamorphic 和 integration cases。
5. 评分不止 pass rate
同时记录解析成功率、公开测试通过率、隐藏测试通过率、回归率、补丁大小、尝试次数、墙钟时间与计算成本。删除测试的补丁应先被完整性检查拦截。
6. 保留证据轨迹
保存原任务、生成补丁、stdout、stderr、退出码、资源消耗、测试身份、模型版本、Prompt 和 Harness 版本。缺少工件的总分很难审计。
用真实失败扩展题库
高价值评测集应从真实遗漏中演化。Agent 补丁在 code review 或生产验证中失败后，可以把事件缩减为最小行为合同，视情况加入公开训练例，并保留一个独立隐藏变体作为回归门。
这条闭环是：生产失败、最小合同、隔离任务、隐藏回归、发布门禁。
目标不是最大化题量，而是持续增加与目标工作流有关的失败机制覆盖。
Failure Map 证明了什么
Failure Map 提供了可检查的受控程序修复任务，并给出清晰的数据切分警告。开放层刻意省略正确修复；记录 checks 只覆盖声明合同与 fixtures；项目方也没有声称模型性能提升。
这种克制反而提升了可用性。团队可以把它当作构建严谨评测的原料，而不是把一个可下载数据集误认为成品 benchmark。
常见问题
Failure Map 是可直接使用的隐藏 benchmark 吗？
不是。公开 checks 明确不具备独立性，需要另建并保护 held-out tests。
20,168 个任务彼此独立吗？
项目区分 mechanism、variant、family 和 evaluation group。评测应分别报告，并按组切分。
为什么要提供一次失败修复？
它构成 hard negative，用于识别那些局部看似合理、仍违反至少一个边界条件的补丁。
可以直接在开发机运行吗？
发布源码只使用 Python 标准库，模型生成代码仍属于不可信输入。应在资源受限环境中执行，并关闭不必要的网络与文件权限。