AI Agent Skill 测评方案及落地实践（上）

AI Agent & Skill 测评方案及落地实践（上）

本文为《AI Agent & Skill 测评方案及落地实践》系列第 1 篇（共 3 篇），建议连续阅读。

导语：当 AI Agent 从"Demo 可用"走向"生产可靠"，测评就是那道必须跨过的门槛。本文介绍了 TEG云架构平台部 网关测试团队 在 AI Agent 测评领域的体系化实践，面对 Agent 非确定性、黑盒化、错误级联放大三大难题，建立了一套"确定性评分器 + Rubric 评分器 + 人工评分器"三类组合的完整测评框架，覆盖功能正确性、过程质量、效率成本、鲁棒性安全、体验对齐五大维度，并已在 TPerf 性能平台智能分析 Agent 项目中落地验证。无论你是刚开始构建 Agent 测评体系，还是已有初步实践希望系统化升级，都可以从中找到可直接复用的方法论、评分模板与工程实现方案。

一、背景：为什么要做测评？

1.1 痛点

Agent 的自主性带来了三个传统软件没有的问题：

1. 非确定性：同一 prompt 多次执行结果不同，"跑通一次"不代表"稳定能跑"。
2. 黑盒化：模型升级、Prompt 微调、工具链变化都可能导致行为漂移，肉眼难以察觉。
3. 错误级联放大：一次任务涉及几十步工具调用，前序步骤的一个小偏差会沿链路逐级放大，最终导致结论完全偏离。

没有测评会让团队陷入以下被动局面：

1.2 核心理念

面对这些痛点，我们需要的不是"偶尔跑一跑"的人工验证，而是一套嵌入研发流程的自动化评估体系。其核心可以概括为一个公式：

Eval（评估）= Agent 输入 → 执行 → 捕获执行过程（Trace + 产物） → 一组检查规则 → 可对比的分数

名词说明：Trace（执行轨迹）是 Agent 执行过程中产生的结构化日志，记录了每一步的工具调用、参数、返回值和思考过程，类似于程序调试中的"调用栈记录"。

测评的目标是建立一个可重复、可量化、可持续演进的评估闭环，而不是追求完美覆盖。关键在于：每次变更都能快速跑出一个可比较的分数，用数据代替直觉，用全量代替抽查。

二、测评框架：谁来评？评什么？

由谁（什么工具/角色）来打分？用哪些维度衡量 Agent 的表现？这构成了整个测评方案的理论基础。我们参考了 OpenAI 和 Anthropic 的实践经验，从中提炼出关键启示，后续的用例设计与评分器实现均建立在此基础之上。

[图片：三类评分器组合框架示意]

2.1 三类评委：谁来打分？

Agent 的输出既有可程序化验证的硬指标（文件存在、调用正确），也有只能靠语义理解才能判断的软指标（推理合理性、建议质量）。单一评分手段无法兼顾两者，因此 Agent 测评没有"银弹评分器"，必须三类组合使用：

┌──────────────────────────────────┐ │ 确定性评分器 │ │ （脚本 / 断言 / Lint / AST） │ │ 快、便宜、客观、可复现 │ │ ⇨ 负责所有"能用代码判断"的事 │ └──────────────────────────────────┘ ↑ │ 日常主力 │ ┌──────────────────────────────────┐ │ 模型评分器（Rubric） │ │ （LLM-as-Judge + Prompt + Schema）│ │ 灵活、可扩展、处理开放式输出 │ │ ⇨ 负责"代码搞不定但能结构化描述" │ └──────────────────────────────────┘ ↑ │ 扩展能力 │ ┌──────────────────────────────────┐ │ 人工评分器（专家） │ │ 昂贵、慢、黄金标准 │ │ ⇨ 负责"校准、诊断、兜底" │ └──────────────────────────────────┘

三类评委职责对照

选择优先级：确定性评分器 > Rubric 评分器 > 人工评分器——能用代码判断的绝不用模型，必要时用模型，人工用于校准。

确定性评分器

快速、客观、可复现，负责所有"能用代码判断"的事：

用例中的确定性规则示例：

expected_behavior: # 过程检查：是否调用了指定工具 - tool_call: "mcp" contains: "tperf-mcp" # 结果检查：产物是否存在 - file_exists: - "cpu.json" - "nic.json" # 结果检查：响应内容是否包含关键信息 - response_contains: - "测试有效" - "出现CPU瓶颈" - "业务QPS平稳" # 效率检查：工具调用次数上限 - max_tool_calls: 10

Rubric 评分器（模型评分）

灵活、可扩展，负责"代码搞不定但能结构化描述"的场景（如输出的内容包含自然语言）：

用例中的 Rubric 规则示例：

rubric: observation_points: - 回答是否基于项目规范/知识库而非通用知识 - 推理过程是否清晰连贯 - 是否存在幻觉或编造内容 scoring: process_score: 0-100 # 过程分 result_score: 0-100 # 结果分 is_false_positive: bool # 是否虚假成功（结果对但过程错）

人工评分器（专家介入的六个必要场景）

人工评分最贵，只在以下场景投入：

1. 校准 LLM 评委（最核心用途）——抽样 100–200 条，和 LLM 打分对齐，一致率≥ 85%才算可用。
2. 主观任务打分——回复同理心、报告论证严谨度。
3. 诊断通过率异常——0% 或 100% 通常是"任务/评分器坏了"，不是模型弱。
4. 建立 Ground Truth（黄金标准答案）——新套件上线的前 20–50 个参考解。
5. Trace 采样审查——每周固定抽样读轨迹，找隐藏失败模式。
6. 高风险兜底——医疗/金融/安全场景 100% 人工复核。

经验法则：能自动化的坚决不找专家；专家时间应60% 以上花在"校准 LLM 评委"和"诊断异常"上。

2.2 五个维度：评什么？

了解了"谁来评"之后，接下来明确"评什么"。我们将 Agent 的测评覆盖拆解为五个大类，从"做对了吗"到"好用吗"逐层递进：

┌─────────────────────────────────────────────────────┐ │ 1. 功能正确性（Functional Correctness）—— 做对了吗 │ │ 2. 过程质量（Process Quality）—— 过程合理吗 │ │ 3. 效率与成本（Efficiency & Cost）—— 划算吗 │ │ 4. 鲁棒性与安全（Robustness & Safety）—— 靠谱吗 │ │ 5. 体验与对齐（Experience & Alignment）—— 好用吗 │ └─────────────────────────────────────────────────────┘

下表汇总了每个大类的子维度、主要由谁来评分、以及落地优先级：

术语说明：

• Rubric：评分量表/评分标准，这里特指"用结构化的评分提示词让另一个大模型充当评委打分"的方式。
• pass^k：k 次试验中每次都通过的概率，衡量稳定性；pass@k：k 次中至少 1 次通过的概率，衡量峰值能力。

P0 先落地、P2 按需补充——优先保证"做对了"和"靠谱"，再逐步覆盖过程、成本和体验。

下面逐一展开五个维度的子项、评测方法和典型指标。

大类 1：功能正确性（Functional Correctness）

回答的问题："这次任务到底做成了没？"

这一类是P0，必须自动化、全覆盖。对应评分体系中"确定性评分器"的主战场。

大类 2：过程质量（Process Quality）

回答的问题："即便做对了，过程合理吗？"

这一类最能体现"智能"水平，但自动化难度高，是Rubric 评委的主战场。

大类 3：效率与成本（Efficiency & Cost）

回答的问题："结果对了，但划得来吗？"

这是被很多团队忽视但极其重要的一类。一个 pass@1 高但 token 花 10 倍的方案，在生产上是不可接受的。建议每个任务都带上成本画像。

大类 4：鲁棒性与安全（Robustness & Safety）

回答的问题："它会不会在关键时刻翻车？"

这一类是P0，尤其是涉及金融、医疗、企业数据的 Agent，必须前置。

pass^k 释义：k 次试验中每次都成功的概率，用于衡量一致性/稳定性。与之对应的 pass@k 是 k 次试验中至少 1 次成功的概率，用于衡量峰值能力。

大类 5：体验与对齐（Experience & Alignment）

回答的问题："用户愿意继续用它吗？"

这一类是P2，但却是决定产品生死的。早期用 Rubric + 人工抽样，成熟后引入线上 A/B + 用户反馈闭环。

2.3 不同类型 Agent 的测评侧重

前面介绍的五大维度和三类评委是一套通用框架，适用于所有类型的 Agent / Skill。但在实际落地时，不同类型的 Agent 面临的核心风险不同，测评的侧重点也应有所差异——把有限的精力花在最容易出问题的地方：

差异体现在"用什么评分器"和"检查什么"，而非流程本身。例如：

• 知识库问答更依赖Rubric 评分器（判断回答质量、检测幻觉）
• 代码编写更依赖确定性评分器（编译是否通过、测试是否跑过）
• 功能工具更关注过程对比（工具调用序列是否与基线一致）
• 问题定位则需要过程 + 结果双重验证（推理链路正确且结论准确）