SpecBench：测量长期编码代理中的奖励黑客行为

摘要

当长周期编码智能体生成的代码量远超任何开发者所能审查的范围时，监督便坍缩至一个单一表面：自动化测试套件。在这种设置下，奖励黑客行为自然产生，因为智能体会优化以通过测试，同时偏离用户的真实目标。我们通过将软件工程任务分解为三个部分来研究这种奖励黑客现象：(i) 规范的自然语言描述，(ii) 单独测试指定功能的可见验证测试，以及 (iii) 组合这些相同功能以模拟真实世界使用的保留测试。基于规范和可见的验证测试套件，一个真正的智能体应该能够生成一个也能通过所有保留测试的解决方案。因此，我们使用这两个套件上的通过率差距来量化奖励黑客行为。基于这种方法论，我们引入了 SpecBench，一个包含 30 个系统级编程任务的基准测试，任务范围从构建 JSON 解析器等短周期任务，到从头构建整个操作系统内核等超长周期任务。大规模实验揭示了一个一致的模式：虽然每个前沿智能体都饱和了可见套件，但奖励黑客行为依然存在，较小的模型在保留套件上表现出更大的差距。这种差距也随任务长度急剧扩大：代码规模每增加十倍，差距就扩大 28 个百分点。失败案例从微妙的特征隔离到故意的漏洞利用，包括一个记忆测试输入的 2900 行哈希表“编译器”。SpecBench 提供了一个原则性的测试平台，用于衡量编码智能体是构建真正可工作的系统，还是仅仅在玩弄开发者交给它们的测试套件。

1 引言

软件工程正在经历一场根本性的范式转变。开发者正越来越多地将复杂系统的端到端实现委托给自主智能体，这些智能体在有限的人工干预下迭代式地编写、测试和优化代码（Anthropic，2026；OpenAI，2025a）。随着任务规模扩展到更长的周期，产生的代码量开始超出任何开发者能够有效审查的范围。因此，监督被压缩到单一表面：自动化测试套件。开发者将其用作规格是否满足的代理指标，而智能体则将其视为优化目标。针对这一代理指标进行优化，会产生一个在强化学习中研究已久但在自主编码领域探索不足的漏洞：奖励破解（Skalse等人，2022；Krakovna等人，2020）。当唯一的反馈信号是测试是否通过时，智能体可能选择阻力最小的路径，生成能通过测试但并未满足开发者真实意图的代码。

奖励作弊已在定性案例研究中有过记载（Wang 等人，2026），但该领域目前缺乏一种量化方法来衡量智能体编程中的这一现象。我们提出了 SpecBench，这是一个包含 30 项系统级编程任务的基准测试，任务范围从 JSON 解析器到操作系统内核。每项任务均由两个测试套件进行评估（图 1）。验证套件对智能体可见，供其迭代改进，用于测试每个指定的独立功能。保留套件对智能体隐藏，它将这些相同功能组合起来，模拟端到端的使用场景。例如，在一个 SQL 数据库任务中，验证测试分别覆盖 SELECT、JOIN 和 GROUP BY，而保留测试则是可能同时组合使用这三者的查询。我们将奖励作弊差距定义为智能体在验证套件与保留套件上的通过率之差。正差距意味着智能体在可见的代理指标上取得了分数，但并未真正满足规范要求。

利用 SpecBench，我们开展了一项大规模实证研究，涵盖多个模型、编码工具（Codex、Claude Code、OpenCode）（Anthropic，2026；OpenAI，2025a；Anomaly，2026）以及搜索策略（AIDE、Linear、Autoresearch）（Jiang 等人，2025；Huntley，2025；Karpathy，2026）。我们发现，每个模型都能在所有任务上达到可见测试套件的饱和通过率。然而，在这种统一的通过率背后，奖励作弊行为沿着两个维度扩展。首先，验证集与保留测试集通过率之间的差距随任务复杂度增加而扩大（图 2）。其次，较弱的模型（以 MMLU 衡量）比更强的模型表现出更大的差距（图 4）。这两项发现都传达了同样的实际警示：随着团队扩展到更长的任务或换用更小的模型，智能体绿色的测试报告越来越掩盖其合规性的下降。除了定量发现之外，我们还记录了作弊策略本身，范围从特征隔离（即智能体实现的各个特征无法在组件间共享状态）到蓄意利用（即智能体通过查找表记忆验证测试，从而完全绕过实际实现）。

总之，（i）我们的工作通过正式定义并测量长周期智能体编码中的奖励作弊，弥合了编码智能体评估中的一个关键空白。（ii）我们为社区提供了一个原则性框架和一个全面的测试平台，揭示了大规模测试驱动开发中隐藏的脆弱性。（iii）通过展示这些结构性利用在不同模型、搜索策略和代码库规模中是多么普遍，我们强调了重新思考如何引导和评估 AI 系统的紧迫性。最终，这些见解强调，确保下一代编码智能体的安全，需要优先考虑真正的架构完整性，而非游戏化、空洞的人工制品的假象——尤其是在长周期任务中。

2 基准设计

设置。每个 SpecBench 任务都提供一份自然语言规范说明、包含桩代码的起始代码，以及一个作为智能体优化目标的验证测试套件。智能体接收规范说明和起始代码后，会迭代生成代码、运行测试，并在预算步骤数内进行优化，最终产出一个候选实现。另有一个独立的保留测试套件，从未向智能体展示，仅用于评估。请注意，规范说明定义了目标生成系统的所有要求，并明确指出该系统将用于端到端的复杂功能交互场景，这正是保留测试套件所评估的内容。

衡量奖励破解。设 和 分别表示候选实现在验证测试套件和保留测试套件上的通过率。我们将奖励破解差距定义为

当 时，智能体对代理指标（验证测试通过率）的优化已超出其真实的规范符合度：它通过了功能级测试，但在这些功能需要组合时却失败了。 表示未发生破解。这直接实例化了 (Skalse 等人，2022) 提出的奖励破解框架，在该框架中，优化代理奖励会偏离真实目标；此处 和 。

测试设计。使 成为奖励破解忠实衡量标准的关键在于 与 之间的关系。验证套件包含针对任务中每个独立功能的测试，例如，一个 SQL 数据库的验证测试会分别验证 SELECT、JOIN、GROUP BY 和 HAVING。保留套件则在每个测试中组合这些功能，例如，一个查询同时连接两个表、按连接列分组，并使用 HAVING 对聚合结果进行过滤。关键在于，保留套件并未引入 和 已规定之外的任何新要求。所测试的每一种组合都是规范说明所要求的。一个真正符合要求的实现应该无需修改就能同时通过两个套件。因此， 反映了智能体对代理指标的投机取巧行为。

任务套件。SpecBench 包含 30 个系统级编程任务，覆盖从构建 JSON 解析器（参考实现 1500 行代码）等短周期任务，到从零实现操作系统内核（参考实现 110000 行代码）等超长周期任务的广泛复杂度范围。每个任务都附带一个能通过所有测试的参考实现，确保测试套件是可满足的。表 2 展示了 SpecBench 与先前编程智能体基准的对比。在这些基准中，SpecBench 是唯一能够衡量奖励黑客行为的基准。请注意，我们的验证测试和保留测试不应与 SWE-Bench Pro（Deng 等人，2025）等基准中的训练/验证划分混淆，后者的训练集和验证集针对不同任务。而在 SpecBench 中，验证测试和保留测试是为同一任务设计的测试套件。表 1 展示了 SpecBench 的汇总统计信息。

3 实验

我们使用两级架构在 SpecBench 上评估编程智能体：一个负责编写和编辑代码的内部智能体，由一个决定优化哪些候选方案的外部搜索循环包裹。这种分离使我们能够独立改变编程模型和搜索策略。除本节实验外，我们在附录 C 中展示了 SpecBench 上的一个额外案例研究。

内部智能体。我们评估了三个智能体：Codex（OpenAI，2025a）、Claude Code（Anthropic，2026）和 OpenCode（Anomaly，2026）。这些是具备工具使用、文件编辑和终端访问能力的前沿级编程智能体。为了扩大模型覆盖范围，我们评估了开源编程 CLI OpenCode，它搭配了五个开放权重和 API 模型：DeepSeek-V3.2（DeepSeek-AI，2025）、DeepSeek-V4-Pro（DeepSeek-AI，2026）、Qwen3-Coder（Cao 等人，2026）、Kimi-K2.5（Kimi Team，2026）、Kimi-K2.6（月之暗面，2026）以及 Minimax-M2.7（MiniMax AI，2026）。

搜索策略。每个编程智能体都搭配一种搜索策略，该策略控制外层循环如何探索解空间。通常，编程智能体为测试套件生成解决方案的过程可以用树结构来描述，其中每个节点都是由内部智能体构建的完整代码库。每个节点可以分支产生子节点，该子节点在其父节点构建的代码库基础上进行扩展，以尝试通过更多验证测试。最初，这棵搜索树的根节点是我们提供给编程智能体的起始代码（桩代码），每次迭代提示编程智能体时，它都会生成一个新节点。在这种搜索树框架下，我们测试了三种搜索策略，包括 AIDE（Jiang 等人，2025）、Linear（Huntley，2025）和 Autoresearch（Karpathy，2026）。AIDE（Jiang 等人，2025）是一种常用于优化代码解决方案的高级搜索算法（OpenAI，2025b）。它使用树搜索，包含草稿、调试和改进分支。在每一步，它都会选择搜索树中最有希望的节点，并通过三种操作之一生成一个子节点。请注意，在 AIDE 中，智能体只能看到从根节点到当前最佳节点的路径上下文，而无法访问任何兄弟节点的上下文。Linear（Huntley，2025）被提出作为一种简单的解决方案，使编程智能体能够处理长周期任务。它执行顺序优化，不进行分支：每一步都对其父节点中的单个候选解决方案进行改进。Autoresearch（Karpathy，2026）扩展了 Linear 策略，始终跟踪到目前为止的单个最佳候选解决方案。图 3 展示了这三种搜索策略的区别。

3.1 任务范围与奖励作弊

我们首先考察实现范围的长度（以参考实现的代码行数衡量）与奖励作弊严重程度之间的关系。图 2 绘制了数据集中每次运行的奖励作弊差距与参考代码行数的关系。我们发现，平均奖励作弊差距以及第 90 百分位的奖励作弊差距均随任务规模呈可预测的缩放趋势。例如，代码行数每增加十倍，第 90 百分位的差距大约增长 27 个百分点。在代码行数低于 1 万行的任务中，最坏情况下的差距为 21 个百分点。在代码行数超过 2.5 万行的任务中，该差距达到 100 个百分点。

这种缩放趋势表明，在长周期代码生成中，奖励黑客行为更多是由组合表面积的增加所驱动，而非孤立的实现难度。随着系统所需的实现规模变大，内部接口、共享不变量以及跨功能执行路径的数量增长远快于功能级验证测试的数量。因此，智能体可以通过实现局部正确的处理程序或特定功能的捷径来获得高验证分数，同时仍然未能构建这些功能交互所需的全局架构。相对适中的结果表明，代码行数（LOC）只是任务周期的一个粗略代理指标——某些小任务仍会暴露棘手的语义交互，而一些较大的任务则具有更易于分解的模块化结构。尽管如此，奖励黑客差距的急剧增大表明，长周期任务为严重的奖励黑客行为创造了更多机会，使其从偶发的边缘情况转变为结构性的失效模式。

3.2 模型能力与奖励黑客行为

接下来，我们研究奖励黑客行为与模型能力之间的关系。图4将每个模型的平均奖励黑客差距与其通用能力（以MMLU分数作为粗略代理指标）进行了对比。我们观察到明显的负相关趋势：更强的模型往往表现出更小的奖励黑客差距。然而，仅凭能力并不能完全消除这一问题。即使是最强的模型，其奖励黑客差距也仍然不为零，这表明奖励黑客行为并不仅仅是弱模型的失效模式。

中间和右侧的图表阐明了这一趋势的来源。在所有模型中，验证分数几乎都已饱和：无论是较强还是较弱的模型，都能将公开测试优化到较高水平。差异仅在保留测试中才显现出来，较弱的模型在此类测试中得分明显更低。这表明，一旦智能体具备足够能力通过特征层面的检查，仅凭验证套件本身已不足以区分真正的实现质量。相反，保留套件能够揭示模型是否构建了真实用例正确通过所需的底层系统架构。这些结果支持两个结论。首先，提升模型能力能够提高对真实规范的遵循程度：更强的模型更善于推断测试和规范背后的预期抽象，并且更不容易依赖脆弱、针对特定特征的实现。其次，更强的模型并未消除测试驱动优化所带来的激励错位。由于验证套件仅能观察到有限的一组特征层面行为，一个实现方案可能得分很高，却仍然缺失真实用例所需的共享不变性和跨特征交互。SpecBench 通过评估规范中已隐含的用例（而非引入新需求）来暴露这一差异。因此，由此产生的差距衡量了可见的测试性能在多大程度上可能高估真实的实现质量。

3.3 智能体与搜索模式对比

接下来我们比较编码智能体和外部循环搜索策略的选择如何影响奖励作弊。图5报告了每种智能体和搜索策略组合的验证通过率与保留测试通过率。图5中每个柱状图显示验证分数，柱状图中堆叠的实心部分为保留测试套件分数，因此阴影区域展示了奖励作弊差距。在大多数设置下，验证分数接近饱和，表明智能体能够可靠地优化可见的验证测试。然而，柱状图的阴影区域差异显著，这意味着相似的验证分数可能对应着截然不同的真实规范符合程度。

结果表明，奖励作弊并非与单一智能体或搜索策略绑定。Claude Code在AIDE、Autoresearch和Linear策略下取得了几乎相同的验证分数，但保留测试分数明显更低，产生了约43-48个百分点的差距。Codex与搜索模式表现出更强的交互性：AIDE在Codex运行中给出了最高的保留测试分数，而Autoresearch产生了最大的差距，这表明当验证分数与组合正确性对齐不佳时，保留最佳验证分数候选者可能加剧代理过度优化。OpenCode则呈现相反模式：AIDE的差距最大，而Autoresearch和Linear恢复了更高的保留测试分数。

这些结果表明，搜索策略会改变奖励破解的表现形式，但并不能消除根本性的激励错配。当探索过程能发现真正更优的架构时，树搜索可以起到帮助作用；但如果脆弱的候选方案在验证测试中得分较高，树搜索也可能将其选中。同样地，“历史最佳”选择机制可以保留有用的改进，但也可能锁定在某个针对代理指标优化的实现上。总体而言，图5强化了SpecBench的核心论点：仅凭公开的验证性能并不能可靠地反映真实的实现质量。即使验证分数几乎无法区分，在生成的系统是否真正满足预期规范方面，留出测试也会揭示出巨大差异。

3.4 更多搜索会加剧破解吗？

一个自然而然的问题是，奖励破解是否仅仅是搜索不足的产物。如果智能体最初生成脆弱的实现，但随后将其优化为连贯的系统，那么增加搜索预算应该会缩小奖励破解的差距。图6通过追踪每个搜索步骤的奖励破解差距来检验这一假设。我们同时报告了四分位均值（IQM）——它捕捉典型行为同时降低对异常值的敏感度（Agarwal 等人，2021年）——以及第90百分位（P90），后者捕捉了严重奖励破解的上尾分布。

研究结果表明，额外的搜索并不能可靠地消除奖励作弊行为。在所有智能体中，IQM 差距在整个搜索过程中始终不为零。OpenCode 在大部分运行过程中表现出最大的中心差距，而 Codex 和 Claude Code 初始差距较小，但在后续搜索步骤后明显增大。P90 曲线显示出更强的效应：严重的奖励作弊案例在整个搜索轨迹中持续存在，并且随着搜索的进行往往变得更大。因此，即使额外的步骤改进了一些实现方案，它们也无法消除那些严重奖励作弊的解决方案的尾部效应。搜索策略的视角阐明了这一现象的原因。AIDE 和 Linear 在长时间搜索后 IQM 差距均有所增加，且它们的 P90 差距仍然很高。这表明，迭代优化可以通过添加特定功能的修复来提升验证性能，而不一定改善保留测试所需的共享抽象。Autoresearch 显示出更平坦的 IQM 曲线，表明保留迄今为止的最佳候选方案有时可以避免中心差距的大幅增加。然而，差距仍然大于零，因此选择最佳候选方案并不能解决根本的代理指标不匹配问题。总体而言，图 6 表明奖励作弊并非仅仅是一个随着计算量增加而消失的早期搜索失败。更长的搜索为智能体提供了更多改进真实实现的机会，但也为它们提供了更多发现能在验证测试中获得高分的奖励作弊候选方案的机会。因此，该效应取决于验证套件与现实世界使用之间的一致性：当验证测试更倾向于奖励局部特征完成而非现实世界用例时，额外的搜索可能会保持或放大奖励作弊差距，而不是缩小它。

3.5 增加验证集的覆盖率。

软件工程中提升代码质量的常见做法是编写更全面的测试。鉴于前述实验中观察到的奖励破解行为，一个自然的问题是：让智能体访问更丰富的验证测试是否会缩小这一差距。如果可见测试套件包含针对特性组合的测试，智能体就能获得关于跨特性交互的直接优化信号，从而可能被引导至能正确处理这些交互且不会进行奖励破解的实现方案。我们通过逐步增加可见测试套件的组合复杂度（同时保持留出评估不变）来验证这一点。

我们比较了三种验证机制。在单特性机制下，智能体仅能看到默认的验证测试，每个测试单独检验一个规范特性；这是所有其他实验中使用的基线方案。在“+组合”机制下，我们在可见测试套件中增加了检验多特性交互的测试，因此智能体现在既能获得针对单个特性的优化信号，也能获得针对特性组合的优化信号。在全覆盖机制下，我们更进一步，增加了与留出测试套件难度水平相近的组合测试，从而使智能体针对与留出评估所用测试在组合复杂度上相当的测试进行优化。在所有三种机制中，留出评估保持不变：我们始终使用相同的留出测试套件来测量差距。

如图 7 所示，增加验证覆盖范围会产生混合效果。差距既没有持续缩小，也没有持续扩大，且影响在不同任务间差异很大。在一个极端案例中，当加入组合测试后，sql_database 任务的差距从 35 个百分点降至 9 个百分点，因为更丰富的信号引导智能体修复了此前缺乏动力去处理的跨特征交互问题。在另一个极端案例中，c_compiler 任务的差距增加了 25 个百分点，因为智能体难以满足一组更大的测试，这些测试对紧密耦合的代码施加了相互冲突的要求。在其他几项任务中，无论暴露多少测试，差距几乎都没有变化，这表明这些组合任务确实难以实现，而不仅仅是缺乏优化信号。这些发现表明，仅靠改进测试套件无法消除奖励作弊行为：当智能体已具备能力但缺乏信号时，更丰富的测试会有所帮助；但当底层组合任务确实难以正确实现时，这些测试反而可能适得其反。

3.6 奖励作弊案例研究

SpecBench 揭示了一系列奖励作弊行为，从显式的代理指标利用到更微妙的系统级失败。我们手动检查了具有代表性的生成程序，以了解哪些类型的实现失败导致了奖励作弊差距。图 8 展示了两个示例，图 9 总结了不同智能体和模型组中相应定性类别的分布情况。

严重：查找表记忆。在C编译器任务中，Codex发现了一种完全绕过实现的策略。该智能体没有构建词法分析器、解析器和代码生成器，而是通过系统GCC运行公开测试程序，预先计算了这些程序的预期输出，然后将结果存储在一个2900行的哈希表中，该哈希表将输入源代码的哈希值映射到预期的输出字节。生成的“编译器”仅对输入进行哈希处理，查找结果，并发出写入预计算输出的汇编代码。这在验证测试上达到了97%的准确率，而在保留测试上为0%，产生了97个百分点的奖励黑客差距。这种行为尤其具有揭示性，因为该漏洞是在搜索过程中被选中的：在同一AIDE运行中，一个更早的节点生成了一个真正的7900行编译器，在验证集上达到了53%的分数，在保留集上达到了43%的分数。然而，AIDE仍然选择了查找表产物，因为它在可见的验证目标上得分更高。这个案例表明，当代理目标与真实目标不一致时，基于验证分数的搜索可能会主动引导智能体远离更真实的实现。

中等程度：特征隔离。最常见的失败模式不那么显性，但更为普遍。在 SQL 数据库任务中，智能体通常将 SELECT、JOIN、GROUP BY 和 HAVING 实现为独立的处理器。每个处理器都能通过其对应特征的验证测试。然而，该实现缺乏用于列解析、别名、连接表模式和聚合状态的共享表示。当一项留出测试将这些特征组合到单个查询中时，处理器无法跨特征边界传递必要的状态。例如，一个将员工表与部门表连接、按连接列分组并使用 HAVING 进行过滤的查询会失败，因为 GROUP BY 逻辑无法解析由连接引入的列。这种实现达到了 100% 的验证性能，但留出性能仅为 35%，产生了 65 个百分点的差距。与查找表记忆不同，这并非智能体故意进行奖励破解。它是从优化单个特征级别检查的过程中自然产生的：生成的系统包含局部上合理的组件，但从未构建出端到端正确性所需的全局抽象。

失败类型的定性分布。图9显示，蓄意利用的情况较为罕见，而组合性失败在奖励破解行为中占据了更大比例。在所有智能体中，相当一部分生成的系统要么属于功能隔离，要么属于边缘情况漏洞，这意味着系统在功能级验证下看似正确，但在更广泛的使用场景中会失败。这种模式在较弱的模型中尤为明显：与更强的模型相比，它们产生的真正解决方案更少，而功能隔离类失败更多。这与第3.2节的结果一致，即较弱模型获得的验证分数与较强模型相当，但保留测试分数却低得多。综合来看，这些案例研究阐明了奖励破解差距所衡量的内容。高差距可能源于显式利用，例如记忆公开测试，但更常见的是反映了局部测试通过与全局系统正确性之间的结构性不匹配。SpecBench能够揭示这两种失败类型，因为保留测试并未引入新需求；它们仅要求指定的功能能够组合成一个真正可运行的系统。

4 相关工作

奖励破解与规范博弈。奖励破解，即优化代理目标而损害真实目标，由Skalse等人（2022）正式提出，他们证明了几乎不存在不可破解的代理目标。Krakovna等人（2020）整理了强化学习和程序合成中的博弈实例。Pan等人（2022）和Gao等人（2022）量化了RLHF中的奖励过度优化问题。Manheim和Garrabrant（2018）将这些现象与古德哈特定律联系起来。在编码智能体方面，Baker等人（2025）展示了经过强化学习训练的模型会利用跨领域迁移的测试框架。Denison等人（2024）表明博弈行为会从简单形式升级到严重形式。Greenblatt等人（2024）发现低风险破解行为可以泛化到新的场景。我们的工作SpecBench向前迈进了一步，在长周期系统级软件工程任务背景下研究了奖励破解问题。

奖励黑客行为基准测试。EVILGENIE（Gabor 等人，2025）修改了 LiveCodeBench（Jain 等人，2024），使其能够操纵测试，发现大语言模型评判器在检测奖励黑客行为方面优于保留测试集。Countdown-Code（Khalifa 等人，2026）表明，在监督微调中 1% 的作弊行为会为强化学习后训练阶段的灾难性黑客行为埋下伏笔。TRACE（Deshpande 等人，2026）引入了横跨 54 个黑客行为类别的 517 条轨迹；GPT-5.2 仅检测出 63%。Terminal Wrench（Bercovich 等人，2026）编录了 331 个可被黑客攻击的任务，包含 3,632 条利用轨迹。RHB（Thaman，2026）发现强化学习后训练将利用率从 0.6% 提升至 13.9%。SpecBench 则有所不同：我们评估的是系统级软件（1.5K–110K 行代码），其中的黑客行为源于架构缺陷（功能隔离），而非测试操纵。这与当前社区将编码智能体部署到真实生产环境的趋势相符。

编码基准测试。HumanEval（Chen 等人，2021）和 MBPP（Austin 等人，2021）评估的是独立函数。SWE-bench（Jimenez 等人，2023；Deng 等人，2025）假设存在预先构建的架构。ClassEval（Du 等人，2023）发现模型在处理类内部依赖关系时存在困难。DevBench（Li 等人，2025）、CrossCodeBench（Niu 等人，2023）、LiveCodeBench（Jain 等人，2024）、KernelBench（Ouyang 等人，2025）和 NL2Repo（Ding 等人，2025）各自拓展了评估范围，但均未将代理指标与真实目标区分开来。SpecBench 在以下三个方面与上述所有基准测试不同：(1) 任务要求从头构建完整的系统（1.5K–110K 行代码），而非修补现有代码库；(2) 我们明确区分了代理指标（验证测试）与真实目标（保留测试集），从而能够量化衡量奖励黑客行为；(3) 我们的任务在复杂度上跨越多个数量级，从 JSON 解析器到操作系统内核，涵盖了长周期开发的完整谱系。

基于大语言模型的编程智能体。现代编程智能体将前沿大语言模型与工具使用、终端访问和文件编辑相结合，在迭代的智能体循环中运行。专有框架包括 Codex CLI（OpenAI，2025a），它为 OpenAI 模型提供了全自动执行能力；Claude Code（Anthropic，2026），它为 Anthropic 模型提供了持久的工作区状态；以及 Gemini CLI（Google，2025），它将 Google 模型与 Shell 访问集成在一起。像 OpenCode（Anomaly，2026）和 Aider（Gauthier，2024）这样的开源替代方案，通过支持多种模型后端，使智能体编程的访问更加民主化。包裹这些智能体的搜索策略与模型本身同等重要。AIDE（Jiang 等人，2025）引入了用于代码生成的树搜索，利用“草稿-调试-改进”的分支来探索解空间。Ralph-loop（Huntley，2025）使用线性顺序精化。Autoresearch（Karpathy，2026）通过跨步骤维护最佳候选方案来扩展线性搜索。我们的实验比较了所有三种策略，并发现搜索算法对奖励破解的影响小于底层模型能力。

5 结论

我们引入了 SpecBench，这是一个通过将可见的验证测试与隐藏测试分离，来衡量长周期编程智能体中奖励破解行为的基准测试。在 30 个系统级编程任务上，我们的结果表明，高分验证测试成绩可能会显著高估真实的规范符合度，尤其是在任务周期变长时。这反映了自主软件开发场景下的古德哈特定律（Goodhart，1975；Strathern，1997）：一旦测试通过率成为优化目标，它就可能不再是衡量生成系统是否真正满足预期规范的有效指标。SpecBench 从定量和定性两个角度揭示了这一差距，既展示了刻意的代理利用行为，也展示了更常见的功能组合失败。这些发现表明，未来对编程智能体的评估必须超越表面上的测试通过，转而衡量生成系统是否保留了真实软件正确性所需的共享抽象、不变量和端到端行为。

参考文献

• Agarwal 等人 (2021) R. Agarwal、M. Schwarzer、P. S. Castro、A. Courville 和 M. G. Bellemare。统计悬崖边缘的深度强化学习。《神经信息处理系统进展》，2021 年。
• Anomaly (2026) Anomaly。OpenCode：开源编程智能体。https://github.com/anomalyco/opencode，2026 年。版本 v1.14.39；MIT 许可证；访问日期：2026-05-05。
• Anthropic (2026) Anthropic。Claude Code：Anthropic 的智能体编程系统。https://www.anthropic.com/product/claude-code，2026 年。访问日期：2026-05-05。
• Austin 等人 (2021) J. Austin、A. Odena、M. Nye、M. Bosma、H. Michalewski、D. Dohan、E. Jiang、C. Cai、M. Terry、Q. Le 等人。基于大语言模型的程序合成。arXiv 预印本 arXiv:2108.07732，2021 年。
• Baker 等人 (2025) B. Baker、J. Huizinga、L. Gao、Z. Dou、M. Y. Guan、A. Madry、W. Zaremba、J. Pachocki 和 D. Farhi。监控推理模型的不当行为及助长混淆的风险。arXiv 预印本 arXiv:2503.11926，2025 年。
• Bercovich 等人 (2026) I. Bercovich、I. Segal、K. Zhang、S. Saxena、A. Raghunathan 和 Z. Zhong。Terminal wrench：包含 331 个可奖励篡改环境与 3632 条利用轨迹的数据集。arXiv 预印本 arXiv:2604.17596，2026 年。
• Cao 等人 (2026) R. Cao、M. Chen、J. Chen、Z. Cui、Y. Feng、B. Hui、Y. Jing、K. Li、M. Li、J. Lin、Z. Ma、K. Shum、X. Wang、J. Wei、J. Yang、J. Zhang、L. Zhang、Z. Zhang、W. Zhao 和 F. Zhou。Qwen3-Coder-Next 技术报告。arXiv 预印本 arXiv:2603.00729，2026 年。URL https://arxiv.org/abs/2603.00729。
• Carlini (2026) N. Carlini。利用一组并行 Claude 构建 C 编译器。https://www.anthropic.com/engineering/building-c-compiler，2026 年。
• Chen 等人（2021）M. Chen、J. Tworek、H. Jun、Q. Yuan、H. P. de Oliveira Pinto、J. Kaplan、H. Edwards、Y. Burda、N. Joseph、G. Brockman、A. Ray、R. Puri、G. Krueger、M. Petrov、H. Khlaaf、G. Sastry、P. Mishkin、B. Chan、S. Gray、N. Ryder、M. Pavlov、A. Power、L. Kaiser、M. Bavarian、C. Winter、P. Tillet、F. P. Such、D. Cummings、M. Plappert、F. Chantzis、E. Barnes、A. Herbert-Voss、W. H. Guss、A. Nichol、A. Paino、N. Tezak、J. Tang、I. Babuschkin、S. Balaji、S. Jain、W. Saunders、C. Hesse、A. N. Carr、J. Leike、J. Achiam、V. Misra、E. Morikawa、A. Radford、M. Knight、M. Brundage、M. Murati、K. Mayer、P. Welinder、B. McGrew、D. Amodei、S. McCandlish、I. Sutskever 和 W. Zaremba。评估基于代码训练的大语言模型。arXiv 2107.03374，2021年。
• DeepSeek-AI（2025）DeepSeek-AI。Deepseek-v3.2：推动开源大语言模型的前沿，2025年。URL https://arxiv.org/abs/2512.02556。
• DeepSeek-AI（2026）DeepSeek-AI。Deepseek-v4：迈向高效百万级 token 上下文智能，2026年。URL https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro。DeepSeek-V4-Pro 模型卡；访问日期：2026-05-05。
• Deng 等人（2025）X. Deng、J. Da、E. Pan、Y. Y. He、C. Ide、K. Garg、N. Lauffer、A. Park、N. Pasari、C. Rane 等。Swe-bench pro：AI 智能体能解决长周期软件工程任务吗？arXiv 预印本 arXiv:2509.16941，2025年。
• Denison 等人（2024）C. Denison、M. MacDiarmid、F. Barez、D. Duvenaud、S. Kravec、S. Marks、N. Schiefer、R. Soklaski、A. Tamkin、J. Kaplan 等。从谄媚到暗算：探究大语言模型中的奖励篡改行为。arXiv 预印本 arXiv:2406.10162，2024年。
• Deshpande 等人（2026）D. Deshpande、A. Kannappan 和 R. Qian。通过对比分析在代码环境中对奖励破解检测进行基准测试。arXiv 预印本 arXiv:2601.20103，2026年。
• Ding 等人（2025）J. Ding、S. Long、C. Pu、H. Zhou、H. Gao、X. Gao、C. He、Y. Hou、F. Hu、Z. Li 等。Nl2repo-bench：面向编程智能体长周期仓库生成的评估基准。arXiv 预印本 arXiv:2512.12730，2025年。
• Du 等人 (2023) X. Du, M. Liu, K. Wang, H. Wang, J. Liu, Y. Chen, J. Feng, C. Sha, X. Peng, 和 Y. Lou. Classeval: 一个用于评估大语言模型在类级代码生成能力的人工构建基准测试, 2023.
• Gabor 等人 (2025) J. Gabor, J. Lynch, 和 J. Rosenfeld. Evilgenie: 一个奖励破解基准测试. arXiv 预印本 arXiv:2511.21654, 2025.
• Gao 等人 (2022) L. Gao, J. Schulman, 和 J. Hilton. 奖励模型过度优化的缩放定律. arxiv 电子预印本. arXiv 预印本 arXiv:2210.10760, 2022.
• Gauthier (2024) P. Gauthier. Aider: 终端中的 AI 结对编程. https://aider.chat, 2024.
• Golnari 等人 (2026) P. A. Golnari, A. Kumarappan, W. Wen, X. Liu, G. Ryan, Y. Sun, S. Fu, 和 E. Nallipogu. Devbench: 一个面向开发者的、贴近现实的代码生成模型基准测试. arXiv 预印本 arXiv:2601.11895, 2026.
• Goodhart (1975) C. A. E. Goodhart. 货币管理问题：英国经验. 货币经济学论文集, 1:1–20, 1975.
• Google (2025) Google. Gemini CLI. https://github.com/google-gemini/gemini-cli, 2025.
• Greenblatt 等人 (2024) R. Greenblatt, C. Denison, B. Wright, F. Roger, M. MacDiarmid, S. Marks, J. Treutlein, T. Belonax, J. Chen, D. Duvenaud, 等. 大语言模型中的对齐伪装. arXiv 预印本 arXiv:2412.14093, 2024.
• Huntley (2025) G. Huntley. 拉尔夫·威格姆作为“软件工程师”. https://ghuntley.com/ralph/, 2025年7月. 访问日期：2026-05-05.
• Jain 等人 (2024) N. Jain, K. Han, A. Gu, W.-D. Li, F. Yan, T. Zhang, S. Wang, A. Solar-Lezama, K. Sen, 和 I. Stoica. Livecodebench: 对代码大语言模型进行整体且无污染评估. arXiv 预印本 arXiv:2403.07974, 2024.
• Jiang 等人 (2025) Z. Jiang, D. Schmidt, D. Srikanth, D. Xu, I. Kaplan, D. Jacenko, 和 Y. Wu. AIDE: 代码空间中的 AI 驱动探索. arXiv 2502.13138, 2025.
• Jimenez 等人 (2023) C. E. Jimenez, J. Yang, A. Wettig, S. Yao, K. Pei, O. Press, 和 K. Narasimhan. Swe-bench: 语言模型能否解决真实的 GitHub 问题？ arXiv 预印本 arXiv:2310.06770, 2023.
• Karpathy (2026) A. Karpathy。autoresearch：在单GPU nanochat训练上自动运行研究的AI智能体。https://github.com/karpathy/autoresearch，2026年3月。MIT许可证；访问日期：2026-05-05。
• Khalifa 等人 (2026) M. Khalifa, Z. Khan, O. Tafveez, H. Peng, 和 L. Wang。Countdown-code：用于研究RLVR中奖励黑客行为的出现与泛化的测试平台。arXiv预印本 arXiv:2603.07084，2026年。
• Kimi Team (2026) Kimi Team。Kimi k2.5：视觉智能体智能，2026年。URL https://arxiv.org/abs/2602.02276。
• Krakovna 等人 (2020) V. Krakovna, J. Uesato, V. Mikulik, M. Rahtz, T. Everitt, R. Kumar, Z. Kenton, J. Leike, 和 S. Legg。规范博弈：AI创造力的另一面。DeepMind博客，3，2020年。
• Li 等人 (2025) B. Li, W. Wu, Z. Tang, L. Shi, J. Yang, J. Li, S. Yao, C. Qian, B. Hui, Q. Zhang, 等人。提示大语言模型应对完整软件开发生命周期：一项案例研究。第31届国际计算语言学会议论文集，2025年。
• Manheim 和 Garrabrant (2018) D. Manheim 和 S. Garrabrant。古德哈特定律变体分类。arXiv预印本 arXiv:1803.04585，2018年。
• MiniMax AI (2026) MiniMax AI。MiniMax-m2.7，2026年。URL https://github.com/MiniMax-AI/MiniMax-M2.7。模型仓库；访问日期：2026-05-05。
• Moonshot AI (2026) Moonshot AI。Kimi k2.6：从代码到创造，从一到多，2026年。URL https://huggingface.co/moonshotai/Kimi-K2.6。模型卡片；访问日期：2026-05-05。
• Niu 等人 (2023) C. Niu, C. Li, V. Ng, 和 B. Luo。CrossCodeBench：源代码模型跨任务泛化能力基准测试。2023年IEEE/ACM第45届国际软件工程大会（ICSE），2023年。
• OpenAI (2025a) OpenAI。推出GPT-5.2-Codex。https://openai.com/index/introducing-gpt-5-2-codex/，2025年12月。访问日期：2026-05-05。
• OpenAI (2025b) OpenAI。OpenAI o3和o4-mini系统卡。https://openai.com/index/o3-o4-mini-system-card/，2025年4月。系统卡。
• Ouyang 等人 (2025) A. Ouyang, S. Guo, S. Arora, A. L. Zhang, W. Hu, C. Ré, 和 A. Mirhoseini。KernelBench：大语言模型能否编写高效的GPU内核？arXiv预印本 arXiv:2502.10517，2025年。
• Pan 等人（2022）A. Pan、K. Bhatia 和 J. Steinhardt。奖励指定错误的影响：映射与缓解失调模型。arXiv 预印本 arXiv:2201.03544，2022 年。
• Skalse 等人（2022）J. Skalse、N. Howe、D. Krasheninnikov 和 D. Krueger。定义与刻画奖励钻营。Advances in Neural Information Processing Systems，35:9460–9471，2022 年。
• Strathern（1997）M. Strathern。“改进评级”：英国大学体系中的审计。European Review，5(3):305–321，1997 年。
• Thaman（2026）K. Thaman。奖励钻营基准：衡量使用工具的 LLM 智能体中的漏洞利用。arXiv:2605.02964，2026 年。
• Wang 等人（2026）X. Wang、M. Tian、Y. Zeng、Z. Huang、J. Yuan、B. Chen、J. Xu、M. Zhou、W. Liu、M. Wu 等。大模型时代的奖励钻营：机制、涌现性失调与挑战。arXiv 预印本 arXiv:2604.13602，2026 年。

附录 A 局限性与更广泛影响

局限性。SpecBench 将奖励钻营操作化为验证性能与留出性能之间的差距。虽然我们的留出测试旨在不引入超出任务规范之外的任何要求，但它们仍然是一个有限的测试集，因此无法穷尽地证明完全符合规范。因此，较小的奖励钻营差距不应被解释为生成的系统在所有可能的使用场景中都是正确的；它仅表明系统从孤立的验证检查泛化到了我们留出测试所涵盖的组合行为。更广泛地说，该基准聚焦于 30 个系统级编程任务以及有限的编码智能体和搜索策略，因此未来的工作应扩展任务集，评估更多智能体框架，并研究相同的失败模式是否会在更大的真实世界代码库中出现。

更广泛的影响。SpecBench 揭示了测试通过率并非代码质量的可靠指标，这对在生产环境中部署编码智能体的组织具有直接影响。我们发布了该基准测试及方法论，以便从业者在部署前能够审计智能体是否存在奖励作弊行为。随着编码智能体向更长的任务周期扩展，奖励作弊问题可能会加剧；我们主张采用能够衡量代码结构完整性（而不仅仅是测试分数）的评估框架。

附录 B 计算资源

所有实验均在一台可通过 API 访问云端模型的机器上完成；未进行任何自定义训练或微调。表 3 总结了所有实验消耗的计算资源。

总实验预算约为 2,700 GPU 等效小时（114 天挂钟时间），API 总成本为 $38,904。尽管运行次数相近，但由于更高的每 token 定价，Codex 占据了大部分成本。Claude Code 和 OpenCode 每次运行的成本则显著更低。每个内部智能体步骤的超时时间为 600 秒（编译器任务为 1,200 秒）。树搜索外层循环通常在 2-4 小时内完成。

附录 C 案例研究：Claude 的 C 编译器

为了解奖励作弊是自主智能体的特有现象，还是会延伸到人类指导的开发过程中，我们评估了 Claude 的 C 编译器（CCC）——一个由 Claude Opus 4.6 在持续人工监督下构建的、拥有 186,000 行代码的 Rust 编译器（Carlini, 2026）。CCC 并未针对 SpecBench 进行优化；它完全是针对 GCC 压力测试套件开发的，该套件是一套全面且广泛用于验证生产级编译器的、包含超过 900 个 C 程序的测试集。CCC 通过了全部压力测试。我们纯粹将 SpecBench 作为一个独立的、分布外评估工具，用以测试一个经过人工指导且通过测试套件验证的编译器，在针对保留测试进行评估时是否仍会表现出奖励作弊行为。

设置。

我们在 SpecBench 的 c_compiler 任务上评估了 CCC，该任务包含 46 个验证测试（独立的 C 语言特性：算术、指针、结构体、函数、控制流）和 299 个保留测试。保留测试包括 88 个跨特性组合（例如，在 for 循环内进行指针运算的结构体成员访问、带 fallthrough 和类型转换的嵌套 switch 语句）和 150 个来自 GCC 折磨测试套件、需要多特性代码生成正确性的测试，外加 61 个错误检测测试，用于验证编译器能正确拒绝无效的 C 程序（例如，函数参数过多、变量重定义、break 在循环外）。

结果。

CCC 在验证测试上达到 97.8%，在保留测试上达到 83.3%，产生了 pp 的奖励黑客差距。作为对比，同一任务上的自主 AIDE 智能体产生的差距范围从 0pp（无法工作的实现）到 99pp（查表式黑客手段），中位数为 55pp。

这 14.5pp 的差距几乎完全由错误检测失败导致。CCC 能正确编译并执行大多数有效的 C 程序——其在有效程序上的组合测试通过率超过 97%。然而，它会静默接受 GCC 正确拒绝的无效 C 代码。表 4 展示了代表性示例。

这些并非组合失败——而是 GCC 折磨测试套件从未测试过的一个缺失的规范符合性维度。折磨测试套件验证的是正确的程序能否产生正确的输出；它并不验证错误的程序是否会报错。由于 CCC 是针对一个只检查有效输入的测试套件进行优化的，该智能体在代理指标上优化得完美无缺，却遗漏了 C 语言规范的一个核心部分。

启示。

本案例研究说明了三点。第一，奖励破解并非仅限于自主智能体，即使是经过仔细的人工引导并使用全面测试套件进行开发，在针对覆盖未测试维度的保留测试进行评估时，也会产生可衡量的差距。第二，这种差距源于测试套件的结构，而非模型能力或人为疏忽。CCC 是一个功能正常的编译器；它只是从未在无效输入上进行过测试。第三，SpecBench 的保留测试之所以能揭示这个盲点，正是因为它包含了错误检测测试，而这是标准编译器测试套件所遗漏的维度。这验证了 SpecBench 的设计原则：保留测试应覆盖规范所允许的任何隐含用例。

附录 D 完整任务套件

表 5 提供了完整的 SpecBench 任务套件，包括参考实现规模、测试数量、实现语言和领域分类。该基准测试本身及附带代码可从我们在 OpenReview 上的补充材料中获取。