摘要 ：美团图灵团队两年踩坑实录，把 Agent 评测从 "打个分" 讲透到 "建体系"。核心就一句话 ------看不见的问题，几乎不可能被稳定解决。读完这篇，你会明白为什么评测不是 QA 的事，而是 Agent 研发的基础设施。
一、写在前面：为什么这篇值得精读
最近 Agent 圈热得发烫，龙虾、爱马仕轮番刷屏，大家都在卷框架、卷模型、卷 Skill。但有一个问题始终绕不开：你怎么知道你的 Agent 变好了？
美团图灵 Agent 评测团队把两年 BP 各业务线的实践浓缩成了一篇万字长文，从 "评测是什么" 一路讲到 "长程 Agent 时代评测基建该长什么样"。这不是一篇理论科普，而是一份带着血和泪的工程手册。
阿宇读完最大的感受是：评测不是 Agent 开发的终点，而是起点。 没有评测体系的 Agent 迭代，本质上就是在裸奔。
下面按我的理解，把核心认知拆成几块聊。
二、Agent 评测到底在评什么
2.1 核心目的：回答 "好不好" 以及 "哪里好哪里不好"
评测的终极目标非常朴素 ------为下一轮迭代指明方向。
这听起来像废话，但很多团队的评测恰恰卡在了这里：打了一堆分，却不知道该改 Prompt 还是该换模型，更不知道改完之后到底有没有真的变好。
Agent 评测不能只停留在离线打榜，更不能只看某次 Demo 的表现。 Demo 是给老板看的，评测是给工程师用的，两者的目标完全不同。
图灵团队给出了一个很精炼的公式：
观测 + 评测 = 持续迭代
这个公式我非常认同。没有观测的评测是瞎子摸象，没有评测的观测是数据垃圾。
2.2 不止看结果，更要看过程和行为
这是全文最戳我的一个观点。两个 Agent 可能最终都 "做对了"，但工程价值天差地别。
- 一个路径清晰、工具调用稳定、耗时可控、可复现
- 一个反复试错、路径混乱、靠偶然命中、不可复现
如果只看最终答案，这俩会被误判为同一水平。但从规模化、成本优化、用户体验的角度看，根本不是一回事。
因此 Agent 评测至少要覆盖四层内容：
| 层级 | 评测重点 |
|---|---|
| 结果层 | 任务是否完成，输出是否可用 |
| 过程层 | 规划是否合理，步骤是否稳定 |
| 效率层 | 耗时、Token、工具调用次数是否可接受 |
| 风险层 | 是否越权、误操作、存在安全隐患 |
Agent 评测正在从 "答案评测" 走向 "行为评测"。 这句话值得每个做 Agent 的人刻在墙上。
2.3 观测是评测的基石
文章里有一句非常朴素但极其深刻的话：
我想看 Case 却发现没打日志。
做过线上排查的人都懂这种绝望。Agent 的执行链路很长 ------Prompt、Skill、工具链、记忆、状态管理、业务流程，任何一层出问题都可能导致最终效果劣化。
如果日志系统只能看到 "用户说了什么" 和 "最后回复了什么"，就几乎无法判断问题根因。
这就是为什么工业界发展出了 Trace 系统 ------将黑盒内部的逻辑推理过程进行全路径披露，把所有影响模型输出的输入信息都记录下来。
对 Agent 的每一个 "隐形动作" 进行精准观测，是从 "概率性生成" 迈向 "工业级可靠性" 的必由之路。
三、评测方法论：图灵团队的核心认知
3.1 评测体系的核心不是堆指标，而是搭桥
这是第二个让我拍大腿的观点。
很多团队做评测的第一反应是：我要设计一套完美的指标体系。然后花了两个月搞出几十个指标，结果发现模型能力指标和业务结果指标之间根本对不上。
图灵团队的解法是分层搭桥：
- 业务层：DAU、留存、点击
- 系统层：召回率、点击率
- Agent 层：意图识别准确率、检索有效性、结果整合可信度
只有把这些层次串起来，才能真正回答 "为什么业务指标变差" 以及 "模型能力提升为什么没有带来业务收益"。
这件事必须依赖真正懂业务流程的人来共同建立，不是算法工程师闭门造车能搞出来的。
3.2 客观评测与主观评测并行
这个没什么好说的，行业共识。但图灵团队给出的落地策略很务实：
- 客观评测覆盖高频、结构化、可规则化的部分
- 主观评测覆盖开放性、高价值、复杂业务场景
- 用主观评测校准客观评测和 AI 评测，再把规模化部分交给自动化
关键在于 "校准" 这个动作，而不是各搞各的。
3.3 "人人一致、人机一致"：主观评测的对齐方法论
这是全文最硬核的部分，也是图灵团队最核心的实践沉淀。
主观评测最大的痛点不是 "没有人会评"，而是**"不同的人评得不一样，机器和人评得也不一样"**。
图灵团队的解法可以概括为两句话：
人人一致：1 个 "独裁者" 好过 10 个 "民主者"。需要一位强有力的角色拉齐产品、运营、研发、QA 的评测标准，避免各自为政。
人机一致 ：机器评测结果与人工评测结果必须保持一致，否则不置信。人机一致的意义在于规模化提效。
具体怎么对齐？三步走：
- 指标下钻：把 "大而模糊" 的概念拆解成多个清晰维度
- Rubric 二元化：把打分规则尽量收敛成是 / 否 / 未知、0/1/unknown
- 持续迭代：用 unknown 占比反查 Rubric 是否合理，直到一致率达到可信阈值
举个例子，原文里 "判断模型回复是否口语化" 这个经典错误示范 ------ 让标注员按 0 到 10 分打分，结果十个人十个分。
下钻二元化之后变成：
- 模型是否以 "您" 指代骑手？
- 模型是否使用 "甭客气"" 明儿见 " 等口语词汇？
- 模型输出是否包含 "吧"" 呢 ""那个" 等语气词？
从 "主观的模糊感受" 转向 "可判断的事实依据"，这就是 Rubric 设计的精髓。
应用这套方法，数字站长的人机一致率达到99% ，Beam 改造后人机一致率从62% 提升到 92%。数据说话。
3.4 Agent 评测是一门实践科学：飞轮比体系重要
这一点我深有体会。绝大部分新上手的团队都会犯同一个错误 ------ 花大量时间设计一个复杂精妙的评测指标体系，然后发现根本执行不下去。
图灵团队的建议非常反直觉：
起步阶段 "让数据飞轮高效运转起来" 的意义远大于 "设计一个复杂精妙的评测体系"。
评测体系不是一蹴而就的，而是靠Good Case 和 Bad Case 喂养出来的。
最佳实践路径：
- 从高频核心场景起步，先定义少量关键指标
- 从生产环境收集 Bad Case
- 沉淀高质量 Good Case，明确什么叫 "好"
- 把 Good/Bad Case 转成标准评测样本
- 用评测结果反哺 Prompt、Skill、策略和模型优化
- 从新的线上表现里持续抽样，形成下一轮迭代
Bad Case 的价值往往更高，因为它最容易暴露能力边界和系统短板。
一个成熟的评测团队，核心能力不是一开始就搭出完美系统，而是能把线上问题、失败样本、模糊反馈不断转化成结构化评测资产。
原文有个数据很有说服力：履约数字站长项目启动时只有 20 多个评测指标，推全 1 年后扩展到了近200 个。体系是长出来的，不是设计出来的。
3.5 专家知识补足垂域模型能力的不足
模型是训练出来的，能力提升强依赖高质量语料输入。在垂域场景，公网数据往往不够用。
当业务知识语料匮乏时，引入行业专家的知识输入就成了破局关键------ 尤其是冷启动阶段。
那么谁来定义 "好不好"？靠最懂业务、最有 Sense 的行业专家。
四、长程 Agent 时代：评测范式正在剧变
4.1 从 "回答问题" 到 "完成任务"
2023 年 ChatBot，2024 年工作流，2025 年 Claude Code，2026 年龙虾热 ------长程 Agent 已经不是未来，而是现在。
短程 Agent 的典型形态是 Query -> Answer，评测重点在回答本身。
长程 Agent 解决的不是 "回答一个问题"，而是**"完成一个复杂任务"**：
- 需要多步骤拆解
- 需要多次调用 Tool 或 Skill
- 需要读取中间结果并动态调整策略
最本质的变化是：ChatAgent 评测关心 "说得好不好"，长程 Agent 评测关心 "事情做成没有，以及是怎么做成的"。
4.2 Skill 评测：新需求、新痛点
龙虾和 Skill 热潮带来了一个直接结论：未来需要评测的人，不只是一小撮产运研，而可能是每一个会创建、修改、接入 Skill 的人。
这对评测系统提出了新要求：要足够简单、足够标准化、足够自动化，最好能接入开发与发布流程。
当前的本质痛点是 ------大家不知道怎样写好 Skill，也缺乏对 Skill 全生命周期进行评测的工具。
Anthropic 在 2026 年 1 月的博客中首次提出了面向 Task 的长程 Agent 评测：通过（prompt - expected_behavior - trace）三元组进行评测，类似于短程 Agent 的（query - ground_truth - answer）。
这个思路我认为是长程 Agent 评测的正确方向 ------不评 "说了什么"，评 "做了什么以及是否符合预期行为"。
4.3 从人评主导走向机评主导
ChatAgent 时代的常见流程是：核心评测员对齐 -> 外包对齐 -> 机评对齐
长程 Agent 场景下，这条链路有机会被缩短为：核心评测员对齐 -> 机评对齐 -> 规模化扩展
原因很现实：
- 长程 Agent 执行轨迹信息密度高，人成为卡点
- Skill 生产门槛低、数量增长快，人工标注不可持续
- 基座模型能力持续突破
这并不意味着人工不重要，而是角色变了：
- 人工做高价值标准设计和 Rubric 对齐
- AI 承担规模化运行、初筛和回归验证
- 平台承担沉淀、回放、告警和归因
AI 评测真正要放大的，不是 "机器打分" 本身，而是核心评测员的判断标准。 这句话说得太到位了。
4.4 长程 Agent 评测基建能力清单
如果要支撑大规模 Agent 和 Skill 生态，评测基础设施至少应具备：
- 全链路回放：复现一次任务从输入到结果的全过程
- Case 管理：统一维护任务样本、上下文、约束和 Rubric
- 执行沙箱：按只读、可写、高风险等类型分层隔离执行
- AI 评测引擎：支持 Rubric 驱动的人机对齐和自动判分，简单易用
- 报告与归因：不仅给分，还能指出问题在规划、工具、环境还是 Skill
- 回归机制：版本升级后自动触发历史 Case 回归
- 准入准出门禁：把评测结果嵌入开发、发布和运营流程
缺少这些能力，评测就容易停留在 "单次分析" 和 "项目制支持" 层面，无法真正成为生产系统的一部分。
五、我的思考与总结
读完这篇文章，我有三个比较深的感触：
第一，评测是 Agent 工程化的 "操作系统"，不是一个功能模块。 很多团队把评测当成 QA 的活，这是根本性的认知错误。没有评测体系，Agent 的每一次迭代都是在赌博。
第二，"独裁者" 机制看似反民主，实则是工程效率的最优解。 评测标准最怕的不是错，而是不一致。一个强有力的角色拍板，比十个人讨论三个月高效得多。当然，这个 "独裁者" 必须是最懂业务的人。
第三，长程 Agent 时代，评测的核心竞争力是 "基建能力" 而非 "打分能力"。 谁能先把全链路回放、Case 管理、自动回归、准入门禁这套体系建起来，谁就能在 Skill 爆发的时代占得先机。
最后用文章结尾的一段话收个尾：
未来真正重要的，不只是能不能做几次评测，而是能不能建设出一套：看得见问题、说得清标准、跑得动规模、接得上流程、带得动迭代的 Agent 评测体系。
与各位学习 Agent 的同学共勉。
参考原文：美团技术团队《Agent 评测漫谈 ------ 由浅入深讲解 Agent 评测》Agent评测漫谈 ------ 由浅入深讲解Agent评测