AI 网关：那个没人点名的单点故障 (SPOF)

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

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

令人不安的是，没有人刻意决定要这样做。网关积累责任的方式就像厨房杂物抽屉积累橡皮筋一样。每一次增加功能都是正确的局部决策 —— 缓存可以省钱，治理可以规避法律风险，评估门控可以防止糟糕的 Prompt 上线 —— 但累积效应是产生了一个单一进程，其爆炸半径让任何单一供应商都相形见绌，而对其投入的 SRE 严谨性却远不及保护（比如）支付服务的程度。

网关里到底装了什么

审视一下一个成熟的 LLM 网关内部运行着什么，爆炸半径就显而易见了。统一的 API 契约是可见的部分 —— 一个兼容 OpenAI 的端点，在幕后转换为五十个供应商的接口。但这只是最薄的一层。

底层坐落着重试和故障转移策略：哪些错误触发重试，哪些触发故障转移到备用供应商，每类错误的指数退避策略是什么，以及哪些流式传输错误可以透明地重试，哪些必须暴露给客户端。来自主供应商的 503 错误应该跳到备份；而 400 错误则不应该，因为在任何地方重试格式错误的请求只会白白增加延迟。这种逻辑在正确时是隐形的；在出错时，它会将上游故障放大为面向用户的错误。

然后是 Prompt 缓存 —— 既包括将重复 Prompt 变为免费查询的精确匹配缓存，也包括能识别出 “什么是 AI” 和 “解释人工智能” 是同一个问题的语义缓存。对于高流量功能，缓存命中与未命中的成本差异大约是十比一，因此一旦你达到任何有意义的规模，这一层就是必选的。绕过它意味着网关宕机后倾泻到供应商身上的每一个请求都要重新支付这笔费用。

评估门控（eval gate）是大多数工程师低估的一层。新的 Prompt 版本、新的工具定义、新的模型版本都流经一个 CI 风格的检查，该检查针对用例库运行它们，如果触发回归阈值则阻止部署。这个门控之所以设在网关中，是因为网关是唯一能看到每个请求和响应的地方 —— 这使其成为了天然的执行点，也是计算回滚信号唯一容易的地方。

可观测性架构决定了每个仪表盘的样子、记录的内容、为搜索索引的内容，以及按团队和功能划分的成本分摊情况。如果网关发出的数据格式错误，下游的每个仪表盘都会出错；如果网关停止发出信号，每个仪表盘都会以一种协同的方式变黑，看起来就像 “AI 在到处都坏了”，因为从仪表盘的角度来看，事实确实如此。

再加上治理 —— PII 脱敏、Prompt 注入防御、按团队进行的频率限制 —— 以及存放每个模型厂商密钥的凭证库，你便拥有了一个同时作为公司每个 AI 功能的策略平面、数据平面、成本平面、评估平面和可观测性平面的服务。

为什么网关宕机比供应商宕机更严重

供应商宕机通常是优雅的，这一点大多数团队在亲历网关宕机之前是体会不到的。当 OpenAI 出现一个小时的服务降级时，网关的故障转移逻辑会将流量切换到 Anthropic 或自托管的备用方案。延迟会增加，成本会略微上升，一小部分边缘案例会失败，但系统大部分时间是正常工作的。爆炸半径被限制在那些配置了故障转移的路径内。

而当网关本身宕机时，所有这些机制都不再运行。每个 AI 功能会同时失去其故障转移、缓存、评估门控、可观测性和密钥访问。原本会告诉你出了什么问题的仪表盘正处于同一场宕机的下游。本应绕过问题的重试策略就住在那个崩溃的对象里。本可以让紧急热补丁绕过网关直接调用供应商的密钥，被锁在网关内部的保险库里。

这种情况的残酷版本发生在网关还足够健康可以接受连接，但又不够健康以至于损坏请求时 —— 比如发布了一个错误的可观测性架构，或者一次交换了两个供应商名称的配置推送，或者是仅在缓存未命中负载下才出现的内存泄漏。网关返回 200 OK，下游系统信任它，错误行为在任何报警触发前就已传播到各处。供应商宕机是一个干净的 503；而网关的“欠压”（brownout）则是无声的污染。

有一种负载模式会让情况变得更糟。当网关从宕机中恢复时，每个重试的客户端和每个排队的请求会同时冲击它。缓存是冷的，所以平时 80% 的缓存命中率现在变成了 0%。每一次未命中都会流向供应商 —— 供应商现在看到的是来自公司每个团队的聚合“惊群效应”，而且失去了网关平时提供的频率限制平滑处理。恢复的成本比宕机本身还要高。

与爆炸半径相匹配的模式

修复方法并非“不要构建网关”。一旦你拥有超过几个 AI 功能，网关在缓存命中、治理以及无需修改应用代码即可切换供应商方面带来的收益就会超过其成本。修复方法是将网关视为它本应是的承重基础设施，并具备相应的运维纪律。

具有独立控制平面的多区域部署。 网关是一个有状态的服务——它持有缓存、密钥材料、部署状态——而单区域部署会继承该区域网络和控制平面的故障模式。多区域意味着两件事：在多个区域部署网关副本，并在前端进行健康检查路由；以及控制平面的独立性，这样一个推送到区域 A 的错误配置不会在同一分钟内污染区域 B。缓存局部性问题使这比听起来更难，但如果不这样做，区域性的云事故就会演变成全公司的 AI 停摆。

紧急绕过路径 (Break-glass bypass path)。 每个依赖网关的团队都需要一条经过文档记录并定期测试的代码路径，该路径可以直接调用供应商，并使用检入到网关不拥有的机密存储中的凭据。这不应该是常规路径。它绕过了缓存、评估门控、可观测性架构、治理层——即网关存在的所有意义。但当网关在凌晨 3 点卡死时，替代方案是每个 AI 功能都处于瘫痪状态，直到网关团队醒来。绕过路径应该足够丑陋，以至于没人会随便使用，但又应该足够易用，以便值班人员通过单个命令即可切换。每季度练习一次是确保它仍然有效的唯一方法。

针对网关边界的契约测试。 网关与每个下游服务都有 API 契约。这些契约会发生漂移——字段被重命名、错误格式改变、流式传输协议被调整——而下游服务直到生产环境才会注意到。在两端固定契约的契约测试可以捕捉到这一点。同样的纪律也适用于供应商边界：网关内的每个供应商适配器都应该有一个契约测试，当供应商更改其响应格式时，该测试会响亮地报错，而不是让更改泄露到面向用户的输出中。

缓存预热和优雅恢复。 从网关故障中恢复不应该是简单的“重新开启”。它应该是“以 10% 的流量重新开启，让缓存预热，然后逐步增加”。否则，恢复过程会因冷缓存的惊群效应而冲击上游供应商。这是标准的服务恢复纪律，应用到了一个大多数团队尚未意识到它是服务的服务上。

网关不拥有的可观测性。 如果每个关于 AI 行为的仪表板都由网关自身的可观测性架构提供数据，那么网关对其自身事故就拥有了可见性特权。至少需要存在一条平行的可观测性路径——Sidecar 指标、独立的追踪导出器、指向不同接收端的异步事件流——这样当网关出故障时，依然有人能看到发生了什么。

为什么团队会低估这一点

诚实的回答是，网关累积爆炸半径的增量非常小，以至于没有人需要提交一份名为“让我们集中化处理每个 AI 故障模式”的设计文档。上线缓存是因为节假日发布带来的成本激增是真实的。上线评估门控是因为一个错误的 Prompt 进入了生产环境并触发了报警。上线可观测性架构是因为财务部门想要按团队进行成本归集。每一次发布都是正确的决定。直到网关宕机那天，有人问为什么公司无法绕过它进行发布时，累积的重量才变得显而易见。

第二个原因是，构建网关的人通常是考虑抽象的平台工程师，而在生产环境中运行它们的人是考虑可用性的 SRE。这两种思维模型之间的交接正是 SRE 纪律缺失的地方——尽管网关持有缓存、凭据和路由状态，它却获得了无状态服务的部署流水线；尽管它执行策略，它却获得了“瘦代理 (thin proxy)”的监控；尽管它的爆炸半径堪比 0 级 (tier-zero) 服务，它却获得了 2 级服务的值班轮换。

第三个原因是，故障模式足够罕见，以至于被低估了。供应商故障每周都会发生；网关故障每季度或半年才发生一次。频率使团队误以为网关是可靠的，而事实是它的故障频率低但灾难性强——这恰恰是需要额外 SRE 关注而非减少关注的特征。

架构层面的承认

网关不再是设计文档中所描述的那个抽象层。它是一个承重的基础设施，其爆炸半径是产品整个 AI 功能的覆盖面。能从这种认识中幸存下来的团队，是那些明确命名它、赋予其与其爆炸半径相匹配的服务等级分类，并像对待支付和认证系统一样，应用相同的多区域、紧急绕过和契约测试纪律的团队。

不这样做的团队将继续像运行原始设计文档中的瘦代理那样运行它。他们将继续增加职责——护栏、Prompt 管理、Agent 编排、MCP 服务器注册——直到网关成为 AI 栈中隐性的操作系统。最终，在某个平静的周二下午，它会宕机 40 分钟，每个产品中的每个 AI 功能都会随之瘫痪，而复盘得出的结论将是：这个抽象层，一直以来，就是系统本身。

成熟的做法是承认这已经是事实，并据此进行运维。