周二下午四点二十分，客服知识库更新任务显示为成功。没有异常告警，没有超时，也没有任何工具调用失败。两小时后，运营同事发现新发布的退款规则把“七个工作日”写成了“七天”。问题看起来只差两个字，影响却已经扩散到帮助中心、机器人话术和三封待发送邮件。这不是一次模型突然胡说八道的故事。真正的问题更隐蔽：流程中的第一个智能体误读了一份表格，后面的智能体都忠实继承了这个错误。系统一路绿灯，因为每一步都正确完成了上一环节交给它的任务。
事故时间线
15:41，检索智能体从共享目录中找到两份退款政策。一份是当天生效的正式 PDF，另一份是三个月前的内部讨论表格。表格的文件名更短，修改时间也更近，因此被排序到前面。智能体没有比较文件状态，只摘取了表格中的“七天”。
15:44，写作智能体收到的输入不是原文件，而是一段已经整理好的事实摘要。它负责把摘要改写成用户能理解的说明，并没有理由怀疑上游提供的数字。15:51，审核智能体检查了语气、敏感词和格式，所有项目均通过。16:20，发布任务完成。
复盘时，团队最初把责任归到“检索不准”。但沿着日志继续看，真正导致事故扩大的不是第一次误读，而是系统把一条没有出处等级的摘要包装成了确定事实。错误失去了来源，也就失去了被质疑的机会。
绿色状态不等于正确
传统软件的成功通常意味着程序按照预期执行；智能体系统多了一层麻烦：程序可以按照预期执行，同时任务理解本身是错的。HTTP 200、队列消费成功、结构化输出合法，只能证明链路通了，不能证明链路上流动的内容可信。
因此，面向智能体的监控不能只盯运行状态，还要保存认知状态。每个关键结论至少应带上来源、提取时间、适用范围和置信说明。数字、日期、权限边界等高影响字段，还应该保留原文片段，让下游能重新核对，而不是只接收一段无法追溯的摘要。
这并不意味着每一步都要做昂贵的全量复核。更实用的做法是给状态分级：普通措辞可以直接传递；会改变用户权益、资金、合规或外部承诺的事实，必须经过第二来源或人工确认。
检查点应该检查什么
很多团队已经为长任务设置检查点，但检查点往往只是保存上下文，方便失败后继续运行。事故表明，检查点还需要承担“重新判断”的职责。保存一个被污染的状态，只会让系统更稳定地从错误位置恢复。
有效的检查点应回答三个问题：到目前为止有哪些事实被当成前提；这些事实分别来自哪里；如果其中一项不成立，哪些下游产物需要作废。只有把依赖关系写清楚，系统才能在发现问题后局部回滚，而不是重新执行整条链。
在这次复盘中，团队最终增加了一个很朴素的规则：所有包含期限和金额的句子，在发布前自动展开出处卡片。审核者不需要重读全部材料，只需确认关键字段与正式来源一致。这个改动没有让模型更聪明，却显著缩短了发现错误的距离。
事故之后
团队没有把模型换掉，也没有把温度调成零。大家修的是任务结构：文件增加状态标签，摘要保留引用，关键字段进入专门的核对队列，发布动作绑定可回滚版本。更重要的是，复盘报告不再只记录哪个组件失败，而会记录哪个假设从何时开始被系统共同相信。
AI 事故最值得警惕的地方，恰恰是它可能表现得十分顺利。错误不一定以异常的形式出现，也可能以一连串漂亮的成功状态出现。工程的任务不是消灭所有不确定性，而是让不确定性在进入高影响动作以前仍然可见、可追溯、可叫停。