252 篇博文 含有标签「reliability」

大多数 AI 功能发布时只有两种状态：正常工作和彻底挂掉。模型调用成功，功能就有响应；模型调用失败，用户就会看到错误。这相当于在构建 Web 服务时没有负载均衡、没有缓存，且只有一个数据库副本——在出事之前，它在技术上是可行的。

不同之处在于，工程师在 20 世纪 90 年代就学会了数据库弹性模式，并将其深刻内化。 AI 功能的弹性仍处于通过一次次生产事故进行艰难探索的阶段。一家支付处理器在一次时长 4 小时的 AI 停机中损失了 230 万美元。一家物流公司在其路由模型宕机时，错过了 30,000 个包裹的交付窗口。这两起失败都有一个共同的根本原因：当主模型不可用时，没有可以回退的方案。

这是多智能体系统设计在架构评审中很少被提及的一个令人不安的事实：当你让两个智能体处理同一任务时，它们在20%到40%的情况下不会就答案达成一致，具体比例取决于任务类型。大多数系统的应对方式是静默地选择其中一个答案。日志中只显示最终决策，中间的分歧消失无踪。一切看起来运转正常，直到下游出现故障——而你要花费三到五倍的时间来调试，因为你搞不清楚哪个智能体出错了，甚至根本不知道它们曾经存在过分歧。

智能体之间的分歧不是一个可以稍后处理的边缘情况。随着并行智能体拓扑逐渐成为标准架构模式，冲突解决从脚注升级为一级可靠性纪律。

大多数生产环境中的 Agent 故障看起来像是模型错误。Agent 在会话开始时能正确响应系统提示词——维持正确的语气，遵守工具约束，遵循定义的工作流程。然后，在第 30 或 40 轮左右，情况悄然发生变化。Agent 开始在本应直接的地方含糊其辞，调用了它被告知应避免的工具，甚至推翻了它在 15 轮前做出的决定。系统提示词没有改变，但 Agent 的行为已经变了。

这就是人格漂移：由于 Transformer 对越来越深埋的上下文的注意方式，Agent 实际行为与其原始系统指令之间产生的渐进式偏差。研究对此进行了精确量化——经过 8–12 轮对话后，人格自一致性指标下降超过 30%。单轮 Agent 的任务准确率约为 90%；在运行相同任务的多轮 Agent 中则降至约 65%。这 25 个百分点的差距并非一个可以通过调整提示词来解决的模型质量问题，而是注意力机制在长序列上工作方式的架构特性。而大多数团队只有在上线某个功能、该功能悄无声息地降级数小时后才被用户发现时，才意识到这个问题。

查看你的网关重试配置。三次尝试。带有抖动的指数退避。在 5xx 错误和超时时重试。最大延迟限制在几秒钟。这看起来很合理，而且是某人两年前从微服务运行手册中复制过来的。但这正是你的 P99 是 P50 两倍、在服务商发生故障期间 Token 费用激增，以及相当一部分用户在默默流失前盯着 30 秒加载圈的最主要原因。

专为 50 毫秒 RPC 设计的重试策略在面对 8 秒的 LLM 调用时注定会失效。失败的形式不同，每次尝试的成本不同，用户感知到的时间维度也不同。默认设置并不安全，只是让人感到熟悉。大多数团队通过同样的方式发现这一点：在一次事后回顾中，网关日志显示响应成功，而客户的截图却显示 UI 已经卡死。

凌晨 3 点因为宕机而把你吵醒的告警其实是简单的。供应商返回了 40 分钟的 503 错误，你的回退机制生效了，运维手册（runbook）启动了，复盘报告（post-mortem）几乎可以自动完成。而那些没有吵醒你的告警——那些在所有仪表盘都显示绿色的情况下，让你的支持队列在 6 小时内堆满的告警——才是渐变故障（brownout）。供应商的 API 仍然有响应。状态页依然显示“运行正常（operational）”。你的 p99 延迟已悄然从 2.1 秒漂移到 14 秒，错误率从 0.1% 上升到 4%，而唯一察觉到的人是那些已经流失的用户。

供应商的可用性并不是非黑即白的二元状态。大多数团队编写的回退逻辑——“如果供应商宕机，则切换到备用方案”——本质上是用一个只有两种状态的状态机去应对一个连续变量，当供应商处于“惨淡运行”而非“彻底宕机”的状态时，这种机制根本不会触发。为渐变故障（brownouts）而设计是一个与处理宕机完全不同的设计问题，我所见过的几乎每一个生产环境中的 Agent 调度框架在发布时都没有解决这个问题。

“先创建后通知”的序列在开发阶段运行良好。而“先通知后创建”的序列则会为一个尚不存在的实体触发 webhook，导致消费者返回 404，接着你的团队会花上一周时间来调试这个看起来像是不稳定的集成测试。这种不稳定并非随机。它是确定性的，源于你的工具集拥有而你的规划器（planner）却不知晓的隐藏排序不变性。

这就是生产环境中 Agent 工具调用排序 bug 的常见形态：工具集在底层以偏序（partial order）方式组合——某些操作必须先于其他操作执行，而另一些则可以按任意顺序运行——但在规划器看来，它们只是一个无序的能力集合。模型选择了一个昨天行之有效的顺序。而明天，一次提示词修改、模型升级，甚至只是不同的 temperature 采样，都会选出另一个顺序。对于阅读追踪记录（trace）的人来说，这两种顺序看起来都很合理。但其中只有一个是正确的。

如果不声明顺序，团队交付的就是一个最终会被模型的提示词敏感性（prompt sensitivity）触发的 bug 隐患。

如今，生产环境中的大多数 “智能体”（agents）其实都是套着对话界面的后台任务。它们不需要用户向其输入内容，而是需要一个触发器、一个状态文件，以及一种在不可避免的超时后恢复运行的方法。对话循环 —— 请求、工具调用、请求、工具调用，无限循环 —— 是为了演示方便而提供的功能，却悄然间成为了默认的执行模型。然而，对于大多数交付的智能体工作负载来说，这其实是一个错误的模型。

这并非一个哲学层面的决定。它直观地反映在账单上、值班告警中，以及任务的运行成功率上。对话循环会在多轮对话中保持模型会话开启，不断累积上下文，一旦链路中任何一环出错，整个过程就会中断。而调度触发则在确定的边界处启动，运行至完成或达到检查点，并在退出前将状态写入持久化存储。前者像是一通电话，而后者则是一个工作队列。将两者混为一谈，会导致一个每月 200 美元的功能在没有任何人修改提示词的情况下，变成每月 4 万美元的负担。

当搜索索引失效、供应商 API 对你限流、数据库只读副本出现延迟，或者下游微服务开始返回 503 错误时，你的智能体（agent）必须决定该做什么。在大多数生产环境的智能体系统中，这个决定从未被真正做出。它是被“默默继承”下来的——往往来自于编写工具封装（tool wrapper）的工程师在项目第三周周二下午 4 点随手写下的代码。

其结果就是你的客户最终替你写出的内容：一个 Reddit 帖子、一份客服对话记录，或者是新闻稿中的一段引述。“助手告诉我余额是 0 美元，但其实我的账户没问题——结果发现是他们的查询服务挂了。”那段话就是你的团队没写的降级模式规范。现在它公开了，它属于客户了，而且你的工程部门在接下来的整个季度里都将忙于应对它。

你团队每季度演练的灾备 (DR) 操作手册是为了一套你已经不再完全运行的技术栈编写的。手册上写着：提升从库、重新指向 DNS、清空队列。它假设状态存储在数据库、队列和对象存储中 —— 这些是 SRE 团队已经管理、命名并测试了十年的地方。接着在上个季度，你上线了一个智能体 (agent)。现在，工作内存存在于推理提供商的会话缓存中、工作节点本地磁盘上的草稿文件里、尚未回写的在途工具调用结果中，以及仅存在于单次模型调用提示词历史中的部分“计划-执行”轨迹 (trace) 里。这些都不在资产登记簿上，也不在操作手册里。

当区域宕机时，智能体并不会干净利落地失败，而是处于一种“半完成”的状态。用户看到工作流已经开始，但故障转移后的区域无法恢复进度；客户收到了两次账单，或者根本没收到，因为幂等键存在于已经失效的工作节点上；值班工程师读着 Slack 频道里的讨论，开头是“编排器已启动，但是...”，六小时后以处理信用卡拒付队列告终。

这就是没人点破的鸿沟：智能体特性拥有现有灾备计划未曾描述的状态模型。如果团队还没有记录下这些状态表面，那么只需一次区域性停机，他们就能深刻体会到操作手册的缺失所带来的代价。

高管演示进行得非常完美。模型回答了精选的问题，智能体（agent）完成了工作流，屏幕录像已保存到公司网盘，发布日期也已排入日程。六周后，上线部署遭遇惨败，复盘报告不言自明：模型需要更多打磨，提示词（prompt）需要更多迭代，团队低估了从原型到生产环境之间的工作量。

这种叙事是错误的，而且代价昂贵，因为它让团队回去重复那些已经失败的工作。演示并不是生产环境的“欠打磨”版本。它只是团队从未测量过的分布中的一个“单一采样”（single sample）。那个惊艳瞬间只是模型针对相同输入可能产生的数千个结果中的一次实现，而团队却把最好的那次当作典型表现发布了。演示与生产环境之间的差距不是质量下滑，而是团队尚未察觉的“方差”（variance）。

这种思维转变至关重要，因为方差问题的解决方法与打磨问题的解决方法完全不同。“打磨”导向会说：“迭代提示词，微调模型，雇个更好的产品经理。”而“方差”导向则会说：“在输入分布中进行 n 次采样之前，你根本不知道自己手里拿的是什么。”这两种诊断会产生不同的路线图、不同的预算以及不同的事故模式。那些在 2026 年能够可靠交付的团队，都清楚自己面临的是哪种问题。

A 团队的智能体宣传其成功率为 99%。B 团队的智能体也宣传 99%。调用这两者的全新联合工作流在状况良好时成功率为 98%，而在状况不佳时仅为 96% —— 负责该联合工作流的团队现在成了两个他们不拥有、无法在本地复现、且未编写评估集的系统的事实上的 SRE。每个上游团队都达到了其 SLO（服务水平目标）。但复合产品却未达标。边界正确一侧的报警器却始终保持沉默。

这是独立失败率的数学问题，自从组织开始允许智能体相互调用以来，它就一直潜伏在显而易见的地方。五个可靠性为 99% 的组件会给你带来 95% 的端到端可靠性。十个组件则会降至 90%。一个每步成功率为 95% 的 20 步流程，其最终成功率仅为 36% —— 超过一半的操作在完成前就会失败。当一个工作流链接了 50 个组件时 —— 一旦企业级智能体开始调用子智能体，再由子智能体调用工具智能体，这种情况并不罕见 —— 一个每个环节都“99% 可靠”的系统，在大约十次请求中就会失败四次。

研究人员在分析了超过 150 个任务中的五个流行多智能体框架后，发现失败率在 41% 到 87% 之间，其中排名前三的失败原因是：步骤重复、推理与行动不匹配，以及对终止条件的忽视 —— 观察发现，与单智能体基准相比，非结构化的多智能体网络会将错误放大高达 17 倍。这其中的数学逻辑并不深奥。问题在于，组织的 SLO 表、仪表板、轮值安排和 PRD 仍然是以单个智能体为单位进行定义的。

你的审核员今天早上做出的第 50 个决策与第 1 个决策的质量并不相同。架构图不会显示这一点。容量模型不会显示这一点。跟踪“每小时审批量”的仪表盘甚至在主动掩盖这一点。然而，你的人机回环（Human-in-the-loop，简称 HITL）系统的整个前提——即由人来捕捉模型产生的错误——从队列开始填充的那一刻起就在无形中退化。

大多数 HITL 设计将审核员的时间视为一种无限的、可互换的资源。团队设置一个置信度阈值，将所有低于该阈值的项路由到人工队列，并宣布系统是“安全”的。六周后，审批率已悄然升至 96%，队列深度是人员配置模型假设的两倍，抽样审计显示审核员正在对他们在第一天会标记出来的边缘案例点击“批准”。系统并没有崩溃，它只是通过“橡皮图章”式的盲目审批，让自己看起来运转良好。