16. Reliability：一次成功不等于可靠
核心工程 · 3～5 小时
学习目标
- 理解 stochastic Agent 的多次运行问题
- 区分 pass@k 与 pass^k
- 设计稳定性、方差和关键 Case 可靠性实验
前置知识
- 基础概率统计
- 第 6～15 章
本章产物： 对同一 Suite 运行多次，并给出可靠性报告。
16.1 为什么单次 Run 不够
Agent 可能因为采样、工具结果和用户交互产生不同轨迹。
一个 Case：
Run1 PASS
Run2 PASS
Run3 FAIL
Run4 PASS
Run5 FAIL报告“这个 Case PASS”毫无意义。
16.2 pass@k 与 pass^k 不一样
pass@k
代码生成常用：k 次采样中至少一次成功的概率。
它回答：
如果允许多试几次，能不能找到一个成功结果？
pass^k
τ-bench 用来强调可靠性：多次独立执行时，Agent 是否能持续成功。
直觉上它强调：
不是偶尔成功，而是重复成功。
这两个指标方向几乎相反，不能混用。
16.3 Per-case Reliability
不要只计算总体成功率。
例如：
easy cases 100%
critical cancellation 60%平均 95% 仍可能不可上线。
16.4 关键任务建议重复运行
可以根据风险分配 Epoch：
normal: 3
important: 5
critical: 10+高成本 Agent 不一定所有 Case 都跑 20 次。
16.5 Variance Sources
记录：
- temperature；
- seed（若 provider 支持）；
- model revision；
- tool response；
- user simulator；
- environment；
- time。
否则无法解释方差来源。
16.6 Reliability 与 Retry Policy
产品里有自动 retry 时，必须同时评：
first-attempt success
eventual success
retry count
cost
duplicate side effects只报 eventual success 会掩盖脆弱性。
16.7 置信区间
对于有限 Case，点估计不是精确真值。
建议报告：
n
mean
confidence interval
per-category breakdownBaseline/Candidate 使用 paired cases 比两个独立平均数更有解释力。
16.8 验收问题
- pass@k 为什么不等于可靠性？
- 自动 Retry 为什么会让成功率看起来更好？
- 为什么 Critical Case 应单独看？