19 · 评测 Evals

没有评测的 Agent 不叫产品

📚 系列导航：这是《Agent 开发进阶》的第 19 篇（共 24 篇）。上一篇多 agent 团队跑起来了，也留下"感觉更好了"的隐患；这一篇进生产化第一课——评测，把感觉换成数据，可观测、安全、优化全建在这块砖上。下一篇：20 · 可观测性。

改一版 prompt，跑两个顺手的例子，"嗯，变好了"，上线。我以前就这么干，直到一次"优化"上线一周后才发现：那两个例子确实变好了，另外三类高频问题全被我改崩了。"感觉变好了"是 agent 开发里最贵的错觉——没有评测，每次迭代都是在赌。这一篇只干一件事：帮你把第一套评测跑起来——三层指标、30 条评测集、一份基线报告。

看完这一篇，你会拿到：

• 三层评测框架：单元/轨迹/端到端各出哪个数
• 从真实 badcase 长出评测集的方法和条目模板
• LLM 裁判校准流程：对齐率怎么算、多少能上岗
• 你自己 agent 的首份基线报告（30 条跑出来）

---

01 三层评测：只看结果会漏大事

好比批改数学卷子：端到端看总分（任务成功率），单元层看每道题（单次工具调用：该调的调了吗、参数对吗），轨迹层看解题过程（答案对，但绕了三页草稿纸也要扣分——步数、绕路、成本）。只看总分会漏大事：一次模型升级后成功率没动、成本却翻了 3 倍——轨迹变啰嗦了，端到端完全无感，只有轨迹指标能抓到。落地就是各盯一个数：工具调用正确率、平均步数与单任务成本、端到端成功率。

💡 一句话总结：成功率、平均步数、单任务成本三个数一起看——只盯成功率，等于只看总分不看解题过程。

02 评测集从真实 badcase 长出来

拍脑袋编 30 个测试问题，编出来的都是你想得到的情况——而线上恰恰翻在你想不到的地方。正确的长法：每一条评测都来自一次真实翻车。用户投诉、抽检发现的错误、你自己被惊到的回答，统统收进来。条目模板：

id: bc-017
input: "查上周退款订单并汇总金额"
expect_tools: [query_orders]
expect: 总金额与库内一致，含订单数
source: 2026-06 线上 badcase

上线前 30 条起步，之后每月用新 badcase 补充。一年不更新的评测集早已不代表真实流量分布——这个亏我吃过。

💡 一句话总结：评测集是从生产事故里长出来的，不是从会议室里编出来的——30 条起步，每月喂新 badcase。

03 LLM 裁判：能规模化，但要先校准

30 条人工看得过来，300 条就得靠 LLM-as-judge：给裁判模型评分标准，批量打分。但裁判上岗前要校准：抽 30–50 条让人工和裁判各打一遍，算对齐率。我的经验线：90% 以上放心用；80% 以下说明评分标准含糊，先改标准再校准一轮。另一条纪律：裁判换一家模型——同款当裁判等于自己给自己打分，会系统性偏高。校准通过后每月仍要人工抽检，防裁判漂移。

💡 一句话总结：裁判先跟人对齐再上岗、换家模型防自夸、定期抽检防漂移——三条做到，规模化评测才可信。

04 回归习惯：改 prompt 必跑评测

评测集建好后，把一个动作练成肌肉记忆：任何改动——prompt、工具描述、模型版本——合入前必跑全量评测，和基线比对。prompt 改动的影响是全局的：你以为只优化了退款场景的话术，可能顺手改崩了查询场景的工具选择。跑一轮 30 条不过几分钟，换来的是每次迭代都有前后数据背书。基线报告存档：日期、改动、三层指标——三个月后回看，能画出你 agent 的质量曲线。

💡 一句话总结：没有回归的迭代是随机游走——改动必跑评测，让每一次变更都有前后数据。

05 动手：30 条评测集 + 首份基线报告

任务：给你的 agent 收集 30 条评测条目（历史 badcase 优先，不够就构造边界情况凑齐），按 02 的模板写成文件；写跑批脚本逐条执行、按三层记指标，产出首份基线报告。

验收标准：一份带日期的基线报告，三层指标齐全，能指出最弱的一层和最典型的 3 个失败条目。

两种结果都正常：成功率比想象低（比如 60%）——别沮丧，这是多数人的第一次真实体检，你终于知道差距在哪；成功率很高（90%+）——警惕评测集太软，往里加更难的边界 case 再跑一轮。

06 小结

你现在应该能：说清三层评测、从 badcase 长出评测集、校准 LLM 裁判、养成改动必回归的习惯，并拿到首份基线报告。

下一篇 20 · 可观测性：评测告诉你"哪里错了"，tracing 告诉你"为什么错"——给 agent 的每一步装上眼睛。

---

📎 实战案例

一个团队只测端到端成功率，一次模型升级后成功率没变、成本却翻了 3 倍——轨迹变啰嗦，平均步数从 4 步涨到 11 步。把轨迹指标（步数/成本）纳入评测、评测集每月从真实 badcase 补充后，这类隐藏退化在合入前就能被拦下。

踩坑

• 我的评测集半年没更新，线上问题类型早换了一茬，评测全绿、投诉照涨——评测集是活的，每月喂 badcase。
• 只测成功率不测轨迹，成本悄悄翻了 3 倍才在账单上发现——平均步数和单任务成本必须进看板。
• 我用同款模型当裁判，打分普遍虚高，与人工对齐率只有 70% 出头——换家模型、先校准再上岗，对齐率过 90% 才放量。