共用方式為

代理程式系統設計模式

建置代理程式系統涉及協調大型語言模型的呼叫、資料檢索以及外部動作的整體運作方式。 您可以在一個從 決定性鏈結、通過能夠做出動態決策（可能涉及多次 LLM 調用）的 單一代理系統，直到能協調多個專門代理的 多代理架構 之間的 複雜性和自主性的連續體上思考設計模式。

工具呼叫

在深入探索設計模式之前，請務必瞭解工具呼叫做為可在任何代理程序系統中使用的基本功能，從簡單到複雜。 工具呼叫是一種機制，可讓代理程式系統與外部函式、數據源或服務互動。 這可以啟用：

  • 實時數據查閱，例如 SQL 查詢、CRM 擷取或向量索引擷取。
  • 傳送電子郵件或更新記錄等動作。
  • 可以透過 Python 函式或 API 執行任意邏輯或轉換。

因此，工具呼叫提供了一種強大的機制，使大型語言模型能夠「意識到」外部數據或 API，無論您選擇哪種設計模式。

若要深入瞭解代理程式工具，請參閱 AI 代理程式工具。

下列各節將討論三種代理程式系統設計模式，每個模式都可以利用不同程度的工具呼叫。

比較 Gen AI 應用程式設計模式

Gen AI 應用程式（代理程式）設計模式會以複雜度的順序呈現。

設計模式 使用時機 優點 缺點
決定性鏈結
  • 定義明確的任務
  • 靜態管線，例如基本RAG
  • 不需要即時決策
  • 非常簡單
  • 易於稽核
  • 死板
  • 需要變更程式代碼才能調整
單一代理程序系統
  • 在相同網域中處理中等至複雜的查詢
  • 某些動態決策不需要多個特製化代理程序的額外負荷。
  • 靈活
  • 比多重代理簡單
  • 良好的「預設值」
  • 較不可預測的
  • 必須防止重複或不正確的工具呼叫
多代理程式系統 大型或跨功能網域;多個「專家」代理：不同的邏輯或交談內容;進階反映模式。
  • 高度模組化
  • 擴展至大型領域
  • 安排起來很複雜
  • 更難追蹤和偵錯

單一代理系統

單一代理程式系統具有一個協調的邏輯流程，通常是協調多個 LLM 呼叫，以處理連入要求。 代理程式可以：

  1. 接受請求，例如使用者的查詢，以及任何相關的上下文資訊，例如對話歷史記錄。
  2. 考量如何以最佳方式回應，並選擇是否呼叫用於外部數據或操作的工具。
  3. 視需要重複呼叫 LLM（和/或相同工具），直到達到目標或符合特定條件（例如接收有效數據或解決錯誤）。
  4. 將工具輸出整合到交談中。
  5. 作為輸出，返回一個一致的回應。

在許多使用案例中，一輪 LLM 推理（通常是使用工具呼叫）就足夠了。 不過，更進階的代理程式可以迴圈執行多個步驟，直到達到所需的結果為止。

即使只有「一」代理程式，您仍然可以在幕後進行多個 LLM 和工具呼叫（用於規劃、產生、驗證等等），全部都由這個單一統一流程管理。

範例：技術支援中心助理

  • 如果使用者提出簡單的問題（「我們的退貨政策是什麼？」），代理程式可能會直接從 LLM 所擁有的知識中回答。
  • 如果使用者想要其訂單狀態，代理程式會呼叫函式 lookup_order(customer_id, order_id)。 如果此工具以「無效的訂單號碼」回應，代理程式可能會重試或提示使用者輸入正確的標識符，繼續直到提供最終答案為止。

使用時機：

  • 您預期會有不同的用戶查詢，但仍在一致網域或產品區域內。
  • 某些查詢或條件可能需要使用工具，例如決定何時提取客戶數據。
  • 您想要的彈性比決定性鏈結更有彈性，但不需要針對不同的工作使用不同的特製化代理程式。

優點：

  • 代理程式可以選擇要呼叫哪些工具，以適應新的或非預期的查詢。
  • 代理程式可以循環執行重複的 LLM 呼叫或工具調用來精簡結果， 而不需要完全多代理程式設定。
  • 此設計模式通常是企業使用案例的甜蜜點-比多代理程式設定更容易偵錯，同時仍允許動態邏輯和有限的自主性。

注意事項：

  • 相較於硬式編碼鏈結，您必須防範重複或無效的工具呼叫。 （無限迴圈可能發生在任何工具呼叫情境中，因此請設定迴圈次數限制或逾時。）
  • 如果您的應用程式涵蓋完全不同的子域（如財務、開發運維、行銷等），單一代理程式可能會變得難以管理或在功能需求上過載。
  • 您仍然需要精心設計的提示和條件約束，讓代理程式保持專注且相關。

決定性鏈結 （硬式編碼步驟）

在此模式中，開發人員會定義呼叫哪些元件、依何種順序，以及哪些參數。 沒有關於 要呼叫哪些工具，或者以 什麼順序的動態決策。 系統會針對所有要求遵循預先定義的工作流程，使其具有高度可預測性。

流程通常稱為「鏈結」，基本上是固定的步驟鏈結，例如：

  1. 持續提取使用者的要求，並從向量索引中提取相關內容。
  2. 將該內容與使用者的要求合併為最終 LLM 提示。
  3. 呼叫 LLM 並傳回回應。

範例：基本 RAG 鏈結

基本RAG鏈結的圖表。

具決定性的RAG鏈可能總是：

  1. 使用傳入使用者的要求從向量索引擷取 top-k 結果（擷取）。
  2. 將提取的區塊格式化為提示模板（擴增）。
  3. 將增強提示傳遞至 LLM（生成）。
  4. 傳回 LLM 的回應。

使用時機：

  • 適用於任務明確且流程可預測的工作。
  • 一致性和稽核是首要任務。
  • 當您希望通過避免多次進行 LLM 呼叫來協調決策，以將延遲降到最低時。

優點：

  • 最高可預測性和稽核性。
  • 通常延遲較低（協調流程的 LLM 呼叫較少）。
  • 更容易測試和驗證。

注意事項：

  • 處理各種或非預期的要求時，彈性有限。
  • 隨著邏輯分支成長，可能會變得複雜且難以維護。
  • 可能需要進行重大重構，以配合新功能。

多代理程序系統

多代理程式系統牽涉到兩個或多個特製化代理程式，這些代理程式會交換訊息和/或共同作業工作。 每個代理程式都有自己的領域或工作專業知識、內容，以及可能不同的工具集。 另一個「協調器」，可能是另一個 LLM 或以規則為基礎的路由器，會將要求導向適當的代理程式，或決定何時要從某個代理程式移交給另一個代理程式。

範例：具有特製化代理程序的企業助理

  • 客戶支援專員： 處理CRM查詢、退貨和出貨。
  • 分析代理程式： 著重於 SQL 查詢和數據摘要。
  • 監督員/路由器： 選擇哪一個代理程式最適合指定的用戶查詢，或切換時機。

每個子代理程式都可以在其自己的網域內執行工具呼叫（例如 lookup_customer_account 或 run_sql_query），通常需要唯一的提示或交談歷程記錄。

使用時機：

  • 您有不同的問題領域或技能集，例如程式開發專員或財務專員。
  • 每個代理程式都需要存取交談歷程記錄或網域特定的提示。
  • 您有許多工具，將它們全部放入一個代理程式的架構是不切實際的;每個代理程式都可以擁有子集。
  • 您想要在專業代理之間實作反思、批評或互動合作。

優點：

  • 這種模組化方法表示每個代理程式都可以由個別的小組開發或維護，專精於窄領域。
  • 可以處理單一代理程式可能難以一致管理的大型複雜企業工作流程。
  • 促進進階的多步驟或多視角推理——例如，一個代理生成答案，另一個代理驗證它。

注意事項：

  • 需要代理程式之間的路由策略，以及跨多個端點進行記錄、追蹤和偵錯的額外負荷。
  • 如果您有許多子代理程式和工具，決定哪個代理程式可以存取哪些數據或 API 會變得很複雜。
  • 如果不加以小心限制，代理可以無限期地在彼此之間傳遞工作，而不被解決。
    • 無限循環風險也存在於單一代理程式工具呼叫中，但多代理程式設定會增加另一層偵錯複雜性。

實用建議

無論您選取哪一種設計模式，請考慮下列開發穩定且可維護的代理程序系統的最佳做法。

  1. 開始簡單： 如果您只需要簡單的鏈結，則確定性鏈結是快速建置的。
  2. 逐漸增加複雜度： 因為您需要更多動態查詢或彈性數據源，請移至具有工具呼叫的單一代理程序系統。
  3. 採用多代理制： 只有當您擁有明確不同的領域或工作、多個對話情境，或是工具集過大且單一代理程式無法負荷時。

如果您的使用情境規模不大，就像一個簡單的RAG鏈一樣，可以先從硬編碼鏈開始。 隨著需求的發展，您可以將工具呼叫邏輯加入動態決策，甚至將工作分割成多個特製化代理程式。 實際上，許多真實世界的代理程序系統會結合模式。 例如，使用大部分具決定性的鏈結，但視需要允許 LLM 在單一步驟中動態呼叫特定 API。

馬賽克 AI 代理程式架構 與您選擇的任何模式無關，可讓您輕鬆地隨著應用程式成長而發展設計模式。

開發指導方針

  • 提示
    • 保持提示清晰和最少，以避免矛盾的指示，分散資訊，並減少幻覺。
    • 只提供代理程式所需的工具和內容，而不是一組未系結的 API 或大型無關內容。
  • 記錄 & 可檢視性
    • 針對每個使用者要求、代理程式方案和工具呼叫實作詳細的記錄。 MLflow 追蹤 可協助擷取結構化記錄以進行偵錯。
    • 安全地儲存記錄，並注意交談數據中的個人標識資訊（PII）。
  • 模型更新 & 版本釘選
    • 當提供者在幕後更新模型時，LLM 行為可能會改變。 使用版本釘選和頻繁的回歸測試，以確保代理程序邏輯保持健全且穩定。
    • 結合 MLflow 與 馬賽克 AI 代理程式評估 提供簡化的版本設定代理程式方式，並定期評估品質和效能。

測試和迭代指引

  • 錯誤處理 & 後援邏輯
    • 為工具或 LLM 故障做好規劃。 逾時、格式不正確的回應或空白結果可能會中斷工作流程。 當進階功能失敗時，包括重試策略、後援邏輯或更簡單的後援鏈結。
  • 迭代提示工程
    • 預期會隨著時間調整提示和鏈結邏輯。 將每次變更版本化（使用 Git 和 MLflow），以便您可以回溯或比較不同版本之間的效能。
    • 請考慮 DSPy 等架構，以程式設計方式優化代理程式系統中的提示和其他元件。

生產指導方針

  • 延遲與成本優化
    • 每個額外的 LLM 或工具呼叫都會增加令牌使用量和回應時間。 可能的話，請結合步驟或快取重複的查詢，以保持效能和成本在可控範圍內。
  • 安全性和沙盒化
    • 如果您的代理程式可以更新記錄或執行程式碼，請對這些動作進行沙盒化，或在必要時強制執行人工核准。 這在企業或受管制的環境中非常重要，以避免意外的傷害。
    • Databricks 建議使用 Unity 目錄工具進行沙箱化執行。 請參閱 選擇您的工具方法。 Unity 目錄可隔離任意程式代碼執行，並防止惡意執行者欺騙代理程式產生和執行會干擾或竊聽其他要求的程式代碼。

遵循這些指導方針，您可以降低許多最常見的失敗模式，例如工具呼叫錯誤、漂移 LLM 效能或非預期的成本尖峰，以及建置更可靠、可調整的代理程序系統。

  • Last updated on