Agent 评测别只看得分，先看它能不能被接进生产流程
先别急着把 Agent 接到线上
本文由本站基于公开热点摘要整理和原创分析生成，原文来源：《Agent 评测白皮书》系列01：Agent 评测全览。
美团技术团队最近开始连载《Agent 评测白皮书》，第一篇讲 Agent 评测全览。基于公开摘要可见，这个系列会按评测全览、冷启动、扩量、自进化几个方向展开，口径看起来更偏工程落地，不是单纯聊 Agent 有多聪明。
我对这类文章的兴趣点很直接：Agent 如果只是 Demo，能跑通一个流程就够了；但只要它要碰真实订单、客服、内部审批、运维工单，问题就变了。线上系统怕的不是模型偶尔答错一句话，而是它在错误的时候还很自信，然后把错误动作一路传给后面的系统。
评测不是考卷，是上线前的闸门
很多团队做 AI 功能，第一反应是找一批样例，看准确率、通过率、平均得分。这个动作有用，但不够。放到后端系统里，我会先问几个更土的问题：失败时有没有明确状态？重试会不会重复下单或重复发消息？人工接管在哪一步？日志里能不能还原它为什么走到这个结果？
这些东西听起来不如“模型能力”性感，但它们决定了你敢不敢把 Agent 放进生产环境。一个 Agent 在评测集里表现不错，却在真实流量里因为工具调用超时、上下文缺失、权限边界没切干净而乱跑，这种事故处理起来很难看。尤其是 Agent 会跨多个系统调用工具，排查链路比普通接口更绕。
冷启动时少谈通用，先谈边界
公开摘要提到后续会讲冷启动。我觉得这里最容易踩坑。新功能刚开始没有足够多的真实样本，团队容易拿一堆“看起来合理”的案例凑评测集。结果上线后才发现，用户的问题比样例脏得多：描述不完整、夹杂旧术语、权限不一致、流程走到一半被取消。
更稳的做法，是先把 Agent 的可用边界写窄一点。它能查什么，不能改什么；能建议什么，不能自动执行什么；遇到低置信度、工具异常、返回结果互相矛盾时，必须停在哪。对小团队来说，最怕的不是新技术不会用，而是出了问题没人接得住。
扩量后真正贵的是维护
Agent 评测一旦进入扩量阶段，成本会冒出来。样本要更新，工具接口会变，业务规则会改，提示词和模型版本也可能跟着调整。今天评测通过，不代表下个月还通过。这个变化对写业务代码的人未必明显，但对维护部署链路的人挺敏感，因为它会变成 CI、灰度、回滚和监控里的新负担。
我更愿意把 Agent 评测看成一种回归测试，只是它比普通单元测试更麻烦。输入不是固定参数，输出也不总是固定字符串，所以评测标准要拆细：事实是否正确，工具是否调用对了，动作是否越权，失败是否可解释。不要把所有东西压成一个总分，否则线上出了问题只会得到一句“评测之前挺高的”。
普通团队可以先做什么
如果团队还没做过 Agent 评测，我不建议一上来就搭很重的平台。可以先从真实工单、客服问答、内部操作记录里抽一小批样本，做成可重复跑的用例。每个用例写清楚允许的动作、禁止的动作、需要人工确认的点，再接入日志和告警。
这件事的判断标准也朴素：当模型换版本、提示词改动、工具接口升级时，团队能不能在上线前知道风险变大了。如果答案是否定的，Agent 现在就不该拿太多权限。先让它做建议和辅助，等评测、监控、回滚都能跟上，再慢慢放开执行权。比起追一个漂亮分数，我更信这种慢一点但能兜住底的做法。
