AI Agent 测评体系设计：从评分器、用例集到工程落地

AI Agent 和传统软件最大的差异，不是多了一层大模型调用，而是行为变得更难预测。传统接口只要输入相同、版本相同，输出通常就是确定的；Agent 则可能因为模型采样、上下文变化、工具返回差异、Prompt 调整而产生不同路径和不同结论。

这让“跑通一次”失去了足够的说服力。一个 Agent 今天能完成任务，不代表改完 Prompt、升级模型、替换工具后仍然可靠。生产环境需要回答的是几个更具体的问题：

• 同一个任务重复执行，成功率有多高？
• 模型升级后，旧能力有没有退化？
• 最终答案对了，执行过程是不是也合理？
• Token、耗时、工具调用次数是否超过可接受范围？
• 遇到异常输入、工具失败、提示词注入时会不会失控？

Agent 测评要解决的不是“能不能偶尔成功”，而是“能不能持续、稳定、低成本地成功”。

Agent 测评到底测什么

可以把 Agent 测评抽象成一个闭环：

flowchart LR
    A[测评用例<br/>Prompt + 输入条件] --> B[Agent 执行]
    B --> C[采集执行轨迹<br/>Trace + 产物 + 指标]
    C --> D[评分器打分<br/>规则 / 模型 / 人工]
    D --> E[生成报告<br/>分数 + 扣分原因 + 成本]
    E --> F[修复或回归]
    F --> A

这个闭环有三个关键点。

第一，必须采集过程。只看最终回答，很容易漏掉“结果碰巧正确、过程完全错误”的情况。Agent 可能没有调用指定工具，却凭训练数据猜出了一个看似合理的答案；也可能漏掉关键步骤，但最后用含糊表述掩盖了问题。

第二，评分结果要可比较。同一个用例在模型 A 和模型 B 上的分数、成本、稳定性都要能横向比较；同一个 Agent 在上周和本周的表现也要能纵向比较。

第三，测评要进入研发流程。只在上线前人工点几条用例，无法覆盖模型升级、工具变化和 Prompt 微调带来的回归风险。更合理的做法是把测评接入持续集成（CI，Continuous Integration），每次关键变更都自动运行。

三类评分器：代码、模型和人工各司其职

Agent 输出里有些内容可以用程序判断，例如文件是否存在、JSON 是否合法、工具参数是否正确；有些内容只能靠语义判断，例如解释是否清楚、建议是否贴合上下文、推理是否自洽。单一评分方式覆盖不了全部场景。

一套实用的 Agent 测评体系通常需要三类评分器组合使用：

flowchart TB
    A[确定性评分器<br/>脚本 / 断言 / Schema / AST] --> B[Rubric 评分器<br/>LLM-as-Judge + 评分量表]
    B --> C[人工评分器<br/>专家标注 / 抽样复核 / 红队测试]

    A -.优先使用.-> D[能用代码判断的硬指标]
    B -.补充判断.-> E[开放式自然语言输出]
    C -.校准兜底.-> F[高风险和边缘场景]

选择顺序很简单：能用代码判断的，不交给模型；代码判断不了但可以写清评分标准的，再交给模型；模型也难以稳定判断、或者风险极高的，再让专家介入。

确定性评分器

确定性评分器负责所有“规则清楚、可以程序化判断”的内容。它是日常回归测评的主力。

常见规则包括：

expected_behavior:
  tool_calls:
    - name: mcp
      contains: tperf-mcp

  files:
    exists:
      - cpu.json
      - nic.json

  response:
    contains:
      - 测试有效
      - 出现 CPU 瓶颈
      - 业务 QPS 平稳
    not_contains:
      - api_key
      - GPU 使用率

  limits:
    max_tool_calls: 10
    max_latency_seconds: 300

这类规则的好处是稳定。只要输入数据和判定逻辑不变，结果就不会因为评分模型波动而变化。

Rubric 评分器

Rubric 是评分量表。用在 Agent 测评里，通常指让另一个大模型按照固定提示词、固定评分维度和固定输出格式打分，也叫 LLM-as-Judge。

Rubric 评分器适合判断自然语言质量，例如：

rubric:
  observation_points:
    - 回答是否基于给定知识库，而不是泛泛而谈
    - 推理过程是否连贯，有没有跳步
    - 是否编造不存在的字段、数据或 API
    - 建议是否能直接指导后续排查

  scoring:
    process_score: 0-100
    result_score: 0-100
    is_false_positive: boolean
    reasons:
      type: array
      items: string

为了减少模型评分抖动，需要固定评分模型版本、固定 Prompt、固定 JSON Schema，并定期用人工标注结果做校准。一个可用的 Rubric 评分器，和专家判断的一致率至少应达到一个团队可接受的阈值，例如 85%。

人工评分器

人工不应该承担日常回归的主要工作。专家时间最适合用在六类事情上：

0% 通过率和 100% 通过率都值得警惕。前者可能是 Agent 真不行，也可能是用例写错、基线错误、评分器过严；后者可能说明 Agent 稳定，也可能说明用例太简单、评分器没抓住关键点。

五个测评维度：从做对到好用

Agent 测评不能只看最终答案。一个完整的测评框架至少要覆盖五个层次：

flowchart TB
    A[功能正确性<br/>做对了吗] --> B[过程质量<br/>过程合理吗]
    B --> C[效率与成本<br/>划算吗]
    C --> D[鲁棒性与安全<br/>关键时刻会翻车吗]
    D --> E[体验与对齐<br/>用户愿意继续用吗]

P0 维度需要优先自动化，尤其是功能正确性和安全稳定性。体验类指标也重要，但通常可以在早期用抽样方式覆盖，等产品进入稳定阶段后再接入线上反馈和 A/B 测试。

pass@k 和 pass^k 不要混用

Agent 的非确定性使得“跑几次”本身也成为指标。

如果一个 Agent 跑 5 次，只有 1 次成功，那么 pass@5 可以是成功，但 pass^5 是失败。生产系统更关心 pass^k，因为用户不会因为“它偶尔能做对”就接受关键任务失败。

不同 Agent 的测评重点

通用框架相同，但不同类型的 Agent 风险点不同，测评权重也应该不同。

例如知识库问答需要重点防幻觉，代码生成则应该优先跑编译和测试。工具型 Agent 的关键不是“会不会说”，而是有没有按正确步骤调用正确工具。

用例集设计：从触发到异常容错

测评用例不是随便收集一批 Prompt，而是要覆盖 Agent 生命周期里的关键风险。一个实用的用例集可以分成四类：

flowchart LR
    A[触发条件<br/>该不该启动 Skill] --> B[核心逻辑<br/>执行路径是否正确]
    B --> C[产物质量<br/>输出是否可用]
    C --> D[异常容错<br/>异常场景是否可控]

触发条件用例

触发用例要同时测“该触发”和“不该触发”。只测正例会让 Skill 变成“什么都响应”，这在线上比漏触发更难排查。

核心逻辑用例

核心逻辑用例通常数量最多。设计时先画出 Agent 的主流程和分支，再保证每条关键路径至少有一个用例。

如果一个 Skill 有 N 条核心分支，至少需要 N 个正向用例，再补充高风险分支的负向用例。分支过多时，优先覆盖高频路径、历史 Bad Case 和影响结论的关键路径。

产物质量用例

产物质量关注最终输出是否能被用户或下游系统使用。

异常容错用例

异常用例要覆盖输入错误、边界条件和外部依赖故障。

MCP（Model Context Protocol，模型上下文协议）常用于让 Agent 标准化调用外部工具和数据源。只要 Agent 依赖外部工具，工具失败和返回异常就必须进入用例集。

评分规则：用扣分制把问题暴露出来

评分规则要能解释“为什么扣分”，也要能拉开好坏差距。一个简单可落地的方案是满分 100 分扣分制：

trial_score = max(0, 100 - 过程扣分 - 结果扣分 - 效率扣分 - 安全扣分)
trial_pass  = trial_score >= 80

评分输出建议使用结构化 JSON，便于生成报告和后续分析：

{
  "case_id": "logic-cpu-01",
  "trial_id": "trial-003",
  "score": 86,
  "pass": true,
  "deductions": [
    {
      "dimension": "process",
      "points": 10,
      "reason": "缺少网络指标排除步骤"
    },
    {
      "dimension": "efficiency",
      "points": 4,
      "reason": "Token 消耗超过基线 40%"
    }
  ]
}

基线管理：先确认一次正确答案，再做回归

很多 Agent 用例很难在设计阶段手写完整预期结果，因为它不仅有最终回答，还有工具调用、上下文检索、中间产物和耗时成本。更实用的方式是先执行一次，经人工确认后把这次执行保存为基线。

flowchart LR
    A[定义用例<br/>Prompt + 检查规则] --> B[执行一次 Agent]
    B --> C[采集 Trace 和产物]
    C --> D{人工确认可接受?}
    D -- 否 --> E[修复 Agent 或调整用例]
    E --> B
    D -- 是 --> F[保存为基线]
    F --> G[后续测评与基线对比]

基线包含两类内容。

后续每次测评都拿新执行结果和基线对比：

基线不是永久不变的。Agent 逻辑变更、模型升级、工具接口调整、用例 Prompt 修改时，都可能需要重新执行并确认新基线。

工程化落地：Trace、隔离环境和流水线

测评方案要真正有用，必须自动运行、可追溯、可复现。

Trace 是过程测评的前提

Trace 是 Agent 执行轨迹，记录工具调用、参数、返回值、时间戳、模型输出和中间产物。没有 Trace，就只能测最终结果，无法判断过程是否正确。

理想的 Trace 可以用 JSONL 表达，每行是一个独立事件：

{"type":"tool_call","name":"read_file","params":{"path":"src/main.ts"},"timestamp":"2026-04-26T10:00:01Z"}
{"type":"tool_result","name":"read_file","result":"...","timestamp":"2026-04-26T10:00:02Z"}
{"type":"thinking","content":"需要修改 handleRequest 的参数校验逻辑","timestamp":"2026-04-26T10:00:03Z"}
{"type":"tool_call","name":"edit_file","params":{"path":"src/main.ts"},"timestamp":"2026-04-26T10:00:04Z"}

Trace 至少要满足三点：

如果 Agent 只有非结构化日志，可以先写解析器提取关键信息，但长期看仍应把结构化 Trace 作为标准能力。

环境隔离避免状态污染

Agent 测评常常会读写文件、调用工具、生成报告。如果多个用例共用同一个工作目录，前一个用例的产物可能影响后一个用例，导致结果失真。

常见隔离方式：

# 每个用例执行前清理工作区
git checkout .
git clean -fd

# 或者为每个 trial 创建独立临时目录
tmp_dir=$(mktemp -d)
git clone "$repo_url" "$tmp_dir"

测评产物需要统一归档，包括 Trace、模型回答、评分 JSON、报告文件、HTML 报告和执行日志。

稳定性评估要多跑几次

Agent 测评不能只跑一次。建议对关键用例执行 N 次，常见取值是 5 或 10。

不同 Agent 对失败的容忍度不一样：

测评报告应该展示什么

好的测评报告不是只给一个总分，而是帮助工程师定位问题。至少应包含四层信息：

报告里最好同时展示质量和成本。一个模型通过率更高，但 Token 消耗是另一个模型的 10 倍，未必适合生产；另一个模型虽然便宜，但 pass^5 明显偏低，也可能不适合关键场景。

实战示例：性能分析 Agent 的测评方案

假设有一个性能分析 Agent，它部署在智能体平台上，接收压测记录 ID，通过 MCP 工具拉取 CPU、内存、网络、磁盘、业务指标，再结合知识库规则判断压测是否有效、是否存在瓶颈，并输出性能分析报告。

整体调用链路可以设计成这样：

sequenceDiagram
    participant U as 用户
    participant P as 性能测试平台
    participant A as 性能分析 Agent
    participant M as MCP 工具
    participant K as 业务知识库

    U->>P: 发起压测并查看结果
    P->>A: 压测完成后触发分析
    A->>M: 拉取压测指标数据
    M-->>A: 返回 CPU / 网络 / 磁盘 / 业务指标
    A->>K: 检索分析规则和排查经验
    K-->>A: 返回知识库片段
    A-->>P: 输出结构化分析报告
    U->>A: 追问瓶颈原因或优化建议
    A-->>U: 返回进一步排查建议

这个 Agent 的测评重点不是闲聊体验，而是三件事：

• 操作步骤合规：是否按正确流程拉取指标、检索知识库、生成结论。
• 执行效率可控：耗时、Token、工具调用次数是否在阈值内。
• 报告质量可靠：压测有效性、性能结果、瓶颈定位和建议是否正确。

评分设计

可以把满分 100 分拆成三类扣分：

综合公式：

trial_score = max(0, 100 + step_deduction + efficiency_deduction + report_deduction)
trial_pass  = trial_score >= 80

case_score =
  avg(trial_score)    当所有 trial 都达标
  0                   当任一 trial 不达标

示例：

这里采用了比较严格的稳定性策略：只要同一个用例的任意一次 Trial 低于 80 分，用例总分就归零。对于会影响性能瓶颈判断、版本发布判断的 Agent，这种策略能更早暴露偶发错误。

操作步骤评分

性能分析 Agent 的流程通常是一串工具调用。比较步骤时不能机械比较完整字符串，否则时间戳、文件内容、查询参数的小变化都会造成误报。更合理的做法是先归一化，再比较序列。

flowchart LR
    A[基线步骤序列] --> C[步骤归一化]
    B[Trial 步骤序列] --> C
    C --> D[LCS 序列对齐]
    D --> E[识别缺失 / 多余 / 顺序错误]
    E --> F[按规则扣分]

LCS（Longest Common Subsequence，最长公共子序列）适合做这类序列对齐。归一化规则可以包括：

这样能让评分器关注真正重要的流程差异，而不是被无关细节干扰。

报告评分

报告评分可以让模型按固定 Rubric 对比基线报告和 Trial 报告。关键判定必须严格一致，章节内容允许语义等价。

报告评分 Prompt 应要求模型输出结构化结果，而不是自由发挥：

{
  "key_judgement_match": true,
  "deductions": [
    {
      "section": "network",
      "points": 5,
      "reason": "Trial 漏掉了 RSS 队列收包不均的结论"
    }
  ],
  "total_deduction": 5
}

用例集组织

性能分析 Agent 的用例最好按瓶颈类型分组，每个用例绑定一条真实压测记录。真实记录生成后不可变，比 mock 数据更接近生产，也更利于复现。

用例配置可以写成 YAML：

task_group: test_cpu
task_group_alias: CPU 相关指标异常分析
tasks:
  - task_name: cpu_interrupt_bindcore_single_core_high_load
    task_desc: CPU 瓶颈，中断绑核异常，单核高负载
    tperf_test_record_id: "1258797"
    prompt: "分析用例 {tperf_test_record_id}"
    baseline_trial:
      session_id: "66254b2c49794713b02cbecd425ebf09"
      message_id: "269806ca2dd04e259b042345cf7fc313"

配置里不需要硬编码完整预期报告，只需要记录人工确认过的基线会话标识。评分时通过平台 API 获取基线报告、步骤、耗时和 Token。

执行流程

单个用例可以跑多次 Trial，并行触发、并行评分，最后聚合为稳定性结果。

flowchart TB
    A[加载用例配置] --> B[获取基线数据]
    B --> C[并发执行 N 次 Trial]
    C --> D1[步骤评分]
    C --> D2[效率评分]
    C --> D3[报告评分]
    D1 --> E[合并单次 Trial 得分]
    D2 --> E
    D3 --> E
    E --> F{所有 Trial 达标?}
    F -- 是 --> G[用例得分 = 平均分]
    F -- 否 --> H[用例得分 = 0]
    G --> I[生成 HTML 报告]
    H --> I

常见执行模式有三种：

模型对比报告建议同时展示质量、稳定性和成本：

pass@1 高但 pass^5 低，说明模型偶发失败较多；费用低但通过率明显下降，也未必适合生产。模型选型不能只看单次成功率。

用例集维护：能力测评和回归测评分开

Agent 测评体系需要持续维护。比较好的做法是把用例分成两套：

能力测评中的用例经过优化后稳定通过，就可以“毕业”进入回归测评。回归测评集原则上只增不减，除非业务逻辑已经变化到用例失效。

flowchart LR
    A[新增能力用例] --> B[能力测评]
    B --> C{稳定通过?}
    C -- 否 --> D[优化 Prompt / 工具 / Agent 逻辑]
    D --> B
    C -- 是 --> E[进入回归测评]
    E --> F[CI 每次运行]
    F --> G[发现退化或 Bad Case]
    G --> B

线上 Bad Case 是最有价值的用例来源。每发现一次失败，都应该按固定流程处理：

1. 复现问题，保存完整 Trace。
2. 分析根因，明确正确行为。
3. 修复 Agent、Prompt、工具或评分器。
4. 把 Bad Case 加入能力测评。
5. 稳定通过后转入回归测评。

术语速查

落地时最容易踩的坑

Agent 测评的核心不是追求一次性覆盖所有风险，而是建立一个能持续运行的工程闭环：用例描述任务，Trace 记录过程，评分器量化表现，基线保证可比较，流水线守住回归。只要这个闭环运转起来，Agent 的每次变更就不再依赖直觉判断，而是有明确分数、证据和成本数据支撑。