原始来源:微信公众号 腾讯程序员,作者 TEG 云架构平台部 网关测试团队(martinskxu),发布于 2026-06-17。 原文链接:https://mp.weixin.qq.com/s/PUbGqheJhFMmb6hGj1ZtOw 导语:当 AI Agent 从”Demo 可用”走向”生产可靠”,测评就是那道必须跨过的门槛。本文介绍了 TEG 云架构平台部网关测试团队在 AI Agent 测评领域的体系化实践,面对 Agent 非确定性、黑盒化、错误级联放大三大难题,建立了一套”确定性评分器 + Rubric 评分器 + 人工评分器”三类组合的完整测评框架,覆盖功能正确性、过程质量、效率成本、鲁棒性安全、体验对齐五大维度,并已在 TPerf 性能平台智能分析 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:10
Rubric 评分器（模型评分）
灵活、可扩展，负责”代码搞不定但能结构化描述”的场景（如输出的内容包含自然语言）：
评分器类型
适用场景
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）—— 好用吗 │
└─────────────────────────────────────────────────────┘
下表汇总了每个大类的子维度、主要由谁来评分、以及落地优先级：
子维度
主要评委
优先级
结果正确性、任务完成度、指令遵循、工具调用正确性
推理合理性、步骤最优性、信息完整性、上下文利用率
Rubric + 人工
Token消耗、工具调用次数、延迟、失败重试率
一致性（pass^k）、异常恢复、抗对抗、幻觉率、越权风险、合规性
代码 + 人工
语气风格、清晰度、主动澄清、同理心、品牌一致性
Rubric + 人工
术语说明：
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 评分器（判断回答质量、检测幻觉）
代码编写更依赖 确定性评分器（编译是否通过、测试是否跑过）
功能工具更关注 过程对比（工具调用序列是否与基线一致）
问题定位则需要 过程 + 结果双重验证（推理链路正确且结论准确）
三、测评实施：怎么做？
第二章回答了”谁来评”和”评什么”的理论问题，本章进入实操层面——从设计用例、制定评分规则、建立基线，到执行测评、维护用例集，形成一个完整的实施闭环。每一步都给出具体的模板和示例，确保读者可以直接复用到自己的 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 逻辑
稳定失败
先检查任务定义或基线是否有问题