Model Router

核心用法

Model Router 是一套基于 sessions_spawn 的任务分发系统，通过模型覆盖机制将不同类型的请求路由至最适合的 AI 模型。核心操作模式包括：

1. 轻量任务代理：使用 haiku-4.5 或 GLM 处理简单查询、摘要、基础问答等1-2步可完成的任务
2. 复杂任务代理：调用 codex-5.2 处理编程、调试、架构设计等需深度推理的任务
3. 均衡/创意代理：通过 sonnet 进行研究与分析，opus 处理创意写作

关键命令模式为 sessions_spawn --task "..." --model <alias>，支持标签追踪、超时控制和自动清理。

显著优点

• 成本优化显著：通过任务分层可将简单查询成本降至最低，避免对基础任务使用昂贵模型
• 并行执行能力：支持多任务并行派发，提升整体吞吐效率
• 动态升降级：提供渐进式复杂度策略，失败后可自动 escalade 至更强模型
• 用户意图尊重：识别"使用某模型"等明确指令，直接执行不覆盖
• 隔离性设计：子代理会话防止主会话上下文膨胀，保持主线程轻量

潜在局限

• 模型别名映射不透明：文档显示 haiku/GLM/sonnet/codex/opus 均指向 zai/glm-4.7，实际差异可能有限
• 分类启发式粗略：关键词触发规则（如"quick"→轻量）可能误判任务真实复杂度
• 上下文迁移成本："切换模型"时需人工迁移相关上下文，无自动化机制
• 故障恢复依赖人工：子代理失败后的分析、重试流程需手动执行
• 供应商锁定风险：底层均为智谱 GLM 系列，缺乏真正的多供应商路由能力

适合人群

• 高频调用 AI 且关注成本控制的开发团队
• 需处理混合任务类型（简单查询+复杂开发）的产品经理
• 已部署智谱模型体系的企业用户
• 希望实现"智能负载均衡"但无资源自研路由系统的中小团队

常规风险

1. 模型能力与预期不符：别名映射可能导致用户误以为切换了不同能力层级的模型
2. 超时配置不当：默认超时可能过长或过短，未根据任务类型预设合理值
3. 子会话泄露：--cleanup delete 为默认但仍需显式确认，敏感任务残留风险
4. 成本追踪盲区：虽提及 model-usage 技能关联，但未展示实时成本反馈机制
5. 过度路由开销：简单任务本身的 spawn 开销可能抵消模型成本节省

核心用法

model-router 是一款任务智能路由技能，通过分析用户请求自动匹配最优AI模型。核心机制基于关键词启发式分类，将任务划分为四个层级：简单任务（haiku-4.5/GLM）、中等复杂度研究与分析（sonnet）、编码与架构任务（codex-5.2）、创意与高质量需求（opus）。使用方法为通过 sessions_spawn 命令配合 --model 参数进行子代理委派，支持并行执行、超时控制及自动清理。

显著优点

1. 成本效益显著：通过精准匹配模型能力与任务复杂度，可大幅降低API调用成本，简单任务使用轻量模型成本仅为强力模型的1/10-1/50
2. 执行效率高：轻量模型响应延迟更低，并行委派机制进一步提升吞吐量
3. 架构清晰：决策流程明确（复杂度→类型→成本敏感度→容错性），易于理解和维护
4. 扩展性强：支持模型别名、自定义分类规则、多模式集成（成本优化/渐进升级/并行委派）

潜在局限

1. 分类依赖关键词匹配：启发式规则可能存在误判，如"debug"必然触发codex，但某些调试场景可能仅需简单查询
2. 无动态学习能力：分类逻辑静态硬编码，无法根据历史执行效果自动优化路由策略
3. 模型可用性依赖外部：实际效果受底层模型服务稳定性制约，SKILL.md中部分模型别名（如zai/glm系列）可能与实际部署环境不符
4. 上下文迁移成本：sessions_spawn创建隔离会话，复杂多步任务可能面临上下文断裂风险

适合人群

• 多模型平台用户：需要管理多个AI模型订阅、希望优化成本结构的企业或团队
• 高频API调用者：日均请求量大的开发者，可通过智能路由节省显著开支
• 任务类型多样者：工作流同时包含简单查询、深度研究、代码开发等多种任务形态

常规风险

1. 路由误判导致质量下降：过度追求成本优化可能将复杂任务错配至轻量模型，需人工复核关键输出
2. 子代理超时与失败：--timeoutSeconds配置不当可能导致长任务中断，建议复杂任务预留充足时间
3. 模型版本漂移：文档中的模型版本（如4.5/5.2）可能与实际服务端不一致，需定期验证session_status
4. 隐私隔离依赖：虽然本技能本身S级安全无网络调用，但 sessions_spawn委派后的子代理行为需额外关注