Agent 可靠性评测：pass@k、pass^k 与失败轨迹

TL;DR

Agent 可靠性需要重复运行同一任务，并分别报告平均成功率、至少一次成功与全部成功。先重置环境，再按任务估计指标和不确定性，不能对总体平均值直接做幂运算。失败轨迹用于定位不稳定决策；多次输出相同只代表一致，仍须独立检查正确性与副作用。

一次成功为什么不能代表可靠交付

同一任务从相同状态重复执行，才能看出成功是否稳定。演示通过一次，无法估计下次失败的风险。

2026 年 9 月的 Consistency Gap 研究 在指定 AppWorld 设置上使用 168 个任务、每任务五次运行。论文报告 GPT-4.1 的平均表现约为 77%，五次全部成功的任务比例约为 53%，差距为 24.4 个百分点。这是该 Agent、模型、任务与配置下的结果，不能推广为所有 Agent 的生产成功率。

平均成功率统计每次运行，全部成功率检查每个任务是否出现过失败。自动处理订单时，还要单独统计偶发越权，不能让它被平均分掩盖。

Agent Harness决定工具、重试、上下文和终止。先排除环境、任务和验收器变化，再分析决策波动；降低温度不能解决所有不稳定问题。

三类指标回答三个问题

Trial 指从规定起点到终止的一次完整运行，是否成功由验收器判断。三个指标分别衡量单次表现、多次找出成功候选的能力，以及重复执行的稳定性。

τ-bench 的 2024 年论文提出 pass^k，验收涉及最终数据库状态和任务要求。近期研究延续了这条思路。

如果每个任务 i 的成功概率是 p_i，并假设该任务各次 Trial 独立且概率固定，则：

Mean = average(p_i)
pass@k = average(1 - (1 - p_i)^k)
pass^k = average(p_i^k)

必须先按任务计算。两个任务的成功概率分别为 1 和 0，平均成功率是 0.5，pass^2 平均仍是 0.5；对总体均值取平方却得到 0.25。

从重复结果计算指标

每任务运行 n 次、成功 c 次，随机选取 k 次，可用组合比例估计至少一次或全部成功。要求 1 ≤ k ≤ n。

pass@k estimate = 1 - C(n-c, k) / C(n, k)
pass^k estimate = C(c, k) / C(n, k)

可选元素少于 k 时，组合数为零。这是无放回选择的估计；要推断未来重复运行，仍需独立同分布假设。

下面使用合成数据，全部任务各运行五次：

pass@2 高，仍可能有频繁失败。实际流程还需要选对成功候选；选择器会挑错时，必须把它纳入端到端评测。

各任务重复次数不同时，先算逐任务指标再等权平均。直接汇总所有 Trial 会偏向重复次数多的任务。按业务流量加权时，另报权重来源。

Go 实践：稳定计算组合比例

下面的 Go 1.23 示例通过比例乘积避免直接计算巨大组合数，只依赖标准库。输出对应上面的合成表格，函数会拒绝 n、c 或 k 不合法的输入。

package main

import "fmt"

type Metrics struct {
	Mean    float64
	PassAny float64
	PassAll float64
}

func subsetRatio(selected, total, k int) float64 {
	if selected < k {
		return 0
	}
	ratio := 1.0
	for j := 0; j < k; j++ {
		ratio *= float64(selected-j) / float64(total-j)
	}
	return ratio
}

func estimate(n, c, k int) (Metrics, error) {
	if n < 1 || c < 0 || c > n || k < 1 || k > n {
		return Metrics{}, fmt.Errorf("require n>=1, 0<=c<=n, 1<=k<=n")
	}
	return Metrics{
		Mean:    float64(c) / float64(n),
		PassAny: 1 - subsetRatio(n-c, n, k),
		PassAll: subsetRatio(c, n, k),
	}, nil
}

func main() {
	counts := []int{5, 4, 2, 0}
	sum := Metrics{}
	for i, c := range counts {
		m, err := estimate(5, c, 2)
		if err != nil {
			panic(err)
		}
		fmt.Printf("%c mean=%.3f any=%.3f all=%.3f\n",
			'A'+i, m.Mean, m.PassAny, m.PassAll)
		sum.Mean += m.Mean
		sum.PassAny += m.PassAny
		sum.PassAll += m.PassAll
	}
	size := float64(len(counts))
	fmt.Printf("macro mean=%.3f any=%.3f all=%.3f\n",
		sum.Mean/size, sum.PassAny/size, sum.PassAll/size)
	if _, err := estimate(5, 6, 2); err == nil {
		panic("invalid count accepted")
	}
}

运行 go run main.go：

A mean=1.000 any=1.000 all=1.000
B mean=0.800 any=1.000 all=0.600
C mean=0.400 any=0.700 all=0.100
D mean=0.000 any=0.000 all=0.000
macro mean=0.550 any=0.675 all=0.425

函数计算指标，不给出置信区间，也不判断 Trial 独立性。很小的概率可能浮点下溢；通常的有限重复规模足够使用，若需要极端尾部概率，应改用对数域并报告精度。

五次全部成功，也不能证明未来必然成功。重复次数由允许的失败风险和估计精度决定。

重复 Trial 必须从相同环境起点开始

每个 Trial 使用隔离的文件、数据库、缓存和操作标识。失败后也要完整清理，否则下次可能复用部分结果。

记录模型版本、采样参数、工具版本和可控随机种子。温度为零，仍可能受服务更新和并行工具调度影响。

超时与工具故障应纳入系统成功率，同时另报根因切片。如果想测纯模型决策，可以另建冻结工具响应的实验，但不能把它当作线上系统可靠性。跨会话中断的专项设计见长任务恢复评测。

不确定性建议采用任务级 bootstrap：以任务为单位有放回抽样，每次携带该任务所有 Trial，重算宏平均，再报告预先选定的百分位区间。比较两个系统时，对相同任务一起抽样。这样的区间主要反映任务抽样不确定性；任务内随机性还需要足够重复和适当的分层模型。

从失败轨迹定位不稳定决策

比较Agent 轨迹中的工具、参数、返回结果和终止原因，定位错误在哪一步发生。

对每个任务选取成功与失败 Trial，先对齐语义步骤：解析日期、查询订单、检查权限、输出结果。然后找最早的关键分歧：日期解析不同、缺少权限查询、重试后重复写入，或者在工具报错后提前结束。

最早分歧只能提供线索。不同调用可能等价，相同调用也可能读到不同状态。核对输入与返回结果后，再做干预实验，例如固定日期解析结果，观察失败是否减少。

修复后重跑相同任务并独立验收。步骤变短、解释变一致，都不能代替正确性检查。

常见问题

pass@k 很高，可以直接上线吗？

需要实际选择机制和成本预算。如果系统只执行一次，pass@k 无法代表交付能力；如果执行 k 次却不能识别成功候选，也无法实现理想的至少一次成功收益。

应该选多大的 k？

根据重复使用方式选择。日常自动化可报告 k=1、2、5 的曲线，但 n 必须至少达到最大 k。高风险业务还需要单独报告严重错误率，不能用总体 pass^k 掩盖少量越权。

输出完全相同为什么仍可能不可靠？

稳定错误仍然是错误。重复性检查回答行为是否波动，正确性验收回答是否满足任务。二者应并列报告，不能互相替代。

如何比较两个 Harness 的重复可靠性？

使用相同任务、快照与验收器，配对比较逐任务指标，同时报告预算。参见Harness 对照与消融评测，避免把更多尝试误认为架构改进。

参考资料

• Consistency Gap 研究，2026-09-08，指定 AppWorld 配置的重复运行结果。
• τ-bench 论文，2024，工具与用户交互评测及 pass^k。
• Anthropic：Demystifying evals for AI agents，2026-01-09。