一、是什么？
1.1 一句话定义
Agent 评测体系是一套标准化的质量度量方法论------它定义了"好的 Agent 长什么样"、"如何衡量好不好"、"如何持续变得更好"。
它不等于"跑一组 case 看结果"，而是一个包含评测集、评测维度、评分标准、自动化执行、结果分析的完整闭环系统。
1.2 为什么需要体系化评测？
Agent 区别于传统软件的核心在于：输出是非确定性的。同一个输入，不同时间、不同模型版本可能给出不同答案。这意味着：
- 单元测试不够用------你无法穷举所有输入输出对
- 人工抽检不够用------成本高、覆盖面窄、标准不一致
- "看起来还行"不够用------无法量化，无法对比，无法回归
你需要一套可度量、可自动化、可持续运行的评测体系。
1.3 四层金字塔模型
好的评测体系应该覆盖四个层次，从基础到深入：
| 层级 | 评什么 | 核心问题 | 典型方法 |
|---|---|---|---|
| L1 基础能力 | Agent 的通用底座能力 | 能不能用？ | 开源 Benchmark（SWE-bench、GAIA 等） |
| L2 业务能力 | 在具体场景下各项能力是否达标 | 做得对不对？ | 多维度 LLM-as-Judge + Ground Truth |
| L3 过程质量 | 推理过程是否规范、高效 | 做的方式对不对？ | Trace 链路分析、SOP 步骤覆盖率 |
| L4 业务价值 | 对真实业务指标的影响 | 做了有没有用？ | A/B 实验、用户满意度、业务指标回收 |
大多数团队只做了 L1（用通用 Benchmark 跑个分），少数做到 L2（有业务评测集），极少数能覆盖 L3 和 L4。一个好的评测体系至少要做到 L2 的体系化建设。
二、该如何实现？
2.1 第一步：设计评测维度
评测维度是评测体系的骨架。好的维度设计应满足：
- MECE 原则：互不重叠、完全覆盖
- 独立可评：每个维度可以独立打分，互不干扰
- 可操作性：扣分时能明确告诉开发者"哪里错了"
以下是适用于所有垂直领域 Agent 的通用评测维度框架：
| 维度 | 评什么 | 适用场景 |
|---|---|---|
| 意图识别 | Agent 是否正确理解了用户的问题，并选择了正确的处理路径 | 所有 Agent |
| 数据正确性 | Agent 引用的数据/事实是否准确，计算是否正确 | Data Agent、RAG Agent |
| 推理逻辑 | 分析过程是否合理，是否遵循了预设的分析框架/SOP | 分析类 Agent |
| 归因准确性 | 根因定位是否正确，是否映射到正确的问题分类 | 诊断类 Agent |
| 输出格式 | 输出结构是否符合预设模板，信息是否完整 | 所有 Agent |
| 建议质量 | 给出的建议是否与结论匹配、是否具体可执行 | 咨询/诊断类 Agent |
| 合规性 | 是否包含敏感信息、违禁内容、内部术语 | 面向外部用户的 Agent |
关键原则：维度框架通用，但每个维度内部的评分标准是领域特定的。
2.2 第二步：构建评测集
评测集是评测体系的燃料。好的评测集需要：
2.2.1 样本设计
评测样本 = 输入（用户 Query） + Ground Truth （预期答案/标注）+ 元数据（场景标签）
- 输入：尽可能使用真实用户 Query，而非人造样本
- Ground Truth：不必是完整的"标准答案"，而是关键判据字段------即足以判断对错的核心信息
- 元数据：场景分类（用于分层分析）、难度标签（用于难度分布控制）
2.2.2 覆盖策略
用场景 × 难度矩阵确保覆盖全面：
| 简单（常见 case） | 中等（边界 case） | 困难（极端 case） | |
|---|---|---|---|
| 场景 A | 3-5 条 | 2-3 条 | 1-2 条 |
| 场景 B | 3-5 条 | 2-3 条 | 1-2 条 |
| 场景 C | 3-5 条 | 2-3 条 | 1-2 条 |
| 异常场景 | 1-2 条 | 1-2 条 | 1-2 条 |
总量建议：50-200 条足以覆盖核心场景，太少无统计意义，太多标注成本过高。
2.2.3 Ground Truth 标注原则
- 只标必要字段：不需要标注完整的"标准答案"，只需标注每个评测维度的判据
- 标注一致性：制定标注规范文档，多人标注时用 Cohen's Kappa 衡量一致性
- 持续迭代：线上 Bad Case 定期回流补充评测集
2.3 第三步：实现评分机制
LLM-as-Judge 模式
用大模型作为裁判，对每个维度独立打分。每个评测维度实现为一个独立的 Prompt：
评测 Prompt = 角色定义 + 评测目标 + 评分标准（例如：1-5分） + Ground Truth+ Agent输出 + 结构化输出格式
设计要点：
- 评分标准必须具体：每个分数档位给出明确的判定条件，不能含糊
- 结构化输出：要求裁判输出 JSON，包含分数、理由、关键错误标记
- 关键错误（is_critical）标记：区分"瑕疵"和"致命错误"，便于优先排序
- 加权汇总：各维度按业务重要性赋权，计算加权总分
评分校准
- 在正式评测前，先用 20-30 条样本做人机对照：人工打分 vs LLM 打分，校准 Prompt
- 如果某个维度的人机一致率 < 80%，需要优化该维度的评测 Prompt
- 定期用新样本复核，防止评分漂移
2.4 第四步：自动化执行
批量评测管线
数据源 → 并发调用 Agent → 收集输出 → LLM-as-Judge 评分 → 汇总分析 →生成报告
工程要点：
- 并发执行：评测集规模大时需并发调用 Agent，控制好并发度和超时
- 断点续跑：跳过已完成的样本，支持中断后继续
- 容错处理：单条失败不阻塞整体，标记 ERROR 后继续
- 结果持久化：评测结果存入数据库/表，支持历史查询和版本对比
触发机制
| 触发方式 | 适用场景 |
|---|---|
| 手动触发 | 开发阶段，修改 Prompt/工具后验证 |
| 定时任务 | 每日/每周跑一轮，监控模型漂移 |
| CI/CD 集成 | 代码合并前自动跑评测，作为质量门禁 |
2.5 第五步：结果分析与闭环
评测的价值不在于"跑出一个分数"，而在于驱动改进。
分析维度
- 整体趋势：总分随版本迭代的变化曲线
- 维度拆解：哪个维度拉分最多？哪个维度最不稳定？
- 场景分层：不同场景的表现差异，哪个场景是短板？
- Bad Case 聚类：critical error 的共性是什么？根因在哪里？
改进闭环
评测发现问题 → Bad Case 分析 → 定位根因 → 优化 Prompt/工具/SOP → 再次评测验证
三、价值是什么？
3.1 对开发者
| 价值 | 说明 |
|---|---|
| 量化质量 | 不再是"我觉得好了"，而是有明确的分数和通过率 |
| 精准定位 | 问题出在哪个场景、哪个维度，一目了然。不再是"这个case错了"，而是"数据引用维度的单位转换出了问题" |
| 回归保护 | 每次修改都能验证是否破坏了原有能力 |
| 迭代方向 | 明确的短板，知道该往哪里用力 |
3.2 对业务
| 价值 | 说明 |
|---|---|
| 上线信心 | 有数据支撑的质量结论，而非主观判断 |
| 效果证明 | 向业务方证明 Agent 能力的量化依据 |
| 持续进化 | 有机制保障能力持续迭代，而非一锤子买卖 |
3.3 对组织
| 价值 | 说明 |
|---|---|
| 标准统一 | 团队内统一的 Agent 质量语言，避免各说各话 |
| 知识沉淀 | 评测集、SOP、评分标准都是可沉淀的组织资产 |
| 能力输出 | 一套体系可复制到多个 Agent 项目，降低试错成本 |
四、可复用性体现在哪里？
4.1 分层架构：通用框架 + 领域配置
好的评测体系的可复用性来自于分层设计：
┌─────────────────────────────────────────────────────────────┐
│ 认知与方法论层（顶层复用） │
│ 7大评测维度框架｜评测集设计原则｜评分校准方法论｜质量定义标准 │
└───────────────────────┬─────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ 通用框架层（工程完全复用） │
│ 评测引擎｜LLM-as-Judge 评分框架｜批量执行｜断点续跑｜结果分析 │
└───────────────────────┬─────────────────────────────────────┘
↓
│ 领域配置层（插拔式适配） │
│ 业务SOP定义｜评分细则｜Prompt模板｜场景规则｜GT字段映射 │
└───────────────────────┬─────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ 评测数据层（业务独有） │
│ 真实用户样本｜场景Case集｜难度分层｜Ground Truth标注 │
└─────────────────────────────────────────────────────────────┘整个 Agent 评测体系采用三层解耦架构：
通用框架层：代码、引擎、评测方法论完全复用，不用重复开发；
领域配置层：以配置化、插拔式适配不同业务 Agent，无需改底层框架；
评测数据层：各业务独立沉淀样本、标注数据，持续迭代优化。
4.2 7 维度跨场景通用性
同一套维度框架，换一套领域知识就能适配不同 Agent：
| 评测维度 | 广告诊断 Agent | 客服 Agent |
|---|---|---|
| 意图识别 | 不起量/超成本 | 咨询/投诉/换货 |
| 数据正确性 | CPA/PCOC | 订单号/金额 |
| 推理逻辑 | 漏斗分析 SOP | 问题排查 |
| 归因准确性 | 10 个诊断 Case | 问题分类 |
| 输出格式 | 三段式报告 | 回复模板 |
| 建议质量 | 提价/优化素材 | 操作指引 |
| 合规性 | 禁止内部术语 | 禁止泄露隐私 |
4.3 可复用的不仅是代码，更是认知
真正的复用性体现在三个层次：
- 工程复用：批量执行引擎、LLM-as-Judge 框架、结果分析模块直接复用
- 方法论复用：7 维度框架、评测集设计原则、评分校准方法可直接迁移
- 认知复用：对"怎么定义好的 Agent"的理解，从一个场景积累的经验可以加速下一个场景的建设
总结：一个好的评测体系，代码是最容易复用的部分。更有价值的是维度设计的方法论和评分标准的设计经验------这些才是真正的、别人无法轻易复制的技术资产。