dsh-model-router

实际使用中，模型池是常态：一条便宜快速的、一条能力更强的、一条备用兜底的。问题在于，如果在配置里硬编码某一条模型 ID，任何一家 provider 的故障都会直接变成你的服务中断。dsh-model-router 把路由这件事从 harness 核心逻辑中抽离出来——你只需声明一条虚拟模型 ID，在模型选择器里它看起来和任何一个真实模型没有区别，但背后是一组你定义的候选池，由路由算法决定每次请求真正落在谁身上。

最核心的体验是透明故障转移：当某个候选超时或报错时，插件自动把同一条请求投递给下一个候选，用户侧看不到任何错误提示；而响应的 provenance 里会如实记录究竟是哪一条模型给出了答案、哪些候选正处于退避冷却期。内置两种算法——priority 模式优先尝试首选候选，失败后按指数退避逐步放开，给恢复中的模型留出时间；round-robin 模式则把调用均匀分发给池内所有候选。若有更精细的策略需求，RoutingAlgorithm 暴露了 select、onFailure、onDispatch、onSuccess 四个工厂钩子，注册一条自定义算法即可接入，无需改动 harness 主流程。

适合的场景很直接：你同时在两三家 provider 之间切换，agent 工作流需要至少一条模型始终可用，又不想为每次故障手写重试逻辑。一条路由声明就够，剩下的交给算法。