kakinang INSIGHTS · 2026-08-28

從 Chatbot 到 AI Agent：能力要配上治理

選擇客服自動化時，先分清楚系統只需要回答、需要查知識我想判斷客服需要知識問答、留單，或受治理的工具動作。，還是需要受確認的動作。能力越接近寫入，治理越重要。

規則式聊天適合有限選項

固定詞彙與少數選項可用規則處理，但面對口語與複合問題時容易失去彈性。

以「知識檢索與受確認的工具動作」為例，先收集十到二十種顧客真實說法，標示哪些可由公開資料回答、哪些一定要由人判斷；每一題同時指定下一位負責者，不要只用沒有後續主人的模擬對話驗收。

把「知識檢索與受確認的工具動作」的測試結果留下來：真實問法、可追溯的答案依據與下一位處理者。不要只因語句流暢就判定通過，還要能說清楚顧客從這一步將被帶往哪個可完成的服務路徑。

模型能理解多種說法，卻不會自動知道商家的現行政策、庫存或權限，因此不能把自然語言當成事實來源。

實作時把原始資料、審閱角色與下次覆核日寫進作業表。針對「知識檢索與受確認的工具動作」分別在營業中與非營業時間演練，確認受理文、畫面狀態與告知顧客的回覆時程沒有互相矛盾。

指定資訊變更的 owner 與通知方式。若「知識檢索與受確認的工具動作」依賴常變資料，審閱完成前應能暫停該類回答，不能讓舊資料被包裝成新的對外承諾，這也是營運能安全維護的必要條件。

RAG 可在回答前取用已核准資料，但檢索結果仍須受來源、更新與無結果時的拒答規則治理。
邊界必須能被測試：不能承諾系統未重新確認的結果、不能混用其他商家的資料，也不能在證據不足時繼續猜。遇到「知識檢索與受確認的工具動作」的例外，轉交文字要說明團隊下一步會做什麼。
負向測試也要寫進驗收：超出範圍的詢問、索取私人資料、要求直接確認訂單、試圖繞過規則。面對這些情況，「知識檢索與受確認的工具動作」應有禮拒絕，並保留讓接手者理解問題的最小脈絡。

當系統能建立留單、查詢資料或呼叫 API，每項動作要有允許清單、輸入驗證、稽核和必要的使用者確認。

擴大前做一張驗收表：來源是否為最新、交接是否真的送達、處理者能否看見足夠脈絡、任何寫入動作是否要求確認。做到這些，「知識檢索與受確認的工具動作」才是可營運服務而非只適合展示的對話。

上線後由營運者固定抽樣閱讀，將更正回寫到原始資料或規則，而不是只在單一對話補一句話。這個回圈讓「知識檢索與受確認的工具動作」能改善，也避免為了修一個例外就擴張 AI 的權限。

讀取公開資訊與建立對外承諾的風險不同。涉及金錢、訂單或外部系統時，應在執行邊界重新檢查條件。

衡量請優先使用自己的紀錄：無法回答的問題、到有人負責的時間、確實被跟進的留單與轉交原因。分析時把「知識檢索與受確認的工具動作」的變化和行銷活動、旺季或人力調度分開看。

初期設定較短的檢討週期，根據證據決定保留、縮小或擴大「知識檢索與受確認的工具動作」。好的判斷不是訊息數變多，而是責任分工更清楚、顧客不必重複描述相同需求，且例外能被看見。

先把知識問答與留單做好，再評估是否真的需要更多工具。不要因為 Agent 一詞流行就把自主權交出去。
可接受的驗收標準是另一位審閱者能追到答案依據、看見誰接手、並解釋高風險案件為何沒有被自動執行。若做不到，先修正「知識檢索與受確認的工具動作」規則，再新增通路、工具或權限。
每次變更知識或流程後，同時重測正常問題與拒絕案例，留下日期與核准者。如此團隊才能向審閱者、顧客與下一位處理者解釋「知識檢索與受確認的工具動作」為何改變，以及這次改變沒有放寬哪些風險邊界。

AI Agent 會自行做決定嗎？

負責任的設計不會讓它任意做決定；它只能在允許的工具、權限與確認規則內運作。

RAG 就是 Agent 嗎？

不是。RAG 是取回資料協助回答的方法；Agent 通常還包含規劃與受治理的工具使用。

何時需要外部 API？

當有明確、可驗證且值得自動化的下一步時才需要，並要處理確認、重送與稽核。

小商家應從哪裡開始？

從公開知識、留單與人工接手開始，先確認服務真的被接住。