当团队开始同时接入 OpenAI、Anthropic、Gemini、DeepSeek 和更多区域化模型时，问题很快就不再是「怎么调用」，而是「怎么长期稳定地调用」。
最早踩过的坑其实很典型，而且几乎所有做过多模型接入的团队都会碰到：
- 同一个模型在不同供应商侧的可用率差异很大。
- 高峰时段的延迟波动会直接放大到业务接口。
- 价格变化、限速规则和地区差异，使得静态配置很快失效。
- 某些模型版本升级后，输出风格、上下文限制和错误码语义会一起变化。
所以我们没有把 Cloubic 设计成单纯的代理层，而是把它当作一个持续做决策的调度系统。
统一 API 当然重要，它解决了 SDK 分裂、认证方式不一致、错误格式难以兼容等工程问题。但一旦调用规模变大，真正决定体验上限的就不再是“有没有统一入口”，而是“入口之后能否持续做出正确决策”。
路由不是 if/else，而是多目标优化
对业务方来说，理想状态是只写一次接入代码，然后把可用率、成本和速度交给平台去平衡。但对平台来说，这实际上是一个多目标优化问题。最低价不一定意味着最低总成本，最低时延也不一定意味着最稳定的成功率。
在路由层，我们通常会同时看几类信号：
- 模型和 provider 维度的实时健康度，包括最近窗口错误率、超时率和熔断状态。
- 区域维度的时延分布，不只看平均值，更看 P95、P99 和抖动幅度。
- 单 provider 的限流状态、额度消耗和当前并发占用。
- 请求本身的任务属性，比如实时对话、批量生成、长上下文分析或工具调用。
- 组织级策略，例如预算上限、合规要求、某业务线的优先级和可回退范围。
这意味着“相同模型、相同参数、相同 API”在不同时间窗口里，完全可能落到不同的上游。平台真正提供的不是一个静态映射，而是一种动态分配能力。
先分类，再路由
很多失败的路由系统，都在试图用一套通用规则处理所有请求。但实际业务并不均质。客服对话关心首 token 时间，研究分析关心长文本稳定性，批量生成关心吞吐和价格。把这些请求混在一起做统一决策，最后得到的往往是“每一类都不够好”。
所以我们在真正路由之前，会先做轻量级分类。分类不一定复杂，但必须足够实用，例如：
- 是否是同步链路，是否存在严格超时预算。
- 是否必须命中某种模态能力，比如图像理解、结构化输出或函数调用。
- 是否允许质量降级，允许的话降到什么层级。
- 是否受到部门预算、地域合规或客户等级策略约束。
只有分类先做对，后面的主路由、备选路由和回退边界才有意义。否则平台看起来很“智能”，实际上只是把错误分配做得更快。
回退链路必须快，而且要有边界
如果主路由失败，回退不能再走一轮完整决策，否则用户看到的就是明显超时。
我们的做法是为每类请求预先计算候选链路，并按优先级排好。失败发生时，系统执行的是“快速切换”。一个简化后的思路类似这样：
const classified = classifyRequest(request, policy);
const primary = pickPrimaryRoute(classified, signals);
const fallbacks = prepareFallbackRoutes(classified, signals);
return executeWithFallback(primary, fallbacks);真正麻烦的部分不在代码量，而在边界控制。回退不是越多越好。回退层级过深，会把一次本该快速失败的请求拖成几十秒的黑洞；回退条件过于激进，又会让系统在多个 provider 之间来回抖动。我们通常会给每条链路设三个约束：总超时预算、最多允许的切换次数，以及允许降级到什么能力层级。
熔断、限流和幂等要一起设计
很多团队会把熔断看成一个独立组件，把限流看成流量组件，把幂等看成业务方自己的责任。拆开看没错，但落到 AI 调用场景里，这三件事必须联动。
原因在于大模型请求天然比传统 HTTP 请求更昂贵。一次失败并不只是一个 5xx，它还可能意味着已经消耗了上游额度、已经占用了几十秒时延预算，甚至已经产生了部分输出。如果没有幂等键和请求级追踪，你很难判断重试是不是安全；如果没有限流保护，某个异常 provider 会在短时间内把失败放大成雪崩；如果没有熔断，策略层会继续把流量送进已经明显异常的通道。
我们的经验是：熔断阈值要尽量贴近真实业务影响，限流策略要区分组织、模型和 provider 三个层面，幂等键则必须贯穿从入口到上游调用链的每一步。
观测的目标不是看板，而是让决策可校准
很多团队把日志、指标和 tracing 做得很完整，但没有真正把这些数据接回调度层。
我们更关注三件事：
- 当前策略是不是还有效。
- 哪个 provider 的异常已经足够影响路由。
- 哪些业务请求应该有不同的优先级。
所以 Cloubic 的观测系统不是事后复盘工具，而是决策输入的一部分。除了常规的成功率、时延和错误分布，我们还会持续观察两个更关键的指标：策略命中率和有效成功成本。前者告诉我们策略是否真的落到了预期目标，后者告诉我们为了这次“成功”到底付出了多少额外代价。
为什么这件事对成本也重要
当路由层真正理解实时健康度后，成本优化才成立。否则所谓的低价 provider，只要多带来一点重试或超时，最终总成本往往更高。
我们在内部更看重“有效成功成本”，也就是一次成功调用背后，真实消耗了多少请求机会、重试次数和时延预算。这个指标会逼着平台从整体看问题，而不是只盯着价格表。
这也是为什么成本治理不能和稳定性拆开做。
策略发布也必须工程化
还有一个很容易被低估的问题，是路由策略本身怎么发布。如果每次调整都靠人工改配置、手工观察和临时回滚，那么策略再聪明也跑不快。我们后来把策略当成版本化资产来管理，要求每次变更都能说明目标、影响范围、灰度比例和回滚条件。
结语
统一 API 是入口，智能路由才是中台能力。前者解决接入效率，后者解决规模化运行。一个真正可用的 AI Gateway，不该把上游的不稳定直接暴露给业务，而应该把抖动、成本和策略复杂度尽量吸收到平台内部。
从工程视角看，这是一套关于信号、约束和自动化的系统；从业务视角看，它决定了平台能否在规模化阶段依然保持稳定体验。后面的文章里，我们会继续拆解限流保护、模型评估和策略发布体系。