Agent 评测方法论

概述

Agent 评测是 Agent 工程中最被低估的环节。没有系统化的评测，你无法区分"感觉变好了"和"确实变好了"。Agent 的非确定性本质意味着单次测试毫无意义——你需要统计显著的、多维度的、可重复的评测体系。

本指南涵盖评测的核心挑战、多维评分量表、LLM-as-Judge 方法论、偏差缓解技术、测试集设计以及持续评测工作流。

何时使用

• 创建新 Agent 后需要验证质量
• 修改 Agent 提示词后需要回归测试
• 比较两个提示变体的效果
• 建立 Agent 质量的持续监控体系
• 排查 Agent 输出质量下降的原因

核心挑战

Agent 评测与传统软件测试有根本性差异：

1. 非确定性

同一输入可能产生不同输出，且多个不同输出都可能是"正确"的。

输入："优化这个函数的性能"

输出 A：使用缓存策略 → 合理 ✓
输出 B：使用算法优化 → 合理 ✓
输出 C：使用并行计算 → 合理 ✓

传统测试思维：只有一个"正确答案"
Agent 测试思维：多个有效路径，需要评估每个路径的质量

2. 多有效路径

不同的执行策略可能都达到目标，但在效率、可维护性、安全性等维度上各有优劣。

3. 复合质量维度

Agent 输出的"好坏"不是一维的。一个回答可能在准确性上完美，但在可读性上糟糕；可能在深度上优秀，但在效率上低下。

多维评分量表

五维评分体系

综合得分计算

综合得分 = Σ(维度得分 × 权重)

示例：
指令遵循：4/5 × 0.30 = 1.20
输出完整性：3/5 × 0.25 = 0.75
工具效率：5/5 × 0.20 = 1.00
推理质量：4/5 × 0.15 = 0.60
响应连贯性：4/5 × 0.10 = 0.40

综合得分 = 3.95 / 5.00 = 79%

单维度评分量表示例（指令遵循）

权重调整指导

根据 Agent 的类型调整维度权重：

评测方法论：LLM-as-Judge

使用另一个 LLM（通常是更强的模型）来评估 Agent 的输出质量。

方法一：直接评分（Direct Scoring）

让 Judge 模型对 Agent 的输出按评分量表打分。

## 评分任务

请评估以下 Agent 输出的质量。

### 用户原始请求
{user_request}

### Agent 输出
{agent_output}

### 评分量表

对以下 5 个维度分别打分（1-5 分）：

1. **指令遵循**：Agent 是否准确执行了用户的请求？
   - 5 分：完全按指令执行，无遗漏
   - 3 分：大致方向正确，有明显遗漏
   - 1 分：完全忽略或误解指令

2. **输出完整性**：[量表定义...]
3. **工具效率**：[量表定义...]
4. **推理质量**：[量表定义...]
5. **响应连贯性**：[量表定义...]

### 输出格式

```json
{
  "instruction_following": { "score": N, "justification": "..." },
  "completeness": { "score": N, "justification": "..." },
  "tool_efficiency": { "score": N, "justification": "..." },
  "reasoning_quality": { "score": N, "justification": "..." },
  "coherence": { "score": N, "justification": "..." },
  "overall_score": N.NN,
  "summary": "一句话总结"
}

优点： 实现简单、可自动化、可与历史数据对比

缺点： 对量表定义的质量高度敏感、绝对分数跨任务不可比

方法二：配对比较（Pairwise Comparison）

让 Judge 对比两个 Agent 输出（或同一 Agent 的两个版本），判断哪个更好。

## 配对比较任务

以下是同一用户请求的两个 Agent 回答。请判断哪个更好。

### 用户请求
{user_request}

### 回答 A
{output_a}

### 回答 B
{output_b}

### 评比维度
对以下每个维度，判断 A 更好、B 更好、还是平局：

1. 指令遵循
2. 输出完整性
3. 工具效率
4. 推理质量
5. 响应连贯性

### 输出格式

```json
{
  "dimensions": {
    "instruction_following": { "winner": "A/B/tie", "reason": "..." },
    "completeness": { "winner": "A/B/tie", "reason": "..." },
    ...
  },
  "overall_winner": "A/B/tie",
  "confidence": "high/medium/low",
  "key_differentiator": "决定胜负的关键因素"
}

优点： 更符合人类判断习惯、对量表定义不太敏感、结果更稳定

缺点： 只能比较相对优劣、无法给出绝对分数、需要成对生成

关键技巧： 为消除位置偏差，每次对比需要运行两次，交换 A 和 B 的顺序。只有两次结果一致时才计入有效判定。

偏差缓解

LLM-as-Judge 存在多种系统性偏差，必须在评测设计中主动缓解：

1. 位置偏差（Position Bias）

表现： Judge 倾向于给排在前面（或后面）的回答更高分。

缓解方法：

• 配对比较时交换 A/B 顺序运行两次
• 只有两次结果一致的判定才有效
• 不一致时标记为"需人工审核"

2. 长度偏差（Verbosity Bias）

表现： Judge 倾向于给更长的回答更高分，即使更短的回答质量更好。

缓解方法：

• 在评分标准中明确"简洁性是加分项，冗余是扣分项"
• 增加独立的"效率"维度
• 在量表中给出"过于冗长"的负面示例

3. 自我增强偏差（Self-Enhancement Bias）

表现： 使用同一模型做 Judge 时，倾向于给与自己风格相似的输出更高分。

缓解方法：

• Judge 模型与被评测 Agent 使用不同模型
• 如果必须用同一模型，增加多次采样取平均值
• 引入人工评测作为校准锚点

4. 详细偏差（Detail Bias）

表现： Judge 倾向于给包含更多技术细节的回答更高分，即使这些细节与任务无关。

缓解方法：

• 在评分标准中加入"相关性"维度
• 明确"与任务无关的细节是扣分项"

5. 权威偏差（Authority Bias）

表现： Judge 倾向于给使用更多专业术语或引用的回答更高分。

缓解方法：

• 评分标准聚焦"是否解决了用户问题"而非"看起来是否专业"
• 加入"可操作性"维度——用户能否直接按建议执行

测试集设计

复杂度分层

将测试用例按复杂度分层，确保每层都有足够的覆盖：

代表性采样原则

• 场景覆盖：确保每个 Agent 声称支持的场景都有测试用例
• 输入多样性：包含不同编程语言、框架、项目规模的用例
• 边缘情况：包含模糊指令、不完整信息、矛盾需求的用例
• 基线用例：包含已知正确答案的用例，用于校准评分

测试集规模指导

评分量表生成

为每个评测维度生成精确的评分量表是评测质量的关键。

量表设计流程

1. 定义维度名称和权重
2. 编写各级别的文字描述
3. 为每个级别编写 2-3 个具体示例
4. 标注边缘情况的处理方式
5. 让 2-3 人独立使用量表评分同一样本
6. 计算评分者间一致性（Cohen's κ）
7. 根据不一致点修订量表定义

量表模板

## 维度：[维度名称]

**定义**：[一句话定义该维度衡量的内容]

**权重**：[0.00 - 1.00]

| 分值 | 级别 | 描述 | 典型特征 | 示例 | 边缘处理 |
|------|------|------|----------|------|----------|
| 5 | 卓越 | [描述] | [特征] | [示例] | [边缘] |
| 4 | 良好 | [描述] | [特征] | [示例] | [边缘] |
| 3 | 可接受 | [描述] | [特征] | [示例] | [边缘] |
| 2 | 不足 | [描述] | [特征] | [示例] | [边缘] |
| 1 | 失败 | [描述] | [特征] | [示例] | [边缘] |

评测工作流

工作流 1：测试新 Agent

新建 Agent
  ↓
准备测试集（L1-L4 各层级）
  ↓
运行 Agent 处理全部测试用例（每个用例运行 3 次）
  ↓
LLM-as-Judge 对每次输出评分
  ↓
统计各维度平均分和标准差
  ↓
标准差 > 1.0 的维度 → 提示词需要加强约束
平均分 < 3.0 的维度 → 提示词需要重写该部分
全维度 > 4.0 → 通过，可以部署

工作流 2：比较提示变体（A/B Test）

原始提示（A）和改进提示（B）
  ↓
使用相同测试集运行两个版本
  ↓
配对比较（Position-swapped）
  ↓
统计各维度的胜/负/平比例
  ↓
对整体胜率做显著性检验（Fisher's Exact Test）
  ↓
p < 0.05 → 差异显著，采纳胜出版本
p >= 0.05 → 差异不显著，需要更多样本或更大改动

工作流 3：回归测试

修改 Agent 的提示词或工具配置
  ↓
运行"回归测试集"（20-30 个历史上稳定通过的用例）
  ↓
与上一版本的评分对比
  ↓
任何维度下降 > 0.5 分 → 回归，需要修复
所有维度波动 < 0.3 分 → 无回归，可以合并

工作流 4：持续质量监控

每周从生产日志中采样 10-20 个真实交互
  ↓
LLM-as-Judge 自动评分
  ↓
生成周报：各维度趋势图
  ↓
任何维度连续 2 周下降 → 触发调查

评测指标参考

核心指标

一致性指标

指标解读

Cohen's κ 解读：
  0.81 - 1.00  几乎完美一致
  0.61 - 0.80  高度一致
  0.41 - 0.60  中等一致
  0.21 - 0.40  一般一致
  0.00 - 0.20  轻微一致
  < 0.00       低于随机一致

κ < 0.60 意味着评分量表需要修订——
要么定义不够清晰，要么维度本身不够可判定。

反模式

1. 单次测试下结论

# 反模式
运行 Agent 1 次 → 看结果 → "效果不错，上线"

# 正确做法
运行 Agent 30+ 次 → 统计平均分和标准差 → 显著性检验 → 决策

问题： Agent 输出是非确定性的，单次结果的方差极大，无法代表整体质量。

2. 只看整体分数

# 反模式
"综合得分 4.2，不错！"

# 正确做法
"指令遵循 4.8，但工具效率只有 2.5——Agent 在频繁做不必要的文件读取"

问题： 综合分数掩盖了维度间的差异。一个 Agent 可能在 4 个维度上满分，但在 1 个关键维度上完全失败。

3. 用自己做 Judge

# 反模式
自己写的 Agent → 自己评判质量 → "确认偏差"导致高估

# 正确做法
让不了解 Agent 设计细节的人来评测，或使用 LLM-as-Judge 做盲评

4. 测试集不更新

# 反模式
创建一次测试集 → 用同一个测试集评测所有版本 → Agent "过拟合"测试集

# 正确做法
每次迭代补充 10-20% 的新用例，淘汰过时的旧用例

5. 忽略偏差控制

# 反模式
配对比较时 A 总在 B 前面 → 位置偏差导致 A 系统性偏高

# 正确做法
每次比较双向运行，只取一致结果

6. 评分量表定义模糊

# 反模式
"3 分 = 一般"——什么是"一般"？

# 正确做法
"3 分 = Agent 完成了主要任务，但遗漏了 1-2 个次要需求，
例如：完成了功能实现但忘记添加错误处理"

总结

Agent 评测的核心原则：

1. 统计思维 — 单次结果无意义，需要足够的样本量和显著性检验
2. 多维度评估 — 综合分数掩盖问题，逐维度分析才能定位瓶颈
3. 偏差意识 — 每种评测方法都有系统性偏差，必须主动缓解
4. 持续迭代 — 评测不是一次性的，需要随 Agent 演进持续更新
5. 量表即文档 — 精确的评分量表是团队对"什么是好输出"的共识文档
6. 数据驱动 — 用评测数据指导提示优化，而非凭感觉调整