# 选对≠调对：工具调用参数塌方 2026年的函数调用排行榜有一个共同的毛病：它们把"模型选对了哪个函数"当成了一件值得庆祝的事。Berkeley 的 BFCL v3 整体准确率已被前沿模型推到 87% 上下，单轮 AST 评分更是常年 90% 以上，看起来工具调用已经"解决"了。但当 57% 上线了 Agent 的企业报告函数调用在生产中失败时（bcloud 2026 调研），这条 87% 的曲线无法解释任何一次真实事故。本文的论点很简单：**工具调用评测被困在了"选择层"这个虚荣指标里，而真实失败几乎全部发生在选择层之下——参数层、一致性层、端态层与步骤层**。把评测下沉到这四层，才能解释为什么"看起来调对了"的 Agent 仍然在烧钱。 ## 评测层级对比 | 基准/方法 | 评测层级 | 是否评参数真值 | 一致性(pass^k) | 步骤归因 | 端态校验 | 主要盲区 | |---|---|---|---|---|---|---| | BFCL v3 (Gorilla/Berkeley) | 选择层+执行层 | 部分(exec acc) | ✗ | ✗ | ✗ | 单轮AST虚高，掩盖参数与一致性 | | τ-bench / τ²-bench (Sierra) | 端态层 | 间接(数据库残差) | ✓ pass^k | ✗ | ✓ | 不暴露中间步骤幻觉 | | AgentHallu | 步骤归因层 | ✗ | ✗ | ✓ 41.1% | ✗ | 不评能力上限，只评归因 | | Internal-Rep (Amazon, AAAI'26) | 内部表征层 | ✗ | ✗ | 隐式 | ✗ | 仅探测，不修复 | | StructFlowBench (ACL'25) | 结构流层 | ✗ | ✗ | 部分 | ✗ | 限定指令遵循，不评工具执行 | | tool-eval-bench | 选择+参数分层 | ✓ 分离评分 | ✗ | ✗ | ✗ | 场景规模小(69例) | ## 一、指标错位：为什么"选对函数"成了虚荣指标 BFCL 的 AST 评分本质上是字符串匹配：模型输出的函数名是否等于标注函数名，参数键名是否齐全。这个口径对**单轮、无副作用、参数可枚举**的场景是公允的，于是它在排行榜上贡献了一个漂亮的天花板。问题在于，选择层恰恰是工具调用里**错误率最低**的一环——当一个函数叫 `cancel_order`、另一个叫 `get_order`，且 schema 描述写得清楚时，前沿模型几乎不会选错。 真正的事故不在这里。BFCL v3 自己新增的 **relevance detection**（相关性检测）子项已经承认了这点：它反向测试"模型是否会被无关函数诱惑去乱调"。这条子项的得分普遍低于整体 5–10 个百分点，说明一旦工具列表里混入干扰项，"选对"这件事立刻就打折。更关键的是 **execution accuracy**（执行准确率）与 AST 的差距：AST 满分的调用，真正跑起来返回正确结果的会掉一截，这一截就是"选对了但没调对"的损失。把 AST 当主指标发布，等于只汇报了整条链路里最不容易出错的那一环。结论：**任何只汇报选择层得分的榜单，都是在用天花板伪装地板。** ## 二、参数层塌方：实体消解与枚举幻觉 选择层之后的第一道深渊是参数。这里有两类系统性失败。第一类是**实体消解（entity resolution）**：用户说"把昨天那个会议改到下午"，模型必须把"昨天那个会议"映射到一个具体的 `event_id`。这个映射在单轮基准里几乎不存在，因为基准的输入里直接给了 ID。真实对话里，模型要么编一个不存在的 ID，要么复用上一轮错误的 ID。 第二类是**枚举幻觉**：参数 schema 声明 `status` 只能取 `["active","inactive"]`，模型却生成了 `"archived"`。planoai 的熵检测实验和 dev.to 的"3 Patterns That Fix LLM API Calling"都指向同一个根因——模型在解码参数值时并没有真正"查询"枚举集合，而是在做概率续写。 `tool-eval-bench`（SeraphimSerapis）的价值正在于此：它用 69 个确定性场景把"是否选对工具"和"是否传对参数"**分开打分**，于是参数层塌方第一次被显式暴露。下面是一段最小可行的参数闸门，把选择层与参数层的损失切开： ```python def safe_tool_call(call, registry): fn = registry.get(call.name) if not fn: return {"error": "selection_miss", "stage": "selection"} # 1) 枚举约束：把 schema 当硬约束，而不是建议 for arg, spec in fn.params.items(): if spec.get("enum") and call.args.get(arg) not in spec["enum"]: return {"error": "enum_hallucination", "arg": arg, "got": call.args.get(arg), "stage": "parameter"} # 2) 实体消解校验：引用型ID必须能在上下文里溯源 for ref in fn.requires_resolution: if not resolvable(call.args[ref], call.context): return {"error": "entity_unresolved", "arg": ref, "stage": "parameter"} return fn.invoke(call.args) # 到这一步才真正"调对" ``` 这段代码的真正用处不是修 bug，而是**给评测提供一个分层标签**：每一次失败都被打上 `selection` 或 `parameter` 的 stage，这样你才能在内部报表里画出"我们的参数层准确率只有 62%"这种排行榜永远不会显示的数字。 ## 三、一致性塌方：pass^k 拆穿"偶发正确" τ-bench 引入的 **pass^k** 是 2026 年最被低估的指标。它的定义是：同一个任务跑 k 次，**全部成功**的概率。这等价于单次成功率 $p$ 的 $k$ 次方 $p^k$。这个数学性质冷酷得近乎残忍——当 $p=0.7$，$p^8 \approx 0.058$，也就是不到 6%。 callsphere 与 benchmarkingagents 的实测数据印证了这点：在 τ-bench retail 上，**前沿模型（含 GPT-4o）在 pass^8 下跌破 25%**，而 pass^1 也仅徘徊在 70% 以下。airline 域更难，因为它的策略更复杂、对话更长。这条曲线的潜台词是：**能力（capability）和可靠性（reliability）是两件事**。一个 pass^1=70% 的 Agent，在生产里被用户反复触发同一类任务时，暴露事故是迟早的——因为用户感知到的是"它有时候很蠢"，而这"有时候"在 k 次方下被急剧放大。 ```mermaid flowchart LR A[单次成功率 p=0.7] --> B["pass^1 ≈ 70%
能力看上去够用"] B --> C["pass^4 ≈ 24%
同一用户触发4次后"] C --> D["pass^8 ≈ 5.8%
可靠性坍塌区"] D --> E[生产事故] style D fill:#f4cccc style E fill:#f4cccc ``` 这就是为什么 BFCL 的单次得分无法指导生产：它测的是 $p$，而生产关心的是 $p^k$。任何严肃的 Agent 团队都应该把 pass^k（哪怕只到 pass^4）写进内部回归，而不是盯着榜单的 pass^1。 ## 四、端态评测：τ-bench 看的是数据库残差 τ-bench 之所以能压出 pass^k 这种残酷曲线，是因为它的评分口径和 BFCL 完全不同：**它不评判"调用序列对不对"，而是评判"对话结束后数据库的状态对不对"**。一个客服任务结束时，系统比对：该退的款退了吗？该改的航班改了吗？不该动的订单被动过吗？ 这个口径带来了两件事。第一是**策略遵守（policy adherence）**：每个域都写了一份策略文档（用户策略 + 业务策略），Agent 必须在两者冲突时做出正确裁决——比如用户要退不可退票，Agent 不能因为"用户说了"就退。τ²-bench 把这一层做成了可测的维度。第二是**airline 比 retail 难**的实证：retail 的工具大多是 CRUD，airline 涉及复杂的退款规则、舱位升降、积分抵扣，参数依赖更深。 这也解释了为什么 τ-bench 是当前最接近生产的基准：它把"调对工具"重新定义为"达成正确的世界状态"，而不是"输出了正确的函数名"。但它的盲区同样明显——**它不暴露中间步骤**。一个任务端态对了，可能中间走了五步弯路、调了三次冗余工具、甚至基于一个幻觉参数"歪打正着"。端态对，不代表过程对。这就引出了下一层。 ## 五、中间步骤幻觉不可定位：AgentHallu 的 41.1% AgentHallu（arXiv 2601.06818）填补了"端态对但过程错"的盲区，它的任务是**步骤级幻觉归因**：在一条多步轨迹里，到底是哪一步产生了幻觉？结果令人不安——**最强模型的步骤定位准确率只有 41.1%**，且工具调用类幻觉集中在中间步骤而非首尾。 这个数字的含义需要 unpack。它不是说"模型 41% 的时候在幻觉"——它是说，即便是用来**评判**别人轨迹的强模型，也只有 41% 的概率能准确指出"哪一步开始错了"。也就是说，我们目前**连自动定位工具幻觉的能力都还没过半**。在生产里这直接表现为：一个长程 Agent 在第 7 步调错了一个参数，但日志、监控、甚至 LLM-as-Judge 都很难把它和第 7 步关联起来，回滚和修复因此变成手工活。 AgentHallu 的方法论价值在于它把评测从"二元成败"升级为"归因图谱"：每一次失败不再是 0/1，而是一个带位置的有向误差。这才是长程 Agent 调试真正需要的评测形态。但 41.1% 也意味着，这套归因机制目前还只能作为**辅助信号**，不能作为可信的自动化裁决。 ## 六、内部表征诚实性：模型的最后一层比它的输出更可靠 如果外部裁判（LLM-as-Judge）只有 41.1% 的归因能力，那有没有可能"模型自己"更知道它在哪里幻觉？Amazon 在 AAAI 2026 的工作（arXiv 2601.05214）给出了肯定回答：**工具选择的幻觉，在模型自己的最后一层隐藏状态里是有迹可循的**。 它的突破点是**单 pass 检测**。传统幻觉检测要么需要多次采样看一致性（self-consistency），要么需要外部检索做事实核对，成本都和推理次数成正比。而这篇工作训练一个轻量探针，只读模型**已经在计算**的最后一层激活，就能在 token 生成的同时给出"这次工具调用大概率为幻觉"的概率，无需额外前向传播。planoai 的熵方法（VarEntropy）从另一个侧面佐证：模型在编造参数值时，token 分布的熵会异常升高，这是一个几乎零成本的旁路信号。 ```python # 内部表征 + 熵 双通道幻觉探测（示意） def halluc_probe(hidden_state_last, logits, call): p_probe = probe(hidden_state_last) # 训练好的线性探针 ent = entropy(logits) # 输出分布熵 var_ent = var_entropy_over_tokens(call.ctx) # 参数token方差熵 # 探针说是幻觉 且 熵也偏高 → 高置信拦截 if p_probe > 0.5 and (ent > T1 or var_ent > T2): return GATE_HALT # 阻断本次工具调用，触发重试/降级 return GATE_PASS ``` 这是评测范式的一次转向：**从"看模型的输出"到"看模型的激活"**。它把幻觉检测的延迟从"事后裁判"压到"同步门控"，使得在线拦截幻觉参数成为可能。局限是探针与模型强绑定、跨模型迁移性差，且只能探测"模型内部不确定"的那类幻觉，对"模型高度自信地错"无能为力。 ## 七、结构流盲区：StructFlowBench 的第二个维度 前六层都聚焦"单次调用的对错"，而 StructFlowBench（ACL 2025，arXiv 2502.14494）补上了被所有人忽视的**轮间结构依赖**。它定义了六种基本的轮间关系——跟进、修正、回溯、前提、分支、终止——并把它们建模成多轮指令的"控制流"。 它的核心洞察是：**多轮指令遵循不仅是"每一轮都对"，还存在一个结构维度**。用户在第二轮说"还是按刚才那个改吧"，这句话的正确执行依赖于第一轮是否真的建立了一个可回指的状态。一旦结构依赖被破坏（比如第一轮的调用其实失败了但 Agent 没发现），后续每一轮都会建立在错误前提上，形成"逐轮累积偏移"。 实测显示，模型在涉及**修正**与**回溯**这两类结构依赖时，准确率会出现断崖式下降——而这恰恰是真实客服对话里最常见的两类（用户改主意、用户纠正）。BFCL v3 的 multi-turn 子项虽然也测多轮，但它的"多轮"更多是"多次独立调用"的拼接，而非带控制流依赖的轨迹。StructFlowBench 的贡献是把"多轮"从一个数量词升级为一个**拓扑结构**，让评测能区分"会调很多次工具"和"会在多轮间维持正确状态"。 ## 八、落地方案：分层评测与可信调用闸门 把上面七层拼起来，2026 年一个可工程化的工具调用评测栈应该是分层的，每一层都有自己的指标和止损手段： ```mermaid flowchart TB subgraph Cap[能力层 — 排行榜关心] L1[选择层 AST准确率] L2[参数层 真值/枚举/实体消解] end subgraph Rel[可靠性层 — 生产关心] L3[一致性 pass^k] L4[端态 数据库残差+策略遵守] end subgraph Diag[诊断层 — 调试关心] L5[步骤归因 AgentHallu式] L6[内部表征 探针+熵门控] end subgraph Flow[结构层] L7[结构流 轮间依赖] end L1 --> L2 --> L3 --> L4 --> L5 --> L6 L7 -.横切.-> L4 style L1 fill:#d9ead3 style L3 fill:#f4cccc style L5 fill:#f4cccc ``` 落地时，能力层用 BFCL 做基线即可，但内部报表必须把参数层（用 tool-eval-bench 式的分离评分）单独画出。可靠性层强制引入 pass^4 以上的回归，并在 τ-bench/τ²-bench 的零售或航空域上跑端态。诊断层把 AgentHallu 式的步骤归因作为离线分析工具，配合内部表征探针 + 熵门控做在线拦截。结构层用 StructFlowBench 的轮间关系做回归集，专门盯"修正/回溯"两类易塌方场景。 变现与训练营维度上，这套分层栈是天然的产品骨架：**"参数层准确率从 62% 提到 85%"** 这种可量化承诺，远比"我们的 Agent 用了 GPT-5"有说服力；面向企业的 Agent 可靠性训练营，可以用 pass^k 的实战压测作为结业标准——能在 pass^4 下保持 60% 以上的学员才算过关。 ## 推荐方案 | 场景 | 主基准 | 关键指标 | 必配闸门 | |---|---|---|---| | 选型/横向对比模型 | BFCL v3 | exec accuracy（非AST） | — | | 客服/交易类生产 Agent | τ²-bench | pass^4 + 端态残差 | 策略遵守裁决 | | 长程研究/运维 Agent | AgentHallu式轨迹归因 | 步骤定位 + 中间步幻觉率 | 探针+熵门控在线拦截 | | 多轮对话产品 | StructFlowBench | 修正/回溯类准确率 | 状态回指校验 | | 工具密集型(MCP/百工具) | tool-eval-bench + BFCL multi-turn | 选择层与参数层分离分 | 枚举/实体硬约束 | ## 参考来源 1. [τ-bench: A Benchmark for Tool-Agent-User Interaction (arXiv 2406.12045)](https://arxiv.org/abs/2406.12045) — 提出 pass^k 一致性指标与数据库端态评分方法。 2. [Tool-Use Reliability in 2026: What pass^k on tau-bench Tells Us (callsphere)](https://callsphere.ai/blog/vw1g-tool-use-reliability-tau-bench-pass-k-2026) — GPT-4o 在 τ-bench retail pass^8 下跌破 25% 的实测分析。 3. [AgentHallu: Benchmarking Automated Hallucination Attribution of LLM-based Agents (arXiv 2601.06818)](https://arxiv.org/abs/2601.06818) — 步骤级幻觉归因，最强模型定位准确率 41.1%。 4. [Internal Representations as Indicators of Hallucinations in Agent Tool Selection (arXiv 2601.05214, AAAI 2026)](https://arxiv.org/abs/2601.05214) — 单 pass 最后一层隐藏状态检测工具选择幻觉。 5. [StructFlowBench: A Structured Flow Benchmark for Multi-turn Instruction Following (arXiv 2502.14494, ACL 2025)](https://arxiv.org/abs/2502.14494) — 六种轮间结构依赖与控制流评测维度。 6. [BFCL V3: Multi-turn & Multi-step Function Calling (Gorilla, UC Berkeley)](https://gorilla.cs.berkeley.edu/blogs/13_bfcl_v3_multi_turn.html) — relevance detection 与 execution accuracy 指标定义。 > [!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 等场景全覆盖。