Agent 评测别只看得分，先看它能不能被接进生产流程
内容提要
美团技术团队发布《Agent评测白皮书》连载，首篇为评测全览。文章指出Agent评测应作为上线闸门，而非考卷，需关注失败状态、重试幂等、人工接管和日志可还原性。冷启动阶段应划定能力边界，明确能查、能改、能建议和必须停止的情形。扩量后维护成本上升，评测应像回归测试，拆细事实、工具调用、越权和可解释性标准，而非压成总分。建议小团队先用真实工单做可重复用例，接入日志告警，逐步放开权限。
延伸解读
评测是上线闸门，不是考卷
文章强调，Agent评测不应只关注准确率或平均得分，而应作为上线前的闸门。这意味着评测需要回答更工程化的问题：失败时是否有明确状态？重试是否会导致重复操作？人工接管点在哪里？日志能否还原决策路径？这些因素直接决定了Agent能否被安全地接入生产流程，避免在真实流量中因工具调用超时、上下文缺失或权限问题引发事故。
冷启动阶段：先划边界，再谈能力
在冷启动阶段，团队容易用“看起来合理”的案例凑评测集，但真实用户输入往往更脏、更不可预测。文章建议，与其追求通用能力，不如先明确Agent的可用边界：能查什么、不能改什么、能建议什么、不能自动执行什么，以及在低置信度、工具异常或结果矛盾时必须停止的情形。对小团队而言，清晰的边界比宽泛的能力更重要，因为出了问题需要有人能接住。
扩量后，维护成本才是大头
Agent评测进入扩量阶段后，成本会显著上升。样本需要更新，工具接口和业务规则会变化，提示词和模型版本也可能调整，导致今天通过的评测下个月可能失效。文章建议将评测视为回归测试，拆细标准：事实正确性、工具调用正确性、动作越权、失败可解释性等，而不是压成一个总分。否则线上出问题时，只能得到“评测之前挺高的”这种无用的结论。
小团队的低成本起步路径
对于尚未做过Agent评测的团队，文章不建议一开始就搭建重型平台。可以从真实工单、客服问答或内部操作记录中抽取小批量样本，做成可重复运行的用例。每个用例明确允许的动作、禁止的动作和需要人工确认的点，并接入日志和告警。判断标准很朴素：当模型换版本、提示词改动或工具接口升级时，团队能否在上线前知道风险变大了。如果答案是否定的，就不该给Agent太多权限，先让它做建议和辅助，再逐步放开执行权。
Q&A
Agent评测为什么不能只看准确率或平均得分？
因为评测应作为上线前的闸门，而非考卷。只看得分不够，还需关注失败时是否有明确状态、重试是否会重复下单或发消息、人工接管在哪一步、日志能否还原决策原因。这些工程问题决定了Agent能否安全接入生产环境。
Agent冷启动阶段应该重点做什么？
冷启动阶段应少谈通用能力，先划定Agent的可用边界：能查什么、不能改什么、能建议什么、不能自动执行什么，以及遇到低置信度、工具异常或结果矛盾时必须停在哪里。把边界写窄一点更稳妥。
Agent扩量后为什么维护成本会变高？
扩量后样本需要更新、工具接口会变、业务规则会改、提示词和模型版本也可能调整，今天评测通过不代表下个月还通过。这会给CI、灰度、回滚和监控带来新负担，因此评测更像回归测试，需要持续维护。
Agent评测标准应该如何拆解？
评测标准要拆细，分别检查事实是否正确、工具是否调用对了、动作是否越权、失败是否可解释。不要把所有东西压成一个总分，否则线上出问题只会得到一句“评测之前挺高的”。
小团队刚开始做Agent评测，有什么可落地的步骤？
先从真实工单、客服问答、内部操作记录中抽一小批样本，做成可重复跑的用例。每个用例写清楚允许的动作、禁止的动作、需要人工确认的点，再接入日志和告警。判断标准是：当模型换版本、提示词改动、工具接口升级时，能否在上线前知道风险变大了。
在Agent评测和监控还不完善时，应该给它多大权限？
如果团队无法在上线前知道风险是否变大，Agent就不该拿太多权限。应先让它做建议和辅助，等评测、监控、回滚都能跟上，再慢慢放开执行权。这种慢一点但能兜住底的做法比追漂亮分数更可靠。
