深度学习 · 2026-07-13

AI Agent 评测与 Benchmark
如何科学判断一个 Agent 好不好

从「只看答对没答对」到「评一整条行动轨迹」——2026 年 Agent 评测方法论正在快速定型。这份文档讲清:是什么、怎么评、用什么工具、有哪些坑。

0 · 30 秒速览

一句话:Agent 评测,是给一个「会自己调工具、分多步干活」的 AI 系统打分——难点在于它可能「答对了但路走歪了」,所以不能只看最终答案,要看它一步步是怎么做的。

传统模型评测像判一道选择题:给个输入,看输出对不对。但 Agent 不是一次问答——它会读任务、调工具、看结果、再决定下一步,循环往复直到完成。这就带来一个新问题:一个 Agent 可能最后蒙对了答案,中间却绕了十步、调错三次工具、烧了十倍的钱。只盯着最终答案,你根本发现不了这些隐患,而它们上线后会变成延迟高、成本爆、偶发翻车。

用户任务 ① 传统模型评测 只看最终答案 ② Agent 轨迹评测 规划 调工具 看结果 再决策 最终答案
图:传统评测只关心「输入→最终输出」的两端;Agent 评测要把中间「规划→调工具→看结果→再决策」的整条轨迹也纳入打分。
🔑 记住这一句Agent 评测 = 结果对不对(任务完成度)+ 过程好不好(轨迹质量)。2026 年的共识是:两者都要评,且过程往往比你想的更重要。

1 · 为什么 Agent 评测这么难

先说清楚痛点,你才知道后面那些方法是来解决什么的。评一个 Agent 难,主要难在三点:

难点一:路径不唯一,答案也不唯一
同一个任务,Agent A 用 3 步搞定,Agent B 绕了 12 步也搞定。两者「答对了」,但工程价值天差地别。而且很多任务(写代码、回邮件)根本没有标准答案,没法用「等于参考答案」来判分。
难点二:会「答对但做错」
Confident AI 等实践者反复强调:一个 Agent 可以把每个工具都调用成功,却依然没完成用户真正的任务;传统的精确匹配(exact-match)指标恰恰抓不到这类失败。
难点三:非确定性 + 多步放大
大模型本身有随机性,Agent 又把它放进「多步循环」里——早期一个小的判断偏差,会在后面被层层放大。今天一条 arXiv 论文《When Agents Do Not Stop》(7 月 2 日)就专门研究了 Agent「停不下来、陷入无限循环」这类失败模式(arXiv 2607.01641)。
🧭 打个比方
评一个只回答问题的模型,像给学生的考卷打分——看答案对不对就行。评一个 Agent,更像给一个实习生的一天打绩效:他最后是把活干完了,但你还得看他中间有没有反复返工、有没有乱调资源、有没有卡在某个环节出不来。只看结果,你会留下一个「效率极差但偶尔能成」的员工。

2 · 到底在评什么:结果 vs 过程

把「评测对象」拆开,Agent 评测大致落在两个层面。理解这个二分,后面的指标和工具就都能对号入座。

层面评什么怎么判典型问题
结果层(output)最终有没有把用户的任务完成能确定的用确定性检查(如代码能否通过测试);开放式的用 LLM-as-Judge「答案对吗?任务达成了吗?」
过程层(trajectory)达成任务的这一整条路径:工具选择、参数、中间推理、重试、步数轨迹匹配 + 逐 span 打分「路走得对吗?高效吗?安全吗?」

Confident AI 把过程层进一步展开成一串可评的能力点:工具调用(tool calling)、规划(planning)、推理(reasoning)、交接(handoffs)、步骤效率(step efficiency)、任务完成(task completion)(来源)。你不必每次全评,但心里要有这张清单,才知道自己漏了哪块。

3 · 轨迹评估(Trajectory Eval):2026 年的核心思路

「轨迹评估」是这两年 Agent 评测最重要的方法转向,值得单独讲透。

什么是轨迹(trajectory)
Agent 完成一个任务时,一连串动作的完整记录:每一次模型调用、每一次工具调用、每次调用传了什么参数、返回了什么、中间做了什么推理、重试了几次。把这些按嵌套关系串起来,就是一棵「调用树(span tree)」。

轨迹评估,就是给这棵树打分,而不只是给树顶的最终答案打分。按 Arize/Confident 等实践的描述,它会:拿轨迹和一条参考轨迹做「轨迹匹配」;在每个 span 上单独评「这一步工具选对了吗、这一步忠实于任务吗」;并监控工具调用准确率、实际步数 vs 最少步数、是否出现循环、出错后能否恢复(来源)。

任务:修复这个 bug ① 规划步骤 ② 搜索代码库 ③ 编辑文件 ④ 读文件(重试×2) ⑤ 跑测试 ✓ ↑ span 级打分:这步为何重试?工具选对没?
图:一次「修 bug」任务的调用树。轨迹评估会对每个节点(span)单独打分——比如发现「读文件重试了 2 次」,顺着追问原因,而不是等测试通过就万事大吉。
⚠️ 硬前提轨迹评估需要 trace 数据,而 trace 数据需要埋点(instrumentation)——这一步不是可选项(来源)。没做可观测性埋点,你连轨迹都拿不到,更谈不上评。所以「先接 OpenTelemetry / 追踪,再谈评测」是正确顺序。

4 · 六个关键指标,一次说清

别被各家花名迷惑,Agent 评测反复出现的核心指标就这几个。每个都配一句大白话:

任务完成度(Task Completion / Goal Accuracy)
用户交代的活,到底干成没有?这是最终的「及格线」指标。开放式任务通常靠 LLM-as-Judge 判。
工具调用准确率(Tool Call Accuracy)
该调的工具有没有调、参数对不对、没瞎调不该调的。这类是「确定性」的,能用规则精确判,不必动用大模型。
规划质量(Plan Quality)
Agent 一开始定的计划,是否完整、现实、高效。一个烂计划会在第一次调用工具之前就注定后面全盘皆输——所以值得单独评。
步骤效率(Step Efficiency)
实际用了多少步 vs 理论最少步数。步数越冗余,线上成本和延迟越高。
循环与恢复(Loops & Recovery)
有没有陷入原地打转;出错之后能不能自己纠回来。对应今天那篇「无限循环」论文的关注点。
忠实度 / 推理质量(Faithfulness)
每一步的推理是不是贴着任务和证据走,有没有「一本正经地跑偏」。
🔑 选型口诀能用规则确定判的(工具对不对、代码过没过测试),就别用大模型——又快又准。只有「依赖 Agent 实际输出、没有标准答案」的部分(回答质量、计划好坏),才交给 LLM-as-Judge(来源)。

5 · LLM-as-Judge:用一个模型评另一个模型

开放式任务没有标准答案,人工逐条评又太慢太贵,于是「让一个大模型当裁判(LLM-as-Judge)」成了主流做法。但它是把双刃剑,用不好比不评还危险。

怎么用得更靠谱(2026 的经验)

  • 给明确的评分标准,而不是「你看着打分」。DeepEval 的实践指出:用 0–5 分制、且每一档都写清判据,人机一致性最高(Pearson 相关 0.89),明显好过 10 分制(来源)。
  • 一定要拿人类判断去校准裁判。最大的坑就是「从不验证裁判分是否和人一致」——你可能根本不知道你的裁判在给啰嗦的回答虚高分、给简洁但正确的回答扣分(来源)。
  • 分层用裁判。2026 的趋势是:用便宜的「蒸馏小裁判」在生产环境持续跑,只在需要深度核查时才动用更贵的「agent-as-judge」选择性复核(来源)。
⚠️ 已知偏见LLM 裁判有系统性偏好:倾向给更长、更啰嗦的回答打高分。不校准就直接信裁判分,等于把这个偏见写进了你的评测标准。

6 · 主流 Benchmark 速查表

公开 Benchmark 用来横向比不同模型/Agent 的「大盘水平」,选型和跟进 SOTA 时看它。核心逻辑都一样:给一个多步任务 + 一套工具,看 Agent 能不能真的把活干完,而不只是答一道题(来源)。

Benchmark评什么怎么跑适合的场景
SWE-bench Verified真实 GitHub issue 的修复能力把模型放进编码 harness,面对 500 个人工核验过的真实 issue,读仓库→改文件→跑测试→迭代到修好工程 / 编码 Agent 的黄金标准
tau-bench(τ-bench)工具型对话 + 策略合规模拟零售、航空客服流程,带一个「用户模拟器」互动面向客户、有合规/规章约束的企业 Agent
WebArena网页操作能力5 个沙箱网站、812 个任务,要点击/填表/搜索/跨页导航浏览器 / RPA 类 Agent
GAIA通用助理能力需要工具、联网、多步推理的真实问题,「人易机难」通用助理 / Deep Research 类

2026 选用建议:工程看 SWE-bench Verified,浏览器任务看 WebArena,助理类看 GAIA,工具对话看 tau-bench(来源)。

今日榜单快照(截至 7 月 11 日)

95.5%
Claude Mythos 5
SWE-bench Verified 第一
95%
Claude Fable 5
紧随其后
88.6%
Claude Opus 4.8
0.621
Zhipu GLM-5.2
SWE-Bench Pro 最强开源

数据来源:BenchLM.ai SWE-bench Verified 榜SWE-Bench Pro 榜。榜单更新快,以官网最新为准。

⚠️ 别只看公开榜单公开 Benchmark 有「刷榜」和「数据污染」风险,而且未必贴合你的业务。学术界也在推 CUBE(统一 Agent 基准的标准,arXiv 2603.15798)UTBoost(针对 SWE-bench 测试用例不足做加强,arXiv 2506.09289)来修补口径不一和评测不严的问题。真要上线,还得配一套贴合自己业务的私有评测集。

7 · 评测工具矩阵:各挑各的活

工程落地时,你需要一套工具把「埋点 → 收轨迹 → 打分 → 看板」串起来。2026 年常被点名的一批(来源):

工具定位特点
DeepEval代码优先的 CI 评测pytest 风格、50+ 内置指标,适合把评测塞进 CI 流水线
Arize Phoenix可观测 + 评测OpenTelemetry 原生、支持轨迹评测,可自托管
LangSmithLangChain 原生轨迹评测和 LangChain / LangGraph 生态无缝
Braintrust评测优先的打分平台以 eval 为核心的评分工作流
OpenAI Evals离线批量评分MIT 开源,做离线 grading
RAGASRAG 场景指标专攻检索增强类的评测指标
🔑 2026 新范式评测正从「上线前跑一次」变成「嵌进运行时的护栏」:便宜的蒸馏评测器在生产环境持续跑,多维指标取代单一准确率数字,可观测性成为地基,eval 直接内嵌进 Agent 运行时充当 guardrail(来源)。

8 · 常见坑(照着避)

  • 只看最终答案。输出对≠过程健康;输出层打分会把轨迹问题藏起来,规模化后变成成本和延迟的爆雷(来源)。
  • 不校准 LLM 裁判。从不拿人类判断验证裁判分,等于蒙着眼信一个有偏见的裁判。
  • 没埋点就想评轨迹。trace 是轨迹评估的前提,可观测性不是锦上添花,是地基。
  • 迷信公开榜单当唯一标准。有污染和刷榜风险,且不贴合你的业务;要配私有评测集。
  • 用单一数字概括一切。「准确率 87%」掩盖了它在工具调用、步骤效率、恢复能力上的差异——多维指标才有诊断价值。

9 · 落地七步法

把上面的东西收成一个可执行顺序,给你自己搭一套 Agent 评测时照做:

  • 先埋点。接 OpenTelemetry / 追踪,确保每次运行都能拿到完整轨迹(span 树)。
  • 定义任务完成度。先把「怎样算干成了」写成可判定的标准——能用规则就用规则。
  • 拆过程指标。从工具准确率、规划质量、步骤效率、循环/恢复里挑你最在意的 2–3 个。
  • 搭 LLM-as-Judge。给 0–5 分制 + 每档明确判据,只用在开放式、没标准答案的部分。
  • 用人类样本校准裁判。标一小批人工分,验证裁判与人的一致性,调 prompt 直到对齐。
  • 建私有评测集。从真实业务采一批代表性任务,别只靠公开 Benchmark。
  • 持续跑 + 当护栏。把便宜的评测器挂到生产环境持续监控,异常轨迹实时告警。

10 · 继续深入的资源

Confident AI:LLM Agent 评测完全指南
指标、轨迹评测、trace 前提讲得最系统。链接
DeepEval:LLM-as-a-Judge 最佳实践(2026)
裁判分制、判据设计、人机一致性的实证。链接
Benchmarking Agents:2026 Agent Benchmark 汇总
SWE-bench / WebArena / GAIA / tau-bench 等横评。链接
Morph LLM:Agent 评测框架 7 家对比
DeepEval / Phoenix / LangSmith / Braintrust 等工具选型。链接
Stanford CS329A《Self-Improving AI Agents》
课程含「构建稳健评测框架的挑战」专题。链接