同一个 Agent 可能要做资料分类、长文总结、代码生成和结构化抽取。把所有请求都交给一个模型，配置简单，却很难解释成本、延迟和结果差异；让模型自己临场决定，又会把路由标准藏在一次次对话里。更稳的做法，是先把任务分成少数几类，再为每类写清首选模型、备用模型和不能接受的结果。
模型路由至少要回答四个问题：这是什么任务，输入有多大，结果需要多严格，首选模型不可用时能否切换。ZGI 的 Model Gateway 可以集中管理模型提供方、渠道、默认设置和 routing policies；这些公开能力能承接路由配置，但具体分类、阈值与切换条件仍需团队在目标环境中设计和验证。
先按任务写路由条件
路由规则应从任务目标开始，而不是从"哪个模型最强"开始。资料分类通常更看重稳定的标签格式；长文总结更看重上下文处理和引用边界；代码生成则需要明确语言、依赖和测试要求。可以为每类任务定义输入长度、输出格式、允许的工具范围和最低验收条件，再绑定首选模型。模型名称只是规则的一部分，输入与结果约束才决定它是否适合。
同一类任务也要保留边界。例如短文本抽取可以设置较小的上下文上限，超过上限就转到长上下文路线；结构化抽取要求返回固定字段，缺字段时进入复核；代码任务必须附带编译或检查步骤，不能只凭自然语言判断完成。这里的阈值是工程配置示例，需要用实际资料校准，不应写成某个模型的普遍性能结论。
路由条件最好能被人读懂。把"高质量模型"改成"合同条款总结，输入不超过某长度，输出必须含条款编号与风险理由"，把"便宜模型"改成"标签分类，固定字段，失败后允许人工补录"。规则越接近业务产物，后续排查越容易定位是任务分类、模型选择还是结果验收出了问题。
备用模型要有出口，结果要回到同一套验收
备用模型不是简单的自动重试。首选模型超时、渠道不可用、输入超过限制或输出缺少字段时，切换动作应记录触发原因、原任务标识和实际使用的模型。若任务涉及对外发送、批量写入或高风险判断，切换后应暂停并交给人确认；低风险的内部草稿可以进入备用路线，但仍要经过同一份结构化校验。
切换前先区分可恢复问题和内容问题。渠道暂时不可用，可能适合换模型；输出字段缺失，则应先检查提示与 schema，不能反复调用同一条错误路线；输入本身不完整，应返回待补资料状态。不同出口要在工作流中分开，否则运行记录里只会出现"重试成功"，却看不出结果为何变化。
验收不能只检查请求返回成功。对分类任务核对字段集合和允许值，对总结任务核对引用来源与覆盖范围，对代码任务核对语法、依赖和指定检查。验收失败时，保留模型响应、校验错误和路由版本，方便比较首选与备用路线的差异。ZGI 的 Workflow、结构化输出和运行状态/步骤/日志能力可以承接这类流程；文章中的规则仍是工程设计，不等于平台自动替团队完成判断。
上线前准备三组输入：边界清楚的正常任务、刚好超过输入限制的任务、首选模型不可用或返回缺字段的任务。逐组检查路由是否命中预期，备用模型是否只在规定条件下启用，结果是否进入正确的继续、补资料或人工复核出口。之后再根据真实失败记录调整规则，而不是先增加更多模型名称。
GitHub：https://github.com/zgiai/zgi