摘要：

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

一、Agent评测是什么

1.1 评测的核心目的

评测的核心目的是为了回答 Agent 好不好？以及哪里好，哪里不好？ 从而为下一轮迭代指明方向。

Agent 评测必须服务于真实业务中的研发、上线、回归、优化和规模化落地。

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

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

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

传统机器学习更像在回答“预测准不准”；大模型评测开始回答“模型能力强不强”；而 Agent 评测真正要回答的是：

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

这意味着 Agent 评测对象不只是单一模型，而是一个完整的复杂系统

1.3 Agent评测不只看结果，还要看行为和过程（核心）

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

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

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

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

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

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

有一个朴素的认知：Agent 属于广义的 SaaS 层，大模型赋予Agent泛化能力但也增加了随机性，而用户期望得到稳定可靠的智能体。为了平衡“随机性”与“可靠性”，必须回归工程视角看待Agent —＂看不见＂（不可观测）的问题，几乎不可能被稳定解决。

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

只要其中任意一层出问题，最终效果都可能劣化。结果稳定需要过程稳定。如果日志系统只能看到“用户说了什么”和“最后回复了什么”几乎无法判断问题根因。正是由于“我想看Case却发现没打日志”这个朴素问题发展出了 Trace 系统。将模型推理步骤披露出来，将影响模型输出的输入都记录下来。

二、评测核心方法论

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

为什么一定要“搭桥”？因为评测Agent好不好要能说清它能不能给业务带来好处。而Agent 评测的难点之一是模型能力指标和业务结果指标脱节、对不上。

这两类指标不能直接映射，中间必须有一层面向任务系统的Agent能力指标。分层思路如下：

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

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

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

Agent的核心目标就是要稳定地交付结果。业内 Agent 评测大量借鉴了大模型评测方法，总体上可以拆成客观评测和主观评测：

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

• 高频、结构化、可规则化的部分交给客观评测
• 开放性、直接影响收益的复杂业务场景交给主观评测
• 用主观评测校准客观评测。

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

“好不好”是一个主观问题，主观的标准需要不同人对齐，否则不能确定迭代后真实效果是否提升。

在评测实践中，真正困难不是“没有人会评”，而是“不同人评得不一样，机器和人评得也不一样”

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

• 人人一致：1个“犭虫裁者”好过10个“民主者”。需要一位强有力的角色，拉齐产品、运营、研发、QA的评测标准，遵循同一套评测体系，避免各自为政。

• 人机一致：机器评测结果与人工评测结果保持一致，否则不置信。人机一致的意义在于规模化提效，以应对更大的业务流量。

具体如何进行对齐？最佳实践是把模糊指标拆成更细的“评测细则Rubric”，再把每个Rubric尽可能二元化。具体如下：

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

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

下面我们分享两个案例。

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

主观的＂好坏＂可以拆解为四个指标

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

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

正确做法：拆解＋二元化之后：

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

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

标注是一种动作，而评测是一套目标导向的判断流程。机器预标注可以帮助人工提效，但只有在人机一致率极高时才能用于规模化提效，否则只是机器做无用功。

2.4 Agent评测是在实践中逐步优化的

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

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

这5个环节与线上AB测试、持续观测共同构成了Agent评测迭代闭环。

绝大部分新上手Agent评测的团队都有一个误区：＂一开始＂就多方调研设计出一个复杂的评测指标体系，但越复杂的指标其实越难执行和对齐。

但Agent评测是一门实践科学。＂先让评测系统循环起来”的意义远大于“一开始就设计看起来精妙的复杂评测体系”。成熟评测体系不是一蹴而就，而是靠 Good Case 和 Bad Case 逐步喂出来的。

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

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

其中，Bad Case 的价值往往更高，因为它直接暴露出系统短板；

一个成熟的评测团队，核心能力不是一开始就搭出完美系统，而是能把线上问题、失败样本、模糊反馈不断转化成结构化评测资产。例如履约数字站长业务，项目启动时只有20多个评测指标，而经历1年时间推全之后，我们扩展到了近200个指标。

2.5 专家知识补充模型能力在垂直领域不足

模型能力提升强依赖语料输入，尤其是高质量语料。无论是早期的RLHF，还是如今的DPO、GRPO等算法，虽然训练架构在不断简化，但对高质量核心数据的依赖从未改变。

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

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

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

2.6 FAQ

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

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

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

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

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

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

为什么建议设立种子集：刁钻问题可能导致Agent答的离谱。因此需要保证Agent基线能力，然后才考虑不断融入Good Case和Bad Case来拓宽Agent的能力边界。

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

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

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

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

专家意见不一致的部分，往往意味着业务本身存在多种优秀策略。可以将这些分歧转化为 Agent 不同风格或策略分支（如：AI电销中，老练激进派 vs 细水长流派），并允许在不同的测试集中独立评测。这些分歧点不仅不是噪声，反而会成为 Agent 未来走向精细化迭代、覆盖更多长尾场景的重要资产。

三、Agent观测评测的演进

今年的龙虾热、爱马仕热，长程Agent逐渐进入大众视野。Agent Harness也全面进入长程Agent时代。

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

3.1 短程Agent的观测评测

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

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

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

3.2 长程Agent的观测评测

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

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

• 任务需要多步骤拆解
• 执行过程中需要多次调用 Tool 或 Skill
• 需读取中间结果并动态调整策略

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

• 观测目标：还原现场，精确定位，解决“我想看Case却发现没打日志”的问题
• 评测目标：Agent行为和过程好不好，指明迭代方向

3.2.2 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评测的差异

可以把两者的差异总结如下：

最本质的变化是短程问答Agent 评测关心“说得好不好”，长程 Agent 评测关心“事情做成没有，以及是怎么做成的”

3.2.4 人评主导走向机评主导

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

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

原因主要有三点：

• 长程 Agent 的执行轨迹更丰富，信息密度高使“人的精力”成为卡点
• Skill 生产门槛低，数量增长极快，人工大规模标注不可持续
• 基座模型能力的持续突破

这并不意味着人工不重要，而是分工不同：

• 人工更应该做“高价值标准设计”和评测细则Rubric对齐
• AI 负责承担规模化运行、初筛和回归验证
• 系统平台负责存数据、复现问题、异常提醒、定位出错原因。

换句话说：AI 评测重点不是让机器自动打分，而是把核心评测员定下的标准大规模复用起来。

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

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

• 全链路回放：能完整还原一次任务从输入到结果的全过程
• Case 管理：集中存放测试样本、对话上下文、约束和评测细则Rubric
• 执行沙箱：按只读、可写、高风险等类型分层隔离执行
• AI 评测引擎：支持 Rubric 驱动的人机对齐和自动判分，且足够简单易用
• 报告与归因：不仅给分，还能指出问题发生在规划、工具、环境还是 Skill
• 回归机制：版本升级后自动跑一遍历史 Case
• 准入准出门禁：把评测结果作为开发、发布的硬性门槛

如果缺少这些能力，评测只能单独给单个项目临时分析，没法融入日常线上生产流程常态化使用。

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

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

第一，评测对象变了

过去评测的是“回答质量”，现在评测的是“任务系统”。

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

第二，评测方法变了

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

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

因此，未来真正重要的是能不能建设出一套：看得见问题、说得清标准、批量规模化、能迭代优化的 Agent 评测体系。