美团图灵两年实践总结：Agent评测体系搭建方法论

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

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

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

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

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

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

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

传统机器学习更像在回答"算得准不准"。大模型评测开始回答"模型能力强不强"。而 Agent 评测真正要回答的是：

当模型被放进一个真实系统里，和 Prompt、Skill、工具链、记忆、状态管理、业务流程耦合在一起后，它能不能稳定交付好的结果。

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

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

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

一个路径清晰、工具调用稳定、耗时可控、可重复复现

一个反复试错、路径混乱、靠偶然命中结果、不可复现

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

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

效率层：耗时、Token、工具调用次数是否可接受

风险层（安全层）：是否越权、是否误操作、是否存在安全隐患

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

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

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

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

1.5 小结：Trajectory Evaluation 与 Response Evaluation

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

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

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

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

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

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

经过第一章的介绍，我们知道，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 分打分。

模型是否使用"甭客气"，"明儿见"等非官方文书的口语交流词汇；

模型输出是否包含"吧"，"呢"，"那个"等语气词汇。

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

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

质检：检查评测标准是否稳定、评测结果是否可信

分析/归因：定位问题归因，形成优化建议和回归任务

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

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

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

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

沉淀高质量 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 的行业专家。

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

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

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

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

我们要认清一个事实，评测体系是不断演进的。从业务冷启动到扩量再到全量，这个过程中用户从愿意尝鲜的 AI 爱好者扩展到全部用户，用户画像会发生明显的偏移。这导致评测目标需要随着业务的扩量不断地发生调整。独裁者的价值更多的体现在拉齐标准，评测目标更多的是由真实的业务场景中 Bad Case/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 未来走向精细化迭代、覆盖更多长尾场景的重要养分。

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

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

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

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

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

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

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

执行过程中需要多次调用 Tool 或 Skill

让我们回顾一下观测和评测的目标，带着这个目标去看长程 Agent

观测目标：还原现场，精确定位，解决"我想看 Case 却发现没打日志"的问题

评测目标：回答 Agent 好不好，指出迭代方向

在讲 Skill 评测之前，我们先分享一下我们关于 26 年春节后这一轮龙虾/Skill 热潮的调研。

谁在提出龙虾和 Skill 的评测需求（2 月至今龙虾/Skill 热潮的用户画像）？

总结起来目前龙虾和 Skill 相关需求主要 广义的运营提效 场景，大致可以分成三类：

公司内部 AI at Work 系统中的龙虾（或其他长程 Agent）融合更广，用户覆盖产、运、研、销等多类角色

Skill 的开发门槛越来越低，甚至可以由 AI 辅助生成

未来需要评测的人，不只是一小撮产运研同学，而可能是每一个会创建、修改、接入 Skill 的人。

本质在于 —— 大家不知道怎样写好 Skill，也缺乏对 Skill 全生命周期进行评测的工具。

为了方便大家理解，我们将 Skill 全生命周期拆解如下：

综上，Skill 评测的痛点总体可以拆解成三个方面：

2026 年 1 月 9 号，Anthropic 发表了一篇博客揭秘 AI Agent 评估，在这篇博客中首次提到了面向 Task 的长程 Agent 评测。文中对 Task，定义为"具有明确输入和成功标准的单个测试"。

我们综合了 Anthropic 以及开源软件对 Task 的定义，简化如下。

Prompt 定义了我们的问题/诉求，expected behavior 定义了我们预期 Agent 达成的行为，当我们在正式或测试环境中向 Agent 发送 prompt，通过 trace 获取到长程 Agent 真实的执行路径，就可以得到（prompt - expected_behavior - trace）三元组，类似于短程 Agent 的（query - ground_truth - answer），即可进行评测。

3.2.3 长程 Agent 评测与短程 Agent 评测的差异

ChatAgent 评测关心"说得好不好"，长程 Agent 评测关心"事情做成没有，以及是怎么做成的"。

ChatAgent 时代常见流程是：核心评测员对齐 -> 外包对齐 -> 机评对齐

而在长程 Agent 场景下，这条链路有机会被明显缩短，甚至可以跳过外包对齐，直接进入：核心评测员对齐 -> 机评对齐 -> 规模化扩展

长程 Agent 的执行轨迹更丰富，信息密度高使人成为卡点

Skill 生产门槛低，数量增长极快，人工大规模标注不可持续

人工更应该做高价值标准设计和 Rubric 对齐

AI 更适合承担规模化运行、初筛和回归验证

换句话说，AI 评测真正要放大的，不是"机器打分"本身，而是核心评测员的判断标准。

3.2.5 长程 Agent 评测基建至少应该具备哪些能力

如果未来要支撑公司内大规模 Agent 和 Skill 生态，评测基础设施至少应包含以下能力：

全链路回放：复现一次任务从输入到结果的全过程

Case 管理：统一维护任务样本、上下文、约束和 Rubric

执行沙箱：按只读、可写、高风险等类型分层隔离执行

AI 评测引擎：支持 Rubric 驱动的人机对齐和自动判分，且足够简单易用，方便广大 Skill 生产者接入

报告与归因：不仅给分，还能指出问题发生在规划、工具、环境还是 Skill

回归机制：版本升级后自动触发历史 Case 回归

准入准出门禁：把评测结果嵌入开发、发布和运营流程

如果缺少这些能力，评测就容易停留在"单次分析"和"项目制支持"层面，无法真正成为生产系统的一部分。

四、总结：Agent 评测正在从打分动作走向基础设施能力

综合来看，随着大模型能力的增强以及 Agent Harness 的持续演进，Agent 评测的演进可以概括为两句话：

过去评测的是"回答"，现在评测的是"任务系统"。

因此我们关心的不再只是输出内容本身，而是完整执行链路中的能力、稳定性、效率与风险。

过去主流是 Query -> Answer 的文本质量评测，现在逐步转向 Prompt -> Expected Behavior 的行为评测。

标准答案不再总是唯一，过程质量、任务完成度和轨迹质量成为新的核心对象。

因此，未来真正重要的，不只是能不能做几次评测，而是能不能建设出一套：看得见问题、说得清标准、跑得动规模、接得上流程、带得动迭代的 Agent 评测体系。

任务（Task，也称 Problem 或 Test Case）：具有明确输入和成功标准的单个测试。每次尝试任务的行动称为试验（Trial）。由于模型输出在不同运行之间会有变化，我们运行多次试验以产生更一致的结果。

评分器（Grader）是评估 Agent 性能某些方面的逻辑。一个任务可以有多个评分器，每个评分器包含多个断言（有时称为检查 Checks）。

记录（Transcript，也称 Trace 或 Trajectory）：试验的完整记录，包括输出、工具调用、推理、中间结果和任何其他交互。

结果（Outcome）：试验结束时环境的最终状态。航班预订 Agent 可能在记录末尾说"您的航班已预订"，但结果是环境中 SQL 数据库中是否存在预订记录。

评估框架（Evaluation Harness）：端到端运行评估的基础设施。它提供指令和工具、并发运行任务、记录所有步骤、评分输出并汇总结果。

Agent 框架（Agent Harness，或 Scaffold）：使模型能够作为 Agent 运行的系统：处理输入、编排工具调用并返回结果。当我们评估"一个 Agent"时，我们是在评估框架和模型协同工作。例如，Claude Code 是一个灵活的 Agent 框架，我们通过 Agent SDK 使用其核心原语构建了我们的长时间运行 Agent 框架。

评估套件（Evaluation Suite）：旨在测量特定能力或行为的任务集合。套件中的任务通常共享一个广泛的目标。例如，客户支持评估套件可能测试退款、取消和升级。

2026 年 2 月，龙虾在全球爆火时候，社区涌现出面向龙虾评测的开源软件：