工具调用四维评测：停对是真断层

2026 年 6 月，Berkeley 函数调用榜单（BFCL）演进到 V4，Sierra 的 τ²-bench 也迭代到 τ³-bench。把这两套权威评测的原始分数摊开看，会得到一个反直觉的结论：工具调用能力从来不是"能调用"和"不能调用"的二元问题，而是选对、填对、用对、停对四个维度严重分化的能力剖面。前沿模型单工具准确率已经摸到 95–96% 的天花板，但参数错误一项就吃掉六到七成的失败；工具数突破 20 后准确率断崖式跌到 65–78%；多步调用复合误差把 90% 的单步准确率在五步内压到 59%；而最被忽视的"停对"——即在应当拒答、应当反问、应当用自然语言直接回答时不去触发工具——才是 BFCL V4 新增 abstention 任务暴露出的真正断层。

一、四维评测框架：为什么"能调用"不等于"能用好"

过去两年，几乎所有"我们的 Agent 支持工具调用"的宣传都建立在同一个误解上：把"会发起一次 function call"等同于"工具使用能力达标"。BFCL V1/V2 时代的 AST 评测强化了这种错觉——只要语法对、参数齐、能执行就算通过。但 V3 引入多轮与并行调用、V4 引入网页检索、跨会话记忆与相关性/无关性检测（abstention）后，评测面被撑开成四道独立的考题：

这四维之间的分化远比总分剧烈。BFCL V4 的核心贡献，就是把"停对"从隐含指标变成了显式题型——结果证明，这是区分"演示级 Agent"与"生产级 Agent"最锋利的那把刀。

二、填对：参数错误吃掉七成失败，是头号病灶

Presenc AI 基于 60+ 企业客户的部署埋点与公开评测报告，给出了失败模式的拆解。在规模化场景下，参数相关错误合计占 74%，远超"选错工具"：

失败类型	占比	典型表现
参数不匹配	~38%	工具选对，但字段名或取值错误
类型强转错误	~24%	期望 integer 却传 string
选错工具	~18%	在候选集中选了语义相近但错误的工具
缺失必填参数	~12%	调用时漏掉必填项
幻觉工具名	~5%	调用了根本不在工具集里的函数
其他（格式/Schema 违例）	~3%	序列化、嵌套结构错误

这张表的真正含义是：即便你用最好的模型、配最规整的 schema，绝大多数翻车都发生在"已经选对工具、却没填对参数"这一步。这意味着任何把工具可靠性全部押在模型身上的架构都是脆弱的。生产级解法是程序化参数校验先行——类型校验、范围检查、schema 强约束，在工具真正执行前拦截掉这 60%+ 的参数类失败，而不是寄希望于模型自觉。Outlines、JSON Schema constrained decoding、Instructor 这类约束解码库在 2026 年的普及，本质就是在补这一刀。

三、选对：工具数破 20 即塌方，单工具准确率是假象

BFCL v3 榜单（2026 年 5 月快照）按工具数量分桶测准确率，暴露出一条陡峭的衰减曲线：

模型	单工具	5 工具	20+ 工具	多轮
Claude Opus 4.7	96%	91%	76%	83%
GPT-5 Pro	95%	90%	74%	81%
Claude Sonnet 4.6	94%	88%	71%	78%
Gemini 2.5 Pro	93%	87%	69%	76%
GPT-5	93%	86%	68%	75%
Qwen 3 235B	91%	84%	62%	71%
Llama 4 405B	90%	82%	58%	68%
Qwen 3 32B	89%	82%	58%	67%
Llama 4 70B	87%	79%	54%	63%
DeepSeek V4	89%	81%	57%	66%

读这张表的方式不是看第一名，而是看列间差。Claude Opus 4.7 从单工具 96% 掉到 20+ 工具 76%，掉了 20 个点；Llama 4 70B 从 87% 掉到 54%，掉了 33 个点。这意味着同一个模型，在"工具箱越大、能力越弱"。开源模型与闭源前沿的差距在单工具时只有 5–12 个点，到 20+ 工具时被拉大到 10–22 个点——工具规模是放大模型差距的透镜。这也是为什么生产实践中那条铁律是"实用工具数上限封在 15–20"，超出后必须分层：先用一个路由模型（router LLM）从大工具池里召回 5–10 个相关工具，再交给执行模型在缩小的集合上操作。

四、用对：多步复合误差，90% 单步准确率五步只剩 59%

"用对"考验的是跨轮上下文的保持与调用结果的复用。BFCL V4 发现一个普遍病灶：当第 3 轮的工具输出要在第 8 轮被用来构造正确调用时，多数模型要么丢失上下文，要么臆造历史结果。客服入职、多步财务分析、长代码审查这类中间结果需要持久化的流程，最容易在这里崩。

更隐蔽的是复合误差的指数衰减。假设每次调用独立、单步准确率 90%：

调用次数	端到端成功率
1 次	90%
2 次	81%
3 次	73%
5 次	59%
10 次	35%

τ²-bench 从另一个角度印证了同一规律：95% 的单轮成功率，在 10 轮对话后只剩约 60%。任何把"单工具 96%"直接外推成"工作流 96%"的产品判断都是危险的。一个 5 步的供应商调研工作流，即便每步都有 90% 准确率，整体也只有 59% 能跑通——这意味着你的品牌或结果只能在那 59% 的成功路径里被呈现。缓解手段只有两个方向：一是减少串行步骤数（能并行就并行、能合并就合并），二是给每一步加重试带反馈——前沿模型在拿到失败信息后往往能自我纠正，不开重试的 Agent 会白白丢掉 8–15% 的完成率。

五、停对：BFCL V4 的 abstention 任务，才是真正的断层

这是四维里最被低估、却最具判别力的一项。BFCL V4 的新增测试包含相关性/无关性检测：模型必须识别出"当前没有任何一个工具能回答这个问题"，并选择自然语言作答、反问澄清，或干脆拒绝，而不是硬塞一个工具调用。结果令人警醒——即便是榜单头部的高分模型，也频繁在"本不该调用工具"时触发调用。

BFCL V4 的判别逻辑是：当一个 query 没有合法工具匹配时，正确的输出是自然语言回答而非 function call。但模型经过大量"工具优先"的后训练后，已经形成了调用偏置（invocation bias）——看到一个看似可操作的请求就条件反射式地发起调用。这会产生三类灾难：调用了语义相近但错误的工具（18% 的选错错误里有相当一部分源于此）、带着幻觉参数强行调用（38% 的参数错误）、在"信息已足够、直接作答即可"时还在重复检索。AgentMarketCap 的分析直接点名：SWE-bench 得 80% 的模型，照样可能在工具调用上"灾难性幻觉、传畸形参数、识别不出无合法工具答案"——这正是压垮生产 Agent 的失效模式，而 SWE-bench 单轮打补丁的任务结构根本测不到。

"停对"的工程意义在于它直接决定成本与延迟的天花板。一个不会停的 Agent，会把每一次冗余调用变成一次 API 计费 + 一次往返延迟 + 一次上下文膨胀。从这个角度，"停对"既是能力维度，也是上一轮"循环二次方烧钱"问题的根因之一——调用偏置不治，预算熔断只是表象。

六、框架级缓解：路由 + 校验 + 重试的三件套

flowchart TD
    U[用户请求] --> R{停对判断}
    R -->|自然语言即可回答| ANS[直接作答/反问]
    R -->|需要工具| RT[路由模型: 从大工具池召回 5-10 个]
    RT --> EX[执行模型: 在缩小集合上选对+填对]
    EX --> V{程序化参数校验<br/>类型/范围/schema}
    V -->|不通过| FB[失败信息回灌]
    V -->|通过| TC[执行工具]
    TC --> OK{成功?}
    OK -->|否| FB
    FB --> EX
    OK -->|是| USE[用对: 结果写入跨轮记忆]
    USE --> NEXT{还有未完成步骤?}
    NEXT -->|是| EX
    NEXT -->|否| DONE[任务完成]
    R -.停对失败: 本不该调用却调用.-> EX

第一件，路由分层：实用工具数封顶 15–20，超出就上 router 召回，把执行模型的"选对"难度从 N 降到 5–10。第二件，程序化校验先行：用 constrained decoding 与 schema 校验在执行前拦截掉那 60%+ 的参数类失败，不把可靠性外包给模型。第三件，重试带反馈：执行失败或校验失败时把结构化错误信息回灌给模型，前沿模型大多能一轮内自我纠正，这是白捡的 8–15% 完成率。这三件套分别对应"选对""填对""用对"的兜底，唯独"停对"目前没有成熟的开源组件——它需要在 Agent Loop 里显式植入一个"是否真的需要工具"的预判门，或者在提示词层强制模型先输出一个 need_tool: bool 的结构化判断。

七、τ²/τ³-bench：双控环境下的政策合规二次检验

如果说 BFCL 测的是"工具调用本身准不准"，τ-bench 系列测的是"在真实业务多轮对话里能不能把事办对且不违规"。τ²-bench 引入双控环境（dual-control）——Agent 和模拟用户都持有工具与控制权，模拟真实客服中双方都在改变系统状态的复杂博弈。2026 年的 τ³-bench 进一步加入 RAG 检索域与语音双工评测。它不仅检查任务是否完成，还检查 Agent 是否严格遵守公司政策（政策合规 + 工具调用双重判据）。

2026 年 4 月的分数展示了工具调用能力跃迁的体感：Claude 3.7 Sonnet 在 2024 年 τ-bench 上仅约 46%，到 Claude Opus 4.6 已达约 95%；GPT-5.2 Thinking 约 90%；Gemini 3.1 Pro 约 83%。两年间近 50 个点的跃升，是评测史上少见的幅度。但要注意 τ-bench 的饱和趋势：头部模型已到 95%+，判别力正在下降，区分前沿模型的能力正在被稀释——这也是为什么 2026 年业界越来越依赖 BFCL V4 的 abstention 与 τ³ 的新域来拉开差距。

八、变现与训练营评估

这套四维评测框架本身就是可以直接变现的资产。训练营方向，"工具调用能力评测"可以拆成一个三天的实战营：Day1 用 BFCL 自测工具跑通选填用停四维，让学员亲眼看到自己 Agent 在 20 工具时的塌方曲线；Day2 上三件套（路由 + 约束解码 + 重试），对比优化前后端到端成功率；Day3 用 τ²-bench 跑政策合规，体会"办对事但违规"的陷阱。这种基于真实榜单分数的、可量化的训练，比泛泛的"Agent 开发入门"贵得多也值得多。产品方向，"工具调用健康度看板"是一个真实缺口——大多数可观测后端只追踪 token 和延迟，却没有把"停对失败率""参数错误占比""选错工具分布"做成一等指标。谁能把 BFCL 的失败模式拆解做成生产级埋点中间件，谁就切进了 Agent 可观测赛道里目前空着的那块。

上手难度上，BFCL 与 τ²-bench 都是开源、可本地跑的，从 clone 到出第一份分数，熟悉 Python 的工程师半天内能完成；难点不在跑分，而在读懂分数背后的四维剖面并据此改架构。变现潜力中等偏上——它不缺受众（每个做 Agent 的团队都需要），缺的是把榜单语言翻译成工程语言的人。

推荐方案

追求选对/填对上限的场景（API 编排、RPA）：用闭源前沿模型 + constrained decoding + 15 工具封顶 + 路由分层，别在 20+ 工具的开放集合上裸跑。追求多轮可靠性的场景（客服、工单）：必须配重试带反馈与跨轮记忆持久化，单步 95% 不等于多轮 95%。追求停对/安全的场景（金融、医疗、合规咨询）：在 Agent Loop 前置一个显式的"是否需要工具"判断门，并强制模型在无合法工具时输出结构化拒答而非硬调用——这是 BFCL V4 abstention 任务给合规场景最直接的工程启示。预算受限的场景：开源模型在单工具上只落后 5–12 点，适合工具数 ≤10 的窄域任务；一旦超过 15 工具或多轮 ≥5 步，闭源前沿的成本节省会被复合误差吃光。

无论选哪条路，记住一句话：会调用工具是 2024 年的及格线，知道何时不调用、何时停，才是 2026 年的生产线。