調整並擴展 AI 代理以進行部署

  • 8 分鐘

前一個單元的實作模式會套用到你所建置的每個代理。 然而，不同情境會帶來不同的需求。 面向客戶的客服人員需要對話式的技巧與隱私控制，而內部營運的客服則要求可靠性與合規性。 本單元探討如何調整代理的配置與行為，以適應這兩類部署。

面向客戶的客服人員

直接與終端用戶互動的客服人員，如客服或銷售助理，需要特別重視對話品質、個人化與隱私。

對話品質

系統提示是你控制代理通訊方式的主要工具。 定義所需的語氣、風格與回應長度：

  • 語氣與風格：包含「以友善且專業的方式回應」或「使用簡單語言並避免專業術語」等指引。對支援人員來說，同理心的語氣很適合。 對銷售助理來說，較具資訊性的語氣可能更合適。
  • 釐清問題：指示客服在請求模糊時主動詢問，而非猜測。 例如：「如果使用者的請求不清楚，請在採取行動前先禮貌地提出澄清問題。」
  • 回覆長度：指導客服保持回應簡潔：「除非使用者要求更多細節，否則回應時間限制在三句以內。」

這些指引可以反覆修正。 測試對話流程與代理，並根據結果調整系統提示。

個人化與資料隱私

面向客戶的客服人員經常會存取個人資料，如訂單歷史和帳戶資料。 在個人化與隱私保護之間取得平衡：

  • 使用者情境注入：當會話開始時，透過系統提示或初始情境注入相關使用者資訊。 例如，包含用戶姓名、帳戶等級及近期訂單紀錄，讓客服人員能提供個人化服務。
  • 隱私說明：在系統提示中加入明確規則：「僅討論已登入使用者的帳號資料。 不要透露內部參考代碼或敏感系統資訊。」
  • 工具中的資料最小化：若工具擷取敏感資訊（如完整地址），工具處理器中過濾回應，只回傳代理人所需的資料（如運輸城市）。

知識整合

客服與銷售人員常需取得產品資訊、常見問題或政策文件，這些資料超出 AI 模型的訓練資料。 擷取擴增生成 (RAG) 模式可透過為代理程式提供搜尋工具來滿足此需求：

  • 定義一個像 search_knowledge_base(query) 這樣的工具，查詢你的文件或常見問題系統。
  • 透過系統提示指示客服在回答產品或政策問題時使用此工具。
  • 保持知識庫最新，避免過時的回應。

這種做法是讓代理人的回答建立在你的實際文件中，而非依賴模型的訓練資料，從而減少不準確的回應。

人工交接

即使是配置良好的客服人員，也會遇到無法解決的問題。 建立明確的升級路徑：

  • 提供 escalate_to_human(reason) 一個工具，將對話轉交給客服人員，並附上客服所蒐集的所有背景。
  • 當無法解決請求或使用者明確要求真人時，指示代理使用此工具。
  • 在初步部署時，考慮將客服回應經由人工審核隊列後再發送給客戶，以建立對客服品質的信心。

後台與自主代理

幕後運作的客服人員——如財務自動化、供應鏈管理或 IT 營運客服——優先考量可靠性、準確性及與企業系統的整合，而非對話品質。

決定論與驗證

在企業流程中，可預測的行為至關重要：

  • 結構化輸出：設計工具介面，使代理提供特定的欄位值，而非系統輸入的自由文字。 例如，讓代理將結構化參數傳給 create_journal_entry(account, amount, description) 工具，而不是以文字形式產生整個條目。
  • 程式碼計算：使用工具進行數學運算，而非依賴 AI 模型。 工具 calculate_tax(amount, rate) 能產生可靠的結果，而模型可能會產生算術錯誤。
  • 歷史驗證：部署前，將代理程式與已知的歷史資料比對，並將其決策與人類的行為做比較。 差異有助於你調整閾值和指示。

排程與觸發條件

與互動式客服不同，後勤客服通常是由事件或排程啟動，而非使用者輸入：

  • 排程任務：cron 工作或排程服務會建立 GitHub Copilot SDK 會話，提供上下文（例如「執行每日發票對帳」），並讓代理執行。
  • 事件驅動：監視警示或 webhook 會觸發工作階段建立，並將事件詳細資料作為輸入傳送。 每個事件通常會建立自己的工作階段，以避免內容混用。
  • 無狀態執行：在獨立的會話中處理每個任務或事件。 此方法避免了無關操作間的混淆。

企業系統整合

後勤人員與 API 和資料庫互動頻繁。 在您的工具處理常式中建立強韌性：

  • 重試與逾時：在呼叫外部系統的工具處理常式中實作具指數退避的重試邏輯。
  • 交易安全性：如果代理執行多個相關寫入，考慮使用單一工具，以原子性方式處理整個交易，而非每一個步驟分別使用獨立工具。
  • 最低權限存取：使用權限最低的服務帳號來呼叫代理的 API 呼叫。 這種做法限制了意外行為的影響。
  • 審計日誌：記錄代理所採取的每一個動作，包括呼叫了哪些工具、傳遞了哪些參數，以及回傳了哪些結果。 請包含一個標示此動作由代理發起的識別碼。

人工監督

自主代理程式仍應具備人工安全機制：

  • 警示：提供 notify_manager(issue) 一個工具，讓客服人員在遇到訓練外的情況或多次嘗試後問題仍存在時可用。
  • 定期審查：讓領域專家定期檢視代理人的決策，尤其是在早期部署期間。
  • 手動覆寫：實作功能旗標或模式切換，能快速將代理從自主執行切換為建議模式，記錄建議但不採取行動。

性能與成本考量

當代理程式頻繁運行或處理大量資料時，請考慮：

  • 模型選擇：用於日常任務使用更快且成本較低的模型，並保留較有能力的模型用於複雜推理。 SDK 允許你在每個工作階段設定模型。
  • 批次處理：若代理需要處理多件物品，請將工作框架設於單一會話中，而非為每個項目建立獨立會話。
  • 多代理樣式：對於複雜的工作流程，可以考慮將責任分配到多個具備不同配置與工具組的階段中。 一個代理可能負責分析，另一個代理負責執行，你的應用程式會在它們之間協調。

總結

調整您的 AI 代理以適應不同部署情境，需要調整其對話風格、工具組及操作模式以符合使用情境。 面向客戶的客服人員重視對話品質與個人化，同時維持隱私;而後勤客服則著重可靠性、整合性及自主運作。 在設計代理人時考量這些考量，能在任何情境下最大化其效能與商業價值。 在下一個單元中，你將看到如何實際使用 GitHub Copilot SDK 實作這些調整。