CheckerBench：长程 Agent 能否合成静态分析检查器

编码智能体能否从缺陷说明出发，在仓库中端到端合成可编译、可复用、误报受控的静态分析检查器，现有基准很少衡量这一点。

• 场景：作者称静态分析可不执行目标程序而检测复杂缺陷，但现有分析器依赖专家把模式写成工具特定规则。直接对代码片段用 LLM 时推理成本高、缺少仓库上下文，作者认为可能导致不完整推理和幻觉式发现。
• 任务：给定缺陷说明后，智能体要浏览分析器、实现并接入检查器，再按编译与扫描反馈修改。作者将此称为 long-horizon agentic static-analysis checker synthesis：须跨文件协调，且检查器要可编译、检出目标缺陷并维持低误报。
• 评测缺口：Figure 2 归纳四类缺口：任务针对单次补丁而非可复用检查器；流程被拆成预定阶段；同一 LLM 换脚手架分数会变；补丁测试缺少检查器重跑、定位和误报。Table 1 中，作者把 SWE-bench、SWE-Gym、R2E-Gym、ReposVul、VulEval、JitVul 标为不支持检查器合成；KNighter 有合成与误报评估，但被标为不支持多 harness 与长程交互。
• 本文提出：CheckerBench 含 300 个任务，来自 297 个 CVE、167 个仓库、85 个 CWE 和五种语言；每题有漏洞版与修复版、固定分析环境和检查器脚手架。CheckerLab 独立重建提交的检查器，并度量诊断对比、补丁定位、误报和工具使用。作者称据其所知，这是首个评测该任务的全面可执行基准。

• 静态分析与检查器合成：RhoSynth（Garg 与 Sengamedu，2022）从样例学习基于图的代码质量规则；Gordon（2018）从行为样例探索程序特定分析。E&V（Hao 等，2023）以伪代码执行和验证做静态分析，SkipAnalyzer（Mohajer 等，2023）用 LLM 过滤报告。IRIS（Li 等，2025）推断仓库级污点规格；MoCQ（Li 等，2025）与 CQLLM（Wang 等，2026）生成漏洞模式或 CodeQL 查询；QLCoder（Wang 等，2026）靠工具使用和迭代反馈合成 CodeQL。KNighter（Yang 等，2025）从 Linux 内核补丁合成并精炼 Clang Static Analyzer 检查器。作者称这些系统面向特定分析器或领域。
• 软件工程编码智能体：SWE-agent（Yang 等，2024）与 OpenHands（Wang 等，2025）支持交互式开发；RepoGraph（Ouyang 等，2025）加入仓库结构；RepoAudit（Guo 等，2025）把智能体用于仓库级缺陷检测。作者称它们产出补丁或缺陷发现，而检查器合成还要接入分析器，并在漏洞版与修复版上用编译和扫描反馈验证。
• 仓库级与漏洞基准：SWE-bench（Jimenez 等，2024）与 SWE-bench Pro（Deng 等，2025）评 issue 解决；FeatureBench（Zhou 等，2026）评功能开发；Terminal-Bench（Merrill 等，2026）评终端任务。SWE-Gym（Pan 等，2025）与 R2E-Gym（Jain 等，2025）为 issue 解决提供可执行环境与验证器。ReposVul（Wang 等，2024）、VulEval（Wen 等，2024）、JitVul（Yildiz 等，2025）面向漏洞检测；SEC-bench（Lee 等，2025）评概念验证生成与修补。作者称这些工作给任务完成、补丁或漏洞检测打分，而不评可复用检查器在留出验证器上的构建、漏洞–修复诊断、补丁定位和误报（Table 1）。
• 基线与数据集：Section 5.3 在 KNighter 原基准的 61 个 Linux 内核任务上，用 DeepSeek-V4-Pro 比较技能引导流程、KNighter 和去掉技能库的变体。主实验数据集是 CheckerBench 的 300 个任务；C/C++ 用 CSA，其余四种语言用 CodeQL。

作者把本文定位为：用统一任务说明和评分协议，评测通用编码智能体能否自主合成可复用检查器，而不是再做一个绑定单一分析器的合成系统，或只判断补丁是否通过测试。

作者用 CheckerBench 把漏洞修复实例打包成可执行合成任务，再用 CheckerLab 把交互合成与冻结检查器的独立验证分开。

任务形式化

• 输入：任务 xi 含漏洞修复实例 pi（仓库、漏洞版、修复版、补丁）、语言、分析器、版本固定的环境和合成指令。各次运行共享初始技能库 K；智能体可改检查器产物，但必须保留两个版本。
• 隐藏验证器：发布记录含可执行验证器 Vi，合成期间不可见。环境、指令和验证器在各模型–harness 配置间固定，轨迹和检查器随 rollout 变化。
• 可见材料：补丁、修复前后函数、构建元数据、编译/扫描命令和最小脚手架。工作区用随机标识，并省略 CVE/CWE 标签。K 提供工作流技能和只读分析器文档、示例检查器与语义工具，不含该题的检查器解答。

六阶段构造

• 收集与重建：从 NVD 公开 CVE 连到 C/C++、Java、Python、JavaScript、Go 的修复提交，要求可取回双版本且补丁暴露可复用的静态分析性质。C/C++ 用 CSA，其余四种语言用 CodeQL；无法重建或不支持稳定差分分析的配对被拒绝。
• 冻结验证器：在收集 rollout 之前冻结留出验证器。它在干净工作区从源码重建检查器，并按后端规则检查漏洞–修复诊断对比和补丁相关性。CSA 要求补丁修改函数中有消失的报告；通过还要求过程与语义质量、主线误报控制、机制与反硬编码检查（附录 F）。
• 人工引导的校准：固定模型、harness、工具和预算。失败后人工根据验证证据修订提示词并重新 rollout；任务、验证器和阈值不变。每题最多 1 次初始尝试加 2 次重跑，三次都不通过则排除。进入抽样的检查器–轨迹对须通过冻结验证器，且轨迹至少 40 个交互步。作者写明 40 步是筛选规则，这些试点干预与自主主实验分开。
• 质控与划分：自动检查产物完整性、可复现构建与扫描、验证器隔离；人工确认缺陷语义和补丁定位诊断。去掉重复版本对，并由仓库、CVE、共享版本或相似补丁连在一起的任务进入同一划分。参考检查器、校准轨迹和验证器细节对评测智能体隐藏。

CheckerLab

• 合成与冻结：每次运行得到隔离工作区，含任务说明、修复补丁、代码上下文、分析器工具和已启用技能；参考检查器和留出验证器隐藏。智能体使用 harness 原生能力以及编译、分析反馈，共同预算为 50 分钟主动生成时间。结束时冻结 CSA 检查器或 CodeQL 查询源码，并记录轨迹与工具调用。
• 独立重放：验证器在干净环境从源码重建，不采用智能体自带的二进制。CSA 的对比要求漏洞版报告数大于修复版，且修复版报告数小于 50；至少一条消失报告须落在补丁修改的函数中。CodeQL 使用自己冻结的查询、差分和相关性规则，不套用 CSA 的计数规则。
• 主线误报：更广的主线扫描与任务的漏洞版、修复版都不同，且不允许再改检查器。最多抽取 10 条需判定的告警。Claude Opus 5 分阶段判定过程质量、漏洞语义和抽样主线告警；判定不能推翻已失败的可执行门控。

通过条件与指标

• 最终通过：一次运行只有在正常生成结束，且满足 Equation 5 的全部门控时才通过。其中 Fi 为正常结束，Oi 为客观门控，Ji 为有效评审，Ri 为默认抽样 FP 不超过 25% 的主线误报门控，Mi 为机制充分，Csem 为语义正确性分类，Hi 与 Ai 为硬编码和语义锚定风险。
• 分数下限：过程分 Sp 满分为 100，下限 80。语义分 Ss 满分为 10；CSA 下限为 7，CodeQL 下限为 8。Figure 5 标出同一组阈值。

Pass_i = F_i ∧ O_i ∧ J_i ∧ R_i ∧ [S_p,i ≥ 80] ∧ [S_s,i ≥ t_αi] ∧ M_i ∧ C^sem_i ∧ ¬(H_i ∨ A_i) 该式表示：可执行正确性、过程质量、语义忠实和误报控制不能互相补偿。

• 主指标：Pass@1 是一次独立合成后通过全部门控的任务百分比。Build 与 Diff. SR 分别是独立编译和差分验证通过的任务百分比，分母为全部任务。FPpass 只汇集已通过检查器上已完全裁定的主线告警。回合数和工具调用只在成功轨迹上平均，并计入子智能体活动。

实验设置

• 模型与 harness：7 个模型 × 3 个 harness，共 21 组。模型为 GPT-5.6-Sol、Claude Opus 4.8、Qwen3.8-Max、DeepSeek-V4-Pro-0813、GLM-5.2、Kimi-K3、HY4-Preview。Harness 为 OpenCode、Claude Code、Hermes Agent。Table 2 将前两者写作 GPT-5.6 与 DeepSeek-V4-Pro。
• 任务：CheckerBench 300 题，167 个仓库、297 个 CVE、85 个 CWE。C/C++ 159 题用 CSA；Java 30、Python 51、JavaScript 30、Go 30 用 CodeQL。
• 重复与预算：每组对同一 300 题做 3 次独立重复，三次通过率等权平均。隔离 E2B sandbox，50 分钟主动生成预算。生成失败、拒答和候选代码错误计为失败。效率指标只对成功轨迹平均。
• 指标：Pass@1 为一次合成后通过全部门控的任务百分比。Build、Diff. SR 以 300 为分母。Process 为 100 分制有效分数均值，Semantic 为 10 分制均值。FPpass 只汇集已通过检查器的已完全裁定主线告警；接受门控默认抽样 FP 截止为 25%。
• 评审：Claude Opus 5 分阶段判定误报、过程质量和漏洞语义。人工校验的 pooled Cohen's κ 为 0.85；附录 E.9 写明按 600 对算出 0.852，并四舍五入为 0.85。数值分数误差不在该表范围内。
• 对照：KNighter 原基准的 61 个 Linux 内核任务；消融在同一 300 题上比较 DeepSeek-V4-Pro 的 OpenCode Full 与三个变体。

主结果

下表为三次重复等权平均的 Pass@1（%），据 Table 2。21 组总平均为 32.30%。

表格较宽，可左右滑动

• 端到端与差分：作者称总体 Build 为 78.25%、Diff. SR 为 73.65%；Diff. SR 与 Pass@1 相差 41.35 个百分点，Build 与 Diff. SR 相差 4.60 个百分点。Hermes Agent 上 GPT-5.6 的 Build 为 100.00%、Diff. SR 为 64.00%（Table 2）。作者称从差分验证到完全接受，还要满足语义、过程、误报和正常结束。
• 模型–harness：三个 harness 的平均 Pass@1 为 36.95%、33.81%、26.14%，作者给出最高与最低平均相差 10.81 个百分点。Claude Code 上 DeepSeek-V4-Pro 为 38.33%，高于该 harness 上的 Claude Opus 4.8。Kimi-K3 从 OpenCode 的 38.67% 到 Hermes Agent 的 24.33%，作者给出相差 14.34 个百分点。作者称比较单位应是完整的模型–harness 配置。
• 质量与误报：Qwen3.8-Max 配 Hermes Agent 的 Process 为 90.92/100、Semantic 为 8.53/10，Build 为 44.00%（Table 2）。OpenCode 的平均 FPpass 为 6.63%，Claude Code 为 1.97%。OpenCode 上 Claude Opus 4.8 的 FPpass 为 13.79%（#WN=174），GPT-5.6 为 0.00%（#WN=7）。作者称没有配置同时在合成成功、过程与语义质量、诊断精度上领先。Table 2 下标中，Claude Code 上 HY4-Preview 的 Pass@1 相对同 harness 的 GPT-5.6 低 10.33 个百分点。

语言、CWE 与交互

• 语言：Figure 6(a,b) 对三个 harness 等权平均。作者称每个模型的语言维最低 Pass@1 都在 C/C++，该层有 159/300 题；正文写 DeepSeek-V4-Pro 为 24.53%。正文还写 Claude Opus 4.8 的 Python 为 65.36%，DeepSeek-V4-Pro 的 Go 为 53.33%，Qwen3.8-Max 的 Java 为 54.44%、JavaScript 为 53.33%。Figure 6 文本中可见 24.5、65.4、53.3、54.4、53.3；列名抽取不完整，语言归属以正文为准。作者称 C/C++ 用 CSA、其余语言用 CodeQL，CWE 组的仓库和语言构成也不同。
• CWE：作者称 Qwen3.8-Max 在 CWE-79 上高于 DeepSeek-V4-Pro，在 CWE-787 上顺序相反。正文未给出这两组的具体 Pass@1。Table 8 以 300 题为分母：CWE-787 为 26 题（8.7%），CWE-125 为 21 题（7.0%），CWE-22 为 15 题（5.0%）。Figure 4(c) 按 314 个任务–标签对画扇区，CWE-787 标为 8.3%。
• 工具调用：作者称 Kimi-K3 在三个 harness 的成功轨迹上平均工具调用都最少。Claude Code 上，其回合数为 31.81、工具调用为 38.61，DeepSeek-V4-Pro 为 47.17 与 62.50；作者称工具调用减少 38.2%（Table 2）。Figure 6(c) 画成功运行的 Pass@1 对平均回合，颜色表示 harness、形状表示模型；文本未给出各点坐标。

基线、消融与失败

• KNighter：61 个 Linux 内核任务、DeepSeek-V4-Pro、50 分钟预算、同一验证器（Table 3）。本文方法有效检查器 49/61（80.3%），KNighter 为 41/61（67.2%），去掉技能库为 18/61（29.5%）。作者认为技能引导流程能迁移到这套独立定义的任务。
• CheckerBench 消融：Table 4 的 Full 复用原 OpenCode 运行，Pass@1 为 39.67%；去掉技能与策略参考为 8.33%，隐藏执行反馈为 13.33%，无工具无 harness 的一次生成为 0.33%。去掉 Process 和正常结束要求后的 artifact pass 为 48.67%、18.67%、20.33%、1.33%。一次生成有 237/300 题提交无效或不完整。作者写明历史运行与新运行的日期、上下文限制和隔离不同，不能把差距单独归因于被消融组件。Table 4 的回合数和工具调用对全部 300 题平均，与 Table 2 只统计成功轨迹不同。
• 失败类别：作者分析 4,360 次选定失败运行。预算耗尽 25.32%，合成过程不足 22.96%，语义建模不足 21.15%，误报过多 15.96%，差分检测或定位 8.17%，针对补丁过拟合或锚定 3.56%，产物缺失或无效 1.83%，编译或注册 1.05%。作者举例：计划中的路径敏感分析变成省略锁与控制流条件的 AST 匹配。

其他消融与分析

• 时间截断（Figure 8、附录 H.3）：聚合 Pass@1 在 10、30、50 分钟为 7.24%、26.05%、32.30%；40 分钟覆盖 50 分钟成功的 93.02%，最后 10 分钟增加 2.25 个百分点。跨 harness 平均，40 到 50 分钟增益最大为 Qwen3.8-Max 的 3.67 个百分点和 HY4-Preview 的 3.33 个百分点。
• FP 阈值（Figure 9）：10%、25%、50% 的聚合接受率为 32.05%、32.30%、32.83%，净增 0.78 个百分点；单配置最大增幅为 Claude Code 上 GLM-5.2 的 1.67 个百分点。25% 复现 Table 2。
• 先验暴露（Figure 10、附录 C.3）：CVE 发表晚于模型发布的任务，Claude Opus 4.8 为 3/300，GLM-5.2 为 1，其余模型为 0。100 题、OpenCode、每条件 1 次生成：Claude Opus 4.8 的 O/P/D Pass@1 为 43.00%/42.00%/39.00%，DeepSeek-V4-Pro 为 55.00%/54.00%/52.00%；P–D 差距为 +3.00 与 +2.00 个百分点。精确 CVE 召回从 10.00% 到 1.00%、从 8.00% 到 1.00%。作者认为在该干预下，认出熟悉漏洞只带来有限增益。这些不是三次重复的主 Pass@1。
• 人工一致性（Table 14）：六行 Judge–human κ 为 0.861、0.821、0.806、0.852、0.760、0.813；每行 100 对。CSA 语义行为 0.760，是六行中最低。
• 告警敏感性（附录 E.6）：历史 repeat-1 的 1,940 个通过检查器中，1,566 个零告警、16 个超过 10 条；1,335 条已保存告警为 1,063 TP、272 FP。这不是三次重复合计。加上全记录告警门控后去掉 81 个通过；领先组合从 Claude Code/Kimi-K3 的 122/300 变为 OpenCode/DeepSeek-V4-Pro 的 119/300。作者写明这不重审原先失败的检查器。
• 成功轨迹工具调用中位数（Figure 7，bin 宽 10）：Kimi-K3 在三个 harness 上为 41.5、38、37；Claude Opus 4.8 为 64.5、41、65。柱的具体高度文本未给出。

作者指出的局限与后续方向

论文没有单独的 Limitations、Discussion 或 Future Work 节。附录里明确写出的未完成项如下。

• 公开时间审计：附录 C.1 写明，补丁与检查器的完整首次公开审计尚未完成，账本不能仅凭 CVE 发表日期认定任务此前未被见过。
• 发布后子集：附录 C.2 写明，现有清单在七个模型发布日之后没有 CVE 发表，因此没有七模型共同的发布后子集。
• 裁定稳定性：附录 E.6 写明，在穷尽裁定下，当前全评测排名的稳定性仍未验证；该审计只覆盖已通过检查器的已保存输出。
• 消融归因：附录 H.2 写明，历史 Full 与新消融运行的执行日期、客户端上下文限制和工作区隔离不同，比较不能分离出单个组件的因果效应。
• 时间预算：附录 H.3 写明，时间结果是对原 50 分钟轨迹的回顾性完成曲线，不是单独重跑的截止实验。
• 待随冻结发布的统计：附录 C 写明，最终剔除数量、审计者一致性和污染重叠统计将随冻结发布一并报告。

实验覆盖范围

• 主实验：7 个模型、3 个 harness、300 个任务、每配置 3 次独立重复、50 分钟主动生成预算（Section 5.1、Table 2）。Table 2 报告 OpenCode、Claude Code、Hermes Agent；附录 A 还将 OpenClaw、PAI、DS Harness 列为多 harness 适配器，正文未给出这三者的 Pass@1。
• 任务构成：C/C++ 159 题用 CSA，Java 30、Python 51、JavaScript 30、Go 30 用 CodeQL；167 个仓库、297 个 CVE、85 个 CWE（Section 3.2、Table 7、Table 8）。
• 评审：Claude Opus 5；抽样 100 个 CSA 任务和 100 个 CodeQL 任务，600 个评审–人工对，pooled Cohen's κ = 0.85（Section 5.1、附录 E.9）。
• 对照与消融：KNighter 对照为 61 个 Linux 内核任务，模型为 DeepSeek-V4-Pro（Section 5.3）。消融为同一模型在 300 题上的 OpenCode 变体；新变体每题 1 次生成，Full 复用历史候选（附录 H.2）。
• 敏感性与暴露：FP 阈值取 10%、20%、25%、30%、40%、50%，裁定标签保持不变（Section 5.6）。时间分析是对已有轨迹施加 10 至 50 分钟截断。先验暴露为 100 个按语言分层的任务、Claude Opus 4.8 与 DeepSeek-V4-Pro、每条件 1 次生成（Section 5.8、附录 C.3）。失败分析使用 4,360 次选定失败运行（Section 5.7）。

• 定位：CheckerBench 与 CheckerLab 用来评测编码智能体能否把漏洞修复实例做成可复用的静态分析检查器，而不是只生成一次性补丁或做漏洞分类。
• 问题：作者称现有仓库级基准多评补丁、补全或漏洞检测，交互常被拆成预定阶段，正确性信号也不覆盖检查器重跑、补丁定位和误报。
• 做法：300 个任务来自 297 个 CVE，覆盖五种语言；C/C++ 用 CSA，其余用 CodeQL。合成时可见补丁、双版本和脚手架，留出验证器隐藏。50 分钟内冻结检查器后，独立重建，并同时要求差异诊断、补丁相关、主线误报、过程分、语义分和反硬编码。
• 主结果：7 个模型、3 个 harness、每配置 3 次重复，平均 Pass@1 为 32.30%，最高为 OpenCode 上 Claude Opus 4.8 的 45.33%。总体 Build 为 78.25%，Diff. SR 为 73.65%；作者写后两者与 Pass@1 的差距为 4.60 和 41.35 个百分点。作者称 harness 会改变成功率以及模型排序。
• 对照：在 KNighter 的 61 个 Linux 任务上，DeepSeek-V4-Pro 的有效率为 49/61（80.3%），KNighter 为 41/61（67.2%），去掉技能后为 18/61（29.5%）。同一模型在 CheckerBench 上，Full 的 Pass@1 为 39.67%，去掉技能为 8.33%，隐藏执行反馈为 13.33%，无 harness 的一次生成为 0.33%；作者写明不能把这些差距单独归因于被消融组件。
• 作者结论：作者称在所评仓库和分析器配置内，当前编码智能体仍难以稳定做出可靠、可复用的检查器，并把 CheckerBench 定位为可复现测试台。