美团的双环评测:一次失败,该改 Agent 还是改标准

白皮书的出发点，是“搭出 Agent”和“把 Agent 持续做好”之间的落差。作者列出几个项目困境：演示时顺利，遇到真实用户却覆盖不住；试用时还能应付，扩量后不知道问题在哪；改了很多版，却拿不出质量变化和业务价值的证据。它们共同指向一项能力：团队能否可靠地判断当前版本好不好、问题在哪里、修改以后有没有退步。〔1〕

为此，全文串起上线前的固定任务回测、上线后的质量评测与运行监控、异常案例的挖掘和归因，以及支撑这些工作的执行记录。它进一步提出两条相互连接的循环：一条改进 Agent，另一条更新评测覆盖和判定标准；两者共享真实案例，并把结论沉淀成下一次还能使用的评测任务。评测不只负责给系统打分，它自己的尺度也需要维护。〔1〕

这份总览覆盖面很大。本篇选其中最关键的一条线来读：一份报告没有交付好，怎样从结果追到过程，再判断应该改助手、补题目，还是修正判定细则。白皮书本身也用商家经营分析任务贯穿讲解；下文先完整还原这项工作，再结合美团此前《Agent 评测漫谈》对判定方法的说明，解释双环怎样运转。〔1〕〔2〕

美团《Agent 评测白皮书》用一个商家经营分析场景讲解评测。用户是连锁餐饮门店的店长或运营：他上传一份门店数据表，希望 AI 助手结合上月的美团投放数据，制作经营分析 PPT。〔1〕

这里的 Agent，可以先理解成能够按要求调用工具、处理文件、交付结果的 AI 助手。店长要的结果，是一份可以使用的经营分析材料。

这项示例任务也有明确前提：门店数据表已准备好，商家账户访问权限已配置，投放工具可用。助手在这些条件下执行工作。〔1〕

原文配图把这项工作写成两步：

1. 调用经营投放工具，取得上月投放数据，保存成 CSV 数据表。

2. 把这份表与用户上传的门店数据结合，调用经营分析工具，制作 PPT。

原文把这两项工具能力称为 Skill。看到这个词时，可以对应到具体动作：一项负责取数据，一项负责结合数据完成分析和制稿。

如果平时做过月报，这段任务并不陌生：先把需要的数据找齐，再整理分析，最后形成别人能看、能用的材料。把这些工作交给 Agent 之后，检查质量也需要沿着这条工作链展开。

白皮书随后用了一个讲解例子：100 次任务中，可交付的 PPT 原先有 68 份，后来降到 55 份。这些是用于说明排查方法的数字。〔1〕

这个变化首先告诉团队：最终交付变差了。站在店长一侧，他交出数据和需求之后，拿到可用报告的机会变少了。

但只看这个结果，还不知道应该让研发修改哪里。前面那两步中，可能是投放数据没有取回来，也可能是数据已取到、合并分析时出了问题。

原文给出的排查分叉是：取数指标下降，追查取数；取数指标没有变化，继续看数据合并；如果现有过程指标都没有变化，仍要寻找尚未被解释的异常。〔1〕

到这里，再看两个评测术语就有具体对象了：

两者共同回答两个不同的问题：最终结果是否退步，以及接下来应从哪段过程开始查。过程指标提供排查线索；找到一个变化之后，还需要查看实际记录，确认它与最终失败有什么关系。

沿着经营报告的执行过程，团队可以查看用户输入、工具调用、工具返回和最终文件。这种按执行顺序保留下来的记录，就是文中说的 Trace。

记录让“报告没做好”变成可以调查的问题。比如已经确认数据处理出错，后续修改就要针对造成错误的系统行为；仅仅把最终回答写得更完整，不能修复上游数据。

美团同时要求检查另一件事：用来判断 Agent 的题目和规则，是否也出了问题。白皮书将失败后的修改分成两条路径，一条改 Agent，一条改评测体系。〔1〕

要读懂后一条，先把“评测体系”拆成两个朴素的问题：

检查哪些任务？团队会准备一批有输入、有预期的任务，供不同版本反复执行，这就是评测集。

什么表现算通过？同一个任务还需要明确的判定细则。它说明评测者应该检查什么、根据什么证据作出判断。

这里要区分两个入口：已有评测题没有通过，需要核查系统行为与判定依据；线上出现旧题没覆盖的任务，则需要考虑补题。后者不能仅从一次评测不通过推断出来。

原文在完整任务表里给了具体的判定例子：必须生成 PPT 文件，投放金额须与源数据一致；同比或环比分析则列为加分项。〔1〕

这比一句“报告质量好不好”清楚：检查对象包括文件、金额和分析内容，而且必过项与加分项作用不同。

沿这组原文细则，可以理解两种不同问题：如果金额与源数据不符，需要追查系统处理；如果只是没有加分项，评分器却因此将整项任务判为失败，就要检查评分规则是否把加分项当成了必过项。这是依据原文规则作的解释，不是美团报告过的一次事故。

如果一名评测者主要看数据，另一名主要看文字表达，两人即使都认真阅读，也可能给出不同判定。这里还没有足够依据去讨论哪个 Agent 版本更好，先要弄清两人是否在检查同一件事。

美团在另一篇《Agent评测漫谈》中给出具体做法：将模糊要求细化，尽量判为是、否或未知；让评测者分别标注、比较分歧，再用未知结果检查细则是否定义清楚。〔2〕

以金额一致这条细则为例：报告金额和源数据能对应，判为是；两者不一致，判为否；缺少用于核对的源表，暂时无法判断，记为未知。这是本文对判定方式的演示。

“未知”提示当前材料不足以作判断。它不能因为报告看起来完整，就被当成通过。

这也是文中 Rubric 的含义：用于判定的具体细则。先知道团队准备怎样判断报告，再读“修改 Rubric”，就能理解它改的是哪一部分。

批注：修改细则，需要有业务依据。单纯放宽要求让分数上升，无法说明 Agent 更能完成店长交给它的工作。标准调整后，还要重新检查它能否区分合理与不合理的表现。

现在可以把前面的工作连起来。

Agent 迭代这条路径，改变的是系统做事的方式。从任务记录定位问题，修复之后，再执行已有评测任务，检查问题是否解决、原有表现是否退步；随后上线观察真实业务效果，并继续接收反馈。

评测迭代这条路径，改变的是检查任务和判定方法。发现遗漏就补任务，发现判定有偏差就修细则。更新后的评测集，继续用于 Agent 的回测。原文所说的双环，就是这两条持续连接的路径。〔1〕

它们有两个连接处：同一条任务记录，可能同时触发系统修复和评测修订；修订后的评测集，又会检查下一版系统。

白皮书还提到上线 AB。它是让可比较的用户组使用不同版本，再观察业务结果。对读者而言，这里需要先分清：回测检查已定义的任务，线上观察则检查真实使用中发生了什么。已有任务的新失败、尚未覆盖的新需求，都可能成为下一轮调查的入口。

一开始，我们只知道店长需要经营分析报告。现在可以沿同一条工作链检查：两份数据是否到位，处理过程是否正常，最后交付是否满足要求。

如果这些表现确有问题，就需要改进系统。如果检查任务没有覆盖当前需求，或者判定依据本身不清楚，就还需要改进评测。

美团这组文章要建立的，正是这种相互反馈的关系：执行留下可查看的记录，记录支持判断和修改，修改后的系统再次接受检查。评测也在这个过程中逐步修正。

〔1〕图灵 Agent 评测团队：《Agent 评测白皮书》系列01：Agent 评测全览，2026-09-10。本文重点依据其中的商家任务配图、双环、端到端与过程评测、案例归因章节。

https://tech.meituan.com/2026/09/10/Agent-Evaluation-White-Paper-01.html

〔2〕履约技术团队：《Agent评测漫谈 —— 由浅入深讲解Agent评测》，2026-08-07。本文使用其细则拆分和判定对齐方法。

https://tech.meituan.com/2026/08/07/Agent-Evaluation.html