使用多模型構建 AI Agents：實用架構指南

大多數 AI Agent 依賴單一模型來處理執行的每個階段。規劃步驟、工具呼叫、資料提取、摘要以及錯誤恢復，全都透過同一個 LLM 執行。雖然這種方法對於初步原型來說很直接，但在生產環境中卻會導致顯著的效率低下。

需要深度推理的規劃步驟，並不需要與基礎 JSON 提取步驟相同的模型。程式碼生成任務的需求與分類任務截然不同。使用像 Claude Fable 5 或 Claude Opus 4.8 這種高階推理模型來格式化日期字串，是一種昂貴的資源分配錯誤。

建構多模型 AI Agent 允許您將工作流程的每個步驟路由至最適合該特定任務的模型。本指南將探討如何設計、實作及管理這些多模型架構。

如果您是在 API 層而非 Agent 編排層工作，請參閱 Agent-First API Design 以及 Why Teams Switch from Direct Model APIs to a Unified AI API 作為本指南的補充。當底層 API 介面穩定到足以在不重寫編排程式碼的情況下更換模型時，多模型 Agent 的運作最為可靠。

:::info

關鍵要點

1. 模型與任務複雜度相匹配：使用小型、快速的模型進行路由、提取和格式化，將較大的推理模型保留給規劃和複雜分析。
2. 標準化 Schema：在每個交接點實施嚴格的輸出驗證（例如 Pydantic），以防止在不同模型供應商之間切換時出現合約偏移（contract drift）。
3. 為備援設計：建立自動化備援路徑，以處理速率限制（rate limits）、供應商中斷或延遲飆升，而不中斷 Agent 工作流程。
4. 集中化遙測（Telemetry）：追蹤每個步驟的延遲、輸入/輸出 token 數量及成本，以持續優化您的路由邏輯。 :::

---

多模型 Agent 架構

多模型 Agent 架構根據複雜度、成本和延遲需求，將任務分配給專門的模型。

使用者請求
    │
    ▼
┌─────────────┐
│   路由 (Router) │  ← 分類任務複雜度
│  (快速模型)   │
└──────┬──────┘
       │
   ┌───┴───┐
   ▼       ▼
┌──────┐ ┌──────┐
│簡單模型 │ │複雜模型 │
└──┬───┘ └──┬───┘
   │        │
   ▼        ▼
┌─────────────┐
│  聚合器 (Aggregator) │  ← 整合結果
│  (快速模型)   │
└─────────────┘

核心架構包含五個主要組件：

1. 路由 (Router)：一種快速、低成本的模型，根據複雜度和意圖對傳入任務進行分類。
2. 模型池 (Model Pool)：與不同任務類型（如推理、提取或程式碼生成）相匹配的模型集合。
3. 聚合器 (Aggregator)：一種快速模型，將平行步驟的結果組合成最終回應。
4. 備援策略 (Fallback Policy)：當主要選擇失敗、逾時或遇到速率限制時，決定使用哪個模型的規則。
5. 遙測層 (Telemetry Layer)：一種記錄模型選擇、延遲和每個步驟精確 token 成本的日誌系統。

若沒有備援策略和遙測，多模型 Agent 可能會變得難以除錯，並具有不可預測的延遲和成本特徵。

---

使用 OpenAI SDK 實作

使用統一的 API 閘道可讓您透過單一 SDK 和 API 金鑰存取來自不同供應商的模型。這簡化了模型切換和路由。

以下範例展示了基本的路由實作。模型可用性和定價應在 TokenLab 模型目錄 上進行驗證。

from openai import OpenAI

client = OpenAI(
    api_key="sk-tokenlab-xxx",
    base_url="https://api.tokenlab.sh/v1"
)

# 具備成本與能力分級的模型池
MODELS = {
    "router": "deepseek-v4-flash",        # 快速分類
    "simple": "deepseek-v4-flash",        # 提取、格式化
    "reasoning": "claude-sonnet-5",       # 規劃、分析
    "complex": "gpt-5.5",                 # 程式碼生成、複雜邏輯
    "budget": "deepseek-v4-flash",        # 批次處理
}

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

---

真實案例：程式碼審查管線

為了了解建構多模型 AI Agent 的實際影響，請考慮一個旨在審查 Pull Request (PR) 的管線。此工作流程將審查拆分為專門的步驟，而不是將整個程式碼差異 (diff) 發送給單一昂貴的模型。

def review_pr(diff: str) -> dict:
    """多模型 PR 審查管線。"""

    # 步驟 1：使用快速、低成本模型分類變更
    classification = client.chat.completions.create(
        model="deepseek-v4-flash",
        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-5",
        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-5.5",
        messages=[{
            "role": "user",
            "content": f"審查程式碼品質：命名、結構、"
                       f"錯誤處理、測試覆蓋率。\n{diff}"
        }]
    ).choices[0].message.content

    # 步驟 4：使用快速、低成本模型產生摘要
    summary = client.chat.completions.create(
        model="deepseek-v4-flash",
        messages=[{
            "role": "user",
            "content": f"將此 PR 審查摘要為 3 個要點：\n"
                       f"類型：{classification}\n"
                       f"安全性：{security[:500]}\n"
                       f"品質：{quality[:500]}"
        }]
    ).choices[0].message.content

    return {
        "classification": classification,
        "security": security,
        "quality": quality,
        "summary": summary
    }

成本與效率優化

下表概述了此管線的模型分配。確切定價因供應商和用量而異；請在 TokenLab 模型目錄 上驗證當前費率。

步驟	模型	輸入 Tokens	角色 / 專業領域
1. 分類	DeepSeek V4 Flash	~2,100	快速分類、低成本路由
2. 安全性	Claude Sonnet 5	~2,500	深度推理、安全性分析
3. 品質	GPT-5.5	~2,500	進階程式碼品質與結構審查
4. 摘要	DeepSeek V4 Flash	~1,200	快速、低成本文字聚合

若將所有四個步驟都透過 Claude Sonnet 5 或 GPT-5.5 這種旗艦推理模型執行，將會顯著增加成本。透過將較簡單的任務路由至 DeepSeek V4 Flash 等低成本模型，多模型管線在保留關鍵安全性分析步驟所需深度推理的同時，降低了整體 token 支出。

---

依能力而非僅依價格進行路由

雖然降低成本是一個常見目標，但路由決策也應考慮特定模型的能力。強健的路由策略會從四個關鍵維度評估模型：

• 推理深度：複雜邏輯、規劃和多步驟演繹。
• Context Window：任務所需的背景資訊或程式碼量。
• 工具使用可靠性：函數呼叫和結構化輸出生成的準確性。
• 延遲敏感度：使用者導向應用程式的速度需求。

這些維度有助於建立明確的路由規則：

• 分解和規劃任務路由至推理能力強的模型。
• 資料提取和格式化任務路由至快速、低成本的模型。
• 程式碼生成和語法分析任務路由至針對程式設計任務優化的模型。
• 跨儲存庫分析任務路由至具備大 Context Window 的模型。

若要使您的路由與這些需求保持一致，請參考 coding model comparison 和 pricing comparison，將您的工作流程步驟與當前模型基準進行匹配。

---

LangChain 整合

您也可以在 LangChain 等編排框架內實作多模型路由。以下範例使用統一的 API 基礎 URL 設定不同的模型：

from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate

# 初始化具備不同設定的模型
fast_model = ChatOpenAI(
    model="deepseek-v4-flash",
    api_key="sk-tokenlab-xxx",
    base_url="https://api.tokenlab.sh/v1"
)

reasoning_model = ChatOpenAI(
    model="claude-sonnet-5",
    api_key="sk-tokenlab-xxx",
    base_url="https://api.tokenlab.sh/v1"
)

# 定義專門的鏈 (chains)
classify_chain = ChatPromptTemplate.from_template(
    "分類此請求的意圖：{input}"
) | fast_model

analyze_chain = ChatPromptTemplate.from_template(
    "對此問題執行詳細分析：{input}"
) | reasoning_model

---

何時使用多模型 Agent

引入多模型會增加架構複雜性。此方法通常在以下情況最為有利：

• 多樣化的任務需求：Agent 處理混合了簡單任務（如分類或格式化）與複雜任務（如策略規劃或程式碼生成）的工作。
• 高用量與高成本：每月 API 支出高到足以透過優化獲得顯著節省。
• 專門的模型優勢：工作流程受益於特定供應商的優勢，例如 Gemini 的 Context Window、Claude 的程式設計能力或 GPT 的工具使用速度。
• 非對稱的延遲需求：工作流程的某些部分必須立即返回結果，而其他背景步驟可以花費較長時間。

對於單一用途的 Agent 或簡單的聊天介面，單一模型通常更容易維護。如果每個請求都需要相同程度的能力，那麼路由的營運開銷可能並不划算。

---

常見失敗模式

多模型架構引入了需要緩解的特定失敗模式：

1. 過度設計的路由 (Over-Engineered Routers)

如果路由提示詞變得過於複雜，分類步驟本身可能會變得緩慢且昂貴。請保持路由提示詞簡潔，並將分類類別保持寬泛。

2. 輸出合約偏移 (Output Contract Drift)

即使被指示返回 JSON，不同模型格式化輸出的方式也可能不同。一個模型可能返回原始 JSON，而另一個則將其包裹在 Markdown 區塊中。為了防止下游解析器失敗，請在每個步驟交接處使用 Pydantic 等驗證函式庫強制執行嚴格的 Schema。

3. 隱性的品質下降

如果備援策略在主要供應商中斷期間將請求路由至較低階的模型，Agent 可能會在不引發錯誤的情況下返回品質較低的答案。實施明確的 rate limiting strategy 和警報系統有助於追蹤備援何時處於啟用狀態。

4. 分散的遙測

當模型使用量分散在多個直接供應商 API 時，彙總成本和效能指標會變得困難。透過單一閘道集中請求可簡化日誌記錄和成本追蹤。

---

最小化評估迴圈

為了維護多模型 Agent，請建立一個基本的評估迴圈來追蹤效能。您可以將每次執行的以下指標記錄到資料庫表中：

• 任務類別：由路由分配的分類。
• 選定模型：每個步驟選擇的模型。
• 步驟延遲：完成每個步驟所需的時間。
• Token 使用量：精確的輸入和輸出 token 數量。
• 備援狀態：是否觸發了備援模型。
• 使用者回饋：最終輸出是否成功的二元指標。

分析這些資料有助於確定路由是否選擇了正確的模型、哪些步驟佔用了大部分成本，以及備援模型是否維持了可接受的品質。

---

常見問題 (FAQ)

如何處理不同模型之間不同的提示詞格式？

不同的模型對不同的提示詞結構反應最佳。例如，有些模型在系統提示詞 (system prompts) 下表現更好，而另一些則偏好嵌入在使用者提示詞中的指令。為了處理此問題，請將您的提示詞抽象化為根據目標模型進行調整的模板，而不是將相同的原始字串發送給池中的每個模型。

路由是否會為使用者導向的應用程式增加太多延遲？

路由確實會為分類步驟引入少量的延遲。您可以透過使用高度優化、低延遲的模型作為路由、保持最大 token 限制在低位（10 個 token 以下），或在可以從使用者應用程式狀態或進入點推斷出分類時進行平行處理，來將此影響降至最低。

切換模型時如何防止 JSON 解析錯誤？

為了防止解析錯誤，請使用模型供應商支援的結構化輸出功能（例如 JSON 模式或工具呼叫）。此外，在將負載傳遞給管線中的下一個步驟之前，請使用 Pydantic 或類似函式庫將所有模型輸出包裹在驗證層中，以進行解析、驗證和修復。

---

透過單一 API 存取每個模型：開始使用 TokenLab，只需一個 API 金鑰即可存取超過 300 個模型。建構多模型 Agent，無需管理多個供應商帳戶或為不同 API 重寫路由邏輯。