多模型路由先把不合格候选排除，再在满足质量、数据、功能与副作用门槛的模型中比较延迟和单位成功成本。降级也不是随便换一个便宜模型：输出结构、工具能力、上下文、地区、保留策略和幂等性都要兼容。若无法安全重试，就应降为草稿、排队或人工处理，而不是静默返回较差答案。
先判断是否真的需要多模型
多模型路由的价值不是让系统显得复杂，而是让不同任务在已满足质量、安全和功能门槛后，选择更合适的模型。若业务只有一种稳定任务、调用量不大、现有模型已满足质量和时限，先把单模型的评测、超时、重试和人工接管做好，通常比增加路由器更可靠。只有当任务差异明显、单一模型成本过高、区域或容量限制经常发生，或同一供应商故障会中断关键流程时，多模型才可能带来净收益。
第一张表不是模型排行榜，而是任务清单。对每类任务记录输入类型、数据敏感度、允许地区、必须能力、输出结构、工具副作用、质量下限、延迟预算、单位成功成本和失败后的业务动作。把不可违反的条件设为过滤器，再在合格候选中优化成本与速度。把质量、价格和延迟直接加权成一个总分，会让便宜模型用低价抵消不合格答案，也会把敏感数据送到未经批准的区域。
普通办公场景可以从三档开始：低风险整理与分类、需要事实与结构完整的写作、会执行工具或影响客户的高风险任务。低风险并不等于无门槛，仍要保护个人信息并验证输出；高风险也不意味着永远使用最贵模型，而是需要更严格的候选池、读回和人工批准。路线越少越容易解释，先用两到三个候选证明收益，再考虑动态预测。
候选池必须先通过兼容与数据边界
备用模型不能只因为接口格式相似就进入路由池。逐项验证上下文长度、图片与文件、中文能力、JSON Schema、工具调用、流式输出、取消语义、错误码、配额、内容安全、数据保留、训练使用、处理地区和审计日志。某个模型不支持当前请求的必要能力时，应在调用前排除，而不是调用失败后才发现。
输出兼容尤其容易被忽略。两个接口都返回 JSON，不代表都能严格遵守同一 Schema；工具字段名称一致，也不代表并行调用、参数校验和拒绝行为相同。对每个候选使用同一正常样本、边界样本和恶意样本，保存原始响应与解析结果。结构化输出失败应进入受控修复或人工路径，不能把解析器猜出来的内容当成模型成功。
数据边界是硬过滤器。供应商、地区、计划、日志和保留策略改变时，候选资格也会改变。请求进入路由器前先按数据等级脱敏或拒绝，把允许的供应商和区域写入策略；日志只保留调试所需字段，密钥与原文件不能落入路由决策日志。官方资料只证明厂商声明和当前入口，不等于本站已在客户账户完成合规实测。
质量、延迟和成本要按成功任务衡量
质量不是一个通用分数。客服草稿可检查事实、语气和是否引用政策；表格提取要检查字段准确与漏项；代码任务要运行测试；工具型 Agent 还要验证是否调用正确工具、是否重复写入、是否在拒绝后停止。为每类任务写最低通过条件和严重错误清单，路由器只有在候选达到下限后才能比较价格或延迟。
延迟要记录端到端 P50、P95 与超时率，并拆出排队、路由判断、模型首 Token、完整输出、工具执行和重试。动态路由本身可能增加一次分类或预测；低延迟模型若频繁输出不合格并升级到更强模型，总时延和费用反而更高。预算分母应是通过验收的一次业务任务，而不是单次 API 请求。
成本表需要包含输入、缓存输入、输出、推理 Token、工具、搜索、批处理、失败重试和人工复核。价格、模型 ID、地区和计划均带核验日期。缓存命中可能依赖路由到同一底层模型；Microsoft 当前文档说明模型路由可使用底层模型的缓存，但路由变化会影响连续请求的缓存收益。任何折扣都应从真实 usage 或合同读回后计入。
路由策略从可解释规则开始
可解释规则适合作为第一版：按任务类型和硬门槛筛候选，再用固定优先级或质量档位选择。规则示例可以是“含图片且需严格 JSON 的采购票据 → 候选 A/B；纯文本分类 → 候选 C；敏感数据 → 仅私有区域候选”。规则要版本化，并在回执中记录命中的条件、候选列表、最终模型与拒绝原因。
预测式路由需要额外评测。Amazon Bedrock 的官方文档说明其智能提示路由会在同一模型家族的候选间预测质量，并以 fallback 模型和质量差阈值作为锚点；同时列出英文优化、不能使用应用自有表现数据等限制。这类托管能力可减少编排代码，但仍需用自己的中文任务和失败样本验证，不能把厂商路由结果当成业务质量证明。
Microsoft Foundry 模型路由器提供 Balanced、Cost、Quality 等模式、模型子集和自动故障转移。模型子集可以限制未批准模型进入，并至少包含两个候选才能获得回退能力。使用托管路由时仍要记录底层模型、尝试顺序和是否发生 failover；若业务拿不到这些信息，就无法解释质量变化、费用波动或数据流向。
超时、重试、切换和降功能必须分开
超时只说明在当前等待窗口内没有完成，不代表上游没有继续执行。对纯文本生成，可在确认取消或没有副作用后重试；对发送邮件、写数据库、下单或创建工单，必须使用业务 task_id 和幂等键，先查询状态再决定是否切换。否则主模型虽超时却已完成写入，备用模型再次执行会制造重复副作用。
切换模型表示保持原任务契约，换另一个兼容候选继续；降功能表示明确减少能力，例如从“自动发信”降为“生成待审核草稿”，从“带引用回答”降为“提示稍后重试”。两者都不同于静默输出低质量答案。用户需要知道结果是否降级、缺少什么、下一步是什么；高风险任务在无法满足门槛时应停止并进入人工，而不是为了可用率返回猜测。
熔断器按供应商、区域、模型和错误类别分别统计，避免一个限流事件把所有流量推向另一条也无容量的通道。恢复时先用小流量探测，再逐步放量；半开状态的样本仍要通过质量与副作用检查。配额、认证、内容拒绝、客户端参数错误和供应商 5xx 的处置不同，不能全部统一成重试。
统一任务状态，防止故障切换重复执行
每个业务任务从入口生成稳定 task_id，模型尝试使用 attempt_id。状态至少包括 received、routed、running、side_effect_pending、completed、failed、manual_review 和 cancelled。一次任务只能有一个最终成功回执；后来的迟到响应必须识别并丢弃，不能覆盖已经人工确认的结果。
工具调用前保存计划动作、目标资源和幂等键，执行后从目标系统读回。若模型 A 已创建草稿但响应丢失，模型 B 应读取现有草稿并继续，而不是重新创建。若工具不支持幂等，使用本地去重表、业务唯一键或人工审批闸门；不能仅在提示中要求“不要重复”。
会话切换也要受控。不同模型的系统提示、工具描述、上下文截断和安全拒绝可能不同；直接把完整对话交给备用模型，可能泄露原模型不该看到的字段或改变指令优先级。构造最小化的任务状态包，只包含授权数据、已确认事实、未完成步骤和必要证据，并记录从哪一模型、哪一版本切换。
用影子流量和同输入回放验证路由
上线前先做离线回放：使用脱敏的历史任务和专门构造的边界样本，让每个候选处理同一输入，按照预先写好的规则评分。对动态路由器，还要比较其选择与人工标注的合格候选。单次样例不能证明总体优劣，报告应展示任务分布、失败类型、严重错误和置信区间或至少原始计数。
影子流量可以把真实请求副本发给候选但不执行外部工具、不向用户展示，适合观察延迟、结构和内容差异。必须先处理授权与隐私，避免为了测试把生产数据送到未经批准的供应商。影子结果只用于比较，不可悄悄进入业务系统；涉及付费、留存与跨境处理时需走组织审批。
正式灰度按任务类别分别放量，固定回滚阈值。监控至少包含实际底层模型、路由原因、尝试次数、结构成功率、业务验收率、严重错误、P95 延迟、单位成功成本、限流与 5xx、人工接管和重复副作用。总体平均数不能掩盖某一高风险任务的退化。
四十八项验收合同怎样使用
本站提供的合同把测试分为任务识别、候选兼容、质量、性能与成本、故障切换、数据与安全、工具副作用、观测与恢复八组。每项记录 case_id、策略版本、输入摘要、允许候选、实际尝试顺序、最终模型、输出校验、工具读回、费用、延迟和决定。blocked 表示缺账号或环境，不能补记为 passed。
合同是静态可复用资产，不代表本站调用了 Azure、Bedrock 或任何商业模型，也不代表获得真实供应商账单。团队需要替换示例阈值，用自己的任务集运行；价格、型号、区域、政策和计划以运行当日官方页面与合同为准。若结构化失败、越权、严重事实错误、重复副作用、引用不可复核或回滚失败，应停止自动放量。
每次新增模型、调整路由规则、更换提示、修改工具 Schema、改变超时、开放新地区或供应商政策变化后，重跑受影响组。认证时保存策略与任务集版本，故障复盘才能重现当时为什么选择该模型。真正可用的多模型系统，不是永远选中最强模型，而是在选择错误或上游故障时也能安全停止、解释和恢复。
来源与适用边界
核心事实核验于 2026 年 10 月 13 日：Amazon Bedrock 智能提示路由、Microsoft Foundry model router、模型路由工作方式与监控、Azure 模型选择架构指南。功能、候选模型、地区、价格与预览状态会变化，实施前应重新核对。本文提供工程验收方法，不代表本站登录客户账户、运行生产流量或完成商业模型实测。
相邻任务可继续阅读 大模型 API 成本计算、长上下文与 RAG 选型 和 结构化输出验收。
