我在项目里同时接过 GPT-5.4、Claude Sonnet 4.6 / Opus 4.6 和 Gemini 3.1 Pro。做下来最大的感受很简单，多模型系统里最麻烦的从来不是榜单怎么排，而是谁该待在哪条链路上。
如果只说我现在还在用的一套分法，大概就是这样：
GPT-5.4负责执行链、Agent、代码任务Claude Sonnet 4.6 / Opus 4.6负责长文档和知识处理Gemini 3.1 Pro负责多模态、高吞吐和 Google 生态侧任务
这套分法不一定适合所有团队，但对工程系统很实用，因为默认路由一清楚，后面的排障、fallback 和成本统计都会轻松很多。
一个踩坑案例
我们早期有一条内部 Agent 链路，里面既要读需求文档，也要顺手调工具、改代码、回结构化结果。当时图省事，我一度把长材料理解和执行都压在同一个模型上，结果很快就不对劲了：
- 文档理解没问题，但一到工具调用和多步执行，链路就开始不稳定
- 返回结果能看，但不够适合直接给下游系统接
- 同一条链路里，理解和执行互相拖累
后来反而是把事情拆开了。长材料先走 Claude Sonnet 4.6 做预处理，执行链默认切回 GPT-5.4，多模态请求单独路由到 Gemini 3.1 Pro。这么一改，链路稳定了，排查问题也简单很多。
一张工程表
| 链路类型 | 更适合的模型 | 主要优点 | 适合场景 | 不适合场景 |
|---|---|---|---|---|
| 执行链 / Agent / Coding | GPT-5.4 | 执行性更强，工具调用和结构化输出更顺 | 工作流中枢、Agent 主链、代码补丁生成 | 超长材料的前置整理 |
| 理解链 / Knowledge Processing | Claude Sonnet 4.6 / Opus 4.6 | 长材料处理更稳，改写和整理更适合作为下一步输入 | 知识库前处理、文档理解链、多文档汇总 | 高依赖工具调用的执行链 |
| Multimodal / High Throughput | Gemini 3.1 Pro | 多模态覆盖更自然，生态适配更直接 | 图片音频视频链路、Google 生态侧、高吞吐轻任务 | 试图把所有文本任务都塞进去的统一主链 |
一个可以直接参考的路由示例
下面这个示例不是生产配置，但拿来做第一版路由已经够用了：
routes:
coding:
primary: gpt-5.4
fallback: claude-sonnet-4.6
knowledge:
primary: claude-sonnet-4.6
fallback: claude-opus-4.6
multimodal:
primary: gemini-3.1-pro
fallback: gpt-5.4
classifier:
- if: request.has_image || request.has_audio || request.has_video
route: multimodal
- if: request.task_type in ["code", "agent", "tool_call"]
route: coding
- if: request.task_type in ["summary", "qa_from_docs", "rewrite", "knowledge_extract"]
route: knowledge
- else: coding
对应到实际流程，其实就是四步：先判断是不是多模态；不是多模态，再判断是不是代码或 Agent；剩下的长文档和知识处理走理解链；主模型失败时，再按链路切 fallback。它不算聪明，但好解释，也好排障。
落地时我会盯的三个指标
如果要继续往下做，我通常会把这三个指标单独拉出来看：
- 平均延迟：一条链路到底慢在哪
- 单请求成本：是不是有链路被重模型吃穿了
- 成功率：失败是来自模型本身，还是来自工具调用和路由错误
对大多数团队来说，先把这三项看清楚，比一开始做复杂调度更有用。
接入层解决什么问题
一旦你决定同时接 GPT、Claude、Gemini 3.1 Pro，问题很快就不再只是 prompt，而是整个系统怎么管。
SDK、认证、限流、账单和迁移方式都不一样。这个时候，多数团队都会开始考虑要不要补一层统一接入。
举个例子，
147API这类方案处理的就是这一层事情。
它不替你决定选哪个模型，主要解决的是几件很实际的事：
- 把不同模型的接入方式收拢到一个入口，减少 SDK 和鉴权层面的重复工作
- 做切换和 fallback 时不用反复改业务代码
- 路由、账单和成本统计更容易放到一处看
- 后面真要替换模型，迁移成本会低很多
说到底，统一接入层的价值不是“帮你选模型”，而是让多模型系统别越接越乱。
结尾
我现在对多模型这件事的看法很朴素：先把分工做对，再把路由做稳，最后再补统一接入层。顺序不要反。
如果一上来就纠结谁是唯一最强，最后往往还是会回到同一个问题上，代码任务谁来跑，长材料谁来吃，多模态请求又该往哪边走。把这几个位置放对了，系统通常就顺了。
