Agent 评测：怎么衡量你训练出来的 Agent 到底行不行

Pass Rate (Pass@1)：每个任务只跑一次，成功就算 pass
→ 衡量的是"用户实际体验"——用户只会用一次，要么成功要么失败

Pass@k (k=5)：每个任务跑 5 次，至少一次成功就算 pass
→ 衡量的是"模型有没有这个能力"——能力有但不稳定也会被发现

实际意义：
Pass@1 = 60%，Pass@5 = 85%
→ 说明模型有能力完成 85% 的任务，但稳定性不够，只有 60% 能一次做对
→ RL 训练应该聚焦提升稳定性，而不是覆盖更多任务

鲁棒性测试示例——错误注入：

正常流程：
  User: 查北京天气 → Agent: get_weather(北京) → 返回：晴，25°C → Agent: 北京今天晴...

注入错误：
  User: 查北京天气 → Agent: get_weather(北京) → 返回：{"error": "API timeout"}
  
  好的 Agent：识别错误 → 重试一次 → 成功获取结果 → 回复
  差的 Agent：把错误信息当结果 → "北京今天 API timeout"
  更差的：陷入无限重试循环

必须满足：
├── 可复现    同一个模型跑两次，结果一致（或方差可控）
├── 隔离性    不同测试用例之间不互相影响
├── 可重置    每个用例执行前环境恢复到初始状态
├── 可观测    记录完整的执行轨迹，便于分析
└── 成本可控  评测不能比训练还贵

适用：工具调用有确定性输出的场景

做法：
├── 预先录制好每种工具调用的标准返回值
├── Agent 调工具时，匹配参数 → 返回预录结果
├── 最终结果用规则匹配判断（精确匹配 / 关键词包含 / 正则）
└── 快、便宜、可复现

局限：
├── 不支持探索性行为（Agent 走了一条没预录的路径就卡住了）
├── 无法测试错误恢复（预录数据里没有错误情况）
└── 结果判断的规则容易遗漏 edge case

适用：代码 Agent、数据库 Agent 等可以搭真实沙箱的场景

做法：
├── 为每个测试用例准备一个 Docker 容器 / 虚拟环境
├── Agent 在沙箱中真实执行操作
├── 用自动化测试验证结果（单元测试、SQL 查询验证等）
└── 最接近真实效果，结果最可靠

局限：
├── 搭建和维护成本高
├── 执行速度慢（每个用例可能要几分钟）
└── 沙箱环境和真实环境可能有差异

适用：结果无法用规则自动判断的场景（开放式回复、复杂分析等）

做法：
├── Agent 执行完毕后，把完整轨迹 + 最终结果提交给 Judge 模型
├── Judge 模型根据预定义的评分标准打分
├── 通常用比被评测模型更强的模型做 Judge（GPT-4、Claude 等）
└── 灵活，能处理开放式结果

局限：
├── Judge 模型本身有偏差（偏好更长的回复、偏好某种格式）
├── 评测成本 = Agent 执行成本 + Judge 模型调用成本
└── 不同 Judge 模型给出的评分可能不一致

推荐的混合方案：
├── 核心功能评测（占 60%）  → 沙箱环境 + 自动验证
│   确定性结果，最可靠
├── 开放式能力评测（占 25%）→ LLM-as-Judge
│   灵活处理开放式结果
└── 快速回归测试（占 15%）  → 静态数据集 + 规则
    跑得快，适合 CI/CD 集成

评测集构建原则：
├── 任务覆盖：每种支持的工具类型至少 20 条测试用例
├── 难度分布：简单 30% / 中等 50% / 困难 20%
├── 长度分布：1-3 步任务 / 4-8 步任务 / 8+ 步任务各占一定比例
├── 负面用例：包含"不需要调工具"和"应该拒绝"的场景
└── 独立性：评测集不能和训练集有重叠

你的 Agent 类型 → 优先用什么 Benchmark

代码 Agent     → SWE-bench（最权威）+ HumanEval（基础能力）
Web Agent      → WebArena
工具调用 Agent → ToolBench + 自建评测集（ToolBench 工具覆盖可能不够）
通用 Agent     → GAIA + AgentBench

模型 A：完成率 82%，平均 6 步完成
模型 B：完成率 85%，平均 14 步完成

如果只看完成率，会选 B。
但 B 的推理成本是 A 的 2 倍多，延迟也更高。
生产环境中 A 可能是更好的选择。

效率得分 = 完成率 × (基准步骤数 / 实际步骤数)

检查方法：
把评测集按难度分层，分别看每层的完成率

简单（1-3 步）：95%  ← 这个高不意外
中等（4-8 步）：65%  ← 这才是真实水平
困难（8+ 步）：30%  ← 复杂场景差很远

如果只看总体：78%（被简单任务拉高了）

评测环境 vs 生产环境的常见差异：
├── API 返回格式    评测环境统一 JSON，生产有 XML、纯文本、HTML 混杂
├── 延迟和超时      评测环境秒回，生产可能 10 秒超时
├── 错误率          评测环境 0% 错误，生产 5-15% 的调用会失败
├── 数据新鲜度      评测环境数据固定，生产数据实时变化
└── 并发和限流      评测环境无限流，生产有 QPS 限制

已知的 Judge 偏差：
├── 长度偏好    更长的回复倾向于得更高分
├── 格式偏好    有 markdown 格式的回复得分更高
├── 自我偏好    如果 Judge 是 GPT-4，它可能给 GPT-4 生成的内容更高分
└── 位置偏好    在 A/B 对比中，第一个选项可能被偏好

泄露场景：
├── 训练数据和评测数据都是 GPT-4 生成的 → 任务类型和表述风格相似
├── 训练数据从某个来源爬取，评测数据从同一来源的不同页面爬取
├── 评测集发布后被人放进了训练集（公开 Benchmark 的老问题）
└── 模型在 pretrain 阶段就见过评测数据（对公开 Benchmark 尤其严重）

检测方法：
├── 用模型没见过的全新任务测一次，对比分数差异
├── 检查评测集中的高分样本，和训练集做相似度比对
└── 定期更新评测集，只用新样本

阶段 1：训练中的快速评测（每 500-1000 步）
├── 用静态数据集跑 50-100 条核心任务
├── 看任务完成率和工具调用格式正确率
├── 同时跑通用 benchmark 的子集（MT-Bench 等）检测能力偏移
└── 目标：快速发现训练方向是否正确，10 分钟内出结果

阶段 2：checkpoint 评测（每个候选模型）
├── 沙箱环境跑完整评测集（300-500 条）
├── 计算全部四层指标（完成率 + 效率 + 鲁棒性 + 安全）
├── 分难度层级看完成率
├── 跑公开 Benchmark 对标业界水平
└── 目标：全面评估模型能力，几小时出结果

阶段 3：上线前灰度评测
├── 在生产环境的灰度流量上跑
├── 监控真实用户任务的完成率和用户反馈
├── 对比新模型和旧模型的 A/B 指标
├── 重点关注 edge case 和安全问题
└── 目标：验证评测结果是否和真实表现一致