跳轉到

查看對話並改善

真實對話會顯示 Agent 在使用者實際脈絡裡做了什麼。請先處理眼前需要，再判斷這段新判斷是否應改變未來 version。

營運循環是：

觀察 -> 處理 -> 保存 -> 修改 -> 驗證

步驟 1：先處理需要注意的對話

打開 對話，優先查看標記為 待真人回覆、後果較高，或帶有 Improve feedback 的訊息。

如果使用者正在等待，請先回覆，再把問題變成 optimization task。你可以直接撰寫，或產生 AI 草稿、檢查後，在支援的情況下透過原 Channel 送出。

→ 回覆對話

步驟 2：連同脈絡檢查發生了什麼

閱讀完整對話，找出：

  • 使用者想完成的工作
  • Agent 當時可以取得的資訊
  • Agent 產生的動作或回答
  • 哪個品質或邊界決定沒有被遵守
  • 這個問題是否屬於目前 scope

「太 generic」這類 feedback 是訊號，還不是診斷。請把它翻成可觀察行為：應該補問哪個問題、避免哪個宣稱、缺少哪個下一步，或應該在什麼時候 handoff。

步驟 3：使用 Add Case 保存情境

當你希望 Agent 修改後仍能檢查這個情境時，使用 Add Case。

在 Case Detail：

  • 保留理解工作所需的脈絡。
  • 確認 Input 能代表要重跑的行為。
  • 只有在範例能改善 review 時才加入 Ideal Response。
  • 撰寫一小組讓其他 reviewer 不必猜測就能判斷的 Standard。

例如，一個有用的 Standard 可以要求回覆補問某項缺少資訊、避免特定無依據承諾，並在資料來源無法解決情況時 handoff。

步驟 4：診斷最小且相關的原因

判斷問題發生在：

  • 預期行為或 Standard
  • Instructions
  • Knowledge Base 內容或 retrieval
  • 工具設定或調用邊界
  • 是否應把這個情境放進目前 scope 的決定

Copilot 可以協助檢查 case 與目前 Agent 設定。請要求最小的 pattern-level 修正，不要新增一條只會重複單一 case 用字的規則。

AI 草稿 feedback 不會發布 Agent 修改

捨棄或調整 AI 草稿，可以改善這段對話的下一份草稿；如果底層行為應該為未來使用者改變，仍要更新 Agent 並重新驗證。

步驟 5：修改並驗證

如果這個情境屬於支援範圍：

  1. 打開 AI 助理，只更新相關 instruction、資料來源或工具。
  2. 使用 套用 保存 draft 修改。
  3. 在 Test Suite 執行新 case。
  4. 執行相關 must-pass cases。
  5. 修改可能影響已通過行為時，執行更廣的 regression cases。
  6. 只有在發布條件通過後，才發布新 version。

如果這個情境不屬於目前 scope，請保留核准 fallback，並把 case 留給之後 version。

步驟 6：觀察結果

發布後回到 對話，確認新流量裡是否再次出現同一模式。Case 通過只能證明案例條件下的受檢行為；production review 則能顯示真實情境是否持續出現或改變。

下一步