在最近的 arXiv 预印本 (2609.03966v1) 中，作者指出，传统的工具调用率统计往往只读取服务栈的输出，而忽略了模型实际发出的合法调用。由于接口在下游看到之前就对轨迹进行了审查，导致统计值可能为零，即使模型已经生成了完整的调用指令。
实验在 BFCL v4 数据上进行，保持权重、案例、解码方式和随机种子不变，仅替换服务适配器。结果显示，同一模型在不同适配器下的得分分别为 0.00 与 0.96/0.19。通过 2×2 的聊天模板与解析器实验，发现所有影响都来源于接口交互本身——没有单独的组件出现缺陷，修复合同的一方也无法提升整体性能。
在 tau‑bench 的 115 项交互式零售任务中，同样的适配器替换使得服务器解析到的调用次数从 0 上升到 636，实际触发工具执行的任务数从 0 增至 103。进一步在 Qwen2.5‑Coder 系列（规模 0.2B‑32B）上复现了该现象：服务器始终解析不到调用（0/100），而模型发出的合法调用在 32B 时可达 80/100（校准后约 72/100）。
在 Llama‑3.1‑8B 上，原始模型有 23% 的调用直接指向任务函数本身，但在加入 strict:true 标志后该比例降至 0。该不匹配甚至渗透到训练循环中：在 verl 的 AgentLoop 中，7B 参数模型在 115 次生成中有 45 次完整调用，但全部被拒绝、未执行、也未返回观察；在 1.5B 参数模型中同样出现零接受的情况。
评估阶段，修复适配器可以恢复解析机制，但对整体通过率提升不显著（解析 0‑84，恢复 0‑9，最终通过率 53‑62，统计上不显著）。作者提供了一个 98 行的预检脚本，可捕获所有静默失败。
结论：工具调用率并非模型本身的属性，而是模型‑接口堆栈的综合度量。
点评