导语：传统大模型的幻觉，是“说错话”；Agent 的幻觉，是“做错事”。当模型开始调用工具、读写文件、发起请求、操作业务系统，一本正经地把事办错就不再是体验问题，而是生产事故。本文讨论 Agent 幻觉的成因、治理思路与工程落点。

一、问题的性质变了

聊天场景里的幻觉，代价通常是一次尴尬的对话，用户重问一遍即可。Agent 场景不同：它把语言输出转化成了动作序列，错误会沿着工具链被放大。

一个典型的失效链条是：模型对任务目标理解偏差 → 选错工具或填错参数 → 工具返回看似合理的结果 → 模型把结果当作事实继续推理 → 最终交付一个格式完整、逻辑自洽、但事实错误的产物。

危险之处在于“自洽”。Agent 的产出往往带有完整的推理痕迹和结构化格式，人类审阅者容易被这种确定性语气说服，从而跳过核验。幻觉的破坏力，与输出的可信外观成正比。

二、Agent 幻觉的几类来源

治理的前提是分类。从工程视角看，Agent 幻觉大致可归为四层：

1. 知识层幻觉
模型内部知识不足或过时，却仍然给出确定答案。在 Agent 中表现为：编造不存在的 API、函数签名、配置项、文件路径。

2. 感知层幻觉
对输入材料的误读。包括长文档中的细节丢失、表格与代码块解析错误、多轮对话中指令漂移。Agent 拿到的是“它以为的输入”，而非真实输入。

3. 行动层幻觉
工具选择错误、参数构造错误、对工具返回值的误解释。例如把空结果当成成功、把错误码当成正常数据继续处理。这一层是 Agent 特有的，也是危害最直接的。

4. 反思层幻觉
Agent 在自我检查时给出虚假的“已确认”。它声称验证过，实际没有验证；声称引用了来源，实际来源不支持结论。这一层最难发现，因为它伪装成了质量控制。

三、治理思路：把“信任模型”改成“验证模型”

核心原则可以概括为一句话：不要问模型对不对，要让系统能证明它对不对。

具体可落到以下几个方向：

（1）缩小单步自由度
把复杂任务拆成边界清晰的小步骤，每步只允许有限的动作空间。步骤越短，模型跑偏的累积误差越小，出错位置也越容易定位。

（2）工具契约显式化
为每个工具定义严格的输入 schema、前置条件、返回值语义和失败模式，并在调用前做参数校验。让“参数不合法”在系统层被拦截，而不是指望模型自觉。

（3）结果可验证优先
优先设计那些结果天然可验证的任务路径：能编译的代码、能执行的测试、能对账的数据、能回查的引用。对不可验证的环节，明确标注为“待人工确认”，而不是让模型自行背书。

（4）外部事实源兜底
涉及事实性内容时，强制走检索或查询接口，并要求输出附带可追溯的来源标识。此处不展开具体检索方案，但原则是：模型负责组织，系统负责取证。

（5）关键动作人工闸门
对写操作、删除操作、对外发送、资金相关等高风险动作设置审批节点。闸门不是不信任 AI，而是把不可逆操作变成可逆或可拦截的。

（6）全链路可观测
记录每一步的输入、工具调用、参数、返回值与模型决策依据。没有轨迹，就无法区分“模型错了”还是“工具错了”，治理也就无从下手。

四、工程落点清单

将上述思路转为可执行的检查项：

• 是否为每个工具定义了失败返回与超时处理？
• 是否校验了模型生成的参数类型与取值范围？
• 工具返回空结果时，Agent 的行为是否被明确定义？
• 是否存在“模型自称已验证”但系统无实际校验的环节？
• 高风险动作是否具备回滚或审批机制？
• 输出中的事实性断言是否可追溯到具体来源？
• 是否保留了完整的调用轨迹用于事后复盘？

这份清单的价值不在于一次全做完，而在于让团队意识到：Agent 的可靠性是系统设计问题，不是提示词问题。

结语

Agent 幻觉治理的本质，是承认模型的不确定性，并用系统设计去吸收它。一本正经地把事办错，靠更严厉的提示词治不好，靠更严密的工程约束才治得住。

把模型当作一个能力强但需要监督的执行者，而不是一个可以托付全部判断的权威——这是当前阶段更稳妥的姿态。

生成标记：本文由 ITPUB 文章生成平台基于已选素材整理生成。