跳轉到

查看回饋並改進

這一步發生在 stakeholder 已經試用過已發布體驗、也留下初步回饋之後。最快的 operator 流程是：先在 Histories 看 thread，請 Copilot 解釋發生了什麼，再用 Add Case 把高風險回覆存成 eval case，接著回到 Editor 更新 Agent，最後在 Test Suite 跑這個案例。

步驟 1：在 Histories 打開 stakeholder 的 thread

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

  • 回答是安全的，但講得不夠自然
  • 少問了一個關鍵澄清問題
  • 應該更早轉交給真人
  • 某一則訊息已經掛著 stakeholder feedback

Histories 中 pricing 回覆下方已附上真實 stakeholder feedback 的 thread

步驟 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 應該檢查什麼

在 Histories 的 thread 旁打開 Copilot 面板，根據 stakeholder feedback 詢問原因與修正方向

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

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

先不要離開 Histories。這是把真實失誤直接整理成可重跑 eval case 的最好時機。

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

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

在 Case Detail 裡：

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

在 Histories 對高風險 pricing 回覆按下 Add Case 後打開的 Case Detail

步驟 4：回到 Editor 更新 Agent

案例存好之後，再回到 Edit Agents，打開 Consultation Desk，只修改 Instructions 中真正有關的那一小段。

當你準備好之後：

  1. 點擊 Apply。
  2. 檢查更新後的 instruction。
  3. 再按一次 Publish，讓 web client 用到新版本。

在 Editor 中更新 instruction 並重新發布 Consultation Desk

讓修改範圍小一點

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

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

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

你要檢查的是：

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

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

  1. 把 Agent 分享給少數 stakeholder
  2. 在 Histories 看初步回饋
  3. 問 Copilot 發生了什麼
  4. 用 Add Case 把重要 thread 存成 eval case
  5. 回到 Editor 更新 Agent
  6. 在 Test Suite 重跑這些案例

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

Test Suite 中已保存並執行的案例結果

慶祝完成第一個改進循環

你現在已經走完整個 beginner loop：發布 Agent、收集真實 stakeholder feedback、留下第一個可重跑的 eval case、更新 instructions，並在 Test Suite 驗證修正。後面的進步，基本上就是把這個循環做得更穩。

什麼時候需要更多結構

當 pilot 開始擴大時：

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

下一步