本系列拆解企業導入 AI/Agent 時,工具明明做完了,工作卻沒有因此變好的決策現場。
Day 05:平台設定完整,不等於已具備正式營運條件。
建立頁面的右上角顯示 100%。
六個區塊旁邊都是綠色勾號。
Role:完成
Goal:完成
Persona:完成
Instruction:完成
Tool:完成
Knowledge:完成
Publish 按鈕也亮了。
專案經理把畫面投到會議室的大螢幕上。
「客服回覆 Agent 的設定完成了。權限確認完,今天就能開給第一批使用者。」
它會讀取客戶來信、查產品文件與歷史 Ticket,再產生一封建議回覆。產品手冊、常見問題、服務政策都已接入;Ticket 查詢、版本搜尋、歷史案例檢索也都測過。
最後測試用的是一封真實郵件。
新版軟體更新後,原本購買的舊版外掛是否仍可使用?如果不支援,公司是否會提供替代方案?
Agent 很快產生草稿:
根據目前產品相容性資訊,舊版外掛可能無法完整支援最新版本。我們建議您先完成資料備份,再進行升級;如有需要,也可以協助您評估替代方案。
語氣沒有問題,文字也沒有明顯錯誤。
專案經理問客服主管:「這封可以過嗎?」
她看著畫面停了一下。
「我不知道。」
工程師先去看引用來源。文件只寫「舊版外掛尚未完成新版認證」,並沒有寫不支援。更重要的是,客戶問的不只有相容性,還問公司會不會提供替代方案。
「它有找到替代產品。」工程師說。
「找到產品,不等於公司承諾替換。」客服主管說。
原本三十分鐘的上線確認會,後面都在補這些問題:
大家知道 Agent 能寫回覆,但沒有人先定義什麼情況下可以讓它進入正式工作流程。
Agent Creator 的欄位通常在描述這個 Agent 的能力:扮演什麼角色、要做什麼、可以用哪些工具、參考哪些知識、輸出要維持什麼語氣。
這些都需要填。但它們回答的是:
這個 Agent 被設計成什麼。
正式上線時,真正需要補上的則是另一組條件:
這一組不是平台做不做得到的問題,而是組織準備好了沒有。
平台上的 100% 只代表建立頁面要求的欄位都填完。它不代表真實案例測過、錯誤風險分過、維護責任有人接,也不代表使用者知道該怎麼判斷輸出。
這兩件事應該分開看:
| 平台設定完成 | 營運準備完成 |
|---|---|
| Agent 可以被建立 | Agent 可以進入既有流程 |
| 欄位、工具、知識已配置 | 成功條件、風險、接管與責任已定義 |
| 按鈕可以按下去 | 出錯時知道由誰處理、怎麼停 |
平台不可能自動補上後半段。因為它不會知道一封措辭不自然的客服信,和一封錯誤承諾交期的信,在公司裡是完全不同等級的問題。
上線討論很容易收斂成一個數字:準確率多少?
但客服回覆的錯誤並不是同一種東西。
即使整體有 95% 的草稿可以接受,也不能直接推出它能自動寄信。關鍵不在平均數,而在高風險錯誤是否會發生、是否能在送出前被看見,以及一旦發生誰要承擔後果。
所以真正的上線門檻不是「準確率高於某個數字」,而是每一種錯誤都有對應處理方式。
低風險的問題可以留給客服快速修改;涉及合約、價格、交期、支援範圍與例外承諾的內容,先強制人工確認。這不是自動化失敗,而是把 Agent 放在它目前能負責的那一段。
團隊後來沒有再調整 Persona,也沒有往 Instruction 裡補更多「請謹慎回答」。他們另外加了一張上線檢查表。
| 項目 | 上線前要答的問題 |
|---|---|
| 輸入來源 | 哪些資料允許進來?缺欄位或資料互相矛盾時怎麼處理? |
| 成功標準 | 草稿替使用者省下哪一步?目前人工處理的 Baseline 是什麼? |
| 錯誤分級 | 哪些錯誤可修正,哪些錯誤不能放過? |
| 錯誤可見性 | 錯誤會在哪個步驟、由誰發現? |
| 人工接管 | 哪些內容一律 Review?誰有最後決定權? |
| 營運 Owner | Prompt、知識、權限與異常回報各由誰負責? |
| 停用條件 | 發生什麼情況時停止使用,退回哪個流程? |
這張表不是為了把風險歸零。它只是避免風險在 Agent 正式發布後,才第一次被看見。
若其中幾項還答不出來,專案仍可以繼續測試;但它只能停在測試,不該把 Publish 亮起來當成可以營運。
客服回覆 Agent 最後沒有直接對外寄信。
第一階段只產生草稿,由客服修改後送出。團隊同步記錄草稿被改了什麼、哪些問題一定被退回、哪些資料常缺、哪些錯誤需要升高處理。
兩週後,他們才根據這些紀錄討論:哪些低風險問題可以少做一次 Review,哪些內容永遠不能交給 Agent 自己送出。
專案經理回到建立頁面時,六個區塊還是全部打勾,設定進度仍然是 100%,Publish 也一直亮著。
它沒有提醒成功標準還沒寫、錯誤還沒分級、Owner 還沒確認。
那個按鈕只知道一件事:所有欄位都填滿了。