工具幻觉：LLM智能体的结构性盲区与闭世界防御

工具增强型大语言模型（LLM）智能体正在成为AI应用落地的主流形态——从函数调用到MCP（模型上下文协议），智能体通过调用外部工具完成复杂任务。但一篇新发布的arXiv论文《Closed-World Resolution Against Tool Hallucination in LLM Agents》揭示了一个被现有防御体系集体忽视的严重问题：工具幻觉（Tool Hallucination）。

智能体会调用根本不存在的工具，或传递任何schema都未声明的参数。这不是工具选择做得不够好，也不是工具安全没做到位，而是整个防御范式的一个结构性缺口。

为什么现有防御全部失效

目前针对工具调用的安全手段大致分两类：一是工具选择（selection），即帮智能体挑出正确的工具；二是门控（gating），即约束智能体对真实工具能做什么。论文一针见血地指出，这两类方法都建立在一个隐含前提之上——智能体发出的调用指向的是一个真实存在的工具。

而幻觉调用恰恰打破了这个前提。作者用一句话概括了这个盲区：一个幻觉出来的调用，从构造上就不是任何门控做出的决策，因此没有任何门控能够拒绝它。换句话说，如果工具压根不存在，那么保护真实工具的所有机制都无从下手。

论文由此得出一个关键论断：幻觉防御必须先于任何因果门控。这在架构层面为智能体安全体系补上了一环——你得先确认调用的是真东西，才谈得上约束它能干什么。

**因果门控（causal gating）**是指在智能体执行工具调用时，由一个独立的决策组件判断该调用是否合规、是否应被允许执行。典型实现包括：基于权限策略的过滤器、参数合规性验证器、以及调用频率限制等。这类机制的共同假设是"被审查的调用对象是真实存在的"——只有工具确实注册在系统中，门控才有检查其行为的逻辑锚点。幻觉调用绕过了这一前提：当模型凭空生成一个不存在的工具名称或参数时，门控组件找不到对应的策略条目，无法触发任何拒绝逻辑，调用要么静默失败，要么被传递给下游系统产生不可预期的副作用。这正是论文强调"防御必须先于因果门控"的架构动机。

五类工具幻觉与「解析梯级」

为了系统化地衡量这一问题，作者提出了工具幻觉的五分类法（H1–H5），涵盖从虚构工具到非法参数的不同形态。作为参考基线，他们设计了一个称为**解析梯级（Resolution Rung）**的机制：一个免训练、闭世界（closed-world）的解析器，核心逻辑相当朴素——注册表成员检查（registry membership）加签名检查（signature check）。

论文特别强调，这个解析器的价值不在于它计算了什么复杂内容，而在于它必须处在架构的哪个位置——即在因果门控之前。作者同时刻画了一个无法消除的残余问题（irreducible residue）：所谓「借用参数」——即那些在schema层面与合法调用完全无法区分的调用。这类边界情况揭示了纯结构检查的天然极限。

**闭世界假设（Closed-World Assumption, CWA）是逻辑与数据库领域的经典概念：凡是系统注册表中未明确声明存在的实体，一律视为不存在。与之对应的开世界假设（Open-World Assumption）**则允许未知实体的存在性悬而未决。传统LLM的生成机制天然是开世界的——模型从训练语料中泛化，可以自由构造从未见过的工具名称和参数组合。论文提出的闭世界解析器，正是将开世界的模型输出强制收敛到闭世界的注册表边界：任何不在注册表中的工具名或不在schema中的参数，均被判定为幻觉并拒绝执行。这种设计简单但在架构位置上不可或缺，其代价是无法处理"借用参数"这类在结构层面与合法调用无法区分的边界情况。

实测数据：模型规模不救场

论文的核心是一项测量与基准研究。研究者在两种调用界面下，对十个托管模型进行了测试，共测得322个真实幻觉案例。

几个数据点值得关注：

• 虚构工具调用高度集中在无约束的原始JSON界面上（34次 vs. 结构化界面的3次）。这说明调用界面的约束程度直接影响幻觉发生率。
• 模型规模帮不上忙——一个675B参数的大模型，其表现与7–8B的小模型不相上下。这打破了「越大越可靠」的直觉，说明工具幻觉是一个无法靠堆参数解决的结构性问题。

这一发现对工程实践的启示是：与其寄望于更强的基座模型自动规避幻觉，不如在系统架构层面引入显式的闭世界解析层。

MCP 场景下的新型幻觉面

研究进一步延伸到模型上下文协议（Model Context Protocol, MCP）。MCP允许将多个服务器合并进同一个命名空间，而这种合并本身就制造出单一注册表无法表达的幻觉面。

作者为此提出了第二套分类法（M1–M5）。在真实的MCP界面上，他们测得154个幻觉案例，其中不乏在单一注册表界面上表现「干净」的前沿模型。原因在于：命名空间碰撞（collisions）与遮蔽（shadowing）是合并操作的结构性副产品。当多个服务器的工具名称冲突或相互覆盖时，即便模型本身没错，系统层面也会产生歧义和幻觉。

这对当前火热的MCP生态是一个重要警示：随着越来越多的服务被聚合进统一入口，幻觉风险不是线性叠加，而是因为结构性合并而产生质变。

模型上下文协议（Model Context Protocol, MCP）是Anthropic于2024年提出的开放标准，旨在为LLM智能体提供统一的工具与数据源接入方式。其核心设计允许一个智能体同时连接多个MCP服务器，并将来自不同服务器的工具合并到同一个可调用命名空间中。这种聚合架构极大提升了智能体的能力覆盖范围，但也引入了命名空间碰撞问题：当两个服务器各自注册了同名工具时，合并后的注册表中只能保留一个，另一个被"遮蔽（shadowing）"。模型在推理时无法感知这种遮蔽，可能以为调用了服务器A的工具，实际执行的却是服务器B的同名工具，或反之。这种幻觉不源于模型能力不足，而是系统合并操作的结构性副产品，单靠提升模型质量无法消除。

HTB 基准：让防御方案可比较

为了推动这一方向的研究，作者发布了带版本管理的Hallucinated-Tools Benchmark（HTB）。其目标是让任何解析器方案都能在提交之间进行横向对比，建立起一个可复现、可累积的评测标准。

对于正在构建智能体系统的开发者与研究者而言，这篇论文的价值有三点：明确了工具幻觉是一个独立于选择和安全的结构性问题；给出了防御必须前置于门控的架构原则；并提供了可量化的基准与分类法。在智能体大规模落地的当下，这类底层安全研究的重要性只会越来越高。