上一篇討論了 Semantic Kernel Plugins 的複雜參數支援，今天我們來探討另一個重要議題：在設計 AI Agent 系統時，應該選擇 Single-Agent 還是 Multi-Agent 架構？

當前，AI Agent 系統的設計越來越多樣化，根據不同的業務需求和技術條件，選擇合適的架構對於系統的性能和可維護性非常重要。但卻也因為陷入選擇困難症，往往過度複雜化而忽略需求上的本質，在 AI Agent 的設計上也是如此，然而生成式 AI 的一日數變，提早的架構化反而造成不必要的負擔，還沒享受到 Agent 帶來的好處，反而就被架構給打垮了。

Single-Agent 架構

Single-Agent系統圍繞單一 Agent 負責理解需求、規劃步驟、呼叫工具、產出結果。它的節奏是線性的，所有的任務都由這個 Agent 依序處理，可以很快嘗到 Agent 成果：資料串起來了，流程跑通了，第一個價值點交付了。通常 Single-Agent 是把「複雜度」收斂在一個點上，靠的是精心的 Prompt 設計與一套大全配的工具，讓這個 Agent 可以應付多種情境。而這個 Agent 的智慧程度，決定了整個系統的智慧程度，所以 Single-Agent 的設計重點在於「如何讓這個 Agent 變得更聰明」，而不是「怎麼分工合作」。相對的也帶來了風險，因為決策都集中在一個 Agent 上，容易決策失誤、叫錯工具，不易限制 Agent 的行為範圍，這個 Agent 的失誤就可能導致整個系統的失效。

• 優點：

  • 簡單易實作，快速上手享受 Agent 帶來的價值
  • 通常適合需求單一、流程簡單的應用
  • 簡單需求容易快速迭代調整和優化

• 缺點：

  • 擴展性差，難以應對複雜需求
  • 單點故障風險高
  • 難以專精於特定領域
  • 維護困難，隨著功能增加，Agent 變得臃腫
  • 難以控制 Agent 的行為範圍，容易出錯
  • 無法充分利用多個模型的優勢
  • 難以實現任務的並行處理

Multi-Agent 架構

Multi-Agent系統特徵為多個自主Agent協作或競爭達成共同或個別目標，由多個 AI Agent 協同工作，各自負責不同的任務或領域。把「複雜度」分攤給不同的 Agent 角色進行分工作業，靠的是協作的概念。 每個 Agent 都有明確的職責範圍，專注於自己的任務，這樣的設計讓系統相對具彈性和可擴展性，可以根據需求增加或減少 Agent 的數量，並且可以針對不同的任務選擇最適合的模型和工具。技術上採用多種協調模式。相對的，Multi-Agent 架構的設計和實作會比較複雜，包括指揮者-工作者模式、監督者架構、Workflow 多Agent工作流程，需要考慮 Agent 之間的協作和互動，並且需要有機制來管理和監控這些 Agent 的狀態和行為。

• 優點：

  • 較高的擴展性，可以應付複雜的需求
  • 每個 Agent 聚焦於特定領域，提高產出的品質
  • 可以利用多個模型的優勢，每個 Agent 可以使用最適合的模型，甚至可以混合雲端和本地模型
  • 支援任務的並行處理，以提高效率

• 缺點：

  • 整體系統設計和實作複雜度提高
  • 需要考慮 Agent 之間的協作和互動
  • 需要有機制來管理和監控多個 Agent 的狀態和行為
  • token 使用量可能增加，因為多個 Agent 進行對話和協作
  • 需要更多的開發和維護資源
  • 系統速度上整體的延遲會增加，因為多個 Agent 之間需要進行對話和協作
  • 需要考慮如何有效的協調和管理多個 Agent 的工作

有什麼例子？

以大家比較熟悉的 RAG 系統來說，最小可行的版本通常是 Single-Agent 架構，因為整個系統是由一個 Agent 負責理解使用者的查詢，檢索相關文件，並且生成回答。雖然 RAG 系統中包含了檢索器和生成模型兩個主要組件，但這些組件都是由同一個 Agent 協調運作的，因此整體架構仍然屬於 Single-Agent。

但是當文件量暴增、跨語系、跨不同領域檢索又需要合規審查與引用校對時，Multi-Agent 就有了用武之地，這時候可以考慮 Multi-Agent 架構，將系統拆分為多個專注於不同任務的 Agent。例如，可以有一個專門負責分類文件檢索的 Agent，另一個負責生成回答的 Agent，還有一個負責審查和校對的 Agent。這樣的設計可以提高系統的靈活性和可擴展性，並且可以針對不同的任務選擇最適合的模型和工具。

再舉個例子，假設我們要設計一個客服系統，這個系統需要處理多種不同的查詢，例如訂單查詢、產品資訊、技術支援等。如果使用 Single-Agent 架構，這個 Agent 需要具備處理所有這些查詢的能力，這可能會導致 Agent 變得過於複雜且難以維護。相反地，如果使用 Multi-Agent 架構，可以為每種類型的查詢設計專門的 Agent，例如一個負責訂單查詢的 Agent，一個負責產品資訊的 Agent，還有一個負責技術支援的 Agent。這樣的設計可以讓每個 Agent 專注於自己的任務，提高整體系統的效率和可維護性。

如何判斷需求的複雜度？

在決定使用 Single-Agent 還是 Multi-Agent 架構之前，首先需要評估系統的需求複雜度。以下是一些可以考慮的因素：

1. 任務數量：系統需要處理多少不同類型的任務？如果任務數量較少且相似，Single-Agent 可能足夠；如果任務數量多且差異大，Multi-Agent 可能更合適。
2. 任務複雜度：每個任務的複雜度如何？如果任務相對簡單且易於理解，Single-Agent 可能足夠；如果任務複雜且需要專業知識，Multi-Agent 可能更合適。
3. 協作需求：任務之間是否需要頻繁的協作？如果任務之間的協作需求較低，Single-Agent 可能足夠；如果任務之間需要頻繁的協作，Multi-Agent 可能更合適。
4. 不同模型需求：系統是否需要使用不同的 AI 模型來處理不同的任務？如果是，Multi-Agent 可能更合適，因為每個 Agent 可以使用最適合其任務的模型。

結論

在設計 AI Agent 系統時，選擇 Single-Agent 還是 Multi-Agent 架構並沒有絕對的標準，Single-Agent，像是把一把好用的瑞士刀磨到利；選 Multi-Agent，像是打造一個分工明確的工作團隊，關鍵在於根據具體的業務需求和技術條件做出合理的選擇。通常，從 Single-Agent 開始，打通價值場景，證明導入 AI Agent 的效益，隨著需求的增長和複雜度的提升，再逐步過渡到 Multi-Agent 會是一個不錯的策略。