下列最佳做法有助於建構強大的代理程式。
以自然語言輸入應對手冊名稱
劇本名稱應清楚明瞭、具描述性，且以自然英文呈現。這有助於提升 AI 產生器在執行階段的效能。舉例來說，「Customer Help Center Playbook」比「company_specialist」更適合。
所有名稱長度不得超過 64 個字元，包括英文字母和空格。
簡潔的目標
目標應簡要說明手冊的用途。
提供優質指令
訓練應著重以下方向：
- 反映解決使用者問題的逐步方法。
- 簡潔的自然語言句子，提供高階指令。
- 請直接說明工具用途，並指定使用情境。
每個劇本至少一個範例
每個劇本至少要有一個範例，但建議至少要有四個。範例應包含滿意路徑情境。
如果沒有足夠的範例，應對手冊可能會導致無法預測的行為。如果劇本未回應或行為不如預期，可能是因為範例遺失或定義不當。請嘗試改善範例或新增範例。
指令和範例的精確度
雖然清楚詳盡的指令有助於提升準確度，但真正決定劇本行為準確度的，是範例的品質和數量。換句話說，請花更多時間撰寫詳盡的範例，而非精確的指令。
範例中的參照工具
如果劇本的設計是使用工具提供回覆，請參考與這類要求對應的範例中的工具。
工具結構定義 operationId 欄位
定義工具的結構定義時，operationId 值非常重要。您的劇本說明會參照這個值。
這個欄位的命名建議如下：
- 只能使用英文字母、數字和底線。
- 所有架構中描述的
operationId皆不得重複。 - 必須是反映所提供功能的有意義名稱。
工具結構定義驗證
請驗證工具結構定義。您可以使用 Swagger 編輯器檢查 OpenAPI 3.0 結構定義語法。
處理空白工具結果
如果應變手冊依賴工具來提供回覆，工具結果空白可能會導致應變手冊行為無法預測。有時，Playbook AI 生成器會在回覆中產生幻覺資訊，而非工具結果。為避免發生這種情況，您可以新增特定指示，確保劇本 AI 生成器不會嘗試自行回答。
在某些情況下，應對手冊回覆必須以工具結果或提供的資料為依據，並避免僅根據應對手冊 AI 生成器知識提供回覆。
以下是降低幻覺的指令範例：
- 「你必須使用這項工具回答所有使用者問題」
- 「如果工具未傳回任何資料，請回覆你不知道使用者查詢的答案」
- 「如果工具沒有傳回任何資料，請勿自行捏造答案」
使用 Gemini 生成結構定義
Gemini 可以為你生成結構定義。 舉例來說，您可以嘗試「請為 Google 日曆建立 OpenAPI 3.0 架構範例」。
專注模式應對手冊
避免建立過大且複雜的手冊。每本應對手冊都應完成特定且明確的任務。如果應對手冊很複雜，建議拆解成較小的子應對手冊。
避免迴圈和遞迴
在指令中連結代理程式時，請勿建立迴圈或遞迴。如果您嘗試將路徑導向祖先應對手冊，而該應對手冊直接或間接呼叫了目前的應對手冊，就會發生迴圈。
提供範例的路由資訊
如果應對手冊應導向其他應對手冊，請在範例中提供這項資訊。這是從「輸入和輸出」範例部分「輸出資訊結尾範例」欄位提供的範例。
舉例來說，這個欄位的最後一句話可以是「如需進一步查詢，請重新導向至預設劇本。」
使用 Dialogflow CX Messenger JavaScript 函式進行個人化
使用 Dialogflow CX Messenger 時，下列函式有助於將使用者個人化資訊從網頁介面傳送至劇本：
規劃成效
生成式功能通常需要幾秒，甚至幾十秒才能生成回覆。應對手冊可提升對話的自然度，但管理回覆時間至關重要，才能維持良好的使用者體驗。
以下是幾種提升成效的策略：
- 平衡生成功能的使用：請仔細考量執行多項生成功能所需的時間，以及這些功能為對話帶來的價值，並在兩者之間取得平衡。如果這些功能對使用者的目標沒有顯著貢獻，請避免過度使用。
- 盡量減少生成功能輸入內容：盡量收集及處理最少量的資訊，讓 AI 生成器產生實用回覆。這可大幅縮短處理時間。
- 使用脈絡快取：如果您透過工具使用 Gemini，且有大型初始脈絡，請使用 Vertex AI 脈絡快取探索快取資訊，避免重複要求相同資料。
- 導入固定回覆內容，加快速度：如果應用程式不需要獨特的動態內容，可以考慮將常用回覆內容儲存在 Firebase 等傳統資料庫中。由於這些回覆是預先定義且隨時可用，因此相較於需要即時計算答案的生成式功能，固定回覆的回應速度快得多。
- 指示 AI 生成器產生簡潔的劇本回覆：對於文字輸入和輸出，AI 生成器的回覆時間高度取決於使用的模型和輸出長度。簡短的回覆可大幅提升成效。雖然輸入內容長度也是影響因素，但輸出內容長度的影響較大。