查看回饋並擴大範圍

這一步發生在 stakeholder 已經試用過已發布的已驗證範圍之後。Production feedback 是你判斷下一步要擴大什麼範圍的依據。最快的 operator 流程是：先在 Histories 看 thread，請 Copilot 解釋發生了什麼，再用 Add Case 把新情境存成可重跑案例，只在需要的地方更新 Agent，最後在 Test Suite 跑受影響的案例。

步驟 1：在 Histories 打開 stakeholder 的 thread

當 stakeholder 開始使用已發布的 Web channel 後，先到 Histories 找出一個值得學習的 thread：

• 回答是安全的，但講得不夠自然
• 少問了一個關鍵澄清問題
• 應該更早轉交給真人
• 某一則訊息已經掛著 stakeholder feedback
• 使用者提出目前已驗證範圍外的問題

步驟 2：在 thread 旁打開 Copilot 並直接問

打開該 thread 後，點擊右下角的 Copilot 按鈕，讓 thread 保持在左邊，再到 Copilot 面板的 Ask a question... 輸入框裡直接問這段回覆為什麼會變成現在這樣，以及規則該怎麼改。

stakeholder 的回饋不需要非常結構化。很多團隊裡，stakeholder 只會指出哪裡怪怪的、也許順手補一句原因。接下來的診斷工作，就是 operator 和 Copilot 的事。

例如：

有位 stakeholder 在 pricing 回覆上留下這段 feedback：
「這段回答是安全的，但還是有點 generic。請縮短一點、更早說清楚價格要由真人提供，並更早提出 human callback。」

為什麼 Agent 會這樣回？我應該在 Agent Editor 裡更新哪一條 instruction？

你可以請 Copilot 幫你釐清：

• 是哪一條 instruction 造成了這個行為
• 哪個規則寫得太模糊或太寬
• instruction 應該怎麼改寫
• 更好的回答大概應該長什麼樣子
• 之後在 Test Suite 裡，Standard 應該檢查什麼

步驟 3：先在 Histories 用 Add Case 建立案例，並和 Copilot 一起寫 Standard

當 thread、feedback 和 Copilot 的分析都還在眼前時，直接對那則高風險回覆按 Add Case。

先不要離開 Histories。這是把真實 pattern 直接整理成可重跑案例的最好時機。

你可以請 Copilot 幫你把 Standard 寫成短而可檢查的條件。例如：

請把這次失誤整理成 `Test Suite` 可以用的 2 到 3 條短 `Standard`。
每一條都要明確到讓另一位 operator 不用猜就能判斷 pass 或 fail。

在 Case Detail 裡：

• 保留附帶的對話脈絡，讓案例包含前面的上下文
• 檢查 Input 是否就是你要重跑的高風險問題
• 更新 Ideal Response，讓它反映你想要的新行為
• 參考 Copilot 的建議，寫出精簡的 Standard
• 點擊 Create

步驟 4：判斷這是否要擴大範圍

案例存好之後，先判斷它屬於哪一種改動：

• 已驗證範圍內的修正
• 下一版應該擴大的新情境
• 目前應該繼續留在安全 fallback 的情境
• 擴大前需要補的 knowledge 或 tool gap

如果你決定要修正或擴大，再回到 Edit Agents，打開 Agent，只修改真正相關的 Instructions、knowledge 或 tool setup。

當你準備好之後：

1. 點擊 Apply。
2. 檢查更新後的 instruction。
3. 先不要發布。先在 Test Suite 重跑受影響的案例。

讓修改範圍小一點

只修一個明確問題，會比一次改很多地方更容易驗證。改動太大時，你很難知道到底是哪一條規則真的有幫助。

步驟 5：在 Test Suite 執行已保存的案例

這個流程裡，不需要再跳回 Live Test。直接到 Test Suite 執行剛存好的案例，確認更新後的版本是否通過。

你要檢查的是：

• 這個案例現在是否通過，或至少明顯往對的方向移動
• Standard 是否真的對準你想要的行為
• 這次修正是否夠聚焦，讓你仍然理解它為什麼有效

從這裡開始，操作模式其實很固定：

1. 在 Histories 查看真實流量
2. 問 Copilot 發生了什麼
3. 用 Add Case 把重要 thread 存成可重跑案例
4. 判斷每個案例是修正、擴大範圍，還是繼續 fallback
5. 只在需要的地方更新 Agent、knowledge 或 tools
6. 先跑受影響案例；如果可能影響既有行為，再跑更完整的案例組
7. 只有在擴大後的範圍穩定時，才發布新版本

這就是讓 Agent 逐步變得更安全、更有用的方法。

慶祝完成第一個改進循環

你現在已經走完整個擴大範圍循環：收集真實 stakeholder feedback、留下可重跑案例、判斷是否擴大範圍、改進 Agent，並在發布新版本前用 Test Suite 驗證改動。

什麼時候需要更多結構

當 pilot 開始擴大時：

• 如果 Agent 需要收集結構化的 intake 資料，就加上 Request Form
• 如果你發現更多不想重複發生的錯誤，就補上更多 驗證與改進 裡的案例
• 如果有多個變更需要一起 review，就用 Version Management

下一步

• 搜集回饋
• 驗證與改進
• 版本管理