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

为什么需要测评？

痛点

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

1. 非确定性：同一提示词多次执行结果不同，跑通一次不代表能稳定跑通。

2. 黑盒化：模型升级、提示词微调、工具链变化都可能导致行为漂移，且肉眼难以观察。

3. 错误级联放大：一次任务涉及几十步工具调用，前序步骤的微小差异会沿着链路逐级放大，最终导致结论完全偏离

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

1. 主观观察性强。依赖“感觉变好了”的直观判断，缺乏量化依据，团队无法基于数据做科学决策。

2. 悄悄退化。改了提示词或升级了依赖，就场景悄悄变差，却无人知晓，直到用户投诉才暴露。

3. 人工验证成本高。SKU越多，模型迭代越快，靠人工回归的成本指数级增加，最终只能选择性验证，留下盲区。

4. 模型不敢升级。新模型发布时没有对比数据支撑，切换决策会错过能力提升和成本下降的红利。

5. 缺少效率基线。没有延迟、Token费用的历史基线，线上变慢变贵时无法定位原因或归因版本。

6. 过程易忽略。最终答案可能碰巧正确，但推理路径是错误的，无法区分正确调用工具后回答与碰巧答对

核心理念

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

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

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

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

测评框架

三类评委

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 # 是否虚假成功（结果对但过程错）

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

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

1. 校准 LLM 评委 （最核心用途）——抽样 100–200 条，和 LLM 打分对齐，一致率 ≥ 85% 才算可用。

2. 主观任务打分 ——回复同理心、报告论证严谨度。

3. 诊断通过率异常 ——0% 或 100% 通常是"任务/评分器坏了"，不是模型弱。

4. 建立 Ground Truth（黄金标准答案） ——新套件上线的前 20–50 个参考解。

5. Trace 采样审查 ——每周固定抽样读轨迹，找隐藏失败模式。

6. 高风险兜底 ——医疗/金融/安全场景 100% 人工复核。

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

五个维度

了解了"谁来评"之后，接下来明确"评什么"。我们将 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 + 用户反馈闭环。

不同类型 Agent 的测评侧重

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

Agent / Skill 类型	测评侧重点	典型检查项
知识库问答	准确性、幻觉检测、引用溯源	回答是否基于知识库内容而非编造；是否正确引用来源；是否覆盖问题核心要点
代码编写	产物正确性、可运行性	生成的代码是否能编译/运行通过；是否满足功能需求；代码风格是否符合规范
功能工具 （如性能分析、数据处理）	过程合规性、工具调用正确性	是否按预期步骤调用了正确的工具；工具参数是否正确；输出报告是否完整准确
问题定位 （如故障排查、日志分析）	推理链路、根因准确性	推理过程是否逻辑清晰；是否定位到真实根因；排查步骤是否高效无冗余

测评实施

设计测评用例集

用例集需要从 触发 → 核心逻辑 → 产物质量 → 异常容错 四个场景层层递进，每个场景都包含 正向 和 负向 用例。

用例设计四大场景 ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ ① 触发 │ → │ ② 核心逻辑 │ → │ ③ 产物质量 │ → │ ④ 异常容错 │ │ 该触发吗？ │ │ 过程对吗？ │ │ 产物好吗？ │ │ 出错扛得住？ │ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘

场景	关注点	正向用例	负向用例
触发	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	优雅降级提示，不无限重试	工具故障兜底

设计评分规则

用例集定义了"测哪些场景"，评分规则则定义了"怎么判对错、怎么算分"。一个好的评分规则需要兼顾 可解释性 （为什么扣分）和 区分度 （好坏能拉开差距）。以下是评分规则的 设计示例 。

评分规则

• 评分按 负分制 进行计算，初始总分 100 分

• 每有一个不符合预期的轨迹或结果，扣除对应的分数，扣至 0 分

• 达标的标准为 80 分 （推荐值，团队可根据 Agent 类型和业务风险等级调整），低于 80 分认为本次试验结果不通过

评分维度与计分项

评分维度	计分项	描述
结果	任务结果	任务结果和预期不符合，扣除 100 分
过程	步骤遵循性	是否按照预设的工作流一致，每有一步不符合预期，就扣 10 分
过程	步骤输出结果	中间步骤的输出结果是否和预设的一致，每有一步不符合预期，就扣 10 分
过程	调用工具/知识库	是否按照预设的调用工具链，每有一项不符合预期，就扣 10 分
效率	分析耗时	基准时长 5 分钟，5 分钟内未输出结果，每多 1 分钟，就扣 10 分
稳定性	一致性	对同一个任务进行 N 次试验（建议 N=5），统计每次的分数。具体容忍阈值根据 Agent 使用类型调整（详见第四章"稳定性评估"），若均达标则取 N 次分数的平均值

评分输出

每执行一个用例，会将每次评分的扣分结果和原因以 JSON 的形式输出，并渲染成 HTML 报告，归档用于回溯、专家介入。

建立用例基线

设计完用例后，我们只定义了 prompt 和检查规则，但 并不确定 Agent 实际的执行过程和结果是什么样的 。因此需要先跑一轮，看到真实的过程和结果，由人工评估是否可接受——如果 OK，就将这轮的过程和结果保留下来，作为该用例的 预期基线 。

什么是用例基线？

用例基线是 单个用例 执行 1 次后，经人工确认的 预期过程 和 预期结果 的快照。它回答的是："这个用例，正确的执行应该长什么样？"

预期过程 ——Agent 应该"怎么做"：

过程内容	说明
思维链（CoT）	Agent 的推理过程、决策依据、步骤规划
工具调用序列	调用了哪些工具、调用顺序、每次调用的入参和返回值
中间产物	执行过程中产生的临时文件、中间数据、API 响应
完整 Trace	以上所有内容的结构化记录，可回放完整执行轨迹

预期结果 ——Agent 应该"产出什么"：

结果内容	说明
最终响应	Agent 返回给用户的文本回答
输出文件	生成的代码文件、配置文件、数据文件等
输出报告	生成的分析报告、图表、结构化数据（如 JSON/CSV）

基线建立流程

核心思路：先跑出来，再确认，确认后就是预期。

• 用例设计阶段只需定义 prompt 和检查规则，不需要手写预期过程和结果

• 执行 1 次后，人工审核该次执行的过程（工具调用是否合理、思维链是否正确）和结果（响应是否准确、产物是否完整）

• 如果不可接受，则调整 Skill / 修复问题后重新执行

• 确认 OK 后，这次执行的完整快照就成为该用例的基线——后续每次执行都参考它来评分

基线在评分中的作用

后续每次测评执行时，将本次执行的过程和结果与用例基线做对比。基线同时服务于 确定性评分器 和 Rubric 评分器 两种评分方式：

• 确定性评分器 使用基线进行可程序化的客观判定（如工具调用序列是否一致、产物文件是否存在、token 数是否超标）；

• Rubric 评分器 使用基线作为参考答案（Reference Answer），由模型对比本次产出与基线的语义差异，按评分维度给出打分。

对比维度	对比内容	确定性判定（程序化）	Rubric 判定（模型评估）
过程对比	本次工具调用序列 vs 基线	关键步骤缺失或顺序偏离 → 过程退化	思维链合理性、步骤选择是否最优
结果对比	本次响应/产物 vs 基线	关键内容缺失或产物不一致 → 结果退化	结论准确性、表述完整性、建议质量
效率对比	本次 token/步骤数 vs 基线	超出基线一定比例（如 >50%）→ 效率退化	—

基线更新时机

场景	操作
Agent/Skill 逻辑变更	预期过程/结果可能变化，需重新执行 1 次并确认新基线
模型版本升级	执行行为可能变化，需重新执行 1 次并确认新基线
用例本身修改	prompt 或检查规则变了，需重新执行 1 次并确认新基线

执行测评

用例设计完毕、评分规则就位、基线确认通过后，就可以正式执行测评了。执行阶段的核心是将上述准备工作串联成一个可自动化运行的流水线——加载用例 → 逐个执行 → 评分 → 汇总报告。

用例集执行流程

💡 完整的带细节流程图见第五章实战案例（5.4 节），展示了并发执行、多评分器并行等具体实现。

触发时机

场景	触发方式	说明
Agent/Skill 提示词变更	自动触发	每次 PR 合入前执行回归测评，验证更新后的表现，必要时重建基线
模型版本升级	手动触发	验证新模型对现有 skill 的兼容性
定期巡检	定时触发	周期性全量回归，发现潜在退化

用例集维护

测评体系不是"搭完就完"的一次性工程。随着 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 是 最有价值的测评素材 ：

1. 复现 Bad Case，记录完整轨迹

2. 分析根因，确定预期行为

3. 修复 Agent/Skill

4. 将 Bad Case 纳入用例集，防止下次回归出现一样的问题

5. 该 Bad Case 用例进入能力测评集，通过率稳定后毕业到回归测评集

工程落地：如何自动化？

前置依赖：被测 Agent/Skill 的 Trace 输出能力

过程评测的前提是 能拿到结构化的执行轨迹 。如果被测 Agent 只输出最终回答，没有可解析的中间过程，那么"工具调用检查"、"过程对比"、"基线对比"等评分器就无从下手。

对被测 Agent/Skill 的要求

要求	说明
输出结构化 Trace	执行过程需以可解析的格式（如 JSONL、JSON）输出，包含工具调用、思维链、中间产物等
Trace 内容完整	至少包含：每步的工具名称、入参、返回值、时间戳；理想情况还包含思维链和决策依据
Trace 格式稳定	字段命名和结构在版本间保持一致，避免评分器因格式变更而失效

如果被测 Agent/Skill 不支持结构化 Trace？

情况	应对策略
有日志但非结构化	编写解析器从日志中提取关键信息（成本高、易碎）
仅有最终输出	只能做结果评测，放弃过程评测维度
可改造	推动 Agent/Skill 侧增加 Trace 输出能力（推荐）

建议 ：在 Agent/Skill 设计阶段就将结构化 Trace 输出作为 标准能力 纳入，而非事后补救。这不仅服务于测评，也有利于线上问题排查和可观测性建设。

环境隔离

每次测评在 隔离环境 中执行，避免状态污染：

• Clone 仓库到临时目录

• 每个用例执行前重置环境（ git checkout . && git clean -fd ）

• 测评产物（Trace、日志、报告）统一归档

稳定性评估

通过多轮执行（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 能力不行 。先检查用例描述是否有歧义、评分器是否配置错误、成功标准是否不合理。

测评报告

输出结构化的测评报告，报告应包含以下核心数据：

报告头部（全局概览）：

• 生成时间、用例总数

• 通过率（≥80分的用例占比）、平均分

• 模型版本及费用区间

• 总 Token 消耗、总费用（估算）

• 平均费用 / Trial

用例列表：

• 按任务分组展示，每组显示用例数量和均分

• 每条用例显示：名称、模型、执行次数（Trial 数）、得分

• Trial 分数分布图（直方图），直观展示稳定性

单用例详情：

• 任务分组、模型、测试记录 ID、基线耗时、基线 Token、基线费用、基线步骤数

• 提示词（Prompt）

用例汇总（多 Trial 聚合）：

• Token 总开销、总费用、平均费用、最终得分

• 每次执行的明细：分数、耗时、Token、费用、步骤扣分、效率扣分、结果扣分、对话详情入口

稳定性评分：

• 回归稳定性评分 = N 次执行全部达标后取平均分

• 显示执行次数、达标标准、达标情况

执行记录（逐 Trial 详情）：

• 每次 Trial 的 ID、Token、费用、耗时

• 步骤评分明细（各维度扣分及上限）

实战案例：TPerf 性能 AI 分析 Agent

理论和框架讲了四章，读者可能会问："实际做起来到底是什么样的？"本章以 TPerf 性能 AI 分析 Agent 为真实案例，从 Agent 特点出发，逐步展示如何将前四章的通用方法论落地为一套完整的、可运行的测评实践——包括评分标准的具体化、用例集的实际组织、基线管理的实操流程、以及最终的工程实现和报告效果。

5.1 Agent 概述

TPerf AI 分析 Agent 属于「功能工具」类型，部署在 Knot 智能体平台上，通过 MCP 工具调用 TPerf-API 获取各维度性能数据，结合知识库检索进行深度分析，经决策树判断资源瓶颈点和压测有效性，输出包含排查建议和优化方向的结构化性能分析报告。

整体调用链路

• ①② 用户 ↔ TPerf 平台 ：用户在平台执行性能测试任务，获取压测结果

• ③ TPerf 平台 → Agent ：压测完成后，平台自动触发 Agent 进行用例结果分析

• ④ Agent → TPerf 平台 ：Agent 通过 MCP 工具拉取任务的性能压测数据

• ⑤ Agent ↔ 业务知识库 ：Agent 检索业务知识库，获取分析规则和排查经验

• ⑥ Agent → TPerf 平台 ：Agent 将分析报告输出到平台展示，报告包括压测有效性，性能指标结果，资源瓶颈点，优化排查建议

• ⑦⑧ 用户 ↔ Agent ：用户查看分析结果，也可对话追问，或手动指定用例进行分析，Agent 返回排查建议

• ⑨ 用户操作 ：根据 Agent 建议进行性能调优

测评侧重三个方面： 操作步骤合规性 + 执行效率 + 输出报告质量 。

5.2 测评设计

了解了 Agent 的定位和能力边界后，接下来按照第二、三章的通用框架，针对 TPerf AI 分析 Agent的业务特点进行具体化设计。

评分标准

采用 确定性评分 + 模型评分 两层组合， 满分 100 分扣分制 （沿用第三章 3.2 的通用评分框架）。TPerf 将通用方案中的"任务结果"映射为"关键判定"（压测有效性 + 性能结果），将"过程"细化为"操作步骤"，将"产物质量"细化为"章节内容"逐项对比。

确定性评测维度 （由脚本自动判定）：

维度	关注点	最大扣分	评分方法
操作步骤	工具调用流程是否与基线一致？	-10	使用 LCS（最长公共子序列）算法对齐基线与 Trial 的操作步骤，步骤不一致/多余/缺少/顺序错误各扣 2 分
效率	分析耗时和 Token 消耗是否合理？	-10	耗时以 300s 为基准每超标 10% 扣 1 分；Token 以基线消耗为基准每超标 10% 扣 1 分
稳定性	同一任务多次分析，结论是否一致？	—	并发 N 次执行，全部达标取平均分，任一不达标则 0 分（见下方说明）

模型评分维度 （由 LLM 按 Rubric 判定）：

维度	关注点	最大扣分	评分方法
关键判定	压测有效性判定（有效/无效）和性能结果判定（通过/不通过）是否与基线一致？	-80	任一项不一致直接扣 80 分
章节内容	CPU/内存/网络/磁盘IO/业务指标/根因定位/优化建议/报告完整性/数据准确性	每项 -5，上限 -80	调用 CodeBuddy CLI 让大模型逐项对比基线报告与 trial 报告

一致性判断标准：

• 数值型 ：整数精确匹配，小数允许相对误差 ≤ 1%

• 结论型 ：异常等级和关键发现一致（如"正常"/"异常"/"堆积"）

• 建议型 ：核心排查方向一致即可， 允许命令参数和措辞差异

关于稳定性"0 容忍"策略的说明 ：第四章 4.3 将"辅助分析类"的容忍阈值定为 ≤10%。TPerf 虽属辅助分析类，但其性能分析结论直接影响后续优化决策和版本发布判断， 一次错误结论可能导致性能问题漏检上线 ，因此选择了更严格的"关键决策类"标准——任一 Trial 不达标即判定该用例不通过。团队可根据自身场景的风险等级调整此阈值。

综合评分公式：

单次 Trial: trial_score = max(0, 100 + 步骤扣分 + 效率扣分 + 报告扣分) 达标判定: trial_pass = (trial_score ≥ T)，T = 80 用例总分: case_score = avg(所有 trial_score) 若全部 trial_pass = true = 0 若任一 trial_pass = false

评分示例（N=3, T=80）：

用例	Trial 1	Trial 2	Trial 3	全部达标？	用例总分
cpu-01	95	92	88	✅ 全部 ≥ 80	91.7
cpu-02	90	75	93	❌ Trial 2 < 80	0
nic-01	100	100	98	✅ 全部 ≥ 80	99.3
disk-01	85	82	80	✅ 全部 ≥ 80	82.3
tcp-01	80	79	85	❌ Trial 2 < 80	0

用例集设计

明确了评分标准后，接下来看用例集如何组织。TPerf AI 分析 Agent 的用例集按 性能瓶颈场景 分组，覆盖 9 大类共 30+ 个用例，每个用例对应一个真实的 TPerf 压测记录。每个用例支持 多模型对比评测 （7 个模型，每个用例 × 每个模型生成独立的参数化测试）。

用例场景覆盖：

场景分组	用例数	典型场景
CPU 瓶颈	6	中断绑核异常（单核/双核/多核高负载）、RSS 哈希配置异常、大象流
网卡瓶颈	5	RSS 队列收包不均（CPU 高/低负载）、大象流、网卡硬件丢包
磁盘瓶颈	4	磁盘繁忙 IO Util > 80%（CPU 高/低负载）、await > 10ms
磁盘 IO	2	磁盘 IO 高负载 + iowait 高（单核/多核）
内存	1	内存占用率 > 85%
TCP 队列	3	Accept 队列溢出、CPU 高负载导致 accept 不及时
Nginx	1	Nginx 代码问题导致核间不均衡
配置问题	1	压测配置问题导致压力不足
正常场景	5	全核高负载但无异常、RSS 均衡、无丢包、内存正常等

用例定义示例：

每个用例包含以下信息：

• 用例名称和描述 ：标识场景和预期异常

• 压测记录 ID ：对应真实的 TPerf 压测数据

• 触发提示词 ：发送给 Agent 的分析指令

• 基线会话标识 ：指向人工确认正确的一次分析结果（session_id + message_id）

task_group: test_cpu task_group_alias:测试CPU相关指标异常情况下的分析 tasks: -task_name:test_cpu_nic_queue_interrupt_bindcore_error_single_core_high_load task_desc:CPU瓶颈-网卡队列中断绑核配置异常-单核高负载、si占用高、RSS队列收包均衡 tperf_test_record_id:'1258797' prompt:分析用例{tperf_test_record_id} base_line_trial: message_id:'269806ca2dd04e259b042345cf7fc313' session_id:'66254b2c49794713b02cbecd425ebf09'

说明 ：用例中不硬编码任何预期输出，而是通过基线会话标识指向一次人工确认正确的 Agent 分析记录，评分时从 Knot API 动态获取基线数据作为参照。模型列表、超时、回归次数等参数由全局配置统一管理。

5.3 基线管理

评分标准和用例集确定后，还需要为每个用例建立"正确答案"——即基线。按照第三章 3.3 的通用基线方法，TPerf 的具体实现如下。由于 TPerf AI 分析 Agent 部署在 Knot 平台上，基线以 Knot 会话标识的形式保存，评测时通过 API 动态获取完整数据。

基线建立流程

基线建立核心步骤：

1. 触发分析 ：向 Knot Agent 发送"分析用例{记录ID}"，触发一次完整分析

2. 获取标识 ：记录本次分析的 session_id 和 message_id

3. 人工审核 ：在流水线平台查看分析报告，确认步骤&结论正确、建议合理

4. 记录基线 ：将确认通过的会话标识写入用例配置

5. 运行时获取 ：评测执行时通过 Knot API 实时获取基线的完整数据（报告、步骤、耗时、token）

基线快照内容

评测执行时从 Knot API 动态采集基线数据，包含：

类别	内容
分析报告	完整的 Markdown 格式性能分析报告
操作步骤	工具调用流程（工具名 + 简化参数 + 调用顺序）
执行耗时	基线执行总耗时（秒）
Token 消耗	输入/输出/总 token 数

基线数据运行时从 API 动态获取，确保始终对应真实的 Agent 执行结果。采集后落盘保存供后续对比使用。

基线更新与用例维护

在第三章 3.3 通用基线更新时机（Agent 逻辑变更/模型升级/用例修改）的基础上，TPerf 细化为以下具体场景：

场景	操作
Agent 逻辑变更	重新执行 1 次，人工确认后更新基线会话标识
Agent 外部依赖变更	重新执行 1 次并确认新基线
模型版本升级	重新执行 1 次并确认新基线
新增 Agent 用例	针对新增用例，执行 1 次确认后记录基线
新增 Bad Case	获取压测记录 ID，执行 1 次确认后记录基线，纳入对应场景分组
新增分析能力	新建对应场景的用例分组，新增覆盖用例

5.4 测评执行

评分标准、用例集、基线三件套就绪后，进入实际执行阶段。TPerf 的测评执行充分利用了 并发能力 ——多个 Trial 并行触发 Agent、Trial 评分并行、三个评分器并行打分——以在可接受的时间内完成大规模多模型对比测评。

执行流程

单用例执行流程：

单个 Trial 执行流程：

评分机制

操作步骤评分 — 确定性评分，最多扣 10 分：

使用最长公共子序列（LCS）算法对齐基线与 Trial 的操作步骤序列。对齐前会对步骤进行归一化处理：时间戳替换为占位符、搜索工具忽略查询参数、写入工具忽略文件内容只保留路径、终端命令提取脚本名忽略环境配置、连续读文件操作组内不校验顺序。对齐后，步骤不一致/多余/缺少/顺序错误各扣 2 分。

效率评分 — 确定性评分，最多扣 10 分：

耗时以全局配置的基准时间（300s）为参照，每超标 10% 扣 1 分；Token 消耗以基线 Token 数为参照，每超标 10% 扣 1 分。两项合计最多扣 10 分。

报告评分 — 模型评分，最多扣 80 分：

将基线报告和 Trial 报告写入文件，生成评分 Prompt，调用 CodeBuddy CLI 让大模型逐项对比两份报告。评分完成后校验结果格式合法性。关键判定（压测有效性/性能结果）不一致直接扣 80 分；章节内容（CPU/内存/网络/磁盘IO/业务指标/根因/优化建议/完整性/准确性/结论）每项差异扣 5 分，上限 80 分。

执行模式

模式	说明	适用场景
快速分析	每用例跑 1 轮，生成可视化报告	日常开发调试、确定基线
全量测评	每用例跑 5 轮 × 7 模型，评估稳定性	版本验收、模型对比
按模型筛选	只运行指定模型的用例	单模型验证
重新评分	对已有执行结果重新评分	评分逻辑调整后无需重新触发 Agent

触发时机

在通用触发时机（见第三章 3.4）基础上，TPerf 增加了工具更新的触发条件：

场景	触发方式	说明
TPerf AI 分析 Agent 提示词变更	CI 流水线自动触发	PR 合入前回归验证
TPerf 分析相关工具更新	CI 流水线自动触发	验证工具变更未破坏分析能力
模型版本升级	手动触发	验证新模型兼容性
定期巡检	定时触发	周期性全量回归

5.5 工程实现

前面介绍了"评什么"和"怎么跑"，本节展开工程实现细节——Trace 如何获取、项目如何组织、流水线如何集成。

Trace 获取

TPerf AI 分析 Agent 部署在 Knot 智能体平台 上，通过 Knot 的 AG-UI 协议进行交互。

采用 Knot API 查询 方式：触发 Agent 分析后，通过轮询等待数据库同步完成，然后获取完整的 AG-UI 事件流。该事件流包含：

• 工具调用事件 ：记录每次工具调用的名称、参数和返回结果

• 文本消息事件 ：Agent 生成的 Markdown 分析报告（分段拼接）

• 时间和消耗 ：请求时间、完成时间（计算耗时）、Token 消耗明细

• 最终分析报告 ：从文本事件拼接后，以"性能用例分析报告"标记截取

事件流解析器跟踪工具调用的开始→参数→结果事件，构建完整的调用步骤列表。对参数进行简化处理（终端命令提取关键信息、读文件提取路径、MCP 工具提取核心参数、写入类工具截断内容），使步骤对比更加合理。

框架结构

测试场景基于 真实的 TPerf 压测记录 ，不使用 mock 数据。压测记录一旦生成即不可变，确保用例 可复现 。

项目按职责分层组织：

层级	说明
API 封装层	封装 Knot 智能体 API 和 TPerf 平台 API
配置层	全局配置（模型/超时/评分标准）、凭证配置、模型定价配置
用例定义层	按场景分组的 YAML 用例文件（9 个分组）
采集层	基线数据采集器：从 Knot API 获取基线的报告、步骤、耗时、Token
评分层	三个独立评分器：操作步骤评分、效率评分、报告评分
执行层	用例执行器（触发 Agent、收集结果、编排评分流程）
工具层	快速评测脚本、报告生成器、重新评分工具、基线同步工具
解析层	AG-UI 事件流解析器（将原始事件流转换为结构化的工具调用步骤列表）
结果层	基线落盘、评分结果、中间文件、HTML 报告

框架启动时递归扫描所有用例配置文件，结合全局模型列表，为每个用例 × 每个模型生成独立的参数化测试。支持通过 pytest marker 按模型筛选用例。

流水线集成与报告

根据执行模式的不同，分为两条流水线：

基线确认流水线

用于日常开发调试和快速验证，确定基线：

环节	说明
执行方式	指定用例 ID 列表 或 全量用例，支持指定并发数和模型
执行环境	Python 3.10+、Knot 凭证、网络可达 Knot API
报告格式	左右分栏：左侧用例列表（支持搜索/筛选）+ 右侧 Markdown 渲染
成本计算	根据模型定价配置计算每次分析的 token 费用

报告效果：

基线确认报告示例：左侧为用例列表（显示用例耗时/Token/费用明细/会话信息），支持搜索和折叠；右侧为选中用例的详情，包含用例基本信息、分析报告结果。

测评流水线

基线确认后进入正式测评环节，采用 pytest 实现全部测评逻辑，用例管理复用 TCase 平台 ：

环节	说明
用例管理	用例上传至 TCase 平台，创建用例集和任务
并发策略	Trial 执行并发 + Trial 评分并行 + 三个评分器并行
重试机制	遇限流/模型异常自动等待重试（最多 5 次）；数据获取轮询等待同步
超时设置	单用例约 3000s；全量 30+ 用例 × 7 模型约 3-5 小时
报告展示	测试结束后自动生成 HTML 报告，在流水线中展示
过程归档	评分结果、基线数据、Agent 响应等过程文件归档至流水线产物

测评完成后自动生成 HTML 报告，全量测评报告包含：

• 顶部汇总 ：总用例数、通过/失败数、通过率、模型版本、执行时间

• 分组展示 ：按场景分组，每组显示用例列表

• 单用例详情 ：展开后显示每次 Trial 的三维度评分明细（步骤对比 + 耗时/Token 对比 + 报告对比 + 综合得分）

• 回归评分 ：显示稳定性达标情况和最终分数

• Knot 对话链接 ：每个 Trial 提供 Knot 平台对话历史的跳转链接

• 成本统计 ：显示每次评测的 token 消耗和费用

全量测评报告总览 ：顶部显示通过率、平均分、模型版本、总 Token、总费用等全局汇总指标；左侧按场景分组展示全部用例及得分和分数分布直方图，右侧展示该用例执行的详细信息。

单用例评分详情 ：展示该用例的基线信息（耗时/Token/费用/步骤数）、Prompt、多次 Trial 的逐项评分（Transcript 扣分、效率扣分、结果扣分）及最终稳定性评分。

Trial 对话详情 ：展示单次 Trial 的完整对话 ID、Token 消耗、费用、耗时，以及 Transcript 各维度评分的扣分明细和上限，支持跳转至 Knot 平台查看完整对话历史。

模型对比报告 ：横向对比多个模型在全量用例集上的综合表现，帮助团队做出模型选型决策。

模型	pass@1	pass^5	用例通过率（跑5次）	得分	Token 使用量/M	开销/$	耗时/s
model-A	9x.x%	9x.x%	9x.x%	9x.x	0.x	x.x	2xx
model-B	9x.x%	7x.x%	9x.x%	8x.x	0.x	x.x	2xx
model-C	9x.x%	7x.x%	8x.x%	7x.x	0.x	x.x	2xx
model-D	9x.x%	8x.x%	9x.x%	8x.x	0.x	x.x	2xx
model-E	4x.x%	x.x%	x.x%	x.x	0.x	x.x	2xx
model-F	6x.x%	1x.x%	2x.x%	2x.x	0.x	x.x	1xx

• pass@1 ：跑一次评分达标的概率

• pass^5 ：连续跑 5 次评分达标的概率

• 开销 = Token 使用量 × 模型单价（单价使用对外售卖价）

• 耗时 受模型部署资源影响

过程日志与归档

每次测评执行产生的所有中间数据和最终报告均按以下方式归档，确保可追溯：

内容	说明	归档方式
基线数据	从 API 采集的报告、步骤、耗时、token 完整数据	流水线产物
基线/Trial 报告	用于报告评分的 Markdown 文件	流水线产物
评分结果	各评分器的逐项对比详情和分数	流水线产物
用例综合评分	包含基线、所有 trial、回归评分和最终得分	流水线产物
HTML 测评报告	可视化报告	流水线展示
基线配置	用例中的基线会话标识	代码仓库（Git 追溯）
用例执行日志	TCase 管理的执行日志	TCase 平台查看

关键设计：

• 基线配置 随代码仓库版本化管理，变更可通过 Git 追溯

• 执行结果 每次执行重新生成，通过流水线归档保留

• 重新评分 ：可对已有结果重新评分，无需重新触发 Agent 执行