你用的模型可能在拖你 workflow 的後腿——聊聊我的 multi-model routing 策略
分享一下我最近做的一個決定：把 OpenClaw workflow 裡所有任務的模型選擇重新梳理了一遍。
說實話，我之前的做法很懶——全部丟給同一個模型，設定一次就不管了。偶爾覺得慢，偶爾覺得貴，但沒去深想過為什麼。直到有次我在跑一個 code review skill，用的是 Claude Sonnet，結果一個月帳單嚇到我，才開始認真研究模型 routing 這件事。
先說結論：大多數人用錯了模型，不是因為沒能力，而是因為習慣用「夠好」代替「最適合」。
我現在的做法是把任務分成三類：
高推理需求： 需要多步驟邏輯、架構決策、複雜 debug 的任務。這類我還是用 Claude Opus 或 GPT 5.5。貴一點但值得，因為你省下來 debug 的時間比 API 費用更值錢。
中等任務： 寫 commit message、整理 changelog、生成文件、做摘要。這類我換成 Qwen 3 或 DeepSeek V3，效果幾乎一樣，速度快一倍，價格差距有時候是十倍以上。
高頻輕量任務： 分類、格式化、關鍵字抽取、intent detection。這類我用 Gemma 4 26b 跑本地，幾乎零成本。
我的 routing 邏輯大概長這樣：
# simplified routing config
routing:
rules:
- match: task_type == "code_review" or task_type == "architecture"
model: anthropic/claude-opus-4
- match: task_type == "summarize" or task_type == "changelog"
model: deepseek/deepseek-v3
- match: task_type == "classify" or task_type == "format"
model: local/gemma-4-26b
fallback: openai/gpt-5.5
這個 config 我放在 skill 裡，每個 workflow 起跑的時候自動根據 task_type 決定用什麼模型。
有幾個踩過的坑值得提一下：
Caveat 1：中文能力差異很大。 我在用某些 cost-effective 模型的時候，中文輸出品質明顯下滑，特別是在需要語氣判斷或 context window 比較長的任務上。測一下再換，別直接全部切。
Caveat 2：latency 不等於 throughput。 有些模型回第一個 token 很快，但 token/sec 很低，整體完成時間反而比「慢」的模型還長。你要測的是 end-to-end 時間，不是 TTFT。
Caveat 3：routing 本身有成本。 如果你用一個模型來判斷「這個任務要用哪個模型」，那個 classifier 的延遲和費用也要算進去。我現在用 rule-based routing，沒有用 LLM 來做 routing 決策，就是為了省這塊。
最近我把這套 routing 邏輯跑了一個月，費用大概降了 60-65%，而且平均任務完成速度反而更快，因為輕量任務不用等大模型。
說穿了，multi-model routing 不是什麼高深技術，就是把「對的工具用在對的地方」這件事系統化。OpenClaw 在這塊的彈性很夠，自己包一個 routing skill 不算太難，難的是你願不願意花時間去梳理每個任務的需求。
如果你的 workflow 裡有固定重複的任務類型，值得花半天去分類一下，然後對應不同模型跑幾次測試。改起來沒那麼複雜，但省下來的費用和時間是真的。
作者：Jesse