AI 客服與 AI Agent 有什麼不同？

AI 客服和 AI Agent 都可能使用語言模型，但工作邊界不同。客服通常先回答、分類與收集需求；Agent 可能依任務呼叫查詢、表單或企業系統。只要會讀取或修改資料，就必須先設計權限、工具白名單與人工確認。

• 角色差異
• 工具權限
• 人工確認
• 風險邊界

先用工作範圍理解兩個名詞

AI 客服通常以對話為主，從核准的 FAQ 或知識庫回答問題、整理客戶需求、提出下一步與轉接人工。它不代表每個答案都正確，也不代表可以直接修改訂單或承諾價格；是否能執行動作，仍要看後端系統與權限。

AI Agent 則是把「理解任務、規劃步驟、呼叫工具、檢查結果、繼續或停止」串在一起。例如先讀取表單、查詢可用時段、整理選項，再建立待人工確認的預約草稿。這不等於任務一定能自動完成，因為工具失敗、資料不足與權限拒絕都需要有明確回復。

不要用名稱取代權限設計

同一個產品可能被稱作客服機器人、Copilot、Agent 或自動化流程，但真正要問的是它能讀取什麼、能呼叫什麼、能不能寫入、誰可以核准，以及每個動作是否可撤回。聊天介面看起來很自然，不代表後端可以省略身份驗證、權限檢查與輸入驗證。

建議將工具分成只讀、可產生草稿、需要人工批准與禁止自動執行四級。查詢公開服務資訊可考慮自動處理；查詢客戶專屬資料要驗證身份；改價、付款、刪除、退款或變更帳號則應由既有系統和授權人員完成。

客服與 Agent 都需要可追溯的資料來源

客服回答應指出內容來自哪一份核准文件、FAQ 或系統狀態；Agent 執行工具時則要保存輸入、工具名稱、回傳狀態、錯誤、人工決定與最後結果。這些紀錄不是用來把所有對話永久保存，而是讓企業能在客戶詢問或事故發生時確認系統做了什麼。

知識內容更新後，要重新測試常見問法與高風險情境。當資料來源不存在或互相矛盾時，系統應停止猜測並轉人工；不能因為 Agent 有下一步工具，就強行把不確定的內容寫進 CRM 或訂單。

Agent 的主要風險在工具與資料邊界

當 Agent 能呼叫外部服務、讀取內部文件或寫入 CRM，提示詞注入、惡意附件、錯誤資料與工具回傳內容都可能影響下一步。OWASP 的 LLM 應用風險清單將 Prompt Injection 列為重要風險；防護不能只靠一句「請遵守規則」，還需要在系統層做工具白名單、參數驗證、最小權限與人工確認。[2]

企業也要設計停止條件，例如資料不完整、連續重試超過上限、外部服務回傳異常或任務涉及付款。Agent 應能把未完成的上下文交給人工，而不是不斷重試或回覆一個看似完成的結果。

企業該先做 AI 客服還是 Agent？

如果企業還沒有整理 FAQ、服務規則、價格來源與人工交接流程，先做範圍清楚的 AI 客服通常較容易驗收。客服試點可以先處理常見問題、需求收集與內部轉派，建立資料品質與錯誤分類，再逐步評估只讀查詢或草稿工具。

如果企業已經有穩定的 API、角色權限、狀態機與可測試流程，才適合評估 Agent 的多步驟工作。Agent 不是客服的高階版本，也不是把所有流程串在一起；它是一種需要更嚴謹工具契約與營運監控的自動化方式。

雲端、本地與混合部署的取捨

客服與 Agent 都可以使用雲端、本地或混合模型。雲端便於先做語意理解與快速試點，本地適合特定敏感文件與內網限制，混合則可將資料分級後使用不同模型或服務。部署選擇仍要回到資料敏感度、使用量、延遲、維運能力與中斷備援，而不是用「Agent」這個名稱推導出一定要更大模型或更高規格。

若本地 GPU、模型能力或維護資源不足，過度複雜的 Agent 可能比簡單的雲端客服更難維護。先以可觀察、可停用、可人工接手的範圍驗證，再決定是否增加工具和模型。

選型前檢查清單

請先回答：要解決的是回答問題、整理資料，還是跨系統執行工作？資料來源是否有擁有人與更新日期？工具的讀取與寫入權限怎麼分級？哪些動作必須人工核准？發生錯誤、重複事件或服務中斷時如何停止與回復？如何從日誌知道系統實際做了什麼？

回答不清楚時，不宜先以 Agent 名稱採購或承諾全自動化。宇哥電腦可依企業現有 LINE、表單、CRM、文件與人工流程，評估先做 AI 客服、知識庫、草稿自動化或更完整的 Agent 工作流。