Generative Playbooks：該用 Flow 還是 Playbook？

課程概述

課程裡常看到「Generative Playbooks」，現行文件多半直接寫 Playbooks。它是 Dialogflow CX（主控台名稱是 Conversational Agents）裡的生成式對話元件：不用把每一句話都綁成 Intent、Page 和 Route，而是提供目標、步驟、範例與工具，讓模型依當下對話決定下一步。

這不表示 Flow 已經過時。退款核准、付款、身分驗證這類有固定順序或法遵要求的流程，通常還是 Flow 比較穩；Playbook 比較適合需要理解語意、追問資訊和彈性說明的段落。實務上最常見的答案不是二選一，而是把兩者接在一起。

你將學到

• 分辨 Flow、Playbook 與混合式設計各自適合的情境
• 寫出可驗收的 Goal、Instructions、Examples 與 Parameters
• 讓工具呼叫有 Schema、權限、逾時和失敗退路
• 理解 Task Playbook 與 Routine Playbook 的用途
• 用評估案例確認改版後沒有把原本可用的對話弄壞

Flow 和 Playbook，不要用開發速度硬分

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

不要用「Flow 要做幾週、Playbook 只要幾天」這類固定數字做決策。Playbook 的畫面可能很快做出來，但例外情境、工具契約、評估集和上線護欄一樣要花時間。

一個 Playbook 真正包含哪些東西？

• Name：讓人和模型一看就知道這個 Playbook 負責什麼
• Goal：最後要完成的成果，不是空泛地寫「協助使用者」
• Instructions：正常步驟、條件、禁止事項和失敗處理
• Examples：幾段完整對話，包含工具怎麼呼叫、失敗時怎麼回應
• Parameters：跨對話步驟保存的結構化資料，以及呼叫前後要交接的欄位
• Tools：能查資料或執行動作的受控介面

現行 Playbook 有 Task 和 Routine 兩種。Task 適合可重用的子任務，透過輸入、輸出參數交接；Routine 適合一段接一段、各自完成的對話階段。新建生成式 Agent 時還會有 Default Playbook，作為對話入口。

Instructions 要像值班手冊，不像品牌標語

「親切地協助客戶」沒有告訴模型該做什麼。比較有用的寫法會交代：

1. 先確認使用者要查詢、取消還是修改訂單
2. 查詢前取得並驗證訂單編號，不要把姓名當成唯一識別
3. 只能讀取目前登入者的訂單，不能接受對話中臨時指定的帳號
4. 工具逾時時說明目前無法查詢，不要自行編一個狀態
5. 涉及退款金額或例外核准時轉到既有 Flow 或真人客服

Instructions 不必鉅細靡遺地模擬程式碼；固定條件真的很多時，應該交給 Flow 或 Code block。相反地，Playbook 要把力氣放在任務邊界與高品質 Examples。

工具不只三種，而且每一種都要有契約

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

Tool 的描述和 Schema 會直接影響模型怎麼選工具，但後端仍要自己驗證身分、參數和權限。描述寫得再漂亮，也不能取代 API 端的 Allowlist、逾時、冪等與稽核。

%%{init: {"flowchart": {"curve": "linear", "nodeSpacing": 20, "rankSpacing": 28, "wrappingWidth": 600}}}%%
flowchart TB
  subgraph ROUTE_STAGE["1. 選擇控制方式"]
      direction TB
      START["先寫成功條件、必要資料<br/>允許動作與失敗退路"] --> FIXED{"順序或核准條件<br/>能由規則明確寫出嗎？"}
      FIXED -->|"可以"| FLOW["用 Flow<br/>或 Code block<br/>保留確定性控制"]
      FIXED -->|"不完全可以"| SEMANTIC{"真的需要語意理解<br/>追問或動態選路嗎？"}
      SEMANTIC -->|"不需要"| SIMPLE["簡化成較小的 Flow"]
      SEMANTIC -->|"需要"| PLAYBOOK["建立邊界清楚的<br/>Playbook"]
  end
  PLAYBOOK --> ACTION
  subgraph TOOL_STAGE["2. 補上工具契約與範例"]
      direction TB
      ACTION{"會讀企業資料<br/>或執行外部動作嗎？"} -->|"不會"| EXAMPLE["補正常、拒絕、澄清<br/>取消與升級 Examples"]
      ACTION -->|"會"| TOOL["定義 Schema、<br/>最小權限<br/>逾時、冪等與人工核准"]
      TOOL --> EXAMPLE
  end
  FLOW --> EVAL
  SIMPLE --> EVAL
  EXAMPLE --> EVAL
  subgraph RELEASE_STAGE["3. 評估後才上線"]
      direction TB
      EVAL["端到端評估狀態、Tool<br/>最終回應與失敗退路"] --> GATE{"成功率、安全和延遲<br/>是否都達標？"}
      GATE -->|"否"| REVISE["縮小範圍或修改設計<br/>再重新評估"]
      GATE -->|"是"| SHIP["小流量上線<br/>監控並保留人工轉接"]
  end

實作重點

• 每個 Playbook 至少準備一個 Example；正式上線通常需要正常、模糊、工具失敗、取消與越界等多種案例
• Example 要檢查自動產生的 Action，不能因為模擬器跑完就直接存下來
• 測試 Tool 時同時測成功、空結果、錯誤格式、逾時與重複提交
• 模擬器能看到 Playbook invocation、Action 和 Tool 輸入輸出，但不要宣稱能看到模型完整的內部推理
• 使用內建 evaluations 比對不同環境與版本，避免改 Instructions 後出現對話回歸
• Playbooks 目前不在 Dialogflow CX SLA 內；正式採用前要確認這項限制符合服務等級需求

課程導讀

課程連結：Create Agents with Generative Playbooks — Google Skills

課程頁目前沒有列出動手 Lab，內容是線上教材與測驗：Playbook 的概念與使用情境、建立與設定（Goal、Instructions、Tools、Parameters、Examples、Conditional actions、Code blocks、多個 Playbook 與搭配 Flow 的混合式 Agent），以及測試、部署與最佳化，最後有一個 generative steering 案例。想動手的話，可以照官方的 Playbook 快速入門建一個小 Agent：不要只看「有沒有回答」，請記錄每次 Playbook 切換、Parameter 交接和 Tool Action；再故意讓工具回傳空資料或錯誤，確認 Agent 會說不知道、要求補資料或轉人工，而不是自己補一個答案。

延伸學習

• Data Store Agent 虛擬 FAQ — 準備 Playbook 使用的企業知識
• Agent Assist 與 GenAI — 把生成式能力接進真人客服流程
• 部署多代理系統 — 比較 Playbook 委派與程式化多代理協作
• Playbooks 官方文件 — 確認類型、模型、地區與目前限制