AI代理架構：模型路由與工具發現

連接一個大型語言模型（LLM）足以讓應用程序生成文本，但這不足以讓AI代理完成現實世界的任務。

要求模型總結已在其上下文中的文檔，模型層就足夠了。要求它比較今天的競爭者價格、豐富公司記錄、檢查社交帳戶或選擇最適合不熟悉工作的API，缺失的部分就變得明顯：代理需要一種可靠的方式來訪問外部系統。

因此，生產代理需要做出兩個獨立的決策：

哪個模型應該處理這一步？
哪個工具或API應該提供數據或操作？

AIHubMix通過統一的模型訪問和請求時的模型路由來解決第一個決策。Monid則通過運行時工具發現、架構檢查和按次計費執行來解決第二個問題。這些產品位於同一架構的不同層次上。

披露：本文是與Monid的內容合作的一部分。AIHubMix是下面討論的模型平台；Monid是工具平台。每個平台都可以獨立使用。

AI代理內部的兩個路由問題

代理的運行很少是一次同質的模型調用。一個研究代理可能會對請求進行分類、搜索當前信息、提取結構化事實、比較結果並撰寫最終答案。這些步驟需要不同的能力。

在模型外部也是如此。一個公司研究任務今天可能需要一個搜索API，明天需要一個公司豐富端點，下週需要一個瀏覽器自動化工具。如果每個模型和工具在構建時都是硬編碼的，每個新任務就變成了一個整合項目。

這兩個層次是平行的：

	模型層	工具層
核心決策	哪個模型應該回答？	應該調用哪個API？
選擇時間	每次請求	每個任務，在運行時
輸入	提示、模式、質量和延遲需求	目標、所需數據或操作、架構和價格
輸出	模型完成	外部數據或執行的操作
示例	AIHubMix	Monid

這種分離很重要。一個更好的模型無法創建對實時數據的訪問，而一個更大的工具目錄無法對其返回的數據進行推理。代理需要這兩種能力，並且它們之間需要有明確的合同。

Monid在為什麼AI代理需要兩個整合中展示了互補的工具側視角。從模型的角度來看，架構的教訓是相同的：保持模型選擇和工具選擇的獨立性，然後針對每個層次進行優化。

為什麼一個固定模型在代理循環中變得昂貴

在各處使用一個模型看起來很簡單。實際上，它迫使每一步都在能力、延遲和價格之間接受相同的權衡。

考慮一個市場研究代理：

意圖分類是簡短且機械的。
工具選擇需要可靠的指令跟隨。
從返回的JSON中提取字段主要是轉換。
最終報告可能需要更強的推理和更好的寫作。

將所有四個步驟發送到最有能力的模型會浪費例行工作上的金錢。將所有四個步驟發送到最便宜的模型可能會降低用戶閱讀的唯一輸出的質量。隨著代理循環的增長，這種妥協在每次調用中都會重複。

AIHubMix提供了一個與OpenAI兼容的端點，涵蓋廣泛的模型目錄。現有的OpenAI SDK整合可以通過更改API密鑰和base_url指向AIHubMix：

from openai import OpenAI

client = OpenAI(
    api_key="<AIHUBMIX_API_KEY>",
    base_url="https://aihubmix.com/v1",
)

response = client.chat.completions.create(
    model="auto:balanced",
    messages=[
        {"role": "user", "content": "對此請求進行分類並提出下一步。"}
    ],
)

將model設置為auto將模型選擇移入請求路徑。路由器分析任務並將其解析為合適的模型。策略後綴使優化目標變得明確：

路由器值	優先級	典型代理步驟
`auto`	成本優先	批量工作和例行轉換
`auto:balanced`	能力、成本和延遲	通用代理工作
`auto:quality_first`	能力優先	複雜推理和最終交付物
`auto:latency_critical`	速度優先	互動循環和輕量級規劃

路由不會增加額外的費用。請求按實際處理它的模型的標價計費。解析的模型和路由詳細信息在響應中公開，包括X-Aihubmix-Router-Resolved-Model標頭，因此決策保持可觀察，而不是變成黑箱。

完整的行為、支持的端點、政策和當前限制在AIHubMix LLM路由器指南中有詳細記錄。

模型路由不會給代理提供實時數據

在配置了模型路由後，代理可以為每一步選擇更好的大腦。它仍然無法知道模型訓練數據後發生了什麼變化，訪問私有業務系統，或在另一個應用程序中執行操作，除非有工具提供該能力。

這就是許多代理項目積累脆弱代碼的地方。一個團隊連接一個搜索API，然後一個抓取API，然後一個豐富API。每個整合都引入了另一個帳戶、憑證、請求格式、錯誤模型和計費關係。工具描述通常被複製到系統提示中，並逐漸變得過時。

失敗模式是危險的，因為它看起來可能是成功的。一個模型可能會對過時的架構產生一個似是而非的調用，接收不完整的響應，並繼續好像任務成功了。運行時架構檢查比要求模型記住訓練或舊提示中的API合同更安全。

因此，工具層在執行之前應回答三個問題：

什麼工具可以滿足這個目標？
現在適用的架構和價格是什麼？
調用實際返回了什麼結果？

工具發現是第二個路由層

Monid將工具訪問轉變為發現-檢查-運行的工作流程。代理不再需要開發人員預測每個可能需要的API，而是可以用自然語言搜索目錄，檢查候選者的合同，並執行所選的端點。

基本流程如下：

# 1. 找到符合目標的工具
monid discover -q "從公共網頁查找當前產品定價"

# 2. 閱讀所選端點的架構和定價
monid inspect -p PROVIDER_SLUG -e ENDPOINT_PATH

# 3. 只有在代理檢查了合同後才執行
monid run -p PROVIDER_SLUG -e ENDPOINT_PATH \
  --query '{"url":"https://example.com/product"}'

發現和檢查讓代理在花費任何費用之前比較選項。執行根據所選端點的定價模型計費。開發人員保持一個整合，而代理則獲得跨多個提供者的工具訪問。

對於可以閱讀設置說明的代理運行時，Monid還發布了一個機器可讀的技能：

設置 https://monid.ai/SKILL.md

Monid工作流程文檔更詳細地解釋了目錄、檢查和執行階段。

兩個層次如何協同工作

模型網關和工具層應保持獨立組件，並有一個小而明確的交接：

代理接收用戶目標。
AIHubMix將計劃調用路由到適當的模型。
計劃確定缺失的信息或所需的外部操作。
Monid發現候選工具並公開其架構和價格。
代理在其權限和預算內選擇並運行工具。
工具返回事實或操作結果。
AIHubMix根據所需的質量、成本或延遲路由綜合調用。
代理返回基於工具結果的答案。

在簡化的Python中，模型側的調用可以保持不變，而工具結果作為上下文插入：

from openai import OpenAI

client = OpenAI(
    api_key="<AIHUBMIX_API_KEY>",
    base_url="https://aihubmix.com/v1",
)

# 一個快速模型對於輕量級的規劃步驟是足夠的。
plan = client.chat.completions.create(
    model="auto:latency_critical",
    messages=[
        {
            "role": "user",
            "content": "計劃如何比較這些產品的當前價格。",
        }
    ],
)

# 你的代理使用Monid來發現、檢查和運行合適的工具。
# 用該調用返回的結構化結果替換這些佔位符。
tool_result = {
    "source": "<source-url>",
    "data": "<structured-tool-result>",
}

report = client.chat.completions.create(
    model="auto:quality_first",
    messages=[
        {
            "role": "system",
            "content": (
                "寫一個簡明的比較。僅使用提供的工具結果，"
                "保留來源URL，並說明何時缺少值。"
            ),
        },
        {"role": "user", "content": str(tool_result)},
    ],
)

重要的細節不是行數的多少，而是這兩個選擇都不需要永久嵌入應用邏輯中。模型可以隨著提示的變化而變化，工具可以隨著任務的變化而變化。

成本控制應該在兩個層次上

模型和工具的成本使用不同的單位，因此應該分開計量。

在模型層，解析的模型決定了令牌定價。AIHubMix使這一決策可追溯，並允許開發人員選擇路由策略或限制API密鑰可以使用的模型。例行步驟可以偏向成本或延遲，而面向用戶的輸出可以偏向質量。

在工具層，端點可能按調用或按結果收費。Monid在檢查期間公開定價，執行之前。代理可以拒絕超出預算的端點，偏好經過驗證的選項，或在進行異常昂貴的操作之前請求批准。

有用的生產控制包括：

每個API密鑰的模型白名單或價格上限。
每個任務的最大工具調用預算。
受管數據的提供者或端點白名單。
將模型路由決策連接到工具調用和最終答案的日誌。
在不可逆或敏感操作之前的明確確認。
輸出驗證，以便將工具數據視為不受信任的輸入，而不是指令。

這種分離還使成本調試變得更容易。如果一次運行變得昂貴，令牌日誌顯示代理是否推理過多，而工具日誌顯示它是否獲取過多。修復方法是不同的，架構應該保持這一區別。

可靠性需要新鮮的合同和可見的決策

動態選擇不應意味著不可預測的行為。

在模型側，AIHubMix報告每個請求的解析模型和路由策略。會話粘性可以在多輪工作中保持模型的一致性和提示緩存的好處，而回退行為可以在必要時遠離不健康的模型。

在工具側，代理在進行付費調用之前檢查當前端點架構。發現結果包括比較候選者所需的信息，而實際調用的結果成為傳遞到最終完成的唯一外部證據。

這些控制共同創建了一個有用的審計跟蹤：

用戶目標
  -> 路由決策和解析模型
  -> 發現的工具候選者
  -> 檢查的架構和價格
  -> 選擇的端點和結果
  -> 最終模型決策和基於結果的回應

這條跟蹤比僅僅擁有多個模型或多個API更有價值。它解釋了代理為什麼做出每個選擇以及什麼證據支持其答案。

何時不需要兩個層次

並非每個工作流程都能從運行時選擇中受益。

如果應用程序將一個穩定的提示發送給一個基準模型，直接指定該模型比路由更簡單且更具可預測性。如果一個計劃的管道始終調用一個已知的API，直接整合該API可能比添加發現層更清晰。

當多樣性是工作負載的一部分時，兩層架構才會獲得其地位：

提示的差異足夠大，以至於最佳模型隨步驟而變。
代理進行多次模型調用，並需要控制累積成本或延遲。
所需工具無法在構建時完全預測。
外部數據必須是最新的，且其來源必須是可見的。
團隊希望在不為每個新功能添加新的供應商整合的情況下增加能力。

根據應用程序實際需要做出的決策，使用模型層、工具層或兩者。

圍繞決策而非依賴構建代理

生產AI代理的定義不在於它能夠訪問多少模型或API，而在於它是否能為當前步驟選擇正確的能力、在預算內運作並解釋發生了什麼。

AIHubMix為代理提供了統一的模型端點和基於成本、質量和延遲優先級的請求時路由。Monid則為其提供運行時工具發現、當前架構、可見定價和跨外部提供者的執行。

一層決定代理的思考方式。另一層決定它如何發現和行動。保持這些決策的分離會產生一個更容易擴展、觀察和控制的代理。

從AIHubMix快速入門開始，然後通過Monid連接工具側。

常見問題

AI代理的模型路由是什麼？

模型路由根據任務類型、能力、成本和延遲等因素為每個請求選擇模型。使用AIHubMix，將model設置為auto或策略如auto:quality_first可以實現請求時選擇，同時保留與OpenAI兼容的API。

如果LLM已經有知識，為什麼AI代理還需要工具？

LLM從其接收到的上下文和訓練期間學到的知識生成答案。它無法可靠地知道當前價格、查詢私有數據庫或執行外部操作，除非有連接的工具。工具提供實時數據和執行；模型則計劃並解釋結果。

模型網關與MCP伺服器或工具平台是同一回事嗎？

不是。模型網關將推理請求路由到模型。MCP伺服器和工具平台向代理公開外部能力。它們解決互補的整合問題，可以一起使用。

AIHubMix和Monid可以獨立使用嗎？

可以。AIHubMix可以為沒有動態工具需求的應用程序路由模型調用。Monid可以為使用其他模型提供者或網關的代理提供工具發現。當代理需要在兩個層次上進行運行時選擇時，使用兩者是有用的。

我如何保持自動路由的可審計性？

記錄每個任務的解析模型、路由策略、工具候選者、檢查的價格、選擇的端點和返回的結果。AIHubMix在響應中公開模型路由詳細信息，而Monid則將發現和檢查與執行分開，以便在付費調用之前記錄工具決策。