AI 应用的可靠性工程，一半是老的分布式系统知识，一半是 AI 独有的新坑。老的部分（重试、超时、熔断）教科书上都有，这一章只讲 AI 特有的部分——因为恰恰是新坑，最容易在半夜把你叫醒。
AI 依赖的三个新失败模式
传统后端挂掉的方式很干脆：超时、报错、返回 500。AI 依赖的挂法要暧昧得多：
第一，概率性正确。同样的输入，这一分钟答对，下一分钟答错。你不能用「跑通一次」来验证修复，只能靠第六章的评估跑通过率。
第二，静默变质。模型提供商会更新模型——同一个 API 名字，底下的权重换了。你什么都没改，系统行为变了。没有版本钉死和定期评估，你连「什么时候开始变差的」都查不出来。
第三，输出违反约定。你的下游代码期待一个 JSON，模型却输出了「我很抱歉，我无法……」。格式错误在 AI 系统里是常态，不是异常。
大白话：传统接口坏了会喊疼，AI 接口坏了会微笑。可靠性工程的第一原则就是别信它的微笑。
防线一：验证与修复，而非祈祷
既然输出违反约定是常态，就不要假设输出合法。每次模型返回后，先过一道程序化验证：JSON 能解析吗？必填字段在吗？数值在合理范围吗？验证不过，有两条路：重试（同一个请求再来一次，概率性错误重试往往就好）或者修复式追问（把错误信息喂回去：「你的输出缺了 amount 字段，请修正后重新输出」——模型很擅长这类自我修正）。第二章说的约束解码能从源头消掉一大半格式错误，这是机制优于祈祷的又一个例子。
防线二：降级链，而不是单点
模型提供商会限流、会抖动、会整个宕机。架构上必须预设一条降级链：首选模型超时或报错，切到备选提供商的同档模型；备选也挂了，降到更小更便宜的模型（质量下降但服务还在）；全挂，落到确定性兜底——一段写死的文案加人工接管入口。
降级链的关键不在「有备选」，而在事前演练：备选通道如果你从来没跑过流量，它大概率在真出事的那天也是坏的（密钥过期、配额为零）。成熟的团队会常态化让 1% 的流量走备选通道，既保持它「是热的」，也持续拿到两个模型的对照数据。
防线三：监控要盯分布，不只盯报错
传统监控盯错误率和延迟。AI 系统还得盯分布漂移：回答的平均长度是不是突然变了？拒答率是不是上升了？某个工具被调用的频率是不是异常？这些指标不变红，但它们的变化往往先于用户投诉。再配合抽样质检——每天随机抽一批真实对话，走一遍评估流程（第六章的裁判在这里复用）——你就有了系统「健康度」的连续曲线，而不是等用户来告诉你。
防线四：成本护栏
可靠性还包括「别把公司烧穿」。一个循环失控的智能体（第五章）、一个被恶意刷的公开入口，一晚上可以烧掉几个月的预算。所以按用户、按功能设 token 配额与消费告警，是可靠性工程的一部分，不是财务的事后算账。
到这里，系统能在混乱里活下来了。下一章把账算细：活下来之外，怎么活得便宜——成本与延迟的经济学。