分享並收集回饋
當第一版 Agent 已經通過 Live Test，就開始一個小而可控的 rollout。實際流程是：先發布 Agent 版本，再建立並發布 Web channel，自己先打開 web client 確認一次，最後再請幾位 stakeholder 實際試用並針對特定回覆留下 feedback。
步驟 1：先發布 Agent 版本
channel 和 Agent 版本是分開發布的。建立或分享 channel 之前，先回到 Edit Agents，打開 Consultation Desk，然後在 Agent Editor 點擊 Publish。
版本發布成功後，按鈕會變成 Unpublish。這就是 web client 已經能真正載入 Agent 的訊號。
如果 web client 顯示 No agents available
代表 channel 已經上線，但 Agent 版本還沒發布。請回到 Edit Agents 發布目前版本，然後重新整理發布 URL。
如果你之後有修改 Agent，也要再按一次 Publish，web client 才會吃到新的版本。
步驟 2：建立 Web channel
- 在 workspace 中打開
Channels分頁。 - 點擊
New Channel。 - 為
Consultation Desk建立一個 channel。
步驟 3：選一個清楚的 slug
建立 channel 時，請填入：
- Name：
Consultation Desk - Slug：例如
consultation-desk - Type：
Web Application
如果你想先有個起點，可以使用 Auto-fill from name。最終的發布 URL 會使用這個 slug，所以請選一個你願意分享的名稱。
步驟 4：發布 channel
channel 建立後：
- 打開 channel 詳細頁。
- 在
Overview檢查 slug URL 是否正確。 - 點擊
Publish。 - 複製發布後的 URL，準備發給測試者。
步驟 5：先自己打開一次 web client
在把連結送給別人之前，先自己確認一次：
- 打開發布後的 URL。
- 確認你看得到 Agent 名稱、描述和聊天輸入框。
- 先送一則簡單訊息，確認公開體驗真的能正常運作。
這就是 stakeholder 在設定正確時會看到的畫面。
步驟 6：請 stakeholder 試用並留下回饋
請 3 到 4 位 stakeholder 從不同角度測試這個 pilot：
- 一個正常的客戶問題
- 一個需要澄清的模糊問題
- 一個高風險或不合理的問題
- 任何讓他們覺得不清楚、太 generic、過度自信或資訊不足的回覆，都直接留 feedback
當某一則回覆不對勁時，請 stakeholder 直接在那則回覆上點 Improve，用自然語言寫下哪裡不對即可。他們不需要自己分析根本原因。像 太 generic 了，應該更早提出 human callback。 這種短句，就足夠讓 operator 和 Copilot 往下處理。
第一輪人數不用多，而且要保持可控。重點是找到下一個要修正的問題，而不是立刻全面上線。
什麼叫做有價值的外部回饋
最有用的 stakeholder 回饋，通常會回答這些問題：
- 是哪一則回覆讓他們覺得不對？
- Agent 應該改問別的問題、提早轉交，還是不要那麼 generic？
- 它有沒有暗示任何團隊尚未核准的內容？
- 站在 stakeholder 角度，更好的回答本來應該做到什麼？
之後再加強存取控制
第一輪先維持小範圍。之後如果你需要更嚴格地控制可使用對象，可以到 受眾存取 使用 whitelist mode。
可選升級：Request Form
如果 Consultation Desk 需要在對話中收集結構化的 intake 或預約資訊，再加入 Request Form。除非結構化資料本來就是核心流程，否則第一輪先不要加。
進階發布方式
如果你需要從自己的產品或後端直接呼叫 Agent，請看 API Access。對第一次 pilot 來說，先從 Channels 開始就好。