Agent 评测别只看分数，先想清楚它怎么进生产
本文由本站基于公开热点摘要整理和原创分析生成，原文来源：美团技术团队《Agent评测漫谈 —— 由浅入深讲解Agent评测》。
这篇美团技术团队的文章，公开摘要里说的是 Agent 评测：什么是评测，怎么建评测体系，以及他们在业务团队里做 BP 时攒下来的实践认知。基于公开摘要可见，它不是单纯晒模型能力，而是把话题拉回到“怎么知道一个 Agent 靠不靠谱”。这点我挺认同。现在很多 Agent Demo 看起来很顺，真要接到线上流程，麻烦通常不在第一次回答，而在第二步、第三步，以及某个工具超时之后它开始自作主张。
先别急着看榜单分数
做业务系统的人应该都熟悉这种感觉：压测报告很好看，上线第一天还是会被一个边角流量打穿。Agent 评测也类似。一个总分能给老板看，却很难告诉值班同学凌晨两点该怎么处理。它到底是不会规划，还是工具参数填错了？是模型理解偏了，还是下游接口返回太慢？如果评测只给“通过/失败”，工程上基本没法用。
我更关心的是错误能不能被拆开。比如任务理解、工具选择、参数生成、权限校验、结果校验、异常恢复，最好都能单独看。这样评测才像日志和指标，而不是一次考试成绩。业务里真正要命的失败往往很小：查错用户、重复提交工单、把测试环境的结论带到生产建议里。它们不一定显得“智能不足”，但足够让团队不敢放权。
评测要贴着真实链路长出来
Agent 和普通问答不一样，它会调用工具，会读上下文，会把前一步的输出当成后一步的输入。链路一长，错误就会滚雪球。放到实际项目里，我会先问几个不太浪漫的问题：它能不能拿到最小权限？工具调用有没有审计？失败后能不能停下来等人确认？重试会不会把外部接口刷爆？这些问题看起来不像 AI 能力，却决定它能不能进生产。
还有成本。Agent 评测不能只测“答得对不对”，还得看一次任务要跑多少轮、调多少工具、烧多少 token。小团队最怕的不是新技术不会用，而是看似省了人力，最后把复杂度塞进一堆没人维护的 prompt、脚本和临时权限里。出了问题，业务同学说 Agent 做的，开发说模型不稳定，平台同学说调用链没埋点，这锅就开始转圈。
普通团队可以先做小评测
不一定一上来就做很完整的平台。更现实的做法，是把最常见的任务挑出来，做一批固定用例，再补一批线上真实失败样本。比如客服摘要、SQL 辅助、告警归因、发布检查单，这些任务都有明确边界，也容易判断错在哪里。评测数据不要只放标准答案，还要放约束：哪些字段不能碰，哪些操作必须人工确认，哪些输出必须引用来源。
我会把 Agent 当成一个新服务来接入，而不是当成聊天框。新服务上线要有灰度、监控、限流、回滚，Agent 也一样。评测体系如果能直接产出这些接入要求，它就有价值；如果只是证明“模型更聪明了”，那离工程落地还差一段路。
最后看的是可接管性
Agent 评测做到最后，我觉得要回答一个朴素问题：它犯错时，人能不能接得住。能看到上下文，能复现步骤，能知道它为什么调用某个工具，能把权限收回来，能把结果回滚掉，这些都比一个漂亮分数更实在。基于公开摘要可见，美团这篇文章把评测放在业务实践里谈，是个比较健康的方向。对准备把 Agent 接进内部系统的团队来说，先别急着扩大使用范围，先把失败样本攒起来，把每次失败变成下次评测的一部分。这样慢，但更像能长期维护的东西。
