AI視頻剪輯工具：解鎖創作的無限可能
開發用于 CCAI 實現的 API 并非易事，可能面臨諸多挑戰，包括：
如果缺乏 API 平臺，實時轉換數據系統復雜性并高效轉發給調用者將非常困難。
通過 API 融入業務結構時，CCAI 的效果更佳。添加的功能越多（API 也越多），簡化 API 集成流程就越重要。需要整合重復性工作，驗證安全狀況，并實施優化，以確保良好的最終用戶體驗。
Apigee API Management 為更快、更輕松地實現這一目標鋪平道路。Apigee 是一個直觀的平臺，供機器人設計師和架構師將關鍵業務流程和見解融入工作流程。具體而言，Apigee 使 Dialogflow 能夠與后端系統對話。
Apigee 的內置策略可用于檢查 Dialogflow 請求、設置響應、驗證定義的參數以及實時觸發事件。例如，如果一次呼叫滿足定義的業務標準，Apigee 可以在 BigQuery 等數據倉庫中增強“360 度視圖”，將客戶添加到營銷活動列表中，或發送短信/文本提醒，所有這些都不會顯著影響路由時間。
通過將 CCAI 與 Apigee 配對，能夠充分利用 Google Cloud 轉換工具集，減少對話架構師集成 API 所需的時間，創建更具凝聚力的開發環境以解決呼叫中心挑戰。
以下是用于 Dialogflow CX API 實現的 Apigee API 開發的一些最佳實踐：
假設有一個 Dialogflow CX 虛擬代理，需要由 Apigee 提供的三個實現 API：
從技術上講，可以為每個 API 創建一個單獨的 Dialogflow CX Webhook，指向三個單獨的 API 代理。
然而，由于 Dialogflow 具有專有的請求和響應格式，為這些履行 API 創建三個單獨的 API 代理會產生三個非 RESTful 代理，除了 Dialogflow CX 虛擬代理外，其他客戶端難以使用這些代理。
相反，建議創建一個通用 Apigee API 代理，負責處理所有履行 API。Dialogflow CX 將只有一個 Webhook，配置為將請求發送到通用 Apigee API 代理。每個 Webhook 調用帶有一個唯一標識正確履行 API 的標簽。
Apigee 提供了兩個特定于 Dialogflow 的策略：ParseDialogflowRequest 和 SetDialogflowResponse。強烈建議盡可能使用這些策略。
這樣不僅遵循了優先選擇內置策略而非自定義代碼的一般最佳實踐，還確保 Dialogflow 請求和響應的解析與設置標準化、強化和高性能。
作為一般規則：
ParseDialogflowRequest 在 API 代理中僅需一次，并在身份驗證后放置在 PreFlow 中。SetDialogflowResponse 可用于每個不同的履行響應（即，每個唯一的 Webhook 標簽）。如果 SetDialogflowResponse 不滿足所有要求，可使用 AssignMessage 或 JavaScript 策略進行補充或替換。
應使用條件流來分離不同履行 API 的邏輯。實現此目的的最簡單方法是在 PreFlow 中放置 ParseDialogflowRequest 策略。添加該策略后，流變量 google.dialogflow.<Optional-prefix>.fulfillment.tag 將使用 Webhook 標簽的值填充。然后，該變量可用于定義請求進入特定條件流的條件。
以下是使用相同三個履行 API 的條件流示例：
Dialogflow CX Webhooks 有自己的請求和響應格式，不遵循 RESTful 約定（如 GET 用于讀取、POST 用于創建、PUT 用于更新等），這使得傳統客戶端難以使用為 Dialogflow CX 創建的 API 代理。
因此，建議使用代理鏈。通過代理鏈，可以將 API 代理分為兩類：Dialogflow 代理和資源代理。
代理鏈提供了一種重用代理的方法。然而，當調用從一個代理轉移到另一個代理時，可能會產生一些額外開銷。另一種方法是使用可重用共享流，開發明確設計為可重用的組件。共享流將策略和資源組合在一起，可抽象為共享庫，允許在多個位置使用的功能被捕獲。它們還使安全團隊能夠標準化可信系統連接的方法和規則，確保安全合規性，同時不影響創新速度。希望以這種方式連接的代理必須位于同一組織和環境中。
在創建聊天機器人或任何其他自然語言理解增強型應用程序時，響應延遲是一個重要指標。最大限度地減少延遲有助于保留用戶注意力，避免用戶懷疑機器人是否已損壞。
如果 Dialogflow 虛擬代理依賴的后端 API 響應時間較長，可通過預取數據并將其存儲在 Apigee 的緩存中提高性能。可以包含令牌和其他元信息，這些信息可能直接影響客戶輸入與 Dialogflow 返回提示之間的時間。Apigee 緩存是可編程的，提供更大靈活性，從而提升對話體驗。可使用 Response Cache（或 Populate Cache）結合 Service Callout 策略實現數據預取和緩存。
使用 SetDialogflowResponse 策略響應虛擬代理時，可通過 <Parameters> 元素一次返回多個值。該元素接受一個或多個子 <Parameter> 元素。如果可能，將單個參數作為 JSON 對象返回，通常比將響應分解為多個參數（每個參數包含單個字符串或數字）更有效。可通過 <JSONPath> 利用此策略。
推薦這種方法的原因：
如果 Webhook 服務遇到錯誤，Dialogflow CX 建議返回某些 4XX 和 5XX 狀態碼，以通知虛擬代理發生錯誤。每當 Dialogflow CX 收到這些類型的錯誤時，會調用 webhook.error 事件并繼續執行，而不向代理提供錯誤響應的內容。
然而，在某些情況下，履行 API 提供錯誤反饋是合理的，例如通知用戶電影不再可用或某個電影票無效。在這些情況下，考慮使用 200 HTTP 狀態碼進行響應，以提供關于錯誤是預期錯誤（如 404）還是意外錯誤（如 5XX）的上下文。
Apigee 的內置策略、細致入微的安全方法、共享流和緩存機制提供了更順暢的方式來實施有效的虛擬代理，從而為最終客戶提供快速響應。通過應用這些最佳實踐，Dialogflow 工程師能夠有更多時間進行創新，專注于構建更好的對話體驗，而無需集成后端系統。
原文鏈接：Apigee best practices for Contact Center AI
