Agent评估指标体系：Pass@k能力上限与Pass^k连续可靠（业务可靠性）-育师

13-Agent评估指标体系：Pass@k能力上限与Pass^k连续可靠（业务可靠性）

系列导读：本系列基于李博杰《深入理解AI Agent：设计原理与工程实践》的阅读思考，结合我在智慧农业、无人售货柜一线的工程实践展开。这一篇聊一个所有做Agent落地的人都绕不开的话题——评估。

先说一个扎心的现实：很多团队的Agent项目，demo惊艳，上线翻车。为什么？因为从第一天起就没有一套严肃的评估体系。你在测试环境里手动点五次，三次成功，就敢说"Agent能用了"——这不是工程，这是抽奖。

《深入理解AI Agent》里有一个核心观点我非常认同：Agent的开发循环是"评估驱动"的。就像深度学习有训练集/验证集，Agent也需要一套可重复、可量化、可持续运行的评估体系。你改了一版Prompt、换了一个模型、调了一次工具描述，怎么知道是变好了还是变坏了？靠感觉是不行的，靠评估。

评估的第一步，是把"成功率"这个词拆开。而拆开之后，你会发现两个长得极像但意义天差地别的指标：Pass@k和Pass^k。

Pass@k 的定义：同一个任务，让Agent独立尝试 k 次，至少有一次成功的概率。

假设单次成功率为 p，那么：

Pass@k = 1 - (1 - p)^k

直觉很朴素：一次不行就再来一次，只要有一次中奖就算赢。取 p = 0.6，k = 5：

Pass@5 = 1 - (0.4)^5 ≈ 1 - 0.0102 ≈ 98.98% ≈ 99%

看，单次只有60%的成功率，五次尝试下来"成功率"直接飙到99%。这就是过去两年AI圈"技术奇观"的数学原理：

这些不是造假，而是Pass@k视角下的能力展示：它衡量的是Agent的能力上限——“最好能做成什么样”。对于写代码、做研究、生成内容这类可以人工审查、可以重试的场景，Pass@k是有意义的指标，因为挑出一次成功结果的成本很低。

再看 Pass^k 的定义：同一个任务，连续做 k 次，每一次都成功的概率：

Pass^k = p^k

同样取 p = 0.6，k = 5：

Pass^5 = 0.6^5 = 0.07776 ≈ 7.8%

对比一下：Pass@5 ≈ 99%，Pass^5 ≈ 7.8%。同一个Agent，同一个任务，同一组数字，结论差了十几个数量级的体感。

这两个指标的关系可以总结成一句话：

Pass@k 衡量"能力上限"，Pass^k 衡量"业务可靠性"。前者是技术奇观的放大器，后者是生产系统的入场券。

为什么业务系统看的是Pass^k？因为在真实业务里，很多操作是零容忍的：

在我的无人售货柜业务里，这感受极其强烈：一个"用户扫码开门取货自动结算"的Agent，识别错了、扣款错了，用户直接投诉，客诉一次的成本远高于它正确服务一百次创造的价值。这类场景下，60%的单次成功率意味着什么？意味着每五单就有两单可能出问题——这不是产品，这是定时炸弹。

所以做Agent落地，第一件事是问自己：我的业务是Pass@k业务，还是Pass^k业务？

《深入理解AI Agent》强调，评估要做轨迹与结果双重覆盖——只看最终结果，你不知道Agent是怎么到达的；只看过程，你不知道结果对不对。一套完整的过程指标至少包括：

过程指标是打分题，但有些是判断题，而且判错直接零分：

安全合规一票否决：Agent把敏感数据发给外部API、执行了越权操作、输出了违规内容——无论任务完成得多漂亮，这条轨迹直接判负；
幻觉一票否决：在事实性任务里编造不存在的订单号、虚构退款政策条款。对售货柜退款Agent来说，"编造一个不存在的优惠券规则说服用户"比"承认查不到"严重一百倍。幻觉不是扣分项，是出局项。

很多Agent在标准环境里表现优秀，一到线上就崩。鲁棒性评估要做扰动测试：

自动化评估再好，也不能100%代替人。实践建议：

给一个我们真实在用的评估框架缩影。退款Agent的任务：用户投诉"扫码扣款了但没拿到货"，Agent需要查订单、查柜机日志、判断责任、执行退款或拒绝。