Multi-Agent LLM API 系統：2026 年的架構與程式碼

單 Agent 架構會撞上天花板。你的寫程式 Agent 能寫——但無法審查自己的輸出。你的帳務 Agent 能解決——但無法跟出貨部門溝通。同一種視角、同樣的盲點。

你不斷加上更多工具。延遲暴增。脈絡視窗溢位。這個天花板是結構性的，不是靠加深提示詞就能突破。

解法：專業化 Agent——收窄專業範圍、並行執行、定義好協定。

讀完你會獲得三種編排模式（Supervisor-Worker、Peer-to-Peer、Hierarchical）的 Python 程式碼、能砍掉 50–70% 成本的角色對模型對應、以及把平坦的 span 列表變成系統地圖的 trace 拓撲。

單 Agent 何時會破功？

複雜度天花板

單 Agent 會以可預測的方式在四種情境下失敗：

跨領域專業。 一個 Agent 被要求同時當寫碼專家、法務審查員和財務分析師。提示詞膨脹——系統提示詞必須大到裝下三個領域。角色混淆——模型把語氣和優先順序攪在一起。用隨便的工程術語寫出來的法律審查意見。因為「寫碼專家」的人設主導、而跳過合規檢查的財務分析。

並行執行。 三個本可同時進行的獨立子任務——研究競品定價、分析使用者評論、彙整產品規格——被單一 Agent 依序處理。總延遲是三者的總和。改用三個專業 Agent 並行執行，延遲就是三者的最大值。

自我批判。 單一 Agent 產生輸出，又自己評估自己的輸出。製造出答案的同一個認知過程，被要求找出自己的缺點。它做不到。同儕審查——一個有不同提示詞、不同模型、不同視角的獨立 Agent——能抓出產生輸出那個 Agent 看不見的錯誤。

工具數量爆炸。 十五個工具沒問題。二十五個工具時，模型的工具選取準確度就會明顯下降——更常選錯工具、漏掉正確的工具、或依錯誤順序呼叫工具。各帶 5–8 個工具的專業 Agent，勝過一個帶 25 個工具的通用型 Agent。

Multi-Agent 不一定是答案

Multi-Agent 系統會帶來實實在在的負擔：Agent 間通訊延遲、Agent 之間訊息產生的 token 成本、兩個 Agent 給出互相矛盾的答案時的一致性風險、以及你無法判斷 5-Agent 鏈中是哪個 Agent 產生錯誤輸出時的除錯困難。如果你的任務用一個提示詞寫得好的 Agent、配上 5–10 個範圍清楚的工具就能處理，就別引入 Multi-Agent 的複雜度。先從單一開始。只有當單一明確失敗時——工具混淆、角色不一致、或並行執行能消除的序列延遲——才改用 Multi。

我們的單 Agent 架構指南涵蓋了基礎。這篇文章假設你已經把單 Agent 設計推到極限、現在正撞上天花板。

三種編排模式

模式 1：Supervisor-Worker

一個 supervisor Agent 負責編排。它分解任務、把子任務分派給 worker、彙整結果、在回傳輸出前跑一道品質閘門。Worker 是專業化的——各自有自己的系統提示詞、工具集和模型。Worker 之間不互相溝通。它們只跟 supervisor 對話。

class SupervisorAgent:
    def __init__(self, model: str, workers: list[WorkerAgent]):
        self.model = model
        self.workers = {w.name: w for w in workers}

    async def execute(self, task: str) -> dict:
        plan = await self._decompose(task)
        results = {}
        for subtask in plan["subtasks"]:
            worker = self.workers[subtask["assigned_to"]]
            results[subtask["id"]] = await worker.execute(subtask)

        synthesis = await self._synthesize(task, results)
        quality = await self._quality_gate(synthesis)

        if quality["passed"]:
            return synthesis
        else:
            return await self._retry_or_escalate(task, quality["issues"])

最適合： 能乾淨地分解成獨立子任務、需要集中式品質管控、且有相對固定團隊結構的任務。取捨： supervisor 會成為瓶頸和單一故障點。不適合 worker 之間需要動態協商的場景。

模式 2：Peer-to-Peer

沒有階層。所有 Agent 都是對等的。任何 Agent 都能透過共享訊息匯流排，跟其他任何 Agent 發起通訊。Agent 彼此探索能力、動態協商任務交接。

class PeerAgent:
    def __init__(self, name: str, role: str, model: str, message_bus: MessageBus):
        self.name = name
        self.role = role
        self.model = model
        self.bus = message_bus
        self.bus.subscribe(self.name, self._handle_message)

    async def _handle_message(self, msg: Message):
        if msg.type == "request":
            result = await self._execute_task(msg.content)
            await self.bus.send(Message(
                to=msg.from_agent,
                type="response",
                content=result,
                correlation_id=msg.correlation_id
            ))

最適合： 動態協商——程式碼審查 Agent 發現 bug，直接把修正訊息傳給寫碼 Agent，迴圈裡沒有 supervisor。沒有瓶頸。工作流程彈性。取捨： 除錯更難——對話圖可能變複雜，對等節點之間的無限訊息迴圈或矛盾輸出，需要明確的迴圈偵測和衝突解決機制。

模式 3：Hierarchical

多層級升級。第一線 Agent 處理例行案件。複雜或異常的案件升級給資深 Agent。最棘手的案件抵達主責 Agent 或人類。模型品質與成本隨層級遞增——Tier 1 用便宜模型、Tier 2 用中階、Tier 3 用旗艦。

class TieredAgentSystem:
    def __init__(self, tiers: list[AgentTier]):
        self.tiers = sorted(tiers, key=lambda t: t.level)

    async def execute(self, task: str) -> dict:
        for tier in self.tiers:
            result = await tier.agent.execute(task)
            if result["confidence"] >= tier.confidence_threshold:
                return result
        return await self._escalate_to_human(task)

最適合： 有天然複雜度層級的支持工作流程、自動過濾——資深審查——人工升級的內容審核、以及大多數請求簡單、少數需要深度專業知識的任何領域。取捨： 升級邏輯需要用生產資料調校——你需要回饋迴圈，為每一層校準 confidence threshold。

Agent 通訊協定

把 Function Calling 當成 Agent 間協定

最簡單的做法：Agent A 呼叫 send_message_to_agent_b 工具。這個工具定義在 Agent A 的 function calling schema 裡。相容於現有基礎設施。零新協定要學。限制：同步阻塞。每則訊息都是一次完整的工具呼叫往返。在多輪 Agent 對話中，延遲線性累積。當工具定義本身要橫跨多個 schema 不一致的供應商時，我們的function calling 與工具使用指南涵蓋了讓 Agent 間工具呼叫能在不同模型間移植的標準化層。

用 MCP 做 Agent 通訊

每個 Agent 把自己的能力以 MCP server 的形式暴露出來。其他 Agent 以 MCP client 的角色探索並呼叫這些能力。我們的MCP 指南涵蓋了協定的基礎。在 Multi-Agent 系統中，MCP 提供標準化的能力探索——Agent 不需要事先知道其他 Agent 能做什麼。它查詢 MCP 生態系、動態探索能力。

Google A2A

專為 Agent 對 Agent 通訊而打造（A2A 規格）。用 Agent Cards 做能力探索。結構化的 Task 生命週期：submitted——working——completed 或 failed。任務執行期間的串流更新。多模態內容交換。跨框架——用不同框架建出來的 Agent，只要會講 A2A 就能互通。最適合不同團隊用不同技術棧的異質 Multi-Agent 系統。

自訂訊息匯流排

用帶結構化訊息 schema 的 Redis Pub/Sub 或 NATS。對路由、持久化、重試和可觀測性的掌控最大。實作心力也最大。Schema：{agent_id, correlation_id, message_type, payload, timestamp}。當你的 Agent 間通訊模式獨特到沒有任何標準協定適用——或你需要高階協定無法提供的保證（exactly-once 送達、有序送達）時，選這個。

角色對模型對應

Multi-Agent 系統最大的成本陷阱：每個 Agent 都用旗艦模型。你的 classifier Agent 只是在「帳務」和「技術支援」之間分流，並不需要輸入 token 每 M $15 的 Claude Opus。它需要的是每 M $0.15 的 GPT-4o Mini——而且分類準確度完全相同。

Agent 角色	建議模型	每 1M 輸入成本	理由
Classifier/Router	DeepSeek V3.2 / GPT-4o Mini	$0.14-0.15	簡單分類。便宜模型跟旗艦模型表現相同。
Basic Q&A / FAQ	GPT-4o Mini / Claude Haiku	$0.15-0.25	檢索增強的事實性回應。中階能力、最低價定價。
Content Generation	GPT-4o / Claude Sonnet 4	$2.50-3.00	語氣、結構、創意都重要。值得花中階的溢價。
Code Generation	Claude Sonnet 4 / DeepSeek V4 Pro	$0.42-3.00	SWE-bench 資料驅動這個選擇。DeepSeek 每一美元的寫碼表現非常出色。
Code Review / Quality Gate	Claude Opus 4 / GPT-5.5	$10-15.00	找 bug 需要旗艦級推理。漏掉一個 bug 的成本，超過模型的溢價。
Final Synthesis	Claude Opus 4	$15.00	這是使用者會看到的輸出。為語氣、準確度與指令遵循付出的溢價很值得。

每個 Agent 的成本追蹤——在每個 LLM span 上記 gen_ai.cost.total、把 agent_id 當成 span 屬性——就能得到每 Agent 的成本報告。你會很快發現吃掉 Multi-Agent 預算 40% 的那個 Agent。把它從 Opus 降級到 Sonnet，看輸出品質是否真的改變。通常不會。除了逐 Agent 選模型之外，我們的12 種 LLM API 成本最佳化指南涵蓋了 prompt caching、批次處理、以及能在你整個 Agent 機隊中產生複合效果的語意快取模式。

除錯與監控 Multi-Agent 系統

Trace 拓撲問題

一個使用者請求可以觸發：Agent A（分類）——Agent B（研究）＋Agent C（程式碼）並行——Agent A（合成）——六次 LLM 呼叫、十次工具呼叫、三則 Agent 間訊息。一條 19 筆的平坦 span 列表根本無法除錯。你看不到執行圖。

解法：用帶階層建模的 OpenInference AGENT span kind。根 span：使用者工作階段。第 1 層：編排者決策。第 2 層：逐 Agent 執行。第 3 層：逐 Agent 的工具呼叫。你的 trace 檢視器畫出的是執行圖，不是平坦列表。當 Agent C 的工具呼叫失敗時，你能在脈絡中看到它——是哪個 Agent、哪一步、前後發生什麼。

完整的 OpenTelemetry 設定請見我們的可觀測性指南。

常見的 Multi-Agent 故障模式

無限訊息迴圈。 Agent A——Agent B——Agent A——Agent B。防範：在訊息匯流排層級設對話深度上限與迴圈偵測。在 API 層，逐 Agent 速率限制加上一層預算天花板——當 Agent 超過請求配額，無論訊息匯流排邏輯允許什麼，迴圈都會停下來。

矛盾輸出。 Agent A 說該退費。Agent B 說不該退費。沒有任何解決機制。防範：用帶明確衝突解決的 supervisor 模式，或跨 Agent 的投票機制。

工具權限外洩。 寫碼 Agent 因為工具登錄檔設定錯誤，意外拿到帳務 Agent 的退費工具。防範：逐 Agent 的工具許可清單。每個工具稽核軌跡都記上 Agent 身分。

靜默 Agent 故障。 某個 Agent 丟出未處理的錯誤。編排者沒發現。使用者收到一份缺少關鍵資訊的部分回應。防範：在 Agent 間協定中做結構化錯誤回報。合成之前先做編排者層級的健全性檢查。

常見問題

什麼時候不該用 Multi-Agent 架構？

如果一個提示詞寫得好、帶 10 個以內定義清楚的工具的單 Agent 就能處理你的任務，就別引入 Multi-Agent 的複雜度。通訊負擔、除錯難度、以及 Agent 間訊息的成本，超過了它的好處。先單 Agent。只有當單 Agent 明確失敗時——工具混淆、角色不一致、或並行執行能解決的序列延遲——才用 Multi-Agent。

系統該從幾個 Agent 開始？

兩到三個，涵蓋彼此清楚不同的角色。不要從六個開始。協調複雜度是非線性成長的——6-Agent 系統不是 2-Agent 系統的 3 倍難。它比較接近 9 倍。只有在既有 Agent 在某個需要獨立專業知識的特定子任務上持續失敗時，才新增 Agent。

該從哪種編排模式開始？

Supervisor-Worker。集中式控制、清楚的狀態管理、最簡單的除錯。只有當 worker 真的需要彼此動態協商時，才升級到 Peer-to-Peer。只有當你有帶可衡量 confidence threshold 的清楚複雜度層級時，才升級到 Hierarchical。從簡單開始。只有當資料證明你需要時，才加入複雜度。

怎麼處理一個一直犯錯的 Agent？

不要從調整它的提示詞開始。第一步：trace 分析。找出失敗模式——哪些輸入觸發錯誤？它的執行在哪一步出錯？第二步：收窄這個 Agent 的範圍。它可能處理太多種任務類型了。第三步：加一個品質閘門 Agent——在使用者看到輸出之前先檢查的審查者。第四步：如果這個 Agent 缺領域知識，加 RAG——不是 fine-tuning，也不是更多提示詞。

跑在 3 層模型上的 5-Agent 系統，實際營運成本是多少？

營運成本不在 token——在於碎片化。每一層 Agent 都可能打不同的供應商。這意味著各自的 API key、各自的速率限制追蹤、各自的成本儀表板。當你的 classifier Agent（每 M $0.14 的 DeepSeek Flash）和你的程式碼審查者（每 M $15 的 Claude Opus）走不同供應商時，你花在管理憑證上的時間比最佳化 Agent 行為還多。解法是架構性的：不管什麼模型，所有 Agent 共用一個端點。逐 Agent 成本歸屬變成 span 屬性，而不是在跨供應商試算表之間對帳的工作。要讓這個單一端點做法達到可上生產的程度所需的可觀測性和延遲調校，TokSpan 的生產最佳化指南涵蓋了你整個 Agent 機隊的連線池、請求佇列和逐模型逾時設定。

Multi-Agent 架構不是比較高明——它是對特定故障模式的回應。當你的單 Agent 在跨領域時混淆工具、當序列執行讓延遲無法接受、當自我審查抓不到自己的錯誤——那些才是訊號。在那之前都不是。

從 Supervisor-Worker 開始。毫不留情地把角色對應到模型——你的 classifier 不需要 Opus。替每個 Agent 的 span 加上 agent_id 計測。盯一週的逐 Agent 成本報告。你會發現至少有一個 Agent 模型過度配置，可以降一階、且品質完全不受影響。

編排模式的重要性，比不上「知道什麼時候不要再加一個 Agent」這個紀律。

你的 Agent 機隊成本報告，不該需要把四個不同供應商儀表板的 CSV 匯出拼在一起。把你的 Agent 部署到 TokSpan——逐 Agent 成本歸屬、集中化的速率限制、以及你的 Agent 需要的所有模型，都收在一個端點後面。