Agent评测为什么总是自我感觉良好：从「答对」到「没做坏事」的三层评测

高分Agent，线上翻车

如果你做Agent评测，大概经历过这个循环：内部评测集90分，上线后用户投诉不断；回头看case，发现”答对了”，但代价是调用了7次工具、花了40秒、顺手改了两条不该改的记录。

问题不在模型，在评测的定义。大多数团队只评估”最终答案对不对”，而Agent的能力边界恰恰在过程与代价里。

三层评测框架

第一层：结果层——答对了吗

最基础的一层，但要点做扎实：

• 用例来源：从真实日志采样（含失败case），而不是自己编。自编用例天然偏向模型擅长的类型。
• 判定方式：能用确定性断言就别用LLM裁判。字段值、SQL结果、API返回、文件内容——这些都能精确比对。
• 必须包含”应该拒绝”的用例：越权请求、事实不存在的请求、需要人工介入的请求。只测”能做对什么”，等于没测边界。

这一层的常见错误是：用例只覆盖happy path，且判定标准宽松到”意思差不多就算对”，导致分数虚高。

第二层：过程层——怎么做到的

Agent与传统调用的最大区别是多步决策，所以必须评估轨迹：

• 工具选择正确性：该用查询却用了写入？该查文档却凭记忆回答？
• 步数效率：同样任务，最优路径3步，它走了9步——成本直接翻三倍
• 错误恢复：第一次工具失败后，它重试、换方案还是编造结果？后者是最危险的模式
• 约束遵守：有没有触碰权限边界、有没有在只读场景执行写操作

实现方式：为每个用例写”轨迹断言”，例如”必须调用search且不得调用delete”、“最多5次工具调用”。这类断言便宜、稳定、可解释，比LLM裁判可靠得多。

第三层：代价层——付出多少

• token成本分布（看P90而非均值）
• 端到端延迟（用户感知的是等待，不是生成速度）
• 人工介入率（转人工比例才是真实自动化率）
• 副作用（写入了什么、通知了谁、产生了多少下游工单）

一个Agent如果准确率95%、但每天误发20封邮件，它在业务上是负资产。代价层就是用来发现这种”技术上正确、业务上错误”的情况。

用例设计：最小可用的组合

不需要上千条，起步100条左右，按这个配比：

类型	占比	目的
典型任务	40%	基线能力
边界/模糊输入	20%	是否乱猜
应拒绝任务	15%	安全边界
工具故障模拟	10%	错误恢复
长尾真实case	15%	覆盖真实复杂度

每条用例至少带一个结果断言；过程类用例再加1-2条轨迹断言。

评测节奏

• 每次提示词/模型/工具变更：跑全量（100条，成本可控）
• 每周：从线上日志新增10条真实case，替换掉已饱和的老用例
• 每次大版本：人工抽检20条轨迹，校准自动断言是否”过松”

三个立刻能改的点

1. 把”应该是拒绝”的用例加进去——多数团队的评测集里一条都没有
2. 给每个用例加轨迹断言，成本极低，能抓到大部分隐性错误
3. 报告里同时给准确率、平均步数、P90延迟，三个数一起看才有意义

评测不是为了证明Agent行，而是为了在它不行的时候，先于用户知道。