开发一个能回答问题、调用工具的 Agent 不难，难的是判断它能不能进生产系统。文章结合内部一套 Agent 评测系统，先区分它与传统软件测试的差异，再沿着用例设计、任务执行、评分和回归的顺序，讲清任务、成功标准、执行证据三要素如何协作。

目前来说，我们想要自己开发一个能够回答问题、调用工具的 Agent，通常都不太难。有各种开发框架和 AI Coding 工具的帮助，在需求明确、功能不复杂的情况下，专业人员三到五天就能做出一个大致可用的原型。现在难的是怎么评价这个 Agent，怎么判断它能不能进入生产业务系统。这些都绕不开一个关键环节：Agent 评测。

本文结合我们内部实现的一套 Agent 评测系统，先介绍评测的基本概念，再沿着用例设计、任务执行、评分和回归的顺序，说明各个环节如何协作。这个项目提供了一种具体实现思路，读者可以根据自己的业务规模和运行环境做出取舍和判断。

01 什么是 Agent 评测

Agent 本质上也是一个软件。按照我们传统的软件工程方法，我们一般把验证软件是否符合预期的工作称为“软件测试”。那为什么到了 Agent 这里，我们又经常说 评测 ？它们有什么不同？

一个主要差异，来自被测对象的行为特点，传统业务程序通常按照明确的逻辑执行，而 Agent 引入了模型的概率性决策，同样的输入可能产生不同的回答和执行过程。

传统软件测试更侧重验证：根据明确的预期，检查程序是否正确执行，判断一个用例通过还是失败，进而发现 Bug、防止回归，如果发现一个bug，那么它一定是可以复现的。

Agent 评测更强调衡量：同样的任务可能有多种合理的完成方式，单次成功也不能说明它始终可靠。我们除了判断任务有没有完成，还要评估完成质量、执行过程质量，以及多次运行的稳定性和成本。

我们来看看 一次 Agent 评测的基本过程是：给 Agent 一个任务，让它在指定条件下执行，再根据预先定义的标准判断表现。

这里有三个基本要素：

1. 任务：输入问题、必要上下文，以及允许使用的工具和资料。
2. 成功标准：什么结果算正确，哪些要求必须满足。
3. 执行证据：实际回答、工具调用、运行结果，以及时间和资源消耗。

对于知识问答 Agent，我们需要检查回答是否正确、是否是基于资料来完成问答，有没有编造事实。对于能够执行操作的 Agent，还要检查任务是否真正完成。

与单轮文本问答相比，Agent 还会选择工具、根据返回结果调整下一步。评测时，除了看最终回答，还需要结合工具调用和实际运行结果，判断任务是否完成。

具体检查哪些内容，要结合任务来定。只要求返回 JSON 的任务，可以重点检查结构与字段值；需要检索、分析和生成报告的任务，则需要同时检查内容和执行过程。下面结合我们内部的实现，看看这些评测要求如何落实到系统中。

02 一套评测系统如何运转

在做Agent测评之前，我们需要先做Agent的可观察性，也就是需要记录Agent的执行轨迹，这个也是评测的基石。

我们单独开发了一套 Agent runtime的运行底座，它主要负责Agent的运行和记录 执行轨迹。不同的业务共享这套运行能力，比如 聊天，知识库问答，内容创作等都运行在这套运行底座上面，只需要传入不同的业务代码，就可以区分开，同样，我们也把Agent的评测当成一个业务模块，共享这套运行机制，具体负责数据集管理、任务调度、评分和结果分析，支持后续复测与回归。

从使用流程来看，我们先编写用例、发布数据集版本，再选择被测 Agent 和评分器，创建评测任务。执行端领取任务后调用 Agent，保存回答和运行记录，接着执行评分、汇总报告。发现问题后，再根据执行证据修改配置，通过复测检查效果。

上述流程涉及任务配置、Agent 执行和结果评分。下面的架构图展示了它们如何衔接：实线表示主要调用和数据流，虚线表示持久化读写。图中展开的是服务端执行路径，桌面端的领取与回传方式放在后文说明。

这里可以分成3个部分：

1. 控制面：由 客户端管理评测任务，确定测什么、按什么标准测，并将配置和结果保存到关系数据库。
2. 执行端：由独立 Worker 领取任务、调用 Agent，记录实际回答和执行过程。
3. 评分环节：由评测服务模块在执行流程中组织评分，根据回答和运行记录判断表现，保存分数、理由和通过状态。

03 如何设计用例和数据集

不管是做什么测试，都离不开测试用例，用例设计决定了评测能发现哪些问题。我们需要从实际业务中选出有代表性的任务，写清楚 Agent 会收到什么信息，以及做到什么程度才算成功。

好用例要有明确的检验目标

核心用例应该由熟悉业务的人提供，再由测试人员扩展常见任务、边界场景。例如，资料问答既要检查信息齐全时能否答对，也要检查资料缺失时会不会编造。已经在线上出现过的错误，也应该整理成用例，供后续回归使用。

每条用例都要说明自己在检验什么。上图这条用例，给出的资料介绍了日报功能的运行方式，却没有首次上线日期。它检验的是 Agent 能否识别信息不足，并如实告知用户。只要明确了这个目标，输入和成功条件就容易确定。

好的用例还要让结果可以判断。笼统地要求回答准确、质量高很难评分，具体到这条用例，成功条件就是承认资料未提供日期，不编造上线时间。对于工具执行的任务，就需要写清楚需要得到什么结果。

用例需要包含哪些内容

一条用例通常包含任务输入和评分依据。前者把输入交给被测 Agent，后者在任务执行完成后用于检查结果。

问题和上下文需要符合要检验的场景。如果希望 Agent 从资料中找到答案，就要提供必要资料，如果需要测试信息缺失时的处理，就需要有意保留信息缺口。

参考答案和评分标准不能提前交给被测 Agent。

涉及复杂任务时，再补充必要的输入和执行条件。多轮对话需要此前的消息，工具任务需要明确可用工具、权限和外部环境，依赖时间的任务需要约定时间与时区。这些内容可以在高级设置里面进行补充，每一个用例都是不一样的配置。

根据成功条件选择评分方法

判分方法要跟用例要求对应。答案唯一、格式明确的要求适合代码检查，例如 只输出固定答案的，可以精确匹配，要求输出指定 JSON 结构，可以用 Schema 校验。允许多种合理表达的回答，则适合用模型根据评分标准判断语义，关键结果还可以由人工复核。

评分前还要确定通过条件。每一个用力都可以设置自己的评分器，多个评分器可以通过权重来综合计算得分，但业务上必须满足的要求应设为关键项，我们称为一票否决，就是这个评分器没有通过，其他评分器打的分再高也没有用。

用例整理好后，按业务场景归入数据集并发布固定版本。后续修改问题、参考答案或评分标准时，发布新版本，旧任务继续保留原版本，查看历史报告或比较两次评测时，才能确认当时用例详情，和评分标准。

04 如何组织和执行评测任务

创建任务时固定配置

测试用例的数据集准备好之后，我们还要确定被测 Agent、评分器、重复执行次数、工具权限，以及时间和资源预算等。

如上图所示，我们在创建好了评测任务之后，任务除了保存 Agent ID，还会保存创建时的配置快照，包括被测 Agent 与评测 Agent 的提示词、模型配置，以及评分器版本等信息，同时记录评测协议和 Runtime 版本标识。

Agent 的提示词和模型可能随时都会被修改，如果历史任务读取的是当前配置，我们就无法解释两次执行为什么不同。

配置快照用于追溯和复测，但是外部模型服务、工具实现和知识库内容仍可能发生变化。如果需要更严格的可复现性时，还要进一步记录这些环境条件。

执行输入与评分输入分开

评测任务创建后，执行端按任务引用读取固定版本的用例，并通过平台适配层调用共享 Runtime。

同一条用例中的内容，按用途进入两个环节：

1. 执行输入：问题、可用资料，以及需要时的对话历史和固定时间等条件，交给被测 Agent。Agent 根据这些信息回答问题或调用工具。
2. 评分依据：参考答案、评分标准和校验规则留在评分环节。Agent 完成后，评分器再结合实际回答和执行记录判断是否达标。

执行层和评分层都需要保存对应的运行轨迹，又统一的观察性平台记录日志。涉及工具的任务还会收集工具调用、任务返回和错误记录。即使后续评分失败，已经发生的被测执行仍然可以追溯，排查时就可以通过可观察性平台查看具体问题发生在哪里。

长任务交给独立 Worker

多条用例、重复执行和模型评分叠加之后，一次评测可能持续较长时间，我们不能通过点击一次开始执行，就依赖某个 HTTP 请求一直保持连接。

我们的服务端使用独立的 evaluation-worker。客户端负责认证、配置和任务管理，Worker 负责领取与执行。任务配置、状态和结果都做了持久化保存，用户关闭页面也不会中断服务端执行。

Worker 通过条件更新领取待执行任务，并记录领取者、租约和心跳。租约用于识别执行进程是否失联。对于失联时正在执行、结果不确定的用例，当前实现记录失败，不自动重放，以免重复执行已经发生的工具操作。

沿着服务端路径看，一次任务的主要交接如下。图中的每次重复都会重新执行被测 Agent，并重新评分；模型评分器也会产生各自的裁判 Run。

为执行设置边界

因为Agent的不确定性，我们不能让评测的worker一直跑用例，必须要做一些限制。

新建评测的时候，可以设置 任务执行时间限制，token限制，最大成本，同时支持设置单用例超时、以及工具权限限制。执行层会将剩余时间传给 Runtime，并在执行边界检查资源使用。

执行前，可以先设定超时时间、Token 和费用预算，避免某条用例长时间运行或消耗过多资源。预算检查依赖已记录的用量，实际消耗可能略有超出。如果用例需要修改外部数据，例如发送消息、修改业务数据，重复评测前还要准备好测试环境。

05 如何给结果和过程评分

Agent 执行完成后，每一个评测用例都会得到实际的运行结果和运行记录，这个时候每一个用例绑定的评分器就会开始工作，负责根据用例里面编写的的成功条件检查这些结果，给出分数、判断依据和通过状态。不同的评分器关注不同的问题，选择时要看我们希望检查回答质量、执行过程，还是某项明确的规则。

系统提供哪些评分器

当前评分器管理页面支持创建四类评分器，分别是 LLM 评分、过程指标、过程评分和人工复核。

LLM 评分主要检查最终回答的质量，过程指标通过代码统计运行中的问题，过程评分让模型结合执行轨迹判断步骤是否合理，人工复核则把结果交给人审核。它们可以在用例中按需要组合使用，同一条用例可以同时绑定不同的评分期，同时检查回答结果和过程轨迹。

精确匹配、包含匹配、正则匹配、JSON 校验，以及耗时、成本、工具调用和安全规则等明确条件，可以直接在用例中配置。执行时，这些规则也会转换为评分器，参与结果汇总。

这一类可以直接通过代码规则来处理的评分器，最开始我也是在评分器这里用新建一个来得到，后续我发现这样做不太合理，这一类评分规则 ，每一个用例的评判内容和条件都不相同，在评分器栏来创建公共的评分器并不合适，就把这一类评分器作为每一个用例的高级设置来单独配置，可以为每一个用例单独添加合适的规则评分。

精确匹配检查回答是否与指定文本一致，包含匹配检查是否出现要求的文本，可以设置全部包含或包含其中任意一项，正则匹配检查文本是否符合指定模式。这些方法适合措辞或格式有明确要求的任务。

JSON 校验检查输出能否解析为 JSON，以及是否符合指定的 Schema，包括必需字段、字段类型和取值约束。业务要求也需要写进规则，单独检查字段存在，并不能保证字段里的内容正确。

耗时和成本检查用于判断一次执行是否超出设定上限，工具调用检查用于确认要求的工具是否被调用、禁止的工具是否出现，安全规则检查用于识别回答是否命中配置的禁止模式。

评分检查回答质量

如果答案允许多种合理表达的回答，我们通常需要判断语义是否相同。LLM 评分会让评测 Agent 对照问题、上下文、参考答案和评分要求，检查实际回答的质量，这种方法也叫 LLM-as-a-Judge。

我们可以按业务需要设置评分维度，例如事实准确性、要点覆盖度、表达清晰度等。每个维度都要说明具体检查什么，再设置权重、通过阈值，以及是否属于必须满足的关键要求。

评分器与评测 Agent 各有职责。评分器保存评分标准和计算规则，评测 Agent 提供模型与提示词配置，负责对照这些标准作出判断。模型返回维度分数和理由后，程序校验结果、按配置计算得分，并判断是否通过。

测评报告会保留评分理由、评分器版本以及运行的日志记录，便于我们检查模型为什么这样判分。

过程指标和过程评分检查执行过程

涉及工具调用的任务，还需要检查 Agent 是怎样完成任务的。评测模块会把运行记录中的模型步骤、工具参数、工具返回和错误整理成执行轨迹，提供给评测Agent使用。这里面有两种评分策越，

过程指标 代码统计，主要检查工具调用次数、重复调用率、空转轮次、无效步骤和错误恢复率等，并与配置的阈值比较。它适合帮助我们发现调用过多、反复执行相同操作或出错后未能继续推进的问题。

过程评分 模型分析执行轨迹，重点判断工具选择是否合适、参数是否合理、步骤是否推进任务，以及出错后有没有采取有效的恢复措施。报告中可以保留具体步骤的问题，方便我们找到需要修改的位置。

这两类评分都依赖可观性平台记录的日志数据，都需要读取一次完整的运行轨迹日志来分析。

人工复核处理需要人判断的结果

人工复核适合业务判断较复杂、模型容易产生分歧，或者需要负责人确认的结果。审核人员查看实际回答、执行过程和评分要求，再提交分数与意见，绑定了人工复核评分器的用例，Agent评测完成后需要显示等待人工审核的状态的，人工提交判断后再更新判定。

人工判断也可以用来检查自动评分器配置是否合适。我们可以选取一组人工确认过的合格、不合格和边界样本，对照模型评分，找到容易误判的要求，再调整维度说明或阈值。

组合评分器

为用例选择评分器时，要分别考虑检查内容、得分权重和通过条件。明确的格式要求交给规则检查，回答质量交给 LLM 评分，需要检查工具过程时加入过程指标或过程评分，必要时再安排人工复核。

多个评分器可以按权重合成总分，但必须满足的要求 需要设为关键项。关键评分器未通过，即使其他评分器得分很高，用例也不能通过。LLM 评分器内部还可以为关键维度设置最低分，让让用例的核心诉求参与实际判定。

06 如何读报告、定位问题与回归

评测完成后，我们需要从报告中判断 Agent 的表现，找到没有满足要求的地方，再通过复测检查修改效果。系统提供报告汇总、用例详情、问题跟踪、重试、基线比较和发布门禁等功能，分别用于了解整体结果、定位原因和验证改动。

报告汇总帮助了解整体表现

报告汇总展示平均分、通过率、通过与失败用例数，以及 Token、预估成本和耗时等信息。平均分用于观察整体质量，通过率用于了解有多少用例满足要求，资源指标则帮助我们判断完成这些任务需要付出多少时间和成本。

这些指标我们需要结合起来看。平均分较高，仍可能有关键用例未通过，通过率提高，也可能伴随更长的执行时间和更多的模型调用成本。

报告按单次运行任务保存结果。如果设置重复执行后，每次都会重新运行被测 Agent，并按需要重新评分，实际回答和运行记录分别保留。多次执行后，可以对比每一次的分数变动，查看任务完成的波动率。

用例详情帮助找到问题原因

整体指标告诉我们哪些地方需要关注，用例详情则用于检查具体问题。进入一条用例后，可以查看输入、实际回答、分项评分、判断理由，以及关联的被测 Run运行记录和裁判 Run运行记录。

未通过的用例，需要检查是哪个评分器判断的失败，然后在进入执行轨迹里面去查看具体详情，到底是被测Agent的执行问题，还是评判Agent的误判。找到问题之后，才能有方向的修改，修改完成之后，也可以直接点击重试，这个用例就可以单独跑一次测评，查看修改效果。

系统支持全部重试、失败项重试和单用例重试。全部重试适合重新检查整批任务，失败项重试用于集中查看未通过的结果，单用例重试则方便排查某个具体问题。

失败用例会进入问题中心，保留来源和处理状态，方便后续跟踪。

基线比较用于判断改动效果

新建评测计划的时候，可以选择基线报告，这个基线报告是指，之前已经跑过的测评结果记录，修改提示词、更换模型或调整工具之后，可以选择一份已有测试报告作为基线，再与新任务比较。基线提供修改前的参照，帮助我们检查哪些能力改善、哪些能力退化。

比较内容包括得分和通过率变化、新增失败、持续失败、恢复通过的用例，以及耗时和成本变化。新增失败需要重点检查，恢复通过的用例则可以继续查看执行证据，确认原来的问题是否解决。

比较时尽量固定数据集、评分规则和执行条件，只改变这次准备验证的部分。如果同时更换模型、修改用例和调整裁判，即使分数发生变化，也难以判断原因。

新建评测时，同时可以设置发布门禁是，用于判断评测结果是否达到业务要求。

总结

做出一个大致可用的 Agent 之后，我们还需要知道，它在哪些任务上表现稳定，哪些地方容易出错，以及出了问题该怎么改。这也是我们建设这套评测系统最直接的目的。

前面介绍了用例、执行、评分，但这些环节最终都要回到具体的业务要求上。用例有没有覆盖实际场景，成功条件是否清楚，评分能不能反映真实表现，决定了评测结果有多大参考价值。

评测也需要随着业务持续维护。线上出现的问题要补进数据集，修改提示词、更换模型或调整工具之后，要重新检查原来的问题是否解决，有没有影响已经可用的能力。这样，当我们再次讨论一个 Agent 能不能上线、某次修改要不要发布时，就有具体的用例、执行记录和比较结果作为依据。

以上就是我们在做Agent评测的一点经验，欢迎大家指正。