Generative Playbooks：該用 Flow 還是 Playbook？
課程概述
課程裡常看到「Generative Playbooks」，現行文件多半直接寫 Playbooks。它是 Conversational Agents 裡的生成式對話元件：不用把每一句話都綁成 Intent、Page 和 Route，而是提供目標、步驟、範例與工具，讓模型依當下對話決定下一步。
這不表示 Flow 已經過時。退款核准、付款、身分驗證這類有固定順序或法遵要求的流程，通常還是 Flow 比較穩；Playbook 比較適合需要理解語意、追問資訊和彈性說明的段落。實務上最常見的答案不是二選一，而是把兩者接在一起。
Flow 預先列出路徑，結果比較可預測；Playbook 讓模型依上下文選路，彈性比較高，也更需要清楚的任務邊界、工具權限、失敗處理和人工轉接。
你將學到
- 分辨 Flow、Playbook 與混合式設計各自適合的情境
- 寫出可驗收的 Goal、Instructions、Examples 與 Parameters
- 讓工具呼叫有 Schema、權限、逾時和失敗退路
- 理解 Task Playbook 與 Routine Playbook 的用途
- 用評估案例確認改版後沒有把原本可用的對話弄壞
Flow 和 Playbook，不要用開發速度硬分
| 面向 | Flow | Playbook |
|---|---|---|
| 怎麼決定下一步 | Intent、條件與 Route | 模型根據目標、指令、範例和上下文選擇 |
| 可預測性 | 高，路徑能逐條檢查 | 較低，同一句話可能因上下文走不同路 |
| 適合場景 | 身分驗證、付款、核准、固定表單 | 開放式問答、需求釐清、彈性說明 |
| 主要風險 | 分支太多、維護成本上升 | 越界、工具選錯、漏問必要資訊 |
| 能不能混用 | 可以呼叫 Playbook | 可以轉交 Flow 或其他 Playbook |
不要用「Flow 要做幾週、Playbook 只要幾天」這類固定數字做決策。Playbook 的畫面可能很快做出來，但例外情境、工具契約、評估集和上線護欄一樣要花時間。
付款、授權和核准留在確定性流程；需求釐清與一般說明交給 Playbook；知識問題由 Data Store Tool 提供來源。低信心、越權或工具失敗時，三條路都要有一致的退場方式。
一個 Playbook 真正包含哪些東西？
- Name：讓人和模型一看就知道這個 Playbook 負責什麼
- Goal：最後要完成的成果，不是空泛地寫「協助使用者」
- Instructions：正常步驟、條件、禁止事項和失敗處理
- Examples：幾段完整對話，包含工具怎麼呼叫、失敗時怎麼回應
- Parameters：跨對話步驟保存的結構化資料，以及呼叫前後要交接的欄位
- Tools：能查資料或執行動作的受控介面
現行 Playbook 有 Task 和 Routine 兩種。Task 適合可重用的子任務，透過輸入、輸出參數交接；Routine 適合一段接一段、各自完成的對話階段。新建生成式 Agent 時還會有 Default Playbook，作為對話入口。
Instructions 要像值班手冊，不像品牌標語
「親切地協助客戶」沒有告訴模型該做什麼。比較有用的寫法會交代：
- 先確認使用者要查詢、取消還是修改訂單
- 查詢前取得並驗證訂單編號，不要把姓名當成唯一識別
- 只能讀取目前登入者的訂單，不能接受對話中臨時指定的帳號
- 工具逾時時說明目前無法查詢，不要自行編一個狀態
- 涉及退款金額或例外核准時轉到既有 Flow 或真人客服
Instructions 不必鉅細靡遺地模擬程式碼；固定條件真的很多時，應該交給 Flow 或 Code block。相反地，Playbook 要把力氣放在任務邊界與高品質 Examples。
工具不只三種，而且每一種都要有契約
| Tool 類型 | 適合做什麼 | 實作時要留意 |
|---|---|---|
| OpenAPI Tool | 呼叫有 OpenAPI 規格的 REST API | Operation、參數、驗證、驗證方式與回傳 Schema |
| Function Tool | 讓客戶端程式執行自訂邏輯 | Agent 會暫停，等客戶端送回結果後才繼續 |
| Data Store Tool | 搜尋企業資料並整理有來源的回答 | 查詢、Filter、Grounding、權限與低信心處理 |
| Connector Tool | 串接 Integration Connectors 支援的系統 | Connection 地區、可用 Action 與最小權限 |
| Built-in Tool | 使用 Google 提供的能力，例如 Code Interpreter | 先確認地區、模型與功能限制，再決定是否啟用 |
Tool 的描述和 Schema 會直接影響模型怎麼選工具，但後端仍要自己驗證身分、參數和權限。描述寫得再漂亮，也不能取代 API 端的 Allowlist、逾時、冪等與稽核。
參數至少要分成「還沒拿到、拿到了、驗證通過」三種狀態。使用者說出一串看起來像訂單編號的文字，不代表它已經通過格式、身分和資源歸屬檢查。
流程圖暫時無法顯示，請重新整理頁面後再試。
實作重點
- 每個 Playbook 至少準備一個 Example；正式上線通常需要正常、模糊、工具失敗、取消與越界等多種案例
- Example 要檢查自動產生的 Action，不能因為模擬器跑完就直接存下來
- 測試 Tool 時同時測成功、空結果、錯誤格式、逾時與重複提交
- 模擬器能看到 Playbook invocation、Action 和 Tool 輸入輸出，但不要宣稱能看到模型完整的內部推理
- 使用內建 evaluations 比對不同環境與版本，避免改 Instructions 後出現對話回歸
- Playbooks 目前不在 Dialogflow CX SLA 內；正式採用前要確認這項限制符合服務等級需求
Lab 導讀
Lab 連結：Create Agents with Generative Playbooks — Google Cloud Skills Boost
Lab 會做一個零售客服 Agent，串接訂單 API 和企業知識。操作時不要只看「有沒有回答」，請記錄每次 Playbook 切換、Parameter 交接和 Tool Action；再故意讓工具回傳空資料或錯誤，確認 Agent 會說不知道、要求補資料或轉人工，而不是自己補一個答案。
延伸學習
- Data Store Agent 虛擬 FAQ — 準備 Playbook 使用的企業知識
- Agent Assist 與 GenAI — 把生成式能力接進真人客服流程
- 部署多代理系統 — 比較 Playbook 委派與程式化多代理協作
- Playbooks 官方文件 — 確認類型、模型、地區與目前限制
相關文章
您可能也會對這些文章感興趣
Generative Playbooks：該用 Flow 還是 Playbook？
從目標、指令、範例、參數到工具護欄，判斷客服流程何時該用 Playbook、何時應留在確定性的 Flow
AI Agent 安全：別只叫模型「不要洩密」
從 Prompt Injection、工具越權與資料外洩，到 Model Armor、IAM、VPC Service Controls 和人工核准的分層防禦
Data Store Agent：FAQ 準不準，先看資料
從資料來源、版控、ACL、解析與切片到引用驗證，整理一套能持續維護的企業知識問答上線流程
