多 Agent 系統

多 Agent 系統會將一項任務分配給多個 Agent，而非要求一個 Agent 包辦所有工作。在 Mastra 中，這通常是指結合 Agent、Workflow，或同時使用兩者，讓系統的每個部分都有清晰的角色。

目標是把合適的上下文、Tool 和責任分配給合適的元件。只要分工清晰，與背負冗長 prompt、過多 Tool 或責任的單一 Agent 相比，多 Agent 系統可能更容易理解。

何時使用多 Agent 系統
何時使用多 Agent 系統的直接連結

當單一 Agent 已不再適合作為工作邊界時，便應使用多 Agent 系統。

常見情況包括：

可以的話，先從一個 Agent 開始。當新增的結構能明顯改善品質、速度或可靠性時，才加入更多 Agent。

當系統需要以清晰方式在各元件之間分配上下文、決策和責任時，多 Agent 模式便很有用。實際上，關鍵的設計問題是：隨着任務推進，哪個元件會繼續掌握控制權。

交接模式會將控制權由一個 Agent 轉交另一個 Agent。與監督者模式不同，第一個 Agent 不會在整項任務中一直掌握控制權，而是由目前負責的專家接管互動的下一部分。

當下一位專家應直接繼續互動，而非透過中央協調者匯報時，請使用交接模式。其取捨是上下文管理會變得更重要，因為系統必須決定下一個 Agent 會繼承甚麼，以及哪些內容仍限定在原有範圍內。

在 Mastra 中，可結合 Agent、Workflow 和記憶實作此模式。Workflow 可以為任務進行路由，但此模式的關鍵特徵是任務擁有權會移交給下一個 Agent。

Workflow 模式會在程式碼中定義執行路徑。你不會要求 Agent 決定下一步，而是透過步驟、分支、迴圈和並行區塊定義執行次序。

當你充分了解任務，而且預先知道執行路徑時，請使用 Workflow。其主要優點是可預測：明確的結構令系統更容易除錯和審計。取捨則是靈活性較低，因為當任務在執行過程中出現變化時，Workflow 的適應能力較弱。

在 Mastra 中，Workflow 可以實作交接和議會等協調模式。Workflow 的不同之處在於，不論它呼叫哪些 Agent，其控制邏輯都位於 Workflow 本身。

監督者模式會讓一個主導 Agent 在整項任務中一直掌握控制權。監督者會決定何時委派工作、呼叫哪位專家、傳遞哪些上下文，以及如何整合結果。

當任務較開放，而且無法預先得知完整執行次序時，請使用此模式。例如，研究任務可能需要根據較早步驟的發現，採取不同的探究方向。監督者可以隨着任務推進作出調整。其取捨是監督者會成為主要協調點。這令模式更靈活，但亦表示結果高度取決於良好的委派方式和清晰的子 Agent 邊界。

在 Mastra 中，此模式直接對應至監督者 Agent。監督者 Agent 會在 agents 屬性中定義子 Agent，並使用 stream() 或 generate() 協調它們。Mastra 亦提供委派 hook、訊息篩選和記憶隔離功能，協助控制此模式。

提示

請參閱監督者 Agent 教學，按照逐步指南實作。

議會模式會要求多個 Agent 各自獨立處理同一問題，然後比較或整合它們的輸出，得出一個最終答案。監督者會將問題拆分成多個部分；議會則讓所有 Agent 處理同一問題，並為同一問題帶來多個觀點。

當問題含糊、需要評估或涉及高風險，而且答案品質比速度更重要時，請使用此模式。其取捨是成本較高，因為議會會刻意重複工作，通常比其他模式需時更長，亦會使用更多 token。

Mastra 並無提供專用的議會原語。在 Mastra 中，可使用 Agent 和 Workflow 實作此模式：並行執行多個 Agent 並收集它們的輸出，然後加入最終整合或審閱步驟。.parallel() 等 Workflow 控制流程方法可為此模式提供所需結構。

這些模式的主要分別在於它們如何分配控制權：

模式	誰掌握控制權	適用情況	取捨	Mastra 實作方式
交接	目前負責的專家	擁有權應在專家之間移交	上下文轉移變得更重要	Agent 配合 Workflow 和記憶
Workflow	執行圖	預先知道執行路徑	任務出現變化時適應能力較弱	Workflow
監督者 Agent	一個主導 Agent	委派工作必須在執行期間作出調整	結果取決於良好的協調和清晰的邊界	監督者 Agent
議會	最終整合步驟	任務需要多個獨立觀點	成本和延遲較高	Agent 配合 Workflow 並行處理

實際上，這些模式經常會互相結合：

應按協調問題而非任務標籤選擇模式。