182 篇博文 含有标签「reliability」

这种说辞听起来很负责任。“我们别在各处硬编码 OpenAI —— 我们在前面加一层薄薄的抽象，这样以后如果需要，我们可以随时更换供应商。”两年后，那个“薄薄的抽象”变成了一项拥有自己部署流水线、SRE 值班表、拦截糟糕 Prompt 的评估门控、每年节省七位数资金的语义缓存、带有针对特定供应商退避机制的重试策略、所有仪表盘都依赖的可观测性架构，以及一个存放着六家模型厂商凭证的密钥库的服务。公司里的每一个 AI 功能最终都汇聚于此。

它也几乎是在无意间，成为了整个技术栈中爆炸半径最大的单点故障（SPOF）。当主要 LLM 供应商宕机时 —— 2025 年，OpenAI 自 1 月以来被记录了 294 次停机事件，而 Anthropic 仅在 12 月就记录了 184.5 小时的总客户影响 —— 网关会自动绕过它，大多数用户甚至察觉不到。而当网关本身挂掉时，每个产品中的每个 AI 功能都会同时停止工作，原本应该触发的故障转移根本没有机会执行，复盘报告的开头往往是：“我们为了隔离供应商宕机影响而构建的抽象层，本身成了那场宕机。”

太平洋时间凌晨 2 点，你的评估套件（eval suite）在平静的提供商环境下全绿通过。上线前一晚 11 点，QA 进行了冒烟测试。功能正式发布。到了周二上午 10 点（东部时间），你的 p95 延迟比你签字认可的仪表盘高出了 40%，你的智能体（agent）在一个包含六步的计划中丢掉了最后一个工具调用，而你的支持信箱塞满了听起来如出一辙的工单：“今天早上 AI 表现很奇怪。” 谁都没错。模型也没错。错的是评估集 —— 它从未见过饱和的提供商环境，因此对于当队列深度翻倍、截止时间预算（deadline budget）崩溃时功能会如何表现，它无法给出任何参考建议。

提供商负载不仅仅是一个伴随质量副作用的延迟问题。它是你的模型和智能体循环接收到的输入的一种分布偏移（distribution shift），而你所信任的每一个质量信号，都是建立在这个分布中错误的那一截之上的。解决办法不是换一个更快的区域或更好的模型。解决办法是停止假装你的评估框架是在与你用户相同的世界中进行采样。

每个将智能体（agent）投入生产环境的团队，最终都会遇到类似的事故。智能体进入了一个无法退出的状态。它在六个小时内反复调用同一个工具，只是参数在表面上略有不同。它在两个前提条件互斥的计划之间摇摆不定。它每隔两百毫秒重试一次瞬时的 429 错误，一直持续到天亮。它生成了一个包含百万 token 的计划，却从未执行。等到有人察觉时，token 账单已达四位数，下游 API 被限流，客户会话已超时十二次，而值班工程师正被针对同一根因的三个不同告警狂轰滥炸。

每个团队首先想到的解决方法都是步骤计数预算（step-count budget）。将智能体限制在 20 次迭代。限制在 50 次。定个数字，然后上线。步骤预算确实让事故报告消失了，但它并没有消除底层问题 —— 一旦你理解了其中的机制，你就会发现步骤预算相当于智能体世界里的家用保险丝：它是在损害造成之后才熔断的，保险丝盒本身现在成了维护负担，而下次发生故障时，你的本能反应是换一个更大规格的保险丝，而不是去追究到底哪里短路了。

一个团队将自我批判循环（self-critique loop）投入生产，因为基准测试数据看起来令人无法拒绝：Self-Refine 报告称在七项任务中平均提升了 20% 的绝对性能，Chain-of-Verification 在问答任务中将幻觉减少了 50% 到 70%，而在一篇被广泛引用的论文中，反思提示词（reflection prompts）将数学方程的准确率提高了 34.7%。一个月后，财务审查揭示了账单。产品的单次请求成本大约增加了三倍，p99 延迟增加了三倍，而实际在生产流量中表现出的质量提升更接近 3% 而非 30%。自我批判循环确实做到了它宣传的效果，只是团队从未计算过它的代价。

这就是自我批判税：一种在 PPT 上看起来像是免费提升质量，但在发票上却表现为结构性成本增加的可靠性模式。模式本身是合理的——在某些实际情况下，“生成并验证”确实是正确答案。失败的原因在于将其作为默认配置而非经过校准的干预手段进行部署，并在季度的错误时间点发现“模型检查自己的工作”实际上是一项采购决策。

你的可观测性技术栈中的单工具仪表盘讲了一个令人宽慰的谎言。search_listings 的成功率是 96%，显示为绿色。book_appointment 是 95%，也是绿色。而连续调用这两个工具的智能体（agent）三周以来的成功率一直只有 78%，却没人能解释原因。原因不在任何一个工具内部，而是在它们之间的缝隙里——那个没有任何仪表盘面板覆盖的地方。

组合不是加法。当工具 A 的输出流入工具 B 的输入时，故障面并不是 B 对“有效调用”的狭隘定义下的 1 - (0.96 × 0.95)。它是 A 在 B 的标准下所有微妙偏差方式的完整笛卡尔积：A 返回的日期格式是 MM/DD/YYYY，而 B 期望的是 ISO 8601；返回的价格单位是分，而 B 解析的是元；分页游标指向了最后一个结果之后的一项；或者上游服务昨天重命名了一个实体 ID。这些情况都能顺利通过 A 自身的契约测试（contract tests），但每一个都会导致 B 崩溃。团队的单工具可靠性指标永远看不到这一点，因为按各自的标准来看，每个工具都运行良好。

你的 LLM 供应商声称 99.95% 的可用性。你的状态页显示绿色。你的延迟仪表盘在 SLO 范围内。但你的产品依然坏了 —— 助手在今天早晨开始拒绝常规请求，支撑下游解析器的 JSON 输出从紧凑变得啰嗦，而且你用模型分拣的支持工单中有三分之一返回了 “我无法提供帮助”。所有这些响应都在 800ms 内返回了 200 OK。它们都没有违反 SLA。这个 SLA 覆盖的是你实际上并没有遇到的故障模式。

这是采购谈判中没人预估到的差距。供应商出售的是 可用性（availability） —— 一种请求层面的承诺，即 API 及时响应了；而产品团队消费的是 能力（capability） —— 一种请求层面的承诺，即答案是可用的。这两者不是同一个指标，而混淆它们的团队离发现其中的区别只差一次静默的模型升级。

仪表盘显示 0.5% 的请求触发了回退（fallback）。仪表盘这么显示已经持续六个月了。直到有人从头重新运行遥测数据（telemetry），发现次级模型正承载着 38% 的流量，而预设回复（canned-response）层级则处理了另外 9% 的流量。团队在路线图评审中一直讨论的尖端模型“主路径”，实际上已沦为少数派体验。没有人注意到这一点，因为没有任何警报被触发 —— 每次降级都是一个小规模的、理由充分的、局部正确的决定，而累积的偏差从未超过任何人事先设定的阈值。

这就是我想要定义的失效模式：成了默认项的回退机制。这不是故障，也不是单个组件的回归。它是产品表面的缓慢轮转，退而求其次的路径不再是安全网，而成了核心体验。团队的心理模型与生产现实渐行渐远，而这种差距是隐形的，因为现有的度量指标（meters）旨在检测失败，而非检测组合（mix）。

我要提出一个更强有力的观点：如果你的 AI 功能拥有两个以上的服务层级，那么你的层级组合（tier mix）本身就是一个 SLO。如果你没有测量它，你其实并不知道你发布了什么。

这张图片是一张红色八角形停止标志的照片。有人在中间的单词上贴了一张小贴纸，上面写着“YIELD”（让行）。你问多模态模型：“这个标志写了什么？”模型回答：“该标志指示驾驶员在交叉路口让行给迎面而来的车辆。” 表现得既自信又流利，却既不忠实于视觉证据，也不忠实于文本证据。它是一个混合体，在产生分歧的真相通道之间采取了折中方案。

这种故障模式目前还没有一个统一的名称。研究多模态幻觉（multimodal hallucination）的研究人员将其称为“语义幻觉”（semantic hallucination）、“跨模态偏差”（cross-modal bias）或“模态主导”（modality dominance），具体取决于撰写论文的细分领域。交付文档 AI、截图智能体和缺陷检测系统的从业者每周都会遇到这种情况，并在事故复盘中将其描述为“模型只是在瞎编”。它不是瞎编的。这是一种在最终层融合了两个通道、却没有任何原语来表示通道意见不一情况的架构的可预测输出。

周五下午，一封客户成功（customer-success）邮件发了过来：“德国用户的模型效果变差了。”团队打开评估仪表板，评分没变，p95 延迟也很正常。配置中的模型名称还是三周前发布的那一个。一切都没变。但其实有些东西变了。上个迭代中，美国的端点悄悄上线了新一代模型，而欧洲的端点由于供应商还没完成地区性的分阶段发布，仍在使用旧版本。而位于两者之前的负载均衡器，则在团队的所有仪表板上掩盖了这一差异。

这就是所谓的区域性模型发布博弈。你的“单一模型”抽象并不是单一的。当供应商跨大洲分阶段发布时，它就开始分化了——而在大多数年份、对大多数供应商而言，这种情况在大多数时间里都在发生。当这种情况发生时，客户端 SDK 中的版本字符串并不会改变。你的追踪（traces）看起来一模一样。你与供应商签订的合同也没有做出其他承诺。而你赖以捕捉行为回归的评估套件，几乎肯定运行在某个地区的 CI 机器上，并访问地理位置最近的端点。

你的契约测试通过了。Schema 校验器显示正常。工具返回的数据结构与上个季度完全一致。然而，面向用户的回答已经悄无声息地错了六个星期。

这就是契约测试从未设计用来捕捉的故障模式。契约测试验证的是传输格式没有改变——比如 search() 是否仍然返回 { results: [{ id, title, score }] }，create_event 是否仍然接受 ISO 8601 字符串，地理编码器是否仍然输出 { lat, lng }。它们无法捕捉到的是：搜索端点开始按新近度而非相关性排序的时刻；日历 API 在欧盟地区静默地将你 14:07 的开始时间吸附到 14:00；地理编码器在同一个模糊的多边形内选择了一个不同的点；或者作为工具的 LLM 分类器在稳定的端点后升级到了新模型，导致你的评估集从未采样过的某个类别中误报率上升了四个百分点。Schema 没变，但行为变了。你的智能体继续读取着代表通过的绿色勾选，并产生了没有任何错误日志捕捉到的退化答案。

智能体自信地告诉用户：“我已经发送了确认邮件，并将退款退回到你的账户。”追踪记录很干净：两次工具调用，均返回 {"success": true}，模型生成了精练的摘要，对话在 3.2 秒内结束。一周后，客户发起投诉，因为邮件从未送达，退款也从未入账。审计日志中全是绿色的勾选标记。没有任何环节失败——除了实际的工作本身。

这就是在大多数智能体技术栈中尚未被命名的故障模式：撒谎的工具。这里的“撒谎”并非恶意——它们返回了其契约规定的响应。这种谎言是结构性的。HTTP 层返回 “200 OK” 是因为请求被接受了，而不是因为操作完成了。邮件服务商返回 success: true 是因为消息进入了发送队列，而不是因为它已经发出了。数据库写入返回且无报错，是因为它写入了一个从未同步的副本。被训练成“乐于助人”且在“绿色代表完成”的示例上训练过的模型，将这些信号编织成一份自信的摘要，然后继续下一步。

用户点击发送。智能体被配置了 30 秒的时间配额。规划器（planner）检查任务，发现一条耗时约 12 秒的“深度研究”路径和一条耗时 3 秒的“快速查询”路径，并自信地选择了深度路径，因为“我们有充足的时间”。28 秒后，响应返回，比团队上季度发布的 SLA 晚了 2 秒。仪表盘显示，智能体的推理是正确的，重试逻辑是正确的，工具调用也成功了。没有人能解释为什么用户的加载动画转了 46 秒。

这个 bug 不在任何单一组件中。它存在于组件之间的缝隙中，存在于一个系统从未想过要刷新的值里：智能体对于还剩多少时间的认知。在请求受理与模型的下一个规划步骤之间，发生了一次透明重试，挂钟时间在流逝，但截止时间的元数据却没有更新。模型现在正根据它在 15 秒前就已经花掉的预算进行推理，而它自己对此一无所知。