很多团队在做 AI 网关时，会先盯着功能完整度：统一鉴权、统一模型 ID、统一日志、统一路由。等这些都搭起来之后，才开始面对一个更现实的问题: 平台到底允许自己失败到什么程度。
传统基础设施团队对“错误预算”并不陌生。它的核心思想很简单，系统不可能永远零故障，所以与其假装不会出错，不如明确允许多少错误发生，并用这个预算约束发布节奏、策略激进程度和恢复动作。到了 AI 网关场景，这个思路反而更重要，因为这里的失败来源比普通 API 更多。
真正麻烦的地方在于，AI 网关不像传统 HTTP 代理那样只负责转发。它通常还承担统一认证、模型映射、策略选择、限流、回退、审计和成本控制。也就是说，用户看到的一次“调用失败”，背后可能既有上游模型问题，也有策略误判、超时边界设计不当、路由抖动、缓存失效甚至预算规则冲突。没有错误预算时，团队往往会把这些异常都当作孤立问题处理，最后系统像是在不断修补，但整体稳定性却没有真正上升。
AI 网关的失败不只是 500
如果只把 5xx 当成失败，AI 网关会遗漏大量真正影响业务的异常。对用户而言，下面这些情况其实都已经是失败：
- 请求虽然成功返回，但时延已经远超可接受阈值。
- 主路由连续失效，系统不得不频繁回退到更贵的 provider。
- 输出结构不稳定，导致下游流程需要人工接手。
- 工具调用成功率下降，表面上返回正常，实际上结果不可用。
- 某个 provider 在特定地区波动，只有部分用户受影响。
这意味着 AI 网关的错误预算，不应该只围绕 HTTP 状态码设计，而应该围绕“业务可接受的失败”设计。
换句话说，错误预算的统计口径必须站在用户和业务这边，而不是站在服务器日志这边。一个客服机器人在 12 秒后返回了正确答案，日志里也许会记作成功，但如果用户原本只能接受 4 秒内的首响应，那这次请求在体验上已经是失败。一个工作流平台返回了格式合法的 JSON，但字段遗漏导致后续审批无法推进，这也不是“轻微瑕疵”，而是标准的业务失败。如果预算没有把这些情况计入，团队就会持续低估系统真实的脆弱程度。
预算一定要按任务层级拆分
所有请求共享同一份错误预算，通常没有意义。实时问答、批量任务、结构化工具调用、长文本分析，这些任务的容错空间完全不同。一个客服 Copilot 的同步请求，如果 P95 时延突然涨到 10 秒，哪怕最后成功，也已经接近失败；但一个离线批处理任务慢两分钟，未必会产生严重影响。
因此更合理的做法，是按任务类型拆预算：
- 实时交互链路，优先约束时延和首响应失败。
- 工作流任务，优先约束结构化输出和工具调用成功率。
- 批量任务，优先约束吞吐稳定性和总体完成率。
- 高风险任务，优先约束错误回答和错误执行。
预算一旦拆开，平台的路由和回退策略才有依据。
这里的关键不是“分类做得多细”，而是预算必须和任务价值相关。越接近用户实时感知、越接近关键业务动作的链路，预算就应该越严格；越偏后台、越可重试、越可延迟处理的任务，预算就可以相对宽松。如果平台没有做这层拆分，就会出现两个极端：要么为了满足最严格链路，把所有任务都过度保护，导致成本和复杂度上升；要么为了追求统一管理，把高风险链路也按宽松标准对待，最后在关键时刻掉链子。
预算不是一张百分比表，而是一套决策边界
很多团队在讲错误预算时，只会说“我们允许 99.9% 可用”。这个数字当然有用，但如果它不能进一步指导系统行为，那就只是一张好看的表。真正有效的错误预算，应该能明确回答几个问题：
- 当预算消耗到什么程度时，要暂停发布。
- 当某个 provider 明显不稳定时，要不要强制降权。
- 当回退频率异常升高时，是优先保成功率还是保成本。
- 当某条链路连续逼近预算上限时，哪些实验功能必须先停掉。
这些决策边界越清晰，平台越像一个可运营系统，而不是一堆随缘生效的策略集合。
发布节奏应该受预算约束
错误预算最实际的价值之一，是它能约束发布动作。没有预算时，系统的更新节奏往往只由“功能准备好了没有”决定；有了预算之后，团队会开始意识到，功能准备好了，不等于现在适合发。
举个很常见的场景。假设最近两周某个主要 provider 的尾部时延一直不稳定，主路由已经依赖回退撑住成功率。这时候即使新的路由策略已经开发完成，是否应该立刻上线，就不该只看功能验证结果，而要看当前剩余的错误预算。如果预算已经很紧，再叠加一次高风险策略变更，就等于让系统在脆弱状态下继续冒险。
很多成熟平台最终都会形成一种纪律：当错误预算进入高消耗状态时，变更窗口自动收紧，新功能上线放缓，优先级转向恢复稳定性。听起来像是在拖慢迭代，但从长期看，这恰恰是在保护迭代能力。因为没有这层约束，团队最终会被越来越频繁的线上问题拖入被动救火。
路由、回退和预算必须联动
AI 网关和普通 API 网关最大的不同，是它几乎总要面对“不只一条路”的选择问题。主路由失败了，要不要回退；回退失败了，要不要继续试；某个 provider 便宜但波动大，要不要让它承担主流量；另一个 provider 更稳定但更贵，什么时候让它接管。这些决策都在消耗不同维度的预算。
因此预算设计不能和路由策略割裂。一个实用的做法通常是：
- 用稳定性预算约束主路由实验比例。
- 用成本预算限制高价回退链路的持续使用时间。
- 用时延预算限制最多允许几层回退。
- 用任务风险等级决定是否允许质量降级。
这样一来，预算不再只是“月底看报表时才拿出来讨论”的东西，而是实时塑造路由行为的运行时约束。
预算也要分组织和客户看
如果平台开始服务多团队、多项目甚至多租户，那么错误预算还需要更细。因为不是所有业务都承受得起同样的风险。一个内部实验项目，允许策略更激进一些；一个面向付费客户的正式产品，则可能需要更保守的保护边界。把所有组织混在一起统计，会掩盖很多真实问题。
更合理的方式，是至少保留三层视角：
- 平台总预算，用来判断整体运行是否健康。
- 产品线预算，用来判断不同业务流量的稳定性压力。
- 关键客户或关键场景预算，用来保护最敏感的部分。
只有这样，平台才能在“整体没崩”的情况下，依然发现某个高价值客户其实已经持续处于糟糕体验中。
预算改变的不只是系统，也会改变讨论方式
一旦平台有了清晰的错误预算，很多争论会变得简单。产品不再只是问“这版能不能发”，而是看这次变更会不会明显消耗稳定性预算；工程也不再只说“理论上应该没问题”，而是要拿出预算影响的证据；运营不再只是抱怨上游波动，而是能明确指出哪类业务正在提前烧掉平台的容错空间。
更重要的是，错误预算会迫使团队承认一个现实：稳定性不是免费的。每一次激进实验、每一次快速接入新 provider、每一次把高风险功能直接推到默认路径，都是在消耗预算。只有这件事被看见，平台才会真正进入可管理状态。
常见误区：把预算做成复盘材料
错误预算最常见的失败方式，是被做成周报里的一个数字。大家都知道它存在，也会在问题发生后引用它，但没有任何实时动作和发布纪律与之绑定。结果就是预算变成一种装饰性治理术语，看上去很成熟，实操上却没改变任何事情。
另一个误区，是把预算目标定得过于理想化。比如平台还处在快速演进阶段，却一开始就给所有链路上 99.99% 的统一目标。这会把团队推向两个不健康方向：要么指标长期不达标，大家逐渐对预算失去敬畏；要么为了守住数字，系统过度保守，创新能力大幅下降。真正合理的预算，应该和平台当前成熟度、业务风险和迭代阶段相匹配。
预算需要和告警体系一起工作
如果错误预算要变成控制器，而不是复盘材料，它就必须和告警体系打通。很多平台虽然有预算概念，但告警依然停留在 CPU、错误码和延迟阈值层面。这些告警当然必要，却无法告诉你“预算正在被谁、以什么速度烧掉”。
更有用的做法，是围绕预算建立分层告警：
- 预算快速消耗告警，识别某类请求是否正在异常燃烧容错空间。
- 预算归因告警，帮助快速定位是 provider 波动、策略变更还是流量结构变化。
- 预算恢复告警，提示系统是否已经回到可以重新开放实验的区间。
这样一来，预算不再只是一个最终结果，而是一个持续变化的运行信号。团队看到的不再只是“今天坏了多少”，而是“为什么正在变坏，以及接下来应该先做什么”。
周期复盘的重点不是追责，而是重估分配
预算机制真正跑起来后，团队还需要定期复盘，但复盘的重点不应该是找人背锅，而是判断预算分配本身是否合理。比如某条链路总是在高负荷时提前烧光预算，这可能不是某次故障引起的，而是最初对业务风险的估计过低；又比如某些实验流量长期没有真正影响预算，说明这部分限制可能过于保守。
因此预算复盘更应该回答这些问题：
- 现在的预算分配是否仍然匹配真实业务价值。
- 哪些任务已经需要更严格的目标，哪些任务可以更灵活。
- 某些回退策略是否在偷偷用成本换稳定，而团队之前没看见。
- 哪些发布纪律是有效的，哪些只是让系统变慢却没有明显收益。
只有不断重估预算，平台才能避免把一套曾经合理的规则，慢慢变成新的僵化约束。
结语
AI 网关最终不是一个演示层，而是一层基础设施。既然是基础设施，就不能只讲能力，不讲稳定代价。错误预算的意义，就在于把“系统允许多冒险”这件事，从感觉判断变成明确规则，把“哪里已经开始变坏”从事后抱怨变成实时信号。
当预算真正进入路由、发布、回退和组织协作之后，平台才会从“能接很多模型”进化为“能长期稳定地驾驭很多模型”。这两者听上去只差一步，但中间真正的分水岭，往往就是有没有把错误预算当成运行系统的一部分。
很多系统虽然记录了成功率和时延，但这些数据只停留在看板上，没有真正参与控制。错误预算真正有价值的地方，在于它能驱动动作。例如：
- 当某条链路的预算快速消耗时，暂停激进实验流量。
- 当某个 provider 持续抖动时，自动降低其主路由权重。
- 当某类请求的尾部失败上升时，收紧回退层级和总超时。
- 当预算恢复后，再逐步放开新策略的灰度比例。
换句话说，错误预算不是给复盘会看的，而是给运行系统用的。
它也会改变团队协作方式
一旦平台有了清晰的错误预算，很多争论会变得简单。产品不再只是问“这版能不能发”，而是看这次变更会不会明显消耗稳定性预算；工程也不再只说“理论上应该没问题”，而是要拿出预算影响的证据。久而久之，发布流程会从拍经验变成看约束。
结语
AI 网关最终不是一个演示层，而是一层基础设施。既然是基础设施，就不能只讲能力，不讲稳定代价。错误预算的意义，就在于把“系统允许多冒险”这件事，从感觉判断变成明确规则。这样平台才可能在迭代速度和运行可靠性之间，找到真正可持续的平衡。