本文件說明使用 Conversational Agents (Dialogflow CX) 流程建構服務專員的基本概念。概略說明最重要的概念。
代理程式
Conversational Agents (Dialogflow CX) 代理程式是虛擬服務專員，可處理與使用者的並行對話。這種自然語言理解模組可以解讀人類語言的細微差異。Conversational Agents (Dialogflow CX) 會將使用者在對話期間提供的文字或音訊內容轉譯為應用程式與服務可以解讀的結構化資料。您可以設計並建構 Conversational Agents (Dialogflow CX) 服務專員，處理系統所需的對話類型。
Conversational Agents (Dialogflow CX) 代理程式與客服中心的真人客服專員類似，您可以訓練代理程式和客服專員來處理預期的對話情境，而且訓練內容不必過於明確。
流量數
複雜的對話通常涉及多個對話主題。舉例來說，披薩外送服務代理商可能會將「餐點訂單」、「客戶資訊」和「確認」設為不同的主題。每個主題都需要多個對話回合，才能讓服務專員從使用者身上取得相關資訊。
流程可用於定義這些主題和相關的對話路徑。每個服務專員都有一個名為「預設啟動流程」的流程。這個單一流程可能就是簡單介面的全部需求。較複雜的介面可能需要額外的流程，而不同的開發團隊成員可負責建立及維護這些流程。舉例來說，披薩外送服務代理程式的流程可能如下所示：
頁面
您可以將 Conversational Agents (Dialogflow CX) 對話 (工作階段) 描述為狀態機器人，並以圖形呈現。工作階段的狀態會以頁面表示。
您會為每個流程定義多個頁面，這些頁面組合可處理流程所設計主題的完整對話。在任何時間點，只有一個頁面是「目前的頁面」，且系統會將目前的頁面視為「有效」，與該頁面相關聯的流程也視為「有效」。每個流程都有專屬的起始頁面。當流程首次啟用時，開始頁面會成為目前的頁面。對於每個對話輪次，目前的頁面會維持不變，或轉換至其他頁面。
您可以設定每個網頁，從使用者收集與網頁所代表對話狀態相關的資訊。舉例來說，您可以為披薩外送服務代理程式的「Food Order」流程建立下方圖表中的頁面 (以藍色標示)。圖表的「Start」節點代表「Food Order」流程的起始頁面。流程完成後，系統會轉換至「確認」流程。
實體類型
實體類型可用於控制從使用者輸入內容中擷取資料的方式。Conversational Agents (Dialogflow CX) 提供預先定義的系統實體，可以比對許多常見的資料類型。舉例來說，您可以使用系統實體來比對日期、時間、顏色、電子郵件地址等。您也可以自行建立自訂實體，用於比對自訂資料。舉例來說，您可以定義蔬菜實體，以便比對可在日用品商店代理程式中購買的蔬菜種類。
參數
參數可用於擷取及參照使用者在工作階段期間提供的值。每個參數都有名稱和實體類型。不同於使用者輸入的原始內容，參數是結構化資料，可輕鬆用於執行某些邏輯或產生回應。表單
您可以為每個網頁定義表單，也就是從網頁的使用者收集的參數清單。代理程式會與使用者進行多次對話，直到收集到所有必要的表單參數 (也稱為頁面參數) 為止。代理程式會按照頁面上定義的順序收集這些參數。針對每個必要表單參數，您也必須提供提示，讓代理程式用於向使用者索取該資訊。這個過程稱為「表單填充」。
舉例來說，您可以建立表單，收集 Collect Customer Info 頁面上終端使用者的姓名和電話號碼。
意圖
意圖：將使用者在一個對話回合中的意圖歸類。
意圖包含下列資料：
| 字詞 | 定義 |
|---|---|
| 顯示名稱 | 意圖在主控台中顯示的名稱。 |
| 標籤 | 有助於將意圖分類的標籤。例如：head intent。 |
| 訓練詞組 | 訓練詞組是指使用者可能會輸入或說出的字詞範例 (亦稱為使用者輸入內容)。如果使用者輸入內容與其中一個詞組相近，Conversational Agents (Dialogflow CX) 就會將其視為與意圖相符。您無須定義所有可能的範例，因為 Conversational Agents (Dialogflow CX) 內建的機器學習技術會依據其他類似的詞組擴充清單。 |
| 參數 | 您可以定義要使用的訓練詞組，以參數擷取使用者輸入內容的特定部分。 |
| DTMF 模式 | 請參閱「電話整合的 DTMF」。 |
Webhook
Webhook 是託管業務邏輯或呼叫其他服務的服務。在工作階段期間，您可以使用 webhook 擷取對話型代理程式 (Dialogflow CX) 自然語言處理程序擷取的資料，產生動態回應、驗證所收集的資料，或在後端觸發動作。快訊可以是標準快訊或彈性快訊。使用標準 webhook 時，要求和回應欄位是由 Conversational Agents (Dialogflow CX) 定義。您可以使用彈性 Webhook 定義要求和回應欄位。
Fulfillment
在代理程式的對話輪次中，代理程式必須向使用者回應問題的答案、資訊查詢或工作階段結束。代理程式也可能需要與您的服務聯絡，以產生動態回應或採取轉換動作。Fulfillment 可用於完成所有這些工作。
滿足條件可能包含下列任一項：
- 靜態回應訊息。
- Webhook 會呼叫動態回應和/或採取動作。
- 用於設定或覆寫參數值的參數預設值。
在服務機器人的回合中，可以 (有時也建議) 呼叫多個執行結果，每個執行結果都可能產生回應訊息。Conversational Agents (Dialogflow CX) 會在回應佇列中保留這些回應。服務專員的回應結束後，Conversational Agents (Dialogflow CX) 會將排序後的回覆傳送給使用者。
狀態處理常式
狀態處理常式 (也稱為 處理常式) 可用於為使用者建立回應，並/或轉換目前的頁面，以便控制對話。系統會針對每個對話輪次評估處理程序，並可能影響會話。處理常見的資料類型有三種：| 字詞 | 定義 |
|---|---|
| 處理常規需求 | 這些是處理程序必須滿足的必要條件，才能對工作階段產生任何影響。當處理程序滿足其需求並以某種方式影響工作階段時，就會呼叫。 |
| 處理常式履行 | 如果呼叫處理常式，系統會使用選用的執行要求為使用者建立回應。這些回應是在靜態代理程式資料中定義，或從Webhook 服務動態擷取。 |
| 處理常規轉換目標 | 如果呼叫處理常式，系統會使用選用的轉場目標來變更目前的頁面。下一頁只能是流程開始頁面，或目前有效流程中的頁面。 |
狀態處理常式分為兩種，分別有不同的處理常式需求：
| 字詞 | 定義 |
|---|---|
| 路線 | 當使用者輸入內容符合意圖和/或符合工作階段狀態的某些條件時，系統就會呼叫路由。含有意圖需求的路徑也稱為意圖路徑。只有條件規定的路徑也稱為條件路徑。 |
| 事件處理常式 | 在叫用事件時，系統會呼叫事件處理常式。收到非預期的使用者輸入內容，或發生 webhook 錯誤時，系統會觸發部分內建事件。您也可以定義自訂事件，在對話之外發生事件時叫用。 |
處理狀態處理常式的步驟有三個：
| 字詞 | 定義 |
|---|---|
| 1. 範圍 | 處理常式必須位於範圍中，才能對工作階段產生影響。範圍取決於處理常式是否套用至流程、頁面或表單參數；以及相關聯的流程是否處於活動狀態、相關聯的頁面是否處於活動狀態，或服務台人員目前是否嘗試填入相關聯的表單參數。 |
| 2. 評估 | 系統會依序評估範圍內的每個處理常式。如果處理常式符合規定，就會通過評估。 |
| 3. 撥打電話 | 如果處理常式在範圍內且通過評估，系統就會呼叫該處理常式。系統會呼叫任何相關的執行作業，並將任何相關的轉換目標套用至工作階段。 |
區域規劃與位置設定
建立代理程式時，您必須指定區域做為代理程式的所在位置。傳送至服務專員的請求會由該區域的 Google 服務處理，而對話式服務專員 (Dialogflow CX) 會將靜態資料實際保留在地理區域或位置中。為獲得最佳效能，請選擇鄰近服務和使用者的區域。
建立代理人後，就無法變更其位置。如要變更代理人的所在位置，您必須匯出並還原至具有不同位置的新代理人。
每個位置都會套用相關聯的設定。在大多數情況下，您不需要編輯這些位置設定，預設設定即可正常運作。如果您的系統需要客戶管理的加密金鑰 (政府機構或受管制產業通常會要求使用這類金鑰)，請進一步瞭解位置設定。
控制台
Conversational Agents (Dialogflow CX) 提供名為「Dialogflow CX 主控台」的網頁版使用者介面 (參閱說明文件，開啟主控台)。您可以使用這個主控台來建立、建構及測試代理程式。它會將每個流程繪製為對話狀態機器圖表，讓您輕鬆設計及瞭解複雜的服務機器人。
Dialogflow CX 主控台與 Google Cloud 主控台不同 (參閱說明文件、開啟主控台)。Dialogflow CX 主控台用於管理 Conversational Agents (Dialogflow CX) 代理程式， Google Cloud 主控台則用於管理 Google Cloud專屬的 Conversational Agents (Dialogflow CX) 設定 (例如計費) 和其他 Google Cloud 資源。
在大多數情況下，您應使用 Dialogflow CX 主控台建構代理程式，但在進階情況下，您也可以使用 Dialogflow API 建構代理程式。
整合
Conversational Agents (Dialogflow CX) 提供多種內建整合，可與其他對話平台整合。這些整合服務會為使用者提供使用者介面，並為您呼叫 API。您只需建立代理程式，並視需要實作webhook 服務。每項整合都會以特定平台的方式處理互動，因此請參閱特定整合說明文件瞭解詳情。
互動
每個會話回合都會發生互動。在互動期間，使用者會將輸入內容傳送至 Conversational Agents (Dialogflow CX)，而 Conversational Agents (Dialogflow CX) 會傳送回應。實作系統以處理互動時，您有兩種選擇：使用 API 或整合。
使用 API 時，系統需要處理下列項目：
- 建構代理程式。
- 為使用者提供使用者介面。
- 針對每個對話回合呼叫 Dialogflow API，將使用者輸入內容傳送至 API。
- 除非您的對話方回應完全是靜態的 (不常見)，否則您需要代管Webhook 服務，才能處理支援 Webhook 的執行要求。
使用整合時，您的系統只需處理下列項目：
- 建構代理程式。
- 視需要實作 Webhook 服務。
下圖顯示會話輪次的一個會話回合所需的步驟。
- 使用者輸入或說出內容，稱為「使用者輸入內容」。
- 使用者介面或整合系統會接收輸入內容，並在偵測意圖要求中轉送至 Dialogflow API。
- Dialogflow API 會收到偵測意圖要求。它會將輸入內容比對至意圖或表單參數，視需要設定參數，並更新工作階段狀態。如果需要呼叫支援 Webhook 的執行要求，系統會將 Webhook 要求傳送至 Webhook 服務，否則請前往步驟 6。
- 您的 Webhook 服務會收到 Webhook 要求。您的服務會採取任何必要動作，例如呼叫外部 API、查詢或更新資料庫等。
- Webhook 服務會建構回應，並將 Webhook 回應傳回至 Conversational Agents (Dialogflow CX)。
- Conversational Agents (Dialogflow CX) 會建立檢測意圖回應。如果呼叫 Webhook，則會使用 Webhook 回應中提供的回應。如果未呼叫 webhook，系統會使用在代理程式中定義的靜態回應。Conversational Agents (Dialogflow CX) 會將偵測意圖回應傳送至使用者介面或整合系統。
- 您的使用者介面或整合系統會收到意圖偵測回應，並將文字或音訊回應轉寄給使用者。
- 使用者看到或聽到回應。