在 AgentBox 上打造多模型 agent：一把金鑰、200 多種模型、零路由膠水碼

多數正式環境的 agent，在一次執行中，會用到好幾個模型。舉例來說，一個客服 agent，可能先用小而快的模型，把進來的工單分類，再用 embedding 模型拉出上下文，最後把困難的推理步驟，交給前沿模型；一個程式 agent，則可能用某個模型起草、另一個模型審查。你的 agent 一旦變得夠強，就會開始需要更多模型。

帳單與工程工時，也就從這裡開始往上攀升。如果每一步都路由到前沿模型，你會多付不少錢，而且幅度往往不小，畢竟大部分步驟，用輕量模型就綽綽有餘。但如果改成直接串接好幾家服務商，你就得為每一家，扛下一套新的整合：各自的金鑰、各自的 SDK 怪癖、各自的速率限制，以及你無法掌控的政策與速率限制變動。

AgentBox 的設計理念很簡單：讓模型層變成你「呼叫」的基礎設施，而不是你「維護」的程式碼。

這是結構性的問題

當你自己動手接線時，一個多服務商的 agent，大概會長成這樣：三家服務商、三把金鑰、三種故障模式。

# The version you end up maintaining
import anthropic, openai
from some_other_sdk import DeepSeekClient

claude = anthropic.Anthropic(api_key=os.environ["ANTHROPIC_KEY"])
gpt = openai.OpenAI(api_key=os.environ["OPENAI_KEY"])
deepseek = DeepSeekClient(api_key=os.environ["DEEPSEEK_KEY"])

# Each carries its own request shape, its own rate limit,
# its own 429 behavior, its own account that can get restricted.

你每多加一家服務商，就多了一個在高負載下，可能限制你速率的環節，多了一段要對帳的計費關係，也多了一個暴露在你無法掌控的政策與速率限制變動下的風險點。對於流量穩定、面向消費者的 agent 來說，這可能導致那些只是想用你產品的使用者，連不上服務。

AgentBox 怎麼處理

在 AgentBox 上，推論一律透過 GMI Models 進行。你的容器，會在執行期被注入兩個環境變數，但這兩個變數，永遠不會被打包進映像檔裡：

import os
from openai import OpenAI

# Injected by the platform at container start.
client = OpenAI(
    api_key=os.environ["GMI_MAAS_API_KEY"],
    base_url=os.environ["GMI_MAAS_BASE_URL"] + "/v1",
)

從這裡開始，換模型，就只是修改一個字串而已：

# Cheap, fast step
triage = client.chat.completions.create(
    model="deepseek-ai/DeepSeek-V4-Flash",
    messages=[{"role": "user", "content": ticket}],
    stream=True,
)

# Hard reasoning step, same client, same key
answer = client.chat.completions.create(
    model="anthropic/claude-opus-4.8",
    messages=[{"role": "user", "content": context}],
    stream=True,
)

一把金鑰，就能觸及超過 200 種開源與前沿模型，而且全都在同一個網路內運行。Claude、GPT、Llama、DeepSeek、Qwen 等等，都藏在同一個端點後面，於是依成本、延遲，或任務品質做路由，就變成你程式裡的一張路由表，取代了一整疊 SDK。計費也同樣集中：跨所有模型的每一次呼叫，都算在同一個帳號上，讓你每個月，拿到的是一個乾淨的數字，而不是六張要對帳的發票。你得先在註冊精靈的第 2 步，挑選好 agent 會呼叫哪些模型，然後才能在程式中引用它們。

這裡有幾個實作上的小提醒，能替你省下一輪部署周期。長時間的多步驟執行，請使用非同步工作模式：回傳 job_id，再輪詢狀態即可。串流輸出也很有用，能讓部分結果更早呈現出來。而且，由於所有呼叫，都在同一網路內經由 GMI Models 進行，你的餘裕，來自 GMI 的整體容量，而不是某一家外部服務商的速率限制層級。

實際運作起來是什麼樣子

已經採用這種做法的團隊，講的都是同樣三件好處：模型選擇的自由、成本效益，以及一個能自己運轉的模型層。

關於模型選擇，以及實現這種自由所需的工程成本：

「現在我們有了 GMI Cloud 這個解法，讓我們打造這些東西容易得多，不只降低基礎設施成本，也省下工程工時。」Joshua Sum，Morphic 執行長

關於「一個帳號打通多種模型」，能為開發者帶來什麼：

「只要一個 GMI 帳號，像我這樣的開發者與創辦人，就能以低成本、低延遲，取用非常多不同的資源。這個好處，非常明顯。」Steven Enamakel，TinyHumans 執行長

關於在運行中的產品裡，只靠一行改動，就能切換模型這件事：

「支援多種模型對我們非常重要。GMI 讓切換模型變得極其簡單，這對我們的生產力幫助很大。」Chenglin Wei，Topify 技術長

什麼時候該用

如果一個 agent，只呼叫單一模型，而且會一直如此，直接串接就很好用。但只要出現下列任何一種情況，走 AgentBox 路由的理由，就會成立：你想讓簡單步驟，改用更便宜的模型；你在穩定流量下，開始撞到某家服務商的速率限制；你希望有多家服務商，以便在其中一個帳號被限制時，產品仍能繼續服務使用者；又或者，你寧願看一張帳單，也不想對好幾張。走到這一步，模型層就成了你呼叫的基礎設施，讓團隊能專心打造 agent 本身。

試試看

瀏覽模型目錄、部署一個 agent，並用一把金鑰，把它路由到超過 200 種模型。

開始使用 AgentBox：https://www.gmicloud.ai/en/models/agentbox

閱讀文件：https://docs.gmicloud.ai/agentbox-marketplace/overview