多模型路由实践：按任务选择 Claude、GPT、Gemini 的基本策略

企业应用里接大模型，最常见的坑不是"模型不够强"，而是所有请求都打到同一个模型上。客服摘要、代码审查、图片理解、合同问答、批量标签生成，本来就不是同一类任务，却被同一个 endpoint 扛住，最后要么成本高，要么延迟大，要么稳定性不好排查。

这篇按工程实现讲，不做模型排名。当前公开官方资料里，OpenAI 主推 GPT-5.5，Anthropic 文档列出 Claude 4.7，Google Gemini API 则有 Gemini 3.5 Pro、Gemini 3.5 Flash 和稳定版 Gemini 2.5 Flash。实际生产请以供应商控制台可用模型为准。

1. 先定义任务类型

建议先在业务层定义 task_type，而不是在代码里到处写模型名。

json 复制代码

{
  "task_type": "code_review",
  "latency_budget_ms": 8000,
  "max_cost_level": "high",
  "need_vision": false,
  "need_json": true
}

可以先拆成几类：

code_review：代码审查、单测生成、重构建议；
reasoning：复杂分析、策略判断、长链路推理；
summary：摘要、提炼、标题、关键词；
customer_service：客服回复、工单归类；
vision_doc：图片、PDF、视频或多模态文档；
batch_low_cost：批量低成本任务。

2. 再做模型映射

一开始别做太复杂的动态路由。规则路由更容易上线，也更容易解释。

yaml 复制代码

routes:
  code_review:
    primary: openai/GPT-5.5
    fallback:
      - anthropic/claude-4.7
      - anthropic/claude-4.7
  reasoning:
    primary: anthropic/claude-4.7
    fallback:
      - openai/GPT-5.5
  summary:
    primary: google/gemini-3.5-flash
    fallback:
      - google/gemini-2.5-flash
      - openai/gpt-5.5-mini
  vision_doc:
    primary: google/gemini-3.5-pro
    fallback:
      - openai/GPT-5.5

这个配置不一定适合所有团队，但思路是清楚的：高价值任务给强模型，高频任务给经济模型，多模态任务看输入能力，失败时自动降级。

3. 统一响应格式

多模型最大的问题是接口差异。OpenAI、Anthropic、Gemini 的 messages、tool calling、stream、usage 字段都不完全一样。工程上要做一层 adapter，把返回统一成内部格式。

ts 复制代码

type UnifiedLLMResult = {
  provider: "openai" | "anthropic" | "google";
  model: string;
  text: string;
  inputTokens?: number;
  outputTokens?: number;
  cachedTokens?: number;
  latencyMs: number;
  routeReason: "primary" | "fallback" | "cost" | "latency";
  raw?: unknown;
};

raw 可以保留，但不要让业务层依赖它。业务层只看统一字段，后面换模型才不会大面积改代码。

4. 失败分类要细

不要所有异常都重试。至少区分：

429：限流，可以延迟重试或切 fallback；
401/403：密钥、权限、区域或账户问题，重试意义不大；
5xx：供应商故障，可以切备选模型；
schema error：模型输出不符合 JSON，需要修复提示词或做二次格式化；
timeout：看任务是否允许降级。

路由日志里要记录 provider、model、task_type、route_reason、status_code、latency_ms、token_usage。没有这些字段，后面做成本优化基本靠猜。

5. 国内调用的限制

国内业务接 Claude、GPT、Gemini，要提前评估几个问题：

官方 API 网络延迟和稳定性；
海外账号、外币支付、额度和发票；
业务数据是否允许出境；
内容安全、日志留存和审计要求；
企业内部是否允许开发者直接持有模型 API Key。

很多项目不是模型效果不行，而是卡在支付、网络、额度和合规审批上。解决方式通常是在企业侧做统一网关，或采用已经做过聚合、结算和网络优化的 API 服务。

词元无忧 API（token5u API）适合放在这个位置：它用 OpenAI 兼容接口承接 GPT、Claude、Gemini 等模型，支持按量计费、人民币相关结算、专线优化和企业级接入。对于已有 OpenAI SDK 的项目，迁移成本会比直接改三套官方 SDK 低不少。

6. 最小可上线版本

如果只做一个 MVP，我建议范围控制在：

一个统一 client；
三类 task_type；
主模型 + 一个 fallback；
usage 和 latency 日志；
每日成本报表；
API Key 不进业务代码。

别把第一版做成平台。先让业务请求都经过同一层，再逐步加缓存、预算、限流和灰度。