做 Agent 之后，我逐渐意识到一个问题：我们习惯的评测方式，可能从一开始就用错了。
大多数人接触 AI 评测是从大模型时代开始的——给一道题，出一个答案，打分。但 Agent 不是干这个的。Agent 面对的不是一道题，而是一个开放任务：你要自己规划步骤、决定什么时候查资料、调用哪个工具、判断什么算"搞定"。这跟考试完全是两码事。
所以 Agent 评测的核心问题，不应该是"这道题答对没有"，而应该是："这个活，它干成了没有？"
两个核心区别
我梳理了 Agent 评测和大模型评测之间最根本的差异。
第一，评测对象不同。大模型评测的是"单点能力"——给定输入，输出是否正确。Agent 评测的是"链路能力"——给定目标，能否自主完成从规划到交付的全过程。
第二，失败模式不同。大模型失败，通常就是答案错了。Agent 失败，原因可能出在任何一个环节：规划本身就偏了、工具调用传错参数、中途遇到异常不知道怎么恢复、甚至最后结果对了但绕了太多弯路导致成本爆炸。
这意味着，只看最终答案正确率，会严重低估 Agent 实际存在的问题。
评测五维度
基于上面这些认知，我把 Agent 评测拆成五个维度来看。前三个更偏结果质量，后两个更偏过程质量。
任务完成率：最基础也最直观的指标。Agent 最终有没有交付用户预期的结果？能完整跑通的 case 占比多少？如果这个指标不好看，别的都先别聊。
步骤完整性：任务完成了，但它是跳步骤完成的吗？还是老老实实执行了所有必要子步骤？有些 case 最终结果碰巧对了，但中间跳过了关键验证环节，这种假性成功在真实业务里很危险。
关键决策准确率：整个任务链里，真正需要模型做判断的关键节点就那么几个。这些节点上有没有出现幻觉？工具选择对不对？参数有没有乱编？把这些节点单独拎出来看，比笼统地看回答质量更有诊断价值。
效率指标：调用次数、端到端耗时、Token 消耗。一个任务能完成，但绕了远路，成本是最优路径的几倍，这在规模化场景下不能接受。
可解释性：Agent 的决策路径能不能被追溯？出问题时能不能快速定位到具体环节？这个维度在初期常常被忽略，但一旦进入持续迭代阶段，没有可解释性就等于盲飞。
分层评测体系
单个指标只能看一个切面，我习惯用分层的方式把指标体系组织起来。
第一层：北极星指标。回答"这个 Agent 到底有没有用"，必须和业务目标直接挂钩。比如做选品类 Agent，我更关注运营采纳率——推荐的结果有多少被真正采用了。
第二层：能力分解指标。回答"能力强弱在哪里"。把核心能力拆成几个可独立衡量的模块：检索质量、决策准确率、工具调用成功率。每个模块有各自的基线。
第三层：可解释性指标。回答"出问题了能不能定位"。决策链路是否清晰可追溯，bad case 能不能快速定位到具体环节。这一层未必是数字，更多是流程上的完备性。
几个容易被忽略的问题
一是工具调用失败率。很多人只盯着回答质量看，忽略了 API 超时、权限问题、参数格式错误。这些问题往往不会体现在最终答案里——Agent 静默失败后换了路径完成任务，但成本被拉高了。
二是评测环境和生产环境的不一致。本地一切正常，上了生产各种问题就冒出来。反爬策略、接口限流、数据格式的细微变化，只有生产环境才能暴露。
三是 bad case 闭环。没有机制把每次翻车的 case 记录下来、归类、回测，同样的错误就会反复出现。评测不是一次性动作，而是一个持续运转的反馈系统。
这些梳理下来，我认为：评测 Agent，评的是它干活的能力，不是它考试的能力。把这个问题想清楚，指标体系怎么搭、评测流程怎么设计，方向就明确了。
---
我在闲鱼 AI Agent 导购项目里验证过这套框架。搭建的五维度评测体系，配合三层闭环——自动化评测跑回归、人工抽样盲评发现漏网之鱼、用户反馈反哺模型迭代——让不良回复率降了 12%，高频问题应答覆盖率到了 95%。