智能体行为评测
上线前建立可用的评分体系——评测集、打分器，以及「用代码还是用模型」的取舍。
为什么「感觉还行」靠不住
「我看了几条输出，挺好」这套判断，扛不住模型更新、提示词微调或流量高峰。没有打分器，你就分不清这是改进还是退化，每次改动都变成赌博。
一套可用的评测包含三部分：用例集、打分器、基线分数。
先用 20 条真实用例，而不是 200 条合成数据
最常见的错误是在还没有任何真实使用时就生成大批合成数据。合成集编码的是「你以为用户会怎么用」，而这通常与实际不符。
应该从现实里收集：
- 你记得的真实失败交互
- 用户实际敲进去的别扭输入
- 曾经搞崩过什么东西的边界情况
- 「正确答案」本身就存在争议的用例
20 条真实用例胜过 200 条想象出来的。等真实流量告诉你还缺什么，再扩充。
选能用判断的最便宜打分器
按被测量的东西匹配打分器，别一上来就用模型：
| 要检查什么 | 打分器 | 理由 |
|---|---|---|
| 格式是否正确 / JSON 合法 | 代码 | 确定性、零成本、瞬时 |
| 是否包含必需引用 | 代码（正则） | 无需判断力 |
| 数值是否在容差内 | 代码 | 比 LLM 更便宜也更严格 |
| 语气、清晰度、完整性 | 模型（评分细则） | 需要判断力 |
| 方案本身是否靠谱 | 模型 + 人工抽查 | 后果太重，不宜全自动 |
今天就能挡住 80% 故障的代码打分器，比下个月还在调的模型打分器更有价值。
写出前后一致的评分细则
模型打分会漂移，要加约束：
- 每个维度单独打分（正确性、完整性、语气），而不是给一个总分
- 用 1–5 分且每一档都用文字定义，不能只定义两端
- 要求打分器引用支撑该分数的原文片段
- 同一用例打 3 次；若分差超过 1 分，说明细则有歧义
最后这条检查团队最常跳过，也正因如此他们的评测结果无法复现。
怎么看数据
跨版本跟踪这些：
- 通过率——在基准集上的主指标
- 退化清单——过去能过、现在挂掉的用例（最有行动价值的产物）
- 打分器分歧率——这里飙升说明是细则坏了，不是智能体坏了
通过率下降时，先看退化清单再动手。通常两三个具体失败就能解释全部差异。
一点提醒
评测衡量的是你的基准集，不是你的产品。用户行为一旦变化就要重审用例集——过时的评测集会自信地放行它早已不再覆盖的退化。