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：能力上限，也是"技术奇观"的制造机

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圈"技术奇观"的数学原理：

• Anthropic让模型一周写出一个C编译器——背后可能是无数次尝试中挑出最好的一次；
• Manus演示虚拟电脑上丝滑操作——演示视频是剪辑的精华，不是连续实录；
• OpenClaw直播"活人感"对话——你看到的是幸存者偏差，翻车的那些run没人给你看。

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

三、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业务？

• 内容生成、代码辅助、研究分析 → Pass@k业务，允许重试和人工挑选；
• 支付、结算、库存扣减、设备控制 → Pass^k业务，必须连续可靠。

四、光看成功率不够：过程指标体系

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

1. 行动合法率：Agent执行的动作是否在允许的动作空间内。比如退款Agent跑去调用库存查询工具修改数据，就是非法动作；
2. 工具调用正确率：参数对不对、调用的工具对不对。工具选对但参数传错，是新手Agent最常见的病；
3. 路径效率：完成任务用了多少步、多少token。10步能完成的事走了47步，即使结果对了，延迟和成本也不可接受；
4. 检索覆盖率（RAG场景）：召回的文档里是否包含了回答问题所需的信息，召回不行，生成再好也是巧妇难为无米之炊；
5. 成本与延迟：单次任务的token消耗、端到端耗时，这直接决定这个Agent在商业上能不能活下去。

五、一票否决项：安全合规与幻觉

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

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

六、鲁棒性：别只在"晴天"测试

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

• 随机种子扰动：同一输入多次运行，输出是否稳定（温度、采样带来的方差有多大）；
• 页面/环境变化：操作网页的Agent，按钮换个位置、弹个新弹窗就傻了？
• API抖动：工具接口偶发超时、返回异常格式，Agent是优雅重试还是直接躺平；
• 长时记忆干扰：多轮会话中，早前的上下文是否污染当前决策。

七、人工抽检与对抗式评审

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

• 人工抽检：按比例抽查轨迹，重点看自动评估判"成功"的样本——机器觉得对的不一定真对；
• 对抗式评审：让一个人专门扮演"找茬的"，构造边界case、诱导性输入、异常数据去攻击Agent。攻击者的视角永远比建设者毒辣。

八、实战：售货柜退款Agent的评估表

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

注意第一条：我们考核的是Pass^20 而不是 Pass@20。因为每一笔退款都是真实的钱，用户不会给你重试五次的机会。

小结

• Pass@k = 1-(1-p)^k，衡量能力上限，是技术奇观的数学来源；
• Pass^k = p^k，衡量业务可靠性，是生产系统的生死线；
• p=0.6 时 Pass@5≈99% 但 Pass^5≈7.8%，同一个模型，两种命运；
• 结果指标之外，补齐行动合法率、工具调用正确率、路径效率、成本延迟等过程指标；
• 安全合规与幻觉是一票否决，不是扣分项；
• 用轨迹+结果双重覆盖、扰动测试、人工抽检和对抗式评审，把评估做成体系，而不是一次性的表演。

评估做得好，Agent的每一次迭代才有方向；没有评估的迭代，只是在换着花样碰运气。