Agent 评测体系怎么搭：从指标设计到工程闭环

前言

大模型降低了搭一个 Agent 的门槛，但一个现实是：大多数团队把 90% 的时间花在评测和调优上，而不是初始搭建。这不是因为 Agent 难做，而是因为 Agent 的输出是非确定性的------同样的输入换一次运行可能得到不同结果，多步链路里前一步的小偏差会被后续放大。跑几条 case "感觉还行" 远不够，必须把不稳定的智能行为持续收敛成可发布的工程质量。本文从"评什么、怎么评、数据从哪来、错了怎么定位"四个环节，讲清楚一套可以落地的 Agent 评测体系。

一、为什么 Agent 评测是真难题

LangChain CEO Harrison Chase 把 Agent 评测称为 AI 应用领域最大的未解决问题之一。这个判断来自三个结构性差异。

第一，非确定性。传统软件的输入输出是确定的，单元测试跑过了就一直稳定。Agent 的底层是概率模型，同一个 Prompt 两次执行可能给出不同答案，这意味着"跑通"不等于"可用"。

第二，错误级联放大。Agent 通常是多步规划链：用户提问 → 意图识别 → 知识检索 → 工具调用 → 结果整合 → 回复生成。前一步选错了工具，后面几步都会在错误基础上继续推理，最终答案看起来完整，但路径已经偏了。

第三，假阳性问题。最终回复表面上是对的，但执行过程中可能调用了不该调的工具、承诺了超出权限的结果、或者跳过了必要的校验步骤。这类问题在手工测试里很难发现，但在生产环境里迟早暴露。

没有评测体系的团队通常会经历同一个循环：每次改模型、改 Prompt、改工具参数都觉得没问题，上线后才发现某些场景悄悄退化了。

一个有用的理论视角

Jason Wei 在 2025 年提出了"验证者定律"：训练 AI 解决某个任务的难易程度，和这个任务的可验证程度成正比。验证越容易，AI 进步越快。数独解题要 20 分钟、验证只要 2 秒，高度不对称，所以 AI 进步飞快。而事实核查一篇夹带大量引用的文章，验证比写作更耗时，属于反向不对称，AI 进展就慢。这个定律解释了为什么 SWE-bench 能成为黄金标准------代码世界天然符合"客观真相、快速验证、可规模化、低噪声"的条件。

同时要警惕 Goodhart 定律：当一个指标变成目标，它就不再是好指标。MMLU 三年从天堑变入门考试、SWE-bench 一年分数翻倍，都是 benchmark 被训练攻克后逐渐失去区分力的例子。

二、评测什么：粒度、质量属性与 Agent 类型

2.1 两种评测粒度

Agent 评测分两个层次。

端到端评测是黑盒评测，关注从用户输入到最终输出的整体表现。它回答的问题是"Agent 在这个场景下能不能完成任务"。端到端是必选项，因为它直接对应业务需求和用户体验，也是建立质量基线的依据。

中间过程评测是白盒评测，深入 Agent 内部的规划、执行、工具调用、记忆管理等模块。它回答的是"哪一步出了问题"。中间过程是可选项，因为它需要访问执行日志和中间状态，实施成本更高。

二者的关系是：端到端发现问题，中间过程定位到具体模块；中间过程的改进最终体现在端到端结果上。

2.2 五大质量属性

质量属性	定义	关键指标
准确性	输出结果的正确程度	正确率 = 正确数 / 总输出数
可靠性	多次运行的一致性与可用程度	可用率、运行一致率、可复现率
安全性	运行过程是否存在安全风险	敏感信息泄露率、恶意输入识别率
效率	响应速度与资源消耗	平均响应时间 / P95、Token 消耗
鲁棒性	对异常输入和边界场景的处理能力	异常输入处理成功率

2.3 Agent 类型决定评测重点

不同类型的 Agent 评测重点完全不同，混在一起评测结果基本不可用。

知识问答型 Agent 的评测重点是准确性和忠实性------回答是否正确、有没有编造来源。任务执行型 Agent（比如自动退款、订单查询）的评测重点是工具选择和参数正确性，以及执行后业务状态是否真的变了。推理决策型 Agent 的评测重点是推理过程和证据链是否完整。多轮对话型 Agent 的评测重点是记忆能力------跨轮对话里有没有"失忆"。

实操里，先做一张 Agent 类型到评测重点的映射表，再设计指标，比上来就铺指标列表有效得多。

2.4 对话型 Agent 的特殊性

客服、导购、售后这类对话型 Agent 不能只看单轮答案，必须把"整段会话是否解决问题"作为主评判对象。它有五个特殊难点：上下文依赖（单轮 OK、整段失忆）、目标动态变化（用户中途改需求）、业务流程约束（要按 SOP 推进）、情绪与体验（客诉时不能机械回答）、人机协同（该转人工时要转，并带上问题摘要）。

正确做法是同时看四个层次：Turn（单轮质量）、Session（整段会话）、Trace（执行轨迹）、Outcome（最终结果），而不是简单平均每轮分数。

三、指标体系

3.1 五大维度和优先级

把业务目标拆成可观察、可打分、可追踪的指标时，建议分五大类并按优先级分配：

功能正确性（P0）：任务完成率、答案准确率、工具调用准确率、参数正确率。这是上线门禁，不达标不能发。

稳定性与安全（P0）：幻觉率、越界承诺、隐私泄露、拒答正确率。也是门禁级。

过程质量（P1）：计划质量、工具顺序、重试次数、无效步骤占比。用于版本比较和工程优化。

效率与成本（P1）：平均轮次、耗时、Token 成本、工具调用次数。

体验与对齐（P2）：语气自然度、情绪承接、品牌风格、满意度。用于长期观察和体验改善。

3.2 一致性度量：Pass@k 和 Pass^k

对任务执行型 Agent，"多次运行的一致性"比单次结果更重要。

Pass@k（k 次至少成功一次）衡量能力上限。一个模型 Pass@10 是 95%，说明它有 95% 的概率在 10 次尝试中至少成功一次。

Pass^k（k 次全部成功）衡量稳定可靠性。Pass^10 只有 60%，意味着连续 10 次里有 40% 的概率至少犯一次错------对支付、退款、医疗这类场景不可接受。

一个典型的案例：某 Agent 退款场景 Pass@10 是 95%，但 Pass^10 只有 60%。单看上限数字会觉得"还不错"，但生产环境里用户不会接受"多试几次总有一次成功"。

3.3 版本对比要做统计检验

版本升级后，不能把随机波动误判为能力变化。报告里需要同时给出三个东西：关键指标的置信区间、与基线版本的显著性判断、最小可感知变化阈值（提前定义"至少提升多少才值得发布"）。门禁不只看"差了多少"，还要看"这个差异是否超过统计噪声"。

四、怎么打分：三层评分器

不管评测哪个场景，都遵循同一个分层原则：能写成代码的确定性指标绝不让 LLM 去"估算"，需要语义判断的才交给 LLM，高风险的再交给人。

4.1 三层结构

第一层 · 确定性计算（规则/脚本 Scorer），覆盖 60-70% 的评测量。JSON Schema 校验、工具参数合法性、状态变更、敏感词检测都放在这一层。特点是快速、便宜、可复现、零争议。

第二层 · 语义判断（LLM-as-Judge），处理相关性、完整性、情绪承接、策略合理性、事实忠实性这类需要语言理解的判断。它的输入不是原始 Agent 输出，而是第一层产出的"事实"------比如工具调用记录、知识库检索内容------然后基于这些事实做判断。

第三层 · 人工抽检（Human Scorer），用于校准锚点。高风险样本、低置信样本、规则与 Judge 冲突的样本、业务口径未固化的样本交给人工。人工不只是"裁判"，还是 Judge Prompt 的校准器。

4.2 LLM-as-Judge 的偏差与治理

LLM-as-Judge 不是银弹，有四个已知偏差：

位置偏差：倾向给先出现的答案打高分
自我偏好：倾向给自己风格的答案高分
长度偏差：更长的回答获得更高分
校准困难：不同 Prompt 下评分分布差异大

能用的 Judge 至少需要做到：评分标准每档有可执行定义、输出 reason（便于 badcase 聚类）、有 few-shot 示例和边界样本。

Hamel Husain 的实践建议值得参考："Start with assertions, graduate to LLM-as-Judge only when you must." 先从基于断言的评测开始，只有当简单方法不够用时才引入 LLM-as-Judge。同时建议每次重大改动后花 30 分钟人肉看 20-50 条输出，往往比纠结技术栈选型更有价值。

五、数据集建设

评测集不是线上数据的随机抽样，而是围绕高风险路径、关键逻辑和失败模式设计出来的质量资产。纯随机采样有明显的幸存者偏差------正常流程占多数，真正让 Agent 出错的边缘场景占比很低，报告"看起来不错"但关键问题被漏掉了。

5.1 四类数据来源

专家设计用例：专家定义核心场景、期望行为、判分标准，锚定业务共识。数量不必大，但要覆盖关键流程和高风险边界。

扩展用例：基于专家用例扩展不同说法、边界、异常组合，扩大覆盖面。结构字段用规则生成，语言表达用 LLM 扩写。

线上真实数据：从真实对话、工单、执行记录抽取，贴近真实分布。注意按场景和风险分类抽样，不能纯随机。

badcase 回流：线上失败、人工质检发现的问题回收成用例，最贴近真实失败。必须沉淀失败原因和修复状态。

5.2 起步规模

先做 50-200 条高质量 golden set（基线集），覆盖核心业务路径和高风险边界，用于版本对比和发布门禁。成熟后再扩展到分类采样集、长尾集、对抗集和线上回流集。

所有用例必须完成打标，覆盖正常场景、边界场景和异常场景。历史 Bad Case 必须沉淀为评测用例，否则同样的错误会在不同版本里反复出现。

六、Badcase 根因定位

端到端失败只是表象。Agent 出错的根因可能来自意图识别、上下文记忆、检索召回、工具选择、参数构造、业务规则理解、模型推理、回复生成、Guardrail 拦截或外部系统异常，十个可能的模块里任何一个出问题都会表现为"回答不对"。

6.1 收敛链路

根因定位的步骤是"先收集证据、再收敛范围、最后定责落盘"：

按 traceId 汇总全链路日志 → 按"问题现象 × 功能模块"映射表缩圈 → 逐模块读 input/output 诊断 → 规则加模块结论定责 → 写入任务记录支持看板查询。

第二步的映射表是关键，不要对全部模块无差别分析：

问题现象	优先候选模块	典型判断依据
答非所问	意图识别、Query 改写、知识筛选	用户问题明确，但回复偏题
订单未澄清	槽位抽取、上下文判断	需要订单号时没追问或绑定错对象
事实性错误	FAQ 检索、知识筛选、回复生成	知识库有正确信息但回复给出错误事实
过度承诺	风险识别、回复生成	承诺超出权限或业务规则

6.2 根因标签体系

根因标签要稳定、可统计、能指向明确 owner。常见的标签包括：Intent 识别错误、Context 记忆错误、Retrieval 召回不足、Tool 选择错误、Tool 参数错误、Reasoning 错误、Policy/SOP 错误、Response 生成问题、System 异常。每类绑定解决角色：运营可配置、算法需优化、工程需修复、业务需定口径。

同一根因、同一场景、同一工具的失败自动聚成问题簇，报告里产出"退款已发货场景中 Agent 跳过订单状态校验 23 次，主要集中在 v1.8 Prompt"这样的可行动结论，而不是"正确率 87%"这种数字。

七、工程落地：全链路过程数据采集

评测的前提是拿到 Agent 执行全链路的过程数据。没有过程数据，就只能看最终输出，假阳性查不出来，根因也定位不了。

以 ReAct 范式为例，Agent 的执行是一个"推理 → 行动 → 再推理"的循环。在关键节点插入 Hook，只读事件数据不修改 Prompt、工具或 Memory，全局 try-catch 吞掉所有异常（评测挂掉不能阻断业务链路）。

java 复制代码

// Hook 接口定义（示例代码，标注为示例）
public interface Hook {
    /** 优先级，数值越小越先执行 */
    int priority();

    /** 事件处理入口 */
    <T extends HookEvent> Mono<T> onEvent(T event);
}

生命周期事件按执行顺序排列：

PreCallEvent：输入消息列表，记录开始时间、提取用户输入
PostReasoningEvent：推理消息（Thinking/Text/ToolUse）、Token 用量
PreActingEvent：即将执行的工具（工具名、参数、调用 ID）
PostActingEvent：工具加执行结果，封装完整调用记录
PostCallEvent：调用链路结束，组装评测数据
ErrorEvent：异常信息，标记后阻断上报

Hook 产出的数据封装成统一的评测消息模型，供后续评分器消费：

java 复制代码

// 统一评测数据模型（示例代码，标注为示例）
@Data
public class LLmAsJudgeSyncMessage {
    private Msg currentMessage;          // 当前用户输入
    private List<Msg> historyMessages;   // 历史会话
    private String sysPrompt;            // 系统提示词
    private List<Skill> skillCandidates; // 挂载技能集
    private List<Tool>  toolCandidates;  // 挂载工具集
    private String thoughts;             // 思考过程（思维链）
    private String knowledge;            // 知识库内容
    private List<ToolCallRecord> toolCalls; // 实际工具调用轨迹
    private String output;               // AI 最终回复
    private Long firstTokenCostMs;       // TTFT 首 Token 耗时
    private Long totalCostMs;            // 链路总耗时
    private Long inputTokens, outputTokens, totalTokens;
}

控制评测成本：分场景采样

全量评测成本很高，尤其是多技能组合场景。解法是按场景独立配置采样率，通过配置中心动态调整，无需发布：

java 复制代码

// 分场景采样控制（示例代码，标注为示例）
private static boolean shouldSample(String scene) {
    int rate = SystemSwitch.getEvalSamplingRateByScene(scene);
    if (rate <= 0)   return false;
    if (rate >= 100) return true;
    return ThreadLocalRandom.current().nextInt(100) < rate;
}

技能 ID 组合按字典序拼接作为"业务场景"标识，每个场景独立配置采样率。这样既保证覆盖所有场景，又控制评测成本。

八、流量回放：解决评测环境稳定性

Agent 评测有一个独特的痛点：上下文依赖的底层数据会变。Agent 执行工具调用时查询订单数据，而订单状态随业务流程不断变化（待发货 → 已发货 → 已签收）。相同的用例在不同时间执行会因数据状态不同产生不同结果，导致评测结果不可复现。

解法是流量录制加 Mock 回放：录制线上真实流量自动生成评测用例（大幅降低构造成本），把录制的方法调用输入输出作为 Mock 数据在评测时回放（确保数据状态一致、结果稳定可复现）。

Mock 执行结果可视化为四种状态：

绿色：成功且顺序正确
黄色：成功但顺序不对
红色：入参有误
灰色：未执行

这个颜色标记让排查 Agent 执行逻辑时一眼就能看出问题出在参数构造还是工具选择。

九、Badcase 回流闭环

评测平台的终点不是报告，而是把线上失败持续转化为可复用的研发资产。一条 badcase 至少可以生产三类反馈：回归用例（防止同类问题再现）、Prompt 或工具改进建议（修复当前行为）、业务规则或知识库修订（修正源头）。

反馈入库要有标准，不能把所有失败无差别塞进回归集：失败可复现、期望行为明确、根因标签清楚、样本有代表性、已完成脱敏。

样本治理要避免回归集无限膨胀：同簇样本保留代表例、P0/P1 长期保留、稳定多版本通过的低风险样本降级为抽样集。

发布阶段要把离线门禁和线上灰度联动，跟踪三类信号：

离线质量信号：核心场景通过率、P0 风险数
线上体验信号：转人工率、重复追问率、投诉率
业务结果信号：任务完成率、工单闭环率

如果离线指标提升但线上关键信号恶化，应该触发回滚或降级，不能只看纸面数字就发版。

十、结语

Agent 的开发本质上是一场与不确定性博弈的过程，评测是这场博弈中最关键、也最容易被低估的能力。

几条务实共识值得反复强调：探索阶段（0 到 1）用快速试错足够，优化阶段（1 到 N）必须建立系统化评测，生产阶段需要全自动化流水线加在线监控。能用脚本算的绝不用 LLM 估，能自动化的绝不长期依赖人工，人工只用于定标准、校准 Judge 和高风险终判。

评测不是项目交付物，而是长期资产。用例库、Trace 库、根因标签库、修复建议库、Judge 校准集、回归集------质量资产越厚，Agent 迭代越不靠个人经验和临时救火。

正如 Eugene Yan 所说："Evals aren't static artifacts or quick fixes; they're practices that apply the scientific method." 好的评测体系，是对可验证性边界的诚实承认，也是让每一次 Agent 迭代都"看得见质量变化"的底层能力。