Claude 4、GPT-5.x、Gemini 2.5 的 Agent 多模型路由方法

Agent 一旦接上订单、检索、邮件和审批，模型超时就会变成业务故障。更常见的麻烦还包括 JSON 缺字段、同一工具被重复调用、长对话里漏掉约束。

候选池里有 Claude 4、GPT-5.x、Gemini 2.5 时，先把业务逻辑和供应商 SDK 拆开。上层只认统一的消息、工具和响应结构；模型名、超时阈值、重试次数、主备顺序写进配置。以后切模型，改路由，不动订单、权限和审计代码。

先别给三家排座次。拿几轮聊天体验选 Agent，测不出工具链是否可靠。可以整理约 200 条回归用例，分成三组：

三家各跑三遍。提示词、JSON Schema、工具权限和超时配置保持一致。至少记录首 token 延迟、整链路 P95 完成时间、人工兜底比例；缺字段、无效 JSON、重复调用则单独计数。数据可以进 Prometheus，也可以进现有可观测平台。

判定标准放在业务动作上。订单查对了、退款条件判断对了、邮件没有重复发，才算通过。回复写得顺，却把工具参数填错，仍然是失败。公开演示和榜单只用来建候选池，主备顺序交给回归结果。

接口支持的窗口再长，也不该把全部历史直接塞回去。上下文越杂，排查一次错误越费劲，切换供应商时还要处理不同的消息格式。

记忆可以拆成三层：

长期层也要控制写入。用户已经确认的偏好、工具返回的任务状态可以保留；临时讨论和重复内容不必反复入库。摘要最好带上来源和更新时间，方便回放时找到原始记录。

已经用 Rust 做网关、用 Python 跑摘要批处理的团队，可以保留现有分工。多模型改造先处理接口和路由，无须顺手重写语言栈。

框架里只有一个 try/except 不够。线上回退至少拆成四级：

L1 同系列降级：先切到已经通过回归的轻量规格。如果账号里同时配置了 GPT-5.1 与 GPT-5 mini，或 Claude Sonnet 4 与 Claude Haiku，可以在这一层完成切换。没有测过的型号不要临时加入。
L2 跨供应商切换：主模型达到超时阈值，或连续返回结构错误时，转到另一家已验证的模型。故障提示使用固定模板，避免备用模型临场编造原因。
L3 工具降级：检索不可用时，仅在业务允许的情况下使用模型自身知识，并明确标注“未走知识库”。订单、退款等实时状态不适合这样处理，应转人工或稍后重试。
L4 人工接管：金融、医疗、合同等高风险节点直接交给指定人员，不让模型自行完成最后一步。

每一级都要写清触发条件、最大重试次数、幂等处理、计费方式和最终接管人。回退路径也要放进那 200 条用例里跑，不能等故障发生后再验证。

公开单价只能做初筛。更实用的办法，是让同一批 200 条用例在同一周跑过三家，再把输入、输出、自动重试、失败调用和人工接管一起记账。

一段 50K token 的长会话，如果因为格式错误又跑了一遍，费用和延迟都会变化。最后统一折算成每个完成任务的成本；每百万 token 的价格留作辅助项。

任务可以先分成三档：

Claude 4 Opus、GPT-5.x、Gemini 2.5 Pro 和 Gemini 2.5 Flash 都可以出现在配置表里。哪个做主路由，按回归结果和实际账单更新，不给某个品牌永久固定席位。

首轮可以只放 10% 流量。确认错误、人工接管和账单没有异常，再逐步提高比例。

模型调用已经做成配置，采购条款也要允许更换。至少问清三件事：

移动端产品页可以用来核对产品入口，API 数据条款仍要回到开发者平台和合同。别把应用商店里的说明直接当成企业采购条件。

路由台账不用复杂，先把下面几列填完整：

每次模型版本、价格或条款变化，重跑同一套 200 条用例，再调整表里的主备顺序。三家无需平均分流。需要保留的是一条经过验证的替代路径，避免供应商变化时临时改业务代码。

Agent选型 Claude 4 GPT-5 Gemini 2.5

Agent 选型别押一家，三模型路由怎么搭