你有没有遇到过这种情况——
上线了一个 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 "干活的完整过程"，不只是最后那句回复。
实操建议：
- 每次做重大改动，花 30 分钟手动看 20-50 条输出
- 边看边记哪里不对，不用急着归类
- 读到新的输出不再带来新的失败模式，再归纳类型
- 针对真实失败写 eval，不要凭空想象可能出什么问题
还有一条经验法则：如果某个场景通过率是 0%，先不要怀疑系统，几乎可以确定是评测本身出了问题。
五、生产闭环：评测的终点不是报告
你跑完一轮离线评测，出了分数，发了报告，然后呢？
然后上线，然后你一定会遇到离线评测里没想到的问题。
这不是你水平不行，是离线评测的天然局限——你只能测到你提前想到的东西。用户会怎么用、会问什么奇怪的问题、会在什么意想不到的场景下翻车——这些你提前猜不全。
所以评测不能止步于离线报告。它得跟生产环境接上，形成一个转不停的轮子。
这个轮子怎么转？说穿了就四步：
- 线上抓：用户在真实使用中遇到的失败，你得能看到——点赞点踩、投诉、对话突然中断、任务完成率掉下来
- 攒下来：把那些有代表性的失败 case 捞出来，扔进你的测试集
- 跑评测：下一轮迭代，用更新后的测试集来评，看这些问题修没修好
- 再上线：改完 → 评测通过 → 上线 → 又发现新的失败 → 回到第一步
这个轮子转起来，你的评测体系才算真正活了。
其中最容易被忽略的是第一步——线上抓。很多团队上线之后就不管了，等用户投诉了才知道出问题。其实你需要两类"探头"挂在线上：
- 用户信号：点赞点踩、投诉、会话中途放弃
- 自动巡检：不需要标准答案，拿一小部分实时流量自动跑评估，确认线上表现和上线前没有明显掉档
最后一条实操经验：不是每个线上问题都值得建专门的评估器。 改一次就好的，直接修。但如果同一类问题反复冒出来，那就该把它沉淀成一条常驻评估规则——下次再出现，在你发现之前，评测就先替你拦住了。
几条实操踩坑经验
最后，把我踩过的坑和看到的规律，浓缩成几条建议：
① 不要上来就搭大而全的评测平台。
早期靠手测和直觉能走很远。通常的临界点是：系统开始放量、用户反馈"改完之后变差了"、团队开始不知道改了有没有变好。没到这个点，先把产品做出来。
② 真实失败是最好的测试数据。
从真实使用中攒几十条失败 case，比凑 1000 条合成数据更有价值。
③ 同一个任务多跑几次。
Agent 的非确定性意味着，"跑了一次通过了"几乎没有统计意义。至少跑 5-10 次，看通过率，而不是单次结果。
④ 评的是系统，不是模型。
同一个模型，harness 不同，成绩差出几十个点。评测报告必须记清楚用的是哪套 harness。
⑤ 分数不等于质量。
如果分数和产品质量的相关性很低，问题几乎都出在最前面——评测目标不明确，跑出来的分数根本没有拟合你真正想要的效果。
⑥ 评测和训练正在变成同一件事。
如果你涉及模型训练或微调，一个设计足够好的评估器本质上就是一个奖励函数。你为评测写的 rubric 和 grader，可以直接用来驱动下一个模型版本的训练方向。
写在最后
总结一下，搭 AI Agent 评测体系，核心就一句话：别追求完美，追求"转得起来"。
很多人卡在"搭一个完美的评测平台"上，迟迟不动手。但评测体系的真正价值，不在于第一版多完善——而在于那个"线上抓 → 攒数据 → 跑评测 → 再上线"的轮子，有没有转起来。
轮子转起来了，哪怕第一版粗糙，它也会自己越磨越好。
轮子没转起来，再漂亮的评测报告，也只是一张静态的照片。
评测不是终点，它仅仅只是起点。
