一、是什么？

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输出 + 结构化输出格式

设计要点：

1. 评分标准必须具体：每个分数档位给出明确的判定条件，不能含糊
2. 结构化输出：要求裁判输出 JSON，包含分数、理由、关键错误标记
3. 关键错误（is_critical）标记：区分“瑕疵”和“致命错误”，便于优先排序
4. 加权汇总：各维度按业务重要性赋权，计算加权总分

评分校准

• 在正式评测前，先用 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 可复用的不仅是代码，更是认知

真正的复用性体现在三个层次：

1. 工程复用：批量执行引擎、LLM-as-Judge 框架、结果分析模块直接复用
2. 方法论复用：7 维度框架、评测集设计原则、评分校准方法可直接迁移
3. 认知复用：对“怎么定义好的 Agent”的理解，从一个场景积累的经验可以加速下一个场景的建设

总结：一个好的评测体系，代码是最容易复用的部分。更有价值的是维度设计的方法论和评分标准的设计经验——这些才是真正的、别人无法轻易复制的技术资产。