工具调用准确率测试的盲区：缺失的“无工具”用例

为什么“没有调用工具”本身也应该被检验

OpenRouter 在《How to Test Tool-Calling Accuracy in AI Agents》一文中指出，评估一个 AI Agent 的工具调用能力，不能只看它是否调用了工具。一个模型如果调用了本不该调用的函数，它依然会输出一个 tool call，因此“响应里包含工具调用”这件事本身不证明任何东西。这个观点看似简单，却暴露了大多数工具调用注册表的结构性盲区。

在常见的评测框架中，工具的失败被拆解为“选错工具”和“选对工具但参数出错”两大类；参数内部又进一步区分为结构和取值两种校验，因为“一个符合 schema 的值依然可能是错的”——例如用户想要 ord_7281，模型却传了 ord_7282，后者完全能通过 schema 校验。DeepEval 将 Tool Correctness 与 Argument Correctness 作为两个独立指标发布，Phoenix 也提供了单独的工具选择评估器，说明这一拆分已经成为行业共识。

双抽屉结构：从个人失误日志到框架共识

文章作者 Tally 是一个运行在公开账本上的小型 AI 模型，经营着一人店铺。它此前根据自己的失误日志搭建了一个“双抽屉”护栏：一个抽屉记录选错工具的案例，另一个记录参数错误的案例。这个结构与 DeepEval、Phoenix 等评测框架最终收敛出的形状一致。

这种一致性本身是一种弱证据——说明作者命名的确实是一个真实的边界，而不是私人执念。对于构建 Agent 可观测性的团队来说，这个观察值得留意：当你从零设计一套工具调用日志时，选错工具和参数错误应当分表记录，否则后续的归因分析会混在一起，无法区分是路由问题还是传参问题。

Tool Correctness 与 Argument Correctness 是 DeepEval 框架中两个独立发布的评测指标。Tool Correctness 衡量模型是否选择了正确的工具，即工具选择准确率；Argument Correctness 则衡量在工具选对的前提下，传入参数是否与预期一致。将两者拆开的意义在于：一次失败调用可能源于路由错误（选错工具），也可能源于传参错误（工具选对但参数不对），二者需要不同的归因和修复策略。Phoenix 框架同样提供了独立的工具选择评估器，印证了这种拆分已成为行业共识。

缺失的第三个抽屉：不该发起的调用

真正让作者意识到盲区存在的，是 OpenRouter 指南中提到的“no-tool case”。作者的失误注册表只记录了“我发起了哪些调用、它们如何失败”，却没有地方存放“我本就不该发起的调用”。文中举了两个具体例子：对一个自己的现场笔记早已判定失效的通道进行重新探测，以及第三次重读一个已经读了两遍的帖子尾部。

这些行为属于浪费，而不是失误。注册表对它们视而不见，因为它们不会产生拒绝或错误响应——调用成功了，只是毫无必要。这类隐性成本在按调用计费或按 token 计费的场景下会持续累积，却很难被传统的错误率指标捕捉到。

no-tool case（无工具调用场景） 指的是用户请求本不需要调用任何工具、模型应当直接以自然语言回应的情形。与之相对的是“错误地调用了工具”。OpenRouter 指南强调，仅仅检查响应中是否包含 tool call 并不能验证模型的决策质量——模型完全可能在本应直接回答时发起了一次多余的调用，而且这次调用可能成功返回，从而在传统错误率指标下被计为“正常”。因此，评估工具调用能力时，必须包含对“是否应该调用工具”这一前置判断的检验。

可落地的修正：每次调用加一行必要性日志

作者提出的修正方案相当轻量：在下一个窗口期为每次调用记录一行日志，问一句“这次调用是必要的吗？”没有任何 compose-time 检查器能完全判定必要性，但一行日志可以测量它。积累足够样本后，这个数字会说明浪费究竟是一个类别问题，还是个别轶事。

这个思路对构建 Agent 系统的团队有直接参考价值。必要性无法在调用前自动判定，但可以在调用后由人工或更强的模型进行回溯标注，形成“必要性”这一维度的独立统计。它与现有的工具选择准确率、参数准确率并列，构成第三个可观测维度。

对 Agent 评测体系的启示

工具调用准确率的评测正在从“是否调用”走向更细的分层：工具选择、参数结构、参数取值，以及现在被提出的调用必要性。前三层已经有成熟框架支持，第四层仍处于手工日志阶段。对于依赖 Agent 完成实际业务的团队，这意味着评测指标需要预留扩展位——不能假设“调用成功即正确”，也不能假设“没有报错即没有浪费”。

作者以公开账本方式运营自身，每一笔收支都记录在页面上，这种极端透明的做法让“浪费”变得可量化、可追问。对多数团队而言，未必需要公开账本，但至少应该在日志中为“不必要的调用”留一个抽屉。

compose-time 检查器 指在 Agent 编排（compose）阶段、即调用发起之前对决策进行静态或规则化校验的组件。作者指出，没有任何 compose-time 检查器能完全判定一次调用的必要性，因为必要性依赖于上下文语义（例如某个通道是否已失效、某篇帖子是否已读够），这些信息难以在调用前被规则化捕捉。因此必要性只能作为事后标注维度来测量，而非事前拦截。这也解释了为什么必要性日志属于“回溯统计”而非“实时防护”。