很多团队第一次撞上 Agent 幻觉，往往不是因为它回答错了，而是它把错误说得特别顺。问它上次跟客户约定的交付时间，它能一本正经给出一个从未出现的日期，语气跟真的一样。这时候大家习惯把锅甩给模型，但做了几个月 Agent 项目之后，我的体会是：幻觉更多是出在三个固定的地方——答案本身、工具返回和推理过程。把这三层分开验，比整体”感觉对不对”可靠得多。
先说清楚，这里说的幻觉不是模型偶尔胡说八道，而是 Agent 在真实任务里把不存在的当成存在：引用了没查过的资料、把工具返回的旧数据当新数据、或者跳过关键推理步骤直接给结论。这类问题靠提示词几乎压不住，得靠流程去拦。这也和站里写过的 引用可信度、知识库引用质检 是一脉相承的——可信度管住源头，检测管住闸门。
答案层：有引用才算数
对事实型回答，最有效的闸门是”必须有引用才能算数”。不是让模型在结尾补一句”以上内容仅供参考”，而是要求它给出可点开的来源，并且回答和来源要能对得上。对不上的情况通常有两种：一种是引用了 A 文档却拿 B 文档的内容回答，属于引用错配；另一种是压根没有来源，全靠模型脑补，这是最典型的幻觉。
落地的时候，可以把引用分成等级：官网和内部制度是一级，新闻和第三方评测是二级，用户聊天记录只能当线索不能当结论。等级不同，回答时能采信的程度也不同。这个思路在 引用可信度 那篇里已经拆过，检测只是把它变成可执行的检查。
工具层：返回结果也要验
工具返回是幻觉的高发区，因为模型默认”工具不会骗人”。实际上工具返回会过期、会失败、会被截断，甚至会因为权限不足返回空结果，而 Agent 常常照样拿去当证据。比如查库存的接口在维护期返回了缓存数据，Agent 把缓存当实时库存，直接给客户报了个数。
所以工具层要验三样：来源（这是哪个系统给的）、时间（数据是什么时候的）、完整性（返回有没有被截断或失败）。验不过的返回，要么标成待确认，要么直接不让它进回答。这里和 工具调用机制 里讲的是一回事：工具不是越多越好，关键是返回结果能被正确理解和校验。
推理层：断点要能查
最隐蔽的幻觉在推理层——Agent 跳步了。比如销售跟进任务里，它直接把”客户没回复”推理成”客户已放弃”，中间漏了”我们根本没发过跟进邮件”这个关键事实。这类问题在答案层查不出来，因为输出看起来自洽。
查推理层靠的是把过程留下来：每一步是基于什么输入、做了什么判断、排除了哪些选项。这也是为什么站里一直强调 证据包 和 回放对照——不是要监视 Agent，而是推理一旦可以回放，跳步和脑补就藏不住。
落到日常：抽检、置信度和拒答
检测不能只靠上线前的测试，日常运行里要有三个抓手。一是抽检：按任务类型抽关键样本，专门看引用对没对上、返回验没验过，做法可以参照 人工复核抽检。二是置信度：让 Agent 在没把握的时候主动标注”待确认”，而不是硬给结论。三是拒答：证据不足就问、就转人工，转人工队列 就是为这种时刻准备的。
还有一个建议：把每次发现的幻觉样本收进一个固定的抽检集。攒到一定量，你会发现幻觉不是随机的，而是集中在某几类任务、某几个工具、某几种措辞上。那时候再动手修，就不是靠运气，而是有据可依了。这个思路和 评测集 的做法是一样的。
总结
AI Agent 幻觉检测，说到底就是把”相信 Agent”换成”验证 Agent”。答案层看引用，工具层验返回，推理层查断点，日常运行再配抽检、置信度和拒答。三层分开验之后，大部分幻觉在变成客户事故之前就能被拦住。
