多模型工作流程其實藏著三個不同的決定，但大家常把它們統稱為「orchestration」。OpenRouter 在 2026 年 10 月 2 日的一篇比較文章把這件事拆開：LangChain 與 CrewAI 做的是工作流編排，OpenRouter 做的是模型路由與 provider 路由，兩者互不取代。對 builder 來說，這個拆分直接影響你要不要在專案裡多背一套框架。
三層各自負責什麼
按照 OpenRouter 的分法：工作流編排是規劃、狀態、記憶與委派，LangGraph 與 CrewAI 屬於這層；模型路由是為某次呼叫挑模型、出錯時換下一個，由 OpenRouter 的 models 參數處理；provider 路由則是決定哪個 endpoint 供應你選好的模型，請求帶工具時 Auto Exacto 會依工具呼叫表現重排 provider 順序，但不會改變你指定的模型。
關鍵結論是：你不需要第一層就能拿到後兩層。一個 models 清單加上幾個 if 敘述，就能在模型之間路由，不必引入 agent 框架。
框架的價值在你真的需要狀態與審核時
LangGraph 把工作流畫成節點圖，靠 checkpointer 存圖狀態、store 存跨執行緒的長期記憶，interrupt() 可以在任何節點暫停等人工核准。代價是每個節點、邊、狀態欄位都是你自己寫、自己維護的程式碼。
CrewAI 走另一條路：crew 由有 role、goal、backstory 的 agent 組成，flow 負責結構化的控制流程。你花比較多力氣寫任務描述、比較少力氣接節點——這是不同的取捨，不是精簡版的 LangGraph。
之前我在換一個模型就壞：agent 框架到底把 tool schema 翻譯放在哪一層也提過類似觀察：框架提供的抽象有真實成本，值不值得取決於你的工作流是否真的用得上它們。
同一條管線，兩種寫法
OpenRouter 用同一個兩步驟管線（一個模型起草、另一個審稿）示範了直接呼叫與 LangChain 版本的差異。直接版本是一個函式加兩個 models 清單：
def route(models, prompt):
response = requests.post(
"https://openrouter.ai/api/v1/chat/completions",
headers={"Authorization": f"Bearer {os.environ['OPENROUTER_API_KEY']}"},
json={"models": models, "messages": [{"role": "user", "content": prompt}]},
timeout=120,
)
response.raise_for_status()
body = response.json()
return body["choices"][0]["message"]["content"], body["model"]LangChain 版本則是用 ChatOpenRouter 搭配 with_fallbacks。兩者路由結果相同，差別在 fallback 在哪裡執行：直接版本由 OpenRouter 在 server 端同一個請求內完成；LangChain 版本由框架在你的行程裡接住失敗、再發第二個請求。
兩個容易誤會的點
第一，OpenRouter 的 fallback 是錯誤驅動的，不會判斷答案品質。想讓強模型審核弱模型的輸出，那是你程式碼裡的第二步，models 清單不會替你做。
第二，框架不是敵人。LangChain 有專用的 ChatOpenRouter 整合，CrewAI 也透過 LLM class 把 OpenRouter 列為 provider——你可以保留任一框架的編排，把 OpenRouter 當模型層放在底下。
實際的決斷標準
如果你的工作流需要可檢視、可恢復的多步驟管線、人工審核或跨執行緒記憶，LangGraph 的結構值得維護成本。如果只是「每步挑個模型、失敗就換下一個」，一個請求參數就夠了。中間地帶——有邊界的多輪工具迴圈——OpenRouter 的 Agent SDK 覆蓋這個情境，附驗證、串流與停止條件。順帶一提，每次回應都內建 usage 物件含 token 數與成本，先看清楚每步花多少，再決定要不要導入分級模型設定，會比反過來做省事得多。