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

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

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

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

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

設計程序總覽

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

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

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

定義需求

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

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

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

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

單一代理系統

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

下圖顯示單一代理程式模式的概略視圖：

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

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

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

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

多代理系統

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

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

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

依序模式

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

下圖顯示多重代理程式循序模式的概略視圖：

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

如果程序結構嚴謹且可重複執行，且作業順序不會改變，請使用循序模式。舉例來說，資料處理管道可能會使用這個模式，先讓資料擷取代理程式提取原始資料，然後將該資料傳送至資料清理代理程式進行格式化，接著再將清理後的資料傳送至資料載入代理程式，以便儲存在資料庫中。

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

平行模式

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

下圖顯示多重代理程式平行模式的概略視圖：

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

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

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

循環模式

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

下圖顯示多重代理程式迴圈模式的概略視圖：

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

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

查看及評論模式

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

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

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

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

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

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

反覆修正模式

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

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

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

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

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

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

協調員模式

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

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

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

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

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

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

階層式工作分解模式

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

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

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

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

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

蟲群模式

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

下圖顯示多代理程式群模式的概略視圖：

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

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

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

如果問題模稜兩可或非常複雜，需要經過辯論和反覆修正才能解決，請使用群體模式。舉例來說，設計新產品可能需要市場研究人員、工程師和財務建模人員。代理程式會分享初步想法、討論功能和成本之間的取捨，並共同制定最終設計規格，以平衡所有相互衝突的需求。

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

推論並行動 (ReAct) 模式

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

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

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

下圖顯示 ReAct 模式的概略視圖：

ReAct 設計模式的架構。

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

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

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

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

人機迴圈模式

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

下圖顯示人為參與迴圈模式的概略視圖：

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

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

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

自訂邏輯模式

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

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

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

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

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

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

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

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

比較設計模式

選擇代理程式模式是基本的架構決策。每種模式在彈性、複雜度和效能方面都有不同的取捨。如要為工作負載決定合適的模式，請參考下列各節的設計模式。

確定性工作流程

確定性工作流程包含可預測的循序工作，且從開始到結束都有明確定義的工作流程路徑。工作中的步驟是預先已知的，而且每次執行的程序不會有太大變化。以下是確定性工作流程的代理程式設計模式：

工作負載特性 代理程式設計模式
  • 遵循預先定義的嚴格工作流程的多步驟工作。
  • 不需要模型自動化調度管理。
  • 作業順序固定。一個代理程式的輸出內容會直接成為序列中下一個代理程式的輸入內容。
 多代理程式依序模式
  • 可同時執行的獨立工作。
  • 不需要模型自動化調度管理。
  • 同時執行子工作，藉此縮短整體延遲時間。
 多代理程式並行模式
  • 開放式或複雜的生成工作，難以一次完成。
  • 需要代理程式在多個週期內逐步改善輸出內容。
  • 不需要模型自動化調度管理。
  • 首重輸出內容品質，而非延遲。
 多代理程式疊代修正模式

需要動態調度管理的工作流程

需要動態自動化調度管理的工作流程包括複雜問題，代理程式必須判斷繼續的最佳方式。代理型 AI 系統必須動態規劃、委派及協調工作，不需要預先定義的指令碼。以下是需要自主和動態調度管理的工作流程適用的代理程式設計模式：

工作負載特性 代理程式設計模式
  • 需要使用外部工具的結構化多步驟工作。
  • 需要快速開發解決方案原型，以進行概念驗證。
 單一代理程式模式
  • 需要將結構化工作動態轉送至適當的專屬子代理程式，並提供各種輸入內容。
  • 由於需要多次呼叫協調員 AI 模型，才能將工作導向適當的子代理程式，因此延遲時間較長。
  • 由於會多次呼叫協調器代理程式，因此可能會產生高昂費用。
 多代理程式協調人員模式
  • 需要多層級模型調度管理，才能處理複雜、開放式和模稜兩可的任務。
  • 需要全面且高品質的結果，主要挑戰在於分解模糊不清的內容。
  • 由於巢狀多層分解，導致多次呼叫 AI 模型進行推理，因此延遲時間較長。
 多代理程式階層式工作分解模式
  • 對於高度複雜、開放式或模稜兩可的任務，需要多位專業代理進行協作討論和反覆修正。
  • 優先整合多種觀點，打造全面或創新的解決方案。
  • 由於代理程式之間動態進行全對全通訊，因此延遲時間較長，作業成本也較高。
 多代理程式群集模式

涉及疊代的工作流程

需要疊代的工作流程包括：透過精修、意見回饋和改良等循環，最終完成輸出內容的工作。以下是涉及疊代的代理程式工作流程設計模式：

工作負載特性 代理程式設計模式
  • 需要代理反覆推論、行動和觀察，才能為複雜、開放式和動態工作建立或調整計畫。
  • 優先提供更準確詳盡的結果，而非縮短延遲時間。
 ReAct 模式
  • 需要重複執行預先定義的動作 (例如自動檢查) 的監控或輪詢工作，直到代理程式符合結束條件為止。
  • 等待符合結束條件時，延遲時間無法預測或過長。
 多代理程式迴圈模式
  • 工作必須經過明確的驗證步驟才能完成。
 多代理程式審查和評論模式
  • 開放式或複雜的生成工作，難以一次完成。
  • 需要代理程式在多個週期內逐步改善輸出內容。
  • 不需要模型自動化調度管理。
  • 首重輸出內容品質，而非延遲。
 多代理程式疊代修正模式

有特殊需求的工作流程

有特殊需求的工作流程包括不遵循常見代理模式的任務。工作可以包含獨特的商業邏輯，或在重要時間點需要人工判斷和介入。代理式 AI 系統是專為單一特定用途設計的自訂機器。以下是工作流程的代理程式設計模式，適用於有特殊需求的情況：

工作負載特性 代理程式設計模式
  • 由於任務涉及高風險或主觀判斷，可能包含安全、可靠性和法規遵循要求，因此需要人工監督。
 人機迴圈模式
  • 複雜的分支邏輯，超出直接線性序列。
  • 需要最高程度的控制權，才能將預先定義的規則與模型推理混合使用。
  • 需要對不符合標準範本的工作流程進行精細的程序控制。
 自訂邏輯模式

後續步驟

貢獻者

作者：Samantha He | 技術文件撰稿者

其他貢獻者：