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 代理會帶來某些獨特且嚴重的安全風險，傳統的確定性安全防護做法可能無法充分因應。使用 Agent Gateway 進行輸入和輸出流量轉送和安全防護、Agent Identity 進行工作負載繫結驗證和最小權限存取控管，以及 Agent Registry 確保使用經過驗證的工具和子代理。

本節指南僅列出部分範例。如要進一步瞭解設計因素和最佳做法，以及建構和部署多代理式 AI 系統的建議，請參閱「 Google Cloud中的多代理式 AI 系統」。

依序模式

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

下圖顯示多代理程式依序模式的概略檢視畫面：

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

如果程序高度結構化、可重複，且作業順序不會改變，請使用依序模式。舉例來說，資料處理管道可能會使用這種模式，先由資料擷取代理提取原始資料，再將資料傳遞給資料清理代理進行格式設定，接著將乾淨的資料傳遞給資料載入代理，儲存至資料庫。

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

平行模式

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

下圖顯示多代理平行模式的概略檢視畫面：

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

如果子任務可以同時執行，請使用平行模式，以縮短延遲時間或收集不同觀點，例如從不同來源收集資料，或同時評估多個選項。舉例來說，如要分析客戶意見回饋，平行代理可能會將單一意見回饋項目同時傳送給四個專門代理：情緒分析代理、關鍵字擷取代理、分類代理和緊急程度偵測代理。最後一個代理會將這四項輸出內容彙整成一份完整的意見回饋分析。

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

迴圈模式

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

下圖概略說明多代理迴圈模式：

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

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

評論與批評模式

多代理審查與評論模式 (又稱生成與評論模式) 會使用兩個專門代理 (通常在依序工作流程中)，提升生成內容的品質和可靠性。審查與評論模式是迴圈代理模式的一種實作方式。

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

下圖顯示多代理程式審查和評論模式的概略檢視畫面：

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

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

審查員和評論模式會新增專屬的驗證步驟，因此可提升輸出內容的品質、準確度和可靠性。不過，這項品質保證會直接導致延遲時間增加和作業費用提高。工作流程需要至少一個額外的模型呼叫，才能進行評論者的評估。如果流程包含修訂迴圈，內容會送回修正，每次疊代都會累積延遲時間和成本。

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

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

下圖顯示多代理程式反覆修正模式的概略架構：

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

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

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

協調員模式

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

協調者模式的特點是使用 AI 模型，自動調度及動態轉送工作。相較之下，平行模式則依賴硬式編碼工作流程，分派工作並同時執行，不需要 AI 模型自動調度管理。

下圖概略說明多代理協調器模式：

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

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

與較為死板、預先定義的工作流程相比，協調器模式更具彈性。透過模型轉送工作，協調者可以處理更多元的輸入內容，並在執行階段調整工作流程。不過，這種做法也有缺點。由於協調者和各個專用代理都仰賴模型進行推論，因此這種模式的模型呼叫次數會多於單一代理系統。雖然協調者模式可提高推論品質，但與單一代理系統相比，也會增加詞元處理量、營運成本和整體延遲時間。

階層式任務分解模式

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

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

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

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

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

群體模式

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

下圖概略說明多代理程式群體模式：

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

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

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

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

群體模式會模擬協作的專家團隊，因此能產生極高品質且富有創意的解決方案。不過，這也是最複雜且成本最高的多代理模式。如果沒有使用 AI 模型來協調的代理，可能會導致無效迴圈，或無法收斂至解決方案。因此，您必須設計複雜的邏輯，管理複雜的代理間通訊、控制疊代工作流程，並處理多個代理之間執行動態、多輪對話時，產生的重大營運成本和延遲。

推論並行動 (ReAct) 模式

ReAct 模式是一種方法，可讓 AI 模型將思考過程和動作，建構為一系列自然語言互動。在這個模式中，代理會反覆執行思考、行動和觀察的循環，直到符合退出條件。

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

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

下圖概略說明 ReAct 模式：

ReAct 設計模式的架構。

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

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

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

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

人機迴圈模式

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

下圖概略說明人工介入迴路模式：

多代理人工介入迴路設計模式的架構。

對於需要人工監督、主觀判斷或核准重要操作的任務，請使用人工介入迴路模式。這類動作包括核准大筆財務交易、驗證機密文件的摘要，或對生成的創意內容提供主觀意見回饋。舉例來說，代理可能需要將病患資料集去識別化，以便進行研究。代理會自動找出並遮蓋所有受保護的健康資訊，但在最後一個檢查點會暫停。接著，系統會等待法規遵循人員手動驗證資料集並核准發布，確保不會公開任何機密資料。

人工介入迴路模式會在工作流程的重要決策點加入人工判斷，提高安全性和可靠性。這種模式需要建構及維護用於使用者互動的外部系統，因此可能會大幅增加架構複雜度。

自訂邏輯模式

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

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

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

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

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

顧客退款代理範例需要獨特的邏輯層級自動化調度管理解決方案，這超出其他模式提供的結構化方法。這個工作流程會混合模式，因為它會執行平行檢查，然後執行自訂條件分支，轉送至兩個完全不同的下游程序。這類複雜的混合模式工作流程，最適合使用自訂邏輯模式。

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

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