客服代理回答了一个用户重置双重身份验证（2FA）的请求，但提供的步骤根本不存在。回复看起来很自信，HTTP 请求返回了 200 OK，延迟正常，所有的监控图表都显示为绿色。
AI 驱动的客服代理产生了幻觉，因为本应捕获错误的内部检查从未运行。工程师依赖的仪表盘报告运行完美，而代理却在悄无声息地编造解决方案。
为什么传统仪表盘会漏掉 AI 幻觉
大多数可观测性技术栈将 AI 代理视为任何其他微服务：单个入站请求和一个单个出站响应。它们记录 HTTP 状态、响应时间和错误计数。它们没有记录请求内部的隐藏步骤——外部文档的检索、对大语言模型的调用、辅助工具的使用，以及任何验证输出的护栏逻辑（guard-rail logic）。
当检索步骤返回空结果时，模型通常会用听起来合理的文本来“填补空白”。从监控系统的角度来看，调用是成功的，因为没有发生崩溃，状态码保持为 200。幻觉保持隐形，唯一的症状就是错误的答案传达给了用户。
将黑盒转变为可读的树状结构
可靠调试的第一步是停止将代理视为一个单体调用，开始将每个内部操作可视化为追踪表（trace table）中的独立行。一个典型的运行过程可以分解为：
- 顶层代理调用
- 提取相关文档的检索步骤
- 处理检索数据的每一次语言模型推理
- 每次工具调用（例如：数据库查询、API 请求）
- 强制执行事实性或策略合规性的护栏检查
每一行都记录了时间戳、成功标志以及在该步骤中传输的有效载荷（payload）。有了这种结构，执行过程就变成了一棵可以逐行检查的树，而不是只能根据最终输出进行猜测。
逃脱检测的 Bug
在那个错误的客服交互中，追踪记录如下：
- 检索运行了但未返回任何文档。
- 下一步仍然继续，将空上下文传递给模型。
- 模型生成了一个答案，用编造的步骤填补了缺失的信息。
- 系统返回了 200，因为流水线没有遇到异常。
幻觉本身并不是语言模型的缺陷；它是检索和生成阶段之间缺失了护栏。即使代理没有任何依据来支撑其回答，它仍然会给出答案。
阻止幻觉的简单护栏
通过两项具体的改进消除了问题：
- 检索为空时中止 – 如果文档库返回空结果，代理必须回答“我找不到您需要的信息”，而不是继续进行生成。
- 事实性检查 (Grounding check) – 在模型生成响应后，验证每一项事实性陈述是否都出现在检索到的内容中。如果检查失败，拒绝该答案并回退到“无法回答”的响应。
加速调试的实用工作流
- 追踪每一次内部调用 – 对代理进行埋点，使每次检索、模型推理和工具使用都能在持久化日志中写入一行。
- 保留失败的运行记录 – 存储用户报告错误的任何交互的完整追踪记录。为了节省存储空间而删除它们，会掩盖寻找回归问题所需的数据。
- 使用版本信息标记运行记录 – 在每个追踪行中包含版本标识符和任何特性开关（feature-flag）状态。这可以让你将新 Bug 与最近的代码更改关联起来。
- 衡量质量，而不只是速度 – 添加衡量答案遵循指令程度以及是否基于检索内容（grounded）的指标。如果答案是错误的，高吞吐量也毫无意义。
- 每日审查失败案例 – 定期对存储的失败案例进行简短审查，通常可以在它们影响大量用户之前发现模式（例如：某种特定类型的查询始终返回空检索结果）。
通过将“绿色”转变为“已验证”，团队可以及早发现幻觉，并保持用户体验的可信度。
忽视内部故障的代价
当仪表盘仅在 HTTP 层报告成功时，组织部署的代理看起来很可靠，但实际上会定期提供错误的指导。
下一步关注点
在这些变得普遍之前，最稳妥的方法是将每一个内部操作都视为可观测的，并在证据缺失时快速失败。
核心要点： 仪表盘显示为绿色只能说明底层架构运行正常，并不保证答案是正确的。通过追踪每一次检索、模型调用和护栏检查，你可以将隐藏的幻觉转化为可见的故障，从而在它们触达用户之前进行修复。