评测体系

如果说 prompt 决定了 agent 的上限，那 eval 决定了你能不能知道自己离上限还有多远。2025 年之后，行业的一个共识是：模型能力不再是多数 agent 项目的瓶颈，评测能力才是。没有 eval 的团队在「改 prompt → 感觉变好了 → 上线 → 翻车 → 回滚」的循环里空转；有 eval 的团队把每一次改动变成可比较的实验。Anthropic 工程博客在《Demystifying Evals for AI Agents》里说得很直白：没有 eval，团队会陷入被动响应模式——只在生产事故后修问题，而修一个问题又制造另外三个。

这一页讲清楚四件事：agent 评测为什么难、评什么（四个层次）、用什么评（四类评分器）、以及主流 benchmark 到底在测什么。最后给一套自建私有 eval 的方法论，和必须警惕的刷分陷阱。

一、为什么 Agent 评测难

传统 NLP 评测是「给输入、对答案」的静态游戏，agent 评测完全不是。难点集中在四个方面。

1. 非确定性：同一个输入，每次跑都不一样

LLM 采样本身有随机性，agent 的每一步决策又会放大它：第一步选了不同的工具，后面整条轨迹就分道扬镳。这意味着「跑一遍，过了」什么都说明不了。业界通行的做法是 pass^k（τ-bench 提出的指标）：同一个任务跑 k 次，全部通过才算真正可靠。一个 pass@1 有 70% 的 agent，pass^8 可能只有个位数——这对客服、金融这类场景是生死线。

2. 多步轨迹：对错不再是二元的

一个 20 步的任务，agent 最终答案对了，但中间调错了三次工具靠运气兜回来——算成功吗？反过来，最终失败了，但失败原因是第 18 步网站崩了——算 agent 的锅吗？单看结果的评测会把这两种情况都评错，所以必须引入轨迹级评估（见第二节）。

3. 环境依赖：被测的是「agent + 环境」这个整体

WebArena、OSWorld 这类环境型 benchmark，任务成功率同时取决于模型能力、scaffold 质量、环境稳定性。同一个模型换个 scaffold，分数可以天差地别——普林斯顿 HAL 榜单上，Claude Sonnet 4.5 在 HAL 自己的 Generalist scaffold 下 GAIA 得分 74.55%，换到 HuggingFace 的 Open Deep Research scaffold 下只有 30.91%，差出 43 个百分点，全来自编排层。所以你看到任何 benchmark 数字，第一个要问的问题是：用的什么 scaffold？

4. 成本：跑一轮 eval 可能比你想象的贵得多

agent eval 不是跑几千个 prompt 就完事。Terminal-Bench 官方榜单上标注了每次完整评测的 API 成本：Claude Code + Fable 5 跑一轮约 553 美元，Codex + GPT-5.5 跑一轮超过 2000 美元。这还没算环境搭建、失败重试和人工抽检。eval 设计必须回答「花多少钱买到多少统计置信度」，这也是成本与优化这一页讨论的问题在评测侧的镜像。

一个常见误判

把「模型在公开 benchmark 上的分数」当成「我的 agent 上线后的成功率」。前者是在受控环境、固定 scaffold、已知任务分布下测的；后者面对的是你的私有数据、脏输入和长尾需求。两者的差距经常大到让 benchmark 排名失去参考意义——这正是本文第七节要展开的问题。

二、评估的四个层次

成熟的 agent 评测体系是分层的，像软件测试里的单元测试→集成测试→端到端测试→线上监控。每一层回答的问题不同，混用会导致结论失真。

┌─────────────────────────────────────────────────────────┐
│ L4 系统层   成本 / 延迟 / 安全 / 用户满意度                │  ← 值不值得上线
├─────────────────────────────────────────────────────────┤
│ L3 结果层   任务成功率（端到端，环境验证）                  │  ← 活干成了没有
├─────────────────────────────────────────────────────────┤
│ L2 轨迹层   每步决策质量、工具选择、错误恢复                │  ← 过程对不对
├─────────────────────────────────────────────────────────┤
│ L1 单元层   单次工具调用、单条 prompt 的输出                │  ← 零件好不好
└─────────────────────────────────────────────────────────┘

L1 单元层

把 agent 拆开评：单个工具的 schema 是否被正确填充、单条 prompt 的分类准确率、RAG 检索的召回率。这一层最接近传统 LLM 评测，可以用静态数据集 + 断言快速跑。价值在于定位问题——端到端失败时，你得知道是哪个零件坏了。工具调用这一层的成熟参照物是 Berkeley Function-Calling Leaderboard（BFCL），用 AST 匹配来判定函数选择和参数填充是否正确。

L2 轨迹层

评估「过程」而非「结果」：agent 是否选择了合理的工具序列、有没有无效循环、错误后是否恢复、步骤数是否失控。常用做法是记录完整 trace（参见可观测性），然后用规则（如「不允许同一工具连续失败 3 次」）或 LLM-as-judge 对轨迹打分。轨迹层的价值在于它能在结果偶然成功时依然发现问题。

L3 结果层

端到端任务成功率：给定任务，最终状态对不对。SWE-bench 的「测试通过即解决」、τ-bench 的「数据库终态匹配」都属于这层。这是最有说服力的一层，也是成本最高的一层——需要可执行的环境或可靠的判据。读 agent 相关论文时，这层指标是唯一值得当真的（参见论文精读路径里对 benchmark 论文的读法）。

L4 系统层

agent 作为线上系统的整体指标：单次任务成本、P50/P99 延迟、安全事件率（参见安全与对齐）、用户采纳率/满意度。这一层没有 benchmark 可用，只能靠线上埋点和 A/B 实验。一个反直觉的经验是：L3 提升但 L4 恶化是常态——准确率更高的模型往往更慢更贵，是否值得要用业务指标裁决。

分层的第一原则

下层指标用于调试，上层指标用于决策。L1 绿了但 L3 红，说明问题在编排；L3 绿了但 L4 红，说明方向本身错了。不要拿单元层的提升去向老板汇报「agent 变好了」。

三、评分器（Grader）的四种类型

评什么确定了，接下来是用什么评。实践中四种类型的评分器按可信度和成本排成一个光谱，成熟的 eval 体系会组合使用。

1. 规则断言（Code-based grader）

正则匹配、JSON schema 校验、状态断言（「数据库里订单状态必须变成 refunded」）。优点是确定、便宜、可复现；缺点是只能评结构化、有明确判据的输出。能用规则的地方一律用规则，这是所有成熟团队的第一原则。

2. 环境验证（Execution-based grader）

规则断言的加强版：不检查输出文本，而是检查世界的状态。SWE-bench 跑测试套件、OSWorld 执行评估脚本检查文件内容、Terminal-Bench 在容器里做 if-and-only-if 校验，都是这一类。它是结果层评估的黄金标准，因为无法被「花言巧语」欺骗——代码要么过了测试，要么没过。代价是环境搭建和维护成本极高。

3. 模型评分（LLM-as-judge）

让另一个 LLM 当裁判，评开放性输出（摘要质量、对话得体性、轨迹合理性）。这是当前覆盖面最广、也最容易用错的一类。

奠基性工作是 Zheng 等人 2023 年的《Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena》（NeurIPS 2023，arXiv:2306.05685），它命名了沿用至今的偏差分类：

• 位置偏差（position bias）：成对比较时，裁判偏好放在前面（或后面）的那个答案。缓解：交换顺序各评一次取平均。
• 冗长偏差（verbosity bias）：更长的答案更容易赢，与质量无关。缓解：在 prompt 里明确「长度不是加分项」，或对长度做归一化。
• 自恋偏差（self-enhancement / self-preference bias）：裁判偏好自己家模型生成的内容。Panickssery 等人 2024 年的 NeurIPS 论文（arXiv:2404.13076）证实 LLM 能认出并偏爱自己的输出。缓解：裁判模型与被测模型用不同厂商的模型族。

该论文同时给出了正面证据：GPT-4 裁判与人类偏好的一致率可达 80% 以上，接近人与人自身的一致水平——这是 LLM-as-judge 在工程上可用的根本原因。但注意这个结论有边界：它成立在「有明确好坏之分的成对比较」上，对需要深层领域知识的细粒度评分（比如「这段代码的并发处理是否安全」），裁判模型的错误率会显著上升。

校准（calibration）是必修课：用一小批人工标注的样本（哪怕只有 50-100 条）定期检验裁判模型与人工判断的一致率，低于阈值就要换裁判、改 rubric 或回退到人工。LangChain 等团队 2026 年的实践指南把「用人工修正样本持续校准 judge」列为核心流程。记住：裁判模型本身也是一个待测系统，它的分数在被验证之前不构成证据。

4. 人工抽检（Human review）

最贵也最不可替代。用途有三：校准 LLM 裁判、评审 benchmark 覆盖不了的维度（用户体验、业务合规）、以及对失败 case 做归因分析。现实的配比是：规则和环境验证覆盖能覆盖的全部，LLM 裁判处理开放输出，人工按 5%-10% 的比例抽检裁判结果。

# 一个带位置偏差缓解的成对比较裁判（示意）
# 原则：交换顺序评两次，两次结论一致才采纳

import random

JUDGE_PROMPT = """你在评估一个客服 agent 的两条回复。
评判标准（按优先级）：
1. 是否解决了用户问题 2. 是否遵守了退款政策 3. 语气是否专业
注意：回复长度不是质量指标。

用户问题：{query}
回复 A：{response_a}
回复 B：{response_b}

只输出 JSON：{{"winner": "A" | "B" | "tie", "reason": "一句话理由"}}"""

def judge_pair(query, resp1, resp2, judge_fn):
    """judge_fn: 调用裁判模型的函数。交换顺序各评一次。"""
    if random.random() < 0.5:
        resp1, resp2 = resp2, resp1  # 随机化首评顺序，避免固定起点
    votes = []
    for a, b in [(resp1, resp2), (resp2, resp1)]:  # 交换位置
        result = judge_fn(JUDGE_PROMPT.format(query=query, response_a=a, response_b=b))
        votes.append(result["winner"])
    # 两次投票映射回原始回复，一致才判胜负，否则记 tie
    if votes[0] == "A" and votes[1] == "B":
        return "resp1"
    if votes[0] == "B" and votes[1] == "A":
        return "resp2"
    return "tie"  # 位置不一致 = 裁判自己也拿不准，交给人工

四、主流 Benchmark 巡礼

截至 2026 年 8 月，agent benchmark 已经从「有没有」变成「信哪个」。先看总览，再逐个说定位和现状。

Benchmark	领域	规模	评分方式	当前状态（2026-08）
SWE-bench Verified	真实 GitHub issue 修复	500 题	测试套件通过	已趋饱和，OpenAI 2026-02 宣布弃用
SWE-bench Pro	长周期软件工程	1865 题（公开集 731）	测试套件通过	现役最难代码 benchmark 之一
GAIA	通用助理任务	466 题（3 个难度级）	答案精确匹配	广泛使用，但 scaffold 影响极大
WebArena	网页操作	812 任务	程序化校验	经典环境，逐渐被 Verified 版和后继者接替
OSWorld(-Verified)	真实桌面 OS 操作	369 任务	执行脚本校验	2026-06 发布 2.0，computer-use 事实标准
τ-bench / τ²-bench	工具-用户交互、政策合规	3 个领域	数据库终态 + LLM 裁判	客服场景标杆，头部分数已逼近饱和
BrowseComp	深度网络检索	1266 题	短答案校验	deep research 类 agent 的核心战场
Terminal-Bench	终端命令行任务	多版本（2.1 / 3.0）	容器内 iff 校验	榜单活跃，含成本数据，工程味最浓

SWE-bench（Verified / Pro）

SWE-bench（ICLR 2024）从 12 个流行 Python 仓库抽取 2294 个真实 GitHub issue，agent 要产出补丁让 fail-to-pass 测试转绿、同时不破坏 pass-to-pass 测试。它定义了「环境验证」这一评测范式的工程标准。

Verified 是 OpenAI 2024 年推出的人工筛选子集（500 题），剔除了描述不清、测试不可靠的样本，此后两年是编码 agent 最常被引用的数字。但到 2026 年它已经完成了历史使命：官方榜单头部在 2025 年底突破 76%，2026 年各第三方追踪站的数据在 75% 以上继续爬升（不同聚合站口径差异很大，引用前务必核对），更重要的是——OpenAI 在 2026 年 2 月公开发文宣布不再用 SWE-bench Verified 评估自家模型，理由是污染加剧和存在有缺陷的测试，它「越来越测不出前沿编码能力的差异」。一个 benchmark 被头部实验室公开弃用，这在评测史上是值得记住的事件。

SWE-bench Pro（Scale AI，2025-09，arXiv:2509.16941）是接棒者：1865 个任务、41 个仓库，设计上专门反污染——公开集 731 题全部来自 GPL 等强 copyleft 许可证的仓库（法律上阻止其进入商业训练语料），另有私有集（276 题，来自创业公司的专有代码）和完全保密的 held-out 集（858 题）。难度也真实得多：参考补丁平均改动 107.4 行、横跨 4.1 个文件。发布时 GPT-5 和 Claude Opus 4.1 在公开集只有 23.3% / 23.1%，私有集进一步掉到 14.9% / 17.8%——从 Verified 的 70%+ 到 Pro 的 23%，这个落差就是「污染 + 饱和」的量化形态。如果你在 2026 年需要引用一个代码 agent 能力数字，Pro 比 Verified 可信得多。

GAIA

GAIA（Meta、HuggingFace、AutoGPT 团队联合，arXiv:2311.12983）测的是「通用助理」：466 个对人类来说概念简单、对 agent 很折腾的问题，覆盖网页检索、文件解析、多模态、多步推理，按人类解题耗时分三个难度级。答案是短文本精确匹配，评分干净。

用 GAIA 数字时必须看 scaffold。普林斯顿 HAL 榜单（目前已暂停更新新模型，转向研究 agent 可靠性）显示：同一批模型在 HAL Generalist scaffold 与 HuggingFace Open Deep Research scaffold 下分差可达数十分——Claude Sonnet 4.5 是 74.55% vs 30.91%，Claude Opus 4.1 是 68.48% vs 28.48%。HAL 同时公布每轮评测成本（从几十到两千八百美元不等），是少数把「成本-准确率」Pareto 摆上台面的榜单。

WebArena 与 OSWorld

WebArena（ICLR 2024，arXiv:2307.13854）自建了一整套可复现的仿真实体网站（Reddit、GitLab、电商、地图、Wiki），812 个长程任务用程序化校验判定成败。发布时 GPT-4 agent 成功率仅 14.41%，而人类是 78.24%——这个巨大落差定义了 2023-2024 年 web agent 的研究议程。如今它更多以「WebArena Verified 校验器」的形式活在后继工作里，直接刷原始榜单的团队已经少了。

OSWorld 把同样的思路推到真实操作系统：369 个任务跑在真实 Ubuntu/Windows/macOS 虚拟机里，涉及跨应用工作流，每个任务配执行式评估脚本。发布时人类完成率 72.36%，最强模型只有 12.24%，残酷程度堪比当年的 WebArena。它的演进很快：2025-07 升级为 OSWorld-Verified（修复社区报告的问题样本、AWS 支持把一轮评测压缩到 1 小时内），2026-06 又发布了 OSWorld 2.0。第三方聚合站显示 Verified 榜单头部已到 85% 上下（数据未逐一核实，引用前请核对官方榜单）。computer-use 方向它是当前的事实标准。

τ-bench 系列

Sierra Research 的 τ-bench 有一个独特的洞察：企业客服场景里，完成任务不重要，不违反政策才重要。agent 订对了机票但跳过了改签费规则，直接判零分，没有中间分。评分靠数据库终态匹配，指标是前面提过的 pass^k。τ²-bench（arXiv:2506.07982）升级为「双控环境」：模拟用户手里也有工具（比如要自己开关手机的飞行模式），agent 必须教会并引导用户配合操作，把协作沟通也纳入了评测。2026 年该系列继续演化，airline/retail 等老域的头部分数已被刷到接近饱和（聚合站报 99% 量级），新域才是区分度所在。

BrowseComp

OpenAI 2025 年 4 月发布（arXiv:2504.12516），1266 个问题，专测「在茫茫互联网里刨出一条被刻意藏起来的信息」的能力——答案短、可自动校验，但找到它要持久地翻几十个页面。它是各家 deep research 产品（OpenAI Deep Research、Gemini Deep Research 及 2026 年的后继者）的核心战场，也催生了 BrowseComp-ZH 中文版。第三方聚合站 2026 年 8 月的头部数字已到 90% 上下，分数通胀速度肉眼可见——又一条「两年从个位数刷到饱和」的曲线。

Terminal-Bench

终端里的 agent 评测：任务跑在 Docker 容器里，用严格的全对校验（if-and-only-if）判定，配套 harbor 运行器一行命令复现。它的官方榜单是笔者眼中最「工程师友好」的：每个条目同时给出分数±置信区间、scaffold、日期和单轮评测成本。2026 年年中 2.1 版榜单头部约 83-84%（Claude Code + Fable 5 83.8%，Codex + GPT-5.5 83.1%），同一模型在不同 CLI scaffold 下同样有明显分差。做命令行/DevOps 类 agent 的话，这是最对口的公开标尺。

选 benchmark 的速查原则

和你的场景同构优先：写代码看 SWE-bench Pro，桌面操作看 OSWorld，客服政策合规看 τ-bench，检索研究看 BrowseComp，终端运维看 Terminal-Bench。跨场景比较排名没有意义——它们测的根本不是同一件事。

五、自建 Eval 的方法论

公开 benchmark 回答「这个模型行不行」，私有 eval 回答「我的 agent 在我的业务上行不行」。后者才是你该投入的地方。一套可落地的流程：

1. 任务集设计：从失败日志里长出来，别从脑子里想出来

• 来源优先级：线上真实失败 case > 内部 dogfooding 记录 > 产品经理拍脑袋。前两者自带分布真实性。
• 规模：30-50 个高质量任务起步，好过 500 个凑数的。每个任务必须有明确、可机器判定的成功判据——写不出判据的任务不要进集。
• 分层采样：按任务类型、难度、输入长度分层，保证每一层都有覆盖，避免 eval 被某一类任务主导。
• 混入对抗样本：故意构造脏输入、歧义指令、越权请求（安全红线 case 必须有，见安全与对齐）。

2. 防污染：私有 eval 的生命线

• 任务和答案不进任何训练/微调管线，不在 prompt 示例里复用，不进公共仓库。
• 定期（比如每季度）轮换 20%-30% 的题目，长期不换题的 eval 会被团队无意识地「过拟合」——大家都盯着这 50 道题优化，分数涨了能力没涨。
• 如果你用公开 benchmark 的数据做私有 eval，默认它已被污染，只当回归测试用，不当能力证明。

3. 统计显著性：没有误差棒的分数是噪音

• 非确定性 agent 必须多次采样。每个任务至少跑 5-10 次，报均值和置信区间，不报单次最好成绩。
• 样本量决定分辨力：50 个任务的 eval，5 个百分点的「提升」大概率是噪音。粗算一下：二项分布下，n=50 时 ±1σ 约 7 个百分点。想分辨 2-3 个点的差异，任务集得几百起，或者接受更长的置信区间。
• 用配对比较提升灵敏度：同一批任务、同一份随机种子预算下跑新旧两版 agent，比较成对差异而不是两个独立分数——Miller 在《Adding Error Bars to Evals》（arXiv:2411.00640）里系统论证过，eval 就是实验，分数是带采样误差的统计量。
• 成本也要纳入报告：「准确率 +3%，单任务成本 ×2.5」不是提升，是交易。

4. 落地节奏

1. 第 1 周：收集 30 个真实 case，手写判据，先用规则断言 + 人工评分跑通流程。
2. 第 2-4 周：给开放型输出配 LLM 裁判，并用 50 条人工标注校准它。
3. 之后：eval 进 CI——每次改 prompt、换模型、动 scaffold，自动跑一轮，分数变化进 PR 描述。
4. 每季度：轮换题目、复核裁判一致率、重估成本基线。

六、Eval 驱动的开发流程

有了私有 eval，开发方式会发生质变：从「改了感觉更好」变成「每次改动都是一次有对照的实验」。

         ┌──────────────┐
         │  线上失败日志  │
         └──────┬───────┘
                ▼
        失败归因（看 trace）        ←── 可观测性打底
                │
                ▼
     新失败模式？ ──是──► 固化成 eval 任务（先进集，再修 bug）
                │否
                ▼
        改 prompt / 工具 / scaffold
                │
                ▼
        跑 eval（多次采样 + 配对比较）
                │
        ┌───────┴────────┐
      显著变好          没变或变差
        │                  │
        ▼                  ▼
     上线灰度           回滚，看轨迹找原因
        │
        ▼
  线上指标确认（L4），新失败回流到第一步

两个关键纪律：一是先进集、再修复——新发现的失败模式先写成 eval 任务并确认它会失败，然后再动手修，这样你就拥有了一个永久的回归测试；二是任何「优化」都要过 eval 闸门，包括换更贵的模型。这套流程的完整操作细节（工具链、CI 集成、评审清单）在实战中的 Eval一页展开，这里只立框架。想把它写进简历或面试答案的，可以对照求职知识地图里「评测与可靠性」这一栏。

七、警惕：Benchmark 刷分与真实能力的脱节

最后泼一盆冷水。2025-2026 年 benchmark 的可信度危机是公开的话题，几个结构性原因值得每个读榜单的人记住：

• 污染是常态而非例外。SWE-bench 公开于 2023 年底，之后发布的模型大概率在训练语料里见过这些 issue 和修复。SWE-bench Pro 用 copyleft 仓库和私有集来对抗，恰恰说明默认假设应该是「已被污染」。当 OpenAI 自己在 2026 年 2 月宣布弃用 Verified，这个行业信号再明确不过。
• Scaffold 即分数。前面 GAIA 的 43 分差距不是孤例。厂商发榜时用的是自家精心调过的 scaffold、最高的 reasoning effort、最多的重试预算——你拿到同一个模型裸 API，跑不出那个数字。榜单测的是「模型 + 脚手架 + 预算」的联合系统，而宣传时只说模型。
• 饱和速度超过benchmark 迭代速度。SWE-bench Verified 从 2024 年的个位数涨到 2025 年底的 76%+ 只用了一年多；τ-bench 老域、BrowseComp 也在复现同样的曲线。一个 benchmark 的平均寿命在缩短，「登顶」的营销价值大于信息量。
• 榜单任务 ≠ 你的任务。SWE-bench 的 issue 是维护者写清楚、社区讨论过、有测试覆盖的优质样本；你面对的可能是一句话需求、祖传代码和没有测试的仓库。分布差异直接吃掉泛化能力。

务实的应对策略只有三条：把公开榜单当初筛而非决策依据（分数接近时，选便宜、快、生态好的，而不是第一名）；把决策权重压在你自己的私有 eval 上；对任何「登顶 XX 榜单」的宣传，先问三个问题——什么 scaffold、多少预算、有没有第三方复现。

一句话总结

公开 benchmark 告诉你模型的上限在哪，私有 eval 告诉你产品的下限在哪。做 agent 的人，两头都要看，但只有后者是你的护城河。

参考资料

• Demystifying Evals for AI Agents — Anthropic Engineering —— 2026 年 1 月发布，agent eval 的工程方法论，本文分层框架的主要参照。
• Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena（arXiv:2306.05685） —— LLM 裁判偏差分类的奠基论文，位置/冗长/自恋偏差即出自此文。
• SWE-bench 官方榜单 —— Verified 等各子集的官方 resolve rate。
• SWE-bench Pro 榜单与方法论（Scale AI） —— 反污染设计、公开/私有/held-out 三集结构。
• Why SWE-bench Verified no longer measures frontier coding capabilities — OpenAI —— 头部实验室公开弃用一个饱和 benchmark 的始末。
• HAL: GAIA Leaderboard（Princeton） —— 带成本维度和第三方复现验证的 GAIA 榜单，scaffold 影响的数据来源。
• Terminal-Bench 官方榜单 —— 含置信区间与单轮评测成本，本文 2.1 版数据经直接核实。
• OSWorld 官方网站 —— OSWorld-Verified 与 2.0 的发布说明和官方结果。
• τ²-bench 代码库（Sierra Research） —— 双控环境 benchmark 的官方实现与论文链接。