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

AI Agent Skill 测评方案及落地实践中本文为《AI Agent Skill 测评方案及落地实践》系列第 2 篇共 3 篇建议连续阅读。三、测评实施怎么做第二章回答了谁来评和评什么的理论问题本章进入实操层面——从设计用例、制定评分规则、建立基线到执行测评、维护用例集形成一个完整的实施闭环。每一步都给出具体的模板和示例确保读者可以直接复用到自己的 Agent 项目中。[图片测评实施闭环示意]3.1 设计测评用例集用例集需要从触发 → 核心逻辑 → 产物质量 → 异常容错四个场景层层递进每个场景都包含正向和负向用例。用例设计四大场景 ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ ① 触发 │ → │ ② 核心逻辑 │ → │ ③ 产物质量 │ → │ ④ 异常容错 │ │ 该触发吗 │ │ 过程对吗 │ │ 产物好吗 │ │ 出错扛得住│ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘场景关注点正向用例负向用例触发Skill 是否在正确场景被激活各种合法表述都能触发相似但不相关的 prompt 不误触发核心逻辑执行过程是否按预期步骤进行工具调用序列、参数、顺序正确缺少关键步骤、调用错误工具、参数错误产物质量最终产物是否完整、准确、可用响应内容准确、文件完整、格式正确内容缺失、格式错误、幻觉/编造异常容错异常输入/环境下能否合理处理优雅降级、明确提示崩溃、死循环、静默失败、泄露信息场景一触发条件用例验证 Skill 是否在正确的场景被触发/不被触发。用例 ID类型Prompt 示例预期行为设计意图trigger-pos-01正向分析用例134263skill_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触发方式核心检查点单用例-仅CPUlogic-cpu-01输入仅含 CPU 数据的用例只获取 CPU 数据不获取无关指标单用例-多指标logic-multi-01输入含多类指标的用例并行获取多类数据全部进入分析多用例对比logic-compare-01对比用例A和用例B两个用例数据都获取输出对比结论结论-存在瓶颈logic-bottleneck-01输入有明显瓶颈的用例识别瓶颈并输出优化建议结论-无瓶颈logic-normal-01输入指标正常的用例输出测试有效不编造问题决策树-压测无效logic-invalid-01QPS 未达预期的用例识别压测无效建议调整参数负向-过程异常logic-neg-01标准分析请求不调用无关工具、无无效重试循环第三步补充组合和边界— 关注分支间组合如多维度同时指定、阈值边缘如瓶颈临界值、跨分支冲突如对比用例指标类型不一致。经验法则核心逻辑用例的数量通常是其他三类场景用例之和的2–3 倍。如果一个 Skill 有 N 条核心分支路径至少需要 N 个正向用例 关键分支的负向用例。分支过多时优先覆盖高频分支和易出错分支。场景三产物质量用例验证 Skill 的最终产物——响应内容、输出文件、报告等是否完整、准确、可用。用例 ID类型Prompt 示例检查规则设计意图output-pos-01正向分析用例1434534file_existsresponse_containsresponse_format_check产物文件存在、关键结论完整、包含结构化内容output-pos-02正向分析用例1434534输出JSON格式报告file_valid_jsonfile_json_has_keys格式合规、必填字段齐全output-neg-01负向分析用例1434534response_not_contains: GPU使用率/api_key不编造指标幻觉、不泄露敏感信息场景四异常容错用例验证 Skill 在异常输入、边界条件、环境故障下能否合理处理而非崩溃或静默失败。子类用例 IDPrompt / 条件预期行为设计意图异常输入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 次试验建议 N5统计每次的分数。具体容忍阈值根据 Agent 使用类型调整详见第四章稳定性评估若均达标则取 N 次分数的平均值评分输出每执行一个用例会将每次评分的扣分结果和原因以 JSON 的形式输出并渲染成 HTML 报告归档用于回溯、专家介入。3.3 建立用例基线设计完用例后我们只定义了 prompt 和检查规则但并不确定 Agent 实际的执行过程和结果是什么样的。因此需要先跑一轮看到真实的过程和结果由人工评估是否可接受——如果 OK就将这轮的过程和结果保留下来作为该用例的预期基线。什么是用例基线用例基线是单个用例执行 1 次后经人工确认的预期过程和预期结果的快照。它回答的是这个用例正确的执行应该长什么样预期过程——Agent 应该怎么做过程内容说明思维链CoTAgent 的推理过程、决策依据、步骤规划工具调用序列调用了哪些工具、调用顺序、每次调用的入参和返回值中间产物执行过程中产生的临时文件、中间数据、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 生命周期变化必须区分两种套件类型核心问题期望通过率作用维护频率能力测评CapabilityAgent 能把什么做好起步 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 支持-ppipe模式以 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%输出多样性本身是特性关注核心逻辑正确性以下是 N5 时不同执行结果的解读和对应行动执行结果含义行动✓ ✓ ✓ ✓ ✓全部通过稳定可信赖✓ ✓ ✓ ✓ ✗存在幻觉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、费用、耗时步骤评分明细各维度扣分及上限