模型只是其中很小的一部分。資料能不能用、介面是否清楚、流程如何銜接、AI 做錯後由誰處理，這些問題會一起出現。
寫完 gptpmt 這套教程後，我一直忙著各種事情，很久沒有真正靜下心，系統地寫一篇文章。
從 2022 年接觸 ChatGPT，到 2023 年開始寫 gptpmt，再到後來參與企業 AI 實踐，前後已經三年多。這段時間做了不少嘗試，也看見許多企業落地 AI 時遇到的問題。
最近，身邊愈來愈多朋友會問：企業已經有很多業務系統，到底應該怎麼接入 AI？
這個問題看起來像技術問題：選什麼模型、用什麼框架、怎麼呼叫介面。
但真正開始做後會發現，模型反而只是很小的一部分。企業內部資料能不能使用、原有介面是否清楚、多個業務流程怎麼銜接、AI 做錯後由誰處理，這些問題都會一起出現。
先從最常見的智慧客服情境開始。假設使用者打開客服視窗，問：
「我的訂單為什麼還沒出貨？」
視窗裡的 AI 先說了一大段物流可能延遲的原因，最後才請使用者提供訂單編號。收到編號後，它還是查不到，只能轉接人工客服。
企業花了不少時間做智慧客服，客服的工作量卻沒有減少，反而多了一件事：替 AI 解釋。
為什麼？
問題未必出在模型，而是把一個只會回答問題的系統，直接拿去執行需要查詢、判斷、操作與承擔風險的任務。
這就像蓋房子。地基還沒打好，就開始討論頂樓怎麼裝潢。最後通常不只是房子蓋得慢，而是蓋到一半才發現底下根本撐不住。
企業老系統接入 AI，也需要一層一層補齊能力。大致可以分成四個階段：Chatbot（以對話方式回答問題的系統）、AI + Tools（AI 可呼叫明確的業務工具）、Copilot（圍繞目標串接步驟，遇到不確定性時由人接手的助手）與 Agent（在約定邊界內自主執行的系統）。
這不是業界標準，而是一套檢查能力的框架。企業不必正式上線每個中間版本，但資料、工具、任務與治理這幾層能力不能跳過。
四個階段，四層能力。
第一階段：Chatbot，先把問題回答正確
先把問題變簡單。
使用者不問自己的訂單，只問：「一般付款後多久出貨？」
這時 AI 不必進入業務系統。只要企業整理好出貨規則、退款政策、商品資料與常見問題，它就可以回答。
Chatbot 在這一階段做的，是依據企業知識回答通用問題。
營業時間、產品介紹、報銷制度、售後規則等答案，通常已經存在企業文件裡。過去要靠員工自行搜尋，現在可以直接以自然語言提問，再由 AI 找到相關內容並組織成答案。
看起來好像只要把文件放進去就夠了。
但問題一旦涉及特定訂單，它就不知道了。它不知道使用者是誰、有哪些訂單，也不知道目前訂單處於什麼狀態。繼續回答，就只能依通用規則猜測。
所以第一階段有明確邊界：它可以回答企業知識裡已存在的問題，但不能假裝知道正在發生的業務事實。
從階段零到第一階段，關鍵不是模型，而是資料治理
許多企業一開始會把幾百萬字的飛書文件、產品手冊和客服紀錄一股腦交給 AI，以為文件愈多，回答就愈好。
其實文件多，不等於知識可用。
想像廚房裡放著幾十個一模一樣的調味罐，沒有標籤，也沒有固定位置。做飯的人知道裡面一定有鹽、糖、醋和胡椒，可真正需要時，還是得一個一個打開聞。
企業文件經常就是如此。
同一條退款政策可能有三個版本；某產品已經下架，舊話術卻還留著；文件裡的一個詞，可能在不同業務裡有完全不同的意思，也沒有分類。同一個詞在不同部門可能代表不同事物，同一個業務名稱在不同年份又可能改過幾次。
人都要找半天，AI 也一樣會找錯。
更麻煩的是，AI 的回答很流暢。當它把舊政策與新政策拼在一起時，一般使用者未必看得出問題。錯誤答案愈像正確答案，風險反而愈大。
因此第一層要補的是資料治理。至少要把以下事情說清楚：
- 哪些內容正確，哪些已經失效；
- 文件如何分類，每類問題應該去哪裡檢索；
- 同一概念在不同系統中叫什麼，是否需要統一詞彙表；
- 不同身分可以看到哪些內容，敏感資訊如何隔離；
- 誰負責更新，舊版本何時下線；
- 回答到什麼程度才算正確，又要如何持續發現錯誤。
AI 可以參與分類、去重與整理，但分類體系、維護責任與驗收標準，仍要由企業自己定義。
資料治理不是做一次大掃除就結束。業務規則會改、產品會下線、組織會調整，今天正確的內容半年後可能不再正確。知識庫必須有持續維護的入口，否則很快又會變回原樣。
做到這裡，客服不只是「接入大型模型」，而是能依據有效的企業知識回答問題。找不到依據時，它應直接說不知道，而不是編出看似合理的答案。
怎麼判斷第一階段是否完成？不是看展示時能不能回答幾個事先準備的問題，而是看真實使用者換一種說法、連續追問、問到權限邊界時，系統是否仍能找到正確依據。只有這一步穩定後，才有必要繼續深入業務系統。
第二階段：AI + Tools，讓 AI 查到這筆訂單
到了第二階段，問題開始涉及特定訂單。
要回答開頭的問題，AI 需要呼叫訂單查詢工具，取得這位使用者的訂單與物流狀態。查到訂單還在倉庫後，才能告訴使用者真正原因。
如果使用者接著要求退款，系統還要呼叫退款工具。
到了這一步，AI 不只讀取企業知識，也能使用業務系統完成一件具體的事。這就是 AI + Tools。
Tools 可以理解為企業提供給 AI 的一組能力入口。查詢訂單是一個工具，取得物流資訊是一個工具，計算退款金額是一個工具，真正送出退款又是另一個工具。
AI 負責理解使用者的話、選擇合適的工具，再把工具回傳的資料整理成使用者能理解的結果。
聽起來不複雜，問題卻隨之而來。
一個老系統裡可能同時存在十幾個退款介面。有些是舊版、有些只退優惠券、有些必須傳內部欄位，還有些執行失敗後不會回傳清楚原因。
把所有介面都交給 AI，讓它自己猜該用哪一個，不會讓老系統變聰明，只會暴露原本藏起來的問題。
過去這些介面由熟悉系統的開發人員呼叫。他們知道哪個能用、哪個只是歷史遺留，也知道哪個參數雖然標示為可選，實際上不傳就會出錯。AI 沒有這些預設知識，只能根據提供的說明判斷。
工具名稱含糊、參數定義不完整、回傳結果不一致時，再強的模型也可能選錯。
從第一階段到第二階段，關鍵是工具治理
工具治理不是簡單包裝舊介面，而是重新回答幾個基本問題：
- 這個工具究竟解決什麼問題，什麼情況下不能使用；
- 呼叫時必須提供哪些參數，參數從哪裡取得；
- 成功、失敗與部分成功時，分別回傳什麼結構；
- 哪些角色有權呼叫，可以讀取與修改哪些資料；
- 查詢類操作可以呼叫幾次，修改類操作是否需要確認；
- 同一請求重複到達時，如何避免重複退款或重複建立訂單；
- 每次呼叫由誰發起、輸入什麼、結果如何，能否完整追溯。
其中很容易被忽略的是冪等性。
假設退款工具呼叫後網路逾時，AI 不知道退款是否成功，於是又呼叫一次。如果介面沒有防止重複的機制，同一筆訂單可能被退兩次。
這不是模型聰不聰明，而是工具本身是否已為自動化呼叫做好準備。
先讓維護系統的人能說清楚工具怎麼用，再把它交給 AI。工具愈少、職責愈清楚，AI 愈容易做對。十幾個歷史介面最好收斂成少數穩定的業務能力入口，而不是把所有複雜度推給模型。
到這裡，還要區分兩件事：執行一條指令，與完成一個任務。
查詢訂單、讀取物流、發起退款，分別都是明確指令。使用者說一步，AI 呼叫一個工具，取得結果後停下來，這屬於 AI + Tools。
但如果只告訴它最終目標，讓它自行判斷先做什麼、後做什麼，中間遇到問題還要繼續處理，事情就進入下一階段。
第三階段：Copilot，讓任務繼續往下走
再加一個條件：查一下這筆訂單，如果還沒出貨就直接退款。
這次不是呼叫一個工具就結束。系統要先確認使用者和訂單，再查詢物流、判斷是否符合退款條件、計算金額、發起退款，最後告知結果。
AI + Tools 比較像人說一步、AI 做一步。Copilot 則是人給出目標，AI 圍繞目標把幾個步驟串起來；遇到不確定或高風險之處，再停下來交由人處理。
過程中，AI 會不斷重複一個循環：理解目前目標、判斷下一步、呼叫工具、讀取結果，再依新結果決定後續動作。
訂單已出貨，就不該繼續走未出貨退款；退款工具回傳金額異常，就應暫停；使用者身分未驗證，也不能直接修改訂單。每一步的結果都會改變下一步應該做什麼。
這就是任務閉環。
因此第二與第三階段的差別，不是 AI 能否一次呼叫多個工具，也不只是由唯讀變成可寫。真正的差別在於：系統能否圍繞一個目標持續運行，直到任務完成、失敗，或需要人接手。
但工具串起來後，新的問題也會出現。
第一個問題：意圖治理
真正麻煩的地方，往往不是某個工具不會呼叫，而是一開始走錯流程。
例如，使用者發現物流三天沒有更新，同時要求投訴和退款。
這個需求同時包含物流異常、投訴和退款。系統若只識別成投訴，可能一直安撫使用者，卻沒處理退款；如果直接退款，又可能漏掉訂單狀態和退款條件。
它需要先判斷屬於哪個業務領域，再把模糊表達拆成可執行的具體意圖，並決定先後順序。
為什麼不能只做一個很大的意圖分類，讓 AI 直接從幾百個選項中挑選？
因為真實企業業務遠比展示複雜。同一句「幫忙改一下」，在訂單系統可能是改地址，在差旅系統可能是改票，在人資系統又可能是修改員工資料。業務不斷增加後，所有意圖放在同一層，分類會愈來愈混亂。
更合適的方法是分層路由。
第一層先判斷屬於訂單、物流、售後或帳戶；進入訂單後，再判斷是查詢、修改、取消或退款。一句話若包含多個意圖，還要拆開並依照相依關係安排順序。
叫車情境會更明顯。使用者說「明天早上送我到機場」，系統需要知道從哪裡出發、航班幾點、要提前多久抵達；使用者又說「順便幫同行的人也叫一輛」，這裡就出現第二位乘客、第二個出發點，以及可能不同的車型。若把所有資訊塞進簡單的「叫車」意圖，後續流程很容易混在一起。
意圖治理不是替一句話貼標籤，而是把使用者真正想完成的事，逐層收斂成系統可以執行的任務。
從一句話，到可執行任務。
第二個問題：狀態管理
接著再加一個變化。
系統已查完訂單，正準備退款，使用者突然改變主意：先不要退款，改一下收件地址。
合理的做法不是硬著頭皮繼續退款，也不是把先前結果全部丟掉。系統要中斷目前流程、保留已取得的訂單與物流資訊，再判斷地址是否還能修改。
這需要狀態管理。系統既要知道前面聊了什麼，也要知道任務做到哪一步、哪些工具已經呼叫、哪些操作還能撤回。如果退款已送出，就要進入取消或補償流程，而不是假裝什麼都沒發生。
這裡至少有兩類上下文。一類是對話上下文，例如「這筆訂單」指哪一筆、先前確認過什麼。另一類是任務上下文，例如目前走到退款流程哪一步、哪個工具已成功、哪個動作仍待確認。
只保存聊天紀錄不夠。聊天裡可能寫著「準備退款」，但系統還要知道退款指令是否真的送出。反過來，只保存工具呼叫狀態也不夠，因為使用者中途一句「還是算了」就會改變任務目標。
因此 Copilot 要能處理幾種變化：
- 任務中斷後，已完成的結果仍可繼續使用；
- 使用者補充資訊後，流程可從正確位置恢復；
- 多個意圖有相依關係時，可以按順序執行；
- 已產生副作用的操作失敗時，可以回復或進入補償流程；
- 超出能力、資訊不足或風險過高時，可以把任務連同完整上下文交給人。
意圖治理決定有沒有走對路，狀態管理決定任務變化後會不會迷路。
做到這些，AI 才不只是幾個工具外面套一層對話框，而是真正開始參與業務流程。
第四階段：Agent，邊界內的結果由誰負責
到了 Copilot，AI 已能理解目標、安排步驟並持續呼叫工具。那它和 Agent 還差什麼？
差的是責任。
假設一套 AI 客服可以退款，一筆訂單原本只能退 50 元，使用者卻透過誘導讓它退了 5,000 元，最後由誰承擔結果？
如果業務人員仍要逐筆檢查，出問題後又說「是審核的人沒看清楚」，那這套系統仍然是 Copilot。AI 在執行，人還坐在旁邊踩煞車。
Agent 代表另一種承諾：在雙方約定的運行邊界內，業務人員不必再逐筆審核；系統自主決策出錯時，交付這套 Agent 的團隊要對約定範圍內的結果負責。
這不是說 Agent 要無限兜底。
自動駕駛的 L2、L3 可以幫助理解這項變化。L2 仍要求駕駛持續監控；L3 則在限定條件下由系統承擔更多駕駛任務，同時保留接管要求。這個類比只說明任務與監控責任的變化，不能用來推導特定事故中的法律責任。
具體事故由誰負責，仍要看當地法律、產品承諾、運行條件與實際情況。Agent 也一樣：邊界必須事先寫清楚，超出邊界時要拒絕、安全降級或交給人。
例如，退款 Agent 只處理金額不超過 200 元、訂單狀態明確、使用者身分已驗證的一般售後。超過金額、命中異常帳戶、規則衝突時，立即轉給人工。
在範圍內，它可以自行完成；超出範圍，不能為了提高完成率繼續猜。
從 Copilot 到 Agent，關鍵是系統化監管
人工不再逐筆審核後，監管沒有消失，只是從「人盯著每一步」變成「系統自動控制風險」。
無人值守不等於無人監管。
這套系統至少要管住幾類問題：
- 權限： 可以存取哪些系統、讀取哪些資料、執行哪些修改；
- 預算： 一次任務最多呼叫幾次工具、消耗多少資源、處理多大金額；
- 監控： 現在正在做什麼、結果是否偏離目標、異常能否及時發現；
- 風控： 哪些規則絕不能繞過、哪些情況必須重新驗證身分；
- 熔斷： 連續失敗、成本異常或行為失控時，系統能否立即停止；
- 回復與補償： 操作已執行一半時，如何恢復到安全狀態；
- 稽核與評測： 每次判斷能否追溯、極端情況是否反覆測試；
- 責任機制： 出問題由誰回應、誰修復、誰承擔約定範圍內的結果。
難點在於，過去人工審核時存在員工經驗裡的判斷，要轉成系統能執行的規則。
客服看到異常退款，可能憑經驗覺得「不太對」。Agent 沒有這種模糊默契。企業需要繼續追問：究竟是金額異常、次數異常、帳戶異常，還是訂單狀態與申請理由不一致？哪些情況直接拒絕，哪些只需二次確認，哪些必須轉人工？
只有把這些經驗說清楚，系統化監管才真正存在。
同樣地，評測不能只看平均準確率。正常訂單處理得再好，只要極端輸入可以繞過權限，或連續失敗後仍不停呼叫工具，就不能放進無人值守的環境。
可靠的 Agent 不只需要效果好的模型，還需要明確的運行範圍、持續監控、人工接管、事故回應與恢復能力。
依照這套框架，Agent 不是把 Copilot 換成更流行的名稱，而是對邊界內自主結果作出的責任承諾。
企業應該從哪一層開始？
先別問「如何做一個 Agent」，看看目前系統缺什麼。
找出目前最薄弱的一層，從那裡開始。
如果企業知識還不準確，就先整理資料，不要急著讓 AI 回答所有問題。
如果 Chatbot 已能說對，就把混亂的舊介面整理成清楚、安全、可追蹤的工具。
如果工具已能使用，就補上意圖治理和狀態管理，讓系統在正確工作流程裡持續推進。
如果 Copilot 已能穩定完成多步任務，再把人工監督中真正有效的規則，沉澱成系統可執行的權限、風控、熔斷、稽核與責任機制。
可以把這四層行動說得更具體。
第一層：先整理知識
選一個邊界清楚、問題集中的業務情境，不要一開始就放入全公司的所有文件。先確認知識來源、分類方式、權限與維護人，再用真實問題反覆測試。
第二層：再整理工具
從查詢類工具開始，先讓入口和回傳結果穩定。涉及修改資料的工具，要把權限、確認、冪等性與稽核放在前面，不要等出錯後才補。
第三層：建立任務閉環
選擇步驟不多、結果容易驗收的流程，驗證意圖拆分、任務狀態、中斷恢復與人工接管。能穩定走完一個流程，比同時做十個半成品更有價值。
第四層：逐步擴大自主邊界
先寫清楚哪些任務可以無人值守，再為這個範圍配置預算、監控、風控、熔斷、補償與責任人。驗證穩定後再逐步擴大，不要一開始就追求什麼都能做。
中間版本可以不正式上線，但背後的能力建設與驗證不能跳過。
四個階段也不是要求所有企業都走到最後。有些業務停在 Chatbot 就夠了；有些操作風險很高，長期保留人工確認反而更合適。
寫在最後
Chatbot、AI + Tools、Copilot、Agent 不是所有企業都必須照做的業界標準，也不是走到第四階段才算成功。
這套劃分真正想處理的是另一個更實際的問題：當 AI 專案做不下去時，我們能否看清楚真正缺的是什麼？
回答不準，先看知識與資料；工具經常選錯，先看介面與權限；流程走不完，先看意圖與狀態；不敢讓系統自主運行，再看監管與責任。
每往前一步，都會暴露下一層原本被人掩蓋的問題。過去靠員工經驗記住的規則，會變成資料問題；靠開發人員默契呼叫的介面，會變成工具問題；靠業務人員盯著處理的異常，會變成治理問題。
接入更強的模型，不會讓這些問題自動消失。
現在所有人仍在探索，許多概念的邊界也會繼續變化。與其急著證明已經做出 Agent，不如先選一個真實情境，讓系統穩定回答正確一個問題、用好一個工具、完成好一段流程。
實踐會告訴我們下一步缺什麼。
先判斷目前在哪一層，再把這一層真正補好。企業老系統接入 AI，才不會只是多一個看起來很聰明的對話框。
參考資料
- NHTSA，Automated Vehicle Safety；SAE，J3016 Levels of Driving Automation。
- NIST，AI Risk Management Framework Core。
- Anthropic，Building Effective AI Agents。
關注微信公眾號
如果你也關注企業 AI、Agent 與真實業務落地，歡迎關注微信公眾號「劉路飛」。之後還會繼續談這些問題。
Luffy Liu · 劉路飛，獨立產品構建者，持續記錄企業 AI、Agent 與真實工作流程。
繼續閱讀
Independent product builder · AI, agents and real workflows.