Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

選擇代理式 AI 系統的設計模式

Last reviewed 2026-05-28 UTC

本文將提供指引，協助您為代理式 AI 系統選擇設計模式。代理設計模式是建構具備代理功能的應用程式時，常見的架構方法。代理設計模式提供獨特的架構，可整理系統元件、整合模型，以及調度單一或多個代理來完成工作流程。

AI 代理適合用於解決開放式問題的應用程式，這類問題可能需要自主決策和管理複雜的多步驟工作流程。代理擅長使用外部資料即時解決問題，並自動執行需要大量知識的工作。如果需要 AI 自主完成以目標為導向的工作，AI 代理就是合適的選擇。如要用於其他用途，可以使用輔助和生成式 AI 應用程式。如要瞭解 AI 代理與非代理 AI 應用程式的差異，請參閱「AI 代理、AI 助理和機器人有何不同？」一文。

本指南假設您具備代理式 AI 系統的基本知識，並瞭解這類系統的架構與非代理式系統 (例如使用直接模型推論或檢索增強生成 (RAG) 的系統) 的差異。

如需代理程式模式指南的摘要，請參閱本文件稍後的「比較設計模式」一節。

設計程序總覽

以下是選擇代理式 AI 系統設計模式的概略步驟。本文稍後會詳細說明這些步驟。

定義需求：評估工作負載的特性，包括工作複雜度、延遲和效能期望、成本預算，以及是否需要人工介入。
查看常見的代理設計模式：本指南將介紹常見的設計模式，包括單一代理系統和多代理系統。
選取模式：根據工作負載特性選取適當的設計模式。

這項程序並非一次性決定，隨著工作負載特性改變、需求演進，或推出新 Google Cloud 功能，您應定期重新檢視這些步驟，以改善架構。

定義需求

以下問題並非規劃時的完整檢查清單，請先回答這些問題，找出代理式系統的主要目標，然後選擇最合適的設計模式。

工作特性：工作是否能在預先定義的工作流程步驟中完成，還是沒有明確的終點？您的工作是否需要使用 AI 模型來協調工作流程？
延遲和效能：您是否需要優先提供快速或互動式回應，但準確度或回應品質會因此降低？或者，您的應用程式是否能容許延遲，以取得更準確或詳盡的結果？
費用：您對推論費用的預算為何？是否支援需要多次呼叫模型才能完成單一要求的模式？
人工參與：您的工作是否涉及重大決策、安全關鍵作業或需要人工判斷的主觀核准？

如果工作負載可預測或高度結構化，或是可透過單一呼叫 AI 模型執行，探索非代理程式解決方案來處理工作，可能更具成本效益。舉例來說，如果只是要摘要文件、翻譯文字或分類客戶意見回饋，可能不需要代理工作流程。如要瞭解如何為不需要代理式基礎架構的生成式 AI 應用程式選擇架構元件，請參閱「為生成式 AI 應用程式選擇模型和基礎架構」。

以下各節說明常見的代理程式設計模式，可協助您建構可靠且有效的代理式 AI 系統。

單一代理系統

單一代理系統會使用 AI 模型、一組定義的工具和完整的系統提示，自主處理使用者要求或完成特定工作。在這個基本模式中，代理會依據模型的推理能力解讀使用者要求、規劃一系列步驟，並從定義的工具集中決定要使用哪些工具。系統提示會定義代理的核心任務、角色和作業，以及使用各項工具的具體條件，藉此塑造代理的行為。

下圖顯示單一代理程式模式的高階檢視畫面：

單一代理設計模式的架構。

單一代理程式系統非常適合需要多個步驟和存取外部資料的任務。舉例來說，客服專員必須查詢資料庫才能找出訂單狀態，研究助理則需要呼叫 API 才能彙整近期新聞。非代理式系統無法執行這些工作，因為無法自主使用工具或執行多步驟計畫，以綜合出最終答案。

如果您剛開始開發代理程式，建議先從單一代理程式著手。使用單一代理系統開始開發代理時，您可以專注於改善代理的核心邏輯、提示和工具定義，再新增更複雜的架構元件。

如果單一代理使用的工具較多，且任務複雜度提高，成效可能會降低。您可能會發現延遲時間變長、工具選取或使用錯誤，或是無法完成工作。您通常可以運用「推論與行動 (ReAct) 模式」等技術，改善代理程式的推論過程，進而減輕這些問題。不過，如果工作流程需要代理管理多項不同的責任，這些技巧可能就不夠用。在這些情況下，建議使用多代理系統，將特定技能委派給專業代理，藉此提升韌性和效能。

多代理系統

多代理系統會協調多個專用代理，解決單一代理無法輕易處理的複雜問題。核心原則是將大型目標分解為較小的子工作，並將每個子工作指派給具備特定技能的專屬代理。這些代理程式會透過協作或階層式工作流程互動，以達成最終目標。相較於使用單一代理程式和單體式提示，多代理程式模式提供模組化設計，可提升整體系統的擴充性、可靠性和可維護性。

在多代理系統中，每個代理都需要特定脈絡，才能有效執行工作。背景資訊可包括文件、歷來偏好設定、相關連結、對話記錄或任何作業限制。管理這類資訊流的程序稱為「脈絡工程」。脈絡工程包含多種策略，例如為特定代理程式隔離脈絡、在多個步驟中保留資訊，或是壓縮大量資料以提升效率。

與單一代理系統相比，建構多代理系統時需要額外評估、考量安全性、可靠性和成本。舉例來說，多代理系統必須為每個專業代理實作精確的存取控管機制、設計穩健的自動調度管理系統，確保代理之間的通訊可靠無虞，並管理因執行多個代理而增加的運算負荷，進而控管營運成本。如需建構多代理系統的參考架構範例，請參閱多代理 AI 系統 Google Cloud。

依序模式

多代理依序模式會以預先定義的線性順序執行一系列專用代理，其中一個代理的輸出內容會直接做為下一個代理的輸入內容。這個模式使用循序工作流程代理，根據預先定義的邏輯運作，不必諮詢 AI 模型來自動調度管理子代理。

下圖顯示多代理程式循序模式的高階檢視畫面：

多代理循序設計模式的架構。

對於高度結構化、可重複執行的程序，請使用循序模式，因為這類程序的作業順序不會改變。舉例來說，資料處理管道可能會使用這個模式，先讓資料擷取代理程式提取原始資料，然後將該資料傳遞給資料清理代理程式進行格式化，接著再將清理後的資料傳遞給資料載入代理程式，以便儲存在資料庫中。

相較於使用 AI 模型來協調工作流程的模式，循序模式可縮短延遲時間並降低營運成本。不過，這種效率是以彈性為代價。管道的結構僵硬且預先定義，因此難以適應動態條件或略過不必要的步驟，如果不需要的步驟速度緩慢，可能會導致處理效率不彰或累積延遲時間較長。

平行模式

多代理平行模式又稱並行模式，是指多個專業子代理同時獨立執行工作或子工作。接著，系統會綜合子代理的輸出內容，產生最終的整合回應。與循序模式類似，平行模式會使用平行工作流程代理，管理其他代理的執行方式和時機，不必諮詢 AI 模型來自動調度管理子代理。

下圖顯示多重代理程式平行模式的高階檢視畫面：

多代理平行設計模式的架構。

如果子工作可以並行執行，請使用平行模式，以減少延遲或收集各種觀點，例如從不同來源收集資料，或同時評估多個選項。舉例來說，如要分析顧客意見回饋，平行代理可能會同時將單一意見回饋項目分送給四個專門代理：情緒分析代理、關鍵字擷取代理、分類代理和緊急程度偵測代理。最終代理程式會將這四項輸出內容彙整成一份綜合分析報告，深入瞭解該意見回饋。

相較於循序方法，平行模式可同時從多個來源收集各種資訊，因此能縮短整體延遲時間。不過，這種做法會導致成本和複雜度有所取捨。並行執行多個代理程式會立即增加資源用量和詞元用量，導致營運成本提高。此外，收集步驟需要複雜的邏輯來綜合可能衝突的結果，這會增加系統的開發和維護負擔。

迴圈模式

多代理迴圈代理模式會反覆執行一系列的專業子代理，直到符合特定終止條件為止。這個模式使用迴圈工作流程代理，與其他工作流程代理一樣，會根據預先定義的邏輯運作，不會諮詢 AI 模型來進行自動化調度管理。所有子代理完成工作後，迴圈代理會評估是否符合結束條件。條件可以是疊代次數上限或自訂狀態。如果未符合結束條件，迴圈代理程式會再次啟動子代理程式序列。您可以導入迴圈模式，在流程中的任何時間點評估結束條件。如果工作需要反覆修正或自我修正，請使用迴圈模式，例如生成內容，並讓評論家代理程式審查內容，直到符合品質標準為止。

下圖顯示多代理程式迴圈模式的高階檢視畫面：

多代理迴圈設計模式的架構。

迴圈代理程式模式可讓您建構複雜的反覆工作流程。這項功能可讓代理程式自行調整工作，並持續處理，直到達到特定品質或狀態為止。不過，這種模式的主要缺點是可能發生無限迴圈。如果終止條件定義不正確，或子代理程式無法產生停止迴圈所需的狀態，迴圈可能會無限期執行。這可能會導致營運成本過高、資源耗用量過大，以及系統可能停止回應。

檢查及評論模式

多代理審查和評論模式 (又稱生成器和評論模式) 通常會使用兩個專門的代理程式，以循序工作流程運作，藉此提升生成內容的品質和可靠性。審查和評論模式是迴圈代理模式的實作方式。

在審查和評論模式中，生成器代理程式會建立初始輸出內容，例如程式碼區塊或文件摘要。接著，評論家代理程式會根據預先定義的一組標準評估這項輸出內容，例如事實準確度、是否遵守格式規則或安全規範。根據評估結果，評論家可以核准內容、拒絕內容，或將內容連同修訂意見回傳給生成器。

下圖顯示多代理程式審查和評論模式的概要：

多代理審查與評論設計模式的架構。

這個模式適合用於需要高度準確的輸出內容，或必須符合嚴格限制，才能向使用者顯示或用於下游程序的作業。舉例來說，在程式碼生成工作流程中，生成器代理程式可能會編寫函式來滿足使用者的要求。然後，這組生成的程式碼會傳遞給充當安全稽核人員的評論家代理程式。評論家代理程式的工作是根據一組限制檢查程式碼，例如掃描安全漏洞或確認程式碼通過所有單元測試，然後核准使用。

審查員和評論模式會新增專屬的驗證步驟，因此可提升輸出內容的品質、準確度和可靠性。不過，這項品質保證的直接代價是延遲時間增加和營運費用提高。工作流程至少需要再呼叫一次模型，才能進行評論家評估。如果程序包含修訂循環，也就是將內容送回以進行修正，則每次疊代都會累積延遲時間和成本。

疊代精修模式會使用迴圈機制，在多個週期內逐步改善輸出內容。反覆修正模式是迴圈代理模式的實作方式。

在這個模式中，一或多個代理會在迴圈中運作，以修改每次疊代期間儲存在工作階段狀態的結果。這個程序會持續執行，直到輸出內容達到預先定義的品質門檻，或達到最大疊代次數為止，避免無限迴圈。

下圖顯示多代理程式反覆改良模式的概略檢視畫面：

多代理反覆修正設計模式的架構。

這個模式適用於複雜的生成工作，因為輸出內容難以透過單一步驟達成。例如撰寫及偵錯程式碼、制定詳細的多部分計畫，或是草擬及修訂長篇文件。舉例來說，在創意寫作工作流程中，代理可能會生成網誌文章草稿、根據流程和語氣評論草稿，然後根據評論重寫草稿。這個程序會重複執行，直到專員的工作達到預先定義的品質標準，或重複次數達到疊代次數上限為止。

反覆修正模式可產生高度複雜或精緻的輸出內容，這類內容很難透過單一步驟完成。不過，迴圈機制會直接增加每個週期的延遲時間和作業成本。此外，這個模式也會增加架構複雜度，因為需要精心設計退出條件 (例如品質評估或疊代次數上限)，才能避免成本過高或執行不受控。

協調員模式

多代理協調工具模式會使用中央代理 (即協調工具) 指導工作流程。協調員會分析使用者的要求並分解為子工作，然後將每個子工作分派給專門的代理程式執行。每個專業代理都是特定功能的專家，例如查詢資料庫或呼叫 API。

協調器模式的特色是使用 AI 模型來協調及動態轉送工作。相較之下，平行模式會依賴硬式編碼的工作流程來調度工作，以便同時執行，不需要 AI 模型自動調度管理。

下圖顯示多代理程式協調器模式的概略檢視畫面：

多代理協調器設計模式的架構。

使用協調器模式，自動執行需要適應性路徑的結構化業務程序。舉例來說，客服專員可以擔任協調員。協調員專員會分析要求，判斷是訂單狀態要求、產品退貨要求還是退款要求。視要求類型而定，協調員會將工作轉送給合適的專責代理。

相較於更嚴格的預先定義工作流程，協調器模式更具彈性。使用模型將工作路徑導向適當的工具，協調器就能處理更多種類的輸入內容，並在執行階段調整工作流程。不過，這種做法也會帶來一些取捨。由於協調器和每個專用代理都會依據模型進行推論，因此與單一代理系統相比，這個模式會產生更多模型呼叫。雖然協調器模式可提升推理品質，但與單一代理程式系統相比，也會增加權杖輸送量、營運成本和整體延遲時間。

階層式工作分解模式

多代理階層式工作分解模式會將代理分組為多層級階層，解決需要大量規劃的複雜問題。階層式工作分解模式是協調器模式的實作方式。頂層父項或根代理程式會收到複雜工作，並負責將工作分解為多個較小的子工作，方便管理。根代理會將各項子工作委派給下層的專業子代理。這個程序可以在多個層級重複執行，代理程式會逐步分解指派的工作，直到最低層級的工作代理程式可以直接執行為止。

下圖顯示多代理程式階層式工作分解模式的概略檢視畫面：

多代理階層式工作分解設計模式的架構。

對於需要多步驟推論的模糊開放式問題，請使用階層式工作分解模式，例如涉及研究、規劃和綜合分析的工作。舉例來說，如要完成複雜的研究專案，協調員代理程式會將高階目標分解為多項工作，例如收集資訊、分析結果，以及統整最終報告。然後，協調代理會將這些工作委派給專用子代理，例如資料收集代理、分析代理和撰寫報告的代理，以執行或進一步分解工作。

階層式工作分解模式非常適合解決高度複雜和模稜兩可的問題，因為這種模式會將問題系統性地分解為可管理的小任務。與較簡單的模式相比，這種模式可產生更全面且品質更高的結果。不過，這項進階功能會帶來重大取捨。多層結構會大幅增加架構複雜度，導致系統設計、偵錯和維護更加困難。多層委派和推論也會導致模型呼叫次數增加，與其他模式相比，整體延遲時間和營運成本都會大幅增加。

Swarm 模式

多代理程式群模式採用協作式全對全通訊方法。在這個模式中，多個專用代理會共同合作，逐步改善複雜問題的解決方案。

下圖顯示多代理程式群模式的大致情況：

多代理群組設計模式的架構。

蜂群模式會使用調度員代理程式，將使用者要求轉送至專用代理程式的協作群組。調度員代理程式會解讀要求，並判斷蜂群中哪個代理程式最適合開始執行工作。在這個模式中，每個代理都能與其他代理通訊，分享發現、評論提案，並根據彼此的工作內容疊代修正解決方案。蜂群中的任何代理都可以將工作交給另一個代理，該代理是蜂群判斷更適合處理下一個步驟的對象，也可以透過協調器代理將最終回應傳達給使用者。

通常，蜂群沒有中央主管或協調代理，無法確保流程順利進行。調度器代理不會自動調度管理代理工作流程，這與協調器模式不同。而是由調度代理程式促進群組子代理程式與使用者之間的通訊。為確保微粒群最終會停止並傳回結果，您必須定義明確的結束條件。這個條件通常是疊代次數上限、時間限制，或是達成特定目標，例如達成共識。

對於模稜兩可或高度複雜的問題，可使用群集模式，透過辯論和反覆修正來解決。舉例來說，設計新產品可能需要市場研究代理、工程代理和財務模型代理。代理會分享初步想法、討論功能和成本之間的取捨，並共同達成最終設計規格，以平衡所有相互衝突的需求。

蜂群模式會模擬專家團隊的協作，因此能產生極為優質的創意解決方案。不過，這是最複雜且成本最高的多代理模式。如果沒有使用 AI 模型來協調的代理程式，可能會導致無效的迴圈，或無法找到解決方案。因此，您必須設計複雜的邏輯，才能管理代理間的複雜通訊、控制疊代工作流程，以及處理與多個代理間動態多輪對話相關的龐大營運成本和延遲。

推論並行動 (ReAct) 模式

ReAct 模式是一種方法，可讓 AI 模型將思考過程和動作架構為一連串的自然語言互動。在這個模式中，代理程式會反覆進行思考、行動和觀察，直到符合結束條件為止。

想法：模型會推論任務內容，並決定下一步該怎麼做。模型會評估收集到的所有資訊，判斷是否已完整回答使用者的要求。
行動：模型會根據思考過程採取下列其中一項行動：
- 如果工作尚未完成，系統會選取工具，然後形成查詢，以收集更多資訊。
- 如果工作完成，就會擬定最終答案並傳送給使用者，結束迴圈。
觀察：模型會收到工具的輸出內容，並將相關資訊儲存在記憶體中。由於模型會儲存相關輸出內容，因此可以根據先前的觀察結果建構內容，避免重複或失去脈絡。

當代理找到明確答案、達到預設的疊代次數上限，或遇到導致無法繼續的錯誤時，疊代迴圈就會終止。透過這個反覆運算的迴圈，代理可以動態建構計畫、收集證據，並在尋找最終答案的過程中調整做法。

下圖顯示 ReAct 模式的概要：

ReAct 設計模式的架構。

對於需要持續規劃和調整的複雜動態工作，請使用 ReAct 模式。舉例來說，假設機器人代理程式必須產生路徑，從初始狀態轉換為目標狀態：

想法：模型會推論從目前狀態轉換至目標狀態的最佳路徑。在思考過程中，模型會針對時間或能源等指標進行最佳化。
動作：模型會沿著計算出的路徑區段移動，執行計畫中的下一個步驟。
觀察：模型會觀察並儲存環境的新狀態。模型會儲存新位置，以及感知到的環境變化。

這個迴圈可讓代理程式根據新觀察結果不斷更新計畫，遵守動態限制，例如避開新障礙物或遵守交通法規。代理會持續執行疊代迴圈，直到達成目標或發生錯誤為止。

相較於複雜的多代理系統，單一 ReAct 代理的實作和維護作業更簡單，成本效益也更高。模型思考過程會提供模型推論過程的轉錄稿，有助於偵錯。不過，這種彈性會帶來取捨。由於迴圈具有反覆運算的多步驟性質，因此與單一查詢相比，端對端延遲時間可能會較長。此外，代理程式的效用高度取決於 AI 模型的推理品質。因此，如果某個觀察步驟中的工具發生錯誤或產生誤導結果，可能會導致最終答案不正確。

人機迴圈模式

人機迴圈模式會直接在代理的工作流程中整合人為介入點。在預先定義的檢查點，代理程式會暫停執行作業，並呼叫外部系統，等待人員審查其工作。這個模式可讓人在代理繼續作業前，先核准決策、修正錯誤或提供必要輸入內容。

下圖顯示人為參與迴路模式的概略檢視畫面：

多代理人機迴圈設計模式的架構。

對於需要人工監督、主觀判斷或核准重要操作的任務，請使用人機迴圈模式。這類動作包括核准大型金融交易、驗證機密文件的摘要，或針對生成的創意內容提供主觀意見。舉例來說，代理可能會負責將病患資料集匿名化，以供研究使用。代理程式會自動識別並遮蓋所有受保護的健康資訊，但會在最終檢查點暫停。然後等待人工合規主管手動驗證資料集並核准發布，確保不會洩漏任何私密資料。

人機迴圈模式會在工作流程中的重要決策點插入人為判斷，藉此提升安全性與可靠性。這個模式需要建構及維護外部系統，以供使用者互動，因此可能會大幅增加架構複雜度。

自訂邏輯模式

自訂邏輯模式可讓您在工作流程設計中享有最大彈性。這種做法可讓您使用程式碼 (例如條件陳述式) 實作特定的自動調度管理邏輯，建立具有多個分支路徑的複雜工作流程。

下圖說明如何使用自訂邏輯模式擷取退款程序：

多代理自訂設計模式的架構。

在上圖中，以下是範例客戶退款代理程式的代理工作流程：

使用者將查詢傳送至客戶退款代理，該代理會做為協調代理。
協調器的自訂邏輯會先叫用平行驗證代理程式，同時調度兩個子代理程式：購買者驗證代理程式和退款資格條件代理程式。
收集結果後，協調員代理程式會執行工具，檢查要求是否符合退款資格。
1. 如果使用者符合資格，協調員會將工作轉送給退款處理代理，該代理會呼叫 process_refund 工具。
2. 如果使用者不符合資格，協調員會將工作轉送至其他循序流程，從商店抵免額服務專員和處理抵免額決策服務專員開始。
無論採取哪種路徑，結果都會傳送至最終回覆代理，以擬定使用者的答案。

顧客退款服務專員範例需要獨特的解決方案，才能進行邏輯層級的協調，這已超出其他模式提供的結構化方法。這個工作流程會混合模式，因為它會執行平行檢查，然後執行自訂條件分支，將流程導向兩個完全不同的下游程序。這類複雜的混合模式工作流程，是自訂邏輯模式的理想用途。

如需精細控管代理程式的執行作業，或工作流程不符合本文所述的其他模式，請使用自訂邏輯模式。不過，這種做法會增加開發和維護的複雜度。您必須負責設計、實作及偵錯整個協調流程，這需要更多開發工作，且相較於使用 Agent Development Kit (ADK) 等工具支援的預先定義模式，更容易發生錯誤。

如要瞭解自訂代理，以及如何使用 ADK 實作自訂邏輯，請參閱「自訂代理」。