编排、模型路由、供应商路由：多模型系统的三层职责，别都塞进一个框架
多模型系统越改越乱，多数时候不是架构不够先进，而是三层职责被压成了一层。
OpenRouter 在一篇技术文章里把多模型编排拆成三层：工作流编排、模型路由、提供商路由。它的判断很明确——LangGraph、CrewAI 这类框架负责的是工作流编排；而「同一个任务该调哪个模型」「同一个模型该走哪家算力」，属于另外两层，二者并非互相替代的关系。LangChain 也单独写过在 Agent Harness 中构建模型路由器的做法。
三层各自在管什么
- 工作流编排：谁在什么时候调用谁、状态怎么流转、重试与回滚的语义是什么。它关心的是流程的正确性。
- 模型路由：同一类任务在多个模型之间怎么选——按质量、按成本、按置信度。它关心的是「这一步该花多少钱买多少确定性」。
- 提供商路由：同一个模型走哪家算力——按可用性、价格、延迟、区域合规。它关心的是供给侧的稳定性。
把三层分清之后，有两个好处会立刻显现：换模型不需要动流程，换供应商不需要动模型。
为什么混在一起会出事
最常见的坏味道，是把模型名写死在业务逻辑里：if 任务类型 == "摘要": call("model-a")。这种写法当下能跑，但它把「策略」编译进了「流程」——等你要换掉 model-a，得回头改状态机；等某家算力涨价，又得改一遍。更糟的是回退逻辑：路由层失效时应由谁兜底，在混写之后通常没人说得清。
一个可以今天就做的自检
拿出你的架构图，给每个模块标注它属于哪一层。如果出现这些情况，就说明分层已经开始坍缩：
- 业务代码里出现具体模型名或供应商域名；
- 「降级」被写在提示词里而不是路由配置里；
- 换了模型之后需要重新跑一遍集成测试才能确认没坏。
分层不是为了让架构图好看，而是为了让变更可控。 每一层独立演进的成本，远低于一次跨层重构。把「模型名是配置、不是代码」这条当成纪律，多模型系统就稳了一大半。