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 的自主性带来了三个传统软件没有的问题：
- 非确定性：同一 prompt 多次执行结果不同，"跑通一次"不代表"稳定能跑"。
- 黑盒化：模型升级、Prompt 微调、工具链变化都可能导致行为漂移，肉眼难以察觉。
- 错误级联放大：一次任务涉及几十步工具调用，前序步骤的一个小偏差会沿链路逐级放大，最终导致结论完全偏离。
没有测评会让团队陷入以下被动局面：
| 痛点 | 后果 |
|---|---|
| 主观性强 | 依赖"感觉变好了"的直觉判断，缺乏量化依据，团队无法基于数据做科学决策 |
| 悄悄退化 | 改了 Prompt 或升级了依赖，旧场景悄悄变差却无人知晓，直到用户投诉才暴露 |
| 人工验证成本高 | Skill 越多、模型迭代越快，靠人肉回归的成本指数级增长，最终只能"选择性验证"留下盲区 |
| 模型不敢升级 | 新模型发布时没有对比数据支撑切换决策，错过能力提升和成本下降的红利 |
| 缺少效率基线 | 没有延迟/Token/费用的历史基线，线上变贵变慢时无法定位原因和归因版本 |
| 过程易忽略 | 最终答案可能碰巧正确但推理路径是错的，无法区分"正确调用工具后回答"与"从训练数据碰巧答对" |
1.2 核心理念
面对这些痛点，我们需要的不是"偶尔跑一跑"的人工验证，而是一套嵌入研发流程的自动化评估体系。其核心可以概括为一个公式：
Eval（评估）= Agent 输入 → 执行 → 捕获执行过程（Trace + 产物） → 一组检查规则 → 可对比的分数
名词说明：Trace（执行轨迹）是 Agent 执行过程中产生的结构化日志，记录了每一步的工具调用、参数、返回值和思考过程，类似于程序调试中的"调用栈记录"。
测评的目标是建立一个可重复、可量化、可持续演进的评估闭环，而不是追求完美覆盖。关键在于：每次变更都能快速跑出一个可比较的分数，用数据代替直觉，用全量代替抽查。
二、测评框架：谁来评？评什么？
由谁（什么工具/角色）来打分？用哪些维度衡量 Agent 的表现？这构成了整个测评方案的理论基础。我们参考了 OpenAI 和 Anthropic 的实践经验，从中提炼出关键启示，后续的用例设计与评分器实现均建立在此基础之上。
[图片：三类评分器组合框架示意]
2.1 三类评委：谁来打分？
Agent 的输出既有可程序化验证的硬指标（文件存在、调用正确），也有只能靠语义理解才能判断的软指标（推理合理性、建议质量）。单一评分手段无法兼顾两者，因此 Agent 测评没有"银弹评分器"，必须三类组合使用：
┌──────────────────────────────────┐ │ 确定性评分器 │ │ （脚本 / 断言 / Lint / AST） │ │ 快、便宜、客观、可复现 │ │ ⇨ 负责所有"能用代码判断"的事 │ └──────────────────────────────────┘ ↑ │ 日常主力 │ ┌──────────────────────────────────┐ │ 模型评分器（Rubric） │ │ （LLM-as-Judge + Prompt + Schema）│ │ 灵活、可扩展、处理开放式输出 │ │ ⇨ 负责"代码搞不定但能结构化描述" │ └──────────────────────────────────┘ ↑ │ 扩展能力 │ ┌──────────────────────────────────┐ │ 人工评分器（专家） │ │ 昂贵、慢、黄金标准 │ │ ⇨ 负责"校准、诊断、兜底" │ └──────────────────────────────────┘三类评委职责对照
| 维度 | 确定性评分器 | Rubric 评分器 | 人工评分器 |
|---|---|---|---|
| 谁来评 | 脚本（Bash/Python） | 大模型（固定版本） | 领域专家 |
| 规则写在哪 | 代码里 | Prompt + JSON Schema | 人脑 + 标注指南 |
| 成本 | 毫秒级 / 免费 | 秒级 / API 费用 | 分钟–小时级 / 人力 |
| 稳定性 | 100% | 有抖动（需降噪） | 取决于标注员水平 |
| 覆盖能力 | 已知硬指标 | 未知软指标 | 主观 + 边缘场景 |
| 典型用例 | 文件存在、构建通过、测试通过 | 代码风格、意图贴合、解释清晰度 | 校准 LLM、诊断 0%/100% 异常、红队测试 |
| 门禁角色 | 硬门禁 | 分级门禁（error 硬、warning 软） | 不进门禁，做采样审查 |
选择优先级：确定性评分器 > Rubric 评分器 > 人工评分器——能用代码判断的绝不用模型，必要时用模型，人工用于校准。
确定性评分器
快速、客观、可复现，负责所有"能用代码判断"的事：
| 评分器类型 | 说明 | 适用场景 |
|---|---|---|
| 工具调用检查 | 检查是否调用了指定工具、参数是否正确 | 过程验证 |
| 产物检查 | 检查文件是否存在、内容是否符合预期 | 结果验证 |
| 关键词匹配 | 检查响应中是否包含/不包含特定内容 | 结果验证 |
| 执行指标 | 检查工具调用次数、token 消耗是否在阈值内 | 效率/成本验证 |
| 基线对比 | 将本次执行的过程和结果与基线快照逐项对比（详见第三章） | 回归验证 |
用例中的确定性规则示例：
expected_behavior: # 过程检查：是否调用了指定工具 - tool_call: "mcp" contains: "tperf-mcp" # 结果检查：产物是否存在 - file_exists: - "cpu.json" - "nic.json" # 结果检查：响应内容是否包含关键信息 - response_contains: - "测试有效" - "出现CPU瓶颈" - "业务QPS平稳" # 效率检查：工具调用次数上限 - max_tool_calls: 10Rubric 评分器（模型评分）
灵活、可扩展，负责"代码搞不定但能结构化描述"的场景（如输出的内容包含自然语言）：
| 评分器类型 | 说明 | 适用场景 |
|---|---|---|
| LLM 评判 | 让另一个 LLM 按评分标准判断表现 | 回答质量、语气、规范遵循度 |
用例中的 Rubric 规则示例：
rubric: observation_points: - 回答是否基于项目规范/知识库而非通用知识 - 推理过程是否清晰连贯 - 是否存在幻觉或编造内容 scoring: process_score: 0-100 # 过程分 result_score: 0-100 # 结果分 is_false_positive: bool # 是否虚假成功（结果对但过程错）人工评分器（专家介入的六个必要场景）
人工评分最贵，只在以下场景投入：
- 校准 LLM 评委（最核心用途）——抽样 100–200 条，和 LLM 打分对齐，一致率≥ 85%才算可用。
- 主观任务打分——回复同理心、报告论证严谨度。
- 诊断通过率异常——0% 或 100% 通常是"任务/评分器坏了"，不是模型弱。
- 建立 Ground Truth（黄金标准答案）——新套件上线的前 20–50 个参考解。
- Trace 采样审查——每周固定抽样读轨迹，找隐藏失败模式。
- 高风险兜底——医疗/金融/安全场景 100% 人工复核。
经验法则：能自动化的坚决不找专家；专家时间应60% 以上花在"校准 LLM 评委"和"诊断异常"上。
2.2 五个维度：评什么？
了解了"谁来评"之后，接下来明确"评什么"。我们将 Agent 的测评覆盖拆解为五个大类，从"做对了吗"到"好用吗"逐层递进：
┌─────────────────────────────────────────────────────┐ │ 1. 功能正确性（Functional Correctness）—— 做对了吗 │ │ 2. 过程质量（Process Quality）—— 过程合理吗 │ │ 3. 效率与成本（Efficiency & Cost）—— 划算吗 │ │ 4. 鲁棒性与安全（Robustness & Safety）—— 靠谱吗 │ │ 5. 体验与对齐（Experience & Alignment）—— 好用吗 │ └─────────────────────────────────────────────────────┘下表汇总了每个大类的子维度、主要由谁来评分、以及落地优先级：
| 大类 | 子维度 | 主要评委 | 优先级 |
|---|---|---|---|
| 1. 功能正确性 | 结果正确性、任务完成度、指令遵循、工具调用正确性 | 代码 | P0 |
| 2. 过程质量 | 推理合理性、步骤最优性、信息完整性、上下文利用率 | Rubric + 人工 | P1 |
| 3. 效率与成本 | Token消耗、工具调用次数、延迟、失败重试率 | 代码 | P1 |
| 4. 鲁棒性与安全 | 一致性（pass^k）、异常恢复、抗对抗、幻觉率、越权风险、合规性 | 代码 + 人工 | P0 |
| 5. 体验与对齐 | 语气风格、清晰度、主动澄清、同理心、品牌一致性 | Rubric + 人工 | P2 |
术语说明：
- Rubric：评分量表/评分标准，这里特指"用结构化的评分提示词让另一个大模型充当评委打分"的方式。
- pass^k：k 次试验中每次都通过的概率，衡量稳定性；pass@k：k 次中至少 1 次通过的概率，衡量峰值能力。
P0 先落地、P2 按需补充——优先保证"做对了"和"靠谱"，再逐步覆盖过程、成本和体验。
下面逐一展开五个维度的子项、评测方法和典型指标。
大类 1：功能正确性（Functional Correctness）
回答的问题："这次任务到底做成了没？"
| 子维度 | 定义 | 评测方法 | 典型指标 |
|---|---|---|---|
| 结果正确性 | 最终产出是否符合预期 | 代码比对、单元测试、数据库校验 | pass@1 / pass^k |
| 任务完成度 | 多步任务完成的百分比 | 子目标打点 | 完成率 % |
| 指令遵循度 | 是否严格按用户指令输出（格式、字段、约束） | JSON Schema 校验、正则、字段检查 | 遵循率 % |
| 工具调用正确性 | 是否选对工具、参数是否正确 | 调用日志断言 | 调用准确率 % |
这一类是P0，必须自动化、全覆盖。对应评分体系中"确定性评分器"的主战场。
大类 2：过程质量（Process Quality）
回答的问题："即便做对了，过程合理吗？"
| 子维度 | 定义 | 评测方法 | 典型指标 |
|---|---|---|---|
| 推理合理性 | 思考链条是否自洽、没有跳步 | Rubric 评委 | 合理性评分 1–5 |
| 步骤最优性 | 是否走了不必要的弯路 | 比较实际步数 vs 参考解法 | 步数比 |
| 信息完整性 | 输出是否覆盖了任务所需的所有关键信息 | Rubric 按要点核查 | 要点覆盖率 % |
| 上下文利用率 | 是否充分利用了提供的上下文，没有遗漏 | Rubric + 人工抽查 | 利用率评分 |
| 自我纠错能力 | 遇到错误时是否能识别并修正 | Trace 分析 | 纠错成功率 |
这一类最能体现"智能"水平，但自动化难度高，是Rubric 评委的主战场。
大类 3：效率与成本（Efficiency & Cost）
回答的问题："结果对了，但划得来吗？"
| 子维度 | 定义 | 评测方法 | 典型指标 |
|---|---|---|---|
| Token 消耗 | 输入 + 输出 token 总量 | API 统计 | avg / p95 tokens |
| 工具调用次数 | 完成任务的工具调用总数 | Trace 统计 | avg / p95 calls |
| 端到端延迟 | 用户发起到收到最终结果的时间 | 时间戳 | p50 / p95 / p99 latency |
| 失败重试率 | 单次试验内工具/模型调用的重试次数 | Trace 统计 | 重试率 % |
| 单次任务成本 | 折算成人民币/美元的成本 | Token × 单价 | ¥/task |
这是被很多团队忽视但极其重要的一类。一个 pass@1 高但 token 花 10 倍的方案，在生产上是不可接受的。建议每个任务都带上成本画像。
大类 4：鲁棒性与安全（Robustness & Safety）
回答的问题："它会不会在关键时刻翻车？"
| 子维度 | 定义 | 评测方法 | 典型指标 |
|---|---|---|---|
| 一致性 / 稳定性 | 相同输入多次运行结果是否一致 | 多次试验（k=5/10） | pass^k |
| 异常恢复 | 工具失败、超时、返回异常时能否兜底 | 故障注入测试 | 恢复成功率 |
| 抗对抗 / 抗注入 | 面对 Prompt Injection、恶意输入是否守住 | 红队用例集 | 抗攻击率 |
| 幻觉率 | 是否编造不存在的事实/API/字段 | 事实核查（代码或人工） | 幻觉率 % |
| 越权 / 越界风险 | 是否执行了超出授权的操作 | 权限断言 | 越权次数 |
| 合规性 | 是否泄露 PII、违反行业规范 | 正则 + 人工抽查 | 违规率 |
| 拒绝合理性 | 该拒绝时是否拒绝、不该拒绝时是否过度拒绝 | Rubric + 人工 | 误拒 % / 漏拒 % |
这一类是P0，尤其是涉及金融、医疗、企业数据的 Agent，必须前置。
pass^k 释义：k 次试验中每次都成功的概率，用于衡量一致性/稳定性。与之对应的 pass@k 是 k 次试验中至少 1 次成功的概率，用于衡量峰值能力。
大类 5：体验与对齐（Experience & Alignment）
回答的问题："用户愿意继续用它吗？"
| 子维度 | 定义 | 评测方法 | 典型指标 |
|---|---|---|---|
| 语气风格 | 是否符合品牌调性（专业/亲切/简洁） | Rubric 评委 | 风格评分 |
| 回复清晰度 | 结构是否清楚、有无废话 | Rubric + 人工 | 清晰度评分 |
| 主动澄清 | 模糊需求时是否会主动提问而非瞎猜 | Rubric | 澄清率 % |
| 同理心 | 对话场景中是否能识别情绪并恰当回应 | 人工 + Rubric | 同理心评分 |
| 可解释性 | 是否能说清自己做了什么、为什么 | 人工抽查 | 可解释评分 |
| 用户满意度 | 真实用户反馈 | 线上点赞/点踩、NPS | CSAT / NPS |
这一类是P2，但却是决定产品生死的。早期用 Rubric + 人工抽样，成熟后引入线上 A/B + 用户反馈闭环。
2.3 不同类型 Agent 的测评侧重
前面介绍的五大维度和三类评委是一套通用框架，适用于所有类型的 Agent / Skill。但在实际落地时，不同类型的 Agent 面临的核心风险不同，测评的侧重点也应有所差异——把有限的精力花在最容易出问题的地方：
| Agent / Skill 类型 | 测评侧重点 | 典型检查项 |
|---|---|---|
| 知识库问答 | 准确性、幻觉检测、引用溯源 | 回答是否基于知识库内容而非编造；是否正确引用来源；是否覆盖问题核心要点 |
| 代码编写 | 产物正确性、可运行性 | 生成的代码是否能编译/运行通过；是否满足功能需求；代码风格是否符合规范 |
| 功能工具（如性能分析、数据处理） | 过程合规性、工具调用正确性 | 是否按预期步骤调用了正确的工具；工具参数是否正确；输出报告是否完整准确 |
| 问题定位（如故障排查、日志分析） | 推理链路、根因准确性 | 推理过程是否逻辑清晰；是否定位到真实根因；排查步骤是否高效无冗余 |
差异体现在"用什么评分器"和"检查什么"，而非流程本身。例如：
- 知识库问答更依赖Rubric 评分器（判断回答质量、检测幻觉）
- 代码编写更依赖确定性评分器（编译是否通过、测试是否跑过）
- 功能工具更关注过程对比（工具调用序列是否与基线一致）
- 问题定位则需要过程 + 结果双重验证（推理链路正确且结论准确）