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