正在加载，请稍候
多模型编排其实是三层独立决策：工作流编排、模型路由、提供商路由。LangGraph/CrewAI 做第一层，OpenRouter 做后两层，附同一管道的两种写法与选型判据。
把"多模型编排"当成一件事，是不少 Agent 项目返工的起点。它其实是三层独立的决策：谁决定下一步做什么、谁决定这次用哪个模型、谁决定由哪家服务商执行。
2026 年 10 月 2 日，OpenRouter 发了一篇把这三层摆上台面的文章：行业里被笼统称作"多模型编排"的能力其实是三件事——LangGraph 与 CrewAI 做第一层，平台侧做第二、第三层，谁都不替代谁。
| 维度 | 工作流编排 | 模型路由 | 提供商路由 |
|---|---|---|---|
| 回答的问题 | 下一步做什么、状态怎么存、子任务交给谁 | 这次用哪个模型、失败用哪个兜底 | 这个模型由哪家 endpoint 服务 |
| 典型载体 | LangGraph 的图、CrewAI 的 Crews / Flows | 请求体的 models 数组、openrouter/auto | 请求体的 provider 对象、Auto Exacto |
| 状态 / 记忆 | checkpointer + store；Flow 的 state 对象 | 无 | 无（仅会话粘性） |
| 回退语义 | 由你写的控制流决定 | 报错驱动：首个模型挂了就试下一个 | 按稳定性 / 价格 / 排序在多家之间切换 |
| 是否必须上框架 | 是，但图与角色要自己定义 | 否，一个数组加少量 if 就够 | 否，默认自动执行 |
| 不负责什么 | 选模型、选执行方 | 判断答案质量、跨步骤规划 | 更换模型（永不改变你写死的那个） |
拆开最直接的好处是故障定位变短：请求报错时，先判断是图里的节点状态没存对、兜底链配错了，还是某家服务商在抖——对应三处完全不同的配置。
用最普通的管道举例：先起草、再复核，每步都带失败回退。直连平台时，选模型与选执行方都在服务端完成：
import os, requests
def call(models, prompt):
r = requests.post(
"https://openrouter.ai/api/v1/chat/completions",
headers={"Authorization": f"Bearer {os.environ['OR_KEY']}"},
json={"models": models, "messages": [{"role": "user", "content": prompt}]},
timeout=120,
)
b = r.json()
return b["choices"][0]["message"]["content"], b["model"]
a, a_model = call(["anthropic/claude-sonnet-5", "openai/gpt-5.6-sol"], "写一段摘要")
b, b_model = call(["openai/gpt-5.6-sol", "anthropic/claude-sonnet-5"], "复核上一步")
print(a_model, b_model)换成 LangChain，则是每步一个模型对象，用 with_fallbacks 串起兜底链（ChatOpenRouter 是它现成的集成，两三行就能接上）。两版走的是同样两步、同样顺序，差别只在回退位置：直连版在服务端一次请求内完成，框架版是你的进程捕获失败后再发一次请求——前者对上层应用是一次调用，后者是两次，压测与计费口径都会不同。
执行方的选择在这之下全程自动跑：默认先排除最近 30 秒有明显故障的服务商，再在稳定的几家之间按价格的反平方加权挑便宜的，剩下的当兜底。官方例子是 $1/M、$2/M、$3/M 三家，若最贵那家刚出过故障，最便宜的会被首选的几率约为它的 9 倍。带工具的请求走 Auto Exacto，按工具调用质量重排。无论怎么排，都不会改变你请求里写死的那个模型。
一个容易被忽略的边界：透明故障转移只在流式输出开始前失败时干净；token 吐到一半才断，半截输出得应用自己兜。
结论先给：不上多模型、不上多家服务商，就别加这一层。价值只在下面这些条件出现时才成立。
但它不是越早越好。平台自己的路由基准页列了三条固有代价：切模型会重建输入缓存，请求反而更贵；只看 prompt 常常判断不出任务复杂度；路由处理越多，延迟越高。只有一个模型、一家服务商、流量也不大时，硬加一层是净亏。
| 判据 | 自建（如 LiteLLM） | 托管网关（如 OpenRouter） |
|---|---|---|
| 可观测性 | 日志与追踪落在自有基础设施，需自己接 Langfuse 一类 | 每个响应带用量与按请求成本，控制台统一看日志与活动 |
| 故障回退 | 自己实现健康检查与切换 | 默认价格加权负载均衡 + 30 秒故障窗口 + 兜底链 |
| 成本核算 | 按 key / 团队预算、成本上限需自己实现 | 按请求成本、按 key 与团队的花费控制、max_price 上限 |
| 合规审计 | 策略在自有基础设施内执行，适合强监管场景 | ZDR、data_collection 允许 / 拒绝、欧盟与美国的在区路由 |
| 运维负担 | 需要自托管并维护网关本身 | 零运维，改一次接入地址即可 |
前三条是工程问题，第四条是采购与合规问题。要求策略在自有基础设施内执行（例如 HIPAA 覆盖），自建或用 Portkey、Kong AI Gateway 一类更合适；更看重"别自己运维网关"，托管方案把接入压到改一次 base_url。
with_fallbacks 实现"强模型复核弱模型"——错。回退由报错触发，不评估答案好坏；质量兜底是应用层的第二步。provider.order 实现模型选择——也错。这一层只决定谁执行，不改变你指定的模型。站内另两篇和本文是三个不同槽位：一篇讲谷歌 AX 声明式编排运行时，落在"编排层内部用什么范式描述流程"；一篇讲决策环节该不该拆给小模型，落在"某一步该分给谁"。两者都在第一层内部做文章，本文讲的是三层之间的边界。把"谁来做""用哪个模型""哪家来跑"塞进同一层，正是多数架构返工的来源。
另有两条相关线索可以对照看：模型网关结算与企业 AI 采购账，以及从协议到多智能体编排的选型。
蓝曜炬辉 在企业 Agent 平台搭建里的做法是先把这三层画清楚，再决定哪层自建、哪层托管。
一定要上 LangGraph 或 CrewAI 吗？
不必。一个 models 数组加少量判断就能完成选择与回退；框架的价值在于规划、状态、人工审核与委派，不需要时就是负担。
models 回退会判断答案质量吗？
不会。上下文超长、限流、服务商宕机、审核拦截都会触发它，但它不评估首个模型答得好不好；想让强者复核弱者，得自己写第二步。
执行方这层会改掉我请求的模型吗？
不会。它只在同一模型的多个 endpoint 之间挑，响应里的 model 字段能核对最终是谁服务的。
什么时候不该引入模型路由？
单模型单服务商、流量不大、对延迟与缓存敏感时。跨模型切换会抬高成本，只看 prompt 也难判断复杂度，收益可能为负。
自建还是托管？
看四条判据：可观测性、故障回退、成本核算、合规审计。策略要留在自有基础设施内，自建更稳；追求零运维且要快速拿到多家服务商，托管更省。