Agent评测漫谈：由浅入深讲解Agent评测

本篇博客是一篇科普文章，由浅入深地介绍Agent评测。其中前两章系统介绍了评测是什么，以及如何建立评测体系；其中第二章是美团图灵Agent评测团队深入美团各业务团队BP总结出的实践经验，是团队在两年实践过程中逐步打磨出来的认知。第三章重点介绍了龙虾/爱马仕这类长程Agent框架的出现对评测带来的变化。

本篇博客在美团内部发表之后获得了较多的关注，我们发现大家对Agent评测的热情非常高，因此我们决定将内部博客进行公开，想把这些经验分享给更多的同学，希望对大家有所启发或帮助。

一、Agent评测是什么

1.1 评测的核心目的

评测的核心目的是为了回答Agent的好不好？以及到底哪里好，哪里不好？从而为下一轮迭代指明方向。评测是Agent效果的“精密量具”。

这也是为什么Agent评测不能只停留在离线打榜，更不能只看某次Demo的表现。它必须服务于真实业务中的研发、上线、回归、优化和规模化落地。

而Agent评测的基石是观测，因此我们得出了Agent研发公式——观测 + 评测 = 持续迭代。

1.2 Agent评测与传统模型评测的不同

评测方法会随着AI形态变化而变化，大致经历了三个阶段：

传统机器学习更像在回答“算得准不准”。大模型评测开始回答“模型能力强不强”。而Agent评测真正要回答的是：当模型被放进一个真实系统里，和Prompt、Skill、工具链、记忆、状态管理、业务流程耦合在一起后，它能不能稳定交付好的结果。

这意味着Agent的评测对象已经不再是单一模型，而是一个“模型 + 系统 + 工具 + 流程”的复杂系统。

1.3 为什么Agent评测不是只看结果，还要看行为和过程

在真实场景中，两个Agent可能最终都“做对了”，但工程价值完全不同：

• 一个路径清晰、工具调用稳定、耗时可控、可重复复现
• 一个反复试错、路径混乱、靠偶然命中结果、不可复现

如果只看最终答案，这两者会被误判为同一水平；但从规模化、成本优化、用户体验的角度看，差别非常大。

因此，Agent评测至少需要覆盖四层内容：

• 结果层：任务是否完成，输出是否可用
• 过程层：规划是否合理，步骤是否稳定
• 效率层：耗时、Token、工具调用次数是否可接受
• 风险层（安全层）：是否越权、是否误操作、是否存在安全隐患

从这个意义上讲，自2023年GPT爆火以来，Agent发展从ChatBot形态快速发展至ClaudCode、OpenClaw这样的多功能长程Agent，Agent能力日渐强大，Agent评测正在从“答案评测”走向“行为评测”。

1.4 为什么说观测是评测的基石

有一个朴素的认知：Agent属于广义的SaaS层，大模型赋予Agent泛化能力但也带出随机性的问题，而用户仍旧期望得到一个稳定可靠的智能体。为了弥合“随机性”与“可靠性”之间的鸿沟，我们必须回归工程视角看待Agent——看不见的问题，几乎不可能被稳定解决。

Agent的一次执行通常包含如下链路：

只要其中任意一层出问题，最终效果都可能劣化。为了结果稳定，我们需要过程稳定。但如果日志系统只能看到“用户说了什么”和“最后回复了什么”，就几乎无法判断问题根因。正是基于“我想看Case却发现没打日志”这个朴素的问题，工业界发展出了Trace系统，将黑盒内部的逻辑推理过程进行全路径的披露，将所有影响模型输出的输入信息都记录下来。

对Agent的每一个“隐形动作”进行精准观测，是实现从“概率性生成”向“工业级可靠性”跨越的必由之路。

1.5 小结：Trajectory Evaluation 与 Response Evaluation

经过前文的论述，我们知道Agent评测本质是在回答好不好，为迭代指明方向。而Agent评测本身既要关注结果（Response）也要关注过程（Trace或者叫做Trajectory）。

二、评测的核心方法论

2.1 评测体系的核心不是堆指标，而是搭桥

有的同学会好奇，为什么一定要“搭桥”？这是因为Agent评测体系必须追求业务价值与评测指标之间的解释性。而Agent评测的难点之一，是模型能力指标和业务结果指标之间有天然鸿沟。

这两类指标不能直接映射，中间必须有一层面向任务系统的桥梁指标。我们提供一种分层思路如下：

以AI搜索为例，业务可能关心DAU、留存和点击；搜索系统本身关心召回率和点击率；Agent层则关心意图识别是否准确、检索是否有效、结果整合是否可信。

只有把这些层次串起来，才能真正回答“为什么业务指标变差”以及“模型能力提升为什么没有带来业务收益”。这件事必须依赖真正懂业务流程的人来共同建立指标体系。

2.2 客观评测与主观评测并行

经过第一章的介绍，我们知道，Agent的核心目标就是要稳定地交付好的结果。行业内Agent评测大量借鉴了大模型评测的方法论，总体上可以拆成客观评测和主观评测：

因此更现实的做法通常是：

• 用客观评测覆盖高频、结构化、可规则化的部分
• 用主观评测覆盖开放性、高价值、复杂业务场景
• 用主观评测校准客观评测和AI评测，再把规模化部分交给自动化系统

2.3 使用“人人一致、人机一致”的方法论对齐主观评测

“好不好”是一个主观问题，主观的标准需要对齐，否则我们不能确定某次迭代之后，到底是指标的抖动带来的提升还是真实的效果提升。

在评测实践中，真正困难的不是“没有人会评”，而是“不同的人评得不一样，机器和人评得也不一样”。在过去一年，我们图灵团队深度BP业务方的过程中，我们发现多个团队相继踩入了相同的坑。

图灵评测积累的关键认知可以概括为“人人对齐和人机对齐”，具体如下：

• 人人一致：1个“独裁者”好过10个“民主者”。需要一位强有力的角色，拉齐产品、运营、研发、QA的评测标准，遵循同一套评测体系，避免大家各自为政。不同评测员通过背靠背标注的方法拉齐标准。
• 人机一致：机器评测结果与人工评测结果保持一致，否则不置信。人机一致的意义在于规模化提效，以应对更大的业务流量。

具体如何进行对齐呢？最佳实践是把模糊指标下钻成更细的评测Rubric（或者叫评测维度：学界关于评测维度dimension和评测规则rubric的说法尚未统一，我们这里与开源项目Arize AI对齐），再把每个Rubric尽可能二元化。具体如下：

• 指标下钻：把“大而模糊”的概念下钻拆解成多个清晰维度
• Rubric 二元化：把打分规则尽量收敛成是/否/未知、0/1/unknown
• 持续迭代：用unknown占比来反查Rubric是否定义合理，直到单条Rubric的人人一致率、人机一致率达到可信阈值（例如85%、90%）

这种拆解法的价值在于：从“主观的模糊感受”转向“可判断的事实依据”，用下钻降低模糊度，从而降低人与人之间、人与机器之间的分歧。应用这套方法，数字站长的人机一致率可以达到99%。Beam以图灵的二元化方案改造评测体系，人机一致率从62%提升到92%。

下面我们分享两个案例。

案例一：如何评价初中生作文的好坏？（满分40分）

案例二：以骑手外呼场景模型回复是否“口语化”举例

经典错误示范——请判断大模型的回答是否口语化，并按照0到10分打分。

下钻与二元化之后的改进版：

• 模型是否以您指代骑手；
• 模型是否使用“甭客气”，“明儿见”等非官方文书的口语交流词汇；
• 模型输出是否包含“吧”，“呢”，“那个”等语气词汇。

补充：标注和评测的关系是什么？

其中，标注是一种动作，而评测是一套目标导向的判断流程。机器预标注可以帮助人工提效，但只有在人机一致率保障才能称为自动化评测，否则只是机器标注。

2.4 Agent评测是一门实践科学

从执行链路看，Agent评测可以被拆成五个关键环节：

• 采集：采集线上或沙箱中的原始任务数据
• 清洗：去重、归类、补上下文、修复脏数据
• 评测：人工评测、AI评测
• 质检：检查评测标准是否稳定、评测结果是否可信
• 分析/归因：定位问题归因，形成优化建议和回归任务

这5个环节与线上AB、持续观测共同构成了Agent迭代的数据飞轮。

绝大部分新上手Agent评测团队都有一个误区——多方调研总结设计一个复杂精妙的评测指标体系，而越复杂的指标越难以执行和对齐。

而Agent评测是一门实践科学。起步阶段“让数据飞轮高效运转起来”的意义远大于“设计一个复杂精妙的评测体系”。评测体系的建立不是一蹴而就的，而是依靠Good Case和Bad Case喂养的。

因此，Agent评测指标体系的搭建最佳实践路径如下：

• 从高频核心场景起步，先定义少量关键指标
• 从生产环境中收集Bad Case
• 沉淀高质量Good Case，明确什么叫“好”
• 把Good/Bad Case转成标准评测样本
• 用评测结果反哺Prompt、Skill、策略和模型优化等等
• 再从新的线上表现里持续抽样，形成下一轮迭代

其中，Bad Case的价值往往更高，因为它最容易暴露能力边界和系统短板；而Good Case的作用则是帮助团队定义高质量完成的范式。

一个成熟的评测团队，核心能力不是一开始就搭出完美系统，而是能把线上问题、失败样本、模糊反馈不断转化成结构化评测资产。我们通过Bad Case和Good Case修正评测体系的目标，逐步修正“独裁者”与真实目标之间的负面偏差。例如履约数字站长业务，项目启动之处只有20多个评测指标，而经历1年时间推全之后，我们扩展到了近200个指标。

2.5 专家知识补充模型能力在垂域场景的不足

从GPT 3.5发布至今，虽然基座能力发生了天翻地覆的变化，但是模型能力终究不是万能的。在过去三年的Agent实践中，我们遇到过大量脱离实际的“许愿式”需求。我们要知道模型是训练出来的，模型本身拟合了Token的概率分布，即便在大规模参数下会产生能力的“涌现”，但模型能力的提升依旧强依赖语料的输入，尤其是高质量语料的输入。无论是早期的RLHF，还是如今的DPO、GRPO等算法，虽然训练架构在不断简化，但对高质量核心数据的依赖从未改变。

例如字节专门设立了众包专家标注平台Xpert，用于生产地理、代码、法律、医学等专业领域的高质量数据，以此支撑豆包基座模型的迭代训练。基座模型能力的提升，大家的直观感受就是它在一个又一个垂直领域的表现越来越好。

因此，当我们在特定垂域面临业务知识语料匮乏（或公网无公开高质数据）的挑战时，通过引入行业专家的知识输入来补足模型/Agent的能力，就成了破局的关键——尤其是在项目的冷启动阶段。

呼应前文，评测的目的是回答“Agent好不好”，那么谁来定义“好不好”呢？靠最懂业务最有Sense的行业专家。

2.6 小结&FAQ

这个章节讲述的是图灵评测从履约的项目出发，又经过这1年多BP公司各个业务方的过程中沉淀的核心方法论。

FAQ

Q1：“独裁者”必须是1个人吗，还是1个团队共同遵循一套评测规范即可？

首先一个团队需要遵循同一套评测体系。独裁者的作用多方征求意见并整合评测体系，当项目方观念无法对齐的时候，由独裁者拍板定论，避免评测体系分化带来项目方各自为政以及内部拉扯带来的损耗。

Q2：评测体系依赖“独裁者”，存不存在风险？

我们要认清一个事实，评测体系是不断演进的。从业务冷启动到扩量再到全量，这个过程中用户从愿意尝鲜的AI爱好者扩展到全部用户，用户画像会发生明显的偏移。这导致评测目标需要随着业务的扩量不断地发生调整。独裁者的价值更多的体现在拉齐标准，评测目标更多的是由真实的业务场景中BadCase/Good Case修正并驱动的。当然，我们需要在评测标准建立之初选出最懂业务的人来制定评测体系。

Q3：冷启动阶段一定要设立种子评测集吗？能不能直接小流量开灰上线，直接收集Good Case和Bad Case来驱动评测呢？

冷启动阶段是否必须设立种子评测集，本质上是一个风险与成本的Trade-Off。

为什么建议设立种子集：大模型具有随机性，Corner Case可能会导致Agent体验剧烈偏移。因此，需要通过回测保证Agent基线能力，不断融入Good Case和Bad Case来拓宽Agent的能力边界。

关于小流量开灰的策略：如果业务场景容错率高，或者构建高质量种子集的成本远超线上试错带来的负面反馈，可以尝试小流量上线收集线上case。

推荐落地方案：人工生产少量评测集后，AI辅助生成或扩写，以较低成本完成冷启动的种子评测集构建。

Q4：我们邀请的行业专家对“好”的定义不一致应该怎么办？

答：最朴素且有效的方法，邀请一批行业专家定义“好”的标准，从中抽取共性的部分建设评测体系。例如邀请金牌销售来定义优秀的销售SOP。

那么非共性的部分就没有价值了吗？并非如此。对于专家意见不一致的部分，往往意味着业务本身存在多种优秀策略。我们可以将这些分歧转化为Agent的不同风格或策略分支（例如：AI电销中，老练激进派 vs 细水长流派），并允许在不同的测试集（Benchmark）中独立评测。这些分歧点非但不是噪声，反而会成为Agent未来走向精细化迭代、覆盖更多长尾场景的重要养分。

三、Agent观测评测的演进

2023年GPT爆火，2024年工作流出现，去年Claude Code发布，再到今年的龙虾热、爱马仕热，长程Agent逐渐进入了大众视野。Agent Harness也全面进入长程Agent时代。

长程Agent（Long-horizon Agent）与短程Agent的区别，在于它如何处理“时间跨度带来的复杂性”：

这些差异会为观测评测带来怎样的变化呢？

3.1 短程Agent时代的观测评测

短程Agent时代的评测对象相对简单。ChatAgent时代的典型输入输出形态是：Query -> Answer。

这类场景的共同特点是：Agent更多是在“回答问题”，进行少量的系统操作，而不是“进入操作系统执行任务”。典型应用场景，例如AI搜索、客服机器人。此类Agent评测重点通常落在回答本身，例如：

在过去1年的发展中图灵形成了成熟的解决方案，包括人工评测、机器评测，部分案例如下：

3.2 长程Agent的观测评测

3.2.1 长程Agent带来评测范式变化

长程Agent解决的不是“回答一个问题”，而是“完成一个复杂任务”。它通常需要：