AI Agent & Skill 测评方案及落地实践（中）
本文为《AI Agent & Skill 测评方案及落地实践》系列第 2 篇（共 3 篇），建议连续阅读。
三、测评实施：怎么做？
第二章回答了"谁来评"和"评什么"的理论问题，本章进入实操层面——从设计用例、制定评分规则、建立基线，到执行测评、维护用例集，形成一个完整的实施闭环。每一步都给出具体的模板和示例，确保读者可以直接复用到自己的 Agent 项目中。
[图片：测评实施闭环示意]
3.1 设计测评用例集
用例集需要从触发 → 核心逻辑 → 产物质量 → 异常容错四个场景层层递进，每个场景都包含正向和负向用例。
用例设计四大场景 ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ ① 触发 │ → │ ② 核心逻辑 │ → │ ③ 产物质量 │ → │ ④ 异常容错 │ │ 该触发吗？ │ │ 过程对吗？ │ │ 产物好吗？ │ │ 出错扛得住？│ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘| 场景 | 关注点 | 正向用例 | 负向用例 |
|---|---|---|---|
| 触发 | Skill 是否在正确场景被激活 | 各种合法表述都能触发 | 相似但不相关的 prompt 不误触发 |
| 核心逻辑 | 执行过程是否按预期步骤进行 | 工具调用序列、参数、顺序正确 | 缺少关键步骤、调用错误工具、参数错误 |
| 产物质量 | 最终产物是否完整、准确、可用 | 响应内容准确、文件完整、格式正确 | 内容缺失、格式错误、幻觉/编造 |
| 异常容错 | 异常输入/环境下能否合理处理 | 优雅降级、明确提示 | 崩溃、死循环、静默失败、泄露信息 |
场景一：触发条件用例
验证 Skill 是否在正确的场景被触发/不被触发。
| 用例 ID | 类型 | Prompt 示例 | 预期行为 | 设计意图 |
|---|---|---|---|---|
| trigger-pos-01 | 正向 | "分析用例134263" | skill_triggered | 标准表述 |
| trigger-pos-02 | 正向 | "帮我看看用例134263的性能数据" | skill_triggered | 口语化表述 |
| trigger-neg-01 | 负向 | "CPU高负载应该如何排查？" | skill_not_triggered | 通用问答，非分析任务 |
| trigger-neg-02 | 负向 | "用例134263是谁创建的？" | skill_not_triggered | 涉及用例但非性能分析 |
为什么需要负向触发用例？只测正例，Agent 可能学会"什么都触发"——过度触发比不触发更难发现。
场景二：核心逻辑用例
验证 Skill 触发后的执行过程是否按预期步骤进行——调用了哪些工具、顺序是否正确、参数是否合理。
这是用例量最大的场景。需要根据 Skill 的实际业务逻辑，梳理出所有核心分支，逐一覆盖。理论上，Skill 内部的每一条核心分支路径都应该有对应的测评用例。
设计方法：三步法
第一步：梳理分支流程图— 画出 Skill 的所有核心分支路径（如：单用例分析/多用例对比/各类结论分支/决策树分支等）。
第二步：每条分支至少 1 个用例— 示例（以性能分析 Skill 为例）：
| 分支路径 | 用例 ID | 触发方式 | 核心检查点 |
|---|---|---|---|
| 单用例-仅CPU | logic-cpu-01 | 输入仅含 CPU 数据的用例 | 只获取 CPU 数据，不获取无关指标 |
| 单用例-多指标 | logic-multi-01 | 输入含多类指标的用例 | 并行获取多类数据，全部进入分析 |
| 多用例对比 | logic-compare-01 | "对比用例A和用例B" | 两个用例数据都获取，输出对比结论 |
| 结论-存在瓶颈 | logic-bottleneck-01 | 输入有明显瓶颈的用例 | 识别瓶颈并输出优化建议 |
| 结论-无瓶颈 | logic-normal-01 | 输入指标正常的用例 | 输出"测试有效"，不编造问题 |
| 决策树-压测无效 | logic-invalid-01 | QPS 未达预期的用例 | 识别压测无效，建议调整参数 |
| 负向-过程异常 | logic-neg-01 | 标准分析请求 | 不调用无关工具、无无效重试循环 |
第三步：补充组合和边界— 关注分支间组合（如多维度同时指定）、阈值边缘（如瓶颈临界值）、跨分支冲突（如对比用例指标类型不一致）。
经验法则：核心逻辑用例的数量通常是其他三类场景用例之和的2–3 倍。如果一个 Skill 有 N 条核心分支路径，至少需要 N 个正向用例 + 关键分支的负向用例。分支过多时，优先覆盖高频分支和易出错分支。
场景三：产物质量用例
验证 Skill 的最终产物——响应内容、输出文件、报告等是否完整、准确、可用。
| 用例 ID | 类型 | Prompt 示例 | 检查规则 | 设计意图 |
|---|---|---|---|---|
| output-pos-01 | 正向 | "分析用例1434534" | file_exists+response_contains+response_format_check | 产物文件存在、关键结论完整、包含结构化内容 |
| output-pos-02 | 正向 | "分析用例1434534，输出JSON格式报告" | file_valid_json+file_json_has_keys | 格式合规、必填字段齐全 |
| output-neg-01 | 负向 | "分析用例1434534" | response_not_contains: "GPU使用率"/"api_key" | 不编造指标（幻觉）、不泄露敏感信息 |
场景四：异常容错用例
验证 Skill 在异常输入、边界条件、环境故障下能否合理处理，而非崩溃或静默失败。
| 子类 | 用例 ID | Prompt / 条件 | 预期行为 | 设计意图 |
|---|---|---|---|---|
| 异常输入 | error-input-01 | "分析用例23457778888"（不存在） | 告知"不存在"，不编造结果 | ID 无效时明确提示 |
| 异常输入 | error-input-02 | "分析用例abc"（非法格式） | 提示格式错误 | 输入校验 |
| 异常输入 | error-input-03 | "分析用例"（缺少 ID） | 主动追问用例 ID | 信息不足时追问而非瞎猜 |
| 边界条件 | error-boundary-01 | "分析用例999001"（数据量极大） | 正常完成，不超时 | 大数据量承压 |
| 边界条件 | error-boundary-02 | "分析用例100002"（数据为空） | 告知"无数据"，不编造 | 空数据处理 |
| 环境故障 | error-env-01 | 标准请求 +mock_tool_failure | 优雅降级提示，不无限重试 | 工具故障兜底 |
3.2 设计评分规则
用例集定义了"测哪些场景"，评分规则则定义了"怎么判对错、怎么算分"。一个好的评分规则需要兼顾可解释性（为什么扣分）和区分度（好坏能拉开差距）。以下是评分规则的设计示例。
评分规则
- 评分按负分制进行计算，初始总分 100 分
- 每有一个不符合预期的轨迹或结果，扣除对应的分数，扣至 0 分
- 达标的标准为80 分（推荐值，团队可根据 Agent 类型和业务风险等级调整），低于 80 分认为本次试验结果不通过
评分维度与计分项
| 评分维度 | 计分项 | 描述 |
|---|---|---|
| 结果 | 任务结果 | 任务结果和预期不符合，扣除 100 分 |
| 过程 | 步骤遵循性 | 是否按照预设的工作流一致，每有一步不符合预期，就扣 10 分 |
| 过程 | 步骤输出结果 | 中间步骤的输出结果是否和预设的一致，每有一步不符合预期，就扣 10 分 |
| 过程 | 调用工具/知识库 | 是否按照预设的调用工具链，每有一项不符合预期，就扣 10 分 |
| 效率 | 分析耗时 | 基准时长 5 分钟，5 分钟内未输出结果，每多 1 分钟，就扣 10 分 |
| 稳定性 | 一致性 | 对同一个任务进行 N 次试验（建议 N=5），统计每次的分数。具体容忍阈值根据 Agent 使用类型调整（详见第四章"稳定性评估"），若均达标则取 N 次分数的平均值 |
评分输出
每执行一个用例，会将每次评分的扣分结果和原因以 JSON 的形式输出，并渲染成 HTML 报告，归档用于回溯、专家介入。
3.3 建立用例基线
设计完用例后，我们只定义了 prompt 和检查规则，但并不确定 Agent 实际的执行过程和结果是什么样的。因此需要先跑一轮，看到真实的过程和结果，由人工评估是否可接受——如果 OK，就将这轮的过程和结果保留下来，作为该用例的预期基线。
什么是用例基线？
用例基线是单个用例执行 1 次后，经人工确认的预期过程和预期结果的快照。它回答的是："这个用例，正确的执行应该长什么样？"
预期过程——Agent 应该"怎么做"：
| 过程内容 | 说明 |
|---|---|
| 思维链（CoT） | Agent 的推理过程、决策依据、步骤规划 |
| 工具调用序列 | 调用了哪些工具、调用顺序、每次调用的入参和返回值 |
| 中间产物 | 执行过程中产生的临时文件、中间数据、API 响应 |
| 完整 Trace | 以上所有内容的结构化记录，可回放完整执行轨迹 |
预期结果——Agent 应该"产出什么"：
| 结果内容 | 说明 |
|---|---|
| 最终响应 | Agent 返回给用户的文本回答 |
| 输出文件 | 生成的代码文件、配置文件、数据文件等 |
| 输出报告 | 生成的分析报告、图表、结构化数据（如 JSON/CSV） |
基线建立流程
[图片：基线建立流程图]
核心思路：先跑出来，再确认，确认后就是预期。
- 用例设计阶段只需定义 prompt 和检查规则，不需要手写预期过程和结果
- 执行 1 次后，人工审核该次执行的过程（工具调用是否合理、思维链是否正确）和结果（响应是否准确、产物是否完整）
- 如果不可接受，则调整 Skill / 修复问题后重新执行
- 确认 OK 后，这次执行的完整快照就成为该用例的基线——后续每次执行都参考它来评分
完整的带细节流程图见第五章实战案例（5.3 节），展示了具体落地时每一步的详细操作。
基线在评分中的作用
后续每次测评执行时，将本次执行的过程和结果与用例基线做对比。基线同时服务于确定性评分器和Rubric 评分器两种评分方式：
- 确定性评分器使用基线进行可程序化的客观判定（如工具调用序列是否一致、产物文件是否存在、token 数是否超标）；
- Rubric 评分器使用基线作为参考答案（Reference Answer），由模型对比本次产出与基线的语义差异，按评分维度给出打分。
| 对比维度 | 对比内容 | 确定性判定（程序化） | Rubric 判定（模型评估） |
|---|---|---|---|
| 过程对比 | 本次工具调用序列 vs 基线 | 关键步骤缺失或顺序偏离 → 过程退化 | 思维链合理性、步骤选择是否最优 |
| 结果对比 | 本次响应/产物 vs 基线 | 关键内容缺失或产物不一致 → 结果退化 | 结论准确性、表述完整性、建议质量 |
| 效率对比 | 本次 token/步骤数 vs 基线 | 超出基线一定比例（如 >50%）→ 效率退化 | — |
基线更新时机
| 场景 | 操作 |
|---|---|
| Agent/Skill 逻辑变更 | 预期过程/结果可能变化，需重新执行 1 次并确认新基线 |
| 模型版本升级 | 执行行为可能变化，需重新执行 1 次并确认新基线 |
| 用例本身修改 | prompt 或检查规则变了，需重新执行 1 次并确认新基线 |
3.4 执行测评
用例设计完毕、评分规则就位、基线确认通过后，就可以正式执行测评了。执行阶段的核心是将上述准备工作串联成一个可自动化运行的流水线——加载用例 → 逐个执行 → 评分 → 汇总报告。
用例集执行流程
[图片：用例集执行流程图]
完整的带细节流程图见第五章实战案例（5.4 节），展示了并发执行、多评分器并行等具体实现。
触发时机
| 场景 | 触发方式 | 说明 |
|---|---|---|
| Agent/Skill 提示词变更 | 自动触发 | 每次 PR 合入前执行回归测评，验证更新后的表现，必要时重建基线 |
| 模型版本升级 | 手动触发 | 验证新模型对现有 skill 的兼容性 |
| 定期巡检 | 定时触发 | 周期性全量回归，发现潜在退化 |
3.5 用例集维护
测评体系不是"搭完就完"的一次性工程。随着 Agent/Skill 能力迭代、线上 Bad Case 积累、模型版本升级，用例集需要持续演进。一个长期不更新的用例集要么覆盖不足（新能力没测到），要么过时失效（旧用例不再适用）。以下是维护的关键场景：
能力测评 vs 回归测评
测评的目标会随 Agent 生命周期变化，必须区分两种套件：
| 类型 | 核心问题 | 期望通过率 | 作用 | 维护频率 |
|---|---|---|---|---|
| 能力测评（Capability） | "Agent 能把什么做好？" | 起步 20–50%，逐步提升 | 目标山峰，指导优化方向 | 主动拓展、频繁迭代 |
| 回归测评（Regression） | "原有能力是否还在？" | 接近 100% | 防御漂移、保住既有阵地 | 只增不减，CI 每次运行 |
与传统的测试流程不同，能力测评是和Skill开发同步启动的，Skill开发人员需要在设计之初就确定测评集，在开发过程中不断测评，通过测评结果优化Skill
生命周期转化：
┌──────────────┐ 持续优化 ┌──────────────┐ │ 能力测评 │ 通过率 = 100% ─────────────▶│ 回归测评 │ │ （新能力） │ │ （已掌握能力）│ └──────────────┘ └──────────────┘ ▲ │ │ │ 持续监控 │ 发现新失败模式（来自线上） │ └────────────────────────────────────────────────┘- 能力测评通过率稳定 = 100% 后，把用例"毕业"到回归套件，从此每次 CI 都跑。
- 回归用例集只加不减（除非用例真的过时）。
根据Anthropic的推荐，对于确定性的任务，用例集整体通过率（即所有用例中通过的占比）需要达到100%，对于非确定性的任务，推荐通过率≥ 95%。
Agent/Skill 调整时
当 Agent/Skill 的提示词、步骤、触发条件发生变更时，需要同步调整相关用例：
- 新增覆盖变更点的用例
- 更新受影响用例的预期行为
- 确认变更未破坏已有用例（回归验证）
新增 Bad Case 时
生产/线下环境发现的 Bad Case 是最有价值的测评素材：
- 复现 Bad Case，记录完整轨迹
- 分析根因，确定预期行为
- 修复 Agent/Skill
- 将 Bad Case 纳入用例集，防止下次回归出现一样的问题
- 该 Bad Case 用例进入能力测评集，通过率稳定后毕业到回归测评集
四、工程落地：如何自动化？
前三章完成了方法论层面的设计——评什么、怎么评、用例怎么组织。但方法论只有嵌入工程流程才能真正发挥价值：每次 PR 合入自动跑、每次模型升级自动比较、每次上线前自动门禁。本章聚焦将测评流程工程化的关键问题：Trace 从哪来、环境怎么隔离、稳定性怎么评估、报告需要包含什么。
[图片：工程落地总体示意]
4.1 前置依赖：被测 Agent/Skill 的 Trace 输出能力
过程评测的前提是能拿到结构化的执行轨迹。如果被测 Agent 只输出最终回答，没有可解析的中间过程，那么"工具调用检查"、"过程对比"、"基线对比"等评分器就无从下手。
对被测 Agent/Skill 的要求
| 要求 | 说明 |
|---|---|
| 输出结构化 Trace | 执行过程需以可解析的格式（如 JSONL、JSON）输出，包含工具调用、思维链、中间产物等 |
| Trace 内容完整 | 至少包含：每步的工具名称、入参、返回值、时间戳；理想情况还包含思维链和决策依据 |
| Trace 格式稳定 | 字段命名和结构在版本间保持一致，避免评分器因格式变更而失效 |
示例：CodeBuddy-Code 的-p模式
CodeBuddy-Code 支持-p（pipe）模式，以 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","changes":"..."},"timestamp":"2026-04-26T10:00:04Z"}这种格式天然适合过程评测：每行独立解析、可按type过滤工具调用或思维链、可与基线逐步对比。
如果被测 Agent/Skill 不支持结构化 Trace？
| 情况 | 应对策略 |
|---|---|
| 有日志但非结构化 | 编写解析器从日志中提取关键信息（成本高、易碎） |
| 仅有最终输出 | 只能做结果评测，放弃过程评测维度 |
| 可改造 | 推动 Agent/Skill 侧增加 Trace 输出能力（推荐） |
建议：在 Agent/Skill 设计阶段就将结构化 Trace 输出作为标准能力纳入，而非事后补救。这不仅服务于测评，也有利于线上问题排查和可观测性建设。
4.2 环境隔离
每次测评在隔离环境中执行，避免状态污染：
- Clone 仓库到临时目录
- 每个用例执行前重置环境（
git checkout . && git clean -fd） - 测评产物（Trace、日志、报告）统一归档
4.3 稳定性评估
通过多轮执行（N 次）检测 AI 的幻觉和非确定性。核心原则：只要 N 次中有 1 次不通过，就说明该用例存在稳定性风险，需根据 Agent 类型判断是否可接受。
不通过比例的容忍阈值取决于 Agent/Skill 的使用类型：
| Agent/Skill 使用类型 | 容忍阈值 | 说明 |
|---|---|---|
| 关键决策类（如问题定位、故障诊断） | 0%（N/N 全部通过） | 任何一次失败都可能导致误判（无论是幻觉、步骤遗漏还是逻辑错误），不可容忍 |
| 辅助分析类（如性能分析、报告生成） | ≤ 10%（如 10 次最多 1 次失败） | 偶发偏差可接受，但需持续观察 |
| 创意生成类（如代码建议、文案撰写） | ≤ 40% | 输出多样性本身是特性，关注核心逻辑正确性 |
以下是 N=5 时不同执行结果的解读和对应行动：
| 执行结果 | 含义 | 行动 |
|---|---|---|
| ✓ ✓ ✓ ✓ ✓ | 全部通过 | 稳定可信赖 |
| ✓ ✓ ✓ ✓ ✗ | 存在幻觉（1/5 失败） | 根据 Agent/Skill 类型判断是否可接受，需分析失败原因 |
| ✓ ✗ ✓ ✗ ✓ | 高幻觉率（2/5 失败） | 需深入排查 prompt/评分器/Agent/Skill 逻辑 |
| ✗ ✗ ✗ ✗ ✗ | 稳定失败 | 先检查任务定义或基线是否有问题 |
调试技巧：0% pass^N（即 N 次试验无一通过）通常说明任务定义有问题，而不是 Agent/Skill 能力不行。先检查用例描述是否有歧义、评分器是否配置错误、成功标准是否不合理。
4.4 测评报告
输出结构化的测评报告，报告应包含以下核心数据：
报告头部（全局概览）：
- 生成时间、用例总数
- 通过率（≥80分的用例占比）、平均分
- 模型版本及费用区间
- 总 Token 消耗、总费用（估算）
- 平均费用 / Trial
用例列表：
- 按任务分组展示，每组显示用例数量和均分
- 每条用例显示：名称、模型、执行次数（Trial 数）、得分
- Trial 分数分布图（直方图），直观展示稳定性
单用例详情：
- 任务分组、模型、测试记录 ID、基线耗时、基线 Token、基线费用、基线步骤数
- 提示词（Prompt）
用例汇总（多 Trial 聚合）：
- Token 总开销、总费用、平均费用、最终得分
- 每次执行的明细：分数、耗时、Token、费用、步骤扣分、效率扣分、结果扣分、对话详情入口
稳定性评分：
- 回归稳定性评分 = N 次执行全部达标后取平均分
- 显示执行次数、达标标准、达标情况
执行记录（逐 Trial 详情）：
- 每次 Trial 的 ID、Token、费用、耗时
- 步骤评分明细（各维度扣分及上限）
 agent和组件)