Agent 评测到底怎么做?从可观测性到生产级质量治理的完整实践

现在借助大模型、Agent SDK、MCP 和 Skill，开发一个能够调用工具、执行任务的 AI Agent，已经不再是一件特别困难的事情。

真正困难的是：当 Agent 开始处理真实业务，我们如何判断它到底做得好不好？

开发阶段，一个 Agent 可能连续回答十几个问题都没有出错。但上线后，用户的表达方式变了，工具返回的数据变了，业务环境也变了，原本表现不错的 Agent 开始出现各种问题。

有时候，Agent 给出的答案看起来完全合理，但实际并没有解决问题；有时候，修改一个 Skill 确实解决了某类故障，却导致其他场景的表现下降；还有时候，评测分数突然提高，最终发现并不是 Agent 变强了，而是评测器本身存在问题。

这就引出了 Agent 工程化过程中一个不可回避的问题：如何建立一套可信、可重复、能够持续推动 Agent 改进的评测体系？

最近研究了得物、淘宝、货拉拉、美团、阿里云等国内技术团队的公开实践，也对照了 OpenAI、Anthropic、Google 和 Microsoft 的相关技术方案。

这些团队的业务不同，使用的工具和评测方法也各有侧重，但它们正在逐渐形成一个共同方向：

Agent 评测正在从简单的答案评分，发展为覆盖执行轨迹、真实任务结果、系统效率与安全风险的完整质量工程。

本文就从实际工程问题出发，系统梳理 Agent 评测的核心概念、技术方案、落地流程和持续优化方法。

一、Agent 评测到底在评什么？

1.1 评测的对象，已经不再是单独的大模型

在传统机器学习中，评测对象通常是一个具体模型。我们可以通过准确率、召回率、F1 等指标判断模型表现。

进入大语言模型阶段，评测范围逐渐扩展到知识理解、数学推理、代码生成、指令遵循等能力。

但是到了 Agent 阶段，情况发生了变化。

一个实际运行的 Agent，并不是简单地把用户输入发送给大模型，再返回一段文字。

它可能需要先理解用户意图，然后选择 Skill，调用外部工具，读取中间结果，调整执行计划，最后完成任务。

因此，Agent 的效果实际上由多个部分共同决定：

Agent = Model + Prompt + Skill + Tool + Memory + Runtime + Orchestration

模型只是 Agent 的一个组成部分。

例如，一个客服 Agent 回答错误，可能是模型理解错了用户的诉求，也可能是知识库没有检索到正确政策，或者工具返回的订单状态已经过期。

一个编程 Agent 修复失败，可能是生成的代码有问题，也可能是没有运行测试，甚至是修改了错误的文件。

如果仅仅给最终答案打分，我们只能知道结果好不好，却不知道问题发生在哪个环节。

所以，Agent 评测首先需要从模型能力评测转向完整任务系统评测。

1.2 结果正确，不代表过程可靠

假设有两个 Agent，任务都是修复一个程序中的错误。

Agent A 阅读报错日志，定位相关代码，修改后运行测试，最终成功解决问题。

Agent B 反复尝试修改多个文件，执行大量无关命令，过程中还意外删除了部分临时数据，最后也碰巧修复了错误。

如果只检查最终程序是否能够运行，两个 Agent 都可能得到满分。

但从生产环境的角度看，它们的工程价值显然不同。

Agent A 的执行路径清晰、成本可控，容易复现和维护。

Agent B 虽然完成任务，却存在大量无效操作和潜在风险。

因此，评测不能只回答“有没有完成”，还需要回答“是怎么完成的”。

目前业界常用的三个概念是：

其中，Trajectory 也经常被称为 Trace，即一次 Agent 执行过程中能够记录到的调用与交互轨迹。

Outcome 则强调任务执行结束后，外部环境是否真正达到了目标状态。

例如，Agent 告诉用户“数据库已经创建成功”，这是 Response；调用创建数据库的 API，是 Trajectory 的一部分；数据库实例是否实际存在、参数是否符合要求，才是 Outcome。

1.3 评测指标与业务价值之间，还需要建立联系

美团图灵团队在《Agent 评测漫谈》中提出了一个很重要的观点：评测体系不是简单堆积指标，而是需要在模型能力和业务价值之间建立联系。

例如，一个 AI 搜索 Agent 的技术指标可能包括检索准确性、引用可靠性和意图识别能力，而业务真正关心的可能是用户是否找到了信息、点击率有没有提升，以及用户是否愿意继续使用。

两者并不能直接画等号。

同样，一个故障诊断 Agent 的答案评分从 80 分提升到 90 分，并不能直接证明用户的故障解决率提高了。

原因很简单：评测器认为方案正确，与用户在真实环境中成功执行方案，是两件不同的事情。

因此，一套合理的 Agent 指标体系应该形成三层关系：

模型与工具能力指标 → Agent 任务质量指标 → 真实业务结果指标。

第一层帮助研发分析技术问题，第二层用于验证 Agent 是否可靠完成任务，第三层用于判断产品是否真正创造了业务价值。

如果只关注第一层，就可能出现模型评测越来越好，但用户体验没有改善的情况。

图 1：Agent 评测的三层指标体系

二、可观测性：为什么 Trace 是 Agent 评测的基础？

2.1 看不到执行过程，就很难定位问题

传统后端系统通常会通过日志、指标和链路追踪分析故障。

Agent 同样需要这些能力，只不过它的执行过程比一般接口调用更加复杂。

一次 Agent 请求可能包含多轮模型推理、多个工具调用、上下文处理和任务状态变化。

如果只记录用户输入和最终输出，就相当于系统中间的大量行为都处于不可见状态。

当用户反馈“Agent 给出的方案不对”时，研发人员很难确认究竟是哪个环节出现了问题。

OpenAI 的 Agents SDK 为此提供了内置 Tracing 机制，可以记录模型生成、工具调用、Agent 之间的任务交接和 Guardrail 等事件。

Langfuse、LangSmith 等平台也提供了相应的可观测性能力。

不过，Trace 并不意味着能够读取模型内部全部真实推理过程。 实际记录内容取决于 Agent 框架、工具系统和观测组件能够提供哪些输入、输出与执行事件。

它的核心价值是让可观察的执行过程具有足够的可追溯性。

2.2 得物技术：使用 Langfuse 还原 Agent 故障现场

得物技术在《压测 AI Agent 治理与评测调优实践》中介绍了一个比较完整的工程案例。

得物的压测平台支持多种协议和脚本组件。用户在配置压测场景、调试脚本或分析执行错误时，经常需要检查场景配置、JMX、请求响应、JMeter 日志和 Trace 等信息。

为了降低排查成本，得物将智能分析 Agent 接入原有调试流程，由 Agent 自动采集证据、分析原因并提出处理建议。

但 Agent 上线之后，也遇到了一个典型问题：用户反馈分析结果不准确时，研发人员应该如何定位具体原因？

得物的做法是通过 Langfuse 记录执行过程，并将用户反馈与对应的 Trace ID 关联。

收到问题反馈后，可以通过 Trace 逐步检查：

首先，核对用户原始诉求和 Agent 实际运行的业务场景。

其次，查看 Agent 调用了哪些工具，是否正确获取配置、日志和请求响应。

然后，展开关键工具节点，检查输入参数、返回数据和异常信息。

最后，再检查 Agent 是否正确使用了这些证据，以及最终方案是否符合用户实际需求。

经过这个过程，原本笼统的“分析不准”，就可以进一步归因到证据采集、工具调用、规则处理或模型分析等具体环节。

例如，一次错误诊断可能并不是模型能力不足，而是工具没有返回必要的 namespace 信息。

如果没有 Trace，研发人员可能直接修改 Prompt；但真正应该修复的却是数据采集逻辑。

可观测性的价值，不只是记录日志，更是避免研发人员在错误的地方进行优化。

2.3 观测并不等于评测

这里还需要区分两个容易混淆的概念。

Tracing 负责记录一次执行发生了什么。

Evaluation 负责依据既定标准，判断这次执行是否正确、是否满足任务要求。

前者提供事实，后者提供判断。

因此，不能认为接入 Langfuse、能够看到完整 Trace，就已经拥有成熟的 Agent 评测体系。

真正的评测还需要数据集、验收标准、评分器、版本比较和回归机制。

这就进入了下一步：如何把线上问题转化成能够反复执行的测试样本？

三、评测数据集：让 Agent 每次面对相同的问题

3.1 为什么只保存用户问题还不够？

对于普通问答模型，一条评测样本可能只需要用户问题、标准答案和评分规则。

但对于依赖工具的 Agent，这远远不够。

举个例子，用户让 Agent 排查 Dubbo 调用失败。

如果只保存一句“为什么这个服务调用失败”，而没有保存当时的 JMX、服务注册信息和异常日志，那么下一次重新评测时，Agent 面对的可能已经不是原来的问题现场。

服务可能已经恢复，配置可能已经修改，日志也可能发生变化。

在这种情况下，即使新版本给出的方案不同，也无法确认变化究竟来自 Agent 本身，还是来自外部环境。

因此，一条完整的 Agent 评测 Case，应该尽可能包括以下内容：

对于具有真实写操作的任务，还应包括初始环境状态、允许执行的操作，以及任务结束后需要检查的状态。

也就是说，评测集不只是问题列表，而应该是可以重复执行、能够验证结果的任务集合。

3.2 得物技术：通过 CLI Mock 固定问题现场

在得物的压测 Agent 案例中，除了使用 Langfuse 记录执行过程，还引入了 CLI Mock 机制。

其核心思路是：固定用户问题和工具返回的诊断证据，但让真实 Agent 重新执行分析流程。

例如，将某次 Dubbo 故障中的场景配置、JMX、日志和请求响应整理为评测 Case。

回测时，Agent 仍然按照正常流程调用 CLI，但 CLI Mock 返回预先固化的数据。

这样一来，前后两个 Agent 版本面对的是同一组业务证据。

评测流程可以概括为：

线上问题 → Trace 取证 → 固化 Case → Mock 工具证据 → Agent 重新分析 → 自动评分 → 对比结果。

这套方案特别适合工具依赖较多、外部数据容易变化的 Agent。

不过，Mock 也有自身边界。

它可以固定输入证据，却不能消除模型输出的随机性；它能够模拟预定义的工具调用，却未必能覆盖 Agent 自主选择的所有执行路径。

如果 Agent 请求了一个没有配置 Mock 的参数组合，评测系统还需要明确应该返回错误、记录未覆盖分支，还是采用其他处理策略。

另外，固定证据回测不能完全代替真实环境验证。

对于故障诊断建议，Mock 可以检查分析方案是否合理；但用户按建议操作后，故障是否真正恢复，还需要依赖真实调试结果或隔离测试环境中的状态检查。

3.3 Golden Dataset 应该怎么建设？

Golden Dataset 通常指经过人工校对、能够反复使用的高质量评测数据集。

但评测集并不是样本数量越多越好。

假设一个客服 Agent 的评测集包含 1000 条几乎相同的正常订单查询，却没有退款失败、参数缺失或权限不足等异常场景，那么即使通过率很高，也不能说明它在生产环境中足够可靠。

因此，评测集至少应该兼顾 Good Case 和 Bad Case。

Good Case 用来定义什么是符合业务预期的高质量行为。

Bad Case 则用来暴露 Agent 的能力边界，沉淀过去真实发生过的失败场景。

美团图灵团队特别强调，评测体系应从真实业务出发，随着 Good Case 和 Bad Case 的积累不断完善，而不是一开始就设计极其复杂的指标体系。

Anthropic 也建议在初期从真实失败和人工测试中选取少量任务，逐步发展评测集。

实际落地时，可以将评测集进一步划分为三个部分：

回归集（Regression Suite）：用于检查历史上已经解决的问题是否再次出现。

挑战集（Capability Suite）：用于检查 Agent 当前的能力边界，寻找更难、更复杂的任务。

独立保留集（Held-out Set）：不直接参与日常调优，用来检查改动是否具有泛化效果，避免研发人员只针对已知题目优化。

这三类评测集的作用不同，不能全部合并后只看一个平均分。

四、评分体系：Agent 不应该只由一个 Judge 打分

4.1 LLM-as-a-Judge 能解决什么问题？

LLM-as-a-Judge 是目前比较常见的自动化评测方案。

它使用一个大模型作为评审器，依据用户问题、参考答案和评分规则，评价被测 Agent 的实际输出。

相比字符串匹配，LLM 更适合处理开放性文本。

例如，参考答案要求 Agent 检查 Dubbo 的 namespace、group 和 version，而实际答案使用了不同的表达方式，只要核心含义一致，Judge 就可以认为其满足要求。

得物技术在压测智能分析 Agent 中，就采用了以人工期望答案为参考的五档评分机制。

评分从低到高分为：

这种方法的优点在于简单、易于批量执行，能够快速比较不同 Agent 版本的方案质量。

但是，五档评分同样有明显限制。

例如，Agent 得到 0.5 分，我们知道答案不够完整，却不一定知道它是没有找到正确证据，还是找到了证据但推理错误。

如果只用一个模型对所有维度进行综合评分，很容易失去对具体问题的解释能力。

4.2 从综合评分走向多维 Rubric

Rubric 可以理解为评价某项任务时使用的具体判断标准。

例如，我们希望评价一个故障诊断 Agent 的方案质量。

如果直接让 Judge 回答“这个方案是否专业”，不同评审模型甚至不同人工评测员，都可能给出完全不同的结果。

但是，如果把“专业”拆分为更具体的要求，评分就容易统一。

例如：

如果进一步把每个检查项拆解为“通过、失败、未知”，就可以更加准确地定位问题。

例如：

这里的“未知”非常重要。

证据不足，不等于 Agent 已经犯错；而没有观察到错误，也不代表一定正确。

美团图灵团队在主观评测校准中强调将模糊指标下钻，并尽量形成容易达成一致的二元化 Rubric。

Google 的评测服务也提供了基于具体任务的 Rubric 机制，用明确的检查条件评价模型输出。

这些实践说明，评测器越想准确归因，就越需要将抽象的“好不好”拆解成可以判断的事实。

4.3 规则评分、模型评分和人工评分应该各司其职

不是所有判断都需要调用大模型。

例如，Agent 是否调用了禁止使用的 API，是否传入错误的枚举值，或者是否违反 JSON Schema，都可以通过确定性程序检查。

对于这些问题，使用程序规则通常更便宜、更稳定，也更容易解释。

但遇到开放性任务，例如故障分析是否合理、用户意图是否得到满足，简单规则又无法覆盖所有有效表达。

因此，一套完整的评分体系通常需要三类评测器共同工作：

规则评测（Code-based Grader）：适合结构化字段、工具参数、权限约束、状态断言等确定性检查。

模型评测（Model-based Grader）：适合语义正确性、回答完整性、证据支持程度和复杂业务判断。

人工评测（Human Grader）：主要用于校准标准、复核争议案例，以及处理高价值或高风险任务。

Anthropic 的官方评测方法中也明确区分了这三类评测器。

货拉拉的业务 Agent 评测平台则进一步将确定性规则、模型裁判、多次评分以及 Session 级判断组合起来。

其中，一个很重要的设计是：严重违规不能简单地被其他维度的高分抵消。

例如，一个 Agent 在前九轮都表现正常，却在第十轮泄露了敏感信息。

如果只对每轮分数取平均值，可能得到一个看起来不错的综合分数。

但对真实业务来说，这次任务仍然存在严重安全问题。

因此，对于越权写操作、敏感信息泄露等红线问题，应设置独立的失败判定或评分上限，而不是完全依赖平均分。

五、评测器也可能出错：如何保证评分可信？

5.1 淘宝的案例：有时不是 Agent 错，而是评测数据错

淘宝技术团队在《淘宝 AI 购物助手在线评测落地实践》中，介绍了大规模线上会话评测面临的工程问题。

购物助手处理用户请求时，会经历意图识别、Skill 路由、工具调用和回复生成等环节。

为了评估真实线上表现，团队从业务日志和相关数据源中采集样本，再通过自动评测流水线进行分析。

但在实践中，他们发现了一个很值得关注的问题：

评测分数异常，并不一定意味着 Agent 质量下降。

例如，某些工具调用结果中包含了较长的内部提示词。

如果评测程序直接把整个工具调用记录交给 Judge，模型可能错误地将这些内容理解成 Agent 对用户输出的回复。

结果就是，实际回答正常的 Agent 被判定为输出大量无关内容。

还有一个问题发生在多轮会话中。

Judge 读取了之前轮次的工具结果，却把其中的信息作为当前轮次的事实依据，最终造成错误评分。

因此，淘宝团队除了改进 Judge Prompt，还需要不断完善数据清洗、字段映射、上下文隔离和业务状态解释。

这些工作看起来不像传统意义上的模型优化，但实际上直接决定了评测结果是否可信。

5.2 通过率下降，可能只是统计分母出了问题

淘宝还记录过一次路由指标异常。

某个业务域的路由通过率突然下降，最初看起来像是 Skill 路由能力退化。

但进一步拆解数据后发现，异常主要来自某类被错误纳入当前评测范围的请求。

这些请求并不属于该业务动作，却因为上游意图标签的问题被计入了统计分母。

当团队修正选样范围后，指标重新恢复稳定。

这里需要区分两个问题：

一个是线上 Agent 有没有正确路由。

另一个是评测系统有没有选择正确的样本来计算路由准确率。

这两个问题不能混为一谈。

如果评测样本本身发生变化，单纯比较前后通过率就可能得出错误结论。

因此，严谨的评测需要同时记录数据集版本、样本数量、适用范围、不可评样本比例，以及具体的评分规则。

5.3 美团的经验：先让人和人一致，再让人和机器一致

对于开放性任务，评分标准往往存在主观性。

不同的产品、开发、测试和业务专家，可能对同一个 Agent 回复产生不同判断。

如果人工标准尚未统一，直接使用 LLM-as-a-Judge 自动化评分，只会把这种分歧规模化。

美团图灵团队提出了“人人一致、人机一致”的校准思路。

首先，让不同人工评测员按照同一套标准独立标注，通过讨论和仲裁解决分歧。

然后，将这些已经校准的案例交给 Judge，观察机器评分与人工判断的差异。

如果分歧较大，就继续检查是 Rubric 不清晰、输入证据不足，还是 Judge 理解存在偏差。

在公开案例中，美团介绍过通过二元化 Rubric 改造评测标准，使相关业务的人机一致率得到明显改善。

这并不意味着所有业务都应该照搬同一套评分规则。

真正值得借鉴的是：先定义什么叫正确，再让机器学习按照这个标准判断。

对于模型 Judge，还需要持续抽样检查，并关注高分误判、低分误判及争议案例。

多次调用 Judge 可以帮助观察随机波动，但不能解决所有系统性错误。

如果评分规则本身不合理，让同一个模型连续评判十次，也可能只是稳定地产生十次错误结果。

六、长程 Agent：最终答案已经不足以证明任务成功

6.1 从回答问题转向完成任务

随着 Claude Code、OpenClaw 等 Agent 框架的发展，Agent 已经可以进入文件系统、执行命令、修改代码、操作浏览器和调用真实业务系统。

这类任务的特点是：执行时间更长，步骤更多，而且通常涉及真实环境状态变化。

过去的评测可能只需要比较：

Query → Answer

但对于长程 Agent，更合理的评测对象是：

Task → Execution Trace → Outcome

例如，一个 Agent 接到任务：修复项目中的登录错误。

它可能需要阅读代码、定位问题、修改文件、运行测试，最后提交修改结果。

如果最终回复写着“问题已修复”，并不足以证明任务成功。

评测系统至少还应检查修改是否正确、原始测试是否通过，以及是否引入新的回归问题。

图 2：长程 Agent 的评测对象

6.2 阿里云的实践：检查真实环境中的最终状态

阿里云在《从 Skill 到 Agent：评测技术的路径与实践》中，介绍了围绕云资源和数据开发任务开展评测的方法。

其中一个很典型的场景是：用户要求 Agent 修复任务并重新执行，Agent 返回执行成功，但最终需要的数据产物并没有生成。

这里存在一个关键区别：

工具调用成功，不一定代表业务任务完成。

因此，阿里云的相关实践不只检查 API 调用是否成功，还会根据任务目标进一步核对真实资源状态。

例如，在云数据库创建任务中，可以检查是否使用了正确的 API、参数是否符合要求、实例是否实际存在，以及数据库引擎、网络和计费配置是否正确。

对于 Skill，还需要测试不同的行为分支。

例如，用户拒绝修改时，Agent 是否停止执行？

上游依赖未完成时，Agent 是否按约定等待或退出？

目标资源存在歧义时，Agent 是否先进行澄清？

这些场景的正确结果未必是“完成创建”或“执行成功”。

如果用户已经明确拒绝操作，Agent 按要求终止任务，也应该被视为符合预期的行为。

这就要求评测集不仅包含标准成功路径，还必须包含异常、拒绝、澄清和回退等分支。

6.3 Skill 覆盖率与任务通过率是两回事

对于复杂 Skill，一个值得借鉴的做法是先整理行为清单，再检查测试是否覆盖这些行为。

例如，一个数据库管理 Skill 可能包含创建、查询、修改、删除、异常处理和人工审批等不同分支。

如果评测集中有一百条创建成功的案例，却没有一条用户拒绝删除的案例，那么测试数量虽然很多，但关键行为仍然没有被覆盖。

阿里云实践中介绍了使用 Skill Test Adequacy（STA）衡量行为覆盖的思路。

但行为被测试覆盖，并不意味着该行为一定正确。

例如，测试确实触发了“用户拒绝删除”分支，这只能说明覆盖了该分支。

如果 Agent 在用户拒绝之后仍然执行删除，那么这条 Case 仍然应该判定失败。

因此，测试覆盖率回答“有没有测到”，任务通过率回答“测到以后做得对不对”。

6.4 环境隔离与状态重置同样重要

当 Agent 真正修改文件、操作数据库或创建云资源时，评测还会遇到另一个工程问题：测试之间可能相互影响。

假设第一次测试创建了一个数据库实例，第二次测试继续使用同一环境。

如果没有清理之前的资源，Agent 即使没有执行创建操作，也可能因为实例已经存在而被错误判定为成功。

因此，长程 Agent 的评测需要明确环境准备、状态检查和资源清理流程。

对于具有写操作的任务，通常还要设置权限隔离、操作预算、超时限制和人工审批机制。

这里没有一种适用于所有场景的固定方案。

对于只读查询或故障诊断，Mock 可能已经足够。

对于代码修改，可以使用独立工作目录或容器。

对于云资源操作，则可能需要受控的测试账号和可清理的资源环境。

具体采用哪种方案，应由任务风险、执行成本和结果验证要求共同决定。

七、如何判断一次 Agent 调优是否真正有效？

7.1 固定变量，再比较版本

Agent 的最终结果会受到许多因素影响。

模型、Prompt、Skill、工具实现、上下文、业务数据甚至 Judge 版本，都可能改变评分结果。

假设某个版本同时升级了模型、修改了 Skill，又更新了评测数据集。

即使综合分数提高，也很难判断是哪项改动发挥了作用。

因此，正式比较时应尽量控制变量。

如果目的是验证 Skill 优化，就固定数据集、工具证据、模型和评分规则，只修改 Skill。

如果目的是比较模型，就固定 Agent 实现、评测样本和工具条件，只替换候选模型。

如果修改了评测规则，应使用同一版本的规则重新评测对比对象，而不是把新旧评分直接放在一起比较。

此外，需要记录 Agent 版本、数据集版本、Judge 版本、工具和环境配置等信息，保证实验结果具有可追溯性。

7.2 得物 Dubbo 调优的阶段性数据

得物技术公开的压测 Agent 实践中，Dubbo 是一个重点优化的协议场景。

其调优并不只是修改 Prompt，而是将人工排查经验沉淀到组件知识、校验规则和分析流程中。

例如，对于 No provider available 异常，除了检查服务名称，还应核对环境、namespace、group 和 version 和实际注册信息。

对于方法调用错误，也需要检查目标方法、参数类型和服务契约，不能简单地把相似方法名称当作可替代方案。

在工程实现上，得物通过 CLI 采集证据，使用 Python 进行确定性解析与检查，再由 LLM 结合组件知识、原始证据和候选原因形成最终建议。

其公开的阶段性结果显示，Dubbo 专项评测评分由约 50% 提升至 90%。

除此之外，文章还整理了 deepseek-v4-flash 001 至 007 系列的历史记录：

需要特别说明：这些是得物技术公开的历史评测记录，并不是本文作者的实验数据。

同时，Dubbo 专项评分、整体历史评分与单轮运行结果对应不同统计范围，不能直接视为同一个指标。

历史记录还显示，调优并非持续单调上升。例如，006 相比 005 的延迟和成本有所改善，但评分从 92.31% 回落到了 83.33%，直到 007 才进一步回升。

因此，相关数据能够用于说明阶段性评测表现和调优方向，但严格的效果归因仍需要核对数据集、评测器和 Agent 的对应版本。

尤其不能把离线评测的“解决率”直接解释成真实用户故障的最终解决率。

7.3 不要只看一次运行的分数

即使固定了数据集和外部证据，Agent 的执行仍然可能存在随机波动。

同一条 Case，第一次可能成功，第二次可能失败。

因此，单次满分并不一定代表稳定可靠。

Anthropic 在 Agent 评测实践中区分了两个指标：

pass@k：进行 k 次尝试，至少有一次成功的概率。

pass^k：连续 k 次尝试，全部成功的概率。

两者关注的目标不同。

对于某些探索型任务，只要多次尝试中有一次成功，就具有一定价值。

但对于用户每天都要使用的生产 Agent，稳定性通常更加重要。

举个简单例子，假设某任务单次成功概率为 75%，并且每次尝试可以近似看作独立事件。

那么连续三次全部成功的概率为：

0.75 × 0.75 × 0.75 ≈ 42.2%

所以，单次成功率看起来不错，并不意味着它能够连续稳定地完成任务。

正式评测时，可以根据业务特点同时观察平均评分、失败比例、多次运行稳定性和执行成本。

对于高风险任务，还需要对严重错误设置单独的判断标准。

八、从离线评测走向生产环境的质量治理

8.1 为什么离线评测和线上评测都需要？

离线评测的优势是条件可控，适合比较不同版本。

但它依赖预先准备的测试用例，无法完整覆盖真实用户不断变化的需求。

线上评测则可以观察真实任务分布，发现新的失败类型和系统性问题。

例如，离线数据集可能覆盖了正常退款、订单查询等标准场景，但真实用户可能提出表达模糊、信息缺失或多个意图混合的请求。

这些场景需要从生产数据中持续发现。

不过，线上评测也不能简单地把所有日志原样交给 Judge。

淘宝的经验已经说明，真实日志可能存在字段缺失、跨轮信息干扰和样本筛选问题。

因此，更合理的方式是：

离线评测用于验证改动与防止回归。

线上评测用于发现新问题与监控真实质量。

两者通过 Bad Case 沉淀和评测数据集更新建立联系。

8.2 评测要进入 CI/CD，而不只是生成报告

货拉拉的业务 Agent 评测平台，把评测进一步接入了研发交付流程。

例如，代码或 Prompt 变更时，触发核心冒烟测试；发布前执行基准回归；如果关键质量指标不符合要求，就阻断发布。

这种设计的价值不在于简单增加一个自动化步骤，而是把质量检查变成正常研发流程中的必经环节。

不过，发布门禁也不能只设置一个平均分阈值。

例如，一个版本平均评分提高了，但出现未经授权的工具操作，那么它仍然不应该通过安全检查。

比较合理的门禁可以同时包含：

如果评分器异常、数据不完整或评测执行失败，也不能将缺少结果直接解释为测试通过。

8.3 性能与成本也是 Agent 质量的一部分

传统 API 性能测试主要关注吞吐量、延迟和错误率。

Agent 的性能评价则更加复杂。

它可能需要连续执行多轮模型请求、工具调用和外部系统交互，因此需要区分单次模型调用与完整业务任务的耗时。

常见指标包括：

货拉拉公开实践中，就将功能评测与 Agent 性能压测结合，关注高并发、流式响应和系统稳定性。

但在实际评价时，质量和成本不能孤立比较。

一个模型成本更低，却需要大量重试才能完成任务，实际单任务成本未必更低。

一个模型响应速度较快，但经常产生错误建议，也不一定适合生产环境。

因此，模型选型应该优先保证任务质量与安全，再根据业务可接受的延迟和成本进行权衡。

九、真正可落地的 Agent 评测体系应该怎样建设？

前面介绍了多个技术团队的实践，但对于普通研发团队而言，并不需要从第一天就建设完整的评测平台。

一个可行的方向，是先从最小闭环开始，再逐步扩展能力。

图 3：评测体系落地的五个阶段

9.1 第一阶段：建立最小可观测能力

首先，保证每次关键 Agent 执行都能关联到必要的 Trace。

至少应该能够查看用户请求、模型调用、工具输入输出、错误信息、最终结果和基本耗时。

这样，当用户反馈问题时，研发人员不需要完全依赖事后描述，而是可以从执行记录中分析原因。

同时要注意日志脱敏、访问权限和保留周期，避免可观测性系统本身成为敏感数据泄露的来源。

9.2 第二阶段：建立小规模高质量评测集

从真实用户反馈、人工测试和已经修复的 Bug 中提取典型 Case。

起步时不必追求几千条数据。

Anthropic 在公开指南中建议，初期可以从 20～50 条真实任务开始，随着 Agent 成熟再增加样本规模。

关键是每条 Case 都应有明确输入、必要上下文、预期行为和判定标准。

对于依赖外部工具的任务，可以使用 Mock 固定数据；对于需要真实状态变化的任务，则逐步建立隔离测试环境。

9.3 第三阶段：采用分层评测器

不要上来就用一个大模型给所有任务打综合分。

先识别哪些指标可以通过程序断言完成，再把复杂语义判断交给 LLM-as-a-Judge。

同时保留人工复核机制。

对每个关键 Rubric，尽量明确什么情况通过、什么情况失败，以及哪些情况属于证据不足。

这样，评测结果才能用于问题归因，而不只是展示分数。

9.4 第四阶段：建立版本回归与对比机制

每次修改模型、Prompt、Skill 或工具后，运行对应的评测集。

比较时尽量固定其他变量，并记录实验配置。

重点关注三类结果：

本次要修复的问题是否得到改善？

历史上已经通过的任务是否出现退化？

质量提升是否伴随着无法接受的延迟、成本或安全风险？

对于波动较大的 Case，要重复运行，而不是根据某次表现判断效果。

9.5 第五阶段：将评测融入发布和线上反馈

最后，将核心回归测试接入 CI/CD 或发布流程，并持续从真实业务中收集新的失败案例。

形成以下闭环：

线上反馈 → Trace 取证 → 问题归因 → 修复 Agent → 固化回归 Case → 评测验证 → 发布上线 → 持续观测。

随着业务发展，这套体系还可以进一步扩展到多 Agent 协作评测、长程任务状态验证、对抗测试，以及基于评测结果的自动化调优。

但需要强调：自动化调优之后，仍然应该使用独立回归集验证结果，避免 Agent 只是在已有评测题目上得到了更高分数。

总结

图 4：评测—改进的持续闭环

通过梳理国内外技术团队的公开工程实践，可以发现 Agent 评测正在经历几个重要变化。

第一，评测对象从最终答案扩展到了完整任务。

Agent 不仅需要回答正确，还需要合理调用工具、遵守权限约束，并在必要时通过真实环境状态证明任务完成。

第二，评测体系不再依赖单一评分模型。

确定性规则、LLM-as-a-Judge、人工专家、Trace 分析和环境状态检查，都有各自适用的场景。真正可靠的体系，需要合理组合这些方法。

第三，评测器自身也需要持续校准。

淘宝的数据清洗实践、美团的人人一致和人机一致方法，以及 Anthropic 对评测结果复核的强调，都说明评测分数并不是天然可信的。

如果评测标准错误、样本范围不合理或输入证据存在问题，分数提高也可能与 Agent 能力改善无关。

第四，评测的最终目标是推动持续改进，而不是完成一次打分。

得物通过 Langfuse 与 CLI Mock 将问题排查和固定证据回归结合，货拉拉通过自动化评测和发布门禁连接研发流程，阿里云进一步强调任务行为覆盖和真实环境状态检查。

这些实践虽然面向不同业务，却体现了相似的工程思想：把每一次失败转化成可以定位、可以修复、可以重复验证的测试资产。

对于准备建设 Agent 评测体系的团队来说，最重要的不是一开始就选择最复杂的框架，或者设计最多的评价指标。

而是先回答几个基本问题：

Agent 失败时，我们能不能知道它哪里出了问题？

修改完成后，我们能不能在相同条件下验证效果？

评分提高时，我们能不能证明它反映了真实能力提升？

历史问题解决之后，我们能不能保证后续版本不再轻易退化？

Agent 评测真正要解决的，不是如何给一个智能体打出漂亮的分数，而是如何将大模型的不确定性，逐步转化成工程系统中可以观察、可以验证、可以治理的质量问题。

当线上反馈、执行轨迹、评测数据集和回归机制真正连接起来，Agent 才有可能从一个“看起来很聪明”的 Demo，逐渐成为能够在真实生产环境中稳定交付任务的系统。