你有没有遇到过这种情况——

上线了一个 AI Agent，测试时跑得好好的，上线后用户一顿吐槽。

你回去看评测分数，90 多分。再看用户的真实反馈，完全是两回事。

分数很高，但说明不了任何问题。

这不是你的 Agent 不行，是你的评测体系没搭对。

AI Agent 的评测，跟传统软件测试完全不是一个逻辑。传统测试是"输入 A 一定得到 B"，Agent 的输出是非确定的、多步骤的、跟环境交互的——你没法用断言一刀切。

那评测体系到底怎么搭？

我把它拆成五个环节：目标定义 → 数据集构建 → 打分机制 → 失败分析 → 生产闭环。

一个一个说。

一、目标定义：先想清楚"评什么"和"为什么评"

很多团队搭起了评测框架，跑出一个分数，却发现分数和产品质量的相关性很低。问题几乎都出在最前面：评测目标不明确。

最基本的区分：

• 测模型：选型时做的事，用通用 benchmark，回答"这个模型够不够强"
• 测产品：测你的整个系统（prompt + 检索 + 工具调用），回答"能不能完成具体业务任务"

模型在通用榜上跑分很高，不代表它在你的场景里表现好。

还要想清楚为什么测：

目的	特点	要求
迭代	快速反馈	可以粗糙
上线准入	高置信度	要设明确门槛
生产监测	轻量可持续	不能太重

一套体系试图同时满足这几个目标，往往哪个都做不好。

二、数据集构建：真实失败 > 手工构造 > 合成数据

测试数据的三个来源，按质量排序：

来源	质量	说明
真实失败记录	⭐⭐⭐	每天用产品时遇到的问题，质量最高
手工构造	⭐⭐	针对关键行为一条条写，覆盖你最在意的场景
合成数据	⭐	用模型从真实样例扩写，量大但质量一般

大多数团队跳过前两步，直接用合成数据或公开 benchmark。公开 benchmark 测的是通用能力，不是你的产品，照搬过来的分数没有意义。

测试用例要按能力打标签（比如"多轮对话"、“工具调用”、“检索”），不按来源分类。这样分析时能快速定位是哪个能力出了问题。

三、打分机制：能用代码判的用代码

打分有三种手段，选择有明确的优先级：

能用代码判的用代码，代码判不了的用模型，最后才上人工。

手段	适用场景	优势	局限
代码打分	格式正确性、关键词出现、JSON 解析、数据库状态检查	快、便宜、可重复	只能判确定性结果
模型打分	语气是否合适、信息是否完整、有没有误导用户	可规模化	有偏见风险、可靠性存疑
人工打分	黄金标准	最可靠	贵且慢

有一条关键原则：每个质量维度用一个独立的评估器，不要把多个维度揉成一个总分。

举个例子：一个客服 AI 的"好回答"要同时做到准确、有温度、不啰嗦、符合公司规定。把这四件事加权成一个分数，你永远不知道分数变化是哪个维度驱动的。分开打，才能定位问题。

四、失败分析：读 transcript 比看分数重要

分数告诉你哪里不对，transcript 才告诉你为什么。

一个场景通过率低，原因可能是 prompt 问题、检索召回错误、工具调用顺序乱了。这些完全不同的问题，分数看起来一样。只有读真实的对话记录，才能找到根本原因。

可能有人会问：transcript 到底是什么？

transcript 指的是 Agent 一次任务从头到尾的完整执行记录——它每一步想了什么、调了什么工具、拿到了什么结果、怎么决定的下一步，全记下来的那份"日志"。

打个比方：

用户说：帮我查一下订单 #1234 的状态
↓
Agent 思考：需要调用订单查询接口
↓
Agent 调用工具：query_order("1234")
↓
工具返回：{"status": "shipped", "items": [...]}
↓
Agent 思考：订单已发货，可以告诉用户了
↓
Agent 回复：您的订单已发货，预计...

这一整条链路，就是 transcript。它是 Agent “干活的完整过程”，不只是最后那句回复。

实操建议：

1. 每次做重大改动，花 30 分钟手动看 20-50 条输出
2. 边看边记哪里不对，不用急着归类
3. 读到新的输出不再带来新的失败模式，再归纳类型
4. 针对真实失败写 eval，不要凭空想象可能出什么问题

还有一条经验法则：如果某个场景通过率是 0%，先不要怀疑系统，几乎可以确定是评测本身出了问题。

五、生产闭环：评测的终点不是报告

你跑完一轮离线评测，出了分数，发了报告，然后呢？

然后上线，然后你一定会遇到离线评测里没想到的问题。

这不是你水平不行，是离线评测的天然局限——你只能测到你提前想到的东西。用户会怎么用、会问什么奇怪的问题、会在什么意想不到的场景下翻车——这些你提前猜不全。

所以评测不能止步于离线报告。它得跟生产环境接上，形成一个转不停的轮子。

这个轮子怎么转？说穿了就四步：

1. 线上抓：用户在真实使用中遇到的失败，你得能看到——点赞点踩、投诉、对话突然中断、任务完成率掉下来
2. 攒下来：把那些有代表性的失败 case 捞出来，扔进你的测试集
3. 跑评测：下一轮迭代，用更新后的测试集来评，看这些问题修没修好
4. 再上线：改完 → 评测通过 → 上线 → 又发现新的失败 → 回到第一步

这个轮子转起来，你的评测体系才算真正活了。

其中最容易被忽略的是第一步——线上抓。很多团队上线之后就不管了，等用户投诉了才知道出问题。其实你需要两类"探头"挂在线上：

• 用户信号：点赞点踩、投诉、会话中途放弃
• 自动巡检：不需要标准答案，拿一小部分实时流量自动跑评估，确认线上表现和上线前没有明显掉档

最后一条实操经验：不是每个线上问题都值得建专门的评估器。 改一次就好的，直接修。但如果同一类问题反复冒出来，那就该把它沉淀成一条常驻评估规则——下次再出现，在你发现之前，评测就先替你拦住了。

几条实操踩坑经验

最后，把我踩过的坑和看到的规律，浓缩成几条建议：

① 不要上来就搭大而全的评测平台。

早期靠手测和直觉能走很远。通常的临界点是：系统开始放量、用户反馈"改完之后变差了"、团队开始不知道改了有没有变好。没到这个点，先把产品做出来。

② 真实失败是最好的测试数据。

从真实使用中攒几十条失败 case，比凑 1000 条合成数据更有价值。

③ 同一个任务多跑几次。

Agent 的非确定性意味着，"跑了一次通过了"几乎没有统计意义。至少跑 5-10 次，看通过率，而不是单次结果。

④ 评的是系统，不是模型。

同一个模型，harness 不同，成绩差出几十个点。评测报告必须记清楚用的是哪套 harness。

⑤ 分数不等于质量。

如果分数和产品质量的相关性很低，问题几乎都出在最前面——评测目标不明确，跑出来的分数根本没有拟合你真正想要的效果。

⑥ 评测和训练正在变成同一件事。

如果你涉及模型训练或微调，一个设计足够好的评估器本质上就是一个奖励函数。你为评测写的 rubric 和 grader，可以直接用来驱动下一个模型版本的训练方向。

写在最后

总结一下，搭 AI Agent 评测体系，核心就一句话：别追求完美，追求"转得起来"。

很多人卡在"搭一个完美的评测平台"上，迟迟不动手。但评测体系的真正价值，不在于第一版多完善——而在于那个"线上抓 → 攒数据 → 跑评测 → 再上线"的轮子，有没有转起来。

轮子转起来了，哪怕第一版粗糙，它也会自己越磨越好。

轮子没转起来，再漂亮的评测报告，也只是一张静态的照片。

评测不是终点，它仅仅只是起点。