pass^k 的敏感度账把「可靠性 ≠ 平均分」算得明明白白——单次 90% 的 Agent，pass^10 只剩约 35%，动钱场景必读。BFCL 的 AST 评估是全新的组件级手艺；结尾的选型框架表可以直接贴墙。
先修：a22（读基准·上）。两类人必读：做「一次失败就很贵」业务的（pass^k 那一节），以及正在挑参考基准的（选型表）。与 a22 连读，先上后下。
先合上原文在心里作答，再点开对照。全对 = 本篇真正通关。
pass@k（k 次至少成一次）回答「它能不能做到」（能力上限）；pass^k（k 次全部成功）回答「它稳不稳定地做到」（可靠性）。面向用户的「动钱」场景，pass^k 更要紧。
约 35%（0.9¹⁰）——可靠性对单次成功率极其敏感，要把 pass^10 拉到 90%，单次成功率得提到约 99%。
不执行工具也能精确验证调用对不对：解析成抽象语法树后按结构比对——参数顺序不同不误判，参数名写错、少传必填参数能精确揪出，还避免了真实执行的副作用。
上方为本站原创导读，下方为原文完整收录，便于对照阅读。
上一讲三个通用基准，主战场都在"端到端 × 任务完成"。这一讲我们看四个更专项的基准——它们各自死磕一类具体能力或场景，而且评分设计各有绝活。我们还是用"读基准四问"，但走得更快；这一讲的重头，是结尾那张选型框架：帮你回答"我的场景，到底该参考哪个"。
读之前先记住总原则：读基准是为了偷设计，不是追排名。这一讲你会偷到四样很不一样的好东西。
测什么 / 任务环境。τ-bench（Sierra 出品）盯的是最像真实客服的场景：工具-Agent-用户交互。它让一个 LLM 扮演用户，和被测 Agent 多轮对话；Agent 手里有该领域的 API 工具，还被塞了一份业务规则（policy）必须遵守。它覆盖两个域：零售（电商客服）和航空（订票与售后）。升级版 τ²-bench 又加了"电信客服"域（telecom，宽带、手机报障这类技术支持）这种双向控制场景——用户和 Agent 都能调工具，更接近真实的协同排障。
怎么评分——这里有它的绝活。除了常规的"任务有没有达成"，τ-bench 提出了一个特别值得你记住的指标：pass^k（读作 "pass power k"）。它衡量的不是平均成功率，而是——连续跑 k 次、一次都不失败的概率。这是个纯粹的"可靠性"指标。数据很扎心：当年的 gpt-4o 在这个基准上任务成功率本就 <50%，而 retail 域的 pass^8 还不到 25%——意思是连续 8 次不出错的概率低得吓人。
它长这样（示意）。零售域里，模拟用户说"我上周买的鞋子小了，想换大一码"。Agent 手上的 policy 可能写着"换货须在 30 天内且未穿着"。一个合格的 Agent，要先调工具查到订单日期、确认在窗口内，再走换货流程；要是用户的要求违反 policy（比如已经 40 天了），它必须守规矩拒绝，而不是为了讨好用户照办。而 τ-bench 判它守没守规矩，主要是间接的——违反 policy 往往会体现成"最终数据库状态不对"（比如给了不该退的款），于是通过查最终状态就能捕获，而不是逐条去核它的推理过程。
启示。τ-bench 把"多轮交互 + 守业务规则"这件最难自动化评测的事做成了基准，适合任何对话式、要遵守流程规范的 Agent 参考。而 pass^k 是它送给你的最大礼物。
测什么 / 任务环境。SWE-bench 测编码 Agent：给一个真实的 GitHub issue，让 Agent 改代码、提交补丁。
怎么评分。这是它最聪明的地方——execution-based：跑这个仓库自带的测试，全过就算解决。它白嫖了开源项目里现成的真实问题和现成的测试套件当 ground truth，几乎没有主观空间。
两个你必须知道的变体。全量之外，有 Lite（300 题，便宜快速）和 Verified（500 题）。Verified 尤其重要：它是请专业开发者人工筛过的子集，剔除了"描述含糊、测试太弱（会误判正确解）"的脏题。这件事直接说明——好基准要人工清洗。目前前沿模型在 Verified 上大致能到 54%–81%。
它长这样。拿一个真实仓库在某次修复之前的状态，配上那个 issue 的描述，把整个仓库交给 Agent。Agent 自己探索代码、定位 bug、改文件、提交补丁。然后评测去跑该 issue 对应的测试：补丁让原本失败的测试通过了、又没弄坏其他测试，才算"解决"。整个判定零主观——测试说了算。
启示。如果你的任务天然带可执行的验收标准（代码、能跑的脚本），SWE-bench 的思路就是金标准：别自己造判定，去借任务自带的测试。
测什么 / 任务环境。BFCL（伯克利函数调用榜，Gorilla 团队）专测一件事：函数 / 工具调用调得对不对。它把这件事拆得很细——单个调用、多个调用、并行调用、并行多调用；还分 Non-Live（静态题）/ Live（真实用户提交的题），新版还加入了多轮的 agentic 场景。
怎么评分——又一个绝活：AST 评估。它不一定真去执行工具，而是把 Agent 生成的调用解析成抽象语法树（AST），和期望的调用结构做比对——函数名对不对、参数对不对、类型对不对。这套方法的好处是不依赖真实执行就能精确判对错，还能轻松扩展到上千个函数。当然它也有 Execute 类，对需要真跑的题用执行来验。
AST 评估长这样。期望调用是 bookflight(from="SFO", to="JFK", date="2026-05-01")，而 Agent 生成了 bookflight(to="JFK", from="SFO", date="2026-05-01")。直接比字符串会判"不一致"（参数顺序不同），但解析成抽象语法树再比对——函数名一致、三个参数的名字和取值都对得上、类型也对——判通过。这种"看结构不看字面"的宽容，正是 AST 评估的价值；它也能反过来精确地揪出"参数名写错了""少传了一个必填参数"这类问题。
启示。BFCL 是"组件级 × 工具调用"的显微镜。AST 评估这招特别实用：当你只想查"这一步工具调用本身对不对"、又不想真触发副作用时，解析调用结构来比对，就够了。
测什么 / 任务环境。OSWorld 测的是电脑操作（computer-use）——让多模态 Agent 在真实的桌面和 Web 应用里干活。它有 369 个任务，覆盖真实软件、操作系统文件读写、以及跨多个应用的工作流。每个任务都配了详细的初始状态设置和一个定制的、基于执行的评测脚本。
怎么评分。和 WebArena 一脉相承——execution-based，验任务最终有没有真的达成（用那个定制脚本检查环境最终状态）。区别是 WebArena 在浏览器里，OSWorld 把考场扩到了整台操作系统。
它长这样（示意）。一个任务可能是："把这个文件夹里的所有 .csv 合并成一个 Excel，并在桌面上建个指向它的快捷方式。" Agent 要在真实桌面里打开文件管理器、调用表格软件、跨应用操作。任务自带的执行脚本会在结束后逐项检查：那个 Excel 生成了吗、内容合并对了吗、快捷方式建好了吗——全对才算成。
启示。它是 computer-use 类 Agent 的范本。如果你的 Agent 要跨应用操作（不只是网页），OSWorld 的"初始状态 + 执行脚本验最终状态"的搭法，就是你要学的结构。
它们的共性，仍是那套"读基准四问"能套进去的结构。看到新基准别慌，按四问拆就行。
我把 τ-bench 的 pass^k 单拎出来，因为它纠正了一个普遍的认知误区。
大多数人看基准，盯的是平均成功率：100 次里成了 70 次，70%，听起来不错。但对很多真实业务，这个数字会骗你。设想一个退款 Agent，平均成功率 90% 听着挺好——可如果它是"随机地" 10 次里崩 1 次，那意味着每 10 个真实用户里，就有 1 个被它搞砸。在"一次失败就很贵"的场景（动钱、医疗、法务），你要的不是"平均还行"，而是"几乎从不出错"。
算一笔账你就懂了。假设单次成功率 p = 90%（听起来很高）。如果每次成败大致独立，那么连续 5 次全成的概率 pass^5 = 0.9⁵ ≈ 59%，连续 10 次 pass^10 = 0.9¹⁰ ≈ 35%。换句话说，一个"90 分"的 Agent，让它连做 10 单，有近三分之二的概率中途至少崩一次。要把 pass^10 拉到 90%，单次成功率得提到约 99%。
| 单次成功率 p | pass^5 | pass^10 |
|---|---|---|
| 90% | ≈59% | ≈35% |
| 95% | ≈77% | ≈60% |
| 99% | ≈95% | ≈90% |
可靠性对单次成功率极其敏感——这就是为什么"动钱"的场景，要死磕那最后几个 9。平均分从 90 提到 95 看着只多 5 分，可靠性却天差地别。
这两个数能讲出完全不同的故事：一个 Agent 可以平均分很高，pass^k 却很低——能力够，但飘。选指标，要看你的业务能不能容忍偶发失败。这个"可靠性 vs 平均水平"的区分，是评测统计严谨性的核心母题之一，也再次坐实了——对 Agent，单次结果是轶事，分布（尤其是分布的下限）才是证据。
把上一讲和这一讲的基准放在一起，按你的 Agent 类型给一张速查表：
| 你的 Agent 是… | 优先参考 | 主要偷的设计 |
|---|---|---|
| 通用助手（有唯一答案的问答） | GAIA | 难度分级 + exact match |
| 想横向比模型的通用底子 | AgentBench | 多环境测泛化 |
| 对话式客服 / 要守业务流程 | τ-bench | 用户模拟 + policy 约束 + pass^k |
| 编码 / 有可执行验收标准 | SWE-bench（Verified） | 借现成测试当 ground truth + 人工清洗 |
| 终端 / 命令行 / 运维 | Terminal-Bench | Docker 环境 + 测试脚本验最终状态 |
| 纯函数 / 工具调用 | BFCL | AST 评估（不执行也能验调用） |
| 网页操作 | WebArena | execution-based 验最终状态 |
| 跨应用 / 桌面操作 | OSWorld | 初始状态 + 执行脚本验 outcome |
| 企业工作流 / 知识工作 | WorkArena、TheAgentCompany | 真实业务流程任务 |
再给三条选型原则，比记住具体某个榜更重要：
这一讲我们拆了四个专项基准，每个都有一手值得偷的绝活：τ-bench（多轮交互 + 守 policy + pass^k 可靠性指标）、SWE-bench（借真实 issue 和现成测试做 execution-based 评分，Verified 是人工清洗的典范）、BFCL（函数调用显微镜，AST 评估不执行也能精确验调用）、OSWorld（把考场搬进整台电脑，execution-based 验跨应用 outcome）。加上一张选型表和三条原则，你以后挑参考基准就有谱了。而 pass^k 那一节——可靠性不等于平均分——是本讲最该带走的方法论。