那个让你的故障面成倍增加的供应商故障转移方案

当你的服务商故障转移（failover）第一次在生产环境中真正触发时，你会发现你真正构建的是什么。网关在几秒钟内完成了流量切换 —— 这一部分运行正常。接着，一种不同类型的事故开始了：12% 的响应中出现了格式错误的 JSON，之前从未被拒绝过的提示词开始遭到拒绝，延迟破坏了你的下游超时设置，面向客户的输出读起来就像是另一个产品。主服务商在 90 分钟后恢复了。而这次“成功”的故障转移留下了一个耗时 48 小时的事故复盘。

这是架构演示稿中最便宜的那一行所产生的账单：“备用服务商以实现韧性”。演示稿中从未提到，备用服务商需要专门的提示词、专门的评估套件（evals）、经过压力测试的容量，以及独立的值班手册。演示稿只说你不会宕机。在这点上它是对的，但在其他所有方面都错了。

在大多数情况下，团队交付的“多服务商冗余”本质上是单服务商生产环境，只是像二进制开关一样生硬地挂载了第二个服务商。提示词已经针对主服务商的特性打磨了六个月：它喜欢的格式、它稳定输出的 JSON 键名、它能按你原意解读的指令。评估套件是针对主服务商运行的。延迟预算、Token 估算、成本预测 —— 全部根据主服务商的行为进行了校准。然后，有人在配置文件中添加了一个备用 URL，就称该系统具备了冗余。

你未计算在内的耦合成本

提示词是与某个特定模型协商的合同。这份合同是无形的，因为它存在于提示词本身之中 —— 模型学会遵循的措辞，锚定在模型倾向产生的输出上的示例，以及预防该模型特定训练数据中故障模式的防御性指令。长达六个月的“智能体一直说 X，所以我们在系统提示词中加入了‘不要说 X’”的操作，产生了一个完全围绕单一模型行为精准塑造的提示词。

更换模型后，这种塑造便不再契合。新模型有不同的默认故障模式；旧的防御性指令现在变成了针对它从未遇到过的问题的 Token 税，而新模型真正存在的故障模式却没有被预防。当要求 Claude 进行微小修改时，它往往会过度解释代码编辑 —— 即便有明确指令，它也会输出整个文件而不是 diff。GPT 类模型通过隐藏的层级系统进行路由，在那里，“深入思考这一点”可能会在无警告的情况下将你切换到更慢、更贵的推理模型。除非有一行独立的“简洁明了。”强制限制，否则 Gemini 默认会输出冗长的多段文字。这些怪癖并非 Bug；它们是性格，而你的提示词已经针对其中之一进行了调优。

这种成本是隐形的，因为它从未出现在主路径上。评估套件通过了。客户反馈保持稳定。备用路径在你一年前某个周二下午编写的冒烟测试中看起来运行良好。它确实没问题 —— 前提是那些提示词是备用模型能够清晰解读的。而那些至关重要的提示词，即那些针对主服务商特定的故障模式进行了数百次小修复的提示词，在备用服务商上会悄然失效，这种失效只有在真实流量下才会显现。

“故障转移成功”到底意味着什么

当主服务商性能下降且网关绕过它进行路由时，会按顺序发生三件事。技术层面的故障转移成功了：备用服务商返回 200 状态码，延迟保持在 SLO 范围内，没有错误传导给客户端。语义层面的故障转移失败了：输出细微地改变了 —— 不同的格式、不同的拒绝模式、不同的推理深度、不同的工具调用格式（对于消耗它们的智能体层而言）。业务结果与这两者都产生了背离：支持票证增加，完成率下降，下游自动化由于预期主服务商的输出格式而发生中断。

团队看着仪表盘上显示的“故障转移已启动，流量正常运行”，并得出系统扛住了的结论。仪表盘在它所测量的层面是正确的。但它没有测量的那个层面，才是用户唯一能感受到的。

这种故障模式使得多服务商策略对那些没有在两方面都进行投入的团队来说，比单服务商策略更糟糕。单服务商团队将停机视为停机：清晰的错误预算消耗，明确的复盘，已知的成本。而没有支付“提示词可移植性税”的多服务商团队，则会将停机视为一种没人能完全界定的降级运行，因为提示词在压力下会产生不同的输出，而评估套件从未对此进行过测试。

2025 年的停机事件让这一点变得具体。仅在去年 12 月的一个月里，各大主要实验室的服务商就记录了数十起事故 —— 主要 AI 系统共发生了 47 起事故。没有故障转移的团队宕机了。拥有天真故障转移方案的团队在技术上虽然在线，但在停机期间却悄悄地向客户交付着不同的输出。第二组团队的事故检测、诊断和记录时间都比第一组长。

那个只有在周二才能通过的评估套件

几乎每个团队的评估套件都是针对主要供应商构建的。它可能运行在 CI 工作流上，并在环境变量中配置了主供应商的 API 密钥。通过/失败的阈值是根据主供应商的输出分布进行调整的。有些案例的编写方式隐含地假设了主供应商的行为：“拒绝案例的响应必须包含‘我无法’字样”或“JSON 输出必须使用键 X”或“答案必须在 200 个 token 以内”。这些断言是针对一个模型进行校准的；次要模型会失败，不是因为它错了，而是因为它的拒绝措辞不同，或者键的命名不同，或者默认运行时间更长。

修复方法是供应商对等评估：整个套件针对故障转移链中的每个供应商运行，准入门槛是对等性而非绝对分数，任何未能通过对等性测试的提示词都会被重新修改或标注为仅限主供应商。这听起来容易做起来难。编写主供应商评估套件的团队并不是以供应商无关的风格编写的；他们是按照“我们已知的主供应商行为”风格编写的。转换它们需要检查每一个案例，并询问该断言是关于任务本身的，还是关于某个模型执行任务的方式。大多数断言最后都被证明是关于模型的。

做得好的团队将评估套件作为一个矩阵运行：每当提示词或评估案例发生变化时，都会运行“每个提示词 × 每个供应商”。矩阵规模很大，以至于运行它变得非常复杂，但这正是重点所在——矩阵的大小就是多供应商策略的实际成本，而假装它很小是导致脆弱故障转移的错误所在。

持续故障转移是唯一有效的故障转移

一年只运行一次（当主供应商服务降级时）的故障转移路径，从未针对重要的流量分布进行过测试。冒烟测试是合成的。评估案例是精心挑选的。真正的提示词——用户实际发送的、在主供应商上花了六个月才摸透的长尾分布——从未以生产规模冲击过次要供应商。它们第一次这样做是在发生事故期间，值班团队正试图同时阅读仪表盘并重建上下文。

弥补这一差距的模式是影子流量：在每次请求时，一小部分真实的生产提示词异步通过次要供应商运行，并记录和比较输出。主供应商仍然为用户提供服务；次要供应商则以生产速率针对生产分布进行演练。当次要供应商的输出在关键方面偏离主供应商时，比较日志会在故障迫使问题出现之前发出警报。

同类想法的一个较弱版本：定期故障转移演练。在一个预先宣布的时间窗口内，网关将一大部分流量路由到次要供应商，团队观察影子比较本来可以持续发现的回归问题。演练更容易设置，但更难维护，因为它们需要协调；团队在截止日期压力下会跳过它们，直到非计划演练——即真正的停机——到来时才发现差距。

交付稳健故障转移的团队不会将次要供应商视为二进制开关，而是将其视为一条持续预热的路径。切换供应商的值班手册是一份简短的文档，因为切换一直在发生。成本仪表盘包含了次要供应商的支出，因为次要供应商一直在产生支出。评估流水线以对等性作为合并的准入门槛，因为对等性是合同，而不是“在主供应商上的分数”。

多供应商是双倍的提示词工程投入

产生脆弱故障转移的思维模式是将多供应商视为一种基础设施决策：选择一个网关，配置链路，然后上线。而产生稳健故障转移的思维模式是将其视为双倍的提示词工程投入：你为主要供应商调整的每一个提示词，也必须为次要供应商进行调整；你编写的每一个评估，都必须在两者之间运行；你修复的每一个回归，都必须在两套提示词集中同时修复。

成本是真实的，而且是架构方案中没有提到的成本。一个在两个供应商上运行生产环境的团队，实际上在做大约两倍的提示词工程工作，而不是在冗余的运行时上做同样的工作。不支付这项成本的团队交付的是选择权——技术上绕过故障的能力——而不是可靠性——即在故障情况下产生等效输出的特性。没有对等性的选择权，就像是披着风衣的第二次事故。

值得明确做出的决策是你想要哪一种。有些工作负载不需要对等性：一个低风险的摘要端点可以容忍在故障转移期间出现明显不同的输出，因为代价很小，而替代方案是服务宕机。有些工作负载需要严格的对等性：下游系统解析的结构化输出 API 不能容忍键名更改或格式漂移。大多数团队都有这两种工作负载，并且不加区分地进行路由，这就是为什么高对等性需求的工作负载默认会受到低对等性待遇的原因。

你必须首先回答的架构问题

在添加备用供应商之前，需要回答的问题不是“选哪家”，而是“输出的一致性（parity）意味着什么，以及我们需要投入多少来维持这种一致性”。如果答案是“我们承担不起”，那么正确的做法通常是选择单一供应商并建立清晰的降级路径——明确的错误消息、排队重试、向用户展示当前状况的状态页面——而不是采用带有隐藏输出偏移（output drift）的多供应商方案。

如果答案是“我们愿意承担这一成本”，那么工作流程应该是结构化的：采用一种与供应商无关的 Prompt 格式，让两个供应商都能运行（这通常意味着重写 Prompt，使其更加明确，减少对特定模型提示词的依赖）；建立一套一致性评估套件，将两个供应商的评估作为合并代码的门禁；向备用供应商发送持续的影子流量（shadow traffic）以保持其活跃；以及编写值班文档，将供应商切换视为常规操作而非紧急事件。

那些宣称“通过备用供应商实现韧性”的项目方案，往往还没经历过有人追问“韧性到底意味着什么”的会议。韧性并非没有停机时间，而是在故障发生时仍能保持等效的行为。如果团队在没有实现后者的情况下交付了前者，那他们实际上是购买了一个新的事故通道，并将其称为一项功能。

多供应商策略是严肃的 AI 系统中杠杆率最高的架构决策之一。它也是最被低估成本的决策之一。代价不在于金钱，而在于团队承诺永远进行的并行工作。有效的故障切换（Failover）是一项持续的实践，而不是一个配置开关。能从第一次真实停机中领悟到这一点的团队是幸运的。而从第二次停机（由故障切换本身引起的停机）的事后总结中才学到这一点的团队，则是我们大多数人的写照。