Agent演示越来越容易，真正推到全量却依然困难。美团图灵Agent评测团队9月10日发布白皮书系列首篇，把两年多业务实践归纳为“四个模块、三种能力、两条Loop、一套资产”。核心转变很直接：不能只在发布前问“最终答案对不对”，还要持续追踪执行过程、线上异常、业务价值和评测标准自身是否失真。

四个模块不是四张报表，而是一条质量链

白皮书把体系拆为离线评测、在线评测、在线监控、Case挖掘与归因，底层由Trace观测支撑。离线评测负责版本变更后的回归；在线评测判断真实场景里的效果；在线监控盯可用性、成本和行为分布；Case模块把异常样本收进池子，再定位问题究竟来自提示词、Skill、知识库、上下文、模型还是评测标准本身。

这里最容易混淆的是监控与评测。工具调用成功率100%，不代表返回的数据正确；监控可能全绿，用户任务仍失败。因此端到端评测要回答“事情办成没有”，过程评测再回答“坏在哪一步”。白皮书用一个示意例子说明：当端到端交付率从68降到55，若某个Skill成功率同时从95%降到70%，团队才能迅速把问题指向具体环节。这些数字是教学示例，不是美团披露的生产成绩。

两条循环同时转，才能避免“迎合测试”

第一条是Agent迭代Loop：线上样本经过挖掘和归因，进入修复、回测、上线与AB观察。第二条是评测体系迭代Loop：若新问题没有被评测集覆盖，就补样本；若Rubric判错，就修改标准。两条循环共享真实Case和评测资产，让每次犯过的错进入错题集，让可接受结果进入黄金集，让当前做不到的任务进入挑战集。

这套设计还防止另一种危险：团队默认“评测说不行就是Agent不行”，于是不断优化模型去讨好错误指标。定期检查Rubric是否误判，等于给评测器本身设置校准机制。对长程Agent尤其重要，因为正确结果往往不止一种，评分必须同时观察最终环境状态和关键行动路径，不能只做字符串比对。

从冷启动开始，先建最小门禁而不是完美体系

落地时，白皮书建议固定评测样本、标准和尽可能接近生产的执行环境；同一任务运行多次，用通过率而非一次成败判断；安全与数据准确性可以一票否决，体验项则设置阈值。真正有约束力的做法，是把回测放进CI/CD，让模型、Prompt、知识库或Skill变化都必须经过同一扇门。

上线后再用影子模式、AB和巡检补足离线盲区，同时跟踪超时、失败率、Token消耗、平均步数、任务分布与工具调用频次。不要一开始把过程集拆到最细；先覆盖关键端到端任务和核心模块，只有在出现“知道坏了却找不到位置”时继续分层。评测资产应由真实问题驱动，而不是由架构完备焦虑驱动。

小编判断：评测的终点不是分数，而是可解释的运营决策

这份全览最有价值的地方，是把Agent质量从算法团队的一次验收，变成产品、研发、运营和业务负责人共同使用的运行系统。分数下降时，团队要能知道影响了哪类用户、哪一步开始偏离、是否值得回滚；分数上升时，也要能证明业务结果、成本和风险同步改善。

企业现在可以从三个动作开始：选十到几十个最高价值真实任务建立黄金集；为最终结果和关键过程各写一组二元Rubric；把线上失败样本自动送入人工归因队列。每个样本还应保留执行环境、模型版本、工具权限与成本信息，否则同一问题换个环境就可能得出相反结论。负责人需要定期检查黄金集是否仍代表真实用户，并把新任务分布、重复失败和高损失个案加入挑战集。评测集本身也要有版本、负责人和更新节奏，不能成为无人维护的历史快照。先让每次改动有证据、每次故障能复盘，再谈自进化。没有持续校准的评测，所谓自进化只会把错误放大得更快。