(點擊上方圖片觀看本課程影片)
一旦你開始從事涉及多代理的項目,就需要考慮多代理設計模式。然而,何時切換到多代理及其優勢可能並非立刻明朗。
在本課程中,我們將嘗試回答以下問題:
完成本課後,你應該能夠:
更大的視角是什麼?
多代理是一種設計模式,允許多個代理共同協作達成共同目標。
這種模式廣泛應用於機器人技術、自主系統及分散式計算等領域。
那些情境適合使用多代理?答案是多種狀況下使用多代理皆有好處,尤其是以下情況:
單代理系統在簡單任務上表現良好,但面對更複雜任務,使用多代理具有多項優勢:
舉例來說,為用戶訂旅程。單代理需涵蓋從尋找航班到訂飯店及租車的所有面向。為此代理需要包含處理所有任務的工具,導致系統複雜且難以維護和擴展。相反,多代理系統可由專責尋找航班、訂飯店和租車的不同代理組成,使系統更模組化、易維護且具擴展性。
比較獨立經營的旅行社與以加盟方式經營的旅行社。獨立店面由一代理負責全部訂程流程,而加盟體系由多個代理分別負責流程不同面向。
在實作多代理設計模式前,需要了解構成該模式的基石。
再以為用戶訂旅程為例,基石包含:
了解多代理如何互動非常重要,這是除錯、優化及確保系統整體效能的關鍵。為此,你需要具備追蹤代理活動與互動的工具與技術,如日誌監控、視覺化工具及效能指標。
以為用戶訂旅程為例,可有一儀表板顯示各代理狀態、用戶偏好與限制及代理間互動。儀表板可展示旅行日期、航班代理推薦航班、飯店代理推薦飯店及租車代理推薦車輛。這樣可清晰觀察代理互動狀況及用戶偏好限制是否滿足。
讓我們更仔細看看這些面向。
日誌監控工具:需為每項代理動作記錄日誌。日誌包含採取動作的代理、動作內容、時間及結果,幫助除錯與優化。
視覺化工具:視覺化工具能更直觀呈現代理間互動。例如資訊流的圖形展示,有助發現瓶頸、效率問題及其他系統缺陷。
效能指標:追蹤多代理系統效能,如完成任務時間、單位時間完成數及代理推薦準確度。這些資訊幫助辨識改進空間,優化系統。
讓我們探討可用於建立多代理應用的具體模式。以下是值得考慮的模式:
想構建多代理可相互通訊的群組聊天應用時,此模式很實用。典型用例包括團隊協作、客服支持及社交網絡。
在此模式中,每個代理代表群組聊天中的一個用戶,代理間透過訊息協議交換訊息。代理可發送訊息至群組、接收群組訊息及回覆其他代理訊息。
此模式可用集中式架構實現,所有訊息經由中央伺服器轉發,或用分散式架構直接交換訊息。

當需要多代理可互相轉交任務的應用時,此模式相當適用。
典型用例包括客戶支援、任務管理及工作流程自動化。
在此模式中,每個代理代表工作流程中的一個任務或步驟,代理可根據預定規則將任務轉交給其他代理。

當想建立多代理協同推薦給用戶的應用時,此模式非常有用。
多代理協同的原因是各代理具備不同專長,可從不同面向為推薦過程作出貢獻。
以用戶想要股市最佳買入股票推薦為例:

假設顧客嘗試申請產品退款,過程中可能牽涉多位代理,我們將代理分為專責退款流程的代理與可應用於其他流程的一般代理。
專責退款流程的代理:
可能參與退款流程的代理如下:
一般代理:
這些代理可供業務其他部分共用。
上述代理不僅涵蓋退款專用,亦包含可用於業務其他部分的一般代理。希望你能由此了解如何決定多代理系統中應使用哪些代理。
設計一個用於客戶支援流程的多代理系統。識別流程中涉及的代理,他們的角色與職責,以及彼此間的互動。請考量既有專屬客戶支援流程的代理,也有業務其他部分共用的通用代理。
在閱讀以下解決方案前,先想一想,你可能需要比預期更多的代理人。
提示:思考客服支援流程的不同階段,並且考慮任何系統所需的代理人。
哪個情境最適合多代理人系統?
何時通常單一代理人是較佳選擇?
在本課程中,我們探討了多代理人設計模式,包括多代理人適用的情境、使用多代理人優於單一代理人的優點、實作多代理人設計模式的組成元件,以及如何掌握多個代理人之間的互動情形。
加入 Microsoft Foundry Discord ,與其他學習者交流、參加辦公時間並獲得你的 AI 代理人問題解答。
免責聲明: 本文件由 AI 翻譯服務 Co-op Translator 翻譯而成。雖然我們致力於確保準確性,但請注意,機器自動翻譯可能包含錯誤或不準確之處。原始文件的母語版本應被視為權威來源。對於重要資訊,建議進行專業人工翻譯。我們不對因使用本翻譯而產生的任何誤解或誤釋承擔責任。