Agent评测:评测体系、工程实践与持续演进

现在在Agent框架的帮助下构建一个Agent其实是一件比较容易的事情，难的是如何保证你构建的Agent能正确稳定地运行，对实际业务产生帮助，这个就是本文要讲的内容：Agent评测，它是构建Agent的关键，也是Agent自迭代的重要基建，类比的是传统软件开发流程中的测试环节。

本文沿着“认识评测—设计评测—运行评测—持续演进—建设落地”的主线展开，重点说明Agent评测评什么、如何评，以及如何形成可持续的质量闭环。

一、Agent评测是什么

1.1 定义与核心目的

Agent评测以真实任务为载体，系统度量Agent的结果、过程、效率和风险。评测对象不是模型的一次回答，而是模型、Agent运行框架与外部环境共同产生的行为和结果。

Agent评测需要回答两个核心问题：

1. 1. Agent能否稳定完成目标？
2. 2. 完成得怎样，问题在哪里？

前者判断是否达到业务预期，后者定位能力短板和系统问题。评测结果应支撑版本对比、发布门禁、线上监控和迭代归因，而不只是产生一个分数。

1.2 Agent评测与LLM评测的区别

LLM评测回答“模型能力强不强”，Agent评测回答“模型进入系统后能否稳定交付”。

Agent系统表现
= 模型 + Prompt + Skill + 工具链
+ 知识与记忆 + 状态管理 + 业务流程 + 运行环境

失败可能源于模型推理，也可能源于Skill规则、工具调用、数据质量、上下文管理、状态流转或系统异常。因此，Agent评测既要判断结果，也要定位和归因。

1.3 Agent评测的四个层面

只看最终答案不足以判断Agent质量。两个Agent都可能完成任务：一个执行稳定、耗时可控、结果可复现；另一个反复试错、依赖偶然命中、结果不可复现。要识别这种差异，评测至少需要覆盖四个层面：

四个层面分别决定Agent是否可用、问题能否定位、能力能否规模化，以及行为是否可控。

二、Agent评测的核心对象与体系框架

第一章明确了Agent评测的对象和目标，本章进一步给出评测体系的全局地图：它包含哪些核心对象，各对象如何关联，以及整套体系由哪些层次构成。具体的评测集设计、评分机制、运行流程和持续演进，将在后续章节分别展开。

2.1 从质量定义到持续演进

从动态过程看，一套完整的Agent评测体系围绕以下闭环运转：

明确什么叫“好”
    ↓
把质量要求变成可执行的任务和判定规则
    ↓
在测试环境和真实环境中运行评测
    ↓
记录执行过程和最终结果，定位问题原因
    ↓
修复Agent或校准评测标准
    ↓
把典型案例加入评测集，持续回归

评测体系建设的本质，是把团队对业务质量的隐性认知，转化为可量化、可复用、可传递、可自动执行的显性资产。

这条闭环也是全文后续章节的主线：第三、四章分别展开任务与评分设计，第五章说明评测如何稳定运行，第六章说明问题如何归因并沉淀为评测资产。

2.2 Agent评测的核心对象

• • 任务（Task / Problem / Test Case）：具有明确输入和成功标准的单个测试，是评测的基本单元。
• • 试验（Trial）：Agent执行某个Task的一次完整尝试。同一Task通常运行多次Trial，以降低模型随机性的影响。
• • 执行轨迹（Transcript / Trace / Trajectory）：一次Trial的完整执行记录，包括输出、工具调用、中间结果、状态变化及其他交互。
• • 环境结果（Outcome）：Trial结束后环境中的实际最终状态。Agent声称“已完成”不代表任务成功，外部环境真实发生正确变化才是Outcome。
• • 评分器（Grader）：评估Agent某方面表现的逻辑。一个Task可以配置多个Grader，每个Grader包含多个断言（Assertion / Check）。
• • 评测套件（Evaluation Suite）：围绕特定能力或行为组织的一组Task。
• • 评测运行框架（Evaluation Harness）：位于Agent外部，组织Task和Trial，提供评测环境，并连接执行证据与评分结果。
• • Agent运行框架（Agent Harness / Scaffold）：负责处理输入、加载上下文、编排工具并返回结果。

这些对象形成如下关系：Evaluation Suite组织一组Task；Evaluation Harness驱动每个Task的一次或多次Trial；Agent Harness负责实际执行，并产生Trace与Outcome；Grader再依据Rubric完成判断。评测Agent，本质上是在评测“模型与Agent Harness的组合”。具体运行过程将在第五章展开。

2.3 评测体系的三层架构

从静态结构看，Agent评测体系可以分为三层：

三、Task与评测集设计

3.1 从“答案评测”到“行为评测”

广义评测集由“问题、参考答案、评价标准”三部分构成。随着Agent从问答形态演进为长程任务形态，三者的含义也随之变化：

短程问答任务的评测单元通常是：

Query + Ground Truth + Answer

长程Agent任务需要将任务定义、执行证据和评分标准分开：

Task（Initial State + Prompt + Expected Behavior + Success Criteria）
    ↓ 多次执行
Trial（Trace + Outcome）
    ↓
Rubrics + Graders

• • Initial State定义数据、工具、权限和环境的初始状态。
• • Prompt定义用户诉求与任务输入。
• • Expected Behavior定义必须满足的关键行为和约束，不要求唯一执行路径。
• • Success Criteria定义任务完成后应达到的结果和环境状态。
• • Trace记录Agent真实执行路径。
• • Outcome验证环境中的最终状态。

3.2 一个完整Task的结构

一个完整Task不只包含Prompt，还要定义任务起点、成功标准和判定方法。以下以“根据商家经营数据生成可演示的PPT”为例：

Task定义初始状态、用户目标、行为约束、成功条件和评分标准；Trial运行后产生Trace与Outcome，再由Graders依据Rubrics判定结果。

3.3 用多次Trial评估非确定性

Agent具有非确定性：相同Task在相同条件下运行，结果也可能不同。因此，单次成功或失败不足以代表真实能力，同一Task应在环境重置后运行多次Trial。

pass@k反映能力上限，pass^k反映稳定性。面向用户的Agent不能只看“多试几次能否成功”，还要看“每次是否可靠”。

3.4 围绕四个层面设计评测集

多个Task组成评测集。结果、过程、效率和风险不是四套独立的评测集，而是评价同一次Trial的四个层面。

以商家经营分析PPT为例：

过程层只约束影响结果和风险的关键行为，不限定唯一执行路径。

评测集还可以按任务粒度分为两类：

端到端评测集负责发现整体质量变化，模块级评测集负责定位问题。两类评测集都可以根据需要覆盖结果、过程、效率和风险。

评测集不宜一开始拆得过细。更合理的顺序是：先建立覆盖四个层面的端到端评测集，再为高风险和核心能力补充模块级评测集，最后根据真实失败Case继续拆分。

四、评测标准与评分机制

第三章定义了评测什么、如何组织评测集，本章进一步回答：一次Trial结束后，依据什么标准判断Agent做得好不好。

4.1 Metrics、Rubric与Grader的关系

评测标准需要依次回答三个问题：关注什么、怎样算好、如何判断。

三者形成一条逐步落地的链路：

质量目标 → Metrics → Rubric → Grader → 评分结果

Metrics定义方向，Rubric将方向转化为可判断事实，Grader负责执行判断。只有三者边界清晰，评测结果才可解释、可复现。

4.2 如何设计可判断的Rubric

Rubric设计的关键，是把“大而模糊”的质量要求拆成边界清晰、证据充分的判断项。

高质量Rubric通常满足五个条件：

1. 1. 单一：每条Rubric只判断一个事实。
2. 2. 可观测：能够从最终产物、Trace或环境状态中获取证据。
3. 3. 边界清晰：明确通过、失败和信息不足的判定条件。
4. 4. 不过度约束路径：只约束关键行为，不指定唯一执行步骤。
5. 5. 重要性明确：区分一票否决项、基础质量项和加分项。

客观事实类Rubric可尽量收敛为1 / 0 / unknown。其中，unknown表示证据不足、规则不清或不适用于当前样本，需要单独统计，不能直接按通过或失败处理。内容质量、视觉效果等主观维度可以使用带有明确行为锚点的分级量表，不宜直接采用缺少判定依据的自由打分。

4.3 如何选择Grader

Grader应根据Rubric所需证据选择，而不是统一交给模型判断。

选择原则是：客观事实优先使用代码，语义质量使用模型，高风险和模糊判断保留人工评审。 一个Task通常会组合多种Grader，而不是只选择一种。

4.4 如何验证评测标准可靠

自动化不等于可信。评测标准需要同时验证一致性、有效性和覆盖度：

• • 人人一致：多名业务专家基于同一Rubric独立评分，检验Rubric是否清晰、人工标准答案是否可信。
• • 人机一致：自动Grader与人工仲裁结果对比，检验自动评分能否替代人工并用于规模化评测。
• • 业务有效性：离线评测结果是否与用户满意度、任务完成率或业务指标同向变化，检验评测方向是否正确。
• • 覆盖度：评测集是否覆盖核心场景、长尾任务和高风险边界，检验评测结果能否代表真实任务分布。

当人人一致率低时，应优先修正Rubric；当人人一致率高、但人机一致率低时，应修正Grader实现、Judge Prompt或输入证据；当离线分数持续提升、线上价值没有改善时，应重新检查Metrics、Rubric和样本分布。

评测标准还应持续分析误判Case。不能默认“评测不通过就是Agent有问题”，也可能是Rubric边界错误、证据不足或Grader判断偏差。

人人一致保证标准清晰，人机一致保证自动评分可信，业务有效性保证评测方向正确，覆盖度保证评测结果具有代表性。

4.5 评分聚合与发布门禁

单条Rubric的判断需要进一步汇总为Task和评测集结果。常见方式包括：

• • 二元门禁：所有关键Rubric通过，Task才通过。
• • 加权评分：不同Rubric按权重汇总，达到阈值即通过。
• • 混合评分：安全和数据准确性使用二元门禁，内容与体验质量使用加权评分。

以经营分析PPT为例：

发布门禁不应只看平均分，还应关注关键Case是否退化、失败类型是否新增，以及多次Trial的稳定性是否下降。

一套可信的评分机制，不只是给Agent打分，还要能够解释为什么通过、为什么失败，以及评测结果是否值得相信。

五、评测工程与运行体系

5.1 一次评测如何运行

一次完整的评测运行包含七个环节：

落到工程实现，Evaluation Harness负责提供指令和工具、初始化环境、按运行配置串行或并发驱动Trial、采集Trace与Outcome、调用Grader并汇总结果。每个环节都需要可追踪：某个Task失败时，应能还原使用了哪个版本、在哪个环境中运行、执行了哪些操作，以及每条Rubric为什么通过或失败。

5.2 观测与可复现

Agent一次执行涉及模型、Prompt、Skill、工具、数据和外部环境。只保存最终输出和分数，无法解释结果变化，也难以复现问题。

一次Trial至少应记录：

Trial
├── Task与Trial标识
├── Agent、模型与参数版本
├── Prompt、Skill与工具版本
├── 评测集、Rubric与Grader版本
├── 初始环境、权限与数据快照
├── Trace
├── Outcome
└── Rubric判断、证据与最终评分

这些信息用于区分三类变化：

可复现不等于每次生成完全相同的轨迹，而是能够还原关键条件、解释差异并再次触发同类问题。Trace应记录可观测行为和状态，不依赖模型内部思维链；涉及敏感数据时，还需要脱敏和访问控制。

5.3 离线评测与发布门禁

离线评测用于比较候选版本与基线版本，判断一次变更是否可以发布。模型、Prompt、Skill、知识库、工具或Agent Harness发生变化时，都应触发相应范围的回测。

基线版本 ─┐
          ├── 相同评测集 + 相同环境 → 对比结果 → 发布或阻断
候选版本 ─┘

有效的离线评测需要满足：

• • 控制变量：除被评估的Agent版本外，数据、权限、工具和环境尽量保持一致。
• • 多次Trial：同时比较平均表现、稳定性和失败分布，避免单次随机结果误导判断。
• • 分层分析：既看评测集整体得分，也看关键Task、Rubric和新增失败类型。
• • 分级门禁：安全、权限和数据准确性一票否决，体验类指标设置综合阈值。
• • 接入流程：将评测嵌入CI/CD或发布流程，未通过时阻止或降级发布。

发布门禁不应只判断“总分是否上涨”，还应检查关键Case是否退化、unknown是否异常增加，以及收益是否以更高成本或风险为代价。

离线评测的核心职责，是守住已经被评测集覆盖的问题。

5.4 在线评测与在线监控

Agent上线后，还需要在真实请求、真实数据和真实环境中验证效果。在线评测与在线监控关注的问题不同：

工具调用成功不代表任务完成。例如，数据查询接口全部返回成功，但生成的经营分析PPT使用了错误口径，在线监控可能正常，在线评测仍应判定失败。

常见的在线评测方式包括：

在线监控还应关注行为分布，例如任务类型、Skill调用频次和平均对话轮次。行为分布发生变化，往往意味着用户需求或运行环境已经变化，评测集也需要随之更新。

离线评测守住已知问题，在线评测验证真实价值并发现未知问题，在线监控保障系统稳定运行。

六、Case挖掘、归因与持续演进

第五章通过离线评测、在线评测与监控发现质量变化，本章进入反馈演进层，进一步回答：发现问题后，如何完成Case挖掘与归因，并将问题转化为可修复、可回归、可复用的评测资产。

6.1 Case如何被发现

Case需要同时覆盖强信号、已知风险和未知问题，不能只依赖用户投诉。

线上信号不能直接作为评测样本。进入Case池前，还需要确认任务上下文是否完整、问题能否复现、数据是否可以安全使用，以及失败是否来自Agent本身。

6.2 从原始Case到评测资产

Case资产化需要经过一条标准流程：

发现原始Case
    ↓
补齐上下文并脱敏
    ↓
回放与确认问题
    ↓
标注预期行为和Rubric
    ↓
归类、去重与版本化
    ↓
加入评测集并持续回归

不同Case应进入不同资产集合：

Case进入评测集后，需要记录来源、适用版本、Rubric、Grader和历史结果。否则，样本会不断累积，却无法解释为什么加入、应该判断什么以及何时可以退出。

6.3 如何完成问题归因

归因不是给失败贴一个标签，而是找到最早出现偏差的位置，并形成明确的修复动作。建议按以下顺序处理：

1. 1. 确认是否真的失败：检查用户目标、Rubric和Grader是否合理。
2. 2. 还原执行现场：结合Trace、Outcome、版本和环境快照定位首次偏差。
3. 3. 判断根因层级：区分Agent、工具、数据、环境和评测标准问题。
4. 4. 确定修复与责任方：形成可验证的修复动作，并补充回归Case。

以经营分析PPT为例：

不能默认“评测不通过就是Agent有问题”。如果评测标准存在偏差，持续优化可能让Agent越来越迎合评测，却离真实用户价值越来越远。

6.4 Agent与评测体系的双闭环

完成归因后，问题会进入两条相互关联的迭代闭环：

线上观测与真实反馈
        ↓
Case挖掘、复现与归因
   ┌────┴────┐
   ↓         ↓
Agent问题   评测问题
   ↓         ↓
修复Agent   修正样本、Rubric或Grader
   └────┬────┘
        ↓
离线回测 → 灰度或A/B → 新一轮线上观测

Agent迭代闭环

如果问题来自Agent，需要调整Prompt、规划与路由、Skill、工具、上下文、知识或模型。修复后先通过离线评测确认问题消失且没有引入回归，再通过灰度或A/B验证真实效果。

评测体系迭代闭环

如果问题来自覆盖不足或评测偏差，需要补充Task、调整Rubric、修正Grader，并重新验证人人一致和人机一致。新增Case只有在标准清晰、证据充分后，才适合进入正式门禁。

双闭环的目标不是积累更多Case，而是让每个有效问题都能被复现、归因、修复，并转化为防止复发的评测资产。

七、建设路径与成熟度

完整的Agent评测体系涉及观测、评测集、评分、离线门禁、在线验证和Case回流，不适合一次性建设完成。更合理的方式是先形成最小闭环，再根据业务规模和真实问题逐步补齐能力。

7.1 最小可用评测闭环

冷启动阶段的目标不是建设复杂平台，而是让一次Agent变更能够被比较、问题能够被定位、修复能够被回归。

选择高频核心场景
        ↓
建立Trace与Outcome观测
        ↓
构建端到端种子评测集
        ↓
定义关键Rubric与基础Grader
        ↓
执行离线回测并形成发布判断
        ↓
将真实Bad Case补入回归集

最小闭环需要具备基本观测证据、端到端种子集、关键Rubrics与Graders、版本回测流程和Case回流机制。当团队能够稳定回答“新版本是否更好”“问题出在哪里”“同类问题是否再次发生”时，最小闭环才算真正建立。

7.2 分阶段建设路径

评测体系可以分为三个建设阶段：

建设顺序应由业务风险和当前短板决定。例如，高风险写操作应优先补齐权限与风险门禁；开放式内容生成应优先建设人工标准答案和模型评分校准。

7.3 评测体系成熟度

成熟度模型用于识别短板，而不是追求所有能力同时达到最高等级。

不同业务阶段对应不同的合理水位：

• • 冷启动阶段：观测L1 + 评测集L1 + 回测门禁L1，先形成最小闭环。
• • 扩量阶段：重点将评测标准、在线评测和Case机制推进到L2。
• • 稳定运营阶段：再建设L3所需的自动化和规模化能力。

不要追求所有维度同时达到L3，更有价值的是识别“短板”和“错配”，评测体系的能力上限，由最短的那块板决定。

八、结语

Agent评测评估的不是模型的一次回答，而是模型、Agent运行框架与外部环境共同形成的系统交付能力。可信的评测既要判断任务是否完成，也要解释执行过程、成本和风险。

评测体系的核心，是将团队对质量的隐性认知转化为Task、Rubrics、Graders和可复用的Case资产，再通过离线回测、线上验证和问题归因形成持续闭环。

建设时不必一次追求完整和复杂。先围绕核心场景建立最小可用闭环，再由真实问题驱动覆盖度、自动化和成熟度提升，通常比提前设计庞大的指标体系更有效。