AI智能体在产线的五种"沉默死法"

你的监控面板一片翠绿，用户那边却什么都没发生——这不是科幻片，是AI智能体每天在产线的真实剧本。

最近读到一组工程师复盘，他们把这类故障叫做"沉默失败"：没有异常抛出，没有红色警报，只有用户对着空白的屏幕发呆。今天拆解五种最隐蔽的死法，以及他们怎么给这些幽灵装上传感器。

第一种：任务跑完了，消息没发出去

定时任务框架有个盲区——它只认智能体"汇报"了什么，不认用户实际收到了什么。

他们的运行时用三个状态记录投递结果："已送达"｜"未送达"｜"未请求"。但问题是，这三个状态是智能体自己填的。一个典型场景：某bug分拣定时任务设了300秒超时，启动就吃掉75秒，智能体成功创建了GitHub工单、开了Jira票、更新了表格，然后在第298秒耗尽预算，Slack通知步骤根本没执行。

框架记录这次运行"已送达"。实际上？零条消息发出。

他们的补丁是把Sentry日志传输和定时任务对齐：ERROR级别的日志自动转成可搜索的事件，带上组件名、任务ID、运行ID。超时从"buried log line"变成能按任务检索的警报。但真正的修复不在监控层——是执行顺序：用户可见的通知必须排在清理动作之前，确保预算优先喂给高优先级步骤。

第二种：工具调用"假装成功"

当工具封装层遇到非200状态码，返回空字符串或者一句温柔的"操作无法完成"，模型读不到任何错误信号。它会把这个响应当成合法的空操作，继续下一步。最终总结报告一切顺利，审计日志显示工具被调用了，但没有任何痕迹表明这次调用其实失败了。

他们在运行时层加了模式匹配：捕获「[tools] NAME failed: reason … ERROR」格式的输出，转发为Sentry异常事件，带上工具名。现在工具失败率是一眼可见的指标，不用翻debug日志。

同时把Slack发送端的静默丢弃日志从verbose提到info级别——速率限制、权限错误这类"无聊但关键"的问题，以前得专门去找，现在主动暴露。

第三种：消息已读不回，锅在路由器

智能体停止回复消息时，九成九不是它坏了。是入站处理器——它坐在平台和智能体之间，对每个事件做路由决策。大部分丢弃是正确的：机器人自提及要防循环，消息编辑不该触发重跑，@所有人需要过滤。

但这也意味着，当真正的消息被误伤，智能体完全不知情。它没崩溃，只是从未收到指令。

他们的解法是给路由层加埋点：每个丢弃决策都记录原因码，定期审计"本不该丢的"模式。不是让智能体更聪明，是让中间层的黑箱变透明。

第四种：启动即破产

有些智能体的"冷启动"成本极高：加载模型、初始化上下文、预热缓存。如果预算按单次运行分配，可能出现启动吃掉80%额度，实际工作只剩20%的荒诞局面。

更隐蔽的是渐进式泄漏：某次运行遗留了未清理的上下文，下次启动要加载更多历史，恶性循环直到某次彻底超时。用户视角是"越来越慢然后突然死掉"，监控视角是"运行时间正常波动后断崖"。

他们的防御是双轨预算：启动预算与运行预算分离，超支即熔断；同时给上下文大小设硬上限，拒绝无限制的历史堆积。

第五种：清理动作抢跑

回到第一种场景的深层修复。很多框架把清理放在finally块，确保资源释放。但AI智能体的"资源"包括用户注意力——如果通知没发出去，清理再干净也是失败。

他们调整了优先级模型：用户可见的副作用 > 内部状态更新 > 资源清理。不是取消清理，是让它排队。预算紧张时，先保证用户知道发生了什么，再收拾残局。

这违背传统软件工程的"资源安全第一"，但符合智能体的产品逻辑：用户是最终裁判，不是运行时。

为什么这些值得产品人关注

这五种模式有个共同特征：故障发生在"系统认为正常"和"用户感知失败"的夹缝里。传统APM（应用性能监控）是为请求-响应模型设计的，假设异常会冒泡、超时会被捕获、成功码等于成功体验。

AI智能体打破了这些假设。它是异步的、有状态的、预算受限的、自我报告的。它的失败不是崩溃，是消失——在日志里留下一行"成功"，在用户那里留下一片空白。

给这些幽灵装上传感器，本质上是在"系统状态"和"用户体验"之间架桥。桥的一头是工程师熟悉的可观测性工具，另一头是产品人更该关心的：用户到底发生了什么。