团队里最常听到的一句话是：这个 Agent 做得差不多了，感觉还行。问题就出在「感觉」两个字上。传统软件能跑单元测试、能看覆盖率，可 Agent 的输出是自然语言，没有标准答案，怎么判断它到底好不好用？评测（eval）就是干这个的——把「感觉还行」换成「有数据支撑」。
这篇把 Agent 评测的完整方法捋一遍：任务集怎么建、指标怎么选、回归测试怎么跑、上线后怎么盯。
为什么 Agent 评测比普通软件难
普通软件有明确的输入输出，跑一遍测试就知道对错。Agent 不一样：同一个任务，它可能这次答得好、下次答得差；输出的是自然语言，好坏有主观成分；任务本身还常常是多步的，中间哪一步错了都影响最终结果。所以评测 Agent 不能用「对/错」一刀切，得建立一套自己的判断标准。
第一步：先建评测任务集
评测的地基是一批有代表性的任务。任务集怎么来？两条路：一是从真实业务里捞，把团队最近一个月遇到的真实问题整理成题库，这类最有代表性；二是从上线后遇到的翻车案例里挑，把这些「历史黑历史」固定下来，确保以后不重犯。任务集要覆盖常见场景、边界场景和容易翻车的场景，不能只挑好答的。
任务集建好之后要持续维护。每次 Agent 上线后遇到新问题，就把新案例补进去，让它越来越厚。这跟站里讲的变更后验证清单是配套的——改一次代码，跑一遍完整任务集。
第二步：选对指标，别只看一个数
评测指标不能只看「答对率」。Agent 评测通常要分层看：任务完成率（有没有把事情办成）、答案质量（对不对、全不全）、过程正确性（中间步骤有没有乱来）。有的任务答案对但过程错，有的过程对但最终没办成，所以要分开看。
还有一类容易被忽略的指标：稳定性和成本。同一个任务跑 10 遍，结果波动大不大？调用一次要花多少 token、多少时间？一个「好用但贵得离谱」或者「时好时坏」的 Agent，同样不能上生产。把指标定清楚，才能知道每一轮优化是进步还是退步。
第三步：回归测试防倒退
Agent 最大的坑之一，是「改了一处，坏了一片」。今天优化了工具调用的逻辑，明天发现它反而在另一个场景翻车了。所以评测不是上线前跑一次就完，而是要固化成回归测试——每次改动都自动跑一遍完整任务集，对比改前改后的分数。
回归测试要能自动出报告，哪些任务变好了、哪些变差了、整体是升是降，一目了然。如果某个指标明显下滑，就别急着上线，先定位原因。这套「改动必回归」的纪律，本质上就是质量门禁在 Agent 上的落地。
第四步：线上监控，别评测完就撒手
评测集再全，也覆盖不了线上的真实情况。Agent 上线后，还得持续盯线上的表现：用户的真实提问有没有超出任务集的范围？翻车率有没有异常波动？这些信号要能及时反馈回评测集，形成闭环。
具体做法是保留每次运行的完整记录，做到可回放、可对照。出了事能回到当时那一步看它到底怎么想的，而不是事后猜。这一点对应回放对照和证据包的思路。对于高风险场景，还可以加一道人工复核抽检，抽样核对 Agent 的结论。
适合人群与代价
评测这套方法，适合那些要把 Agent 真正推到生产、并且在乎稳定性的团队。如果只是内部随便用用，花大力气建任务集确实有点重；但一旦 Agent 要对外服务、要替团队办事，评测就是绕不过去的一关。代价是要投入人力维护任务集和跑回归，但换来的是「每次改动都有据可查、可回退」的底气。
总结
Agent 评测不难，难的是坚持：先建一批有代表性的任务集，再选对分层指标，改一次跑一遍回归，上线后持续监控反馈。把这四步走通，「感觉还行」就变成了「数据说话」。Agent 不是玄学，是能像软件一样被认真对待和验收的。
0 条评论