2026年的工具使用能力评测已分裂成两套截然不同的话语体系：榜单上"前沿模型整体过线87%"的乐观叙事，与 pass^k 一致性指标下"前沿模型跑8次只有2次稳定成功"的悲观现实。本文沿着 Berkeley 函数调用评测（BFCL，v1→v4）与 Sierra 的 τ-bench 系列三代演进主线，拆解评测维度如何从"单次调用的 AST 参数匹配"演进到"多轮 API 状态验证"，再到 τ²-bench 的 dual-control 共享环境（Dec-POMDP）与 τ³-bench 的 τ-Knowledge 检索压测。核心结论：能力上限与可靠性下限是两个独立维度，能跑通和稳定跑通之间的鸿沟，正是 2026 年 Agent 工程化的主战场。
| 维度 | BFCL（v1→v4） | τ-bench | τ²-bench | τ³-bench（2026） |
|---|---|---|---|---|
| 出品方 | UC Berkeley Gorilla | Sierra Research | Sierra/Barres等 | Sierra |
| 评测核心 | 函数调用正确性 | 多轮客服任务完成 | dual-control协调 | +大知识库检索 |
| 关键指标 | AST/可执行准确率 | 任务完成率、pass^k | 协调成功率 | 知识检索+任务 |
| 环境模型 | 静态API | 单控制（agent用工具） | 双控制（Dec-POMDP） | 双控制+知识库 |
| 领域 | 通用API池 | 零售、航空 | 电信 | 电信+知识 |
| 负向维度 | Relevance Detection | 策略合规 | 用户对抗 | 知识冲突 |
| 可靠性维度 | 单次 | pass^k | pass^k | pass^k |
BFCL 早期版本（v1/v2）的判分逻辑建立在抽象语法树（AST）匹配之上——把模型输出的函数调用解析成参数键值对，与标准答案集合做列表匹配。这种方式的致命缺陷在于：它只验证"参数对不对"，不验证"调用后世界状态对不对"。一个典型的漏网场景是 delete_file(path) 被判对，只要 path 参数正确，哪怕模型把不该删的文件删了。BFCL v3 引入可执行评估是一次范式跃迁：不再解剖参数对，而是在模型跑完函数链后，直接检查文件系统或预订系统的实际状态。这与"工具调用格式债归零"中讨论的格式正确≠语义正确一脉相承——可执行评估把判分标准从语法层抬到了语义层。
# BFCL v3 可执行评估的核心转变：从参数匹配到状态断言
# 旧范式（AST）：只看参数键值对
def eval_ast(model_call, gold_args):
return set(model_call.args.items()) <= set(gold_args.items())
# 新范式（Executable）：检查真实系统状态
def eval_executable(env, task):
# 任务: "删除 temp 目录下的所有 .log 文件"
remaining_logs = env.fs.glob("temp/*.log")
assert len(remaining_logs) == 0, f"未删除: {remaining_logs}"
# 还要确认没误删 non-log 文件
assert env.fs.exists("temp/report.txt"), "误删了非目标文件"
return True
可执行评估的代价是基准建设成本飙升——每个测试用例需要一个可复现的环境（mock 文件系统、预订系统、数据库快照）。这也是 BFCL 数据集规模始终远小于 ToolBench 的根本原因：质量约束换不掉。
工具使用能力评测最容易被忽略、却最致命的维度是"不调用"。BFCL 引入 Relevance Detection（相关性检测）专项：在工具池里混入与用户请求无关的工具，测试模型能否克制住"找一个最像的函数硬调"的冲动。这直接戳中生产环境的真实痛点——一个总爱多调一次工具的 Agent，比偶尔调错的 Agent 危险得多，因为多余的调用会触发副作用、消耗成本、污染状态。
负向能力的评测难度远高于正向。正向评测有明确的黄金答案，对就是对；负向评测要穷举"所有合理的不调用方式"，而模型的拒绝理由千差万别。BFCL 的处理是把 Relevance Detection 做成二元判断（该调用/不该调用），用人工标注保证质量。这与"百工具选择塌方与检索增强实测"中揭示的工具选择压力形成对照：工具越多，模型"硬调一个最像的"倾向越强，Relevance Detection 分数下滑越明显。从训练数据偏置看，模型在 SFT 阶段被喂了大量"调用成功"的正例，几乎没见过"正确的不调用"，这是结构性缺陷。
BFCL v3 的多轮（multi-turn）与多步（multi-step）函数调用专项，揭露了一个单轮评测根本看不到的病灶：循环病。官方博客明确指出，只有进入多轮多步评测，才会看到模型"反复列出目录、尝试写一个不存在的文件、再列出目录"的死循环，或者"明明已经登录在浏览别人帖子，却反复索要用户名密码"。这些行为在单轮评测里不会暴露，因为单轮根本不构成循环的条件。
死循环的根因是模型缺乏终止条件感知。在每一步都倾向于"再做点什么"的训练偏好下，模型不会主动判断"我已经做完了"。这与"Agent终止逻辑：早停与死循环四态实测"的四态分析高度吻合——多轮评测本质上是在给模型的终止逻辑施加压力测试。BFCL v3 的贡献不在于发现了循环病，而在于把它量化进了榜单：一个单轮分数 90+ 的模型，多轮分数可能直接掉到 60 以下，分差本身就是工程化价值的提示。
τ-bench 引入的 pass^k 指标是 2026 年评测最重要的概念创新之一。传统准确率只看"能不能跑通一次"（pass^1），而 pass^k 看"独立跑 k 次能全部通过的比例"。二者的差距触目惊心：有实测数据显示，GPT-4o 在 τ-bench retail 上 pass^1 表现尚可，但 pass^8（跑8次全过）通过率跌破25%。这意味着同一个任务、同一个模型、同样的输入，约四分之三的概率会跑出不同的轨迹和结局。
# pass^k 的本质：从"能跑通"到"稳定跑通"
import numpy as np
def pass_at_k(trajectories, k):
# trajectories: 每个任务独立跑 N 次的成功/失败序列
# pass^k = 至少连续 k 次全成功的任务比例（最严格）
# 工程上常用 1-(1-p)^k 期望或组合数估计
n = len(trajectories)
successes = sum(1 for t in trajectories if all(t[:k]))
return successes / n
# 典型塌方曲线（能力vs可靠性解耦）
# pass^1 = 0.72 -> 看起来很强
# pass^4 = 0.31 -> 一致性塌方
# pass^8 = 0.18 -> 生产环境不可用红线
pass^k 揭示的核心洞察是：能力上限与可靠性下限是两个解耦的维度。一个 pass^1 高、pass^k 低的模型，是典型的"演示型 Agent"——demo 漂亮但上不了线。可靠性塌方的根因是模型决策的随机性（temperature、采样、上下文窗口里的微小扰动）在多步轨迹里被指数级放大。这也是为何"自主Agent静默漂移"会成为一个独立工程课题：可靠性不是调几个 prompt 能解决的，需要从采样策略、状态机约束、确定性内核多个层面兜底。
τ²-bench（arxiv 2506.07982）把评测环境从"单控制"升级到"双控制"，这是对真实客服场景的关键修正。在 τ-bench 里，只有 Agent 能用工具改世界，用户只是被动信息提供者；但真实技术支持场景中，用户也会主动操作——你让用户重启路由器、插拔SIM卡、在手机上点某个设置项，用户的行为本身也在改写共享世界状态。τ²-bench 把这种"双方都用工具、状态共享且动态演化"的场景建模为 Dec-POMDP（去中心化部分可观察马尔可夫决策过程）。
Dec-POMDP 的难度跃升在于：Agent 不仅要规划自己的工具序列，还要预测和协调用户的行为。一个典型的 telecom 场景是 Agent 引导用户在手机端关闭5G开关——Agent 调用 check_device_status，用户调用 toggle_setting，两个动作交织在共享状态机上。这把评测从"单智能体规划"推向了"人机协调"，直接连接到"多智能体心智理论：对方建模破局"——dual-control 本质上是要求 Agent 对用户建模。τ²-bench 四大贡献中的"组合式任务生成器"（compositional task generator）正是为了规模化生成这种复杂的协调任务。
τ²-bench 选择 telecom（电信客服）作为 dual-control 的首发领域，并非偶然。电信技术支持是 dual-control 的天然温床：故障排查需要用户在物理设备上配合操作（重启、插拔、切换网络模式），而这些操作的真实结果只有用户执行后才知道，Agent 无法直接观测。共享世界状态的不可见性，正是 POMDP 中"部分可观察"的体现——Agent 必须基于用户的口语反馈推断设备实际状态。
telecom 领域的协调红线体现在三个层面：一是政策合规（用户套餐、合约限制、漫游规则）与工具调用的耦合；二是用户配合度的不确定性（用户可能操作错误、报告错误、半途放弃）；三是长链条诊断（信号问题→SIM问题→基站问题→套餐问题）的分支决策。这与"自主SRE智能体爆炸半径实测"形成领域呼应——telecom 客服 Agent 的爆炸半径同样受 dual-control 放大：一个错误引导可能让用户误操作触发更大故障。telecom leaderboard 上 pass^k 的塌方曲线比 retail/airline 更陡，正是因为协调复杂度更高。
2026年初 Sierra 推出的 τ³-bench，在 dual-control 之上叠加了 τ-Knowledge 维度——测试 Agent 在大型内部知识库（政策文档、产品手册、历史工单）上的检索能力。这直接回应了一个生产现实：客服 Agent 的工具调用正确率再高，如果它从知识库里捞错了政策条款，依然会给用户错误答案。τ-Knowledge 把"检索增强"从一个独立的 RAG 评测项，缝合进了端到端的工具使用轨迹里。
τ-Knowledge 揭示的盲区是知识冲突与时效性。当知识库里有新旧两版政策、当用户引用的是过期条款、当工具返回的实时数据与知识库静态文档矛盾时，Agent 必须做出正确的取舍决策。这与"工具调用上下文工程"四栈中的"上下文污染"问题同源——知识库内容也是上下文的一部分，错误的知识上下文会让工具调用在正确的前提下得出错误结论。τ³-bench 的价值在于：它把"会不会调工具"和"调工具时脑子里装的知识对不对"绑在一起评，这才是真实 Agent 的完整能力画像。
把上述三代基准的覆盖范围拼起来，依然存在四个基准基本不碰的盲区，它们恰是生产事故的高发地。第一是成本维度：没有一个主流基准把"完成任务的token成本/工具调用次数"作为扣分项，于是榜单鼓励的是"多调几次保平安"的冗余策略，与生产成本约束背道而驰。第二是延迟维度：pass^k 衡量可靠性但不衡量首字节延迟与端到端时延，而语音客服场景里延迟就是失败。第三是安全副作用维度：可执行评估检查目标状态，但不检查"为了达到目标是否触发了不该有的副作用"（如多删了文件、多发了通知），这与"工具投毒"和"行为合约"的安全红线直接相关。第四是长尾分布：基准的任务是人工/合成均衡分布，但生产流量是长尾的，基准 87% 的整体过线率可能在生产长尾上骤降到 50%。
flowchart TB
subgraph G1["第一代：单次调用正确性"]
A1[BFCL v1/v2<br/>AST参数匹配]
A2[维度: simple/multiple/parallel]
A3[判分: 参数对不对]
end
subgraph G2["第二代：多轮状态验证"]
B1[BFCL v3 多轮多步<br/>+可执行评估]
B2[τ-bench: 任务完成率]
B3[判分: 世界状态对不对]
B4[新增: Relevance Detection<br/>死循环检测]
end
subgraph G3["第三代：一致性与协调"]
C1[pass^k 可靠性指标]
C2[τ²-bench dual-control<br/>Dec-POMDP共享环境]
C3[τ³-bench τ-Knowledge<br/>大知识库检索]
C4[判分: 稳不稳定+能不能协调]
end
G1 -->|范式跃迁| G2 -->|可靠性转向| G3
subgraph BLIND["基准盲区 黑洞"]
D1[成本/调用次数]
D2[延迟红线]
D3[安全副作用]
D4[生产长尾分布]
end
G3 -.不覆盖.-> BLIND
quadrantChart
title Agent工具使用能力-可靠性矩阵
x-axis "低可靠性 pass^k低" --> "高可靠性 pass^k高"
y-axis "低能力 pass^1低" --> "高能力 pass^1高"
quadrant-1 "生产可部署区"
quadrant-2 "不稳定但能力强<br/>需确定性内核兜底"
quadrant-3 "重写区"
quadrant-4 "稳定但能力弱<br/>窄场景可用"
"演示型Agent": [0.25, 0.8]
"生产级Agent": [0.8, 0.82]
"玩具Agent": [0.7, 0.3]
"待淘汰": [0.2, 0.25]
场景一：模型选型与横向对比。 选 BFCL v4 榜单做初筛，重点看 Relevance Detection 和 multi-turn 两个子项的分差——分差小的模型更稳健。BFCL 适合回答"哪个模型调用工具的基本功更扎实"。
场景二：客服/运维 Agent 上线前验收。 必须跑 τ-bench 或 τ²-bench 的 pass^k（至少 pass^4），而非只看 pass^1。pass^k 低于 0.5 的模型不具备上线条件，需引入确定性内核或状态机约束兜底。涉及用户配合操作的场景（电信、IT支持）优先用 τ²-bench telecom。
场景三：知识密集型 Agent 验收。 选 τ³-bench τ-Knowledge，验证 Agent 在工具调用正确的同时能否从知识库捞出正确条款，特别测知识冲突与时效矛盾场景。
场景四：自建评测集。 不要只搬运公开基准，必须叠加四大盲区的自评项：成本（每次任务的token/调用数）、延迟（P95端到端时延）、副作用（目标外的状态变更审计）、长尾（用生产日志采样构造边缘案例）。公开基准保下限，自建盲区评测保上限。
工具使用能力评测的三代演进，本质是从"测单点"到"测轨迹"再到"测稳定性与协调"的不断逼近真实。BFCL 解决了"参数对不对"，τ-bench 解决了"任务成不成"，pass^k 解决了"稳不稳"，τ²-bench 解决了"能不能协调"，τ³-bench 解决了"知识对不对"。但成本、延迟、副作用、长尾四大盲区仍是公开基准的真空地带。记住一条铁律：榜单上的 pass^1 永远比生产环境的真实可用性乐观一个数量级，pass^k 才是工程化的真实门槛。
本文由「51学通信」原创整理，站长爱卫生（微信：gprshome201101）持续追踪 AI Agent 与通信前沿。更多 5G/6G 核心网与智能体工程化深度内容，欢迎关注「51学通信」。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。