《Agent 评测白皮书》系列01：Agent 评测全览 | 美团 · 技术团队

一是基座模型的能力持续进化，它带来的结果是对使用者的要求在往下降。早期要让模型稳定地按格式输出、正确地选中一个工具，需要反复打磨 Prompt、设计各种兜底。现在这些能力越来越多地由模型本身承担，长上下文、原生工具调用、更强的指令遵循和多步推理，把大量原本需要工程去补的地方补上了。
二是 Agent 框架的功能持续丰富。从早期需要自己实现规划、记忆、工具注册和状态管理，到现在框架和协议层把这些抽象成标准组件，接一个工具、加一个 Skill，工作量都在显著下降。
两条曲线叠加，结论很直接：搭建 Agent 门槛正在逐年降低。这带来的直接变化是 Agent 落地场景越来越多，越来越发散。
自 2022 年底 ChatGPT（基于 GPT-3.5）发布以来，市场上出现了一波又一波 Agent 项目。但是那些真正走过冷启动、完成灰度扩量、推到全量的项目数量屈指可数。这导致掌握 Agent 评测方法的人非常稀缺。
过去三年绝大部分 Agent 项目都死掉了。它们消失的原因有一些共性：
这三种死法看起来不同，追下去会发现共同点：团队缺少一套可靠的判断机制。不知道当前版本行不行，不知道问题出在哪一层，不知道改完是真的变好还是换了个地方出错，也不知道怎么向外证明这件事的价值。做决策靠的是感觉和个别案例，而感觉在复杂系统面前不可靠。
把两件事放在一起看，会得到一个略显割裂的图景：搭 Agent 的门槛在快速降低，把 Agent 做好的认知却仍十分稀缺。并且，有限的评测认知面对发散的场景，同样力不从心。做好一个 ChatBot 的经验，并不能无缝泛化到做一个长程 Agent 身上。为此，我们希望将团队两年来在众多业务方中打磨出的评测的认知，以体系化的形式分享给大家，希望能帮大家少走一些弯路。
前不久，我们发布了一篇博客《Agent 评测漫谈》，介绍了评测的核心方法论，回答的是“评测是什么、为什么这么做”。文章发出后，我们收到不少的反馈，其中出现频率最高的一类是：方法论看了，但具体到自己的项目，还是不知道从哪下手。
为此，我们计划撰写《Agent 评测白皮书》系列博客，体系化地为大家讲解评测的落地指南 —— 先做什么后做什么，每一步的产出物长什么样，做到什么程度算达标，遇到常见的坑怎么处理。计划分四篇：
本系列博客面向 Agent 产品、研发、算法、运营和评测负责人。如果你正在从零开始搭一个 Agent，或者手里的项目卡在某个阶段推不动，希望这几篇能提供一些可以直接用上的东西。
这里也需要强调一下：评测是一门实践科学，本系列给出的做法来自我们评测团队在美团多个业务的实践，它们在各自的场景里被验证有效，但迁移到新场景时仍然需要结合业务特点做调整。比起照搬步骤，更值得关注的是每个做法背后要解决的问题。理解了问题，做法自然可以因地制宜。
第一篇《评测全览》目的在于让大家系统地了解评测的构成，我们用一套统一的语言对齐行业内尚在发散和纠缠的概念，用一套叙事逻辑打通冷启动、扩量和自进化。有了全览之后，大家可以以终为始，判断自己现在处在哪里、下一步补哪一块。完备的评测体系可以概括为四个模块、三种能力、两条 Loop、一套资产。
评测的核心目的是回答两个问题：Agent 好不好？到底哪里好、哪里不好？前者给出判断，后者指明方向。一套完备的评测体系必须同时回答这两个问题。
在《Agent 评测漫谈》一文中，我们认为评测是一套“精密量具”，这个类比其实包含两个隐喻：
第二点是评测贴近真实业务场景、消除独裁者偏差的关键手段，但却是最容易被忽略的。
理想的评测体系是一套持续运转的系统。它由两条 Loop 构成，二者共享同一批线上真实样本，通过 Case 挖掘与归因这个枢纽相互咬合。
第一条：评测体系迭代 Loop（评测演进）
Agent 上线后，在线评测和在线监控开始持续产出异常信号。这些信号背后的线上真实样本，经过 Case 挖掘进入 Case 池，再经过归因判断问题性质。如果归因结论是“评测集没有覆盖这类问题”，那么这个样本就应该补充进评测集；如果归因结论是“评测标准判错了”，那么迭代评测是 Metrics 和 Rubric 本身。这条 Loop 让评测集从冷启动人工搭建逐步逼近真实用户的反馈，逐步消除前文博客中提到的独裁者偏差。
第二条：Agent 迭代 Loop（Agent 演进）
同样是这批线上真实样本，经过 Case 挖掘和归因之后，定位到 Agent 本身的问题点——可能是 Prompt 写得不够明确、某个 Skill 的描述导致路由错误、上下文管理丢了关键信息，或者模型能力确实不够。研发据此做出变更，变更后用评测集回测，确认没有引入退化，再上线 AB 观察真实效果。这条 Loop 让 Agent 的能力持续提升，同时保证每次提升不以牺牲已有能力为代价。
除了 Case 挖掘和归因这个显而易见的咬合点，其实还有第二个咬合点——评测资产（评测集）。评测体系迭代 Loop 的产出是更完善的评测集，回测的门禁价值就越高；回测门禁越严格，Agent 上线后暴露的新问题就越少。从而形成正反馈。
把两条 Loop 放在一起看，完备的评测体系要同时具备三种能力，并沉淀评测资产（评测集）。
这三种能力运转起来后，会沉淀下可复用的资产，它们才是评测体系真正的长期价值。
但“什么叫好”的共识和“踩过哪些坑”的记录会随着 Agent 扩量而持续扩充。从这个意义上说，评测体系建设的本质，是把团队对业务质量的隐性认知，转化为可量化、可复用、可传递、可自动执行的显性资产。
从评测体系的视角，可以拆解出四个模块。前三个模块分别回答不同的问题，第四个模块是前三者的地基。
业界和开源领域对离线评测的定义非常清晰，而在线评测、在线监控、观测以及 Case 挖掘与归因这几个模块彼此之间存在模糊地带，例如 Arize AI、LangFuse、Braintrust 对这几个概念的划分就不尽相同。例如有的产品把“Online Evaluation”和“Monitoring”合并成一个概念，有的把 Trace 采集归入 Observability 而把 Trace 分析归入 Evaluation。
由于行业内没有形成统一的概念划分，为了方便后续讨论中的概念对齐，以及用一套框架贯穿冷启动、扩量和自进化，我们拆解出上面这四个大模块。读者在实践过程中可以按自己团队的组织方式重新切分，不漏掉任何一项职责即可。
为了让后面的讨论有实感，我们先约定一个贯穿全文的场景——商家经营分析 Agent（对应内部的商家 Claw 类场景）。
这个场景的特点是典型的长程 Agent：多步骤、多 Skill 调用、有中间产物、与环境频繁交互、没有唯一正确答案。后面每讲一个模块，我们都会回到这个例子上看它具体长什么样。
离线评测的核心作用在于 Agent 版本变更后的回测，可以作为上线前的门控。它依赖：固定评测集（固定样本和固定评测标准）、尽可能贴近生产的固定执行环境。
当 Agent Harness 的任何一个环节发生变化——模型升级、Prompt 调整、知识库更新、Skill 新增或下线——都可以通过离线评测验证效果，避免不成熟的变更导致 Agent 能力劣化。
回测的本质是控制变量对比：只让 Agent 版本变化，其他一切保持不变，这样分数的差异才能归因到版本变更上。
实践中最容易被破坏的是执行环境。比如评测时调用的是测试环境的下游接口，而测试环境的数据和生产不一致；或者沙箱里没有预置用户的历史文件，导致 Agent 拿不到必要的上下文。这类环境差异会让离线分数和线上表现系统性偏离，最终让团队不再信任离线评测。
一个实用的检验方法：拿同一批样本，分别在离线环境和线上影子流量里跑一遍，看两边的结论是否一致。差异过大，说明环境保真度不够。
广义的评测集由（问题、参考答案、评价标准）三元组构成，其中问题-参考答案合起来称作评测样本。这个概念最早出自大模型评测领域，如今被借用到 Agent 评测领域。
但随着 Agent 形态从 ChatBot 演进到长程 Agent，这三元组的具体含义也在发生迁移：
这个迁移背后是一个根本性变化：Agent 评测从“答案评测”走向“行为评测”。短程场景下，参考答案是一个可以逐字比对的字符串；长程场景下，参考答案变成了一段对执行过程的描述，评测要看的是 Agent 走过的路径是否符合预期，以及最终环境状态是否达成目标。
借用 Anthropic《Demystifying evals for AI agents》文中对长程 Agent 评测 Task 定义：为“具有明确输入和成功标准的单个测试”，这个概念同样可以泛化到短程 Agent 领域。
借用这个概念，评测集的每一行三元组都可以看做一个 Task。
具体而言 Task 里要有固定输入，比如 Query / answer，或者 prompt / expected behavior；评价部分由 Metrics 和 Rubric 构成，其中 Rubric 是最小粒度的评测标准。