评测集守住已知：美团把 Agent 评测拆成四块和两条闭环

评测集守住已知：美团把 Agent 评测拆成四块和两条闭环

美团技术团队的图灵 Agent 评测在 2026 年 9 月 10 日发了《Agent 评测白皮书》系列第一篇。它不报某一套模型的分数，而是把评测写成上线前的门控和上线后的校准。全文的骨架是四个模块、三种能力、两条 Loop、一套资产。系列计划写四篇落地指南，这一页只展开全览；四篇各自的标题在配图里，正文没有逐条抄出。

门槛降了，判断机制还没有

作者把过去三年收成两条同时发生的曲线。基座模型自己承担了更多格式、工具选择、长上下文和多步推理，使用者不再靠 Prompt 和兜底硬补。Agent 框架把规划、记忆、工具注册和状态管理收成标准组件，接一个工具或加一个 Skill 的工作量下降。结果是搭建变容易，场景更散。

真正走过冷启动、灰度和全量的项目仍被写成屈指可数。自 2022 年底 ChatGPT（基于 GPT-3.5）出现以来，项目常见三种停法：Demo 一接真实流量就盖不住脏数据和边界；小范围还能用，一放量就说不清问题在哪一层，也不敢改；模型换了几轮、Prompt 改了几十版，团队觉得变好了，却回答不了「带来了什么」。共同点是没有可靠的判断机制。ChatBot 的经验也不能直接挪到长程 Agent。

这篇之前已有《Agent 评测漫谈》，回答评测是什么。白皮书要回答先做什么、产出物什么样、做到哪算达标、坑怎么处理。读者被写成产品、研发、算法、运营和评测负责人。作者强调做法来自美团多个业务，换场景仍要改，不能照搬步骤。

量具要准，还要能校准

评测要同时回答两件事：Agent 好不好，以及哪里好、哪里不好。前一个是判断，后一个是方向。量具的比喻有两层。同一条样本，换人、换时间、换成人和机器，结果要一致，对应「人人一致、人机一致」。业务扩量后用户变了、能力边界变了、目标变了，旧评测集和 Rubric（最小粒度的评分细则）会失去代表性，所以量具还要定期校准。后一层被写成消除独裁者偏差的办法，也是最容易被丢掉的一层。

两条 Loop 共用同一批线上样本，在 Case 挖掘和归因处咬合。

评测体系自己的 Loop：在线评测和监控产出异常，样本进 Case 池再归因。若结论是评测集没覆盖，就把样本补进去；若结论是标准判错了，就改 Metrics 和 Rubric。评测集从冷启动的人工搭建，逐步靠近真实用户。

Agent 自己的 Loop：同一批样本定位到 Prompt 不清楚、某个 Skill 的描述导致路由错误、上下文丢掉关键信息，或模型能力不够。改完用评测集回测，确认没有退化，再上线做 AB，看真实效果。提升不能以丢掉已有能力为代价。

第二个咬合点是评测集本身。评测集越完整，回测门禁越有用；门禁越严，上线后的新问题越少。

三种能力在小结里写明：发现问题、定位问题、驱动演进。少一项，体系就在对应环节卡住。沉淀下来的资产有两类。标准是团队对「好」的显式共识。样本里，黄金集定义下限，错题集记下踩过的坑，挑战集标定能力边界。价值是可回归：犯过的错不应再犯第二次。建设评测，本质是把对质量的隐性认知变成可量化、可复用、可传递、可自动执行的资产。

四个模块可以重切，职责不能漏

离线评测、在线评测与监控、Case 挖掘与归因、观测基建。前三个回答不同问题，观测是地基。作者承认行业切分并不统一：Arize AI、LangFuse、Braintrust 对 Online Evaluation、Monitoring 和 Trace 的归类不一样。美团拆成这四块，是为了用同一套语言穿过冷启动、扩量和自进化。团队可以按组织重切，但不能漏职责。

贯穿全文的例子是商家经营分析 Agent，对应内部商家 Claw 一类场景：多步骤、多 Skill、有中间产物、频繁和环境交互、没有唯一正确答案。下文的 68、55、95% 和 70% 都是这个例子里的说明数字，不是对外公布的生产成绩。

离线评测只守已知

离线评测在版本变更后做回测，充当上线前门控。它依赖固定评测集和尽量贴近生产的固定执行环境。模型升级、Prompt 调整、知识库更新、Skill 新增或下线，都要先过这一关，避免不成熟的变更把能力做差。

「固定」是为了控制变量：只让 Agent 版本变，分数差异才能归因到这次变更。最容易被破坏的是环境。测试环境的下游数据和生产不一致，或者沙箱里没有用户历史文件，Agent 拿不到上下文，离线分就会和线上系统性偏离，团队随后不再信离线评测。检验方法写得很具体：同一批样本分别在离线环境和线上影子流量跑一遍，结论差太大，就是环境保真度不够。

广义评测集是（问题、参考答案、评价标准）三元组。问题和参考答案合称评测样本，概念来自大模型评测，借到 Agent 之后含义变了。短程场景的参考答案可以逐字比对；长程场景的参考答案变成对执行过程的描述，要看路径是否符合预期，以及最终环境状态有没有达成。作者借用 Anthropic《Demystifying evals for AI agents》里的 Task：有明确输入和成功标准的单个测试。输入可以是 Query / answer，或 prompt / expected behavior。评价由 Metrics 和 Rubric 组成。二元化 Rubric 是把「这个 PPT 好不好」拆成一组能回答是或否的检查项。人人一致和人机一致的提高，被写成来自这种下钻。Task 的完整样例在配图里，正文没有逐字段列出。

端到端评测集回答事有没有办成，过程评测集回答中间哪一步出错。例子是：100 个任务里 68 个交付了可用 PPT，这是业务方最关心的交付率；数字掉到 55 时，端到端说不出原因。若「投放数据 Skill 调用成功率」从 95% 掉到 70%，问题就定位到这一层；Skill 成功率没变、数据合并正确率下降，问题在另一处。过程指标都没波动、端到端却下降，说明出现了未知异常，要再挖掘并回头补评测集。作者把分工写成：端到端决定要不要拉警报，过程评测决定警报响了找谁。只有端到端，知道坏了不知道哪坏了；只有过程，每个模块都达标但用户仍不满意。

端到端评测集站在用户视角。功能变多之后要按功能模块分开建。商家 Agent 里，门店经营由若干 Skill 组成，门店百科由查数 Skill 和门店知识库组成，两者应各有一套端到端评测集。过程评测还可以再拆成知识库评测集、Skill 评测集。拆到和组织分工对齐时，某一层掉分可以直接找到负责人。但拆解是被真实问题推着走的，不是一开始就画满。顺序是先跑端到端和核心模块的过程评测，遇到「知道坏了但不知道哪坏了」再加细。冷启动篇才会展开这一点。配图里的拆解树，正文没有逐节点抄录。

回测要变成机制，而不只是「跑一遍」。三点工程要求：

1. 多次试验取稳定结论。同一 Task 跑两次可能不同，实践上用多次试验，也就是常说的 Pass@k，用通过率而不是单次对错做结论。原文没有规定 k 的取值。
2. 分层门禁。安全和数据准确性可以一票否决；体验类和加分项可以设阈值。
3. 接进 CI/CD 或发布流程。没有接进流程的门禁，只是一条建议。

离线的边界也写死了：评测集里没有的场景，回测永远测不出来。若集子里全是「制作 PPT」，用户开始大量要求「对比三家门店」时，固定集覆盖不到。所以离线守已知，在线发现未知。

在线评测看质量，监控看有没有在干活

在线评测包括 AB、影子模式和巡检，在真实环境里看效果。在线监控看 Skill/Tool 成功率、失败率、Token 消耗和异常波动。一句区分：评测回答系统工作得好不好，监控回答系统有没有在正常工作。Skill 调用成功率 100% 但每次都返回错误数据时，监控是绿的，评测是红的。

三种在线手段的互补被写成：影子模式在上线前用真实流量兜底，AB 在上线后确认业务价值，巡检在日常盯基本盘。三者各自的操作步骤主要在配图里，正文没有展开成操作手册。

巡检同时有评测属性和监控属性。常见做法是从离线评测集抽一部分代表性 Task，周期性地看线上表现；评测变细之后也可以单维护一套巡检集。它既判断关键任务成功率有没有低于预期，也把分数变化、失败样本和异常趋势留给后面的 Case 挖掘。商家经营分析的巡检设计同样在配图中，正文没有列出检查项清单。

监控维度分三层。可用性：调用成功率、失败率、超时率、异常类型分布。成本：Token、单任务平均步数、平均耗时。行为：任务类型分布、Skill 调用频次、平均对话轮次。行为层用来发现用户结构变化，某一类新任务占比快速上升，通常意味着评测集要扩充。

两类指标必须一起看。例子：任务完成率下降 5 个点，若某个 Skill 失败率从 2% 涨到 15%，更大概率是工程问题；若 Skill 都正常，但「数据对比类」任务占比从 10% 涨到 35%，结论是用户结构变了，Agent 在新场景上不够。两种情况的修法完全不同，后面就进入挖掘和归因。

Case 要分来源，还要怀疑评测自己判错

Case 挖掘把样本收进池子，归因再定位流程里的问题点。来源包括线上反馈、监控、规则挖掘和随机采样，另外也接收业务规则筛出的样本。只靠反馈，只能看见用户愿意抱怨的问题；只靠监控，只能看见指标能刻画的问题；只靠规则，只能看见已经想到的风险。随机采样成本最高、命中率最低，但是唯一能发现「根本没想到」的问题的手段，不能省。四类来源的更细清单在配图里。

进池之后分成 Good Case 和 Bad Case。错题集的回报最直接：犯过的错不再犯第二次。黄金集容易被低估，因为 Bad Case 只说明哪里不行，不说明到什么程度算行。没有黄金集，讨论质量时各说各话。

归因要把执行过程铺开，用 Trace 逐点查，和看日志查 bug 同类，因此高度依赖观测。可以人工做，也可以机器辅助。分层示意图在配图中，正文没有给出层级名称表。归因之后，正向 Case 进入黄金集或挑战集；负向 Case 要么去修 Agent、回测、上线，要么回头校验 Rubric，标准没刻画到风险就把 Case 放进错题集并改标准。

只走第一条路会出隐蔽问题：Agent 被优化成迎合评测，而不是解决用户问题。标准有偏差时，越优化越偏。定期检查「是不是评测判错了」，是体系自我校准的必要动作。

观测先做到能复现一条 Bad Case

观测被放在研发公式的第一位：观测 + 评测 = 持续迭代。一次执行是用户输入、意图理解、任务规划、工具或 Skill 调用、环境交互、中间结果、策略调整、最终输出。只看见用户说了什么和最后回了什么，就无法判断根因。Trace 要把影响输出的输入都记下来。

观测基建从 Trace SDK 走到集成在 OpenClaw、Claude Code 里的 Trace Plugin，开源基建仍落后于 Harness 的迭代速度。正文说一套完备观测至少应具备若干能力，清单在配图里，没有逐条写出。落地标准被写成一句：想自动判断某件事，但数据里没有，就是该补埋点的时候。冷启动的底线是最小可归因：至少拿到完整的模型调用输入输出和 Skill 调用记录，能凭 Trace 复现一条 Bad Case。

成熟度看短板，不追求每项都到 L3

作者观察到三种常见的「部分完备」。第三种最要警惕：既有评测集又有监控看板，汇报时数据很齐，但缺中间枢纽。线上问题回不到评测集，评测集也解释不了线上现象。投入不小，收效有限。前两种形态的具体缺口写在配图里，正文没有单独命名。

自查表按 L0 到 L3 使用，但不要所有维度都追到 L3。冷启动阶段，观测、评测集和回测门禁到 L1 就够最小闭环。扩量阶段，把评测标准和在线评测推到 L2，少量指标到 L3。全量运营才考虑 L3 的自动化和规模化。更有用的是看错配：评测标准已经到 L3、机评已经规模化，Case 挖掘却还在 L0、只靠用户投诉，那么机评只是在重复评测已知样本，投入应转到挖掘。体系上限由最短的那块板决定。表上的逐行定义在配图中，不能把没写出来的等级说明补成事实。

全景图被明确写成终局，不是起点。没有任何团队应该照着从头建一遍。起步阶段让数据飞轮转起来，比设计一套精巧体系更重要。下一篇预告是冷启动：没有评测集时，怎么做最小闭环。本页没有给出那一篇的发布日期。

离线分升高，不等于可以代替线上 AB

FAQ 直接拒绝把基座模型的打榜习惯搬过来。基座模型测的是通用能力，指标体系是多年论文堆出来的，benchmark 的含义本身也变过。Agent 服务垂直业务，最好的指标是业务指标，上线 AB 看业务指标变化被写成黄金标准。

评测集再拆成必过集和挑战集。挑战集很难建，也很容易跟不上功能迭代。必过集是核心功能，已知问题要尽量解决了才能上线。于是经常出现必考题都会了、难题又见不到的情况。离线评测因此更多用于回测；真实好坏看线上 AB。如果设了挑战集，必须及时更新到线上真实分布，否则评测集不可信。

读这篇时要守住的限制：68/100、掉到 55、95% 到 70%、完成率降 5 个点、Skill 失败率 2% 到 15%、对比类任务 10% 到 35%，都是商家经营分析例子里的说明，不是美团公布的线上成绩。Pass@k 没有规定 k。四篇系列、Task 字段、能力清单、巡检项、归因分层、观测能力表和成熟度逐行定义，有一部分只在配图，本文不补写图中没有落到文字里的条目。

出处：美团，图灵Agent评测，Agent 评测白皮书系列01：Agent 评测全览，2026-09-10，https://tech.meituan.com/2026/09/10/Agent-Evaluation-White-Paper-01.html