PROBE × InfraDev × FeatureArc：编码 Agent 评测从单请求到真实工程流的三个台阶 精读

本组论文

• PROBE: Frontier Coding Agents Find Different Bugs Than Maintainers Fix
  • 链接：https://arxiv.org/abs/2610.35987
  • 发表时间：2026 年 10 月（arXiv 2610.35987，2026-10-26 提交）
  • 机构：LogicStar.ai + ETH Zurich
  • 领域标签：软件工程、LLM Agent 评测、主动式 bug 发现
• InfraDev: Can Coding Agents Develop AI Infrastructure, and How Can We Tell?
  • 链接：https://arxiv.org/abs/2610.36589
  • 发表时间：2026 年 10 月（arXiv 2610.36589，2026-10-27 提交）
  • 机构：University of Edinburgh + Tencent Hunyuan（腾讯混元）
  • 领域标签：AI 基础设施、多 GPU 软件工程、Agent 评测
• FeatureArc: Benchmarking Coding Agents on Evolving Features
  • 链接：https://arxiv.org/abs/2610.37434
  • 发表时间：2026 年 10 月（arXiv 2610.37434，2026-10-27 提交）
  • 机构：Tencent Hunyuan（腾讯混元）+ The Chinese University of Hong Kong
  • 领域标签：软件演化、持续多阶段开发、长程 Agent 评测

一、论文背景

1.1 领域地基：从 SWE-bench 到能力天花板

编码 Agent（coding agent）的研究地基是 SWE-bench 系列奠定的「issue → 补丁 → 测试验证」范式：给定一个 GitHub issue 和仓库快照，agent 产出补丁，用 PR 自带的 fail-to-pass 测试判定是否解决。2023 年 SWE-bench 发布时最好的模型只能解决 1.96% 的问题；到 2026 年，SWE-bench Verified 子集（500 个经人工验证的 issue）上最强模型已能解决超过 70%。表面上，「编码 Agent 已接近实用」的叙事似乎成立。

但这个范式有三块看不见的天花板。第一，任务粒度是单请求：一次只修一个 bug、实现一个功能，而真实工程师的工作是连续的——在同一个代码库上持续发现 bug、持续扩展功能、持续维护自己的早期代码。第二，评分依赖 PR 自带测试：这些测试本身可能是不完整的，SWE-ABS 等工作已经证明大量被接受的补丁实际上是错的。第三，参考答案是已知的：issue 报告了 bug，agent 只需要定位并修复，而真实工程中最困难的部分恰恰是「发现哪里有问题」。

2026 年 10 月下旬，三篇论文在同一周内出现在 arXiv 上，分别从三个方向捅破了这三块天花板，它们恰好构成一组阶梯。

1.2 初学者概念阶梯

读这三篇论文之前，先把几个核心概念按依赖关系排成阶梯：

• 编码 Agent（coding agent）：以 LLM 为核心、能自主检查仓库、编辑代码、运行测试的智能体。模型（GPT-6 Sol、Claude Opus 5.5 等）与外壳（Codex CLI、Claude Code、OpenCode 等 harness）共同构成评测单元。
• F2P / P2P 测试：fail-to-pass 测试在正确补丁应用前失败、应用后通过，用于验证新行为；pass-to-pass 测试在前后都应通过，用于验证旧行为未被破坏。这是仓库级评测的判定基石。
• 开放式任务 vs 封闭式任务：封闭式任务给定问题（issue、PR 描述），agent 找解法；开放式任务只给仓库（甚至什么都不给），agent 要自己发现问题。开放式任务的难点在于 ground truth 本身未知——一个仓库里到底有多少 bug，没人知道。
• 多遍审计 harness：把仓库切成多个文件分区，每个分区在独立 agent 会话中审计，配合全仓上下文文档与调用图。这是 PROBE 把召回率提升一个数量级的关键工程。
• 对抗补丁与隐藏探针：对抗补丁是「能通过官方测试但违反任务真实要求」的错误实现，用来暴露测试盲区；隐藏探针是为盲区补写的测试。二者构成「红队攻击测试套件」的闭环，是 InfraDev 的方法论核心。
• L1–L4 委托级别：类比自动驾驶自动化等级。L1 用户告知如何修复；L2 用户指出失败行为；L3 用户只告知该段是否通过；L4 用户只给下一段规格、对早期阶段一言不发。L4 要求 agent 自己发现并修复早期错误，是 FeatureArc 的评测设定。

1.3 为何放在一起读

三篇论文回答的是同一个问题的三个侧面：编码 Agent 到底能不能干真实工程师的活？ PROBE 问「能不能主动发现整个仓库里维护者会修的 bug」（发现侧）；InfraDev 问「能不能实现生产级 AI 基础设施的多文件多 GPU 改动」（实现侧）；FeatureArc 问「能不能在没有人工检查的情况下持续演化同一个功能」（演化侧）。三者拼起来正好覆盖真实工程工作流的完整生命周期，而它们的结论惊人地一致：单请求分数高估真实工程能力 2 倍以上。放在一起读，能看到「评测基准如何一步步逼近真实工程」的完整方法论演化。

机构视角的一个补充观察。三篇都体现了「企业 + 高校」的合作结构：LogicStar.ai（专注代码正确性的商业公司）与 ETH 的组合让 PROBE 兼具产品现实感（主动找 bug 是其商业命脉）与统计严谨性（stable-beta 建模、置换检验）；Edinburgh 与腾讯混元让 InfraDev 的任务筛选有真正的基础设施专家把关（36 个 PR 全部人工挑选）；腾讯混元与 CUHK 让 FeatureArc 从一开始就有 8,881 个真实 IDE 会话的内部数据支撑问题定义。这种产学结构或许不是巧合——真实工程评测需要只有生产企业才有的场景、数据与算力，而严谨的评测方法论需要学术团队的验证工具箱，两者缺一就不能同时做到「真实」与「可信」。

1.4 一张全景图：三篇论文在评测空间中的坐标

把「任务开放度」（从给定问题到自主发现问题）与「时间跨度」（从单次请求到持续多阶段）作为两条轴，可以给三篇论文定位：SWE-bench 系在左下角（封闭问题、单时间点），PROBE 在左上角延伸（全开放发现、单一快照上的审计），InfraDev 沿纵轴中度上移（PR 级改动、需双向评分加固），FeatureArc 在横轴上走到最右（2–10 个阶段的持续委托）。三篇合起来把原来左下角的一小块评测空间扩展成了一个完整的四象限——而这个四象限的中心地带（既开放又持续的任务，比如「自主发现并持续修复一个演化仓库的 bug」）目前仍是空白，值得读者留意。

2.1 谱系定位

三篇论文共享同一个祖系（SWE-bench 范式），但各自走向不同的分支：

2.2 各自的前序工作与差异化

PROBE 的前序是三类：(1) 修 bug 基准（SWE-bench、SWE-Bench Pro），给定 issue 让 agent 修，已证明可行，但没有回答「agent 能否自己找到 bug」；(2) 受限 bug 检测（SWR-Bench 给 PR 让 agent 写评审意见、Active-SWE 给定受影响文件），都预先提示了缺陷位置；(3) 安全漏洞检测（Cybench、CyberGym-E2E、BountyBench），聚焦可利用的安全漏洞而非一般软件缺陷。PROBE 的差异化在于：任务是完全开放式的（审计整个仓库、无任何提示），且 ground truth 用「维护者实际修复行为」锚定——这绕开了「仓库总 bug 数未知」这一经典难题（Bird et al. 2009 指出依赖 issue 链接的数据集小而有偏）。此前没有任何基准评测过一般性的全仓 bug 发现。

InfraDev 的前序是 AI 基础设施与 ML 工程基准：KernelBench/TritonBench/ParallelKernelBench 评单内核或多 GPU 内核生成，ISO-Bench/InferenceBench/Φ-Bench 评推理优化但目标固定，MLE-bench/PaperBench 评「使用」基础设施而非「开发」它。其差异化有二：任务单元是生产框架（Megatron-LM/verl/vLLM）的真实合并 PR——典型地跨多文件、须在多 GPU 上正确运行；方法单元是「测试与 prompt 联合合成」——此前 UTBoost 只加强测试、SWE-ABS 只用对抗补丁曝光假通过、SWE-bench Verified/SWE-Bench Pro 只丰富 prompt，InfraDev 首次把两者放进同一个闭环。

FeatureArc 的前序是特性基准与多阶段基准：FEA-Bench/FeatBench/FeatureBench 均为固定代码库上的单次特性请求，没有后续阶段可供错误传播；CCBench 一条指令给全部阶段；SWE-STEPS 每段返回测试反馈且串联的 PR 不必属于同一功能；SlopCodeBench/EvoCode-Bench/EvoWeb 的阶段是手写或从相似产品生成的，不遵循功能在仓库中的真实生长方式。FeatureArc 是 Table I 对比表中唯一同时具备「历史同功能依赖 + 顺序请求 + 在 agent 自己代码上持续评测 + 无隐藏测试反馈」四项的基准。其 L1–L4 分级直接借鉴 SAE 驾驶自动化分级与 AI agent 自主性分级，且有明确的工业动因：腾讯内部评测只覆盖 L1–L3，早期尝试把单个功能请求切段制造出的阶段几乎相互独立，测不出「连续扩展」。

2.3 三篇之间的互文

三篇论文互相印证又互相补位。PROBE 证明「发现问题」这一侧存在 agent 与人类维护者的系统性分布错位；InfraDev 证明「实现改动」这一侧官方测试与原始描述双向不可靠；FeatureArc 证明「持续演化」这一侧自检信号几乎失效。它们共同的前序敌人是同一个：用 PR 自带测试 + 单请求定义的旧范式。PROBE 的「LLM 评审团验证参考集之外发现的有效性」与 FeatureArc 的「绿自测不预测隐藏 F2P」形成跨论文的呼应——两种情况下，局部验证信号都与全局真值脱钩。

另一个值得注意的互文是机构视角的对称性。PROBE 出自 LogicStar.ai（一家做自主代码正确性的商业公司）与 ETH Vechev 组，其商业产品线决定了「主动发现 bug」是刚需场景；InfraDev 与 FeatureArc 都有腾讯混元参与，分别从基础设施开发（训练/推理框架是混元自身的生产资料）与功能持续演化（腾讯内部 8,881 个 IDE 会话中 43.5% 含后续交互的实证数据支撑了 L4 需求）两个方向服务模型迭代。学术-工业的分工在三篇中各不相同：PROBE 是公司定义问题、高校Contributing 方法论；InfraDev 是高校主导方法、公司提供场景与算力；FeatureArc 是公司主导全链路、高校参与构念与通信作者把关。这种多样性说明真实工程评测已经是学界与工业界的共同议程，而非单方面的学术趣味。

从发表时间线看，三篇都在 2026 年 10 月下旬提交（26/27/27 日），彼此大概率独立完成——这种「同时收敛」本身就是领域信号：SWE-bench Verified 分数在 2026 年突破 70% 后，评测社区不约而同地把矛头指向了同一个盲区。可以预期这三个方向（开放式发现、评分对抗强化、长程持续演化）会成为接下来一两年基准工作的标准配置项。

三、问题定义

3.1 PROBE：开放式全仓 bug 发现的形式化

设仓库在 T0 时刻的快照为 R，其真实包含的全部 bug 集合为 U（未知）。维护者在参考窗口 [T0, T1]（18 个月）内实际修复的、且在 T0 时已存在的 bug 构成参考集 H ⊆ U。PROBE 要评测的是：给定 R（无历史、无网络），bug 发现器 F 输出发现集 F(R)，度量其相对于 H 的召回率与精确率：

• Recall = |{h ∈ H : ∃f ∈ F(R), f 匹配 h}| / |H|
• Precision = |{f ∈ F(R) : ∃h ∈ H, f 匹配 h}| / |F(R)|

核心挑战有三。第一，H 是 U 的真子集且不完整：T1 之后维护者还会继续修 bug，因此即便完美发现器精确率也有上限。作者用对数正态分布拟合修复位置的尾部，估计完美发现器的精确率上限仅 26–47%。第二，匹配问题：一条 agent 发现与一个参考 bug 是否为同一缺陷，需要可靠的判定器。第三，分布错位问题：低精确率究竟意味着幻觉（报告假 bug）还是错位（报告真 bug 但维护者不会修）？这决定了结论完全不同的两种解读，需要独立的有效性验证。

3.2 InfraDev：AI 基础设施开发的双向评分可靠性

给定生产框架仓库的 pre-PR 快照 S 与任务 prompt p，agent 产出补丁 Δ，评分器须判定 Δ 是否正确实现了真实 PR 的改动。正确性有两个正交维度：数值正确性（在分布式执行下算出正确的激活、梯度、状态）与行为正确性（新功能真的生效、优化真的省了内存/通信/时间）。

核心挑战是评分的双向不可靠。方向一（假阳性）：官方测试不完整——36 个 PR 中 24 个没有任何数值断言，15 个性能优化 PR 中 13 个不检查承诺的节省，因此「跳过优化的补丁也能通过」。方向二（假阴性）：PR 原始描述欠指定——省略了测试依赖的接口名，正确实现也会因 import 失败而挂掉。且两个问题耦合：测试强制的每条需求都必须写进 prompt，加强测试而不改 prompt 会让任务变得不可解。此外还有工程挑战：每任务独立构建 Docker 镜像在依赖频繁变更的基础设施项目上成本爆炸（19 个 Megatron-LM 任务横跨 5 个月却用 6 个版本的 Transformer Engine），多 GPU 执行使单个模型评测消耗数百 GPU 时。

3.3 FeatureArc：L4 持续演化的形式化

一个任务是从仓库历史恢复的同功能链 m0, …, mn−1：m0 实现功能初版，每个后续 mi 扩展同一功能。任务提供初始状态 S0、容器镜像与逐段规格（需求文档 + 接口契约）。L4 协议下，agent 在单一持久会话与工作区中依次接收规格，在自己上一段的代码上实现新请求；隐藏的 stage gate 对每段运行 F2P/P2P 套件，失败既不回滚也不告知；全部段结束后 chain gate 在最终工作区上检验完整功能。

核心挑战有三。第一，阶段依赖的构造性：怎么保证后续段真的依赖早段（而不是可独立求解的拼盘）？第二，评分的归属：后续段失败时，是这段自己写错了，还是继承了早段的缺陷，还是回归破坏了旧行为？三种机理需要不同的测试设计与轨迹证据才能区分。第三，自主错误察觉：L4 把「发现并修复自己早期错误」的责任完全交给 agent，而这一能力在 L1–L3 评测中从未被测量过——因为那时光线（用户反馈） always 打在失败处。

3.4 三篇问题定义的公共结构

把三节的形式化放在一起，能看到一个公共结构：三者都在处理「验证信号与真实要求之间的缺口」，只是缺口的位置不同。PROBE 的缺口在参考集之外（真 bug 但维护者未修，占有效的三分之二以上）；InfraDev 的缺口在官方测试之内（32% 假通过）与任务描述之内（欠指定导致假阴性）；FeatureArc 的缺口在反馈通路本身（L4 切断了外部反馈，自测信号失真）。用测量理论的术语说：PROBE 处理的是「标准答案不完备」问题，InfraDev 处理的是「测量仪器偏倚」问题，FeatureArc 处理的是「被测者自我报告不可信」问题——分别对应教育测评、工程验收与行为审计三个经典场景在编码 Agent 领域的重演。这个公共结构也预示了三者方法论的公共解法：都必须引入与被测系统独立的第二验证通路（LLM 评审团 / 对抗构造的探针 / 隐藏门禁 + 轨迹标注），而第二通路自身的可靠性又要用第三层手段（人工盲审 κ / 三条件合取验收 / 三模型多数投票 + 盲验证）来背书——形成「验证的递归」，递归的深度是基准可信度的度量。

此外，三个问题定义都内嵌了「时间」这个此前被 SWE-bench 范式冻结的维度：PROBE 的时间是维护者的修复历史（18 个月窗口 + 对数正态外推），InfraDev 的时间是 PR 前后两个快照，FeatureArc 的时间是功能生长的多个阶段。把时间解冻后，任务的 ground truth 从静态快照变成了动态过程，这既是三篇能发现单请求范式盲区的原因，也是它们构建成本高于传统基准一个数量级的根源。

4.1 PROBE：六步流水线 + 两步匹配 + 多遍 harness

参考集构建（六步流水线）。从 20 个 Python/JS/TS 仓库（T0 = 2025-01-01 快照，≤200k 行、无网络依赖、宽容许可证）出发：(1) 识别 bug 修复 commit——确定性规则过滤自动化维护/生成文件，再用 LLM 结合 commit 信息、补丁、关联 issue 与 PR 判定是否修正运行时行为，13,254 个 commit 保留 4,296 个；(2) 抽取 bug——LLM 按根因拆分，得 4,763 个候选；(3) 锚定代码变更——把修复时刻 T′ 的代码区间沿文件重命名与行增删回溯映射到 T0，映射失败则丢弃，剩 3,345 个；(4) 存在性验证——带完整历史与 AG-SZZ 追踪信息的 agent 判定 bug 在 T0 是否已存在，剔除后引入的，剩 2,501 个；(5) 合成 bug 报告——基于 T0 状态重写描述且不引用修复；(6) 去重——严格共享根因标准下合并，得 2,457 个参考 bug。两阶段审计验证质量：agent 审出 8.5% 可疑，人工盲标 100 个仅弱重叠（κ=0.29），故保留全集。

总 bug 池估计（形式化的亮点）。以「bug 修复 commit 数」而非日历时间为时钟（消除维护活跃度波动），对每个 bug 的修复位置 xij 拟合条件似然 p(xij | xij < Nj) = f(xij)/F(xij)——条件化使得每个仓库未知的 T0 bug 总数在似然中相消，只用「修复有多前置」来拟合。三候选族（指数/Weibull/对数正态）中对数正态拟合与留出预测最好，外推得 5 年内修复 5.2k–5.9k、10 年内 7.2k–9.4k 个 bug，由此定出完美发现器的精确率天花板 26–47%。

两步匹配器。第一层规则过滤：六种相似度信号（行区间重叠 Jaccard、描述/全文嵌入余弦、代码 token/标识符/API 调用的 IDF 加权 Jaccard），任一超阈值即送审，2.7% 的仓内配对通过过滤且包含全部真匹配。第二层 LLM 判官：Gemini 3.5 Flash 判定「解决任一根因是否同时解决另一个」。在 307 条发现、67 个专家验证匹配上，五次运行平均精确率 98.8%、召回 97.6%，每次 $5–8/千条发现。判官与带全仓访问的 Claude Opus 5 在 452 对上一致率 98.9%（κ=0.932），分歧的 5 对上人类站在判官一边。

多遍审计 harness。原始单会话审计召回不足 1%（全仓 20 仓库报出不到 100 条发现），因此：(i) 预处理——探索 agent 编写项目上下文文档（目的/架构/公共 API/支持的输入），静态构建函数级调用图；(ii) 文件分区——按复杂度评分 s(f) = 3c(f) + 0.05l(f) + 0.5n(f)（跨文件调用伙伴数权重压倒行数：一个跨文件调用伙伴抵 60 行），最复杂文件独立成遍，其余按目录分组、60k token 预算切分，20 仓库共 740 遍覆盖 4,468 文件；(iii) prompt 由审计指令 + 上下文文档 + 目标文件全文 + 调用图摘录 + 跨文件调用者/被调者代码片段构成，发现以与参考 bug 同 schema 的 JSON 报告；(iv) 每遍 3 小时超时、独立 Docker、无网络、无版本历史。

4.2 InfraDev：对抗补丁 → 隐藏探针 → prompt 的联合合成闭环

PR 筛选。从 2025-01 到 2026-09 合并进 Megatron-LM/verl/vLLM 的 21,389 个 PR 中，规则过滤（已合并未回退、≥1000 行、带新测试）加领域专家人工挑选核心功能改动，得 36 个任务：新特性 19、性能优化 15、重构 1、bug 修复 1；平均改动 17.4 文件/1,818 行，20 个需多 GPU。

隐藏探针合成（Algorithm 1）。probe agent 先总结 PR 承诺实现什么；再构造对抗补丁——通过全部官方测试但违反数值/行为正确性的错误实现（例：verl PR 6974 承诺只同步变化的权重条目，对抗补丁全量发送 65,536 条也能过官方测试）；然后为官方测试未覆盖的要求编写探针。探针与对抗补丁在循环中共同修订，验收检查（Algorithm 2）要求：每个探针在金补丁上连续三次通过（接受对的），在 pre-PR 快照、空壳补丁（保留金补丁全部接口但新增函数全部抛异常，防止探针只查接口存在性）、每个对抗补丁上全部失败（拒绝错的），且每个对抗补丁在官方测试上得分不低于金补丁（证明它真能骗过官方测试）。三条件合取，缺一不可。

prompt 合成。把 PR 信息切分为「规格」（做什么：测试调用的接口、官方测试与探针检查的行为、完成定义）与「解法」（怎么做：算法、公式、数值常数与容差、验证策略），prompt 只含规格。静态分析器从金补丁提取接口契约（测试引用的符号、签名、形状、配置开关），authoring agent 据此撰写，双重检查：linter 拒绝漏掉任何契约符号的 prompt，checker agent 拒绝泄露解法的 prompt，authoring 迭代修订直到双过。

共享执行环境。打破 Docker 前缀缓存复用的低效：轻量基础镜像只装跨 PR 共享件（CUDA、Python），每任务依赖装入 uv 安装的虚拟环境放共享卷上，依赖哈希相同的环境直接共享、新环境硬链接缓存包而非重装；模型权重与数据集统一进共享 HF 缓存。在 Megatron-LM 上省 57% 存储（80.7→34.8 GB）、vLLM 上省 52%（206.0→98.8 GB），且节省随任务数增长（Megatron 两任务省 17% → 全部 19 个省 57%），构建时间省 13–14%。

4.3 FeatureArc：历史链挖掘 + 配对参考态 + L4 协议

五步构建流水线。(1) 历史分析：选 ≥30 星、宽容许可、可离线 Linux 构建的 Python/TS/Rust/Go 仓库，构建随 commit 序演进的模块导入图，拓扑与语义 agent 互补地检查模块结构与 commit 意图。(2) 演化链挖掘：把候选关系表达为证据图（节点是 commit 或小 commit 组，边是共享代码元素/文件历史/引用/导入），四路图搜索——全局 beam（跟随有前途路径）、锚点引导（从已识别的特性改动出发）、端点桥接（连接相关端点）、社区引导（检查相关变更群）；LLM 评审 agent 对照源码、测试与 diff 审链，只有每段都扩展同一用户可见功能且行为可观测可测试才保留，并补漏、删无关、调段界。(3) 参考态构造：按角色标注历史文件补丁（特性/测试/必要依赖），从最终 checkpoint 摘除所选补丁得 S0，按序重放得 S1..Sn，未选改动留作共享上下文——配对态使每段的贡献可被直接测试。(4) 环境与测试验证：环境 agent 准备离线容器并修复到参考态可构建；测试抽取 agent 打包历史测试及 fixture，按在配对态上的观测结果分类：F2P 须前败后过、P2P 须前后皆过，链级套件在 S0 与 Sn 间同样验证。(5) 规格生成：规格 agent 用段补丁与 F2P 测试写需求文档（行为与验收标准）与接口契约（名称/签名/常数/错误消息），发布前清除 agent 生成文档并还原泄露后续实现的文档。

评测集治理。分层抽样（每语言 25 个、按链长分层）→ 多模型轨迹筛查剔除任务缺陷（排除 7 个：5 个链级套件要求了未指明行为、1 个测试套件自身缺陷、1 个仓库钩子截获 prompt）→ 人工检查（规格质量、契约与隐藏测试对齐、段间是否真扩展同一功能），最终 73 任务/263 阶段/53 仓库。

L4 协议。单会话单工作区贯穿全任务；agent 可查自己的代码、跑自己的检查，但参考补丁、隐藏套件、未来规格全部保密；每段完成触发隐藏 stage gate（F2P+P2P 双过才算段过），失败不回滚不上报，下段从 agent 刚产出的代码开始；末段后 chain gate 在最终工作区跑链级 F2P/P2P 套件检验完整功能。每段 4 小时预算。

轨迹标注体系。三类标签：过程标签（最强检查形式、末次测试结果、准则覆盖度、停止原因、驳回证据、先前察觉——只用规格/轨迹/agent 代码可见信息）与诊断标签（继承性——失败是否由早段缺陷引起及引入段，F2P 失败原因细分）。三个模型（Hunyuan 4 Preview、DeepSeek V4.1 Flash、GLM-5.3 Flash）独立标注取多数，第一作者仲裁全分歧项；人工盲审验证一致率 89.4–100%，关键标签 Fleiss κ 0.80–0.94。

4.4 方法论中的公式直觉

三篇论文中值得向初学者转述的公式并不多，但每个都有清晰的直觉。PROBE 的条件似然 p(x|X<N) = f(x)/F(N)：直觉是「只观察窗口内修复的 bug，相当于把完整分布截断后重新归一化」，好处是每个仓库未知的 bug 总数在似然中相消——你不需要知道总共有多少 bug，只需要知道已修复的修复时机有多前置，就能外推尾部。同一直觉的另一个表达式是完美发现器的精确率上限：如果 agent 报的 bug 里只有落在「人类 5–10 年内会修」的子集才算命中，而这个子集只占快照期 bug 池的 26–47%，那 7% 的实测精确率要乘上这个天花板修正后再解读。PROBE 的文件评分 s(f) = 3c(f) + 0.05l(f) + 0.5n(f) 则是工程判断的代数化：一个跨文件调用伙伴的权重抵 60 行代码，因为跨文件接口是理解难度的主来源，行数只是代理变量。InfraDev 的 resolve 判定（补丁通过数 ≥ 金补丁通过数）看似简单，实则解决了「金补丁自身也有挂掉的测试」这一现实问题——门槛不是满分而是「达到人类实现的水平」。FeatureArc 没有显式公式，但其条件切分比较（同一 task-stage 组内对比前段成败两种条件的 F2P 通过率再组间平均）是因果推断中配对设计的干净实现——组内配对消除了任务难度混杂，这是其 47.6pp 落差结论可信的方法论根基。

5.1 核心数据总览

三篇的实验设置分别是：PROBE 以多遍 harness 评 10 个前沿模型（GPT-5.6 家族三个变体、GPT-5.4、Claude Sonnet 5 与 Opus 5、Gemini 3.5 Flash、GLM 5.3 Flash、DeepSeek V4.1 Flash、Muse Spark 1.3），每配置跑一轮（重复配置除外），全部用统一 harness 以隔离模型差异；InfraDev 以 2.5 小时/任务的预算评 6 个 agent（两个闭源跑 Codex、四个开源跑 OpenCode），推理档位统一 xhigh；FeatureArc 以每段 4 小时预算评 10 个 agent（9 个跑 Claude Code、GPT-6 Astra 跑原生 Codex CLI 以保留其会话恢复机制），单会话贯穿全任务。

PROBE 主结果（10 模型 × 多遍 harness）：

最佳召回仅 20.8%（GPT-5.6 Sol high），无一模型精确率超 8.1%。推理努力从 low 扫到 xhigh，Luna 召回从 5.3% 升至 17.3%（$8→$131）而精确率几乎不动——更强的推理主要靠多报（发现数与召回的 Pearson r = 0.94），不是靠报得更准。便宜模型出现性价比反转：DeepSeek V4.1 Flash 与 GLM 5.3 Flash 的 F1 超过 GPT-5.6 Sol (medium)，成本不到其五分之一。

InfraDev 主结果（6 模型 × 36 任务）：

最佳 38.9%，且推理类（vLLM）任务所有模型都只解 1/10。通过率 74.3–83.3% 的高分掩盖了 25.0–38.9% 的解决率——任务只有全部测试通过才算解决，看似完整的补丁过不了少数精确测试。

FeatureArc 主结果（10 agent × 73 任务，L4）：

汇总裁减：首段 62.7% → 整功能 28.5%，不足一半；每个 agent 损失 26.0–38.4 个百分点。排名大体一致（m0 与 Gate 的 Spearman ρ=0.87），说明难度结构相似，但首段分数系统性高估整功能完成率 2 倍以上。表中的 Cont.（延续率）列揭示了一个分化：首段成绩相近的 agent（如 60.3–64.4% 的中段集团）在整功能上拉开到 21.9–34.2%，分化的主要变量正是「前段失败后的下段表现」——这也是 RQ2 要量化的核心。

5.1.1 三张核心表的逐行解读

PROBE 表的逐行读法。第一行 GPT-5.6 Sol (high) 是「不计成本」的天花板：$1,185 买到 20.8% 召回，但精确率 6.7% 意味着每 15 条发现只有一条与维护者修复对齐。第二行 GPT-5.6 Luna (xhigh) 是全文最划算的一行：召回 17.3%（达第一行的 83%）只花 $131（11% 的成本）——推理努力的边际回报递减在这里极其醒目。第三行 DeepSeek V4.1 Flash 用 $73（Sol high 的 6%）拿到 15.2% 召回与全场最高精确率 8.1%，F1 10.5% 反而登顶：在「报出来的东西维护者也会修」这个维度上，便宜模型是最准的。第四、五行说明同系模型换档位不改变精确率（6.7% / 7.0%），能力差异全部体现在召回上。最后一行 Claude Sonnet 5 (medium) 的 7.9% 召回与 $421 成本组合最差——单条有效发现的成本是 Luna xhigh 的约 8 倍。整张表的单调关系只有一个：钱买召回，不买精确率。

InfraDev 表的逐行读法。第一行 GPT-6 Sol 以 43.9 分钟的 Median runtime 全场最快、38.9% 解决率全场最高，但 $5.37 的成本意味着跑完全部 36 任务约 $193——速度与质量的兼得使其成为唯一「既快又对」的选项。第二行 HY4 preview 是开源组的赢家：36.1% 与 GPT-6 Sol 只差一个任务，$2.09 的成本与 83.3% 的通过率（全场最高）使其成为性价比首选——通过率高说明它的补丁结构完整度高，输在少数精确测试上。第三到五行挤在 30.6%：GPT-5.6 Sol 贵 9.5 倍却与 DeepSeek V4 Pro、Kimi K3 完全同分，这是闭源模型溢价最直白的一行；DeepSeek 以 $1.89 全场最低成本跻身该档。最后一行 GLM 5.3 的 25.0% 与最长的 136.9 分钟组合，说明其慢在搜索而非验证。单独一行数据值得全文记住：所有模型在推理类（vLLM）任务上都只解 1/10——这一子类对 2026 年的前沿模型近乎地板，任何在该子类上的进步都会直接改写榜单。

FeatureArc 表的逐行读法。第一行 Claude Opus 5.5 一骑绝尘：首段 83.6% 领先第二名 16.5 个百分点，整功能 49.3% 是唯一接近一半的 agent，Cont. 79.2% 全场最高说明「前段失败后下段依然能过」的韧性最强。第二行 GPT-6 Astra 的 37.0% 巩固第二梯队。中间集团（Hunyuan 4 Preview 到 Doubao 2.1 Pro，共七行）首段挤在 52.1–64.4% 的窄带里，整功能却散布在 17.8–34.2%——首段分数几乎不预测整功能排名，这正是 ρ=0.87 之外那 13% 方差的意义所在。倒数第二行 Kimi K3 的 19.2% 与 Doubao 的 21.9% 相差不到 3 个百分点，已落在置信区间重叠带内——榜单下半段的区分需要更大样本，这是使用该基准时要克制的结论强度。最后一行汇总给出全文引用最多的那对数字：62.7% → 28.5%。

5.2 消融解读

PROBE：harness 消融揭示覆盖瓶颈。以 Claude Sonnet 5 与 GPT-5.6 Luna 对比四档：Vanilla（单会话原始 CLI）召回 0.6–0.9%（全部 20 仓库不足 100 条发现）但精确率高（17.4–32.3%）；Passes（保留 740 遍分区但换成极简 prompt）召回升到 5.3–5.8%；完整 harness 再升到 7.6–7.9% 且更便宜（Luna $15 vs Passes $18 vs Hound $129）。解读：瓶颈不是模型看不出 bug，而是单会话根本走不完仓库——分区把「审计整个仓库」分解为可行的小任务，上下文文档与调用图则防止分区切断跨文件推理。与前序 bug 发现器比，安全审计 agent Hound 召回不到一半（3.2%）且贵 8.6 倍，基于性质测试的 agentic-pbt 召回不足 1%。这组消融还有一个次级发现值得注意：Vanilla 的精确率（17.4–32.3%）远高于完整 harness（5.8–7.0%），说明单会话下 agent 只报最有把握的少量发现，而多遍结构把发现数量放大两个数量级的同时把精确率稀释了——召回-精确率的权衡在 harness 设计层面就已经内嵌，不是模型属性。五仓库子集上的对齐比较（Claude Opus 5 达 21.2% 召回 / 10.0% 精确率，与 GPT-5.6 Sol medium 持平）则排除了「便宜模型占便宜是因为仓库子集不同」的质疑。

InfraDev：探针与 prompt 的双向消融。加探针使每个模型的解决率降 11–19 个百分点（GPT-6 Sol 58.3%→38.9%，官方测试下的虚高即刻现形）；216 个提交中 102 个通过全部官方测试，其中只有 69 个也通过探针——探针拒绝了 32% 的「官方认证」。反向消融更惊人：把合成 prompt 换回 PR 原始描述，在 Megatron-LM 上一旦加上探针，GPT-6 Sol 与 DeepSeek V4 Pro 都从能解若干任务跌到解决率为零（GPT-6 Sol 68.4%→5.3% 量级）。解读：测试与 prompt 必须联合设计——只补测试，欠指定的 prompt 让正确实现也挂掉（假阴性）；只改 prompt，盲区测试放过跳过优化的补丁（假阳性）。二者是同一枚硬币的两面。分仓库的分解让这幅图景更立体：verl 任务上官方测试虚高最严重（GPT-6 Sol 100%→42.9%，虚高 57 个百分点），因为 RL 框架的行为类要求（如权重同步只传变化条目）几乎不被官方断言覆盖；vLLM 任务加探针前后全员 10% 不变，说明推理类任务的难度根本不在测试覆盖而在任务本身。共享环境的消融则证明工程优化不伤效度：节省 52–57% 存储的同时评分结果与逐任务镜像一致。

FeatureArc：条件消融定位失败机理。按前段成败切分同任务同段的 109 个组：段过之后下段 F2P 通过率 72.6%，段败之后仅 29.0%（ pooled 70.2% vs 22.6%，落差 47.6 个百分点）；一旦某段失败，该 run 平均 85.1% 的剩余段也失败。而对照组因素小得多：上下文压缩落差约 5–6 个百分点、累计规格长度落差 6.4 个百分点——继承缺陷是主导因素，不是长上下文也不是规格膨胀。回归路线被证伪为主因：全段 F2P 过后链级 F2P 反败的「内链回归」仅 7.3%，链级 F2P 过后 P2P 失败的「纯回归」仅 3.3%——失败主因是继承而非破坏。任务长度效应同样陡峭：两段任务 chain gate 通过率 44.4%，五段及以上仅 1.5%（仅两个 run 通过、均属 Grok 4.7）——链长每加一段，失败概率复利叠加。构造质量的间接验证也藏在消融里：agent 后续段改动文件中 52.8–57.7% 与自己早段重叠，与参考实现的 54.3% 几乎一致，说明 agent 确实在「自己的代码上继续写」而非绕开早段重写——任务设定的依赖性被真实遵守了，继承缺陷的高占比因此可信。

5.3 机制归因

PROBE：分布错位而非幻觉。低精确率（~7%）的发现是不是假 bug？两级 LLM 评审团（须给出真实输入上的 PoC 证明）确认：匹配参考集的发现 96% 有效，未匹配的也有 84% 有效（人工盲评与评审团一致率 93%，κ=0.77）。也就是说 agent 报的大多是真 bug，只是维护者不修。错位在哪？33 类 bug 类型分布对比：agent 过度报告局部正确性错误——错误算术/比较占 agent 发现的 18.5% vs 维护者修复的 9.9%（差距 +8.6pp，比率 1.86），退化值处理 +4.8pp、正则模式 +2.8pp；维护者更多修复公共 API 面上的输入处理不完整——支持输入变体缺分支占 18.0% vs agent 7.7%（−10.3pp，比率仅 0.43），分发/查找表缺条目比率 0.14、公共类型声明错误 0.24。触发条件分层更直观：agent 发现 83.9% 只需特定输入即可触发，维护者修复的 bug 更多需要特定环境（10.8% vs 4.7%）或人工检视输出（3.8% vs 0.7%）。同类型内部同样错位：GPT-5.6 Luna 多次运行之间对同类型 bug 的重叠是对人类参考集的 6.3 倍（中位数）——agent 的一致性远高于 agent-人类一致性。跨模型条件分析补上最后一块拼图：某参考 bug 被 9 次 Luna 运行中越多地发现，其他模型发现它的条件概率从 5%（零次运行发现）单调升到 87%（9 次全发现），远高于同类内随机采样的 12–17%——bug 存在一个与模型无关的「可发现性谱系」，agent 群体采样的是这个谱系，而人类维护者采样的是另一个由使用行为驱动的谱系。机制解释：维护者通过运行软件、使用公共 API 发现「描述与实现不符」的 bug，agent 主要静态检查代码发现「逻辑微妙错误」——两种发现方式采样自不同的 bug 分布。

InfraDev：失败模式的层级结构。1,754 个失败用例归为三类（按从基础到进阶排序）：结构错误占提交的 48%（代码与周围程序不匹配：无法执行/破坏 API 占 46%、张量形状/布局/dtype 22%、状态/生命周期 33%）；数值错误占 24%，且全部是算法错误、无一例纯精度损失（如某补丁算出 indexer loss 19.95 而正确值是 0.0——与人类基础设施工程师「算法易、精度难」的经验正好相反）；行为错误占 29%，其中 67% 是条件特定的——CUDA-graph 任务上 60% 的提交有此类错误（其他任务仅 15%），因为 agent 为 eager 模式写代码、把 CUDA graph 当开关，忽略了图回放不会重跑周围 Python 代码。agent 自测的盲区被量化：94 个有轨迹的 run 中 agent 确实写自测（5,532 条断言），但功能断言占 56%、结构 28%，资源类（内存/时间/流量）不足 2%；11 个死于资源检查的 run 只有 1 个写过资源断言。失败模式在模型间的共性同样有信息量：三分之二的错误为大多数模型共享——说明这些失败反映的是任务的结构性难点而非个别模型的偶然失误，改进需要的是普遍性的方法而非单家模型的补丁。失败分析反哺改进：把「检查每个调用方与每份状态、新计算对照朴素参考、测资源与 CUDA-graph 行为」三原则编码为不含任何任务答案的 skill，GPT-5.6 Sol 在 Megatron-LM 上解决率 42.1%→52.6%（+10.5pp）——证明基准的诊断价值可以直接转化为能力提升，且提升恰好出现在失败模式最集中的 Megatron-LM 训练任务上，这个「诊断-改进」的闭环是 InfraDev 区别于纯排行榜工作的最大亮点。

FeatureArc：错误察觉是瓶颈而非修复。失败后续段中 agent 对早期错误「从未察觉」占 94.9%（各 agent 90.2–99.0%）；在确实察觉的 50 段中修好 34 段——一旦发现，修复多数成功，瓶颈在检测而非修复。自测信号系统性失真：73.8% 的段以绿自测收尾，但绿自测只有 52.7% 通过隐藏 F2P（全段基线 50.4%，几乎无增量信息）；失败段之后的绿自测更跌到 24.5%，假绿占比从 28.7% 升至 75.5%。红自测则被习惯性驳回：367 个红自测段中 87.5% 被 agent 归因为「无关/先前就有」，其中只有 7.2% 先在起始代码上跑过同一测试验证基线。即使覆盖全部验收准则的自测也只有 54.9% 过 F2P，45% 的失败中 62% 源于未被察觉的前段失败——准则覆盖与断言期望值的正确性是两回事。接口契约的缺失同样可测：F2P 失败段中 18.1% 因隐藏套件无法编译，其中 61.4% 是接口不匹配（缺符号/错误类型/重复声明），缺失名目的 44.1% 在本段规格、30.5% 在早段规格中其实写明了。

5.4 跨论文数据交叉解读

成本结构的横向对比。三篇论文的计价口径不同但可粗对齐：PROBE 单模型跑完 20 仓库一轮约 $15–1,185（取决于模型与推理档位），单条发现成本约 $0.01–0.14；InfraDev 单任务单模型 $1.89–17.98 外加数百 GPU 时的硬件成本；FeatureArc 单段 4 小时预算、整任务最多 40 小时。可以看出任务单元越接近真实工程，单位任务成本越高出数个数量级——这也是三篇都投入大量篇幅做环境复用（InfraDev 共享卷省 52–57% 存储）、任务治理（FeatureArc 三步筛选从 100 候选保 73）的原因：真实工程级基准的可扩展性本身就是研究问题。PROBE 的匹配与验证流水线同样有可复用性设计：六步构建流水线不需要任何人工 bug 标注，可套用到任何有 commit 历史的仓库——这是其声称「适用于任何仓库」并开放为基准资源的底气。

仓库/语言维度的方差。PROBE 的分仓库数据揭示了容易被汇总均值掩盖的方差：召回率从 sqlglot 的约 3% 到 liquidjs/jsonschema 的 40%+，TypeScript 汇总召回 25.4% 显著高于 Python 10.8% 与 JavaScript 12.0%；精确率从 jose 的 0.6% 到 pypdf 的 22.9%。各配置对仓库的排名高度一致（Kendall W=0.75–0.92），说明难度是仓库的稳定属性而非模型偏好——这对基准使用者的启示是：横向比较模型必须固定仓库子集，混用子集的比较毫无意义。FeatureArc 的语言分布（Python 21/Go 20/TS 18/Rust 14）与七个应用域的分层则是刻意为之的方差控制设计。

重复运行与集成。PROBE 对 Luna（10 次）与 Muse Spark（5 次）的重复实验给出两个可用结论：单配置运行间方差很小（召回标准差 0.5–0.7pp），但两次运行的平均发现重叠仅 57–63%——稳定的是分数，不稳定的是具体发现集合。用「至少 n 次运行中重复报告」的阈值切分可以在召回-精确率前沿上移动：Muse Spark 全部运行的并集召回 26.7%、Luna 全部运行的交集精确率 10.5%，均超过任何单次运行。stable-beta 过程建模（拟合折扣参数 σ≈0.26–0.29）进一步证明发现集呈「稳定核心 + 无限稀有尾」结构——报告概率更高的发现更可能匹配人类，这与直觉一致却首次被形式化。附带的理论推论值得记录：由于仓库的真实 bug 宇宙有限而稳定-beta 过程的发现流无界（期望随运行数按 r^σ 增长），无限次运行的累计发现中假阳性比例必然趋于一——多轮集成换取召回的策略存在数学上不可避免的精度代价，n-of-m 阈值是在这对矛盾上的实用 Pareto 滑块。

恢复与救援的稀缺性。FeatureArc 中 525 个含失败段的 run 只有 14 个（2.7%）最终通过 chain gate；InfraDev 的恢复机制只防 agent 意外早停；PROBE 的多遍结构则用并行分区绕开了序列依赖。三个设计对「失败恢复」的态度差异本身就是一个信号：开放式发现（PROBE）里失败可以并行稀释，序列演化（FeatureArc）里失败会复利放大——工作流的结构决定了错误的半衰期。

5.5 机制归因（续）：三篇的失败机理对照表

对照表暴露出一个有趣的互补性：PROBE 的失败多数是「良性的」（agent 没找到维护者会修的 bug，但找到的也真）；InfraDev 的失败集中在「结构性贴合」（代码在局部是对的但装不进周围程序）；FeatureArc 的失败则是「时间性的」（此刻的正确被上一刻的错误拖垮）。三种机理对应三种改进路径：PROBE 需要行为化审计（跑起来、用公共 API），InfraDev 需要跨模块契约检查与资源验证，FeatureArc 需要周期性回归早段行为——最后一点恰好是 InfraDev 的 P2P 思想向时间维度的推广。

为什么 agent 察觉不到自己的错误。FeatureArc 的轨迹标注把这一点拆得很细：失败段之后 agent 的工具调用中位数仅增加 4–18%，测试类调用占比几乎不变（Opus 5.5：15.3% vs 15.0%）——agent 没有因为前面失败而增加验证投入，因为按照 L4 协议它根本不知道失败了。但更深层的问题是：即便主动增加自测，绿信号的预测力也只有 52.7%——问题不在测试数量而在断言质量：agent 倾向于断言「我实现的逻辑」而非「规格要求的行为」，两者在 54.4% 的失败案例中出现「逻辑正确但读错规格」的错位。这与 PROBE 的「agent 从代码出发而非从使用出发」是同一个根因的两面：验证视角与需求视角的系统性错位。

规格核查实验进一步把责任摊开：在 60 个「全准则覆盖 + 绿自测 + F2P 仍败」的段里，第一个失败断言的依据 34 个明确写在当前或早段规格里、12 个可由规格推出、14 个来自起始仓库——几乎全部是「本可核对而未核对」的期望，而非规格未覆盖的隐藏要求。换言之，agent 的自测输在执行而非信息：规格就在手边，断言却凭实现反推。这为改进指出了一个非常具体的杠杆——强制 agent 在写断言前先从规格逐条摘录期望值（而非从自己的实现归纳），就切断了「实现-断言循环论证」这条最短的失败路径。

InfraDev 数值错误的反直觉性值得单独强调。人类基础设施工程师的经验是「算法容易对、精度难以对齐」，而 agent 的 24 个数值错误提交全部是算法错、零个纯精度错。可能的解释：agent 倾向于把数值计算当作可「合理近似」的对象（训练数据中大量伪代码与示意实现），而分布式训练中梯度按 rank 求和还是求平均这类细节在自然语言描述里往往被省略。这提示对基础设施代码的训练语料而言，「数值语义的精确性」比「数学公式的复杂性」更是短板——与人类短板恰好互补，也是人机协作分工的一个具体依据。

5.6 数据质量与标签可信度

读实验数字之前必须先看「标签是怎么验证的」，三篇在这一点上的投入都超出常规基准。PROBE 的匹配器（评分的地基）在 67 个专家验证匹配上五次运行平均精确率 98.8% / 召回 97.6%，且全部被规则过滤剔除的配对在独立实验中也被 LLM 判官拒绝——两层之间没有漏网；评审团的有效性判定与作者盲评一致率 93%（κ=0.77），分歧集中在「是否算可修缺陷」的边缘案例。InfraDev 的探针验收是执行级的：金补丁三连过 + 三类错误补丁必拒，全部在真实 GPU 上跑，不依赖任何人工标注——其可信度来自对抗构造而非标注一致性。FeatureArc 的三模型标注 + 人工盲审给出 Fleiss κ 0.80–0.94（六个标签全部超过 0.8 的 substantial 区间），关键的继承性标签盲审一致率 100%（90/90），先前察觉标签 93.3%。三套验证体系的共同特点是「用第三层手段背书第二层信号」：匹配器靠专家标注、评审团靠人类盲评；探针靠对抗执行；轨迹标签靠多模型投票加人类抽样。这套层层背书的成本不低（PROBE 仅验证花费约 $772 + 专家工时），但它正是三篇结论能承载「单请求分数高估 2 倍」这类强论断的底气所在——在一个人人都在发基准的领域，验证深度是区分「又一个榜单」与「可信测量」的分水岭。

从三篇的结果反推编码 Agent 领域的规律，可以提炼出六条：

规律一：覆盖是第一瓶颈，能力是第二瓶颈。PROBE 中 Vanilla 单会话召回不足 1%，同样的模型换多遍 harness 升到 7.6–20.8%——二十倍的差距来自任务分解而非模型更换。FeatureArc 中 36.2% 的 run 首段就失败、20.7% 在第一扩展段失败，一半以上的失败发生在最早两段。当任务从单请求变成真实工作流，先败在「走得完走不完」，才轮到「做得对不对」。

规律二：单请求分数是整功能能力的上界估计，且系统性高估约 2 倍。FeatureArc 给出最干净的量化：62.7% → 28.5%（2.2 倍），每个 agent 无一例外损失 26–38pp；InfraDev 的对应数字是官方测试 58.3% → 加探针 38.9%（1.5 倍），外加原始 prompt 下解决率归零；PROBE 对应的是「84% 的发现是真 bug，但只有 7% 与维护者修复对齐」。三个口径不同、方向一致：局部信号 → 全局能力的换算系数大约是 0.4–0.5。

规律三：自验证信号在无外部反馈时趋于失真。FeatureArc 的绿自测对隐藏 F2P 的预测力几乎为零（52.7% vs 基线 50.4%），红自测 87.5% 被无基线验证地驳回；InfraDev 中 agent 自测断言不足 2% 检查资源；PROBE 中 agent 发现与维护者修复分布错位。三者共同指向：agent 的内部一致性不能替代外部基准，且失败后的自检信号质量进一步恶化（假绿率 28.7%→75.5%）——错误会腐蚀后续的验证判断本身。

规律四：错误的生命周期比错误的发生更关键。FeatureArc 的机理链：早期错误 94.9% 无察觉 → 后续段以错误依赖为基（22.6% vs 70.2%）→ 72.9% 的失败后续段含继承缺陷 → 段败后 85.1% 的剩余段连锁失败，而恢复率仅 2.7%。InfraDev 的对应物是状态/生命周期错误常逃过官方测试（35 个状态错误提交中 15 个只有隐藏探针能抓到）。在持续工作流中，一个未被发现的中等错误比一个被发现的大错误的破坏力更大。

规律五：评分体系的可靠性是基准的第一性问题。InfraDev 证明官方测试双向不可靠（32% 假通过 + 原始 prompt 下全员归零）；PROBE 用「维护者修复行为」这一自然锚绕开未知全集，并诚实量化了参考集不完整带来的精确率天花板（26–47%）；FeatureArc 用配对参考态把「新行为失败」与「旧行为破坏」分离。三者共同的方法论是：先证明你的尺子准，再量东西——而证明尺子准的办法是对抗（InfraDev 的对抗补丁）、外推（PROBE 的对数正态尾部）与配对对照（FeatureArc 的 S0..Sn）。

规律六：失败模式的诊断价值可以被闭环兑现。InfraDev 把失败分析编码为 skill 拿到 +10.5pp；PROBE 的类型分布错位直接指出改进方向（像用户一样运行软件、测公共 API 面）；FeatureArc 给腾讯混元团队定位到具体短板（驳回失败解释时不跑基线验证：46 段中 44 段归因于先前已有，只有 5 段真去验证过）。基准不只是排行榜，失败taxonomy 是可执行的改进路线图。

规律七：便宜模型在开放式任务上的性价比反转是结构性的。PROBE 的成本-性能曲线给出三个便宜模型（DeepSeek V4.1 Flash、GLM 5.3 Flash、GPT-5.6 Luna xhigh）以不到五分之一的成本超过 GPT-5.6 Sol medium 的 F1；FeatureArc 的中段集团（Doubao、Kimi、DeepSeek 等）首段都能过六成；InfraDev 中 DeepSeek V4 Pro 以 $1.89/任务的成本拿到 30.6% 解决率（GPT-5.6 Sol 花 $17.98 拿到同样的 30.6%）。当任务从「单点精确推理」变成「覆盖 + 流程 + 自查」的组合，前沿模型的精确推理优势被稀释，而成本差距被多轮执行放大——在开放式与长程任务上，「够用的模型 + 好的协议」是比「最强模型」更优的工程解。这条规律对 agent 创业公司的选型含义直接：不要按单请求 benchmark 选模型，按你的任务结构选。

三个基准的 ground truth 构造方法论对比。三篇论文各自面对一种特定的「标准答案偏差」，并各自发明了一种锚定术。PROBE 面对「静态 bug 集不可知」——任何时点的 bug 清单都不完整（维护者还在继续修），它用「维护者未来 18 个月的实际修复行为」作锚：参考集不是专家认定的 bug，而是被真实工程流程筛选过的 bug，偏差从「全集未知」转化为「窗口截断」，后者可以用对数正态尾部外推定量补偿（26–47% 天花板）。InfraDev 面对「官方测试既放错又冤枉对」的双向偏差，它不用未来行为而用「对抗构造的当下列决」：金补丁必过 + 空壳/对抗补丁必拒的三条件合取，把「正确」从测试作者的主观意图变成可执行验证的不变式——偏差从「测试不完备」转化为「对抗覆盖度」，而对抗覆盖度可以靠持续添加对抗补丁逼近完备。FeatureArc 面对「单快照无法承载过程正确性」，它用「历史演化链的逐段重放」构造配对参考态 S0..Sn：每段的 F2P/P2P 都在真实前后状态上验证，偏差从「任务与历史脱节」转化为「链挖掘的忠实度」，后者用 LLM 评审 + 人工审查 + 后续段 54.3% 文件重叠的构造性证据兜底。三种锚定术的共性是：都拒绝「专家拍脑袋定答案」，都把答案锚定在某种真实证据（未来行为 / 对抗执行 / 历史重放）上，并且都诚实地量化了锚定残余的偏差上界——这构成真实工程评测时代 ground truth 方法论的三种范式。

作者方法论的反推。三组作者共享三个手法：其一，用真实历史锚定 ground truth——PROBE 用维护者修复、InfraDev 用金补丁、FeatureArc 用历史演化链，全部拒绝人工造任务；其二，用对抗性构造验证评测自身——对抗补丁、空壳补丁、多模型轨迹筛查、盲审 κ 值报告，把「基准自己有没有 bug」当成一等公民问题；其三，诚实的上限分析——PROBE 明说精确率天花板 26–47%、召回不受窗口影响可外推，InfraDev 明说 GPT-5.6 Sol 测量期可能服务降级、vLLM 任务全员 10% 说明该子类近乎不可区分，FeatureArc 明说跨 agent 比较耦合了模型与外壳的贡献。

再补一条容易被忽略的方法论细节：三篇都对「评测协议本身的泄漏面」做了防御性设计。PROBE 从 Docker 镜像里删除全部 git 历史（防止 agent 读到快照之后的修复）、禁用网络与 web 搜索工具、并用修复时间排名的置换检验排查数据污染（Holm 校正后全部 p≥0.20，仅有 cut-off 落在窗口内的模型才可被此检验覆盖）；InfraDev 在评分时替换整个测试目录防止 agent 篡改测试、prompt 中显式禁止查询原始 PR、缺失/空补丁记 0 分而非剔除（防止「放弃策略」得利）；FeatureArc 的隐藏评分在 agent 工作区之外独立运行、发布前清除 agent 生成的文档并还原泄露后续实现的文档。这些细节共同构成「基准的免疫系统」——在 LLM 时代，任何可被 agent 触碰的评分通路都必须假设被利用。

还有一条关于负结果的价值：FeatureArc 的 Table I 把 SWE-STEPS、EvoCode-Bench 等近邻基准逐项对比后，明确指出自己早先「把单个功能请求切段」的尝试产生了弱依赖阶段——这个失败的内部尝试被写进论文作为设计动机，比任何 related work 都更有说服力。同样，InfraDev 承认「无模型在解决率、时间、成本三项全胜」、PROBE 承认「其他 harness 可能给出不同结果」。敢于报告约束条件的论文，其正面结论才可信。

七、通用灵感

最后提炼跨领域可迁移的思维模式，四条：

灵感一：用行为锚代替完备枚举来定义开放任务的 ground truth。任何「全集未知」的开放评测（安全威胁发现、科研想法评估、市场机会识别）都面临 PROBE 同款难题。解法是把「权威会在实践中处理什么」当作参考集：维护者修什么 bug、评审接收什么论文、用户为什么产品付费。配套三件套：锚定回流（把后来的修复映射回首测时刻）、不完备性的定量上限（条件似然外推天花板 26–47%）、以及「未匹配 ≠ 无效」的独立验证（84% 未匹配发现仍真）。迁移到内容审核：判断 AI 生成报告的质量，可以锚定「专家实际会修改什么」，同时独立验证未匹配项的价值而非直接判负。

灵感二：评分器与被评对象必须对抗地共同进化。InfraDev 的闭环——先造能骗过现有评分的错误答案（对抗补丁），再为骗过点补测试（探针），同时保证任务描述陈述所有被测要求（prompt 同步）——是任何「AI 产出 + 自动评分」系统的通用架构。适用场景远超编码：作文自动评分应先构造「词汇华丽但论证错误」的对抗作文检验评分器；代码迁移工具的验收测试应先写「接口齐全但函数全空」的空壳实现确认测试不只查存在性。关键细节是双向验收的三条件合取（对的必过、错的必拒、对抗样本确实骗得过旧评分），以及「测试强制的每条要求必须出现在任务描述里」这条耦合律——漏掉任何一半，评分器就往虚高或虚低两个方向失真。

灵感三：把「察觉失败」从能力评测中拆出来单独测量。FeatureArc 的 L4 设计精髓在于剥离所有外部反馈光线，让「发现自己是错的」成为独立可测变量——结果是察觉率仅 5.1%，且察觉后修复率 68% 相当高。这个拆分对一切长程自主系统都有启发：自动驾驶的接管请求质量、自动化交易的事后自检、多 agent 系统中协调者的声明核验，都应区分「做对的能力」与「知道自己错了的能力」。配套测量设计同样可迁移：条件切分（前段成败对后段的因果对比，47.6pp 落差 vs 环境因素 5–6pp）、信号校准分析（绿信号的条件命中率 52.7% vs 24.5%，红信号的驳回验证率 7.2%）。管理上的对应物：让员工自查流程错误时，先测「能不能发现」再测「能不能改正」，两者往往差一个数量级。

灵感四：性价比反转与瓶颈迁移决定投入方向。PROBE 中便宜模型以 1/5 成本达到更高 F1、推理努力只增加数量不增加质量（精确率恒定）；InfraDev 中 HY4 preview 以 39% 的成本少解一个任务、无模型在解决率/时间/成本三项全胜；FeatureArc 中排名前二（Opus 5.5、GPT-6 Astra）与其后梯队的整功能差距远大于首段差距。三组数据共同指向：能力接近时，harness/协议/skill 的工程投入（PROBE 的多遍分区 +10 倍召回、InfraDev 的 skill +10.5pp）回报远高于换更强模型。对任何 AI 应用团队的启示：先把任务分解、上下文供给、验证反馈的工程设计做到位，模型档位是最后一步——瓶颈通常不在你换不起模型，而在你还没给模型一个它能走完的任务结构。

灵感五：把「时间维度的回归」设计进一切持续系统。FeatureArc 最被低估的贡献可能是 chain gate 与 stage gate 的分离：273 个通过末段门禁的 run 中 25.3% 在整功能检验时失败——逐段通过不等于整体成立，因为段的正确性是条件于当时状态的，而状态在漂移。这个现象在任何持续交付场景都有对应物：微服务逐个迭代部署后链路整体行为的退化、模型逐轮微调后在早期任务上的遗忘、组织逐季度优化后端到端流程的劣化。通用设计模式是维护「链级测试」——一组只在完整交付物上运行、覆盖端到端行为不变量的检查，与逐段验收正交。FeatureArc 的数据还给出了配比直觉：纯回归虽少见（3.3%），但内链回归（全段过而整体败）有 7.3%，两者叠加意味着约一成的前缀完美执行会在终点翻车——链级检查不是锦上添花而是必需品。

灵感六：协作分工按短板互补设计。三篇论文合力画出了一张人机短板对照表：人类维护者擅长发现「需要运行软件、使用公共 API、检视输出才能暴露」的 bug（PROBE：环境/交互类占维护者修复的 21%+），agent 擅长静态扫出局部逻辑错误（算术/比较类 18.5% vs 9.9%）；人类基础设施工程师苦于数值精度对齐，agent 却零纯精度错误、全栽在算法语义上（InfraDev）；人类工程师在代码评审中承担「察觉异常」的角色（FeatureArc 的 L1–L3 本质是把察觉外包给人类），而 agent 察觉自身错误率仅 5.1%。这张表对任何规划人机协作流程的人都有直接用处：把「运行时行为验证」「跨模块契约把关」「阶段性外部审计」留给人类或专用工具，把「大规模静态扫描」「格式化实现」「初版生成」交给 agent——不是按任务难度分工，而是按错误类型分布分工。

尾注

三篇论文在 2026 年 10 月下旬同期出现并非偶然：SWE-bench 范式的分数在 2026 年逼近饱和，「单请求 + PR 自带测试」的评测红利耗尽，社区被迫向真实工程工作流要下一批信号。PROBE 补上发现侧、InfraDev 补上实现侧的评分可靠性、FeatureArc 补上演化侧的自主性，三者合起来给出的一致判断是：当前编码 Agent 的真实工程能力约为其单请求分数的一半，缺口主要在覆盖结构、评分对抗性与自我察觉三处——而这三处恰好都是工程与方法论问题，不是单纯的模型能力问题。这或许是这组论文最乐观的注脚：下一个数量级的提升路径，写在基准的方法论里，而不只在参数规模里。

对后续研究的具体指向，三篇各自留下了清晰的接续点。PROBE 明确提出「像用户一样运行软件的方法可能找到更接近维护者修复的 bug」——行为化审计（动态执行 + 公共 API 面覆盖）是对抗分布错位的自然下一步，其 stable-beta 发现过程模型也为「多少次运行才够」给出了统计框架。InfraDev 承认两个扩展瓶颈：多 GPU 评级的成本（提出用模拟/仿真降低）与 PR 筛选仍靠领域专家（需要自动化筛选方法），其探针-对抗-循环的构造流程理论上可迁移到任何有金补丁的场景。FeatureArc 的 L1–L4 阶梯暗示了一整套尚待填充的评测矩阵：不同反馈级别 × 不同功能域 × 不同链长的系统测量，以及「察觉率」作为独立优化目标的新型训练信号——教会 agent 在没有外部反馈时怀疑自己，可能是继工具使用与长上下文之后的下一个能力分水岭。

最后值得提醒读者的是三篇的适用边界：PROBE 只覆盖三种内存安全语言（排除内存安全 bug）且仓库 ≤200k 行；InfraDev 的 36 个任务偏小、vLLM 子类近乎 floor 效应（全员 10%）使其区分度有限；FeatureArc 的 73 任务在 10 个 agent 的比较上已见置信区间重叠（如 Hunyuan 4 Preview 的 Gate 34.2% 区间宽达 23.3%–45.2%）。结论的方向可靠，具体数字会随模型迭代快速过期——但正如三篇论文共同示范的：把验证体系本身做扎实，数字过期之后方法论仍在。