策略模式定义一组可互相替换的算法，把每种算法封装成独立类，运行时按需切换，调用方不感知内部实现。在我们自研的企业级 AI 网关里，智能路由就是策略模式的典型落地：网关维护一个 RoutingStrategy 接口，轮询、最低延迟、最低成本、故障转移、按内容分类路由各自实现成独立策略类，路由引擎按请求上下文选出命中策略并执行。效果是把”选哪个模型”从业务代码里彻底抽出来，新增一种路由规则就是新增一个策略类，网关重启都不用。据企业 CIO 调研数据，生产环境同时跑 5 个以上模型的企业占比已接近四成，没有策略化路由，多模型只会增加运维负担而不是提升可用性。
一、为什么网关的路由逻辑要策略化
AI 网关面对的是模型数量多、能力分层的局面：轻量模型响应快、成本低，重型模型推理强、价格贵。一个对话请求是简单问答还是复杂推理，路由结果应该完全不同。如果把选择逻辑写成 if-else 堆在调用处，每加一条规则就要改主流程代码，规则之间还会互相纠缠。
策略模式把”决策”与”执行”分开。决策层由路由引擎负责，它收集请求上下文（任务类型、用户等级、可用预算、模型健康状态），把上下文交给当前激活的策略，策略返回候选模型列表，引擎再结合各模型的实时状态做最终裁决。业务代码只发请求、收结果，不关心背后是哪个模型在处理。
| 策略 | 决策依据 | 典型场景 |
|---|---|---|
| 轮询策略 | 按序循环 | 多 key 负载均衡 |
| 最低延迟策略 | 实时响应耗时 | 追求首 token 速度 |
| 最低成本策略 | token 单价与预估消耗 | 批量低价值任务 |
| 故障转移策略 | 主模型健康状态 | 主服务异常兜底 |
| 内容分类路由 | 任务类型识别 | 问答走轻量模型、推理走重型模型 |
二、策略接口与注册机制
网关定义一个极薄的策略接口，一个方法返回候选模型，实现自由度高：
public interface RoutingStrategy {
String name();
List<ModelCandidate> select(RouteContext context);
}RouteContext 携带请求的原始内容、预估 token 消耗、用户等级、预算余量、各模型健康快照。策略实现各自解析这些信息，互不干扰。引擎在 Spring 容器里收集所有 RoutingStrategy Bean，按 name() 建索引，配置中心下发路由规则时指定走哪套策略，热生效。
2.1 最低成本策略的实现
成本策略是网关里最常被问起的。它按模型单价与请求预估 token 数算出期望成本，在健康模型里挑最低者：
@Component
public class LowestCostStrategy implements RoutingStrategy {
private final ModelRegistry registry;
@Override
public String name() {
return "lowest-cost";
}
@Override
public List<ModelCandidate> select(RouteContext ctx) {
return registry.healthyModels().stream()
.sorted(Comparator.comparingDouble(m -> m.price(ctx.estimatedTokens())))
.limit(1)
.toList();
}
}接到 AI 爆款文章创作器后，它的批量改写、标题生成这类对质量要求不高的阶段自动落到成本最低的模型上，复杂推理阶段才走重型模型，整体调用成本降下来一大截。
2.2 内容分类路由
按任务内容分类需要先做意图判断。网关在策略里预置一份轻量分类逻辑：命中代码、逻辑推理关键词的请求归到推理类，其余归到通用类。分类结果映射到模型分组，创作器的”多阶段生成”正好复用：选题阶段走便宜模型，成文阶段走高质量模型，润色阶段再走便宜模型。这套映射也做成配置，运营可以随时调。
三、策略落地与切换的标准步骤
把一套路由规则从想法变成线上配置，网关内遵循固定流程：
- 定义策略类实现
RoutingStrategy，在select里写清选路逻辑； - 用
@Component注册，启动后出现在策略注册表中； - 在管理后台配置路由规则，指定模型分组、策略名与参数；
- 先用小流量灰度，观察成功率与平均延迟，对比基线数据；
- 效果达标后逐步放量，异常时一键回切旧策略。
这套流程跑通后，改路由规则不需要发版，运营人员在后台上改配置即可，策略本身因为独立成类，可以单独单测。
四、自研策略路由与成熟方案的取舍
| 维度 | 自研策略路由 | 直接采用第三方 AI 网关 |
|---|---|---|
| 定制能力 | 强，策略完全自控 | 弱，受制于产品形态 |
| 接入成本 | 中，需自建策略与注册表 | 低，开箱即用 |
| 与 Spring AI 集成 | 天然契合 | 需额外适配 |
| 可观测性 | 需自建埋点 | 通常内置监控面板 |
内部系统已经深度绑定 Spring AI，自研策略路由的集成成本被显著摊薄，还能把路由、适配、健康检查、降级串成一条完整的调用链，这是引入黑盒方案很难做到的。
五、易踩的两个坑
策略之间的优先级要显式定义，内容分类路由和故障转移同时命中时，故障转移必须先行，否则会把请求路由到故障模型上。另一个坑是策略状态要幂等，select 方法里不要改全局状态，多线程并发下策略必须可重入，否则线上会出现诡异的偶发路由错乱。
常见问题（FAQ）
Q1：策略模式和适配器模式会混淆，怎么分辨？
适配器翻译接口，策略替换算法。网关里适配器管模型接入，策略管选路，职责不同。
Q2：策略多了会不会变成一堆类？
每个策略一个类，靠配置与注册表管理，十来个策略规模完全可控，比 if-else 好维护。
Q3：路由策略能不能支持运行时动态切换？
能。策略按名注册，配置中心改规则即热生效，无需重启网关。
