--- layout: default title: Agent 评测：怎么衡量你训练出来的 Agent 到底行不行 description: Agent 评测的指标体系、评测环境搭建与常见评测陷阱 eyebrow: Agent 训练实战 / 05 --- # Agent 评测：怎么衡量你训练出来的 Agent 到底行不行 你训练了一个 Agent 模型，RL Reward 曲线看起来在涨，Loss 也在降——但它真的变强了吗？ Agent 评测和普通语言模型评测完全不是一回事。语言模型评测的是“输出的文本好不好”，Agent 评测的是“任务完成了没有、完成得高不高效、过程合不合理”。你不能只看最终输出，还要看执行轨迹；不能只在固定数据集上跑，还要在真实环境里测。 本篇讲 Agent 评测的指标体系、评测环境搭建，以及那些让你的评测结果“看起来好但实际不行”的常见陷阱。 ## 为什么 Agent 评测特别难 先说清楚为什么这件事难，理解了难点才能设计好评测方案。 **难点 1：结果正确不代表过程合理** 一个 Agent 查天气用了 3 次工具调用最终给出了正确答案，另一个 Agent 只用了 1 次。两个都“完成了任务”，但效率差 3 倍。如果你只看任务完成率，这两个 Agent 的评测分数一样。 **难点 2：同一个任务可以有多条正确路径** 让 Agent “帮我了解一下北京到上海的高铁信息”，它可以先查班次再查价格，也可以先查价格再查班次，也可以一次查询全部信息。没有唯一的标准答案，无法用简单的字符串匹配来评判。 **难点 3：环境不确定性** Agent 调用工具的返回结果可能随时间变化（API 数据更新）、随环境变化（沙箱状态不同）。今天跑通的测试用例，明天可能因为 API 返回变了就失败——但这不是模型的问题。 **难点 4：评测成本高** 每跑一个测试用例，Agent 要真的执行多步工具调用。一个 500 条的评测集，Agent 平均每条跑 8 步，就是 4000 次工具调用。如果工具涉及代码执行或 API 请求，评测一次可能要几个小时。 ## 指标体系：看什么数字 Agent 评测不能只看一个数字。你需要一套多维度的指标体系，从不同角度评估 Agent 的能力。 ### 第一层：任务完成指标 这是最基础的——Agent 到底有没有完成任务。 | 指标 | 定义 | 适用场景 | |---|---|---| | 任务完成率 (Pass Rate) | 完全正确完成的任务占比 | 所有场景 | | 部分完成率 (Partial Score) | 按任务子目标计分，完成一部分也有分 | 复杂多目标任务 | | Pass@k | 生成 k 条轨迹，至少一条成功的概率 | 评估模型的能力上限 | **Pass Rate vs Pass@k 的区别**： ```text Pass Rate (Pass@1)：每个任务只跑一次，成功就算 pass → 衡量的是"用户实际体验"——用户只会用一次，要么成功要么失败 Pass@k (k=5)：每个任务跑 5 次，至少一次成功就算 pass → 衡量的是"模型有没有这个能力"——能力有但不稳定也会被发现 实际意义： Pass@1 = 60%，Pass@5 = 85% → 说明模型有能力完成 85% 的任务，但稳定性不够，只有 60% 能一次做对 → RL 训练应该聚焦提升稳定性，而不是覆盖更多任务 ``` ### 第二层：效率指标 任务完成了，但完成得好不好？ | 指标 | 定义 | 为什么重要 | |---|---|---| | 平均步骤数 | 完成任务平均需要多少步工具调用 | 步骤多 = 延迟高 + 成本高 | | 冗余步骤率 | 对最终结果没有贡献的步骤占比 | 直接衡量无效操作 | | 首次成功率 | 第一次工具调用就成功（无需重试）的比例 | 衡量工具调用准确性 | | Token 消耗 | 完成任务消耗的总 token 数 | 直接影响推理成本 | 效率指标在企业场景中非常重要——每多一步工具调用就多一份延迟和成本。一个完成率 80% 但平均 5 步的 Agent，可能比完成率 85% 但平均 12 步的更适合生产环境。 ### 第三层：鲁棒性指标 正常情况下能跑通，异常情况呢？ | 指标 | 定义 | 测试方法 | |---|---|---| | 错误恢复率 | 工具报错后能正确恢复并最终完成任务的比例 | 注入工具错误（超时、参数错、空返回） | | 指令扰动稳定性 | 同一任务用不同措辞描述，完成率的方差 | 对每个任务准备 3-5 种不同表述 | | 上下文长度鲁棒性 | 轨迹变长后（8K/16K/32K）完成率的变化 | 测试不同长度的任务 | | 工具缺失处理 | 需要的工具不在 tool list 中时，能否合理拒绝 | 故意隐藏某些工具 | ```text 鲁棒性测试示例——错误注入： 正常流程： User: 查北京天气 → Agent: get_weather(北京) → 返回：晴，25°C → Agent: 北京今天晴... 注入错误： User: 查北京天气 → Agent: get_weather(北京) → 返回：{"error": "API timeout"} 好的 Agent：识别错误 → 重试一次 → 成功获取结果 → 回复 差的 Agent：把错误信息当结果 → "北京今天 API timeout" 更差的：陷入无限重试循环 ``` ### 第四层：安全指标 Agent 能执行操作，安全必须单独评测。 | 指标 | 定义 | 测试方法 | |---|---|---| | 危险操作拒绝率 | 收到危险指令时正确拒绝的比例 | 构造危险操作指令集 | | Prompt 注入抵抗率 | 工具返回中嵌入恶意指令时不执行的比例 | 在工具返回中注入攻击文本 | | 权限越界率 | 尝试调用没有权限的工具或访问越权数据的比例 | 设置权限边界后测试 | | 确认率 | 执行不可逆操作前主动确认的比例 | 给出删除文件、修改数据库等指令 | ## 评测环境搭建 有了指标，还需要一个靠谱的评测环境。 ### 评测环境的基本要求 ```text 必须满足： ├── 可复现 同一个模型跑两次，结果一致（或方差可控） ├── 隔离性 不同测试用例之间不互相影响 ├── 可重置 每个用例执行前环境恢复到初始状态 ├── 可观测 记录完整的执行轨迹，便于分析 └── 成本可控 评测不能比训练还贵 ``` ### 三种评测环境方案 **方案 1：静态数据集 + 规则判断** ```text 适用：工具调用有确定性输出的场景 做法： ├── 预先录制好每种工具调用的标准返回值 ├── Agent 调工具时，匹配参数 → 返回预录结果 ├── 最终结果用规则匹配判断（精确匹配 / 关键词包含 / 正则） └── 快、便宜、可复现 局限： ├── 不支持探索性行为（Agent 走了一条没预录的路径就卡住了） ├── 无法测试错误恢复（预录数据里没有错误情况） └── 结果判断的规则容易遗漏 edge case ``` **方案 2：沙箱环境 + 自动验证** ```text 适用：代码 Agent、数据库 Agent 等可以搭真实沙箱的场景 做法： ├── 为每个测试用例准备一个 Docker 容器 / 虚拟环境 ├── Agent 在沙箱中真实执行操作 ├── 用自动化测试验证结果（单元测试、SQL 查询验证等） └── 最接近真实效果，结果最可靠 局限： ├── 搭建和维护成本高 ├── 执行速度慢（每个用例可能要几分钟） └── 沙箱环境和真实环境可能有差异 ``` **方案 3：LLM-as-Judge** ```text 适用：结果无法用规则自动判断的场景（开放式回复、复杂分析等） 做法： ├── Agent 执行完毕后，把完整轨迹 + 最终结果提交给 Judge 模型 ├── Judge 模型根据预定义的评分标准打分 ├── 通常用比被评测模型更强的模型做 Judge（GPT-4、Claude 等） └── 灵活，能处理开放式结果 局限： ├── Judge 模型本身有偏差（偏好更长的回复、偏好某种格式） ├── 评测成本 = Agent 执行成本 + Judge 模型调用成本 └── 不同 Judge 模型给出的评分可能不一致 ``` **实践建议**：三种方案不是互斥的，通常混合使用。 ```text 推荐的混合方案： ├── 核心功能评测（占 60%） → 沙箱环境 + 自动验证 │ 确定性结果，最可靠 ├── 开放式能力评测（占 25%）→ LLM-as-Judge │ 灵活处理开放式结果 └── 快速回归测试（占 15%） → 静态数据集 + 规则 跑得快，适合 CI/CD 集成 ``` ### 评测集的构建 评测集的质量直接决定评测结果的可信度。 ```text 评测集构建原则： ├── 任务覆盖：每种支持的工具类型至少 20 条测试用例 ├── 难度分布：简单 30% / 中等 50% / 困难 20% ├── 长度分布：1-3 步任务 / 4-8 步任务 / 8+ 步任务各占一定比例 ├── 负面用例：包含"不需要调工具"和"应该拒绝"的场景 └── 独立性：评测集不能和训练集有重叠 ``` **特别注意数据泄露**：如果你的 Agent 轨迹数据是强模型生成的，而评测集也是类似方式生成的，两者可能有分布重叠——模型在训练集里“见过类似的题”，评测分数虚高。 防泄露的做法： - 评测集由不同的人 / 不同的方法构建 - 评测集发布后冻结，不随训练数据更新 - 定期引入新的评测用例，检查模型是否只是“记住了答案” ## 主流 Benchmark 参考 不需要从零搭评测体系——已经有一些成熟的 Agent Benchmark 可以直接用或参考。 | Benchmark | 场景 | 评测方式 | 核心指标 | |---|---|---|---| | SWE-bench | 代码修复 | 沙箱 + 单元测试 | 修复通过率 | | WebArena | 网页操作 | 模拟浏览器环境 | 任务完成率 | | ToolBench | 工具调用 | API 沙箱 | 调用正确率 + 任务完成率 | | GAIA | 通用 Agent | 混合环境 | 任务完成率（分级别） | | AgentBench | 多场景 Agent | 多种沙箱 | 综合得分 | | HumanEval | 代码生成 | 执行 + 测试 | Pass@k | **选择建议**： ```text 你的 Agent 类型 → 优先用什么 Benchmark 代码 Agent → SWE-bench（最权威）+ HumanEval（基础能力） Web Agent → WebArena 工具调用 Agent → ToolBench + 自建评测集（ToolBench 工具覆盖可能不够） 通用 Agent → GAIA + AgentBench ``` 但不要只跑公开 Benchmark——公开 Benchmark 的任务分布和你的真实业务分布大概率不一样。**公开 Benchmark 用来对标业界水平，自建评测集用来评估真实业务表现。两者缺一不可。** ## 评测陷阱：看起来好但实际不行 ### 陷阱 1：只看完成率，忽视效率 ```text 模型 A：完成率 82%，平均 6 步完成 模型 B：完成率 85%，平均 14 步完成 如果只看完成率，会选 B。 但 B 的推理成本是 A 的 2 倍多，延迟也更高。 生产环境中 A 可能是更好的选择。 ``` **解决**：报告完成率时必须同时报告平均步骤数和 Token 消耗。计算一个综合效率分： ```text 效率得分 = 完成率 × (基准步骤数 / 实际步骤数) ``` ### 陷阱 2：评测集太简单 如果评测集里 80% 是简单任务（1-2 步就能完成），模型的完成率看起来很高，但一到复杂场景就拉胯。 ```text 检查方法： 把评测集按难度分层，分别看每层的完成率 简单（1-3 步）：95% ← 这个高不意外 中等（4-8 步）：65% ← 这才是真实水平 困难（8+ 步）：30% ← 复杂场景差很远 如果只看总体：78%（被简单任务拉高了） ``` ### 陷阱 3：评测环境和生产环境不一致 评测时用的是模拟 API，返回格式整洁、永不超时、参数校验宽松。生产环境的 API 返回可能有噪声、会超时、参数格式要求严格。 ```text 评测环境 vs 生产环境的常见差异： ├── API 返回格式 评测环境统一 JSON，生产有 XML、纯文本、HTML 混杂 ├── 延迟和超时 评测环境秒回，生产可能 10 秒超时 ├── 错误率 评测环境 0% 错误，生产 5-15% 的调用会失败 ├── 数据新鲜度 评测环境数据固定，生产数据实时变化 └── 并发和限流 评测环境无限流，生产有 QPS 限制 ``` **解决**：在评测环境中注入真实的噪声——随机 5% 的工具调用返回超时，随机 3% 返回格式异常。看模型在有噪声的环境中表现如何。 ### 陷阱 4：LLM-as-Judge 的系统性偏差 用强模型做 Judge 很方便，但 Judge 模型有自己的偏好： ```text 已知的 Judge 偏差： ├── 长度偏好 更长的回复倾向于得更高分 ├── 格式偏好 有 markdown 格式的回复得分更高 ├── 自我偏好 如果 Judge 是 GPT-4，它可能给 GPT-4 生成的内容更高分 └── 位置偏好 在 A/B 对比中，第一个选项可能被偏好 ``` **缓解方法**： - 多个 Judge 模型交叉打分，取平均 - 对 A/B 对比做位置随机化（交换 A/B 顺序各跑一次） - 控制回复长度后再比较（或在评分标准中明确说明简洁更好） - 关键评测点用人工抽检校准 Judge 的准确度 ### 陷阱 5：训练集和评测集分布泄露 这不是说两者有完全相同的样本——而是分布层面的泄露。 ```text 泄露场景： ├── 训练数据和评测数据都是 GPT-4 生成的 → 任务类型和表述风格相似 ├── 训练数据从某个来源爬取，评测数据从同一来源的不同页面爬取 ├── 评测集发布后被人放进了训练集（公开 Benchmark 的老问题） └── 模型在 pretrain 阶段就见过评测数据（对公开 Benchmark 尤其严重） 检测方法： ├── 用模型没见过的全新任务测一次，对比分数差异 ├── 检查评测集中的高分样本，和训练集做相似度比对 └── 定期更新评测集，只用新样本 ``` ## 评测流程：串成一条线 把上面的内容串起来，一套完整的 Agent 评测流程： ```text 阶段 1：训练中的快速评测（每 500-1000 步） ├── 用静态数据集跑 50-100 条核心任务 ├── 看任务完成率和工具调用格式正确率 ├── 同时跑通用 benchmark 的子集（MT-Bench 等）检测能力偏移 └── 目标：快速发现训练方向是否正确，10 分钟内出结果 阶段 2：checkpoint 评测（每个候选模型） ├── 沙箱环境跑完整评测集（300-500 条） ├── 计算全部四层指标（完成率 + 效率 + 鲁棒性 + 安全） ├── 分难度层级看完成率 ├── 跑公开 Benchmark 对标业界水平 └── 目标：全面评估模型能力，几小时出结果 阶段 3：上线前灰度评测 ├── 在生产环境的灰度流量上跑 ├── 监控真实用户任务的完成率和用户反馈 ├── 对比新模型和旧模型的 A/B 指标 ├── 重点关注 edge case 和安全问题 └── 目标：验证评测结果是否和真实表现一致 ``` ## 小结 - Agent 评测不是看一个完成率就够的——需要四层指标：完成（Pass Rate/Pass@k）、效率（步骤数/Token 消耗）、鲁棒性（错误恢复/指令扰动）、安全（拒绝率/注入抵抗） - 评测环境推荐混合方案：沙箱自动验证为主，LLM-as-Judge 处理开放式结果，静态数据集做快速回归 - 警惕五大陷阱：只看完成率、评测集太简单、环境不一致、Judge 偏差、分布泄露——每个都会让你对模型能力产生错误判断 - 公开 Benchmark 用来对标业界，自建评测集用来评估业务——两者缺一不可 - 评测贯穿训练全周期：训练中快速检查、checkpoint 全面评测、上线前灰度验证 下一篇建议继续看： - [从 SFT 到部署：Agent 模型上线全流程](../06-train-to-deploy/index.html)