6 篇博文 含有标签「agent-reliability」

你发布会幻灯片上的可靠性数字，来自一些和用户实际使用的会话完全不像的对话。演示是五轮的：打开、提问、看到一个干净的回答、再细化一次、然后在高音上收尾。而你的核心用户昨天跑的那个会话有三十一轮长，包含两次工具失败（智能体用乐观主义掩盖了过去），最后用户放弃并提交了一张工单。两个会话出自同一个模型。第一个发了新闻稿。第二个被归档为"边缘情况"。

会话长度是评测的一个维度，而演示文化系统性地低估了它。我们衡量单轮准确率，是因为单轮准确率能放进幻灯片里，然后当单会话成功率从一个我们从未在任何图表上画过的悬崖上掉下来时，我们感到惊讶。这个悬崖既不是随机的，也不是尾部事件——它是误差累积、注意力漂移以及那些模型不会重新审视的已承诺假设的可预测后果。每个团队应该问的问题不是"这个模型有多好"，而是"在我们已经在第一到第二十七轮说过那些话之后，这个模型在第二十八轮有多好"。

你交付了一个工具，让你的 Agent 可以获取用户个人资料。描述中写道：“通过用户 ID 检索用户信息。”六周后，后端团队将 user_id 重命名为 customer_uuid 并添加了一个必填的 tenant_id 字段。没有人更新工具的 Schema。你的 Agent 继续调用旧的签名，收到 400 错误，将空结果解释为“未找到用户”，并“热心地”创建了一个重复记录。

日志中没有错误。没有触发任何报警。Agent 全程都非常自信。

这就是工具文档问题：Schema 漂移将陈旧的描述变成了隐性故障向量。这可能是当今生产环境 AI 系统中最被低估的可靠性风险，而且你的 Agent 运行的时间越长，情况就越严重。

我上个季度交流过的一个团队，他们的所有仪表盘都显示绿色。工具错误率稳定在 0.3%。端到端成功率为 98%。SLO 预算几乎没动过。但他们的 Token 支出却是预计的四倍，而且没人能解释原因。当他们最终对每个 Trace 的重试深度进行埋点时，情况发生了反转：成功请求的中值实际上进行了 2.7 次工具调用，而不是架构图里承诺的 1.0 次。智能体（Agent）并没有失败。它是在同一个 Span 内部不断失败又不断恢复，而成功率指标根本无法体现这一点。

这是传统可靠性词汇无法涵盖的智能体可靠性部分。MTBF（平均故障间隔时间）假设故障是断续的、可观测的事件，你可以在两次故障之间进行计数。你测量间隔，计算平均值，并在间隔缩短时发出警报。这对于硬盘、网络和确定性服务都很有效。但对于那些在单个用户可见的操作内部进行重试、重定向、降级并静默恢复的系统来说，它失效了。

一家金融科技创业公司的多智能体成本追踪系统在没人察觉的情况下运行了 11 天。原因是：智能体 A 向智能体 B 寻求澄清，智能体 B 向智能体 A 寻求帮助以解释回复。两者都没有打破循环的逻辑。在人类查看发票之前，每周 127 美元的账单变成了 47,000 美元。

没有抛出错误，没有触发告警，延迟也正常。系统正完全按照设计运行——只是在永远运行下去。

这就是 AI 事故真实的样子。它们不是堆栈跟踪和 500 错误。它们是无声的行为失效、失控的循环，以及在生产规模下以十足信心交付的似是而非的错误答案。你现有的故障响应手册几乎肯定没有涵盖其中的任何一种。

每个后端工程师都知道重试是必不可少的。每个分布式系统工程师都知道重试是危险的。当你让 LLM agent 负责重试工具调用时，你会同时遇到这两个问题，而且还有一个新问题：每次重试都会消耗 token。一个不稳定的 API 端点可能会在不到一分钟的时间内，将一个 0.01 美元的 agent 任务变成一场 2 美元的灾难。

重试风暴问题并不新鲜。分布式系统几十年来一直在处理惊群效应（thundering herds）和级联故障。但 agent 系统放大了这个问题，而微服务模式无法完全解决它，因为重试逻辑存在于一个不理解背压（backpressure）的概率推理引擎中。

一个 AI Agent 在第 3 轮读取了一个文件，在第 4 轮到第 30 轮对其内容进行推理，然后在第 31 轮将修改后的版本写回磁盘。然而，该文件在第 17 轮时被另一个进程修改过。Agent 悄无声息地用陈旧的版本覆盖了较新的版本。没有抛出异常，没有触发警报。从外部看，Agent 成功完成了任务。

这就是陈旧世界模型（Stale World Model）问题，它是生产环境中的 Agent 系统中最少被讨论的故障模式之一。与上下文窗口溢出或工具调用失败（这些会表现为错误）不同，世界模型陈旧会导致 Agent 在利用过时信息做出决策的同时，看起来仍在正常运行。这种失败是无声的，通常是不可逆的，并且会随着任务长度的增加而累积。