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

作者：martinskxu

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

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

1.1 痛点

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

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

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

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

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

1.2 核心理念

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

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

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

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

二、测评框架：谁来评？评什么？

**由谁（什么工具/角色）来打分？**用哪些维度衡量 Agent 的表现？ 这构成了整个测评方案的理论基础。我们参考了 OpenAI 和 Anthropic 的实践经验，从中提炼出关键启示，后续的用例设计与评分器实现均建立在此基础之上。

2.1 三类评委：谁来打分？

Agent 的输出既有可程序化验证的硬指标（文件存在、调用正确），也有只能靠语义理解才能判断的软指标（推理合理性、建议质量）。单一评分手段无法兼顾两者，因此 Agent 测评没有"银弹评分器"，必须三类组合使用**：**

        ┌──────────────────────────────────┐
        │         确定性评分器               │
        │   （脚本 / 断言 / Lint / AST）     │
        │   快、便宜、客观、可复现            │
        │   ⇨ 负责所有"能用代码判断"的事       │
        └──────────────────────────────────┘
                        ↑
                        │ 日常主力
                        │
        ┌──────────────────────────────────┐
        │         模型评分器（Rubric）       │
        │   （LLM-as-Judge + Prompt + Schema）│
        │   灵活、可扩展、处理开放式输出       │
        │   ⇨ 负责"代码搞不定但能结构化描述"    │
        └──────────────────────────────────┘
                        ↑
                        │ 扩展能力
                        │
        ┌──────────────────────────────────┐
        │         人工评分器（专家）          │
        │   昂贵、慢、黄金标准                │
        │   ⇨ 负责"校准、诊断、兜底"          │
        └──────────────────────────────────┘
 

三类评委职责对照

选择优先级：确定性评分器 > Rubric 评分器 > 人工评分器——能用代码判断的绝不用模型，必要时用模型，人工用于校准。

确定性评分器

快速、客观、可复现，负责所有"能用代码判断"的事：

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

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

Rubric 评分器（模型评分）

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

用例中的 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 评委"和"诊断异常"上。

2.2 五个维度：评什么？

了解了"谁来评"之后，接下来明确"评什么"。我们将 Agent 的测评覆盖拆解为五个大类，从"做对了吗"到"好用吗"逐层递进：

┌─────────────────────────────────────────────────────┐
│  1. 功能正确性（Functional Correctness）—— 做对了吗  │
│  2. 过程质量（Process Quality）—— 过程合理吗         │
│  3. 效率与成本（Efficiency & Cost）—— 划算吗         │
│  4. 鲁棒性与安全（Robustness & Safety）—— 靠谱吗     │
│  5. 体验与对齐（Experience & Alignment）—— 好用吗    │
└─────────────────────────────────────────────────────┘
 

下表汇总了每个大类的子维度、主要由谁来评分、以及落地优先级：

术语说明：

• Rubric：评分量表/评分标准，这里特指"用结构化的评分提示词让另一个大模型充当评委打分"的方式。

• pass^k：k 次试验中每次都通过的概率，衡量稳定性；pass@k：k 次中至少 1 次通过的概率，衡量峰值能力。

P0 先落地、P2 按需补充——优先保证"做对了"和"靠谱"，再逐步覆盖过程、成本和体验。

下面逐一展开五个维度的子项、评测方法和典型指标。

大类 1：功能正确性（Functional Correctness）

回答的问题："这次任务到底做成了没？"

这一类是 P0，必须自动化、全覆盖。对应评分体系中"确定性评分器"的主战场。

大类 2：过程质量（Process Quality）

回答的问题："即便做对了，过程合理吗？"

这一类最能体现"智能"水平，但自动化难度高，是 Rubric 评委的主战场。

大类 3：效率与成本（Efficiency & Cost）

回答的问题："结果对了，但划得来吗？"

这是被很多团队忽视但极其重要的一类。一个 pass@1 高但 token 花 10 倍的方案，在生产上是不可接受的。建议每个任务都带上成本画像。

大类 4：鲁棒性与安全（Robustness & Safety）

回答的问题："它会不会在关键时刻翻车？"

这一类是 P0，尤其是涉及金融、医疗、企业数据的 Agent，必须前置。

pass^k 释义：k 次试验中每次都成功的概率，用于衡量一致性/稳定性。与之对应的 pass@k 是 k 次试验中至少 1 次成功的概率，用于衡量峰值能力。

大类 5：体验与对齐（Experience & Alignment）

回答的问题："用户愿意继续用它吗？"

这一类是 P2，但却是决定产品生死的。早期用 Rubric + 人工抽样，成熟后引入线上 A/B + 用户反馈闭环。

2.3 不同类型 Agent 的测评侧重

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

差异体现在"用什么评分器"和"检查什么"，而非流程本身。 例如：

• 知识库问答更依赖 Rubric 评分器（判断回答质量、检测幻觉）

• 代码编写更依赖 确定性评分器（编译是否通过、测试是否跑过）

• 功能工具更关注 过程对比（工具调用序列是否与基线一致）

• 问题定位则需要 过程 + 结果双重验证（推理链路正确且结论准确）

三、测评实施：怎么做？

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

3.1 设计测评用例集

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

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

场景一：触发条件用例

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

为什么需要负向触发用例？ 只测正例，Agent 可能学会"什么都触发"——过度触发比不触发更难发现。

场景二：核心逻辑用例

验证 Skill 触发后的执行过程是否按预期步骤进行——调用了哪些工具、顺序是否正确、参数是否合理。

⚠️ 这是用例量最大的场景。 需要根据 Skill 的实际业务逻辑，梳理出所有核心分支，逐一覆盖。理论上，Skill 内部的每一条核心分支路径都应该有对应的测评用例。

设计方法：三步法

第一步：梳理分支流程图 — 画出 Skill 的所有核心分支路径（如：单用例分析/多用例对比/各类结论分支/决策树分支等）。

第二步：每条分支至少 1 个用例 — 示例（以性能分析 Skill 为例）：

第三步：补充组合和边界 — 关注分支间组合（如多维度同时指定）、阈值边缘（如瓶颈临界值）、跨分支冲突（如对比用例指标类型不一致）。

经验法则：核心逻辑用例的数量通常是其他三类场景用例之和的 2–3 倍。如果一个 Skill 有 N 条核心分支路径，至少需要 N 个正向用例 + 关键分支的负向用例。分支过多时，优先覆盖高频分支和易出错分支。

场景三：产物质量用例

验证 Skill 的最终产物——响应内容、输出文件、报告等是否完整、准确、可用。

场景四：异常容错用例

验证 Skill 在异常输入、边界条件、环境故障下能否合理处理，而非崩溃或静默失败。

3.2 设计评分规则

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

评分规则

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

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

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

评分维度与计分项

评分输出

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

3.3 建立用例基线

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

什么是用例基线？

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

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

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

****基线建立流程

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

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

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

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

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

💡 完整的带细节流程图见第五章实战案例（5.3 节），展示了具体落地时每一步的详细操作。

基线在评分中的作用

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

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

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

基线更新时机

3.4 执行测评

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

用例集执行流程

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

触发时机

3.5 用例集维护

测评体系不是"搭完就完"的一次性工程。随着 Agent/Skill 能力迭代、线上 Bad Case 积累、模型版本升级，用例集需要持续演进。一个长期不更新的用例集要么覆盖不足（新能力没测到），要么过时失效（旧用例不再适用）。以下是维护的关键场景：

能力测评 vs 回归测评

测评的目标会随 Agent 生命周期变化，必须区分两种套件：

与传统的测试流程不同，能力测评是和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 的要求

示例：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 输出作为标准能力纳入，而非事后补救。这不仅服务于测评，也有利于线上问题排查和可观测性建设。

4.2 环境隔离

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

• Clone 仓库到临时目录

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

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

4.3 稳定性评估

通过多轮执行（N 次）检测 AI 的幻觉和非确定性。核心原则：只要 N 次中有 1 次不通过，就说明该用例存在稳定性风险，需根据 Agent 类型判断是否可接受。

不通过比例的容忍阈值取决于 Agent/Skill 的使用类型：

以下是 N=5 时不同执行结果的解读和对应行动：

调试技巧：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 将通用方案中的"任务结果"映射为"关键判定"（压测有效性 + 性能结果），将"过程"细化为"操作步骤"，将"产物质量"细化为"章节内容"逐项对比。

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

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

一致性判断标准：

• 数值型：整数精确匹配，小数允许相对误差 ≤ 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）：

用例集设计

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

用例场景覆盖：

用例定义示例：

每个用例包含以下信息：

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

• 压测记录 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 动态采集基线数据，包含：

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

基线更新与用例维护

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

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 分。

执行模式

触发时机

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

5.5 工程实现

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

Trace 获取

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

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

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

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

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

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

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

框架结构

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

项目按职责分层组织：

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

流水线集成与报告

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

基线确认流水线

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

报告效果：

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

测评流水线

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

过程日志与归档

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

关键设计：

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

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

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

六、参考文档

本文的方法论和实践经验参考了以下来自 OpenAI 和 Anthropic 的一手资料，推荐进一步阅读：

附录：术语速查表