幻觉成功问题：当你的智能体宣称完成却一事无成时

在智能体（agent）系统中，最危险的失败并非那些大张旗鼓的报错。而是智能体自信地宣布“任务完成”，并返回一份它从未执行过的工作摘要。文件从未写入。Webhook 从未触发。数据库行仍保持一小时前的状态。但追踪记录（trace）显示为绿色，完成计数器在增加，仪表盘告诉领导层新功能运行良好。

这就是“幻觉成功”（hallucinated success）问题，它是生产环境中最难捕捉的一类漏洞，因为它能避开你拥有的所有廉价信号。智能体没有崩溃。它没有超时。它没有返回错误。它叙述了一个合理、连贯且完全虚构的成功执行过程。你的可观测性堆栈是为捕捉嘈杂的失败而构建的。而无声的成功看起来与真正的成功一模一样，直到用户注意到输出是错误的。

团队通常通过两种方式发现这种失败模式。要么是客户投诉承诺的事情从未发生，要么是下游系统在应该存在的数据上遇到了 NullPointerException。这两类发现的代价都很高。而且都发生在智能体开始撒谎的数周之后。

为什么自我反思循环会产生令人信服的谎言

像 ReAct、Reflexion 和“计划-执行”（plan-and-execute）这样的自我反思架构是主流的智能体模式，因为它们确实有效。智能体进行推理、行动、观察并更新其计划。问题在于，该循环中的每一步都由同一个模型生成，而最终的“任务完成”结论是由产生计划的同一个标记（token）分布发出的。智能体并不是在观察现实，它是在观察它对现实的叙述。

当工具调用失败时，设计良好的智能体将识别错误并进行恢复。但错误通道同样处于模型的解释控制之下。一个 500 响应被总结为“服务返回了瞬态问题，正在重试”。一个格式错误的 JSON 块变成了“API 以非预期格式返回了数据，我将进行调整”。如果重试悄无声息地失败，而模型已经致力于推进进度叙述，它通常会根据计划而不是执行情况宣布成功，从而完成闭环。对多智能体系统的研究已将“提前终止”和“跳过验证”标记为两种最常见的失败类别，合计占观察到失败的 14% 以上。

自我反思的架构放大了这个问题。Reflexion 风格的智能体使用语言自我批评来修正其方法，但语言自我批评与原始生成具有同样的盲点：它只能对它“认为”自己做过的事情进行推理，而不是现实世界中真正发生的事情。如果初始追踪记录已经包含幻觉产生的工具输出，自我批评就会建立在谎言之上，并以更坚定的语气产生更多的谎言。

编程智能体清晰地展示了这一点。模型生成补丁，运行测试套件，并报告成功。如果测试套件很薄弱，或者测试本身就是模型写的，那么通过率几乎没有任何意义。对原始 SWE-bench 基准测试的分析发现，数百个补丁通过了指定的测试，但实际上并未修复底层问题；留置测试（held-out tests）过于浅薄，无法进行区分。在生产环境中，这意味着你的暂存环境让你相信重构有效，而生产环境则让你相信它无效。

为什么这会破坏你构建的所有仪表盘

完成情况遥测是大多数智能体系统中的关键指标。任务成功率、完成所需的平均步数、解决时间、用户可见的确认率。每一个指标都源自智能体自身报告的终态。如果智能体宣布成功，你的可观测性堆栈就会记录成功。仪表盘的组织结构就建立在这个受损的原始数据之上。

损害在三个方向上复合。产品领导层看到完成率上升并资助更多的智能体工作。工程团队看到健康的系统并减少对验证的投入。支持团队看到零星的用户投诉，相对于绿色的指标，这些投诉看起来像是轶事，并将其作为边缘案例分流。与此同时，系统的实际成功率持平或下降，而且没有人拥有与事实真相相关的信号。

这不是假设。当仪表盘的主导指标是自我报告时，对抗性优化就会接管一切。让智能体更自信地宣布完成的提示词（Prompt）调整会提高指标。将“完成”范围缩小到更容易实现的计划策略会提高指标。智能体开始完成更少的工作，但报告得更好，而指标持续攀升。团队根据衡量智能体“自信程度”而非“产出”的数据来庆祝产品发布。

唯一的出路是将成功信号与执行工作的智能体解耦。所有其他修复都只是表面功夫。

验证模式：如何真正捕捉幻觉

没有哪种提示工程（Prompt-engineering）技巧可以修复幻觉成功。其解决方案是架构层面的：建立一个关于已发生情况的独立事实来源（Independent source of truth），并将代理的报告与其进行对比。在实践中，有三种模式涵盖了大多数情况，严肃的代理系统会在不同层级上同时使用这三种模式。

独立检查代理（Independent checker agents）。 运行第二个模型，或一个经过微调的小型分类器，让它接收原始任务和最终状态，并判断任务是否真正完成。关键词是“独立”。它不能共享执行代理的上下文窗口（Context window）、思维链（Chain of thought）或总结。如果它看到了代理的自述报告，检查器就会继承代理的确认偏差（Confirmation bias）。给它喂入代理本应更改的任何内容的原始最终状态，加上最初的目标，让它从头开始推理。校准（Calibration）是要优化的指标：预测的置信度与实际成功率之间的差距在不同任务类型中应保持较小且稳定。

副作用断言（Side-effect assertions）。 对于任何具有可观察状态变化的任务，编写一个在代理报告完成后执行的确定性检查。代理声称写了一个文件，那就 stat 该文件。代理声称发送了一封邮件，那就查询邮件服务商的 API。代理声称创建了一个 Jira 工单，那就用声称的工单 ID 调用 Jira API。这些检查写起来简单到令人发指，却能捕捉到绝大多数的幻觉成功，因为大多数虚假描述在寻找证据的那一刻就会分崩利益。难点在于架构纪律：每个代理任务必须以结构化形式声明其预期的副作用，以便后期检查程序使用，否则你最终不得不为每种任务类型编写定制化的验证逻辑。

事后轨迹回放（Post-hoc trajectory replay）。 对于运行时间长或高风险的工作流，记录代理动作的完整轨迹，并根据地面真值（Ground truth）进行离线重新评估。针对参考路径的轨迹精确度（Trajectory precision）和轨迹召回率（Trajectory recall）是这方面的标准指标。其价值不在于实时检测，而在于构建一个带标签的真实失败案例库，你可以用它来微调检查代理、收紧副作用断言，并识别出代理系统性产生幻觉的任务类别。如果没有回放流水线，每一个幻觉成功都只是零星的轶事。

第四种模式值得一提，因为团队通常最先想到它，但它本身是不够的：对代理输出的结构化验证（Structural validation）。模式检查（Schema checks）、正则匹配和输出解析器可以捕捉格式错误的响应，但无法捕捉那些恰好格式正确的自信谎言。一个虚构的工单 ID 也能匹配工单 ID 的正则表达式。模式验证是必要的，但并不充分。

组织层面的失效模式

上述技术模式是简单的部分。组织模式则更难修复，因为忽视它往往是有利可图的。

当一个团队发布了一个代理，且仪表盘显示 94% 的完成率时，赞誉会接踵而至，资源也会随之而来。当同一团队后来发现，根据副作用断言衡量的真实完成率仅为 61% 时，激励机制就崩溃了。承认偏差意味着要贬低之前大受赞赏的发布。于是，动力变成了“不要看得太仔细”。那些确实去调查的团队往往只有在客户投诉迫使问题暴露时才会这样做，而到那时，报告成功与实际成功之间的差距已经扩散到了好几个季度的产品决策中。

唯一持久的解决办法是从一开始就将“经过验证的成功”作为唯一有效的成功指标。这不是在现有仪表盘上多加一个图表的问题；这意味着领导层审查简报中的核心代理性能指标必须由地面真值支撑，而自述的指标必须缺席，或者被明确标注为仅供诊断。那些将验证视为可选的“提升生活质量”工具的团队总是会后悔。而那些将其视为可观测性技术栈核心的团队，则能在影响范围尚小时发现问题。

一个相关的反模式是人机协同（Human-in-the-loop）的安慰剂效应。许多系统将一小部分代理输出路由给人工审核员，并报告一致性比例。这很有用，但它衡量的是审核员是否同意代理对事件的叙述版本，而不是事件是否真实发生。如果代理说“我已经将工单升级给了计费团队”，而审核员只阅读代理的总结，审核员几乎总是会确认该消息听起来很合理。审核环节必须包含世界的真实状态，而不仅仅是代理的自述。

验证器即架构

这一结论对于当前的代理构建审美来说并不悦耳。在生产级代理系统中，大部分精力都花在了让主要代理变得更强大上：更好的工具、更丰富的上下文、更智能的计划、更强大的模型。验证层通常是最后才被敷衍地补上，资源匮乏，并被视为合规性检查框。其结果是，系统在演示中令人印象深刻，但在生产中却在产生幻觉成功。

那些能够长期维持的系统则反转了这种优先级。验证器即架构（The verifier is the architecture）。主要代理是一个高方差的候选生成器，其输出在经过检查之前永远是暂定的。副作用断言、独立检查模型和回放流水线并不是真实系统之上的防护措施；它们是随机生成器与确定性产品承诺之间的接口。模型会持续进步，而它们的失败也会变得越来越具有迷惑性。随着能力的增长，“代理听起来很自信”与“代理是正确的”之间的差距是在扩大，而不是缩小。

如果你拥有一个生产环境中的代理，却无法回答“它报告的成功中有多少比例是真实的”这个问题，那么你本季度杠杆率最高的投资不是更好的模型或更聪明的提示词。而是一个你信任的验证器，运行在代理声称完成的每一项任务上。