Dialogflow CX 教學：從入門到進階完整攻略

Dialogflow CX 是 Google 專為企業級對話機器人設計的平台。如果你需要處理複雜的多輪對話、多人協作開發、或是嚴謹的版本控制，CX 是比 ES 更好的選擇。

但 CX 的學習曲線比 ES 陡峭。Flow、Page、Route...這些新概念可能讓人一開始有點迷惑。這篇文章從零開始，帶你完整掌握 Dialogflow CX 的核心功能和進階技巧。

如果你還在猶豫該選 CX 還是 ES，可以先參考 Dialogflow CX vs ES 完整比較。想了解 Dialogflow 基礎概念，請參考 Dialogflow 完整指南。

---

CX Console 操作入門

介面導覽

進入 Conversational Agents Console，你會看到和 ES 完全不同的介面。

主要區域：

CX vs ES 介面差異：

建立第一個 Agent

1. 進入 Conversational Agents Console
2. 點擊「Create agent」>「Build your own」
3. 填寫基本資訊：
   • Display name：Agent 名稱（如：my-cx-agent）
   • Location：asia-northeast1（日本，延遲較低）
   • Time zone：Asia/Taipei
   • Default language：Chinese (Traditional)
   • Conversation start：Flow
4. 點擊「Create」

建立完成後，系統會自動建立一個「Default Start Flow」，這是對話的起點。

測試面板使用

CX 的測試面板功能比 ES 強大許多。

基本測試：

1. 點擊右下角的「Test Agent」按鈕
2. 輸入訊息測試對話
3. 觀察回覆和觸發的 Intent

進階功能：

• Environment 選擇：可以測試不同環境的版本
• Session 參數：查看和修改當前 Session 的參數
• Page 追蹤：即時顯示目前在哪個 Page
• Intent 偵測結果：顯示偵測到的 Intent 和信心分數

---

Flow（流程）設計

Flow 是 CX 最核心的概念，也是它跟 ES 最大的差異。

什麼是 Flow

Flow = 一個獨立的對話主題

把 Flow 想像成一本書的「章節」。每個 Flow 處理一個特定的業務場景：

• 訂位 Flow：處理所有訂位相關對話
• 查詢 Flow：處理訂單查詢、狀態追蹤
• 客訴 Flow：處理投訴、退換貨

Flow 的組成：

• Pages：Flow 中的各個狀態（對話節點）
• Routes：Page 之間的轉換條件
• Start Page：Flow 的起始 Page

預設 Flow：

• Default Start Flow：Agent 的入口點，所有對話從這裡開始
• 可以建立多個自訂 Flow

視覺化編輯器操作

CX 的視覺化編輯器讓複雜對話變得直覺。

建立新 Flow：

1. 點擊左側「Flows」區塊的「+」
2. 輸入 Flow 名稱（如：Booking）
3. 點擊「Create」

在 Flow 中建立 Page：

1. 在流程圖空白處點擊右鍵
2. 選擇「Add Page」
3. 輸入 Page 名稱（如：Ask Date）

連接 Page：

1. 點擊起始 Page
2. 點擊右側出現的「+」圖示
3. 拖曳到目標 Page
4. 設定轉換條件（Route）

多 Flow 架構設計

大型專案建議用多 Flow 架構，好處是：

1. 模組化：每個業務邏輯獨立開發
2. 團隊協作：不同人負責不同 Flow
3. 維護容易：改一個 Flow 不影響其他

範例架構：餐廳機器人

Default Start Flow
    │
    ├─→ Booking Flow（訂位）
    │       ├── Ask Date
    │       ├── Ask Time
    │       ├── Ask Party Size
    │       └── Confirm
    │
    ├─→ Menu Flow（菜單查詢）
    │       ├── Category Selection
    │       └── Item Details
    │
    ├─→ Order Flow（外送訂餐）
    │       ├── Add Items
    │       ├── Review Cart
    │       └── Checkout
    │
    └─→ Support Flow（客服）
            ├── FAQ
            └── Transfer to Human

Flow 切換：

• 在 Route 中可以設定「Transition to flow」
• 使用者說「我要訂位」→ 切換到 Booking Flow
• 使用者說「看菜單」→ 切換到 Menu Flow

---

流程設計卡關？多 Flow 架構的規劃需要經驗，設計不好後面會很痛苦。預約架構諮詢，讓有經驗的人幫你把架構設計對。

---

Page 與 State 管理

Page 是 Flow 中的「狀態」，代表對話的某個階段。

Page 的組成

每個 Page 包含：

Parameter 收集

CX 的 Parameter 收集比 ES 的 Slot Filling 更強大。

設定 Parameter：

1. 在 Page 中點擊「Parameters」
2. 點擊「+ Add parameter」
3. 設定：
   • Parameter name：參數名稱（如：date）
   • Entity type：實體類型（如：@sys.date）
   • Required：是否必填

自動提問：

如果參數是 Required，CX 會自動提問直到收集到為止。

設定：
- Parameter: date
- Entity: @sys.date
- Required: Yes
- Prompt: 「請問用餐日期是哪一天？」

對話：
Bot: 請問用餐日期是哪一天？
User: 明天
Bot: [收集到 date = 2025-01-16]

Route 條件設計

Route 定義什麼時候離開當前 Page。

Route 類型：

條件範例：

// 所有必填參數都收集完成
$page.params.status = "FINAL"

// 特定參數有值
$session.params.date != null

// 數值判斷
$session.params.party_size > 10

Route 優先順序：

1. Intent routes（最高優先）
2. Condition routes
3. Event handlers

---

Route 與條件設計

Route 是 CX 流程控制的核心，需要好好理解。

Intent Routes

當使用者說的話符合某個 Intent，就會觸發對應的 Route。

範例：

當前 Page: Booking.AskDate

Intent Route:
- Intent: cancel_booking
- Transition: End Flow
- Response: 「好的，已取消訂位。」

效果：
User: 「不訂了」
Bot: 「好的，已取消訂位。」[結束 Booking Flow]

Condition Routes

根據參數值或狀態判斷，不需要使用者說話也能觸發。

範例：大桌訂位需要特殊處理

Condition: $session.params.party_size > 10
Transition: Booking.LargePartyConfirm
Response: 「10 位以上訂位需要預付訂金，我為您轉接專人處理。」

Event Handlers

處理特殊事件，確保對話不會卡住。

常用 Event：

設定 Event Handler：

1. 在 Page 中點擊「Event handlers」
2. 選擇要處理的 Event
3. 設定回應或轉換

---

Webhook 進階開發

Webhook（也叫 Fulfillment）讓 CX 能呼叫外部 API，實現動態回覆。

Fulfillment 設定

建立 Webhook：

1. 點擊左側「Manage」>「Webhooks」
2. 點擊「Create」
3. 設定：
   • Display name：Webhook 名稱
   • Webhook URL：你的 API 端點
   • Timeout：逾時時間（建議 5-10 秒）

在 Page 中使用：

• Entry Fulfillment 可以勾選「Enable webhook」
• Route 的 Fulfillment 也可以啟用 Webhook

Cloud Functions 整合

Cloud Run functions（原 Google Cloud Functions）是最方便的 Webhook 部署方式。

建立 Cloud Function：

1. 前往 Google Cloud Console > Cloud Run
2. 點擊「Write a function」
3. 設定：
   • Service name：dialogflow-cx-webhook
   • Region：與 Agent 相同 Region
   • Trigger：HTTP
   • Authentication：Allow public access（或 Require authentication 搭配服務帳戶）

基本程式碼（Node.js）：

exports.cxWebhook = (req, res) => {
  const tag = req.body.fulfillmentInfo?.tag;
  const params = req.body.sessionInfo?.parameters;

  let response = {};

  switch (tag) {
    case 'check-availability':
      response = checkAvailability(params);
      break;
    case 'confirm-booking':
      response = confirmBooking(params);
      break;
    default:
      response = { fulfillmentResponse: { messages: [] } };
  }

  res.json(response);
};

function checkAvailability(params) {
  const { date, time, party_size } = params;

  // 這裡呼叫你的訂位系統 API
  const available = checkYourSystem(date, time, party_size);

  return {
    fulfillmentResponse: {
      messages: [
        {
          text: {
            text: [available
              ? `${date} ${time} 有空位，請問訂位大名？`
              : `抱歉，${date} ${time} 已滿，請選擇其他時段。`
            ]
          }
        }
      ]
    },
    sessionInfo: {
      parameters: {
        availability_checked: true,
        is_available: available
      }
    }
  };
}

Request/Response 格式

CX Webhook Request：

{
  "detectIntentResponseId": "xxx",
  "intentInfo": {
    "lastMatchedIntent": "projects/.../intents/xxx",
    "displayName": "make_booking",
    "confidence": 0.95
  },
  "pageInfo": {
    "currentPage": "projects/.../pages/xxx",
    "displayName": "Confirm Booking"
  },
  "sessionInfo": {
    "session": "projects/.../sessions/xxx",
    "parameters": {
      "date": "2025-01-20",
      "time": "19:00",
      "party_size": 4
    }
  },
  "fulfillmentInfo": {
    "tag": "confirm-booking"
  }
}

CX Webhook Response：

{
  "fulfillmentResponse": {
    "messages": [
      {
        "text": {
          "text": ["訂位完成！"]
        }
      }
    ]
  },
  "sessionInfo": {
    "parameters": {
      "booking_id": "B12345"
    }
  },
  "targetPage": "projects/.../pages/end-page"
}

錯誤處理

Webhook 可能的錯誤：

設定 Fallback：

1. 在 Page 的 Event handlers 中
2. 加入 webhook.error 處理
3. 設定替代回應：「系統暫時忙碌，請稍後再試」

更多 Webhook 開發細節，請參考 Dialogflow Fulfillment 與 API 整合教學。

---

RAG 整合（知識庫問答）

CX 支援 Data Store 整合，可以實現基於知識庫的生成式問答（RAG）。

Data Store 設定

建立 Data Store：

1. 前往 Google Cloud Console > AI Applications
2. 點擊「Create Data Store」
3. 選擇資料來源：
   • Website：爬取網站內容
   • Unstructured documents：上傳 PDF、Word 等
   • Structured data：CSV、JSON 等

範例：匯入公司 FAQ 網站

1. 選擇「Website」
2. 輸入網站 URL（如：https://example.com/faq）
3. 設定爬取深度
4. 點擊「Create」
5. 等待索引建立完成（可能需要數小時）

生成式回答配置

在 CX Agent 中啟用：

1. 在左側選單點「Tools」>「+ Create」，Type 選「Data store」
2. 點「Add data stores」選擇剛建立的 Data Store
3. 在 Route 的 Fulfillment > Data store tool 選用這個工具

設定 Fallback 行為：

當一般 Intent 都沒有匹配時，CX 會從 Data Store 搜尋相關資訊，用生成式 AI 組合回答。

範例對話：

User: 你們的退貨政策是什麼？
[Data Store 搜尋到退貨相關頁面]
Bot: 根據我們的政策，商品在購買後 7 天內可以無條件退貨。
     退貨時請保持商品完整包裝，並攜帶購買憑證。
     如需退貨，請前往任一門市或聯繫客服專線 02-1234-5678。

品質調校技巧

1. 調整搜尋範圍

如果回答太發散，可以限制 Data Store 的範圍：

• 只索引特定網頁
• 為文件加上 metadata 分類

2. 設定 Grounding

Grounding 讓 AI 只能根據知識庫內容回答，避免「幻覺」。

設定：
- Grounding: Required
- No match behavior: 「抱歉，我找不到相關資訊，請聯繫客服。」

3. 監控品質

定期檢視對話記錄：

• 回答是否正確
• 是否有不適當的內容
• 使用者是否滿意

---

想用 RAG 打造智慧客服？RAG 的效果取決於知識庫品質和配置。預約 AI 導入諮詢，讓我們幫你設計最佳方案。

---

版本控制與發布

CX 內建完整的版本控制系統，這是企業開發必備的功能。

Version 管理

建立 Version：

1. 進入 Flow
2. 點擊右上角「Versions」
3. 點擊「Create version」
4. 輸入版本描述（如：v1.0 - 基本訂位功能）

Version 用途：

• 保存開發里程碑
• 出問題時可以回滾
• 比較不同版本的差異

Environment 管理

Environment 讓你區分開發、測試、正式環境。

預設 Environment：

• Draft：開發中的最新版本
• Production：對外服務的版本（需要自行建立）

建立 Environment：

1. 點擊左側「Manage」>「Environments」
2. 點擊「Create」
3. 設定：
   • Display name：環境名稱（如：production）
   • Flow versions：選擇各 Flow 要使用的版本

發布流程：

1. 在 Draft 環境開發和測試
2. 功能確認後，為各 Flow 建立 Version
3. 將 Production 環境指向新的 Version
4. 對外服務不中斷更新

Traffic Split（A/B 測試）

可以將流量分配到不同版本，測試哪個設計效果更好。

設定方式：

1. 在「Experiments」中建立實驗並選擇 Environment
2. 為同一個 Flow 指定對照版本與變體版本
3. 設定流量比例（如：80% v1.0、20% v1.1）

應用場景：

• 測試新的對話流程
• 比較不同的回應文案
• 驗證 RAG 效果

---

實戰專案：客服 FAQ 機器人

來做一個完整的實戰專案，整合前面學到的所有概念。

專案目標

建立一個能回答以下問題的客服機器人：

• 營業時間查詢
• 訂單狀態查詢（需要 Webhook）
• FAQ 自動回答（用 RAG）
• 真人客服轉接

架構設計

Default Start Flow
    │
    ├─ [Intent: ask_hours] → 回覆營業時間
    │
    ├─ [Intent: check_order] → Order Status Flow
    │       ├── Ask Order ID（收集訂單號）
    │       └── Show Status（呼叫 API 查詢）
    │
    ├─ [Intent: transfer_human] → 轉接真人
    │
    └─ [No match] → RAG 知識庫搜尋

實作步驟

Step 1：建立 Intent

• ask_hours：「營業時間」、「幾點開門」、「週末有開嗎」
• check_order：「查訂單」、「訂單狀態」、「我的訂單到哪了」
• transfer_human：「轉客服」、「找真人」、「我要投訴」

Step 2：設定 Start Flow Routes

在 Default Start Flow 的 Start Page 加入：

• ask_hours → 直接回覆營業時間
• check_order → Transition to Order Status Flow
• transfer_human → 回覆轉接訊息

Step 3：建立 Order Status Flow

1. 建立 Flow：Order Status
2. Start Page：設定 Entry Fulfillment「請提供您的訂單編號」
3. 建立 Page：Ask Order ID
   • Parameter：order_id（Required）
   • Prompt：「請輸入訂單編號，格式為英文字母加數字」
4. 建立 Route：當 order_id 收集完成
   • Enable Webhook（tag: check-order-status）
   • Transition to: Show Status Page

Step 4：設定 RAG Fallback

1. 建立 Data store tool
2. 加入公司 FAQ 的 Data Store
3. 設定 No match 時使用知識庫回答

了解更詳細的 Intent 設計，請參考 Dialogflow Intent 與 Context 完整教學。費用估算請參考 Dialogflow 費用完整解析。

---

下一步

學完這篇教學，你已經掌握 Dialogflow CX 的核心功能。接下來可以：

1. 深入對話設計：Dialogflow Intent 與 Context 完整教學
2. 開發後端整合：Dialogflow Fulfillment 與 API 整合教學
3. 了解費用：Dialogflow 費用完整解析
4. 整合 LINE：Dialogflow LINE Bot 串接教學

---

Dialogflow CX 架構需要建議？

好的架構設計能讓維護成本降低一半，反之則可能讓專案變成難以維護的「義大利麵」。

如果你正在：

• 規劃複雜的對話機器人架構
• 考慮從 ES 遷移到 CX
• 需要多人協作開發的 Flow 設計
• 想導入 RAG 但不確定效果

預約架構諮詢，讓有經驗的人幫你設計可擴展、易維護的架構。

諮詢完全免費，我們會在 24 小時內回覆。