美团谈 Agent 评测,生成 PPT 就算完成任务了吗?

美团技术团队在 2026 年 9 月 10 日发布的《Agent 评测白皮书》第一篇里，举了一个商家经营分析的场景。一位连锁餐饮店的店长，上传门店数据，希望 Agent 结合上个月的投放情况，做一份分析 PPT。

按预期流程，Agent 要获取投放数据，与门店数据结合，再生成文件。流程走到最后，就可以显示“已完成”。

店长拿到文件以后，还要检查什么？

投放金额有没有错，两份数据有没有对上，结论能不能用于经营讨论。假如这些都需要他重新核实，文件虽然生成了，原本想省下的工作却可能没省多少。

我把这篇白皮书和它引用的 Anthropic 评测文章对照读了一遍，觉得这个例子很适合产品经理细看。它让“任务完成”有了具体的讨论对象，究竟完成了哪一步，还有多少工作留给了用户。

一、先说清楚店长能拿走什么

如果团队把成功定义成“生成一个 PPT 文件”，评测会很容易。检查文件是否存在，格式是否正确，就能给出结论。

这样的标准只覆盖了交付的一部分。

美团在示例中继续检查，PPT 里的投放金额是否与源数据一致，有没有同比或环比分析，耗时是否在约定范围内，以及执行过程中是否出现未经确认的写操作或数据外发。它把一份看起来不错的 PPT，拆成了可以逐项核对的条件。

美团原文截图。表中的五分钟等要求是场景示例，不能直接当作所有 Agent 的上线标准。

这里已经有了产品取舍。文件必须能交付，关键金额必须准确；同比或环比分析可以作为加分项；越权操作要单独处理。

这些检查项不能随便平均。一份 PPT 排版很好、图表很多，但投放金额写错了，其他地方多得几分也补不回来。把所有维度合成一个总分，容易让这种错误在汇报时消失。

评审时应该让业务方参与约定这些条件。哪些缺陷可以接受，哪些错误会让结果无法使用，研发需要知道区别。现有系统只能检查文件格式，就先把格式写进验收标准，这样省事，却可能把金额准确性留到了用户手里。

数据不足也要提前约定。沿用这个场景，如果某个月缺少投放记录，Agent 应该补问、标注缺失，还是停止生成？强行做出一份完整报告，反而可能给店长留下更难察觉的问题。

二、PPT 做错了，先找到错在哪一步

最终交付能不能用，决定了用户对产品的判断。但只盯着最终结果，研发往往不知道从哪里改。

美团原文给了一张执行记录示意图。Agent 已经获取投放数据，也写出了 CSV 文件，随后调用经营分析工具时，参数校验失败，提示缺少门店编号。前面的几步都正常，整项任务仍然失败了。

美团原文中的执行记录示意，经营分析工具因缺少门店编号报错。该图用于说明排查方法。

如果系统只留下用户的提问和最后一条回复，这个问题很容易被概括成“模型做不好经营分析”。

把工具输入、返回结果和报错记录展开，就可以继续查，门店编号在哪一步丢掉，工具说明是否交代清楚，调用前有没有校验。团队有了具体的修复方向，才值得讨论换模型能不能解决它。

这也是原文把结果评测和过程评测分开的原因。结果评测检查店长有没有拿到可用的分析，过程评测帮助团队寻找失败发生的位置。

两者得连起来。接口返回成功，只能说明调用在某种意义上执行了；数据日期取错、门店取错、金额口径理解错，都可能藏在一次正常返回里。运行监控没有报警，业务质量仍然可能不合格。

Anthropic 在评测文章里用了一个更直接的例子。订票 Agent 说已经订好机票，评测仍要检查环境中的数据库是否真的存在预订记录。回复文本和执行后的实际状态，需要分别确认。阅读 Anthropic 原文

验收时要拿到用户最终收到的东西，也要能追到关键步骤。前者帮助业务方确认结果，后者让研发知道该改哪里。

三、发现问题以后，评分规则也要接受检查

美团白皮书里，我很认同的一点，是它给失败样本安排了两种处理路径。

一条路径检查 Agent。团队沿着执行记录定位错误，检查需求理解、工具参数和中间结果。如果用户约束在执行途中丢失，还要继续查看上下文处理，找到信息从哪里开始缺失。

另一条路径检查评测本身。样本有没有覆盖当前需求，评分规则有没有误判，所谓的标准答案是否仍然适用。

美团原文截图。一次问题排查，可能需要修改 Agent，也可能需要修改评测规则。

评分规则一旦自动执行，误判也会被反复执行。

Anthropic 提到过一个任务设计问题。任务要求 Agent 写脚本，却没说明保存路径，测试程序又只在某个指定路径寻找文件。Agent 按要求写了脚本，也可能被判失败。这样的分数，无法准确反映它完成任务的能力。来源

回到经营分析的场景，假设用户最初只要求分析一家门店，后来开始要求比较多家门店。如果评测集仍围绕旧任务打转，分数保持稳定也不能证明产品覆盖了新需求。

评分标准还可能把合理选择判错。沿用这个例子，若某份分析满足数据准确、结论有依据等要求，却因为采用了另一种合理图表被扣分，就该检查评分是否把表达偏好误当成了业务要求。

这不意味着出错以后可以随意改标准。用于版本对比的样本、规则和环境要保持稳定；确实需要更新时，应记录原因和版本，再重新建立比较依据。否则，分数提高究竟来自产品改进，还是评分放宽，团队自己也说不清。

评测规则可以修改，但得留下理由。

四、多试几次成功，用户愿意等吗

Agent 同一个任务跑两遍，结果可能不一样。只展示一次成功的执行，能证明的事情很有限。

这里有个容易混淆的口径。Anthropic 区分了 pass@k 和 pass^k。前者关注尝试 k 次，至少成功一次的概率；后者关注 k 次全部成功的概率。它们回答不同的问题，不能统称为“多跑几次的通过率”。来源

产品是否允许重试，会直接影响我们应该关注哪种表现。

生成一份经营分析，用户也许愿意再试一次。前提是失败能被发现，重试有明确提示，多花的时间和费用可以接受。如果一份错误报告已经被当成正确结果交出去，用户甚至不知道该重试。

允许多次尝试的产品，还要有办法挑出正确结果。让用户把每份 PPT 都从头核对一遍，重试带来的检查负担仍由用户承担。

所以，一次上线评审至少要讲清楚，用户通常会得到怎样的结果，失败能否识别，需要多少次尝试，以及重试增加多少成本。一次很漂亮的演示，不能替这些问题作答。

五、先测一类任务，修过的问题也要继续检查

美团在文末提醒，完整体系描述的是逐步建设的目标。冷启动阶段，可以先有可回放的执行记录、一批评测样本，以及发布前的回归检查。

Anthropic 给过一个起步建议，收集二十到五十个来自真实失败的简单任务，先运行起来。这个数量适合发现早期改动带来的明显变化，不能据此证明所有场景都可靠。来源

以经营分析为例，先把一类常见任务测明白。保留输入数据、初始权限和交付结果，让业务方确认可用标准。发现一次金额错误，就把它变成之后版本还要检查的样本。修复以后再运行，确认旧问题没有重现。

离线测试通过以后，还要看真实使用。用户愿不愿意采用分析，检查和修改是否减少，出了问题是否仍然回到人工处理，这些需要上线后的观察来回答。具体选择什么业务指标，要由产品承诺决定。

美团原文截图。影子模式、A/B 实验和巡检各有用途，也各有成本与限制。

影子模式可以让新版本处理真实请求，用于比较，但结果不直接交给用户；A/B 实验可以进一步观察业务影响，却也意味着部分用户会接触新版本。涉及写操作的任务，影子运行还需要隔离，避免测试真的改动业务数据。

因此，上线前的准确性和权限检查不能省。实验能提供反馈，也会让真实用户承担试用成本。

读完这篇白皮书，我对 Agent 验收更愿意问一句具体的话。

店长拿到这份 PPT 以后，还需要自己做多少工作？

如果他仍要重新取数、重算金额、逐条检查结论，下次评审就把这些工作摆出来。约定 Agent 应该承担哪些，哪些仍需店长确认，再用同一批任务检查新版有没有做到。否则，“已完成”的状态只是把工作交回给了用户。

内容来源

美团技术团队《Agent 评测白皮书》系列第一篇，发布于 2026 年 9 月 10 日。本文采用具体案例贯穿全文的写法，重点讨论产品验收与上线取舍。商家经营分析及相关图表是原文的方法示例，未将示例数字作为公开实测成绩。

阅读美团原文

相关文章

Anthropic 关于 AI Agent 评测的工程实践，发布于 2026 年 1 月 9 日。

配图均截自美团原文，版权归原作者所有。公开发表前请确认原图使用授权。