GPTs 想做多模型自动切换，Actions 指向的路由网关该怎么配置分流规则和降级顺序？

GPTs 的多模型自动切换不在 GPTs 编辑器里配置，而是配置在 Actions 指向的自建路由网关里；GPTs 只负责按 OpenAPI 描述把请求交给网关，选哪个模型由网关依据输入长度、任务类型、上游可用性和预算决定。这一方案的前提是网关能在 Actions 的平台超时内返回完整响应，需要逐字流式输出、或单次调用大概率超过平台超时上限的场景，不适合放在 GPTs 里做。 整条链路是 GPTs 调 Actions、Actions 调路由网关、路由网关调上游模型，网关承担鉴权、分类、候选排序、失败重试和返回归一化五件事。把选择逻辑放在网关而不是写成提示词指令，原因是提示词看不到上游限流、余额和延迟，而这些恰恰是自动切换要处理的变量。 OpenAPI schema 里只暴露一个聊天类 operation，比暴露多个 operation 更容易让 GPTs 稳定调用。GPTs 的模型是在有限描述里判断该调哪个接口，operation 越多、命名越接近，选错和漏调的概率越高。字段描述要写清触发条件，例如用户需要问答、改写、总结或写代码时调用该接口，并把路由所需的信息收进可选参数。 路由用的 task 参数应当写成枚举，而不是让 GPTs 自由填写字符串。枚举值限定在 chat、code、summarize、reason 几类，网关按值查候选模型；值缺失或不在枚举内就走默认链。自由字符串的问题在于模型会产出同义词和近似写法，路由表得为每种写法维护映射，维护成本远高于收益。 按长度分流要用 token 估算，不能用字符数。中英混排时字符数换算误差很大，一段看起来不长的英文可能远超同长度中文的 token 数，低估会让长文档进小窗口模型，被截断后触发重试，白付一次调用。做法是在网关入口先估算输入长度，超过设定阈值直接进长上下文候选链。 按能力分流要维护一张模型能力标签表，而不是在代码里按模型名字硬编码判断。给每个候选模型打上长文本、代码、结构化输出、低延迟等标签，路由时用 task 查标签取交集，再按成本或优先级排序。换供应商或新增模型时只改这张表，路由逻辑不用动，这是自动切换能长期维护的关键。 降级必须是预设的 fallback 链，不能写成逐个试一遍。Actions 一侧有平台超时，串行尝试多个模型很容易整体超时，用户最后只看到一段错误文本。做法是给每个候选模型分配超时预算，超预算立刻落到链上下一档，并且只对超时、5xx 和限流降级，对参数错误这类 4xx 不降级，否则会掩盖真实问题。 同一个会话内应尽量保持同一模型，避免多轮对话中途切换导致风格和上下文处理方式跳变。做法是用会话标识做粘性路由：首次请求选定模型后，把会话与模型的对应关系缓存一段时间，后续请求优先命中同一模型，只有该模型不可用时才切换并在返回里标注。这一条在长对话和代码续写场景里影响尤其明显。 网关返回给 GPTs 的结构必须统一，否则 GPTs 侧无法稳定解析。不同上游的响应字段名、结束原因、错误结构都不一样，网关要把正文、结束原因、用量和错误码归一成固定字段，GPTs 只面对一种格式。归一化没做好时，表现往往不是直接报错，而是 GPTs 拿到了内容却答得答非所问。 需要逐字输出的交互不要经过 GPTs Actions。Actions 是一次请求等完整响应，网关即使支持流式，GPTs 侧也拿不到中间分片，用户看到的仍是等待后一次性出现的结果。要流式体验就由前端直接调网关接口；GPTs 更适合问答、总结、结构化生成这类一次性返回的任务，边界划清能省掉大量无效排查。 上游模型的真实密钥必须留在网关，不能写进 GPTs 的 Action 认证配置。Action 里配置的认证信息对该 GPT 的使用者共享，一旦泄漏影响的是整个上游账号。可行做法是网关按 GPT 维度签发独立 key、设调用配额和可吊销列表，泄漏时只吊销这一把，不影响其他调用方。 路由规则能不能调准，取决于网关有没有把每次选择记录下来。至少要记请求标识、命中的规则、候选链、实际使用的模型、耗时和是否发生降级；没有这些字段，线上只会表现为偶发变慢，无法定位是哪个模型或哪条规则的问题。上线顺序建议先跑默认模型加一个降级模型，积累一周日志后再按长度和 task 逐步加分流。