本篇博客是一篇科普文章，由浅入深的介绍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 解决的不是“回答一个问题”，而是“完成一个复杂任务”。它通常需要：
- 任务需要多步骤拆解
- 执行过程中需要多次调用 Tool 或 Skill
- 需要读取中间结果并动态调整策略
让我们回顾一下观测和评测的目标，带着这个目标去看长程Agent
- 观测目标：还原现场，精确定位，解决“我想看Case却发现没打日志”的问题
- 评测目标：回答Agent好不好，指出迭代方向
3.2.2 Skill评测
在讲Skill评测之前，我们先分享一下我们关于26年春节后这一轮龙虾/Skill热潮的调研。
谁在提出龙虾和Skill的评测需求（2月至今龙虾/Skill热潮的用户画像）？
总结起来目前龙虾和Skill相关需求主要 广义的运营提效 场景，大致可以分成三类：
用户规模正在从少量专业角色扩展到更广人群
- 商家侧仍在探索和试点阶段，规模有限
- 公司内部AI at Work系统中的龙虾（或其他长程Agent）融合更广，用户覆盖产、运、研、销等多类角色
- Skill 的开发门槛越来越低，甚至可以由 AI 辅助生成
这会带来一个直接结论：
未来需要评测的人，不只是一小撮产运研同学，而可能是每一个会创建、修改、接入 Skill 的人。
这对评测系统提出了新的要求：
- 要足够简单
- 要足够标准化
- 要足够自动化
- 最好能接入开发与发布流程
当前的本质痛点
本质在于 —— 大家不知道怎样写好 Skill，也缺乏对 Skill 全生命周期进行评测的工具。
为了方便大家理解，我们将Skill全生命周期拆解如下：
综上，Skill评测的痛点总体可以拆解成三个方面：
面向Task的评测
2026年1月9号，Anthropic发表了一篇博客揭秘AI Agent评估，在这篇博客中首次提到了面向Task的长程Agent评测。文中对Task，定义为“具有明确输入和成功标准的单个测试”。
我们综合了Anthropic以及开源软件对Task的定义，简化如下。
prompt定义了我们的问题/诉求，expeted behavior定义了我们预期Agent达成的行为，当我们在正式或测试环境中向Agent发送promt，通过trace获取到长程Agent真实的执行路径，就可以得到（prompt - expeted_behavior - trace）三元组，类似于短程Agent的（query - ground_truth - answer），即可进行评测。
3.2.3 长程Agent评测与短程Agent评测的差异
可以把两者的差异总结如下：
最本质的变化是：
ChatAgent 评测关心“说得好不好”，长程 Agent 评测关心“事情做成没有，以及是怎么做成的”。
3.2.4 人评主导走向机评主导
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 评测体系。
附：长程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月，龙虾在全球爆火时候，社区涌现出面向龙虾评测的开源软件：
| 软件名称 | 简介 | GitStar | task定义 |
|---|---|---|---|
| pinchbench | 2026年2月开源，是一套专门用于评估OpenClaw的性能基准测试系统。与传统的合成测试（Synthetic Tests）不同，PinchBench 强调“真实场景下的任务模拟”。它通过给 AI 代理布置实际工作中会遇到的复杂任务，来衡量模型在处理多步工作、实际开发与办公环境下的真实表现。 | 1200+ | md文件 |
| claw eval | 北大发布的龙虾能力评测 task列表  |
500 | yaml文件 |
| WildClawBench | WildClawBench：野生环境 AI Agent 能力评测 10 大模型谁的"龙虾"最强？核心理念是"在野生环境中测试 Agent"——不是给模型一个精心设计的沙盒，而是把它扔进真实用户每天使用 OpenClaw Agent 的场景中，看它能不能活下来。 | 500 | Skill |
