← 返回闯关手册

AI Agent & Skill 测评方案及落地实践

核心内容速览

• 框架总览：针对非确定性、黑盒化、错误级联放大三大难题，建立「确定性评分器 + Rubric 评分器 + 人工评分器」组合，覆盖功能正确性、过程质量、效率成本、鲁棒性安全、体验对齐五大维度。
• 工业级用例模板：正向 / 负向 / 异常容错用例 + 检查规则（file_exists、response_contains、response_not_contains 防幻觉防泄露），表格可直接套用。
• 稳定性量化与「0 容忍」：同一用例多次 Trial，任一 Trial 不达标即整体不通过（关键决策类）；辅助分析类可放宽至容忍 ≤10%，并给出综合评分公式与示例。
• LLM 一致性评判工程化：数值型精确匹配（小数允许 ≤1% 相对误差）、结论型对齐异常等级、建议型抓核心排查方向——把「大模型当评委」变成可审计的规则。
• 工程闭环：测评接入 CI 自动跑批与报告，附完整术语表（pass@k / pass^k、Prompt Injection、Ground Truth 等）。

适合谁 · 怎么用

已过「要不要做测评」阶段、正在搭建或升级 Agent 测评体系的工程与测试团队，这篇是直接的参照系；它把 a04（Grader 分工）、a05（Agent Eval 概念）落到了代码级。建议精读第五章 TPerf 实战案例。

闯关自测

先合上原文在心里作答，再点开对照。全对 = 本篇真正通关。

Q1　腾讯的三类评分器分别管什么？

确定性评分器管可程序化验证的规则（文件存在、格式合规、敏感信息不出现）；Rubric 评分器管开放性质量；人工评分器管争议仲裁与抽检兜底。

Q2　「0 容忍」稳定性策略是什么意思、何时放宽？

同一用例跑多次 Trial，任一 Trial 不达标即判该用例不通过——适用于结论直接影响决策的关键场景；纯辅助分析类场景可放宽到容忍 ≤10% 的波动，按风险等级选择。

Q3　负向用例主要防什么？

防幻觉（不编造不存在的指标）与防泄露（不输出 api_key 等敏感信息），用 response_not_contains 等确定性规则验证，而不是靠观感。

以下为原文全文

上方为本站原创导读，下方为原文完整收录，便于对照阅读。

作者：martinskxu

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

一、背景：为什么要做测评？

1.1 痛点

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

1. 非确定性：同一 prompt 多次执行结果不同，"跑通一次"不代表"稳定能跑"。
2. 黑盒化：模型升级、Prompt 微调、工具链变化都可能导致行为漂移，肉眼难以察觉。
3. 错误级联放大：一次任务涉及几十步工具调用，前序步骤的一个小偏差会沿链路逐级放大，最终导致结论完全偏离。

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

痛点	后果
主观性强	依赖"感觉变好了"的直觉判断，缺乏量化依据，团队无法基于数据做科学决策
悄悄退化	改了 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 消耗是否在阈值内	效率/成本验证
基线对比	将本次执行的过程和结果与基线快照逐项对比（详见第三章）	回归验证

用例中的确定性规则示例：

expectedbehavior: # 过程检查：是否调用了指定工具 -toolcall:"mcp" contains:"tperf-mcp" # 结果检查：产物是否存在 -fileexists: -"cpu.json" -"nic.json" # 结果检查：响应内容是否包含关键信息 -responsecontains: -"测试有效" -"出现CPU瓶颈" -"业务QPS平稳" # 效率检查：工具调用次数上限 -maxtoolcalls:10

Rubric 评分器（模型评分）

灵活、可扩展，负责"代码搞不定但能结构化描述"的场景（如输出的内容包含自然语言）：

评分器类型	说明	适用场景

LLM 评判

让另一个 LLM 按评分标准判断表现

回答质量、语气、规范遵循度

用例中的 Rubric 规则示例：

rubric: observationpoints: -回答是否基于项目规范/知识库而非通用知识 -推理过程是否清晰连贯 -是否存在幻觉或编造内容 scoring: processscore:0-100 # 过程分 resultscore:0-100 # 结果分 isfalse_positive:bool # 是否虚假成功（结果对但过程错）

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

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

1. 校准 LLM 评委（最核心用途）——抽样 100–200 条，和 LLM 打分对齐，一致率 ≥ 85% 才算可用。
2. 主观任务打分——回复同理心、报告论证严谨度。
3. 诊断通过率异常——0% 或 100% 通常是"任务/评分器坏了"，不是模型弱。
4. 建立 Ground Truth（黄金标准答案）——新套件上线的前 20–50 个参考解。
5. Trace 采样审查——每周固定抽样读轨迹，找隐藏失败模式。
6. 高风险兜底——医疗/金融/安全场景 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 评分器（判断回答质量、检测幻觉）
• 代码编写更依赖 确定性评分器（编译是否通过、测试是否跑过）
• 功能工具更关注 过程对比（工具调用序列是否与基线一致）
• 问题定位则需要 过程 + 结果双重验证（推理链路正确且结论准确）

三、测评实施：怎么做？

第二章回答了"谁来评"和"评什么"的理论问题，本章进入实操层面——从设计用例、制定评分规则、建立基线，到执行测评、维护用例集，形成一个完整的实施闭环。每一步都给出具体的模板和示例，确保读者可以直接复用到自己的 Agent 项目中。

3.1 设计测评用例集

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

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

场景	关注点	正向用例	负向用例
触发	Skill 是否在正确场景被激活	各种合法表述都能触发	相似但不相关的 prompt 不误触发
核心逻辑	执行过程是否按预期步骤进行	工具调用序列、参数、顺序正确	缺少关键步骤、调用错误工具、参数错误
产物质量	最终产物是否完整、准确、可用	响应内容准确、文件完整、格式正确	内容缺失、格式错误、幻觉/编造
异常容错	异常输入/环境下能否合理处理	优雅降级、明确提示	崩溃、死循环、静默失败、泄露信息

场景一：触发条件用例

验证 Skill 是否在正确的场景被触发/不被触发。

用例 ID	类型	Prompt 示例	预期行为	设计意图
trigger-pos-01	正向	"分析用例134263"	skill_triggered	标准表述
trigger-pos-02	正向	"帮我看看用例134263的性能数据"	skill_triggered	口语化表述
trigger-neg-01	负向	"CPU高负载应该如何排查？"	skillnottriggered	通用问答，非分析任务
trigger-neg-02	负向	"用例134263是谁创建的？"	skillnottriggered	涉及用例但非性能分析

为什么需要负向触发用例？ 只测正例，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 + responsecontains + responseformat_check	产物文件存在、关键结论完整、包含结构化内容
output-pos-02	正向	"分析用例1434534，输出JSON格式报告"	filevalidjson + filejsonhas_keys	格式合规、必填字段齐全
output-neg-01	负向	"分析用例1434534"	responsenotcontains: "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	标准请求 + mocktoolfailure	优雅降级提示，不无限重试	工具故障兜底

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 是最有价值的测评素材：

1. 复现 Bad Case，记录完整轨迹
2. 分析根因，确定预期行为
3. 修复 Agent/Skill
4. 将 Bad Case 纳入用例集，防止下次回归出现一样的问题
5. 该 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":"toolcall","name":"readfile","params":{"path":"src/main.ts"},"timestamp":"2026-04-26T10:00:01Z"} {"type":"toolresult","name":"readfile","result":"...","timestamp":"2026-04-26T10:00:02Z"} {"type":"thinking","content":"文件结构清晰，需要修改 handleRequest 函数...","timestamp":"2026-04-26T10:00:03Z"} {"type":"toolcall","name":"editfile","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、费用、耗时
• 步骤评分明细（各维度扣分及上限）

五、实战案例：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: trialscore = max(0, 100 + 步骤扣分 + 效率扣分 + 报告扣分) 达标判定: trialpass = (trialscore ≥ T)，T = 80 用例总分: casescore = avg(所有 trialscore) 若全部 trialpass = 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 的分析指令
• 基线会话标识：指向人工确认正确的一次分析结果（sessionid + messageid）

taskgroup: testcpu taskgroupalias:测试CPU相关指标异常情况下的分析 tasks: -taskname:testcpunicqueueinterruptbindcoreerrorsinglecorehighload taskdesc:CPU瓶颈-网卡队列中断绑核配置异常-单核高负载、si占用高、RSS队列收包均衡 tperftestrecordid:'1258797' prompt:分析用例{tperftestrecordid} baselinetrial: messageid:'269806ca2dd04e259b042345cf7fc313' sessionid:'66254b2c49794713b02cbecd425ebf09'

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

5.3 基线管理

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

基线建立流程

基线建立核心步骤：

1. 触发分析：向 Knot Agent 发送"分析用例{记录ID}"，触发一次完整分析
2. 获取标识：记录本次分析的 sessionid 和 messageid
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 按模型筛选用例。

流水线集成与报告

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

基线确认流水线

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