你的 AI agent 刚刚完成了一项复杂的数据库迁移任务。它调用了正确的工具，使用了恰当的术语，引用了正确的库，并返回了看起来完全合理的输出。然后你的 DBA 在一个拥有 5000 万行的生产表上运行它 —— 结果备份标志（backup flag）写错了。这个标志存在于相邻的库版本中，语法上是有效的，但它在静默状态下没有执行备份步骤。
这个 agent 并不是在胡言乱语。它表现得自信、流畅且方向正确。但在操作上，它错得正是会导致数据丢失的那种方式。
这是该领域投入不足的一种幻觉类别，也是你的评估（evals）几乎肯定无法捕捉到的那种。
两种错误
当从业者谈论 LLM 幻觉时，通常指的是两种情况之一。第一种是纯粹的虚构：模型发明了一个统计数据，引用了一篇不存在的论文，或者生成了一个在现实中毫无根据的命名实体。这是那种会被写进论文或在主题演讲中演示的失败模式。
第二种则更为隐蔽，在生产环境中也更糟糕：模型了解正确的领域，选择了正确的工具，调用了正确的概念 —— 但在操作性的关键细节上出错。这种错误在方向上是合理的，但在操作上是失效的。
称之为操作性幻觉 (operational hallucination) ：模型的输出能通过表面层面的正确性检查，并能通过大多数事实性评估，但在针对真实系统实际执行时却会失败。
这种区分很重要，因为这两种失败模式有着不同的成因、不同的检测策略以及不同的后果。事实性幻觉通常会表现得很明显 —— 编造的引用是可以追溯的，虚构的统计数据会被搜索结果反驳。而操作性幻觉则是静默失败的：代码运行没有错误，API 调用返回 200，备份显示完成 —— 直到它在某个时刻出问题，且很难追溯回模型。
问题的形态
操作性幻觉通常归为几个反复出现的类别。了解这些分类有助于你决定在哪里部署监控。
错误的参数实例 。模型知道正确的 API，调用了正确的方法，但使用了看似合理但错误的参数值。例如，系统要求 DD/MM/YYYY，但指定的日期格式为 YYYY-MM-DD。或者当有效值为 "true" 时，将标志设为 "enabled"。如果你的 schema 比较宽松，这些能通过 schema 验证；如果验证层在下游，它们会静默失败；而且通过阅读输出来检测它们几乎是不可能的。
过时的方法签名 。训练数据包含了多个库版本的文档。模型自信地调用 requests.get(url, verify=False, timeout=30, proxies=proxy_dict) —— 但在你环境所锁定的版本中，proxies 不是位置关键字。或者它针对不支持该版本的 Node 环境调用了较新 JS 规范中的 array.toSorted()。一切看起来都对，但错误是时间维度上的，而非概念上的。
概念正确，实例错误 。模型理解你需要配置重试策略，选择了适当的 SDK 方法，但将配置应用到了错误的堆栈层级 —— 比如应用到了 HTTP 客户端而不是应用层的重试处理器。代码编译通过，测试通过，但重试在关键点上静默地失效了。
工具使用中的虚构 。当给定部分或模糊的工具规范时，模型会虚构出听起来很正确的参数名称。一个名为 send_notification 的工具被调用时带有一个 spec 中并不存在的 recipient_email 字段 —— 因为模型推理出邮件通知需要一个接收者，且这个名称听起来很合理。如果你的工具处理逻辑没有根据 schema 严格验证输入，这就会通过。
为什么评估体系会遗漏它
这是令人不安的部分。大多数团队运行的评估流水线在结构上对操作性幻觉是视而不见的。原因如下。
标准的事实性基准测试衡量输出是否匹配参考答案或是否与已知的训练数据矛盾。操作正确性需要一个不同的“先验知识”（oracle）：你需要知道实际 的 API 规范、当前 的库版本、具体的 运行时环境。这些知识通常不在基准测试中。
语义一致性检查 —— 询问模型的回答是否自相矛盾或与上下文矛盾 —— 在这里甚至更没用。错误的参数标志与模型被告知的一切在语义上都是一致的。没有任何矛盾可以被检测到。
最近基准测试工作的数据使这一点更加具体。AgentHallu 基准测试（2026 年 1 月）评估了 13 个领先模型在多步 agent 轨迹中的幻觉归因。整体步骤定位准确率最高仅为 41.1%。特别是对于工具使用步骤 —— 与操作性幻觉最相关的类别 —— 归因准确率下降到了 11.6% 。即使是运行在专门为探测这种失败模式而设计的任务上的顶级模型，也无法可靠地识别出 agent 轨迹中哪里发生了操作性错误。
同时， 42% 部署了基于 LLM 的 agent 的团队报告称，在发布后的三个月内发生了与幻觉相关的生产事故。这些事故中有很大一部分并不是“模型编造了某些东西” —— 而是“模型以错误的方式做了正确的事情”。
检测鸿沟 许多团队将其作为可扩展评估策略的 LLM 作为裁判 (LLM-as-judge) 流水线，自身也存在操作性幻觉问题。最近的一项分析发现，LLM 作为裁判报告的幻觉中，有 42% 实际上是流水线故障——速率限制、格式错误的输入、不完整的追踪。与此同时，工具调用中实际发生的操作性幻觉却被误分类为正确输出，因为裁判读取的是意图，而非执行结果。你正在用一把由相同材料制成的尺子来测量你的测量工具。
语义熵探测 (Semantic entropy probes) 提供了一种更规范的方法。这些方法量化了生成内容 意义 上的不确定性——而不仅仅是 Token 概率——并标记出模型内部表示在各种可能的完成结果中方差较高的输出。错误的 API 标志通常会在周围上下文中产生较高的语义熵，因为模型正在它在训练中见过的多个可能的规范之间进行插值。语义熵可以在执行前以近乎零的开销发现这一点（2024 年关于语义熵探测的《自然》杂志论文证明了其延迟成本几乎可以忽略不计）。
静态分析是另一个杠杆，它确实有效，但效果有限。关于代码库幻觉的实证研究发现，静态分析能捕捉到 16% 到 85% 的库级错误，具体取决于模型和数据集。那个高端数字听起来很鼓舞人心；而 16% 的低端数字更能代表实际情况。静态分析会告诉你你安装的库中是否存在该方法，但它不会告诉你参数值对于你特定的运行时配置在操作上是否错误。
真正有帮助的模式 鉴于检测鸿沟的存在，实际的问题是：你到底能做些什么？
根据实时规范校准工具定义。 针对 API 幻觉，最高杠杆的干预措施是直接从目标 API 的 OpenAPI/Swagger 规范生成工具 Schema，而不是手动编写或根据文档推导。手写的工具描述包含的陈旧信息与模型在训练中已经掌握的信息是一样的。实时规范生成可以揭示模型认为的与 API 实际接受的之间的差异——在模型产生这种偏差的幻觉之前。
在绑定层而非输出层进行验证。 大多数团队在事后验证模型输出——审查响应，检查追踪。更有效的模式是在工具调用绑定层进行严格的 Schema 验证：如果任何参数与规范不完全匹配，工具调用在执行前就会因结构化错误而失败。这将静默的操作故障转化为响亮的、可追溯的错误。这也意味着你的评估 (Evals) 现在可以捕捉到这类故障，因为你有了可以进行评估的故障信号。
在提示词中构建版本感知上下文。 当模型运行在具有固定库版本或特定 API 版本的环境中时，该信息需要在系统提示词中明确说明，并附上准确的版本字符串。“使用 boto3” 会产生版本模糊的输出；“使用 boto3==1.34.0 —— 仅参考此版本中可用的方法” 则为模型提供了一个锚点。这不能消除陈旧签名的幻觉，但通过缩小模型的插值目标，可以显著减少它们。
将功能性评估与操作性评估分开。 大多数团队运行一套评估组件来检查智能体是否实现了目标。增加第二类专门针对操作正确性的评估：工具调用是否与预期的 Schema 完全匹配？参数值是否在当前环境的有效范围内？这些评估需要了解参数级别的正确答案，这意味着它们更难编写——但它们也是唯一能在投入生产前捕捉到这种失效模式的评估。
为高风险工具调用增加沙箱执行步骤。 对于影响持久化状态的工具调用——数据库写入、API 变更、文件系统操作——先运行一次沙箱化的空运行 (Dry-run)，并检查执行追踪，而不仅仅是模型输出。沙箱追踪会暴露任何语义检查都无法捕捉到的参数错误。这增加了延迟；但对于不可逆的操作，这种权衡通常是值得的。
置信度问题 操作性幻觉之所以特别危险，是因为它与基于置信度的方法的可检测性呈负相关。当模型不确定时，它会采取回避态度。当它在其训练数据中的两个可能的库版本之间进行插值，并自信地确定其中一个时，它会以极高的确定性输出该结果。它自信生成的标志在它见过的 某个 版本的世界中是正确的。只是它碰巧不是你正在运行的那个版本。
这是侧重于真实性的研究在结构上难以解决的失效模式。真实性有时可以通过查找来验证；而操作正确性则需要执行。该领域正朝着正确的方向发展——像 AgentHallu 和 HalluLens 这样的基准测试专门设计用于暴露这些故障——但学术测量与部署的检测工具之间的差距仍然很大。
对于现在构建生产级智能体的团队来说，这意味着防御性架构：工具边界处的严格 Schema 验证、提示词中固定版本的上下文、高风险调用的沙箱执行，以及将参数级正确性视为一等指标（而非功能正确性的假设结果）的评估套件。模型在大方向上会是正确的。你的工作是让“方向正确但操作错误”的失败表现得足够响亮，以便你在用户发现之前就能捕捉到它。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
