LLM 系統降本九成，但不動搖品質：編排與執行分層的 Subagent 架構實踐
想在不犧牲品質的前提下，大幅降低 LLM 系統的營運成本嗎？本文將揭露一個實戰案例，教你如何運用「編排與執行分層」的 Subagent 架構，讓昂貴的頂級模型專注於決策，而將實際執行交由更經濟的本地模型。這種聰明的策略，不僅能將成本降低超過 90%，更能為你的 AI 應用找到永續發展的關鍵解方。
大型語言模型（LLM）的成本是建構 AI 系統時最棘手的限制之一。我們都希望利用 Claude 3 Opus 或 GPT-4 這類頂級模型的強大推理能力，但其高昂的 API 費用，尤其在自動化或批次處理場景下，很容易失控。一個務實的解方是採用「編排與執行分離」的架構，讓昂貴的頂級模型專注於高層次的規劃與指揮（編排），而將定義明確的具體任務（執行）交由更小、更便宜甚至本地部署的模型處理。這種分工模式不僅能維持系統的整體品質，更能將營運成本降低超過 90%，是實現可持續、可規模化 AI 應用的關鍵策略。
為什麼「分層」是解方？編排與執行的分工邏輯
在許多 AI 應用中，一個複雜的任務通常可以被拆解成多個子任務。例如，一個「分析用戶回饋並生成報告」的系統，可能包含讀取數據、分類情緒、提取關鍵字、總結各類別要點、生成圖表數據，最後撰寫成一份完整的報告等步驟。在這些環節中，並非所有都必須仰賴頂級模型的智慧。
這就是「編排層（Orchestration Layer）」與「執行層（Execution Layer）」分工概念的價值所在。我們可以將其類比為一個由專案經理與專業團隊組成的組織：
- 編排層（專案經理）：由像 Claude 3 Opus 這樣的高階模型擔任。它的核心職責是理解總體目標、拆解任務、分配工作，並在最後整合成果、進行品質把關。它負責「思考」與「決策」，決定「做什麼」以及「誰來做」。
- 執行層（專業團隊）：由多個更小、更專業或成本更低的「Subagent」組成。這些 Subagent 可以是更便宜的 API 模型，甚至是透過 LM Studio 或 Ollama 在本地運行的開源模型。它們接收來自編排層的明確指令，專注於完成特定任務，例如格式轉換、代碼生成、或根據模板進行翻譯。
這種模式的優雅之處在於，我們將最昂貴的資源——頂級模型的推理能力——用在刀口上。它不再需要親自處理每一件瑣碎的執行細節，而是轉變為一個高效的指揮官。這種架構與微軟提出的 AutoGen 框架中多代理協作（Multi-agent Conversation）的精神不謀而合，透過角色分工與協作來解決複雜問題。
如何實作一個高效率的 Subagent 系統？
理論很吸引人，但實務上如何操作？一個日本開發者的具體案例為我們提供了清晰的藍圖。他原先的夜間批次處理系統完全依賴 Claude 3 Opus，每次運行的成本約為 3.60 美元，換算下來每月高達 108 美元。這對於一個需要持續運行的自動化系統來說，是一筆不小的開銷。
他的改進策略非常直接：保留 Opus 作為總指揮官（Orchestrator），但將所有可以標準化的執行任務，透過 LM Studio 轉交給本地運行的模型處理。結果極為顯著：單次運行成本從 3.60 美元驟降至 0.12 美元，降幅高達 97%，每月成本也因此壓縮到僅 3.60 美元。系統的核心邏輯與產出品質幾乎沒有受到影響，但成本效益卻實現了指數級的提升。
這個案例的關鍵不在於完全拋棄昂貴的模型，而是將它們的價值最大化，讓其專注於無法被輕易取代的複雜推理與規劃，而非可被標準化的勞力工作。
要實現這樣的系統，路由（Routing）設計是核心。編排層需要能夠判斷一個子任務的性質，並將其分派給最適合的執行者。一個簡單的路由規則判斷可能如下：
| 任務類型 | 建議執行者 | 理由 |
|---|---|---|
| 高層次目標拆解、策略規劃 | Claude 3 Opus / GPT-4 | 需要強大的邏輯推理與世界知識 |
| 根據明確規格生成程式碼 | 本地 Code Llama / DeepSeek Coder | 任務明確，開源模型已足夠勝任 |
| JSON 格式化、數據清洗 | 本地 Mistral 7B / Claude 3 Haiku | 結構化任務，對模型要求低，速度快 |
| 最終報告整合與品質審核 | Claude 3 Opus / GPT-4 | 需要全局視野與對細微差別的判斷力 |
這種混合模型（Mixture-of-Models）或稱混合專家（Mixture-of-Experts, MoE）的系統設計理念，正從模型底層架構（如 Mixtral 8x7B）擴展到應用層的架構設計中，成為建構高效能、高效率 AI 系統的主流範式。
成本與品質的權衡：哪些任務可以放心交出去？
當然，將任務下放給能力較弱的模型，必然存在品質下降的風險。因此，界定哪些任務可以安全地「外包」出去，是整個架構設計的關鍵。一般而言，符合以下特性的任務是較好的候選者：
- 輸入輸出明確（Well-defined I/O）：任務的指令清晰、格式固定，幾乎沒有模糊的詮釋空間。例如「將這段文字翻譯成英文並以 JSON 格式回傳」。
- 容錯率較高（High Fault Tolerance）：即使執行結果有微小瑕疵，也不會對系統的最終產出造成災難性影響，或者可以輕易地被後續步驟修正。
- 可被驗證（Verifiable）：執行結果可以透過自動化程序（如單元測試、格式檢查）進行快速驗證。例如，生成的程式碼可以立即被編譯或測試。
反之，需要複雜情境理解、多步驟推理、創意發想或對用戶意圖進行深度揣摩的任務，則應繼續保留在編排層，由最強大的模型處理。同時，讓編排層模型負責對所有 Subagent 的產出進行最終的審查與整合，是確保系統總體品質的最後一道，也是最重要的一道防線。這就像一位優秀的總編輯，即使稿件由不同記者撰寫，他依然會對最終的風格、事實和品質進行統一把關。
隨著開源模型的能力快速追趕，以及 NVIDIA NIM 這類推論微服務的成熟，在本地或私有雲中部署高效的執行層模型將變得越來越容易。對 AI 系統建構者而言，與其執著於尋找單一的「萬能模型」，不如轉向設計一個分工合理、協作高效的「模型團隊」。這不僅是成本考量，更是未來複雜 AI 系統架構演進的必然方向。
延伸閱讀
- "AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation" - Microsoft Research 關於多代理框架的原始論文。
- "Build a multi-agent LLM application using the agent framework LangGraph on Amazon Sagemaker Studio" - AWS 關於建構多代理應用的技術部落格。
- "Mixture of Experts Explained" - Hugging Face 對 MoE 模型架構的深入解釋。
我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。