Agent 评估
Agent 评估衡量的是一个多步、有状态、会调用工具的系统在完整任务上的表现，不只看最终答案，更要看决策轨迹。它与单轮 QA 评估有五个结构性差异：评估对象是轨迹不是答案、正确性含中间步骤、答案空间无法枚举、跑一次很贵、可复现性差。传统的 BLEU 和 MMLU 那套方法论在这里失效。
评估对象：轨迹
单轮评测测“模型能不能答对”，Agent 评测测“系统能不能走对路”。一条轨迹里每一步都可能出错：工具选错、参数填错、该停不停、不该调时乱调。单看最终输出可能是对的，但中间花了 50K token、跑了 8 分钟。
三个评估层次：
- 结果层（Outcome）：任务最终成功了吗。最常用，但蒙对的也算过
- 轨迹层（Trajectory）：逐步骤对照专家轨迹，有没有多余动作、漏关键步骤
- 过程层（Process）：用 LLM-judge 评估每步决策的合理性，殊途同归也给分，最贵
实践折中：结果层判通过失败，只对失败轨迹用 LLM-judge 定位根因。
工具调用指标
Agent 评测的核心指标集：
| 指标 | 含义 |
|---|---|
| Task Success Rate | 任务最终完成比例 |
| pass^k | 跑 k 次全部成功的概率，衡量稳定性。pass@1=0.8 但 pass^16=0.1 说明靠运气 |
| Step Efficiency | 平均步数，越少越好。10 步完成比 50 步便宜 5 倍 |
| Tool Selection Accuracy | 选对工具的比例 |
| Argument Accuracy | 参数填对的比例 |
| Policy Violation Rate | 违反业务策略的比例 |
| Avg $ / Task | 单任务成本 |
生产场景几乎都用 pass@1 加 pass^k 的组合，Pass@K 留给论文展示模型上限。
主流基准
| 基准 | 测什么 | 特点 |
|---|---|---|
| SWE-bench Verified | 真实 GitHub issue 修复 | 500 题，跑测试判分，无 judge 主观性，编程 Agent 标杆。一次 full run 约 $1500-3000 |
| GAIA | 通用助手任务 | 466 题，普通人 92%，问题对人简单对模型难，测推理加多模态加工具协调 |
| τ-bench | 零售/航空客服 | 模拟真实业务，测策略一致性，核心创新是 pass^k |
| AgentBench | 8 类环境（OS/DB/游戏等） | 通用环境覆盖广度 |
| BFCL | function calling 专项 | 单步加多步工具调用准确率 |
SWE-bench 和 GAIA 互补：前者吃代码理解，后者吃信息检索和综合。单轮 benchmark 高分不等于 Agent 强，Claude 3.5 的 MMLU 不如 GPT-4o，SWE-bench 却明显领先。
生产评估体系
- 评估集从真实 trace 挖：从生产日志、用户投诉中挖掘任务，聚类采样保证覆盖，至少 150 题：50 日常能力、50 历史 bug 回归、30 对抗压测、20 多轮难题
- Grader 确定性优先：能规则判就规则判（测试、数据库状态、工具调用检查），LLM-judge 只用于主观维度，且要用比被测模型更强的模型加抽样校准
- 评测进 CI：改 prompt、改工具、改 harness 都要跑回归，分数倒退就阻断
- 每次跑多次：Agent 有随机性，跑 k 次取 pass^k 看稳定性
面试追问
- Agent 评估和单轮评测的区别？ 评估对象从答案变成轨迹，正确性含中间步骤和副作用，可复现性差，成本高，指标多维。五个差异叠加使传统方法失效
- pass^k 是什么？ 跑 k 次全部成功的概率。普通 pass@1 被偶尔成功误导，生产要的是稳定
- SWE-bench 凭什么可信？ 真实仓库 issue 加跑测试判分，客观无主观性。局限是只覆盖 Python，过测试不等于代码质量好
- GAIA 和 SWE-bench 什么区别？ GAIA 测通用助手能力（推理、多模态、工具协调），SWE-bench 测编程能力。互补不重叠
- 生产评估怎么搭？ 从真实 trace 挖任务建 150 题基准，Grader 确定性优先，跑多次取 pass^k，进 CI 防回归，失败轨迹用 LLM-judge 定位根因