大多數 AI Agent 都使用單一模型處理所有事務。規劃步驟、工具調用、摘要總結、錯誤恢復。這在 Demo 演示時可行，但在生產環境中卻是一種浪費。
需要深度推理的規劃步驟，與 JSON 提取步驟所需的模型並不相同。程式碼生成任務與分類任務的要求也不同。使用 Claude Opus 4.6（每 1M output tokens 25 美元）來格式化日期字串，就像聘請資深建築師來刷牆一樣。
以下是如何構建能將每個步驟路由到最佳模型的 Agent。
如果您是在 API 層而不是 Agent 層工作，請在閱讀本文的同時參考 Agent-First API 設計 以及 為什麼團隊從直接使用模型 API 轉向統一 AI API。當底層 API 介面足夠穩定，可以在不重寫編排程式碼的情況下更換模型時，多模型 Agent 的效果最好。
多模型 Agent 架構
使用者請求
│
▼
┌─────────────┐
│ 路由器 │ ← 分類任務複雜度
│ (快速模型) │
└──────┬──────┘
│
┌───┴───┐
▼ ▼
┌──────┐ ┌──────┐
│ 簡單 │ │ 複雜 │
│ 模型 │ │ 模型 │
└──┬───┘ └──┬───┘
│ │
▼ ▼
┌─────────────┐
│ 聚合器 │ ← 整合結果
│ (快速模型) │
└─────────────┘
三個組成部分：
- 一個根據複雜度對傳入任務進行分類的路由器 (Router)
- 一個匹配不同任務類型的模型池
- 一個在需要時整合結果的聚合器 (Aggregator)
在實踐中，生產環境的 Agent 通常還需要另外兩個部分：
- 當偏好模型失敗或變慢時的 Fallback（回退）策略
- 記錄每個步驟的模型選擇、延遲和成本的遙測層 (Telemetry layer)
如果沒有這兩點，多模型 Agent 很快就會變成一個行為不可預測的黑盒子。
使用 OpenAI SDK 實作
透過聚合器使用單一 API key，您可以存取所有模型，而無需管理多個 SDK：
from openai import OpenAI
client = OpenAI(
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
# 具有成本/能力層級的模型池
MODELS = {
"router": "gpt-4.1-mini", # $0.40/1M in - 快速分類
"simple": "gpt-4.1-mini", # $0.40/1M in - 提取、格式化
"reasoning": "claude-sonnet-4-6", # $3.00/1M in - 規劃、分析
"complex": "gpt-4.1", # $2.00/1M in - 程式碼生成、多步驟
"budget": "deepseek-chat", # $0.28/1M in - 批量處理
}
def route_task(task: str) -> str:
"""使用廉價模型分類任務複雜度。"""
response = client.chat.completions.create(
model=MODELS["router"],
messages=[
{"role": "system", "content": """將此任務分為以下一類：
- simple: 數據提取、格式化、翻譯
- reasoning: 分析、規劃、比較
- complex: 程式碼生成、多步驟問題解決
- budget: 批量處理、非關鍵任務
僅回覆類別名稱。"""},
{"role": "user", "content": task}
],
max_tokens=10
)
category = response.choices[0].message.content.strip().lower()
return MODELS.get(category, MODELS["simple"])
def execute_task(task: str, context: str = "") -> str:
"""將任務路由到適當的模型並執行。"""
model = route_task(task)
messages = []
if context:
messages.append({"role": "system", "content": context})
messages.append({"role": "user", "content": task})
response = client.chat.completions.create(
model=model,
messages=messages
)
return response.choices[0].message.content
實戰案例：程式碼審查流水線
這是一個審查 Pull Request (PR) 的實用多模型 Agent：
def review_pr(diff: str) -> dict:
"""多模型 PR 審查流水線。"""
# 步驟 1：分類變更（廉價模型）
classification = client.chat.completions.create(
model="gpt-4.1-mini",
messages=[{
"role": "user",
"content": f"分類這些程式碼變更：{diff[:2000]}\n"
"類別：bugfix, feature, refactor, docs, test"
}],
max_tokens=20
).choices[0].message.content
# 步驟 2：安全掃描（推理模型）
security = client.chat.completions.create(
model="claude-sonnet-4-6",
messages=[{
"role": "system",
"content": "你是一位安全審查員。檢查： "
"SQL 注入、XSS、身份驗證繞過、程式碼中的金鑰、 "
"不安全的反序列化。請明確指出行號。"
}, {
"role": "user",
"content": f"審查此 diff 的安全問題：\n{diff}"
}]
).choices[0].message.content
# 步驟 3：程式碼品質（通用模型）
quality = client.chat.completions.create(
model="gpt-4.1",
messages=[{
"role": "user",
"content": f"審查程式碼品質：命名、結構、 "
f"錯誤處理、測試覆蓋率。\n{diff}"
}]
).choices[0].message.content
# 步驟 4：摘要（廉價模型）
summary = client.chat.completions.create(
model="gpt-4.1-mini",
messages=[{
"role": "user",
"content": f"用 3 個重點總結此 PR 審查：\n"
f"類型：{classification}\n"
f"安全：{security[:500]}\n"
f"品質：{quality[:500]}"
}]
).choices[0].message.content
return {
"classification": classification,
"security": security,
"quality": quality,
"summary": summary
}
典型 PR 審查（2K token diff）的成本明細：
| 步驟 | 模型 | Input Tokens | 成本 |
|---|---|---|---|
| 分類 | GPT-4.1-mini | ~2,100 | $0.0008 |
| 安全 | Claude Sonnet 4.6 | ~2,500 | $0.0075 |
| 品質 | GPT-4.1 | ~2,500 | $0.0050 |
| 摘要 | GPT-4.1-mini | ~1,200 | $0.0005 |
| 總計 | ~$0.014 |
如果所有四個步驟都使用 Claude Sonnet 4.6，成本約為 0.028 美元。多模型方法將成本降低了 50%，同時在最關鍵的地方（安全審查）使用了最強大的模型。
依能力路由，而不僅僅是價格
許多團隊開始進行多模型路由時遵循一個簡單規則：昂貴的任務交給昂貴的模型，廉價的任務交給廉價的模型。
這是一個很好的初步嘗試，但還不夠。
更強大的路由策略會考慮四個維度：
- 推理深度 (reasoning depth)
- 上下文長度 (context length)
- 工具調用可靠性 (tool-use reliability)
- 延遲敏感度 (latency sensitivity)
這會產生更好的規則：
- 規劃和任務分解交給推理能力強的模型
- 提取和格式化交給廉價、快速的模型
- 程式碼審查交給最擅長發現 Bug 的模型
- 全專案範圍的分析交給具有最大上下文窗口的模型
這也是為什麼 程式碼模型比較 和 價格比較 應該直接用於指導您的路由器，而不是僅僅放在研究資料夾中。
LangChain 整合
from langchain_openai import ChatOpenAI
# 建立具有不同配置的模型實例
fast = ChatOpenAI(
model="gpt-4.1-mini",
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
reasoning = ChatOpenAI(
model="claude-sonnet-4-6",
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
# 在 LangChain 鏈中使用
from langchain_core.prompts import ChatPromptTemplate
classify_chain = ChatPromptTemplate.from_template(
"Classify: {input}"
) | fast
analyze_chain = ChatPromptTemplate.from_template(
"Analyze in depth: {input}"
) | reasoning
何時使用多模型 Agent
多模型路由增加了複雜性。在以下情況下是值得的：
- 您的 Agent 處理多樣化的任務類型（而不僅僅是聊天）
- 每月 API 成本超過 100 美元（節省的成本變得有意義）
- 您需要特定模型的優勢（Claude 用於程式碼，Gemini 用於長上下文，GPT 用於速度）
- 某些步驟對延遲敏感，而其他步驟則不然
對於簡單的聊天機器人或單一用途的 Agent，單一模型就足夠了。當每個請求都需要相同的能力時，路由的開銷並不合理。
轉折點通常是以下情況之一：
- 您在低價值任務上支付了高昂的推理費用
- 單一供應商的服務中斷已成為真正的業務風險
- 工作流中的上下文需求差異巨大
- 您需要在一個昂貴的核心階段周圍增加更便宜的審查/提取/摘要階段
如果以上皆非，單一模型仍然是正確的選擇。
常見失敗模式
多模型系統會以可預測的方式失敗：
1. 路由器過於「聰明」
如果路由器的 Prompt 變成了一個巨大的分類練習，您在決定該做什麼上花費了太多。請保持路由器的廉價和粗放。
2. 輸出合約偏移 (Output contracts drift)
一個模型返回乾淨的 JSON，另一個返回帶有 JSON 區塊的散文，導致您的下游解析器崩潰。在每次交接時使用明確的 Schema 和驗證。
3. Fallback 靜默改變品質
在供應商壓力期間路由到較便宜的模型，如果使用者看到完全不同的品質特徵，會讓 Agent 看起來不穩定。這就是為什麼 速率限制策略 (Rate limiting strategy) 應該包含在設計中，而不是事後才考慮。
4. 缺少成本報告
如果您不記錄每個步驟的模型選擇、成本和延遲，您就無法判斷多模型設計是否真的節省了資金。
最小化評估循環
您不需要龐大的評估平台就能負責任地運行多模型 Agent。
從每次運行的單個表格或資料庫表開始記錄：
- 使用者任務類別
- 路由器決策
- 每個步驟使用的最終模型
- 每個步驟的延遲
- 總 token 成本
- 是否觸發了 Fallback
- 使用者是否接受了答案
這為您提供了足夠的信號來回答關鍵問題：
- 路由器是否足夠頻繁地選擇正確的昂貴模型？
- 哪個步驟消耗了大部分預算？
- Fallback 是在挽救運行，還是僅僅隱藏了不穩定性？
- 廉價路徑對於重複性任務是否足夠好？
這也是為什麼統一網關很有幫助。當模型使用分佈在多個供應商時，很難組裝出一份可比較的運行帳本。當一切都通過一個 API 層時，檢測負擔就會降低。
保持架構簡潔穩定
最好的多模型 Agent 不會讓人感到奇特。它們在操作上讓人感到「枯燥」（穩定且可預測）。
這意味著：
- 進入編排層的請求形狀保持穩定
- 有一個統一的地方定義路由規則
- 有一個統一的地方檢查成本和延遲
- 每個任務系列有一個 Fallback 策略
- 模型允許列表 (Allowlists) 有單一事實來源
如果您的 Agent 圖譜看起來很聰明，但您的操作員無法解釋為什麼一個請求去了這個模型而不是另一個，那麼設計還沒有完成。
何時不該使用多模型 Agent
也有一些明顯的情況是簡單設計勝出的。
不要僅僅因為模型目錄很大就增加路由。
在以下情況下堅持使用單一模型：
- 產品重複執行一項狹窄的任務
- 模型之間的品質差異對使用者無關緊要
- 您的流量太低，成本優化無關緊要
- 您的運維監控已經不足
- 您還沒有足夠強大的評估 (Evals) 來判斷路由是有利還是有害
一個經過精心挑選、具有良好重試機制、Prompt 衛生和可觀測性的單一模型，通常優於一個沒人信任的華麗多模型圖譜。
正確的問題不是「我們能路由嗎？」而是「路由是否為此工作流帶來了更好的品質、更低的成本或更安全的失敗行為？」
如果答案模糊不清，請保持架構簡單，直到工作流本身變得更加多樣化。
關鍵要點
- 使用能處理好每個步驟的最廉價模型
- 將昂貴模型保留給真正需要的任務
- 分類/路由步驟應始終使用最廉價的可用模型
- 衡量每次 Agent 運行的實際成本，而不僅僅是每 token 價格
- 使用單一 Key 的 API 聚合器可以顯著簡化多模型存取
多模型 Agent 本身並不一定更好。只有當工作流中確實包含不同類型的工作時，它們才會更好。
透過一個 API 存取每個模型：LemonData 使用單一 API key 提供 300 多個模型。構建多模型 Agent，無需管理多個供應商帳戶，也無需為每對供應商重新開發路由。