Agent 评估要查执行过程与重复成功率

dev.to · AI#Agent#评估#可靠性

Editor brief · 编辑速览

文章建议同时评估任务最终状态、工具选择、参数准确性和重复执行的一致性，避免只凭最终回复判定成功。它区分 pass@k 与 pass^k，指出单次成功率为 75% 时，在独立运行假设下连续三次成功的概率仅约 42%。

文章思维导图

Knowledge map

拖拽缩放

AI deep read

AI 深度解读

Agent 演示成功，不代表上线后就可靠。原文拿「退款工单看似处理完，背后却调错工具」提醒我们：评估不能只看最后一句回复，还要检查任务是否真正完成、工具是否用对，以及重复执行能否稳定成功。

它最有用的地方，是把「偶尔能做成」和「每次都靠得住」分开衡量。不过，这份短文给出的是评估方法与经验建议，没有展示作者团队的完整实验，也没有展开所提到的八项指标。

原文描述了一个典型风险：Agent 经过三次错误的工具调用，再靠一次碰巧猜对，最终看起来完成了退款工单。如果评估只读最后的回复，这条执行记录很可能被判通过。

但真实系统要检查的是状态。工单是否关闭、记录是否更新，和回复里写了「已处理」是两回事。错误调用还可能已经留下副作用。

因此，作者提出的指标阶梯从结果向执行过程深入，文中具体展开了四项：

最终状态和执行过程，需要一起验收。

原文称完整指南包含八项指标，但当前材料没有列出另外四项，不能替作者补齐。

作者最强调的是 pass@k 与 pass^k 的区别。

按原文的用法，pass@k 关注多次尝试中是否至少能成功一次，用来观察能力；pass^k 关注连续 k 次是否全部成功，用来观察可靠性。

一个单次成功率为 75% 的 Agent，三次全部成功的概率只有约 42%。这个计算隐含每次运行相互独立、成功概率不变的前提。真实任务未必满足这些条件，但它解释了为什么一次漂亮演示不能代表稳定表现。

两项指标应该并排看。pass@k 高、pass^k 低，说明 Agent 有能力完成任务，却经常发挥失常。对于需要人工审核的草稿生成，这可能可以接受；对于会更新记录、触发业务操作的流程，代价就不同了。

LLM-as-a-judge，也就是让大模型担任评分者，可以降低评估成本。但作者指出，未经校准的评分规则，也可能把错误答案评成高分。

建议的起点是：为每套评分规则准备 50–100 个经过人工标注的标准样例，测量模型裁判与人工判断的一致率。如果低于约 75%，先修改评分规则，不要急着修改 Agent。之后每季度重新校准，并像管理代码一样管理规则版本。

这里的一致率衡量的是「裁判是否和人工判断接近」，不能与 Agent 的任务成功率混用。

原文还列出三类裁判偏差：偏爱排在前面的答案、给更长的答案更高分，以及偏爱同一模型家族的回答。对应做法是打乱答案顺序、限制回答长度，并使用不同模型家族担任裁判。不过，当前材料没有提供这些偏差的具体研究出处或实验数据。

测试集也要覆盖失败情形。只有顺利路径，遇到第一条含糊指令就可能失效。作者建议把每次真实失败转为回归测试，让评估逐步接近用户实际遇到的任务。

我认同这篇的优先级：先确认业务状态和工具调用，再谈回复质量。对于会执行操作的 Agent，这比只给最终文本打分更有解释力。

但几个数字需要保留边界。50–100 个标准样例、约 75% 的裁判一致率、每季度校准，都是作者给出的实践建议。文中没有对照数据证明它们适合所有团队，应当把它们当作起点，而非统一验收线。任务风险、人工标注质量和评分规则复杂度，都会影响实际要求。

同样，GAIA、SWE-bench Verified 的榜单只能说明特定条件下的表现。作者提醒，要在同一榜单、相同验证标准下比较，区分自行报告和维护者验证的成绩；单次 #1 只是某个时刻的快照。它不能替代团队自己的业务测试。

原文提到 DeepEval、RAGAS、LangSmith、Braintrust 和 Arize Phoenix，但没有展开选型依据，仅凭这些内容还无法判断该选哪个框架，或何时值得自建。