你把 Claude 和 OpenAI 一起接进生产环境后，真正的难题不是“能不能调通”，而是怎么在质量、延迟、成本三角里稳定跑。
如果没有路由网关，最常见结果就是：高峰期延迟抖动、账单失控、异常时全站雪崩。

一、先定路由目标：别让“智能路由”变成玄学

模型路由不是“随机挑个便宜的模型”。先把目标写死成 3 条：

  1. 延迟目标：P95 在可接受范围（例如 < 3s）
  2. 成本目标：单请求 token 成本上限（例如 <$0.02）
  3. 质量目标：关键任务成功率（例如 >= 97%）

再把请求按业务价值分层：

  • L0（高价值）：订单、风控、客服升级单 → 质量优先，允许更高成本
  • L1（中价值）：常规问答、报告生成 → 平衡质量与成本
  • L2（低价值）：草稿、改写、分类 → 成本优先

这一步做完，后面的策略才有依据。

二、延迟分层：先快后稳，不是先贵后慢

推荐的默认路由策略：

1) 首选模型（Primary）

  • L0：选择质量更稳的主模型
  • L1/L2：选择性价比更高的模型

2) 软超时切换（Soft Timeout）

  • 例如 1200ms 未首 token 返回，则并行触发备选模型（Hedged Request）
  • 先返回谁就用谁，另一路取消

3) 熔断与半开恢复

  • 连续失败阈值触发熔断（如 5 次/30s）
  • 熔断后进入半开：每 N 个请求放 1 个探测

Go 伪代码：

type RoutePolicy struct {
    SoftTimeoutMs int
    MaxCostUSD    float64
    Tier          string // L0/L1/L2
}

func Route(req Request, p RoutePolicy) Provider {
    if p.Tier == "L0" {
        return providerWithBestQuality()
    }
    if req.EstimatedCostUSD() > p.MaxCostUSD {
        return cheaperProvider()
    }
    return providerWithLowestP95()
}

三、成本阈值：先算清楚再调用

常见坑：只看单价，不看总 token。你需要在网关层做两件事：

  • 预估成本：按输入长度 + 预计输出长度计算预算
  • 硬阈值阻断：超过阈值直接降级（短答案、摘要模式、排队异步）

建议至少配置三档阈值：

  • warn_threshold：记录告警，不拦截
  • degrade_threshold：切换便宜模型或压缩 max_tokens
  • block_threshold：拒绝同步请求，改异步任务

四、质量守门：A/B 不够，必须有回归基线

上线前只做肉眼评审远远不够。建议在网关层内置评测闸门：

  1. 金样本集合：覆盖高风险场景（拒答、安全、结构化输出）
  2. 周级回归：新路由策略必须跑完整评测
  3. 分级放量：1% → 10% → 50% → 100%
  4. 自动回滚：关键指标跌破阈值立即回退上个稳定策略

可观测指标最少要有：

  • provider/model 维度的成功率、P50/P95 延迟
  • 每千请求成本（CPM-like）与 token 消耗
  • 任务级质量得分（人工/自动混合）

五、生产落地清单（可直接照抄）

  • 按 L0/L1/L2 完成请求分层
  • 配置 Soft Timeout + Hedged Request
  • 配置 provider 熔断阈值与半开探测
  • 配置成本三档阈值（告警/降级/阻断）
  • 建立金样本与每周回归
  • 灰度发布 + 自动回滚

六、常见翻车点与修复

翻车点 1：只按价格路由，质量断崖

修复：L0 请求绑定质量优先池，不参与低价路由。

翻车点 2：超时后串行重试，尾延迟爆炸

修复：改为软超时并行备援，限制并发倍率。

翻车点 3：成本告警太晚

修复：在请求入口做预算预估，超过阈值提前降级。

总结

Claude + OpenAI 双供应商路由的关键不是“多接一个 API”，而是把延迟分层、成本阈值、质量守门变成可执行的网关策略。
先把规则写死，再让策略自动化，你的系统才会在高峰期保持可控，而不是靠运气。