超越Pass@k：衡量代理代码生成的可靠性和安全性

# 超越Pass@k：衡量智能体代码生成的可靠性与安全性
来源：https://arxiv.org/html/2608.14711
Sharon Zheng、Natan Vidra（隶属机构：Anote\.Ai）、Spurthi Setty（隶属机构：Stevens Institute of Technology）\[0\.6em\]Cornell University

###### 摘要

当前AI编程智能体基准测试使用Chen等人(2021)提出的pass@k估计器对智能体进行排名，但现有实现存在误用：它们将n设为单次提交中的单元测试数量，而非独立执行轮次的数量，从而混淆了测试套件规模与尝试独立性。本文诊断了这一操作化错误，通过反例进行证明，并提出了reliability@k指标——即正确应用同一估计器，其中n为独立执行轮次数，c为每个（任务, 智能体）对中完全通过的轮次数。在合成多轮次基准测试中，误用的指标使报告分数绝对值虚增了0.85–0.97（报告值0.96–0.98 vs. 修正值0.00–0.12），且廉价的单轮次代理指标无法替代多次运行（斯皮尔曼ρ=0.417）。基于功能性正确并不意味着安全性的相关证据，我们进一步提出了安全调整版reliability@k，该指标仅统计既通过功能正确性测试又无严重不安全模式的轮次；在对三个智能体的初始实时API测试中，根据当前扫描器和阈值，调整未改变任何排名，因此我们将其作为提议的互补评估视角呈现，其决定性评估需要后续更强力的运行来验证。最后，在真实代码仓库环境中的初步5任务SWE-bench Verified试点观察到了同样的核心问题：宏平均隐藏测试通过率为0.80，而严格任务解决率仅为0.20。

## 1引言

AI编程智能体正越来越多地被部署于生产环境中的软件工程工作流，诸如Claude Code、GitHub Copilot和Codex等工具处理从功能实现到错误修复的众多编码任务。评估这些智能体的基准测试及其排名指标，对于决定智能体的应用至关重要。有缺陷的基准测试不仅会错误呈现性能表现，还会误导开发优先级，并影响企业部署决策。本文将研究可靠性与安全性对智能体AI部署的影响。

本文指出当前评估AI编程智能体方式中存在的两个独立缺陷。

第一个缺陷是数学层面的。评估指标pass@k基于Chen等人[2]提出的无偏组合估计器，该估计器在数学上是正确的，但要求输入n个来自相同分布的、独立同分布的完整解决方案样本。当前实践却错误地将单次提交中的单元测试数量代入n，将通过的测试数量代入c。我们发现这些并非独立样本，而是单次执行中相互关联的子结果。因此，pass@k分数取决于测试套件规模而非智能体能力。两个具有相同40%任务成功率的智能体，仅因测试套件包含不同数量的测试，其分数分别达到0.976和1.000。在整个基准测试中，这导致报告分数绝对值虚增0.85–0.97，并且原则上可能逆转智能体排名。

第二个缺陷是安全盲区。即使功能正确性被准确衡量，它也仅反映代码是否通过测试，而非是否适合部署。Veracode（2025）[6]报告指出，AI生成的代码引入的漏洞比人类编写的代码多2.74倍，且约45%通过所有功能测试的AI生成解决方案包含严重安全漏洞，如SQL注入（CWE-89）、OS命令注入（CWE-78）或不安全反序列化（CWE-502）。

我们提出了CodeBench评估框架来解决上述两个缺陷。我们的主要贡献包括：

- •pass@k操作化错误的正式证明。我们证明将单元测试计数替代独立执行轮次计数违反了Chen等人估计器的独立同分布假设，并提供了一个反例，展示了在具有相同真实可靠性的智能体上由此产生的分数差异（假设H1）。
- •reliability@k。我们提出了正确操作化Chen等人公式的方法：将其应用于n=每个（任务, 智能体）的独立执行轮次数，c=达到完全执行成功的轮次数。在合成多轮次基准测试中，这将报告分数从0.96–0.98降至0.00–0.12，即使排名顺序保持不变，也从根本上改变了绝对分数的解释（假设H2）。
- •单轮次代理指标不足的实证验证。我们测试了一个廉价代理指标（通过回归惩罚和工具效率加权的通过率）是否与reliability@k足够强相关以替代重复评估。结果并不相关（斯皮尔曼ρ<0.70），这确立了多轮次数据收集对于获得可信可靠性估计的必要性（假设H3）。
- •security\_adjusted\_reliability@k。我们提出了一种复合指标，将reliability@k与启发式安全筛选相结合，其动机在于担心企业选择最可靠的智能体时，可能同时选择了最易产生漏洞的代码生成器。在对三个智能体的初始实时API测试中，根据当前扫描器和宽松阈值，调整后的指标未改变任何排名（肯德尔τ=1.000）；因此我们将其作为提议的互补视角呈现，其决定性测试需要更强力的评估（假设H4）。

除上述贡献外，我们还报告了一项初步的外部验证：在真实代码仓库环境中进行的5任务SWE-bench Verified试点（第4.5节）显示，严格的任务解决率（0.20）与宏平均隐藏测试通过率（0.80）存在显著差异，这与上述估计器问题在现实场景中的表现一致。

## 2背景

### 2.1大语言模型代码生成与采样

大语言模型通过预测给定提示和所有先前生成令牌的下一个令牌概率分布来生成代码。在每个解码步骤中，模型为其词汇表中的每个令牌分配概率，并从该分布中采样以产生输出。控制这一过程的关键参数是温度：在温度为0（贪婪解码）时，模型总是选择最高概率的令牌，产生确定性输出。随着温度升高，分布变得平坦，较低概率的令牌更可能被采样，为输出引入随机性。这意味着在同一非零温度下提交两次相同的提示会产生不同的补全——有时细微（变量重命名、循环重构），有时显著（完全不同的算法方法）。这种运行间的差异并非缺陷；它反映了模型输出分布的真实不确定性，也是pass@k旨在测量的方差来源。通过采样多个补全并检查有多少通过测试，pass@k估计从模型分布中独立抽取的k个样本中至少有一个产生正确解决方案的概率。

### 2.2pass@k指标

Chen等人[2]在Codex论文中引入pass@k，旨在以避免朴素估计器高方差的方式来评估大语言模型代码生成。朴素方法——生成k个样本，检查有多少通过，然后相除——当k较小时具有高方差。因此，Chen等人提出了一个无偏估计器：生成n个样本（n≥k），统计正确的数量c，并计算：

pass@k = E[1 - (n-c choose k) / (n choose k)]  (1)
该公式估计从生成的n个样本中随机选择k个样本，其中至少有一个正确的概率。该公式基于两个关键假设：首先，n个样本中的每一个都是从模型输出分布中独立抽取的；其次，相对于k，n应足够大以稳定估计。当n是从同一提示的模型中采样的独立代码补全数量时，这些假设得到满足。当n被重新解释为单次提交中的测试用例数量时，这些假设被违反——这是一种范畴错误，混淆了测试套件多样性与尝试独立性，也是本文要解决的核心问题。

### 2.3代码生成基准测试格局

早期的代码生成基准测试如HumanEval[2]和MBPP[1]评估模型在简短、自包含的编程任务上的表现——通常是可在20行代码内解决的单一函数。这些基准测试天然适合pass@k：为简短函数生成10-20个独立补全是廉价、快速的，且输出确实是来自模型分布的独立抽取。随着领域成熟，基准测试在范围和复杂度上不断增长。SWE-bench[4]评估智能体处理需要多文件编辑、依赖关系感知和跨整个代码仓库测试套件导航的真实GitHub问题。EvalPlus[5]在HumanEval基础上增加了额外测试用例以减少误报，但继承了相同的单函数评估范式。LiveCodeBench[3]通过时间分层问题解决训练数据污染问题，但未改变评估协议。CodeBench属于SWE-bench级别：任务是多步骤、代码仓库级别的，且运行成本高昂。这一区别很重要，因为适用于HumanEval的评估方法并不适用于此场景。

### 2.4智能体与基于补全的代码生成

基于补全的代码生成将模型视为无状态函数：给定提示，产生一个补全。每次调用独立、廉价且快速——非常适合基于采样的评估。智能体代码生成则根本不同。编程智能体在循环中运行：它读取任务，形成计划，发出工具调用（文件读取、终端命令、测试运行器、网络搜索），观察结果，更新状态，并迭代直至判断任务完成或耗尽预算。在单个任务上的每次完整智能体运行可能涉及数十次工具调用，消耗大量时间和API令牌，并在环境中产生需要在运行之间重置的副作用。这使得每次尝试都昂贵且审慎，而非廉价的独立样本。在生产环境中部署编程智能体的工程师不会在相同任务上运行它五十次并选择最佳输出——他们只运行一次并希望它成功。这一操作现实正是reliability@k旨在衡量的：不是从众多廉价样本中至少有一个正确的概率，而是单次审慎尝试成功的概率，通过适度次数的重复运行来估计。

## 3实验设置

### 3.1基准测试与任务语料库

CodeBench的任务语料库包含十个精心策划的编码问题，涵盖算法、数据结构和轻量级代码仓库风格场景。任务分为三个等级：

- •简单（3个任务）：导入解析（基于AST）、归并排序和单函数实现。
- •中等（3个任务）：数据管道设计、LRU缓存和Trie数据结构。
- •困难（4个任务）：Dijkstra算法、BM25排序、背包DP和流式中位数查找器。

每个CodeTask都有自然语言描述、Python参考解决方案和相应的测试文件路径。对于合成基准测试实验（种子=42），这些任务与模拟重复评估运行的合成智能体提交配对。

### 3.2智能体与提交

我们评估了三个标记为以下的合成智能体配置文件：

- •agent-x：智能体配置文件1。
- •claude-code：智能体配置文件2。
- •codex：智能体配置文件3。

*注意：这是一项合成基准测试实验，并非对生产系统的评估。*提交通过make\_rollout\_benchmark()函数合成生成，该函数为每个（任务, 智能体）对创建独立执行轮次。每个轮次以潜在的“真实技能”参数s∈[0.30,1.0]建模，s均匀采样，单次轮次性能从以s为中心、方差与(1.0-0.5s)成比例的截断高斯分布中抽取。该分布旨在引入受控的轮次级方差：

- •重复运行中的轮次级变化。
- •决定长期可靠性的连续潜在技能参数。
- •通过种子控制（种子=42）实现确定性可重现性。

### 3.3评估指标

CodeBench为合成提交实现了五个核心评估指标。

#### 通过率。

pass\_rate = tests\_passed / tests\_total
单次提交中单元测试通过的比例。

#### 回归率。

regression\_rate = regression\_count / tests\_total
因回归（在原本工作的测试用例中引入缺陷）导致的测试失败比例。

#### 工具效率得分。

tool\_efficiency = max(0, 1 - tool\_calls\_used / 20)
惩罚过度的工具调用；旨在奖励简洁的智能体行为。

#### 成本调整得分。

cost\_adjusted = pass\_rate / log(1 + cost\_usd)
通过日志成本对通过率进行归一化，奖励高效的解决方案。

#### 安全得分。

启发式扫描器检测生成代码中的七种高危模式：eval()、exec()、os.system()、带shell=True的subprocess、pickle.load()、未使用Loader的yaml.load()以及\_\_import\_\_()。每种模式使得分降低1/7；返回值范围为[0,1]。

### 3.4实验方案

所有实验使用固定种子（种子=42）以保证可重现性。主要实验框架是通过make\_rollout\_benchmark(n\_tasks=10, agents=3, n\_rollouts=8, seed=42)构建的合成基准测试，产生10×3×8=240个合成ExecutionResult条目。每个智能体配置文件具有潜在的“真实技能”参数（采样自~U[0.30,1.0]），单次轮次结果围绕该技能值从截断高斯分布中抽取。对于每个（任务, 智能体）对，如果在该轮次中任务达到接近完全的测试成功（pass\_rate≥0.95），则execution\_success设为True。

实验0-3按顺序在此合成基准测试上运行：

- •实验0：使用错误的estimate\_pass@k指标的基线排行榜（混淆单元测试计数与轮次计数）。
- •实验1：独立同分布违反的受控证明（假设H1）。两个具有相同0.40单次提交测试通过率但不同测试套件规模的合成智能体配置文件，获得不同的基于测试用例的pass@5分数。
- •实验2：正确与错误pass@k下的分数虚增幅度（假设H2）。测量合成基准测试上estimate\_pass@k与reliability@k之间的差距。
- •实验3：单轮次代理指标与reliability@5的相关性分析（假设H3）。计算所有30个（任务, 智能体）对的斯皮尔曼ρ。