AI 面试知识体系

012：美团 Agent 评测方法论和白皮书（微信文章归档）

本文档收录微信公众号「美团技术团队」（meituantech，__biz=MjM5NjQ5MTI5OA==）两篇 Agent 评测系列文章全文（含全部图片），内

本文档收录微信公众号「美团技术团队」（meituantech，__biz=MjM5NjQ5MTI5OA==）两篇 Agent 评测系列文章全文（含全部图片），内容原样保留，未做摘要或改写。

篇目 文章 微信发布时间 微信原文链接 美团技术博客原文
文章一（方法论） 《Agent评测漫谈 —— 由浅入深讲解Agent评测》 2026-08-06 10:24 https://mp.weixin.qq.com/s/gZKWRqznB8sNBFf69fBIvw https://tech.meituan.com/2026/08/07/Agent-Evaluation.html
文章二（白皮书系列01） 《Agent 评测白皮书》系列01：Agent 评测全览 2026-09-10 10:24 https://mp.weixin.qq.com/s/hBSIPQnsBeWwX9UZLjWYFA https://tech.meituan.com/2026/09/10/Agent-Evaluation-White-Paper-01.html

说明： - 文章一对应微信链接（__biz=MjM5NjQ5MTI5OA==&mid=2651783112&idx=1&sn=785b0bc4b98c0324a528cb87717f3032&scene=21&poc_token=HFOMo2qjDqiZNvB7vubc9UczlKCjcjVvbYnKbo-S），该链接含会话级 poc_token，过期后无法直接访问；正文取自同一篇的微信原文（gZKWRqznB8sNBFf69fBIvw），内容一致。 - 两篇文章均首发于美团技术团队官方博客（tech.meituan.com），微信版在此基础上增加了"全文速读"、目录与推广元素。 - 图片存放在同目录 012_美团Agent评测方法论和白皮书_images/ 下，文件名前缀 man_ 对应文章一、wp_ 对应文章二，均以相对路径引用。

📑 目录

第一部分｜文章一：Agent评测漫谈 —— 由浅入深讲解Agent评测（美团 Agent 评测方法论）

📎 内容来源

项目 内容
来源平台 微信公众号「美团技术团队」（meituantech）
微信原文 《Agent评测漫谈 —— 由浅入深讲解Agent评测》
官方博客 美团技术博客 · Agent评测漫谈
发布时间 2026-08-06 10:24（微信）

点亮👆“☆”星标，不错过推送内容~

全文速读

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

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

🎈我们还在文末增加了读者互动环节，欢迎大家晒出自己的见解、思考，分享实践经验，一起交流学习。

本文目录

1 Agent评测是什么

1.1 评测的核心目的

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

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

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

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

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

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

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

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

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

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

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

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

从这个意义上讲，自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 评测的核心方法论

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

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

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

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

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

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

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

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

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

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

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

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

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

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

下面我们分享两个案例。

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

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

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

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

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

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

2.4 Agent评测是一门实践科学

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

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

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

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

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

其中，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 未来走向精细化迭代、覆盖更多长尾场景的重要养分。

3 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 解决的不是“回答一个问题”，而是“完成一个复杂任务”。它通常需要：

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

3.2.2 Skill评测

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

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

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

用户规模正在从少量专业角色扩展到更广人群

这会带来一个直接结论：

未来需要评测的人，不只是一小撮产运研同学，而可能是每一个会创建、修改、接入 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 场景下，这条链路有机会被明显缩短，甚至可以跳过外包对齐，直接进入：核心评测员对齐 -> 机评对齐 -> 规模化扩展

原因主要有三点：

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

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

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

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

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

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

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

第一，评测对象变了

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

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

第二，评测方法变了

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

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

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

5 附：长程Agent评测开源领域的行业调研

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

欢迎大家积极留言，分享自己在评测过程中踩过的坑，也欢迎大家对文中评测核心方法论发表自己的看法或者见解。

----------  END  ----------

推荐阅读

| 用Agent评测思路管理AI Coding —— 31万行代码AI重构的实践

| 美团正式发布 CatPaw：全场景 AI Agent，从个人提效到企业智能化

| 正式开源！美团 LongCat-2.0 同步开放国产卡推理代码

❤️❤️❤️ 如果这篇文章对你有帮助，欢迎大家帮忙点赞、评论，分享给更多的小伙伴。⬇️

第二部分｜文章二：《Agent 评测白皮书》系列01：Agent 评测全览

📎 内容来源

项目 内容
来源平台 微信公众号「美团技术团队」（meituantech）
微信原文 《Agent 评测白皮书》系列01：Agent 评测全览
官方博客 美团技术博客 · Agent 评测白皮书系列01
发布时间 2026-09-10 10:24（微信）

点亮👆“☆”星标，不错过推送内容~

全文速读

前不久，我们发布了一篇《Agent评测漫谈》，收到最多的反馈是：方法论看懂了，但落到自己项目上还是不知道从哪下手。于是我们推出了《Agent评测白皮书》系列博客，体系化地为大家讲解评测的落地指南，分为《评测全览》、《冷启动篇》、《扩量篇》、《自进化篇》等共4篇，本文为系列的第一篇。

本系列博客面向 Agent 产品、研发、算法、运营和评测负责人。我们给出的做法来自我们评测团队在美团多个业务的实践，它们在各自的场景里被验证有效，但迁移到新场景时仍然需要结合业务特点做调整。比起照搬步骤，更值得关注的是每个做法背后要解决的问题。理解了问题，做法自然可以因地制宜。

🎈我们还在文末增加了读者互动环节，欢迎大家晒出自己的见解、思考，分享实践经验，一起交流学习。

本文目录

6 综述

6.1 搭一个 Agent 正在变得越来越容易

过去三年，有两条趋势在同时发生。

一是基座模型的能力持续进化，它带来的结果是对使用者的要求在往下降。早期要让模型稳定地按格式输出、正确地选中一个工具，需要反复打磨 Prompt、设计各种兜底。现在这些能力越来越多地由模型本身承担，长上下文、原生工具调用、更强的指令遵循和多步推理，把大量原本需要工程去补的地方补上了。

二是 Agent 框架的功能持续丰富。从早期需要自己实现规划、记忆、工具注册和状态管理，到现在框架和协议层把这些抽象成标准组件，接一个工具、加一个 Skill，工作量都在显著下降。

两条曲线叠加，结论很直接：搭建 Agent 门槛正在逐年降低。这带来的直接变化是 Agent 落地场景越来越多，越来越发散。

6.2 评测认知的稀缺

自 2022 年底 ChatGPT（基于 GPT-3.5）发布以来，市场上出现了一波又一波 Agent 项目。但是那些真正走过冷启动、完成灰度扩量、推到全量的项目数量屈指可数。这导致掌握 Agent 评测方法的人非常稀缺。

过去三年绝大部分 Agent 项目都死掉了。它们消失的原因有一些共性：

这三种死法看起来不同，追下去会发现共同点：团队缺少一套可靠的判断机制。不知道当前版本行不行，不知道问题出在哪一层，不知道改完是真的变好还是换了个地方出错，也不知道怎么向外证明这件事的价值。做决策靠的是感觉和个别案例，而感觉在复杂系统面前不可靠。

把两件事放在一起看，会得到一个略显割裂的图景：搭 Agent 的门槛在快速降低，把 Agent 做好的认知却仍十分稀缺。并且，有限的评测认知面对发散的场景，同样力不从心。做好一个 ChatBot 的经验，并不能无缝泛化到做一个长程 Agent 身上。为此，我们希望将团队两年来在众多业务方中打磨出的评测的认知，以体系化的形式分享给大家，希望能帮大家少走一些弯路。

6.3 这个系列博客想做什么

前不久，我们发布了一篇博客《Agent 评测漫谈》，介绍了评测的核心方法论，回答的是“评测是什么、为什么这么做”。文章发出后，我们收到不少的反馈，其中出现频率最高的一类是：方法论看了，但具体到自己的项目，还是不知道从哪下手。

为此，我们计划撰写《Agent 评测白皮书》系列博客，体系化地为大家讲解评测的落地指南 —— 先做什么后做什么，每一步的产出物长什么样，做到什么程度算达标，遇到常见的坑怎么处理。计划分四篇：

本系列博客面向 Agent 产品、研发、算法、运营和评测负责人。如果你正在从零开始搭一个 Agent，或者手里的项目卡在某个阶段推不动，希望这几篇能提供一些可以直接用上的东西。

这里也需要强调一下：评测是一门实践科学，本系列给出的做法来自我们评测团队在美团多个业务的实践，它们在各自的场景里被验证有效，但迁移到新场景时仍然需要结合业务特点做调整。比起照搬步骤，更值得关注的是每个做法背后要解决的问题。理解了问题，做法自然可以因地制宜。

7 前言

第一篇《评测全览》目的在于让大家系统地了解评测的构成，我们用一套统一的语言对齐行业内尚在发散和纠缠的概念，用一套叙事逻辑打通冷启动、扩量和自进化。有了全览之后，大家可以以终为始，判断自己现在处在哪里、下一步补哪一块。完备的评测体系可以概括为四个模块、三种能力、两条 Loop、一套资产。

8 完备的评测体系是什么样子

8.1 回到原点：评测是 Agent 效果的“精密量具”

评测的核心目的是回答两个问题：Agent 好不好？到底哪里好、哪里不好？前者给出判断，后者指明方向。一套完备的评测体系必须同时回答这两个问题。

在《Agent 评测漫谈》一文中，我们认为评测是一套“精密量具”，这个类比其实包含两个隐喻：

第二点是评测贴近真实业务场景、消除独裁者偏差的关键手段，但却是最容易被忽略的。

8.2 两条相互咬合的 Loop

理想的评测体系是一套持续运转的系统。它由两条 Loop 构成，二者共享同一批线上真实样本，通过 Case 挖掘与归因这个枢纽相互咬合。

第一条：评测体系迭代 Loop（评测演进）

Agent 上线后，在线评测和在线监控开始持续产出异常信号。这些信号背后的线上真实样本，经过 Case 挖掘进入 Case 池，再经过归因判断问题性质。如果归因结论是“评测集没有覆盖这类问题”，那么这个样本就应该补充进评测集；如果归因结论是“评测标准判错了”，那么迭代评测是 Metrics 和 Rubric 本身。这条 Loop 让评测集从冷启动人工搭建逐步逼近真实用户的反馈，逐步消除前文博客中提到的独裁者偏差。

第二条：Agent 迭代 Loop（Agent 演进）

同样是这批线上真实样本，经过 Case 挖掘和归因之后，定位到 Agent 本身的问题点——可能是 Prompt 写得不够明确、某个 Skill 的描述导致路由错误、上下文管理丢了关键信息，或者模型能力确实不够。研发据此做出变更，变更后用评测集回测，确认没有引入退化，再上线 AB 观察真实效果。这条 Loop 让 Agent 的能力持续提升，同时保证每次提升不以牺牲已有能力为代价。

除了 Case 挖掘和归因这个显而易见的咬合点，其实还有第二个咬合点——评测资产（评测集）。评测体系迭代 Loop 的产出是更完善的评测集，回测的门禁价值就越高；回测门禁越严格，Agent 上线后暴露的新问题就越少。从而形成正反馈。

8.3 评测体系的三种能力

把两条 Loop 放在一起看，完备的评测体系要同时具备三种能力，并沉淀评测资产（评测集）。

评测资产（评测集）：

这三种能力运转起来后，会沉淀下可复用的资产，它们才是评测体系真正的长期价值。

但“什么叫好”的共识和“踩过哪些坑”的记录会随着 Agent 扩量而持续扩充。从这个意义上说，评测体系建设的本质，是把团队对业务质量的隐性认知，转化为可量化、可复用、可传递、可自动执行的显性资产。

8.4 评测体系的构成

从评测体系的视角，可以拆解出四个模块。前三个模块分别回答不同的问题，第四个模块是前三者的地基。

关于模块划分的说明 业界和开源领域对离线评测的定义非常清晰，而在线评测、在线监控、观测以及 Case 挖掘与归因这几个模块彼此之间存在模糊地带，例如 Arize AI、LangFuse、Braintrust 对这几个概念的划分就不尽相同。例如有的产品把“Online Evaluation”和“Monitoring”合并成一个概念，有的把 Trace 采集归入 Observability 而把 Trace 分析归入 Evaluation。 由于行业内没有形成统一的概念划分，为了方便后续讨论中的概念对齐，以及用一套框架贯穿冷启动、扩量和自进化，我们拆解出上面这四个大模块。读者在实践过程中可以按自己团队的组织方式重新切分，不漏掉任何一项职责即可。

一个贯穿全文的例子

为了让后面的讨论有实感，我们先约定一个贯穿全文的场景——商家经营分析 Agent（对应内部的商家 Claw 类场景）。

这个场景的特点是典型的长程 Agent：多步骤、多 Skill 调用、有中间产物、与环境频繁交互、没有唯一正确答案。后面每讲一个模块，我们都会回到这个例子上看它具体长什么样。

9 离线评测：变更的门控

离线评测的核心作用在于 Agent 版本变更后的回测，可以作为上线前的门控。它依赖：固定评测集（固定样本和固定评测标准）、尽可能贴近生产的固定执行环境。

当 Agent Harness 的任何一个环节发生变化——模型升级、Prompt 调整、知识库更新、Skill 新增或下线——都可以通过离线评测验证效果，避免不成熟的变更导致 Agent 能力劣化。

为什么强调“固定” 回测的本质是控制变量对比：只让 Agent 版本变化，其他一切保持不变，这样分数的差异才能归因到版本变更上。 实践中最容易被破坏的是执行环境。比如评测时调用的是测试环境的下游接口，而测试环境的数据和生产不一致；或者沙箱里没有预置用户的历史文件，导致 Agent 拿不到必要的上下文。这类环境差异会让离线分数和线上表现系统性偏离，最终让团队不再信任离线评测。 一个实用的检验方法：拿同一批样本，分别在离线环境和线上影子流量里跑一遍，看两边的结论是否一致。差异过大，说明环境保真度不够。

9.1 评测集：评测体系的核心资产

9.1.1 评测集的构成

广义的评测集由（问题、参考答案、评价标准）三元组构成，其中问题-参考答案合起来称作评测样本。这个概念最早出自大模型评测领域，如今被借用到 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 是最小粒度的评测标准。

一个完整的 Task 大致长这样：

《Agent 评测漫谈》中强调的二元化 Rubric思路就是用在这里的：把“这个 PPT 做得好不好”这种模糊判断，下钻成一组可以回答是/否的具体检查项，从而将模糊的问题尽可能量化，消除分歧。人人一致率和人机一致率的提升，本质上都来自这种下钻。

9.1.2 评测集的分类：端到端与过程

评测集总体上可以分成两类：端到端评测集和过程评测集。每一个评测集都由上文的三元组构成。

对于端到端评测和过程评测，都可以建立我们常说的黄金集、必过集，这两套概念彼此独立不冲突。

为什么两类都需要？端到端评测集看的是最终结果，重点回答“事有没有办成”；过程评测集看执行过程，回答的是“中间哪一步出了问题”。回到商家经营分析的例子。端到端评测集告诉你“100 个任务里有 68 个交付了可用的 PPT”，端到端交付率是业务方最关心的数字。但当这个数字从 68 掉到 55 时，端到端评测集无法告诉你原因。而过程评测集可以：如果“投放数据 Skill 调用成功率”从 95% 掉到 70%，问题就定位到了；如果 Skill 成功率没变、但“数据合并正确率”下降，问题就在另一处。若过程评测集指标未发生波动，但端到端交付率降低，则说明发生了未知异常，需要我们进一步挖掘和归因从而迭代评测集。

一个实用的经验：端到端评测集回答“要不要拉响警报”，过程评测集回答“警报响了该找谁”。只有端到端，你会陷入“知道坏了但不知道哪坏了”；只有过程，你会陷入“每个模块都达标但用户就是不满意”，二者相辅相成。

再次强调，端到端评测集是站在用户视角建立的。也就是说当 Agent 功能逐渐增加之后，需要按照端到端的功能模块建立不同的端到端评测集。例如商家 Agent，门店经营是一个核心功能模块，由若干个 Skill 构成；门店百科又是一个核心功能模块，由查数 Skill 和门店知识库构成。这种情况应该分别建立端到端评测集。

9.1.3 评测集的分层拆解

过程评测集还可以继续往下拆。比如知识库相关的问题，可以单独沉淀成知识库评测集；具体 Skill 调用相关的问题，可以沉淀成 Skill 评测集。后面业务长出新的子场景，也可以继续往下拆。

评测集要随着 Agent 的功能发展、随着问题的出现而不断细化。以商家经营分析为例，可以拆成这样一棵树：

拆解带来的一个额外收益是责任清晰。当过程评测集和组织分工对齐后，某一层的分数下降，就能直接找到对应的负责人，而不需要先开一轮会来确定“这是谁的问题”。

拆解的边界：不要过早拆得太细 分层拆解是演进的结果，不是设计的起点。《Agent 评测漫谈》博客中明确提到评测是一门实践科学，与其设计精妙的评测体系，不如抓住核心场景先跑起来。 正确的顺序是：先建端到端评测集和核心模块的过程评测集跑起来，遇到“知道坏了但不知道哪坏了”的情况，再进一步丰富。让拆解被真实问题驱动，而不是被完备性焦虑驱动。这一点在《冷启动篇》会详细展开。

9.2 回测执行：把评测集用起来

Agent 发生变更时，评测集起到门控的作用。通过回测，我们能保证变更前后核心链路、核心指标的一致性。但“跑一遍评测集”和“建立有效的回测机制”之间还有距离。几个关键的工程考量：

离线评测的固有局限 必须清醒认识到离线评测能力的边界。它只能发现已知的问题——评测集里没有的场景，回测永远测不出来。 例如商家经营分析的场景：如果评测集里全是“制作 PPT”类任务，那么当用户开始大量提出“帮我对比三家门店的数据”这种新需求时，固定的离线评测集显然无法覆盖到新出现的 Case。 这正是为什么完备的评测体系必须包含在线部分——离线负责守住已知，在线负责发现未知。

10 在线评测与在线监控：真实世界的反馈

离线评测做得再丰富多样，也是无法穷举所有场景的，而在线评测接受真实世界得分反馈，则可以弥补这部分短板。

在线评测和在线监控处理的是线上真实运行时的质量观察。二者关注的层面不同，但有一块重要的交集 —— 巡检。

一个直观的区分：在线评测回答“系统工作得好不好”，在线监控回答“系统有没有在正常工作”。前者是质量视角，后者是运维视角。Skill 调用成功率 100% 但每次都返回了错误的数据，监控是绿的，评测是红的。

10.1 在线评测的三种手段

三者的互补关系：影子模式在上线前用真实流量兜底，AB 在上线后确认业务价值，巡检在日常持续盯住基本盘。

10.2 巡检：两个模块的交集

巡检处在在线评测和在线监控的交集上，核心作用是持续监控线上 Agent 效果的稳定性。巡检是业务上把“线上质量观察”变成“持续可追踪过程”的常用手段。最常见的做法是从离线评测集中抽取一部分代表性的 Task 用于周期性检查线上 Agent 的表现，随着评测精细化，也可以单独维护一套巡检评测集。巡检同时具备两种属性：

回到商家经营分析的例子，一套合理的巡检可以这样设计：

10.3 在线监控关注什么

在线监控关注的是运行指标，工程中常见的大量稳定性指标，都在在线监控的范围内。常见的监控维度包括：

稳定性指标和行为监控类指标要放在一起看，才能得出有意义的结论。举例来说，任务完成率下降 5 个点，如果同时观察到某个 Skill 的失败率从 2% 涨到 15%，那结论极大概率是工程问题；如果 Skill 都正常，但“数据对比类”任务占比从 10% 涨到 35%，那结论是用户结构变了、Agent 在新场景上能力不足——这两种情况的应对完全不同。这就是 Case 挖掘和归因的范畴了。

11 Case 挖掘与归因：驱动双环演进的枢纽

Case 挖掘与归因主要承接在线评测和在线监控中暴露出来的问题线索，同时也接收线上反馈、真实样本采样和业务规则筛出的样本。

职责分工上：Case 挖掘负责把样本收进 Case 池，归因负责继续往下定位，判断 Agent 流程里的核心问题点。

这个模块是整个体系的枢纽，也是当下火热的“Agent 自进化”的核心切入点。

11.1 Case 挖掘的四大类来源

四类来源需要搭配使用，因为它们的“盲区”不同。只靠线上反馈，你只能看到用户愿意抱怨的那部分问题；只靠监控，你只能看到能被指标刻画的问题；只靠规则挖掘，你只能看到自己已经想到的风险。随机采样是唯一能发现“你根本没想到的问题”的手段，虽然它成本最高、命中率最低，但不可省略。

11.2 Case 池的分化：Good Case 与 Bad Case

挖掘出来的样本进入 Case 池后，可以继续区分为 Good Case 和 Bad Case，分别沉淀成不同类型的资产：

错题集是回报最直接的一类资产。它的逻辑很朴素：每一个曾经犯过的错，都不应该再犯第二次。

而黄金集的价值容易被低估。Bad Case 告诉你哪里不行，但它不能告诉你“到什么程度才算行”。没有黄金集，团队在讨论质量时只能各说各话；有了黄金集，“我们要做到这个水平”就变成了一个可以指着看的具体样本。

11.3 归因：从“这里出了问题”到“为什么出问题”

归因的目标，是定位 Agent 流程里的核心问题点。一个 Bad Case 只能说明“这里出了问题”，还不能说明“为什么出问题”。

归因要继续判断问题发生在哪个环节：常见的做法是将 Agent 执行过程全链路铺开，通过 Trace 日志逐一定位问题点，这个过程与软件问题排查过程中看日志查 bug 高度雷同。正因如此归因高度依赖观测基建 Trace。这个过程可以由人工完成，也可以由机器辅助完成。

一个可操作的归因分层，大致如下：

归因明确之后，正向 Case 一般可以归入评测集中的黄金集、挑战集；负向 Case 则会进入两条不同的路径：

很多团队只走了第一条路径——默认“评测说不行就是 Agent 不行”。这种默认假设会带来一个隐蔽的问题：Agent 会被优化成“迎合评测标准”，而不是“解决用户问题”。当评测标准本身有偏差时，优化得越努力，偏离真实需求越远。定期检查“是不是评测判错了”，是评测体系自我校准的必要动作。

12 Agent 观测基建：一切的地基

《Agent 评测漫谈》里有一个朴素的表述：看不见的问题，几乎不可能被稳定解决。观测的核心价值在于让 Agent 链路白盒化。这也是 Agent 研发公式“观测 + 评测 = 持续迭代”中，观测被放在第一位的原因。

Agent 的一次执行是一条长链路：用户输入 → 意图理解 → 任务规划 → 工具/Skill 调用 → 环境交互 → 中间结果处理 → 策略调整 → 最终输出。只要其中任意一层出问题，最终效果都可能劣化。但如果系统只能看到“用户说了什么”和“最后回复了什么”，就几乎无法判断问题根因。这正是工业界发展出 Trace 系统的动因——将黑盒内部的推理过程进行全路径披露，把所有影响模型输出的输入信息都记录下来。前篇博客中已经充分论述了观测之于评测的意义，这里不再赘述。

12.1 观测基建的建设思路

从 Trace SDK，到如今集成在 OpenClaw、Claude Code 当中的 Trace Plugin。观测基建也随着 Agent Harness 高速迭代。

综合前面的讨论，一套支撑完备评测体系的观测基建，至少应该具备以下能力：

由于 Agent Harness 迭代太快，哪怕是开源社区，相关基建也是落后于需求的。观测是地基，但这不意味着必须项目启动之初就需要建立一套完备的系统 。实际落地过程中，观测指标、观测基建也是需要基于需求反向设计的。判断标准很简单：当你发现“想自动化判断某件事，但数据里没有”的时候，就是补埋点的时候。

一个务实的建设思路是：先保证“最小可归因”——至少能拿到完整的模型调用输入输出和 Skill 调用记录，能凭 Trace 复现一个 Bad Case 到底发生了什么。这是冷启动阶段的底线，也是《冷启动篇》会重点讨论的内容。

13 评测体系成熟度自查

实践中，我们观察到各业务方评测体系三种最常见的“部分完备”形态。它们各自能解决一部分问题，但都存在明确的能力缺口。

第三种形态最值得警惕，因为它看起来最“完备”——既有评测集又有监控看板，汇报时数据很齐全。但由于缺少中间的枢纽，两套体系是割裂的：线上发现的问题回不到评测集，评测集的结论也解释不了线上现象。这种形态往往投入不少但收效有限，团队容易陷入“我们该做的都做了，为什么还是这样”的困惑。

最后，把前面的讨论收敛成一张可以直接使用的自查表。建议对照打分，找出自己业务最短的那块板。

如何使用这张表？ 不要追求所有维度都达到 L3。不同业务阶段对应不同的合理水位：冷启动阶段，观测 L1 + 评测集 L1 + 回测门禁 L1 就足以支撑起最小闭环；扩量阶段，重点是把评测标准和在线评测推到 L2，少量指标推到 L3；全量运营阶段，才需要考虑 L3 的自动化与规模化。 更有价值的用法是看“短板”和“错配”。如果你的评测标准已经到了 L3（机评规模化），但 Case 挖掘还在 L0（靠用户投诉），那么再精密的机评也只是在重复评测已知的样本——投入应该转向补齐挖掘能力。体系的能力上限，由最短的那块板决定。

14 小结与下一篇预告

回到本篇开头的问题：一套完备的评测体系长什么样？可以概括为四个模块、三种能力、两条 Loop、一套资产：

需要强调的是，这张全景图是“终局”而不是“起点”。没有任何一个团队应该照着这张图从头到尾建一遍——那既不现实，投入产出也不划算。

《Agent 评测漫谈》里有一句话值得在这里重复：Agent 评测是一门实践科学，起步阶段“让数据飞轮高效运转起来”的意义，远大于“设计一个复杂精妙的评测体系”。全景图的价值在于让你在每个阶段都清楚：我现在处在哪里，下一步补哪一块收益最大，以及某一块暂时不做的代价是什么。

那么起点在哪里？在一穷二白、没有评测集的冷启动阶段，如何实现评测飞轮的最小闭环？这正是下一篇《冷启动篇》将要回答的问题。

15 FAQ

Q：Agent 离线评测集只用在回测吗，为什么不可以按照大模型迭代一样必须比上一次得分高才可以发版？

这个问题涉及到 Agent 的评测和大模型评测的核心差异，需要从两个方面回答。

1、Agent 为什么不像基座模型一样打榜？基座模型提供的是通用能力，可以拆解出一系列的通用能力。提醒大家，大模型评测本身也是行业极其专业的领域。目前大家看到的大模型基座能力的评价指标体系是在过去三年中无数论文堆砌而来的。这三年基座模型 benchmark 的含义本身也发生了极大的变化。而 Agent 是服务于垂直业务领域的，最佳的 Agent 指标就是业务指标，所以对 Agent 而言，上线 AB 看业务指标变化是评价其能力的黄金标准。

2、评测集可以拆分为必过集合和挑战集。显然在垂直业务领域里，挑战集的构建是极其困难的，非常容易跟不上 Agent 版本功能迭代。而必过集样本属于 Agent 核心功能，对于已知的问题必须尽可能解决才可以上线。所以日常工作中，经常会出现必考题（必过集）都会了，难题（挑战集）又见不到的情况。

综上，Agent 离线评测更多是用在回测方面，真实效果的好坏直接通过线上 AB 看业务指标。

补充：如果设立了挑战集，一定要及时更新拟合线上真实场景的分布，否则评测集不置信。

欢迎大家在文末评论区积极留言，可以围绕Agent评测，展开深入的讨论和经验分享。我们会精选一些评论，给大家送上一份美团定制的小礼品。

----------  END  ----------

推荐阅读

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

用Agent评测思路管理AI Coding —— 31万行代码AI重构的实践

美团智播——数字人直播技术创新与实践

❤️❤️❤️ 如果这篇文章对你有帮助，欢迎大家帮忙点赞、评论，分享给更多的小伙伴。⬇️