本文根据美团技术团队 2026 年 9 月 10 日发布的《Agent 评测全览》和大淘宝技术 9 月 18 日发布的业务效果评测实践撰写。文中的方法和实验结果来自两家团队的公开披露，产品判断来自我对材料的分析，不是对其内部系统的实测。标题中的“必争之地”指这项能力的重要性，不代表大厂正在争夺评测市场或行业标准。

9 月 10 日，美团发布《Agent 评测全览》，讨论怎样同时检查结果、过程、效率和风险。八天后，大淘宝技术把同一个问题放进营销业务，一条看起来合理的策略，究竟能不能带来真实效果？

如果评测只是给模型多做一套考试，就很难解释两支技术团队为什么都把上线、迭代和业务效果放进同一套讨论。Agent 已经不只负责回答问题。它开始读取业务数据、调用工具、生成文件，甚至产出会进入真实系统的策略。任务往前多走一步，错误的代价就更具体：数据可能拿错，工具可能调错，结果也可能看起来合理，放到线上却没有效果。

Agent 一旦进入真实业务，团队就得回答四个问题：哪个版本敢上线；改完以后是否真的更好；出了问题该改 Agent 还是评测标准；现有证据够不够支持扩大使用。

这两篇实践共同指向一件事：评测要为这些决策提供依据。团队有了依据，才可能把 Agent 从演示推向上线，持续迭代并逐步扩大使用。评测因此不再是发布前打一次分，而是贯穿产品运行的依据。

01 Agent 一旦开始办事，错误就有了业务代价

美团的经营分析 PPT 例子，正好说明了为什么最后结果还不够。

用户上传门店数据，再让 Agent 结合平台投放数据制作一份经营分析 PPT。Agent 要先调用取数 Skill，也就是预先配置好的取数能力，拿到对应月份的平台数据，保存中间文件，再把两份数据合并起来完成分析。

如果团队只检查最终交付物，一份能打开、排版完整的 PPT 很容易被判成成功。可 Agent 可能拿错月份，数据合并可能出错，图表看起来很漂亮，结论却没有数据支持。只看最终 PPT，团队可能连错误都发现不了；即使发现了，也很难判断该回头检查数据获取、工具调用、数据处理，还是内容生成。

一次完整 Trace，可以把错误定位到具体工具与参数。

到了淘宝的营销场景，错误会直接落到业务结果上。Agent 生成的补贴或广告策略可以格式合法、推理合理，也符合历史经验，上线后却未必带来投入产出比（ROI）或成交额（GMV）的提升。商品组合、流量和投放周期的变化，都会影响最终结果。离线评测可以检查策略是否合规、是否说得通，却不能代替真实业务实验。

PPT 能打开，不等于分析正确；策略说得通，也不等于业务有效。Agent 的验收对象已经不再是最后一段文字，而是从获取数据、调用工具到最终交付和线上效果的一次完整任务。

交付物看起来成功，后台链路仍可能全错。

这些标准不能等到模型选完、功能做完再补。AI 产品经理在定义功能时就得写清三件事：用户拿到什么才算任务完成，哪些错误绝不能发生，什么时候 Agent 必须停下来交给人。写不清这些，团队连一次任务是否真的完成都无法判断，更谈不上比较后续版本。

02 有了可靠的评测，团队才敢持续改、逐步放量

标准写清以后，团队才有了比较版本的尺子。但 Agent 不会一次定型。模型升级、提示词调整、知识库更新、工具增删，每一次改动都可能修好一个问题，也让原本能完成的任务重新出错。

美团把离线评测称为“变更的门控”，也就是上线前必须经过的检查。新旧版本用同一批任务、同一套标准，在尽量一致且贴近生产的环境里重跑，尽可能让差异只来自版本本身。安全和数据准确性这类被设为一票否决的检查，只要一项不达标，就阻断发布。这次回测先看核心任务是否仍能完成，踩过的坑有没有再次出现。总分更漂亮，并不能单独说明版本可以发布。

离线回测也只能守住已知问题。美团举了一个很直观的例子：如果评测集里全是“制作 PPT”，后来用户开始大量提出“帮我对比三家门店的数据”，原来的回测根本看不见这类新任务。

通过离线回测后，新版本也不能直接全量。团队还要先在不影响用户结果的情况下跟随真实请求运行，再用小范围线上实验观察业务效果。离线结果提供放行依据，真实业务结果决定是否继续扩大使用范围。

评测既推动 Agent 迭代，也要持续校准自身。

线上出现一个失败样本，事情也不该停在“记下来”。团队要还原执行过程，判断究竟是 Agent 做错了，还是原来的评测漏掉了这个风险。前一种要修提示词、工具或模型，再重新回测；后一种要补样本、改标准，让下一次评测能把同类问题拦住。

Agent 做错与评测漏判，需要走两条不同的修正路径。

只有还原过程、找到原因并重新回测，一次线上失败才真正推动了下一版产品。Agent 仍然会出错，但每次改动都有检查依据，问题出现后也知道该往哪里修，团队才敢继续改、继续扩大使用。

不过，这套做法还有一个前提：负责判分的评估器得先判对。否则，回测越稳定，团队反而可能越坚定地朝错误的方向优化。

03 更难的一关：评估器自己也会判错

淘宝早期做过一次实验。他们让另一个大模型充当评估器，比较一条业务效果较好的策略和一条较差的策略，判断哪条更违反某项候选规则。训练集准确率一度达到 96%；但当一半数据用于训练、另一半留作验证时，验证集准确率只有 50%，和随机猜测相当。

原文中的 96%、50% 和 69.3%，都在提醒团队先校准评估器。

问题不在策略，而在实验的摆法：好策略总在候选位置 A，差策略总在位置 B。好坏标签和位置绑在一起以后，评估器只要记住位置规律就能拿高分，根本不必理解那条业务规则。训练集上的漂亮数字，遮住了这条捷径。

如果裁判只记位置，它根本不需要看懂选手。

96% 和 50% 衡量的是评估器能否按候选规则区分策略好坏，不是 Agent 的任务成功率，也不代表 ROI 或 GMV 的变化。淘宝随后随机交换两条策略的位置，让评估器不能再靠位置猜答案。这样得到的结果虽然变低了，却少了一层由实验摆法造成的虚高。

位置偏差也只是其中一个坑。一条规则可能只在筛选它的那批样本上有效，换一批数据就失灵；一个评估器也可能每次都给出相同答案，却稳定地判错。判断稳定、训练集分数高，都不能单独证明这把尺子量得准。

淘宝后续没有把模型生成的评分规则直接当成标准，而是先把它们放进候选池，再通过位置随机化、不同数据上的验证和持续筛选，淘汰不稳定的规则。模型给出的只是一批待验证的规则，最终能不能用于上线决策，还要看独立验证和真实业务结果。

对 AI 产品经理来说，接入模型评估器只是开始。团队还要给它准备经过业务确认的正确答案，拿没见过的样本复测，并约定机器和业务专家意见不一致时由谁裁决。评估器犯过的错能够被发现、修正并加入后续回测，它的分数才配进入发布决策。反复验证过的规则和失败样本，也才可能留给后续版本使用。

04 业务经验写进标准，才开始成为可复用的积累

美团把完成得好的任务收进黄金集，也就是一组经过确认的标杆任务；失败样本进入错题集，暂时做不好的任务则作为挑战任务保留下来。淘宝从历史上的好坏策略中生成候选规则，再用真实结果筛掉不可靠的部分。一轮评测结束后，分数会过去，样本和规则还能在下一版继续使用。

留给下一版的，还有成功、失败与能力边界。

对业务复杂、协作团队多的大公司来说，这种积累尤其重要。场景、用户和协作团队一多，一类错误可能被成批放大，质量标准也会随着版本和项目反复争论。模型、提示词和工具可以更换，但三件事必须留下来：哪些任务最重要，哪些错误绝不能发生，什么证据足以支持扩大使用。把这些判断变成团队能够反复使用、持续更新的标准，大厂才更有把握把 Agent 放进更多业务。

这些标准也不能定死。Agent 服务的人群和任务会随着使用范围扩大而变化，旧案例可能失效，迁移到新业务也要重新校准。数据多、指标多，本身不会自动变成壁垒。

起步不需要先造一套庞大的评测平台。先选少量核心任务，写清成功条件和不可接受的失败，保留足以复现问题的输入、工具调用和结果记录；等真实问题出现，再补样本、标准和观测能力。

下一次评审 Agent 版本时，先问清三件事：核心任务有没有完成，必须拦住的风险有没有被拦下，线上反馈是否支持继续扩大使用。这三件事答不清，版本就不该继续扩大使用。

参考资料