为什么传统 LLM 榜单对 Agent 毫无参考价值？
在 MMLU、GSM8k 等选择题基准上拿高分的模型，在实际面对一个包含文件系统、网络工具和多步报错的复杂环境时，可能第一步就会拼错参数而崩溃。
选择题基准与 Agent 任务的差异可以从三个维度刻画：其一，前者单步完成、后者多步串联，单步成功率即便高达九成，串起来后错误会按链路长度复利放大；其二，前者环境无反馈、后者每一步都会收到真实世界的返回值，处理反馈本身就是新的能力项；其三，前者答对即可、后者存在大量"答案正确但路径荒谬"的过拟合解法。评测体系因此必须整体换轨。
新一代 Agent 专属评测基准
- GAIA（General AI Assistants）：由 Meta 等机构联合推出，要求智能体综合使用多模态感知、网页检索和本地工具解决看似简单但容错率为零的现实复杂多步任务；
- AgentBench：首个系统性多环境评估基准，涵盖操作系统命令行、数据库查询、网购交互等 8 个不同维度的交互环境；
- 核心关注指标：从单纯的“回答正确率”转变为“首击命中率（Pass@1）”、“达到目标的平均工具调用步数（Efficiency）”以及“成本开销（Cost-per-task）”。
三项核心指标的计量口径
| 指标 | 统计什么 | 常见计量陷阱 |
|---|---|---|
| Pass@1 | 首次尝试即通过任务的比例 | 任务集过窄导致采样偏差，或把重试后成功记入 |
| Efficiency | 达成目标的平均工具调用步数 | 未计入失败重试的隐性步数，虚显高效 |
| Cost-per-task | 单任务全链路花费 | 只记模型 token，漏掉沙箱、检索等外围开销 |
建议在报表里固定注明分母（任务数、试次）与口径（是否含重试），否则同名指标在不同团队间不可比。
搭建内部 Agent 评测的五步法
公开基准回答"模型之间谁强"，业务选型还需要一套内部评测集：
- 任务采集：从真实工单、缺陷单与客服记录中挑选已完结、可自动判定的任务，保证评测分布与生产分布一致；
- 判分器先行：为每类任务写确定性的判分脚本（测试通过与否、字段匹配与否），人工判分只作抽检；
- 环境快照：固定文件系统与依赖版本，让同一 Agent 的两次运行结果可比；
- 多试次跑方差：同一任务重复执行若干次，记录通过率分布而不只取最好一次，暴露非确定性风险；
- 分层记账：按任务类型分别统计三项指标，避免平均分掩盖某一维度的系统性短板。
常见问题速查
| 现象/疑问 | 原因/背景 | 处理/建议 |
|---|---|---|
| 榜单高分但上线翻车 | 公开基准与业务任务分布错位 | 建内部评测集并定期对齐生产分布 |
| 同一 Agent 时好时坏 | 采样非确定性叠加长链路 | 提高试次、报告通过率区间 |
| 步数少但结果错 | 早停或跳过必要验证 | 判分器强制校验最终状态 |
| 成本报表差异巨大 | 口径未统一（是否含外围调用） | 明确定义任务全链路的成本边界 |
小结
选型时的可执行判断标准：不看任何单一分数，只看三样东西——与自身业务同分布的内部评测通过率区间、达成目标所需步数的中位数、单任务全链路成本的口径明细。三者齐全且经得起复跑的结果，才配进入采购讨论；缺一样，就把那个数字当成宣传材料。