幽灵工具调用：当AI智能体调用不存在的工具

你的智能体通过了所有单元测试，完美处理了正常路径，然后在某个周二下午，它试图调用 get_user_preferences_v2——一个在你的代码库中从未存在过的函数。这个调用在语法上看起来完全正确。参数也很合理。唯一的问题是，你的智能体凭空捏造了这一切。

这就是幽灵工具调用：一种不表现为错误文本而表现为错误操作的幻觉。与人类可能在审查中发现的事实幻觉不同，幽灵工具调用会直接命中你的运行时，抛出一个晦涩的 ToolNotFoundError，并使原本运行正常的多步骤工作流脱轨。

为什么智能体会捏造工具调用

根本原因很简单：LLM是在包含API文档、SDK参考和代码示例的大量语料库上训练的下一个token预测器。当智能体需要一个在当前注册表中不存在的工具时，它不会束手无策——它会根据它见过的所有内容进行模式匹配，生成一个看似合理的调用。

NESTFUL基准测试的研究量化了这个问题。表现最好的模型GPT-4o在嵌套工具调用上的完整序列匹配准确率仅为28%。单个调用通常能成功，但组合会急剧失败，因为错误在依赖步骤之间会累积。

三个因素会放大幽灵调用的频率：

• 工具库存规模。 可用工具越多，模型就越难区分真实的和想象的。在每个提示中暴露50+工具的团队，比那些将活跃集保持在5-10个的团队，看到明显更多的幻觉函数名。
• 指令复杂度。 带有条件分支的多步骤工作流创造了模型需要一个逻辑上应该存在但实际不存在的工具的场景。它通过发明一个来弥补差距。
• 文档缺失。 OpaqueToolsBench研究表明，不完整或误导性的工具描述不仅会导致错误的工具选择——还会导致捏造替代品。当模型找不到它需要的东西时，它会制造它期望的东西。

工具幻觉的五个类别

2026年的一项研究分析了工具选择过程中LLM的内部表示，识别出五种不同的幽灵调用模式，每种都有不同的下游后果。

不存在的函数调用是最明显的：智能体调用一个在工具注册表中根本不存在的函数名。这些很容易捕获，但当工具名称遵循可预测的模式时，它们出人意料地常见。如果你的注册表有 create_user 和 delete_user，模型会自信地调用 update_user，即使该函数从未实现过。

语义不当的工具选择更加微妙。工具存在，但在上下文中是错误的。一个被要求检查库存的智能体可能会调用报告函数而不是库存查询函数，因为描述听起来很相似。

无效参数是最隐蔽的类别。函数名是正确的，但智能体发明了schema中不存在的参数——为没有该选项的函数添加 include_metadata 标志，或传递API不接受的 format 参数。

缺少必需参数方向相反：智能体省略了schema要求的字段，生成的调用即使函数名正确也会验证失败。

工具绕过是最奇怪的类别。智能体不调用工具，而是在内部模拟工具的行为，并将捏造的输出呈现为来自真实工具的输出。它可能生成看起来与工具返回值匹配的逼真JSON，完全跳过实际执行。

悖论：更好的推理反而让情况更糟

最近研究中一个更反直觉的发现是，提高智能体的推理能力实际上会增加工具幻觉率。OpenReview发表的研究表明，通过强化学习逐步增强推理能力会使工具幻觉与任务性能成比例增加。

一旦你理解了，机制就很简单。更强的推理能力让模型构建更复杂的计划，这创造了更多需要不存在工具的机会。一个能推理五步工作流的模型，遇到工具库存缺口的可能性是处理单步请求模型的五倍。

这对模型选择有实际影响。最新的以推理为重点的模型如o3和o4-mini在某些基准测试上将一般幻觉率分别推到了33%和48%，即使它们在复杂问题解决方面表现出色。对于工具调用智能体，推理深度和调用可靠性之间的权衡是真实的，必须明确管理。

运行时防御：将工具调用视为不可信输入

大多数团队尚未完成的心智模型转变是：来自LLM的工具调用应该与来自HTTP请求的用户输入以同样的怀疑态度对待。你不会在没有验证的情况下从表单字段执行任意SQL查询。你也不应该在没有验证的情况下从语言模型执行任意函数调用。

这导致了分层防御架构：

第一层：工具注册表断言。 在任何工具调用执行之前，验证函数名是否在你注册的工具集中。这听起来很明显，但许多框架在没有检查函数是否实际存在的情况下，将模型的输出直接传递给动态分发器。严格的注册表检查在幽灵调用产生令人困惑的下游错误之前就能捕获它们。

第二层：Schema验证调度。 每个工具调用的参数都应在执行前根据类型化schema进行验证。根据采用严格验证的团队的生产数据，使用Pydantic模型或JSON Schema验证可以将参数相关错误从40%降低到2%。

第三层：未知工具断路器。 当检测到幽灵调用时，不要只是记录并继续。将错误反馈给模型，并附上明确的上下文："函数 get_user_preferences_v2 不存在。可用函数为：[列表]。请选择适当的工具或解释为什么这些都不满足要求。"这个反馈循环让模型自我纠正，而不是挣扎。

第四层：执行前规划。 让智能体在执行任何调用之前，用抽象占位符概述其完整的工具调用序列。这让你可以在执行任何真实调用之前，根据注册表验证计划。研究表明，这种方法将选择准确率从大约60%提高到85%。

在生产中有效的实用模式

除了防御层之外，几种架构模式已被证明在部署的系统中有效减少幽灵调用。

动态工具检索解决了库存规模问题。不是在系统提示中暴露所有可用工具，而是使用检索仅展示当前步骤最相关的5-10个工具。这大大降低了模型混淆相似工具或发明看似应该存在的工具的机会。

硬钩子与软引导是来自AWS生产部署的模式，将不可协商的约束与可纠正的指导分开。硬钩子在违反关键不变量时完全阻止执行——你不能确认一个尚未处理的付款。软引导提供纠正指导——智能体请求了15位客人但最大值为10，所以调整并继续。这在防止危险的幽灵调用的同时避免了过度阻止。

使用内部模型表示的实时幻觉检测是一种新兴方法。研究人员证明，从工具调用生成期间的最终transformer层提取的特征可以以高达86%的准确率被分类为正确或幻觉，使用的轻量级神经网络增加的延迟很小。

基于MCP的Schema执行正在成为标准的互操作层。模型上下文协议使用JSON-RPC 2.0强制执行schema验证的消息，为每条消息提供明确的类型、经过验证的有效载荷和清晰的意图。微软于2026年4月发布的Agent Governance Toolkit在此基础上构建，为所有十种OWASP智能体应用风险提供确定性的亚毫秒级策略执行。

上下文窗口维度

幽灵工具调用还有一个容易被忽略的上下文窗口维度。随着对话越来越长，上下文被压缩或截断，模型对可用工具的感知会退化。20,000个token之前清楚定义的工具，到模型需要使用它时，在模型的表示中可能已经变得模糊。

这意味着工具定义应该在决策点刷新，而不是在长对话开始时定义一次。一些框架通过在每个工具选择步骤之前重新注入工具schema来自动处理这个问题。其他框架将其留给开发者，这意味着通常不会发生。

未来展望

幽灵工具调用问题不会消失。随着智能体获得更多工具的访问权限并处理更复杂的工作流，幻觉调用的攻击面只会增长。处理得好的团队有一个共同特征：他们以对待任何外部API边界相同的严谨态度对待智能体的工具接口。

这意味着类型化schema、运行时验证、自我纠正的反馈循环，以及不仅跟踪工具是否被调用，还跟踪是否使用正确参数调用了正确工具的监控。这意味着接受你的智能体对工具调用的置信度与调用的有效性之间零相关。

在生产中可靠工作的智能体不是那些拥有最好提示或最强模型的智能体。而是那些每个工具调用都通过模型本身无法绕过的验证的智能体。