agent-evaluation-benchmark-production
Benchmark 高分不等于生产可靠。Agent 评估不能只看准确率，需要从离线 benchmark、回归场景、在线灰度三层搭建评估体系——这是从 demo 到生产的分水岭。
上周帮朋友排查一个多 Agent 系统。他一脸困惑地给我看两组数据：
SWE-bench 上 78% pass@1，Terminal-Bench 跑分也在及格线以上。"所有 benchmark 都过了，但上线第一天就在一个退款场景上循环了 20 多轮 tool call，退了接近两块钱的 API 费，最后还把订单状态搞错了。"
这不是个例。我聊过的团队，十有八九都经历过类似的"benchmark 全绿，上线就崩"。
问题出在哪儿？不是模型不行，是压根没搞清楚该测什么。
Benchmark 和生产的鸿沟
先想一个问题：SWE-bench 测的是什么？从真实 GitHub issue 出发，生成代码 patch，跑 Docker 验证。它测的是"在给定问题描述下，能不能产出正确的代码修改"。
这很严格。但它测不到什么？
测不到你的 Agent 在 20 步之后会不会忘记初始目标。测不到工具调用失败时它怎么恢复。测不到它做退款操作之前有没有先校验订单权限。测不到它会不会在某个分支上无限循环。
Benchmark 的设定是窄的、受控的、单次通过的。生产流量的特征是宽的、无序的、多步分叉的。这两个分布本身就不同——不是你的 Agent 跑分不够高，是 benchmark 的考核范围和生产级的失效模式压根不是同一个集合。
我越来越觉得，把 benchmark 分数当作上生产的标准，就跟用高考成绩判断一个人能不能当好项目经理一样——不是完全无关，但远远不够。
三层评估，少一层都是裸奔
真正靠谱的生产评估体系有三层，每一层抓一类不同的错误。
第一层：离线 Benchmark 门禁（每日跑）
这是最基础的一层，主要目的是发现能力回退。
每次换模型、改 prompt、加工具时跑一遍完整的 benchmark portfolio：
- SWE-bench（代码修复）
- Terminal-Bench（终端自主操作）
- OSWorld（GUI 操作）
- Tau-bench（工具调用策略）
每个 benchmark 都有侧重点，只跑一个会产生结构性盲区。我见过一个团队只盯着 SWE-bench 的分数涨了 5%，开心地部署上去，结果工具选择准确率掉了一大截——因为新模型在代码生成上变强了，但判断"该不该调这个 API"的能力变弱了。光看总分根本看不出来。
硬规则：任何一个 benchmark 低于底线，就算总分涨了也阻止上线。这条规则可能救过我的次数，一只手已经数不过来了。
第二层：回归场景门禁（预发布跑）
Benchmark 是通用能力测试，但你自己的业务场景才真正决定成败。
这一层需要积累一套私有回归测试集。典型的结构是：
# minimal structure
eval_suite = [
{
"input": "用户要求退款订单 12345",
"expected_tools": ["verify_order", "check_refund_policy", "process_refund"],
"must_not_call": ["delete_order", "modify_inventory"],
"expected_output": "退款已发起",
},
# ... 持续积累线上失败案例
]
注意这里不仅要测"最终结果对不对"，还要测路径对不对。
我有过一个血的教训：一个 Agent 在处理退款时，绕过了订单校验直接调了退款 API，恰好那次输入碰上了合法订单，最终结果是正确的。但问题在于——这次是碰对了，下次呢？只看最终输出的话，这个 bug 永远抓不到。所以必须把期望的工具调用序列也写进断言。
还有一个简单但极高 ROI 的字段：must_not_call。列清楚你的 Agent 绝对不能碰哪些操作。这是防止生产事故最便宜的保险。
第三层：在线灰度门禁（渐进放量）
离线测试跑得再好，上了生产也可能会崩。原因是——你永远无法在离线环境里完全模拟真实流量分布。
推荐三阶段：
- Shadow 模式（1-3 天）：Agent 跑在真实流量上，但它的输出不生效。只看它"打算怎么做"，跟人肉的答案对比。
- 金丝雀 1-5%（1-2 天）：小流量上线，监控成功率和干预率。重点看有没有异常的工具调用模式——连续 5 次无进展的 tool call 循环、异常高的 token 消耗、被频繁拒绝的 API 调用。
- A/B 测试（50/50 分流）：跑一段时间，等数据显著后再全量。
每道门的硬性指标：
- 任务成功率 >= 基线 + 2%
- 人工干预率 <= 基线 + 0.5%
- P95 延迟 <= 基线 + 10%
- 单次任务成本 <= 基线 + 10%
- 策略违规率 = 0
这里特别说一下"人工干预率"。很多团队只看成功率，觉得从 85% 涨到 87% 就是进步。但如果那 2% 的涨幅是靠"需要人工介入的案例也变多了"换来的，那实际上是在用运维人力换准确率。长期不可持续。
哪些指标真正有用
我见过太多团队把 Agent 评估复杂化成一张 30 个指标的 Excel 表。然后谁也说不清哪个指标最重要。
说实话，生产中最有用的指标不超过 6 个：
| 指标 | 说明 | 为什么重要 |
|---|---|---|
| 任务成功率 | 核心质量 | 没这个其他都别谈 |
| 人工干预率 | 运营安全 | 成功率涨但需要更多人来兜底 = 倒退 |
| P95 端到端延迟 | 用户体验 | Agent 慢不一定是模型慢，可能是循环了 |
| 单次成功成本 | 经济可行性 | 效果好但太贵的话也是白搭 |
| 策略违规率 | 合规/安全 | 应当 0%，有任何一次都要停 |
| 工具失败率 | 集成可靠性 | 工具调不通，再聪明的规划也白费 |
不要只靠"分数"做决策。一个分数涨了但人工干预率翻倍的版本，大概率是个倒退。
LLM-as-Judge 的校准陷阱
说到自动评估就绕不开用 LLM 当裁判。
这个方法有用，但有个大坑：LLM 评委有自己的偏好。有些模型对长篇回答天然给高分，有些对自谦的语气更友好，有些在自己擅长的领域（比如代码）判断很准，但放到客服场景就乱打分了。
怎么解决？校准。
定期拿一小批人工标注的样本，算 LLM 评委打分和人工打分的 Spearman 相关性。如果相关性掉到 0.7 以下，要么换裁判模型，要么重写评分 rubric。
还有个小技巧：优先用 pairwise 比较而不是点状打分。"回答 A 比回答 B 好多少"比"回答 A 打 7 分"要稳定得多。人类做相对判断本来就比绝对判断可靠，LLM 也是。
一些绕不开的脏活
最后说几个我深有体会的反模式：
"MVP 上线了再加评估"。这是最常见的坑。等系统跑起来了，再回去加评估体系，改造成本是 4-6 周。因为你需要回溯日志、重构 trace 结构、对齐数据格式。而这段时间里很可能已经出了一次生产事故。
"分数够了就上线"。分数只是过滤条件，不是上线理由。你需要考量的是完整画像：质量、成本、延迟、安全性、运营负担。
"没有自动回滚"。灰度放量不带自动回滚，等于手动挡开飞机。策略违规率超过阈值就自动切回旧版本，这一点应该在第一天就配置好——不是因为信不过新版本，而是因为半夜被叫醒 debug 的感觉真的不好。
为什么这件事值得做
说实话，搭建评估体系很枯燥。没有新功能发布时的成就感，没有炫酷 demo 的冲击力。但它有一个无可替代的价值：让你敢改代码。
没有评估基础设施的 Agent 项目，每次模型升级、prompt 调优、工具变更都是一次祈祷。有了它，每次变更都变成一次可审计、可回滚、可度量的工程操作。
模型是商品，评估才是护城河——这句话我过往半年才真正读懂。
评论
发表评论