Agent 评测别只看分数，先想清楚它怎么进生产
内容提要
Agent评测不应仅看分数，需关注生产落地。应拆解错误环节（如任务理解、工具选择），贴近真实链路，考虑权限、审计、成本。普通团队可从小规模固定用例和失败样本入手，将Agent视为新服务接入，需有灰度、监控、限流。最终目标是可接管性，确保人能在出错时介入，积累失败样本以持续改进。
延伸解读
评测分数之外的工程视角
文章指出，Agent评测不能只看总分，因为总分无法告诉值班同学具体问题所在。更关键的是拆解错误环节，如任务理解、工具选择、参数生成等，让评测像日志和指标一样可定位。这种思路强调评测要服务于工程调试，而非仅仅展示模型能力。
生产环境中的隐性风险
Agent进入生产前，需考虑权限、审计、失败后的人工确认、重试限流等非AI能力问题。文章提醒，小团队容易将复杂度塞进无人维护的prompt和脚本中，导致责任不清。因此，评测应包含这些接入要求，确保Agent能像新服务一样被管理。
从失败样本中持续改进
文章建议普通团队从小规模固定用例和线上失败样本入手，如客服摘要、SQL辅助等边界清晰的任务。评测数据需包含约束条件，而非仅标准答案。最终目标是可接管性，即人能在Agent出错时介入，积累失败样本并纳入评测，形成长期维护的闭环。
Q&A
为什么Agent评测不能只看分数？
因为总分无法反映具体错误环节，比如是任务理解、工具选择还是参数生成出了问题，工程上难以定位和修复。评测需要能拆解错误，像日志和指标一样，才能用于生产。
Agent评测应该关注哪些真实链路问题？
应关注权限最小化、工具调用审计、失败后能否暂停等待人工确认、重试是否可能刷爆外部接口，以及成本（如轮数、工具调用次数、token消耗）等，这些决定Agent能否进生产。
普通团队如何低成本开始Agent评测？
可以挑选常见任务（如客服摘要、SQL辅助、告警归因、发布检查单）做固定用例，并补充线上真实失败样本。评测数据要包含约束条件，如哪些字段不能碰、哪些操作必须人工确认、哪些输出必须引用来源。
Agent上线时应该具备哪些工程化能力？
Agent应像新服务一样接入，需要具备灰度发布、监控、限流、回滚等能力。评测体系如果能直接产出这些接入要求，就有价值。
Agent评测的最终目标是什么？
最终目标是可接管性，即当Agent犯错时，人能否接得住：能看到上下文、复现步骤、知道为何调用某个工具、能收回权限、能回滚结果。这比一个漂亮分数更实在。
为什么Agent评测要积累失败样本？
因为失败样本能帮助持续改进，每次失败都应成为下次评测的一部分。这样评测体系才能长期维护，而不是一次性证明模型更聪明。
