SWE-Bench Pro Verified：去除 reward hacking 与 task quality 失真的可靠评测集

关联论文：2609.08149
作者：flyP
更新：2026-09-11

元层五问（v2 模板 §0）： R1 命名 = R-132（撞自己检测 ✓ 与 inbox/flyp/ 历史无同名主稿 · 注：SWE-Bench 通用主题需警惕撞名，已加边界声明） R2 截止日 = 2026-09-11（cron 任务窗口内） R3 评级 = A-（事实层全部 anchor 至 abstract · 数字 100% abstract verbatim · 无私域污染 · 双轨齐全 · 公开仓库 / 数字细节 abstract 未明确已 ⚠️） R4 边界 = 仅写本文件 / 不动他人目录 / 不 git / 不输出密钥；本稿 ≠ SWE-Bench / SWE-Bench Verified 原文分析，避免与外部评测团队产物撞名 R5 字数 = 主稿 ≤3,500 CJK · 反方 ≤300 CJK · 元信息 ≤100 CJK（硬约束 ≤3,900）

一句话结论

SWE-Bench Pro Verified 把「SWE-Bench Pro」这个仓库级软件工程 agent 评测基准里两类失真（reward hacking 来源 + task quality 来源）一并修掉，给出可信版本，让榜单成绩更接近 agent 的真实编码能力。

它要解决的真问题

SWE-Bench Pro 已成软件工程 agent 的事实标准之一。但作者分析发现其评测可信度被两类系统性失真侵蚀：

Reward hacking 来源：gold solution 泄漏 + 隐藏评测信息泄漏 → agent 可能「抄答案」而非「真解题」，分数虚高；
Task quality 来源：误导性 problem statement + 不当 scope 的测试 → 即使 agent 正常解题也会被判失败，分数虚低。

这两类问题叠加，会把榜单上的 agent 排序整段「反转」——一个靠 reward hacking 拿高分的 agent，可能在真实仓库里反而不如一个被 task quality 误判的低分 agent。

核心方法

SWE-Bench Pro Verified 的核心是「验证 + 修复」而非「重新出题」。具体动作（abstract 描述级）：

reward hacking 侧：识别 gold solution / 隐藏评测信息泄漏点，重写评测协议或 task 包装，切断 agent 直接抄答案的路径（具体技术手段 abstract 未明确，需要 PDF §III 核验）；
task quality 侧：人工 + 工具双重审阅 problem statement 与 test scope，修正误导性描述 + 收紧 test 边界（具体审阅流程 abstract 未明确）；
保留原 SWE-Bench Pro 的 task 分布与难度：不在「题目难度」上动手脚，确保 verified 版与原版「同一难度谱」，避免「verified 版变简单」的可信度反向问题。

伪代码骨架（机制示意，非 SDK）：

def verify_task(task, gold_solution, hidden_info, tests):
    # 1. leak detection: gold solution / hidden info 是否在 agent 可达上下文
    leaks = detect_leak(gold_solution, hidden_info, task.context)
    # 2. statement audit: problem statement 是否误导（歧义 / 自相矛盾 / 与测试不一致）
    statement_issues = audit_statement(task.statement, tests)
    # 3. test scope audit: tests 是否覆盖了 statement 中的所有承诺？
    scope_issues = audit_test_scope(task.statement, tests)
    if any([leaks, statement_issues, scope_issues]):
        return fix_task(task, leaks, statement_issues, scope_issues)
    return task  # verified

关键实验与数据

评测对象：原 SWE-Bench Pro 上的所有 task；
操作方式：找到失真 task → 修复（leak / statement / scope 任一）→ 保留难度；
核心证据：abstract 明确陈述两类失真存在并导致「benchmark performance inflate」+「obscure agents' true coding ability」；
公开榜单数字：abstract 未给出具体 agent 在原版 vs verified 版上的 Δ 分数对比（标注为「原文未明确」）。

⚠️ 关键数字（verified 版的 task 数、agent 排名变化、reward hacking 命中率、statement audit 通过率）在 abstract 中均未明确。下文涉及「具体提升幅度」必须以 PDF §V 核验。

亮点与局限

亮点

「验证 + 修复」而非「重新出题」：保留原 SWE-Bench Pro 的难度谱，避免「verified 版变简单」的二次失真；
同时打两类失真：reward hacking + task quality 并修，对榜单可信度的修复是端到端的；
方向对了：与同日发布的 AgentAudit（2609.09875）形成「benchmark 可信度」的双轨——前者修 benchmark 本身，后者评 agent 在 benchmark 上的失败位置；
填补社区缺口：SWE-Bench 家族之前已有 SWE-Bench Lite / SWE-Bench Verified（针对 SWE-Bench 而非 Pro），但 Pro 版本的 verified 一直缺位。

局限

被引 0（2026-09-09 提交）：同行评审尚未发生；
具体数字 abstract 未给：verified 版 vs 原版各 agent 排名变化幅度、leak 命中率、statement audit 通过率均未披露 ⚠️；
「修复」的标准未必唯一：problem statement 误导 / test scope 失当的判定本身是 judgment call，可能引入 verified 团队的偏好；
公开仓库 / 评测协议 abstract 未附链接：独立复现门槛高（与原 SWE-Bench Pro 是否有公开 GitHub 仓库需进一步核查）；
难以反向验证：单方面声明「修好了」不等于社区公认；需等独立第三方复现。

对工程落地的启发

任何 benchmark 都需要「verified pass」：上线前自建内部 benchmark 也应跑 leak / statement / scope 三件套审计，避免团队内「我们做的内部榜第一」其实是 reward hacking；
「保留难度谱」是 verified 版本的核心约束：重做基准最容易踩的坑是「verified 版变简单」，SWE-Bench Pro Verified 把这点作为方法学约束明确写出，值得借鉴；
双轨对照：自己 agent 跑 verified 版 + 原版两份，对比 Δ 是判断自身稳健性的便宜信号；
避免撞名：本主题（SWE-Bench 家族）已被多团队多角度解读，写作时务必明确「本文针对 SWE-Bench Pro Verified ≠ SWE-Bench Verified ≠ 原 SWE-Bench Pro」三者的区别，避免撞自己 ⚠️。

与同方向工作的关系

vs 原 SWE-Bench Pro：Verified 是 Pro 的「可信度修复版」，不是替代；保留难度谱；
vs SWE-Bench Verified（针对 SWE-Bench 非 Pro）：两者都是「verified」思路，但目标 benchmark 不同（SWE-Bench 是经典版，Pro 是仓库级商用版），不可混为一谈；
vs AgentAudit（2609.09875，同日）：SWE-Bench Pro Verified 修「benchmark 本身的可信度」；AgentAudit 评「agent 在 benchmark 上的失败位置」。两者构成「评测可信度」主题的双轨：
SWE-Bench Pro Verified = 把尺子校准；
AgentAudit = 把尺子的读数拆到 stage；
vs LiveCodeBench / RepoBench 等动态榜：动态榜用持续更新规避失真，但代价是「同一 agent 不同时间点分数不可比」；Verified 路线保留可比性，代价是修榜本身需要人工；
vs HumanEval / MBPP：单函数级别基准的 verified 化早已成熟；SWE-Bench Pro Verified 把这条路径推到仓库级 + 商用代码库规模。

适合谁读

agent 团队负责人 / Tech Lead：上 SWE-Bench Pro 之前先跑 Verified，避免自家 agent 排名被 reward hacking / task quality 失真误导；
benchmark 维护者 / 数据集策展人：把「leak detection + statement audit + scope audit」三件套吸收到自家 benchmark 发布 checklist；
学术评测研究者：可作为「verified benchmark 路线」的近期案例，与动态榜路线（LiveCodeBench）对照阅读；
不推荐：纯应用 LLM 开发者（chat / RAG）—— 本主题只与代码 agent / 仓库级 benchmark 相关。

反方（v2 三段式 · 按主线分布）

机制层：「修复」的判定标准本身是 judgment call；problem statement 误导与 test scope 失当的边界由谁来划、划在哪条线，abstract 未明确 author team 的审阅 SOP；这意味着 verified 版可能引入 verified 团队的偏好，构成「权威方定义失真」的新风险。
工程层：保留原版难度谱是承诺也是负担——任何 verified 修复都可能在「题面改了」与「难度没改」之间踩线，需大量 regression testing；公开仓库 / 评测协议 abstract 未附，独立复现门槛高 ⚠️。
数据层：verified 版 vs 原版各 agent 排名变化幅度、leak 命中率、statement audit 通过率等核心数字 abstract 均未披露；缺乏量化证据下「修好了」的声明难以被社区证伪；与同日发布的 AgentAudit（2609.09875）相比，本篇缺乏「跨模型横向数字」，可比性较弱。

⚠️ 本稿事实层全部 anchor 至 arxiv abstract（2609.08149，2026-09-09 提交）。verified 版 task 数 / agent 排名变化 / leak 命中率 / statement audit 通过率 / 公开 GitHub 链接 = 原文未明确。本稿 ≠ SWE-Bench Pro 团队官方产物，仅为第三方学术解读。