AI 降级设计是架构问题，不是事后补丁
当麦当劳在三年运营后关停其 AI 得来速系统时，失败的原因并不是模型识别订单能力不足。失败的根源在于架构：没有明确的升级路径交给人工收银员，没有触发重试的置信度阈值，也没有定义系统困惑时该如何处理。AI 只是不停地尝试。顾客不断地抓狂。顺利路径设计得很好，其他一切都没有。
几乎每一个失败的 AI 部署都重复着这个模式。模型在演示中运行良好，在生产中出现故障。而事后分析揭示了同样的根本原因：降级设计从来不是架构的一部分，而是某人打算"之后再加"的东西。
解决方法不是更多的提示工程，而是把故障模式作为一等设计交付物来对待——在写第一个生产 prompt 之前，就要完成评审。
为什么顺利路径还不够
基准测试以一种特定的方式谎报可靠性。在评估套件上取得 60% pass@1 的分数，并不意味着你 60% 的生产调用都会成功。ReliabilityBench 是一个 2025 年设计用于在生产压力下测量代理行为的评估框架，其研究发现：在相同输入的多次试验中，单次试验成功率为 60% 的模型，一致性不足 25%。生产数字不等于基准数字，而是远比基准糟糕。
生产故障的来源有据可查：
- 速率限制（429） 是已部署 LLM 应用中最常见的单一错误类别。在速率限制压力下，ReliabilityBench 观察到成功率从 96.9% 的基线下降到 88.1%——接近 9 个百分点的劣化，没有任何基准测试能预测到。
- 上下文窗口溢出 尤为危险，因为它是无声的。模型不会崩溃，而是截断内容、丢失早期上下文，或返回不完整的答案却没有任何错误信号，没有任何东西可以在异常处理器中捕获。
- 幻觉 在生产移动应用的用户投诉中出现比例约为 1.75%，这是 2025 年对三百万条应用评论的分析结果。这个数字听起来很小，直到你在大规模运行时才会发觉不对。
- 工具响应超时 会导致代理即兴发挥而非正确失败。当工具调用未能及时返回时，许多代理实现仍会生成响应，用虚构的数据填补空缺。
每一种都是已知的故障类别，每一种都需要不同的响应。问题在于，大多数团队针对一种故障模式设计一次 AI 功能，然后希望其他问题不会出现。
四层降级分类体系
并非所有故障都值得相同的响应。一个四层分类体系将故障类别映射到适当的响应：
静默降级：AI 功能变得 不可用，但用户不知道。系统返回缓存的、过时的或预计算的结果，这些结果足够好。这适用于具有建议性或展示性的功能——个性化内容推荐、AI 生成的历史数据摘要、可选建议。关键标准：过时或缓存的结果仍然足够有效，显示它不会造成伤害。
优雅替代：AI 功能失败，但系统返回降级但可用的替代方案。AI 生成的邮件草稿退回到模板。智能搜索退回到关键词搜索。个性化排序退回到默认排序顺序。用户得到了一些可用的东西，而不是什么都没有。
显式错误：系统承认 AI 功能不可用并告知用户。当没有有效降级方案，且用户需要知道他们正在没有 AI 辅助的情况下工作时，这是合适的做法。它需要为错误状态编写 UX 文案，而大多数团队直到生产时才会写这些。
硬失败：系统完全阻止操作。当 AI 输出至关重要时——当不正确或缺失的响应会导致数据损坏、安全违规或不可逆的用户伤害时——这是合适的做法。内容审核门控是明显的例子。AI 驱动的交易授权路径上的欺诈检测也是如此。
架构审查的问题是：对于系统中的每个 AI 功能，它属于哪一层，谁负责验证降级行为已实现并经过测试？
将降级层级与故障类别匹配
层级分类体系回答"降级有多糟糕"。但故障类别决定了何时以及如何激活该降级方案。
模型 API 超时或 5xx：激活熔断器，使用指数退避和抖动重试。连续三次失败后，断开电路并路由到降级层。冷却后电路应自动探测恢复——这是熔断器模式中的半开状态。在没有熔断器的情况下硬编码重试循环是一个常见错误，会将可恢复的中断变成级联故障。
速率限制（429）：不同于超时。API 是正常工作的，但你超出了配额。响应：如果有 Retry-After 头则遵从，否则使用指数退避。不要立即升级到备用提供商——速率限制通常是暂时的。如果速率限制持续数分钟，那时才适合切换提供商。
上下文窗口溢出：这需要在调用之前而非之后进行检测。在组装 prompt 时跟踪你的 token 预算。当你达到上下文窗口的 80% 时，触发预防性剪枝、摘要或分块处理。等到 API 返回错误时意味着你已经浪费了调用的延迟。
内容政策拒绝：模型拒绝处理请求。这与技术故障在语义上是不同的。系统不应重试——模型会再次拒绝。适当的响应是显式错误（附有适当的用户界面文案）或硬失败，取决于功能试图做什么。
幻觉或低置信度输出：这是最难处理的，因为模型无法可靠地自我报告置信度。有效的架构模式是：定义可测量的输出验证（格式检查、约束检查、与确定性数据源的交叉引用），并将验证失败视为触发自身降级方案的故障类别。
恢复所有权是一个架构决策
每个降级层都需要一个负责人。这听起来显而易见，但实际上这是最常被跳过的步骤。发布 AI 功能的团队很少是显示降级界面的 UI 的运营团队。拥有 API 集成的团队 并不总是处理面向用户的错误状态的团队。没有明确的所有权，降级方案就没人负责，直到发生事故。
这里一个有用的工件是能力依赖映射。对于每个 AI 驱动的功能，它列出：
- 它依赖的模型属性（上下文窗口、遵循指令能力、低拒绝率、结构化输出支持）
- 哪些是供应商提供的，哪些是工程控制的
- 按层级排列的降级链
- 降级链中每一步的负责人
这份文档在事故中起到第二个作用：它告诉值班工程师，如果 AI 提供商中断，哪些功能会降级，以及这些功能对用户来说是什么样的。Anthropic 在 2025-2026 年的实际生产正常运行时间约为 99.32%，而承诺的 SLA 是 99.9%——每月超出 SLA 约五小时的额外停机时间。已经映射其 AI 功能依赖关系的团队迅速恢复。没有的团队手忙脚乱。
在写第一个 Prompt 之前设计降级方案
最重要的转变是时间上的。大多数团队将降级设计视为在功能运行之后发生的强化步骤。所需的纪律是颠倒这个顺序。
在写第一个系统提示之前，架构审查应该回答：
- 这个功能最可能的三种故障模式是什么？
- 每种故障映射到哪个降级层，为什么？
- 静默降级或优雅替代的输出是否真的可用，还是我们在自欺欺人？
- 谁负责降级 UX？它已经被设计了，而不仅仅是计划了？
- 熔断器配置是什么——超时阈值、重试次数、冷 却时间？
- 上下文溢出检测是 prompt 组装管道的一部分，还是事后才想到的？
- 每个降级层的监控是什么样的，这样我们就能知道生产中何时发生降级？
这不是为了形式而走流程。那些构建了可靠 AI 基础设施的公司——Netflix 在 2011 年 AWS 中断期间应对功能降级的方法确立了行业至今仍在使用的模式——首先设计了弹性，然后在上面叠加能力。那些事后才添加降级的，最终得到了麦当劳的得来速。
前瞻性约束
代理系统使降级设计变得更难，而不是更容易。微软 2025 年关于代理 AI 故障模式的分类体系在 13 个主要类别中识别了 37 种不同的故障类别，涵盖特定于多代理系统的安全故障、安全违规和操作故障。对开源多代理系统中 1,642 条执行轨迹的分析发现，在真实工作负载中故障率在 41% 到 86.7% 之间。
多代理系统的故障方式是单模型 API 调用所没有的：失败子代理的部分状态向下游传播，一个工具调用超时让编排代理携带着它视为完整的不完整上下文，两个冲突输出的代理产生一个自信却错误的混合响应。降级分类体系仍然适用——但故障检测面更大，所有权问题更复杂。
无论系统是简单的 API 调用还是多代理管道，工程纪律都是一样的：定义故障类别，将它们映射到降级层，分配所有权，并在写第一个 prompt 之前完成评审。最后做的代价总是高于最先做的代价。
将构建可靠 AI 系统的团队，不是那些拥有更好模型的团队，而是那些将"当 AI 不工作时会发生什么"视为设计问题、早早回答了它、 并构建了与答案相匹配的基础设施的团队。
