模型路由 2026：不要把所有任务都交给同一个模型
flowchart LR
A["用户任务"] --> B["任务分类"]
B --> C["低风险快模型"]
B --> D["高推理模型"]
B --> E["代码/工具专用模型"]
B --> F["开源/本地模型"]
C --> G["验证器"]
D --> G
E --> G
F --> G
G --> H["升级 / 重试 / 人工确认"]2026 年继续用“一个默认模型打天下”，不是简单，是偷懒。模型之间的差别已经不只是谁更聪明，而是谁更便宜、谁更快、谁更会用工具、谁更适合隐私场景、谁在你的私有任务上更少犯错。
出处与延伸阅读：
这篇文章会讲什么
040 模型选型策略 写的是“怎么选一个模型”。但到 2026 年，很多产品真正需要的是：
怎么在一次用户任务里，动态选择多个模型。
这篇讲模型路由，不讲“谁最强”。因为“最强”这个词在生产里经常没用。
先说结论
- 模型路由是 AI 产品的成本控制中枢。尤其是 Agent、多轮对话、RAG、代码任务，一次请求背后可能有十几次模型调用
- 路由不只是省钱。它还关乎延迟、工具能力、上下文窗口、隐私、地区合规、失败恢复
- 最小可行路由：便宜快模型处理低风险任务，高推理模型处理难任务，代码/工具任务走专用模型，敏感任务走本地或 ZDR 端点
- 路由规则必须来自 eval。不要靠厂商榜单猜，要用自己的真实任务做分流依据
- 别把 fallback 写成“失败后换一家”这么粗。有时要换模型，有时要升 reasoning，有时要换工具，有时应该叫人
1. 为什么 2026 年必须做模型路由
1.1 模型家族开始分层
以 2026-06-03 的公开产品形态看，GPT-5.5 已经有 Instant、Thinking、Pro 等不同使用形态。Anthropic、Google、开源生态也类似：快模型、强推理模型、coding 模型、多模态模型、小模型各有位置。
这不是营销命名，而是产品架构信号：
- 不是所有任务都需要最高推理
- 不是所有任务都能等最慢模型
- 不是所有任务都值得花最高成本
1.2 Agent 会把成本放大
普通聊天一次请求就是一次模型调用。Agent 不一样：
理解任务
→ 搜索资料
→ 调工具
→ 看结果
→ 继续规划
→ 再调工具
→ 验证
→ 总结一个任务跑 10 到 30 轮很正常。每一轮都用旗舰模型，账单会很快变难看。
099 Agent Runtime 讲过，runtime 需要管理状态、工具和验证；模型路由就是 runtime 的一部分。
1.3 开源模型进入可用区间
081 开源 LLM 2026 里已经提到，开源模型在 coding、agentic、reasoning 的部分场景里足够可用。
这意味着很多低风险、内部、批处理任务可以走开源或自托管模型：
- 文档粗摘要
- 标签分类
- 结构化抽取
- 内部搜索改写
- 低风险客服草稿
- 代码初筛
闭源 frontier 模型应该用在“值得用”的地方。
2. 一个实用的路由矩阵
| 任务类型 | 默认模型 | 升级条件 | 不该做什么 |
|---|---|---|---|
| 简单问答 / FAQ | 快模型 / 小模型 | 置信度低、用户追问 | 默认上旗舰 |
| 文档摘要 | 快模型 + RAG | 涉及决策或合规 | 让模型自由发挥 |
| 代码修改 | coding 专用模型 | 测试失败、跨模块重构 | 只看 benchmark 选 |
| 多步 Agent | 强工具模型 | 工具失败、计划偏移 | 不设步数和成本上限 |
| 法务/医疗/财务 | 高推理 + 人审 | 默认人审 | 用便宜模型直接定稿 |
| 敏感数据 | 本地 / ZDR / 企业端点 | 无法满足合规则拒绝 | 把数据发给未知 provider |
| 实时交互 | 低延迟模型 | 用户愿意等待 | 用慢模型破坏体验 |
| 批处理 | 低成本模型 | 错误率超过阈值 | 用最高价模型跑全量 |
这个矩阵不应该照抄。你要用 101 Real-World Evals 里的私有任务来校准。
3. 路由规则怎么写
3.1 先按风险分
风险比能力更重要。
低风险：摘要、改写、分类、搜索 query
中风险：生成草稿、代码 patch、数据分析
高风险：外发消息、改生产数据、合规建议
不可自动：付款、删除、权限变更、医疗/法律最终建议低风险可以用便宜模型试，结果不满意再升级。高风险不要靠升级模型解决，应该引入确认和审计。
3.2 再按能力分
不同模型的“强”不一样：
- 有的强在代码
- 有的强在长上下文
- 有的强在多模态
- 有的强在速度
- 有的强在工具调用稳定性
- 有的强在中文写作
模型路由的坏味道，是把所有任务都归结为“智商高低”。生产里更常见的是“合不合适”。
3.3 最后按成本和延迟分
延迟和成本要写进规则，而不是事后看账单。
例如：
如果任务为 faq_answer 且检索命中度 > 0.85：
用 fast_model
如果用户连续追问或答案置信度 < 0.6：
升级 thinking_model
如果涉及合同/隐私/外发：
切到 high_risk_flow，强制人工确认4. Fallback 不是简单重试
很多系统把 fallback 写成：
OpenAI 失败 → Anthropic
Anthropic 失败 → Gemini这只是 provider fallback，不是智能路由。
真实 fallback 至少有几种：
| 失败信号 | 应对 |
|---|---|
| provider 挂了 | 换 provider |
| 输出格式错 | 同模型重试或强 structured output |
| 推理不够 | 升级 reasoning effort / thinking 模型 |
| 检索不够 | 换 query、扩大检索、让人补上下文 |
| 工具调用错 | 换工具或进入人工确认 |
| 安全风险 | 拒绝或升级人审 |
| 成本超预算 | 停止、总结已完成部分 |
一个成熟 router 应该知道“为什么失败”，而不是只知道“失败了”。
5. OpenRouter 这类服务给了什么启发
OpenRouter 的 provider routing 文档里有几个生产系统很需要的概念：
- 按价格、吞吐、延迟排序
- provider fallback
- 只选支持特定参数的 provider
- 控制数据保留策略
- 选择 ZDR 端点
- 用 p90/p99 latency 做偏好
这些不是所有团队都要直接用 OpenRouter，但它提供了一个路由思维模板：模型调用不是单点 API，而是一个可调度资源池。
企业内部也可以做类似的网关：
app → model gateway → policy → provider/model/router → logs/evals把模型选择集中到 gateway，避免每个业务线自己乱接。
6. 路由和 prompt caching
模型路由不是每次都换模型。对长任务来说，频繁换模型可能破坏上下文缓存和工具状态。
096 Claude Code Prompt Caching 讲过，长上下文场景里缓存能显著影响成本和延迟。路由时要考虑：
- 当前模型是否已有缓存
- 换模型会不会重新发送大上下文
- 任务是否即将结束
- 升级后的收益是否超过缓存损失
所以一个好 router 不是“每轮选最优模型”，而是“在任务级别管理切换成本”。
7. 一个最小实现
小团队可以先不做复杂系统，写一个非常朴素的 router。
type TaskRisk = "low" | "medium" | "high" | "blocked";
type TaskKind = "faq" | "summary" | "coding" | "agent" | "legal" | "data";
function chooseModel(kind: TaskKind, risk: TaskRisk, signals: {
confidence?: number;
needsTools?: boolean;
containsSensitiveData?: boolean;
}) {
if (risk === "blocked") return "human_review";
if (signals.containsSensitiveData) return "enterprise_zdr_model";
if (risk === "high") return "thinking_model_with_human_review";
if (kind === "coding") return "coding_model";
if (kind === "agent" || signals.needsTools) return "tool_strong_model";
if ((signals.confidence ?? 1) < 0.6) return "thinking_model";
return "fast_model";
}这段代码不复杂，但它把关键思路摆正了：先看风险，再看任务，再看置信度。
8. 常见误区
8.1 “路由会降低质量”
路由做差了会。做好了不会。
因为高价值任务仍然会走强模型，低价值任务不浪费强模型。真正会降低质量的，是为了省钱一刀切降级。
8.2 “路由就是多接几个模型”
多接模型只是 provider 管理。真正的路由要有任务分类、风险策略、失败信号、eval 反馈。
8.3 “自动路由可以完全替代模型选择”
不行。自动路由需要默认策略，也需要人工定期复盘。尤其是高风险领域，模型选择是产品责任的一部分。
小结
模型路由会从“高级优化”变成 AI 产品的基本功。
原因很现实：
- 模型越来越多
- 价格差异越来越大
- Agent 调用轮次越来越多
- 隐私和合规要求越来越细
- 公开 benchmark 对真实任务的解释力越来越有限
好的路由不是为了炫技，而是为了把每个任务交给“足够好、足够快、足够便宜、足够安全”的模型。
这句话听起来像废话，但能做到的产品，会比只会接一个旗舰模型的产品活得久。