这是2026年的第28篇文章

（本文阅读时间：约15分钟）

01 为什么 Agent 评测需要体系化

划重点：Agent 评测是把「不稳定的智能行为」持续收敛成「可发布的工程质量」，不是上线前抽查。

和传统软件相比，Agent 的输入、输出和状态空间都更开放：用户表达不可穷举，模型输出有随机性，多轮对话会累积上下文，工具调用还会改变系统状态。也就是说，Agent 从 Demo 到生产可用，真正要跨过的是三道门槛：非确定性（同样输入不一定同样输出）、黑盒化（内部决策过程不透明）和错误级联放大（前一步小错会在后续被放大）。

所以，“跑几条 case 感觉还行”远远不够：

同一 Prompt 跑通一次，不代表稳定可用；
每次改模型、改 Prompt 或改工具参数，都可能把原来好用的场景改坏，而且不容易第一时间发现；
多步链路里前面一个小偏差，也可能在后面被放大成错误结论；
更隐蔽的是，有些样本最终答案看起来对，但执行路径已经偏离或带风险，这类假阳性（结果看起来通过、过程其实有问题）在生产里迟早会暴露。

评测体系必须嵌入研发流程，而不是上线前人工抽查。评测平台不只是“出分工具”，它的核心价值是把问题稳定转化为可执行修复，形成持续迭代闭环。

一套成熟的 Agent 评测体系至少要回答三类问题：

能力边界：这个 Agent 能解决什么问题、不能解决什么问题？
稳定性：同样场景反复跑，成功率是否足够高？
可修复性：评测失败时，能否快速定位到具体模块、具体根因？

02 Agent 类型与评测侧重

划重点：先分清 Agent 类型，再定义评测指标；类型不分，评测结果基本不可用。

Agent 的系统形态差异很大，不能用一套“万能指标”评所有系统。常见分类包括：

对话型 Agent：客服、导购、售后，核心看会话是否解决问题、是否自然、是否过度承诺。
任务型 Agent：订票、报销、填表，核心看任务完成率、流程合规性、状态一致性。
推理型 Agent：研究、分析、决策辅助，核心看推理链质量、结论正确性、引用可靠性。
工具型 Agent：代码、数据、运维，核心看工具调用正确率、副作用控制、异常处理。
多 Agent 系统：协作效率、角色边界、信息传递一致性。

评测底层骨架可以复用：执行用例、采集 Trace（执行轨迹）、运行 Scorer（评分器）、生成报告、做根因归类。真正需要按业务定制的是“评什么”和“怎么判”。

除了按 Agent 类型设计评测体系，还需要关注 Agent 内部的能力单元。随着 Agent 越来越多地通过 Skill 完成工具调用、数据处理、报告生成和业务动作，Skill 本身也需要测评：它是否该触发、触发后是否走对流程、工具参数是否正确、最终产物是否可用、异常时是否能降级。本文会把 Skill 相关方法拆到指标、数据集、评分、归因和优化各章节中统一说明。

03 对话 Agent 的特殊性

划重点：对话 Agent 不能只看单轮答案，必须把整段会话是否解决问题作为主评判对象。

如果聚焦在“对话形态”的 Agent，客服、营销、导购、售后等系统往往同时包含知识问答、任务执行、推理决策和多轮引导能力，但只要它们通过多轮对话面向用户，就会额外面临上下文、目标切换、情绪回应和人工接管等评测问题。

对话 Agent 至少有五个特殊难点：

上下文丢失：多轮后 Agent 忘记用户之前说过什么。
目标漂移：用户中途切换意图，Agent 没有跟上。
过度承诺：为了“表现好”给出无法兑现的回答。
情绪不敏感：用户在抱怨，Agent 还在机械复述流程。
人工接管时机：该转人工的时候没转，或过早转人工。

对话评测不要只平均每轮分数。一段会话每轮都“答得还行”，但最终没有解决用户问题，仍然是失败。正确做法是同时看历史 Turn（单轮）、Session（整段会话）、Trace（执行轨迹）、Outcome（最终结果）四个层次。

04 指标体系

划重点：指标体系不止用于打分，更用于驱动可落地、可验证的持续优化。

Agent 评测要从“感觉好不好”变成“可量化、可比较、可回归”，关键抓手就是指标体系。指标的作用，是把业务目标和专家经验拆成可观察、可打分、可追踪的检查项，让每次评测不只给分，还能明确好在哪、差在哪、下一步该改什么。

Agent 评测指标建议分成五大类。P0 指标用于上线门禁（不达标不能发），P1 指标用于版本比较和工程优化，P2 指标用于体验改善和长期观察。

五大类指标

正确性（Correctness）：最终答案或执行结果是否满足目标。包括答案准确、任务完成、状态一致、无幻觉。
完整性（Completeness）：是否覆盖了用户问题的所有子需求。包括信息完整、步骤完整、边界情况处理。
合规性（Compliance）：执行过程是否符合规则、权限、安全、政策约束。包括不越权、不泄露、流程合规。
效率（Efficiency）：完成目标所需的资源消耗。包括调用次数、Token 消耗、延迟、轮次数。
稳定性（Stability）：在重复、变体、扰动下表现是否一致。包括成功率、方差、回归通过率。

如果系统大量依赖 Skill，可以在上述五大维度下再补一组 Skill 子指标：

Skill 触发准确率：该触发时是否触发、不该触发时是否误触发。
Skill 参数正确率：传给工具/接口的参数是否准确。
Skill 流程遵循率：是否按预期流程执行，有没有跳过关键步骤。
Skill 产物可用率：生成的内容、数据、文件是否可直接使用。
Skill 异常降级率：失败或异常时是否能优雅降级，而不是直接崩溃或给出错误结论。

05 数据集构建

划重点：数据集不是“越多越好”，而是“覆盖越准越好”。

Agent 评测数据集要回答三个问题：

场景覆盖：是否覆盖了真实用户会提的主流、边缘、异常请求？
难度分层：是否按简单、中等、困难做了分层，能反映能力边界？
标注质量：每个样本的期望输出、评判标准、通过条件是否清晰？

数据集来源通常包括：

真实日志抽样：从线上会话中抽取，最贴近真实分布。
人工构造用例：针对边界场景、对抗样本、合规风险场景专门构造。
合成数据：通过 LLM 扩增，但需要注意质量控制，避免“模型考自己”。
众包/外包标注：成本低，但标注一致性需要严格验收。

数据集需要持续维护：

每次线上事故或失败案例，都应及时补充进评测集；
每次模型/提示词/工具升级，都应跑回归集，防止“修好 A 破坏 B”；
定期清理过时用例，避免数据集膨胀导致评测成本失控。

06 评分机制

划重点：评分不是非黑即白，最好支持多档、多维度、可解释。

Agent 评测的评分常见有三种粒度：

二进制：通过/不通过。适合上线门禁和硬性约束。
多档：优秀/良好/及格/不及格。适合模型比较和体验优化。
连续分：0-1 或 0-100。适合细粒度回归分析和 A/B 测试。

评分方式主要有：

规则评分：基于预定义规则、正则、状态断言判断。可解释、稳定，但难以覆盖复杂语义。
模型评分：用另一个模型（通常是更强模型或专用 Judge 模型）作为裁判。灵活，但需要注意裁判模型自身的偏见和一致性。
人工评分：最可靠，但成本高、不可扩展。通常用于校准自动评分器和处理争议样本。
混合评分：规则 + 模型 + 人工分层。规则做硬约束，模型做语义理解，人工做仲裁和校准。

评分器设计的关键原则：

可解释：每个分数都能追溯到具体检查项。
可重复：同样输入反复跑，分数波动在可接受范围。
可校准：定期用人工评分校准自动评分器，防止漂移。

07 归因与根因分析

划重点：评测最终的价值不在分数，而在于能不能把失败变成可修复的任务。

Agent 失败通常来自多个环节：输入理解、意图识别、规划、工具调用、记忆、生成、执行环境。评测体系必须能把失败样本归因到具体模块，否则团队只能在“模型/提示词/工具”之间盲目试错。

常见归因维度：

模块归因：失败发生在哪个模块？例如 NLU、规划、工具调用、总结生成。
类型归因：失败属于哪类问题？例如幻觉、工具参数错误、上下文丢失、边界未处理。
输入归因：失败是否集中在某类用户输入、某类场景、某类工具上？
版本归因：哪个版本开始引入？是否和某次模型/提示词/工具变更相关？

根因分析工具建议：

Trace 可视化：把 Agent 执行轨迹按时间线展示，方便人眼定位异常。
差异对比：同一用例在不同版本下的执行路径对比。
聚类分析：对失败样本自动聚类，找出高频问题模式。
关联回归：把失败用例和代码/提示词/配置变更关联。

08 持续迭代闭环

划重点：评测体系是工程系统，不是一次性报告。

Agent 评测的最终目标是形成持续迭代闭环：

定义指标：明确业务目标和可观测指标。
构建数据集：覆盖真实场景、分层难度、持续补充。
自动评分：规则 + 模型 + 人工混合评分，可解释可重复。
归因分析：把失败样本定位到模块和根因。
修复优化：改模型、改提示词、改工具、改 Skill。
回归验证：修复后跑全量回归，确保不引入新问题。
上线门禁：达到 P0 指标阈值才能发布。

评测平台要嵌入 CI/CD 流程，每次代码、提示词、模型、工具变更都自动触发评测。评测结果要反馈给研发、产品、运营，形成数据驱动的优化节奏。

09 小结

Agent 评测不是“跑几条 case 看看效果”，而是一套把不稳定智能行为收敛为可发布工程质量的体系。核心要点：

先分 Agent 类型，再定指标；
对话 Agent 看整段会话结果，不是单轮分数；
指标体系分五大类：正确性、完整性、合规性、效率、稳定性；
数据集要覆盖真实场景、分层难度、持续维护；
评分要可解释、可重复、可校准；
失败要归因到模块和根因；
评测必须嵌入研发流程，形成持续迭代闭环。

只有这样，Agent 才能从 Demo 走向生产可用。

Agent 评测：方法论与体系设计