聊天機器人跟 AI Agent 差在哪？什麼時候才該接到系統裡

先看它做完之後，系統裡有沒有留下痕跡

一個最實際的判斷方式，是看這次互動結束後，營運系統有沒有多出一筆可追查的結果。如果對話結束，什麼都沒寫進 CRM、工單或訂單，它比較接近聊天機器人，頂多幫人節省搜尋時間。如果它能依權限查出一筆訂單、建立待辦、通知負責人，或把整理後的欄位送去人工確認，那才進入 Agent 的範圍。

這個差別聽起來像技術分類，對中小企業其實很具體。客服主管在意的不是模型名稱，而是下班後有沒有漏掉的詢問、會不會用錯價格、出問題時能不能找到是誰、在哪個步驟放行。聊天視窗很難回答這些問題；Agent 若沒有狀態與紀錄，也一樣幫不上忙。

例如一家同時用官網表單和 LINE 收詢問的服務公司，原本請值班人員把對話複製到試算表。後來加了聊天機器人，回覆變快，建檔卻還是靠人。速度看起來有進步，漏單和重複詢問並沒有比較少。問題不在模型不夠聰明，而在「回答」和「進系統」仍是兩條路。

• 只查公開 FAQ、不改任何資料：先當聊天或知識輔助
• 要讀訂單、客戶或庫存：開始涉及權限與資料來源
• 要建立紀錄、分派或通知：必須當成 Agent 與流程來設計

Agent 不是比較會聊天的客服，而是受控的作業員

把 Agent 想成多了一個很會寫字的同事，通常會高估它的判斷、低估它的權限風險。比較接近的比喻是：你請一位新進人員幫忙處理固定作業，但這個人記性很好、手很快，也可能在資料不完整時自行腦補。所以上線前要先寫清楚三件事：可以讀哪些資料、可以呼叫哪些工具、哪些動作一定要等人核准。

讀資料和寫資料的風險差很多。讓 Agent 搜尋已核准的產品說明，錯了頂多是答得不準；讓它直接改價格、標示已出貨或送出對客承諾，錯一次的補救成本完全不同。很多專案卡關，不是卡在提示詞寫不好，而是一開始就把「查」和「做」混成同一個開關。

AgentTech 在規劃時會把對話、查詢、工具呼叫和寫回拆開。對話負責理解意圖；查詢只能打到被允許的資料來源；工具呼叫對應建立紀錄、通知、轉單這類動作；寫回則要有對象、欄位與可否覆寫的規則。模型負責理解與整理，系統負責限制它碰得到什麼。

什麼時候聊天就夠，什麼時候值得做成 Agent

不是每個場景都該上 Agent。如果問題集中在公開資訊、答案穩定、就算答錯也容易被發現，先把知識整理好、讓人快速找到，往往比急著接系統划算。等同一類問題開始帶出「幫我查一下這筆單」「幫我開一張跟進」這類後續動作，再把 Agent 接進既有流程，才比較補得到時間。

值得做成 Agent 的工作，通常有三個特徵。第一，每週都重複發生，不是偶發的疑難雜症。第二，輸入雖然不整齊，但結果可以用欄位、狀態或文件來驗收，例如「有沒有建立客戶紀錄」「有沒有通知到對的人」。第三，做錯之後還有人接得住，而不是直接對客戶生效。

反過來說，價格談判、客訴責任、個資更正、合約條款這類事情，即使 Agent 能起草，也不該讓它自己送出。這裡不是技術做不到，而是企業要能指出：最後按下去的人是誰。

• 高頻、規則清楚、結果能量測：適合作為第一條 Agent 流程
• 資料分散、但已有系統可當來源：適合接進 CRM 或後台
• 高風險承諾或無法回溯：只做草稿，不自動完成

AgentTech 會先定作業範圍，再決定要不要接模型

實務上我們很少從選模型開始。比較有效的順序是：先畫出今天這件工作怎麼做、資料從哪裡來、誰可以看、做錯會怎樣。若這條流程連人工都做不穩定，先接 Agent 只會把混亂加速。資料來源、欄位定義和例外處理先有共識，模型才有可依賴的輸入。

接著才決定 Agent 的第一個任務。常見做法是讓它負責分類、擷取欄位、搜尋依據和產生草稿，真正寫入系統前留一個確認步驟。確認介面要讓人看得懂：引用了哪筆資料、準備寫入哪些欄位、哪裡不確定。只給一段通順的文字，覆核的人很容易被語氣帶過去。

若企業已經有客製系統或 App，Agent 應該使用同一套身分、權限和狀態，而不是另外開一個誰都能問的聊天室。這樣之後要加第二條流程，才是在同一條軌道上擴充，而不是每做一次就多一個無法稽核的機器人。

驗收不要只看「回答得像不像」

聊天機器人常用滿意度或回覆速度當成果。Agent 若也只用這兩個指標，很容易忽略它有沒有把工作做完。比較有用的是看：正確建立紀錄的比例、需要人工修改的欄位、例外轉出的原因，以及從進線到負責人接手花了多久。這些數字不一定漂亮，但能告訴你下一步該整理資料、調整權限，還是根本不該自動化某一段。

第一階段也不必覆蓋所有通路。可以先選官網表單或內部文件這一種輸入，跑完「理解、查詢、草稿、確認、寫回」再擴充到 LINE 或 Email。通路一多，例外就會一起變多；先把一條路走通，比同時讓 Agent 面對所有入口更容易看出問題出在模型、資料還是規則。