隨著架構師和開發人員設計其工作負載以充分利用語言模型功能，AI 代理系統變得越來越複雜。 這些系統通常超出了可以存取許多工具和知識來源的單一代理的能力。 相反，這些系統使用多代理協調來可靠地處理複雜的協作任務。 本指南涵蓋多代理程式架構的基本協調流程模式，並協助您選擇符合特定需求的方法。
概觀
當您使用多個 AI 代理時，您可以將複雜的問題分解為專門的工作或知識單元。 您可以將每項任務指派給具有特定功能的專用 AI 代理程式。 這些方法反映了人類團隊合作中的策略。 與單片單一代理解決方案相比，使用多個代理具有多種優勢。
專業化： 單個代理可以專注於特定的領域或功能，從而減少代碼和提示的複雜性。
可擴展性：可以添加或修改代理，而無需重新設計整個系統。
可維護性： 測試和調試可以專注於單個代理，從而降低了這些任務的複雜性。
優化： 每個代理程式都可以使用不同的模型、任務解決方法、知識、工具和運算來實現其結果。
本指南中的模式顯示了協調多個代理協同工作並完成結果的經過驗證的方法。 每個模式都針對不同類型的協調需求進行了優化。 這些 AI 代理協調模式透過解決在 AI 驅動的工作負載功能中協調自主元件的獨特挑戰，補充和擴展了傳統的 雲端設計模式 。
循序編排
循序編排模式以預先定義的線性順序鏈結 AI 代理程式。 每個代理程式都會處理序列中前一個代理程式的輸出，這會建立特殊化轉換的管線。
循序協調流程模式解決了需要逐步處理的問題，其中每個階段都建立在前一個階段之上。 它適合具有明確依賴關係的工作流程，並透過漸進式細化來提高輸出品質。 此模式類似於 Pipes 和 Filters 雲端設計模式，但它使用 AI 代理程式而不是自訂編碼的處理元件。 選擇接下來叫用哪個代理程式是確定性地定義為工作流程的一部分，而不是流程中代理程式的選擇。
何時使用循序編排
請考慮下列案例中的循序協調流程模式：
具有明確線性相依性和可預測工作流程進度的多階段流程
資料轉換管線，其中每個階段都會新增下一個階段相依的特定值
無法平行化的工作流程階段
漸進式細化要求，例如 草稿、審查、潤色 工作流程
在這類系統中，您能瞭解管線中每個 AI 代理的可用性和效能特性，並且一個 AI 代理的處理失敗或延遲可以被容忍，而不影響整體任務的完成。
何時避免循序協調流程
在下列案例中避免此模式：
階段是令人尷尬的平行。 您可以將它們平行化處理，既不會影響品質，也不會造成共享狀態的競爭。
只包括幾個階段，並且單一 AI 代理程式可以有效完成。
早期階段可能會失敗或產生低質量的輸出，而且沒有合理的方法可防止後續步驟使用累積的錯誤輸出來處理。
AI 代理程式需要共同作業，而不是交出工作。
工作流程需要回溯或迭代。
您需要以中繼結果為基礎的動態路由。
循序協調範例
律師事務所的檔管理軟體會使用循序代理程式來產生合約。 智慧型應用程式會透過四個特製化代理程式的管線來處理要求。 循序和預先定義的管線步驟可確保每個代理程式都能與上一個階段的完整輸出搭配運作。
範本選擇代理會接收客戶規格，例如合約類型、管轄區和相關方，並從公司的資料庫中選擇適當的基本範本。
條款自訂代理程式會採用選取的範本，並根據協商的業務條款（包括付款排程和責任限制）修改標準條款。
監管合規代理根據適用法律和行業特定法規審查定制合同。
風險評估代理對整個合約進行全面分析。 它評估責任風險和爭議解決機制，同時提供風險評級和保護性語言建議。
並行協調
並行協調流程模式會在相同的工作上同時執行多個 AI 代理程式。 這種方法允許每個代理從其獨特的視角或專業化提供獨立的分析或處理。
此模式可解決您需要不同見解或方法來解決同一問題的情況。 所有代理程式都平行工作，而不是循序處理，這可減少整體執行時間，並提供問題空間的全面涵蓋面。 此協調流程模式類似於扇出/扇入雲端設計模式。 每個代理程式的結果通常會彙總以返回最終結果，但這並非必要。 每個代理程式可以在工作負載中獨立產生自己的結果，例如叫用工具來完成工作或平行更新不同的數據存放區。
代理程式會獨立運作，且不會互相交出結果。 代理程式可能會透過使用其自己的編排流程方法，叫用額外的 AI 代理程式，作為其獨立處理的一部分。 可用的代理程式必須了解哪些代理程式可供處理。 此模式同時支援所有已註冊代理程式的決定性呼叫，以及根據工作需求叫用的代理程式動態選取。
使用並行協調流程的時機
在下列案例中，請考慮並行協調流程模式：
您可以使用固定的代理程式集，或根據特定工作需求動態選擇 AI 代理程式，以平行方式執行的工作。
受益於多個獨立觀點或不同專業領域的任務，例如技術、商務和創意方法，這些都能對同一問題作出貢獻。 此共同作業通常會在具有下列多代理程式決策技術的案例中發生：
腦力激盪
集成推理
法定人數和基於投票的決策
平行處理可減少延遲的時間敏感情境。
何時應避免並行協調
在下列案例中避免此協調流程模式：
代理程式必須以彼此的工作為基礎，或需要特定序列中的累積內容。
工作需要特定的作業順序或確定性、可重現的結果，這些結果需通過在已定義的序列中運行才能實現。
資源條件約束，例如模型配額，使得平行處理效率不佳或不可能。
代理程式無法在同時執行時可靠地協調共享狀態或外部系統的變更。
沒有明確的衝突解決策略可處理來自每個代理的衝突或矛盾結果。
結果匯總邏輯太複雜或降低結果的品質。
並行協調範例
金融服務公司打造了一個智慧型應用程式，使用並行代理，專門從事不同類型的分析，以便同時評估相同的股票。 每個代理程式都從其專業化的觀點提供見解，提供多樣化且時間敏感的資訊，以支持快速做出投資決策。
系統透過將相同的股票代碼分派給並行執行的四個專用代理來處理股票分析請求。
基本面分析代理評估財務報表、收入趨勢和競爭定位，以評估內在價值。
技術分析代理檢查價格模式、成交量指標和動量訊號以識別交易機會。
情緒分析代理處理新聞文章、社交媒體提及和分析師報告，以衡量市場情緒和投資者信心。
環境、社會和治理 （ESG） 代理人審查環境影響、社會責任和治理實踐報告，以評估可持續發展風險和機會。
然後，這些獨立結果被組合成全面的投資建議，使投資組合經理能夠快速做出明智的決策。
群組聊天協調
群組聊天協調模式可讓多個客服專員透過參與共用對話線程來解決問題、做出決策或驗證工作，他們透過討論進行協作。 為了協調流程，聊天管理員通過確定哪些客服人員可以接下來作出響應，並管理從協作腦力激盪到結構化質量把關等不同互動模式。
此模式解決了最好通過小組討論來做出決策的場景。 這些場景可能包括協作構思、結構化驗證或品質控制流程。 該模式支持各種互動模式，從自由流動的腦力激盪到具有固定角色和審批門的正式審查工作流程。
此模式非常適合人機迴圈案例，其中人類可以選擇性地承擔動態聊天管理員的職責，並引導對話取得成效。 在此協調流程模式中，代理程式通常處於 唯讀 模式。 他們不使用工具來更改正在運行的系統。
何時使用群組聊天協調流程
當您的案例可以透過自發性或引導式協作或反覆製作者－檢查者迴圈來解決時，請考慮群組聊天協調流程。 所有這些方法都支持實時人工監督或參與。 因為迴圈中的所有代理程式和人員都會將輸出發出到單一累積執行緒中，所以此模式提供了透明度和可審核性。
協作場景
創意腦力激盪會議，具有不同觀點和知識來源的客服專員在彼此對聊天的貢獻的基礎上進行交流
受益於辯論和共識建立的決策過程
需要透過討論反覆細化的決策場景
需要跨職能對話的多學科問題
驗證和品質控制案例
涉及結構化檢閱過程和反覆過程的質量保證需求
需要多個專家視角的合規性和監管驗證
需要編輯審查的內容創建工作流程，並明確區分創建和驗證之間的關注點
何時避免群組聊天編排
在下列案例中避免此模式：
簡單的任務委派或線性管道處理就足夠了。
即時處理需求使討論負擔變得不可接受。
明確的分層決策或無需討論的確定性工作流程更為合適。
聊天管理員沒有客觀的方法來判斷任務是否完成。
管理對話流程和防止無限循環需要仔細注意，尤其是當更多的代理使控制更難以維持時。 為了保持有效控制，請考慮將群聊編排限制為三個或更少的客服人員。
製作者檢查器迴圈
製作者-檢查器循環是一種特定類型的群聊編排，其中的一位代理人（製作者）創建或提議某些內容。 另一個代理人， 檢查器，對結果提出了批評。 此模式是迭代的，檢查代理會將對話傳回給製作代理，以進行更新並重複這個過程。 雖然群組聊天模式不需要客服專員 輪流 聊天，但製作人員-審核者迴圈需要由聊天管理員驅動的正式回合製流程。
群組聊天協調流程範例
城市公園和娛樂部門使用包含群聊編排的軟件來評估新的公園開發提案。 該軟件會閱讀提案草案，多名專家代理討論不同的社區影響觀點，並努力就提案達成共識。 此程序會在提案開放供社群檢閱之前進行，以協助預測提案可能收到的意見反應。
該系統通過與從多個公民角度參與任務的專業市政機構發起小組諮詢來處理公園開發提案。
社區參與代理評估無障礙要求、預期居民回饋和使用模式，以確保公平的社區存取。
環境規劃代理人評估生態影響、永續性措施、原生植被位移以及環境法規的遵守情況。
預算和營運代理分析建築成本、持續維護費用、人員配置需求和長期營運永續性。
聊天管理器促進結構化辯論，客服人員可以互相質疑彼此的建議並捍衛自己的推理。 公園部門員工參與聊天線程以增加見解並即時回應客服人員的知識請求。 此過程使員工能夠更新原始提案，以解決已識別的問題並更好地為社區反饋做好準備。
交接協調流程
交接協同模式可在專業代理之間動態分配任務。 每個代理都可以評估手頭的任務，並根據上下文和要求決定是直接處理還是將其轉移到更合適的代理。
此模式可解決預先不知道任務的最佳代理程式，或任務需求僅在處理期間變得清晰的情況。 它支援智慧路由並確保任務到達最有能力的客服專員。 此模式中的代理程式通常不會平行運作。 完全控制從一個代理轉移到另一個代理。
何時使用移交協調流程
在下列情境中考慮代理人交接模式：
需要專業知識或工具，但無法預先確定所需客服人員數量或其順序的任務
在處理過程中出現專業知識需求的場景，導致基於內容分析的動態任務路由
需要不同專家逐一操作的多領域問題
可預先確定的邏輯關係和信號，用於指示一個代理何時達到其能力極限，以及下一個代理應該處理任務的順序。
何時避免交接協調流程
在下列案例中避免此模式：
適當的代理及其訂單始終是預先知道的。
任務路由簡單且確定性地以規則為基礎，而不是基於動態上下文視窗或動態解釋。
次優的路由決策可能會導致使用者體驗不佳或令人沮喪。
多個作業應該同時執行，以處理工作。
避免無限的交接循環或避免代理之間的過度跳動具有挑戰性。
客服專員交接模式範例
電信客戶關係管理 （CRM） 解決方案在其客戶支援入口網站中使用移交代理程式。 最初的客服專員開始幫助客戶，但在對話過程中發現它需要專業知識。 初始代理將任務傳遞給最合適的代理，以解決客戶的疑慮。 一次只有一個代理程式對原始輸入進行操作，而交接鏈會產生單一結果。
在此系統中， 分級支援代理程式 會解譯要求，並嘗試直接處理常見問題。 當它達到極限時，它會將網路問題交給 技術基礎設施代理，將計費爭議交給 財務解決代理，等等。 當目前的代理人認識到自己的能力限制並知道另一個代理人可以更好地支持場景時，這些代理人之間會進一步交接。
如果每個客服專員確定已實現客戶成功或沒有其他客服專員可以進一步使客戶受益，則該客服專員能夠完成對話。 一些代理程式還設計為在問題需要解決時將使用者體驗移交給人工支援代理，但目前沒有人工智慧代理程式有能力解決該問題。
圖中醒目提示了遞交實例的一個範例。 它從分診代理將任務移交給技術基礎結構代理程式開始。 然後，技術基礎設施代理決定將任務移交給財務解決代理，最終將任務重新導向給客戶支援。
Magentic 編排
magentic 協調流程模式是針對沒有預先決定方法計劃的開放式和複雜問題所設計。 此模式中的代理程式通常具有允許他們在外部系統中進行直接變更的工具。 重點既在於構建和記錄解決問題的方法，也在於實施該方法。 任務清單在專用代理程式與磁性管理代理程式之間的協作下，作為工作流程的一部分，進行動態構建和優化。 隨著上下文的發展，magentic 管理器代理會構建一個任務分類帳來制定包含目標和子目標的方法計劃，最終最終確定、遵循和跟踪以完成預期結果。
管理員代理程式直接與專用代理程式通訊，以在建立和精簡任務分類帳時收集資訊。 它會視需要多次反覆、回溯和委派，以建立可以成功執行的完整計劃。管理代理程式經常評估原始要求是否完全滿足或停滯不前。 它會更新總帳以調整計劃。
在某些方面，這種協調流程模式是 群聊 模式的延伸。 磁性協作模式專注於一個負責制定方法計劃的代理程式，而其他代理程式則使用工具在外部系統中進行更改，而不是僅依賴其知識儲存來達到結果。
何時使用磁性編排
在以下場景中考慮青色圖案：
沒有預先決定解決方案路徑的複雜或開放式使用案例。
考慮多位專業專家提供的意見和反饋，以制定一條有效的解決路徑的要求。
AI 系統生成一份完整的行動計劃的要求，人類可以在執行前或後檢閱該計劃。
配備工具的代理程式會與外部系統互動、取用外部資源，或可能會引發執行中系統的變更。 記錄的計劃，是展示這些代理程式應如何排序，並在允許代理程式執行任務之前，將其呈現給使用者。
避免使用磁場協作的時機
在下列案例中避免此模式：
解決方案路徑已被開發，並且應以決定性的方式進行。
不需要產生總賬。
工作的複雜性較低，而且較簡單的模式可以加以解決。
工作具有時效性，因為模式著重於建置和辯論可行的計劃，而不是針對最終結果進行優化。
您預期經常發生停滯或無限迴圈，而沒有明確的解決路徑。
Magentic 協調流程範例
網站可靠性工程團隊（SRE）建置了使用編排機制的自動化，以處理低風險事件回應場景。 當服務中斷發生在自動化範圍內時，系統必須動態建立並實作補救計劃。 它不需要事先知道所需的特定步驟，即可這樣做。
當自動化偵測到合格事件時， magentic 管理程式代理程式 會先建立起始作業分類帳，其中包含高階目標，例如還原服務可用性及識別根本原因。 然後，經理代理會諮詢專業代理，以收集資訊並完善補救計劃。
診斷代理程式會分析系統日誌、效能指標和錯誤模式，以識別潛在原因。 它會將調查結果報告回管理代理。
根據診斷結果，管理程式代理程式會使用特定調查步驟更新工作分類帳，並諮詢 基礎結構代理程式 ，以瞭解目前的系統狀態和可用的復原選項。
通訊代理提供利害關係人通知功能，經理代理根據 SRE 團隊的升級程序，將通訊檢查點和審批門納入不斷發展的計劃中。
隨著情境變得更加清晰，當需要部署還原時，管理員代理人可能會將 復原代理人 新增至計畫，或者在事件超出自動化範圍時，尋求人工 SRE 工程師的協助。
在整個過程中，管理器代理程式會根據新資訊不斷完善任務分類帳。 它會隨著事件的發展而新增、移除或重新排序任務。 例如，如果診斷代理程式探索到資料庫連線問題，則管理程式代理程式可能會將整個計劃從部署回復策略切換至著重於還原資料庫連線功能的計劃。
管理代理程式會監控還原服務時出現過多的延遲，並防範無限修復迴圈的發生。 它維護不斷發展的計劃和實施步驟的完整審計跟踪，這為事件後審查提供了透明度。 這種透明度確保 SRE 團隊能夠根據經驗教訓改進工作負載和自動化。
實作考量
當您實作任何這些代理程式設計模式時，必須解決數個考量。 檢閱這些考量事項可協助您避免常見陷阱，並確保您的代理程式協調流程穩健、安全且可維護。
單一代理，多工具
如果您授予單一代理程式對工具和知識來源的充分存取權限，則可以解決其某些問題。 隨著知識來源和工具數量的增加，提供可預測的客服專員體驗變得困難。 如果單一代理程式可以可靠地解決您的案例，請考慮採用該方法。 決策和流程控制額外負荷通常超過將任務分解為多個代理的好處。 然而，安全邊界、網路視線和其他因素仍然可能使單一代理方法變得不可行。
確定性路由
某些模式需要您以決定性方式在代理程式之間路由流程。 其他人則依靠代理商來選擇自己的路線。 如果您的代理程式是在無程式碼或低程式碼環境中定義的，您可能無法控制這些行為。 如果您使用 Microsoft Agent Framework 或語意核心等 SDK 在程式碼中定義代理程式，則有更多控制權。
語境視窗
AI 代理通常具有有限的上下文視窗。 這種限制會影響他們處理複雜任務的能力。 當您實作這些模式時，請決定下一個代理程式需要什麼內容才能有效。 在某些情況下，您需要截至目前收集到的完整原始上下文。 在其他案例中，摘要或截斷版本更合適。 如果您的代理程式可以在沒有累積上下文的情況下工作，並且只需要新的指令集，請採用該方法，而不是提供無助於完成代理程式任務的上下文。
可靠性
這些模式需要正常運作的代理和它們之間的可靠轉換。 它們通常會導致經典的分散式系統問題，例如節點故障、網路分割區、訊息遺失和級聯錯誤。 應制定緩解策略來應對這些挑戰。 代理及其協調器應執行下列步驟。
實作逾時和重試機制。
包含正常降級實作，以處理模式錯誤中的一或多個代理程式。
顯示錯誤而不是隱藏它們，因此下游代理程式和協調器邏輯可以適當地回應。
考慮代理相依性的斷路器設計模式。
將代理程式設計為彼此之間盡可能隔離，代理之間不共用單一故障點。 例如：
確保代理程式之間的運算隔離。
評估使用單一模型即服務 （MaaS） 模型或共用知識儲存庫如何在代理程式同時執行時導致速率限制。
使用 SDK 中可用的檢查點功能，協助從中斷的協調流程中復原，例如從錯誤或新的程式碼部署中復原。
安全性
在這些設計模式中實施適當的安全機制可以最大限度地降低 AI 系統遭受攻擊或資料外洩的風險。 保護代理之間的通訊並限制每個代理對敏感資料的存取是關鍵的安全設計策略。 請考慮下列安全措施：
實作驗證，並在代理程式之間使用安全網路。
考慮代理通訊對資料隱私的影響。
設計稽核追蹤以符合合規性要求。
設計代理程式及其協調器，以遵循最小權限原則。
考慮如何跨代理程式處理使用者的身分。 客服專員必須具有知識存放區的廣泛存取權，才能處理來自所有使用者的要求，但不得傳回使用者無法存取的資料。 必須在模式中的每個代理程式中實作安全性修剪。
可觀察性和測試
將 AI 系統分佈在多個代理之間需要單獨監控和測試每個代理以及整個系統，以確保功能正常。 當您設計可觀測性和測試策略時，請考慮下列建議：
監控所有代理程式操作和交接。 對分散式系統進行故障排除是一項電腦科學挑戰，編排的 AI 代理也不例外。
追蹤每個代理程式的效能和資源使用量指標，以便建立基準、尋找瓶頸並進行最佳化。
為單個代理設計可測試的界面。
實施多代理工作流程的整合測試。
常見陷阱和反模式
當您實作代理程式協調流程模式時，請避免下列常見錯誤：
當簡單的循序或並行編排就足夠時，使用複雜的模式來造成不必要的協調複雜性。
新增不提供有意義的專業化的代理程式。
忽略多跳通訊的延遲影響。
在並行代理程式之間共用可變狀態，這可能會導致交易不一致的資料，因為假設跨代理程式界限進行同步更新。
針對本質上不確定的工作流程使用確定性模式。
針對本質上具有決定性的工作流程使用非決定性模式。
當您選擇並行協調流程時，忽略資源限制。
消耗過多的模型資源，因為隨著代理程式累積更多資訊並查閱其模型以取得任務進展，上下文視窗會增加。
結合編排模式
應用程式有時需要您結合多個協調流程模式來滿足其需求。 例如，您可以針對初始資料處理階段使用循序協調流程，然後切換至並行協調流程以進行可平行化的分析工作。 當工作負載的不同階段具有不同的特性，而且可以使用不同的模式從每個階段獲益時，請勿嘗試讓一個工作流程符合單一模式。
與雲端設計模式的關係
AI 代理編排模式透過解決協調智慧、自主元件的獨特挑戰，擴展和補充了傳統的 雲端設計模式 。 雲端設計模式著重於分散式系統中的結構和行為問題，但 AI 代理編排模式專門解決元件與推理能力、學習行為和非確定性輸出的協調。
SDK 型實作
其中許多模式都依賴程式碼型實作來解決協調流程邏輯。 支援代理程式架構的 SDK 通常會為許多代理程式協調模式提供支援。
Microsoft 代理程式架構
Microsoft Agent Framework SDK 具有 代理程式架構協調流程的實作指引。
如需實作，請探索 GitHub 上的代理 程式架構宣告式工作流程範例 ，這些範例在實務中示範其中一些模式。
語意核心
語意核心 SDK 具有其 代理程式架構的實作指引。
如需實作，請探索 GitHub 上的 Semantic Kernel 多代理人協作範例，以示範這些模式的實務應用。
您還可以在 AutoGen 中找到其中許多模式，例如 Magentic-One。
Microsoft Foundry Agent Service 中的實作
你也可以利用 Microsoft Foundry 代理服務 ，透過 其連結的代理 功能，將代理串聯成相對簡單的工作流程。 您使用此服務實作的工作流程主要是不確定的，這會限制在此無程式碼環境中可以完全實作哪些模式。
貢獻者們
本文由 Microsoft 維護。 下列參與者撰寫本文。
主要作者：
其他貢獻者：
- 赫馬瓦西·阿拉加南丹 |首席軟件工程師
- 李志堅 | 資料科學家 2
- Ritesh Modi |首席軟體工程師
- Mahdi Setayesh |首席軟體工程師
- Mark Taylor |首席軟體工程師
- 亞尼夫·瓦克寧 |高級技術專員
若要查看非公開的 LinkedIn 個人檔案，請登入 LinkedIn。