异步 Agent 的静默失败：为何你的 AI 任务悄然终止却无人察觉

异步 AI 任务有一个传统后台 Worker 没有的问题：它们会静默而自信地失败。一个文档处理 Agent 返回 HTTP 200，输出格式规整的结果，然后继续执行——而实际输出却悄悄出错了：可能不完整，可能建立在三步前幻觉出的事实上。你的仪表盘依然绿色，值班工程师照常入睡，客户最终才发现异常。

这不是边缘情况，而是未经可观测性设计的异步 AI 系统的默认行为。让传统分布式系统中后台作业队列保持可靠的工具——死信队列、幂等键、Saga 日志——同样适用于 AI Agent。但失败模式足够不同，需要做一些"翻译"。

为何异步 AI 失败不同于普通作业失败

传统后台作业的失败模式是可识别的：抛出异常、超时、队列消息未确认。每种失败都有明确信号，重试逻辑介入，耗尽重试后死信队列捕获消息，工程师可以回放或检查失败的 payload。

AI Agent 作业包含上述所有失败方式，再加上几种新的：

• 语义失败：从队列角度看，Agent 成功完成了——它返回了结果、消耗了 token、更新了数据库——但结果是错的。库存充实 Agent 编造了一个商品 SKU，摘要 Agent 删掉了最重要的条款，多跳研究任务"回答"了问题却自信地引用了错误来源。
• 静默部分完成：Agent 处理了 6 步工作流中的前 4 步，然后在中途停滞。由于最终回调触发，作业被标记为完成，而第 5、6 步从未执行。
• 重试引发的重复：LLM 调用在 28 秒后超时，调用方重试，而原始调用在 3 秒后完成。同一操作的两次调用都触发了——与数据库写入不同，发送邮件或调用外部 API 默认可能不是幂等的。
• 幽灵循环：由于提示词轻微格式错误引发的重试风暴，在一个周末烧掉了 1.5 万美元的 API 费用，无人知晓，直到账单到来。

贯穿所有这些的线索是：AI 作业将执行成功与正确性混为一谈。基础设施层面的指标——作业完成率、队列深度、错误数——无法捕获 Agent 是否真正做了正确的事。

死信队列作为控制面，而非垃圾桶

大多数工程师把死信队列当作处置机制：消息在其他一切都失败后落入其中，某人最终会查看它们。这种思维对 AI Agent 系统来说过于被动。

为 AI 作业设计良好的 DLQ 是一个控制面。它捕获原始 payload、完整重试历史、失败原因以及相关实体 ID。它提供回放接口，并将不同失败类型路由到不同处理程序。

对于 AI 来说，失败类型的区分比传统作业更重要。瞬态失败——触达速率限制、上游超时、瞬时网络错误——值得用指数退避自动重试。永久性失败——格式错误的提示词、违反策略、上下文窗口溢出——重试无益，应直接送人工审核。

对所有失败一视同仁的朴素重试策略会在不可恢复的错误上耗尽重试次数，同时浪费 token 并产生不必要的费用。更糟糕的是，它会静默丢弃那些看起来像瞬态失败、实则是语义错误的消息——这类失败会返回成功响应码，却污染下游状态。

将 AI 特有的失败类型路由到特定 DLQ 通道还能产生有用的遥测数据：上下文溢出失败的突然激增意味着输入分布发生了变化；策略违规失败的集群可能预示着提示注入攻击。死信队列成为生产漂移的被动传感器。

每一步都加幂等键，而不仅仅是入口处

大多数团队只在 API 层加幂等键——每个入请求生成一个键，在队列入口做去重。这是必要条件，但对多步 AI 工作流来说远远不够。

问题出在工作流的中间环节。设想一个 5 步文档处理流水线：提取、分类、增强、转换和存储。第 1 到 3 步完成，第 4 步超时。编排器从最后一个检查点重试——但如果第 3 步没有自己的幂等键，增强调用就会再次触发。根据被调用的工具，这可能无害（纯查找），也可能灾难性（创建记录、发送消息或向客户收费的操作）。

正确的模型是逐步幂等：每个有副作用的操作都获得一个由工作流执行 ID 和步骤索引派生的键。编排器在调用操作前检查这个键是否已记录为完成。若已完成，跳过该步骤；若未完成，触发操作并原子性地存储结果。

加载中…