- 聊天機器人輸出文字，Agent 輸出交付物
- Agent 的四個必要條件：職掌、工具、權限、可稽核的紀錄
- 會動用金錢、個資與對外發言的節點，一定要保留人工確認
- 先編制職務，再選工具，順序反了就會變成買了工具沒人用
一個簡單的判準
要分辨眼前這套系統是聊天機器人還是 Agent，問一個問題就夠了：它跑完之後，留下的是一段文字，還是一份東西？
聊天機器人給你一段文案。Agent 把文案排進發佈時程、產出配圖、送審、發佈，並在四十八小時後回報互動數據。前者是工具，後者是職務。
Agent 的四個必要條件
一、明確的職掌
「幫我處理行銷的事」不是職掌，「每週一產出下週的社群貼文排程，含文案、配圖與 Hashtag，送審後排程發佈」才是。職掌寫得越像徵才啟事，導入後的落差越小。
二、可動用的工具
沒有工具的 Agent 只能建議。要能真的交付，它得能讀信箱、寫行事曆、查訂單、呼叫廣告平台的 API。導入的技術難度通常不在模型，而在這些串接。
三、明確的權限邊界
每一個 Agent 應該對應到一組明確的資料讀取層級與操作範圍。客服 Agent 可以查公開的退換貨政策，但不能查訂單金額；廣告 Agent 可以讀成效，但不能自己調預算。
四、可稽核的執行紀錄
任務怎麼被拆解、走了哪些節點、哪一步等了人確認、哪些旁支被判斷為不必做，都要留下來。出錯時你要看得出是哪一個節點判斷錯誤，而不是重跑一次碰運氣。
把 Agent 當成新進員工來設計，而不是當成軟體功能來設計。你會問新人「這件事你做完要交什麼給我」，就該問 Agent 同樣的問題。
哪些節點一定要停下來等人
自動化程度不是越高越好。以下三類節點建議一律保留人工確認關卡：
- 會動到錢的。調整廣告預算、開立折扣、發出報價、執行退款。
- 會碰到個資的。轉出客戶名單、寄送含個資的內容、跨系統同步聯絡人。
- 會對外發言的。社群貼文、公開回覆負評、寄給客戶的正式信件。
把這些關卡設成「Agent 準備好，人按下送出」，實務上既不會拖慢流程，又能把大部分風險擋在外面。準備工作佔了一件事九成的時間，最後那一次確認只要三十秒。
先編制，再選工具
導入失敗最常見的路徑是反過來：先買了一套工具，再想公司裡誰要用。比較穩的順序是：
- 盤點現有流程，找出重複、可規則化的工作。
- 把這些工作按「職務」而不是按「功能」分組，決定要編制幾個 Agent。
- 為每個 Agent 寫下職掌、交付物與權限。
- 最後才決定用什麼工具、串什麼系統來實現。
這個順序的好處是，就算之後換了底層模型或平台，職掌與交付物的定義都還在，不用重做一次。
導入之後會變成什麼樣
成熟的 Agent 編制，日常大致是這樣運作：早上八點半，統籌的 Agent 已經把昨天所有隊友的執行紀錄彙整成一份摘要，標出三件需要主管裁示的事。客服 Agent 整晚接住了進線訊息，答得出來的都附了知識庫出處，答不出來的開了工單。廣告 Agent 準備好調整建議，停在等待核可的節點上。
人的工作沒有消失，只是位置變了——從執行者變成裁決者。這是導入 Agent 真正的價值，也是為什麼它需要被當成組織設計來規劃，而不只是技術採購。
從交辦一件事開始拆
把前面的原則放進一個具體的例子會清楚很多。假設你要交辦「處理展場收到的名片」這件事。
如果是聊天機器人，它能做的是：你把名片文字貼給它，它幫你整理成表格。整理完之後的所有事——寫進 CRM、判斷要不要追、寫信、排提醒——還是你自己做。它省下的是打字時間。
如果是 Agent，這件事會被拆成一串有明確產出的節點：辨識名片並抽出欄位、比對 CRM 避免重複建檔、查核公司背景與過往往來、依互動深度給初始評分、草擬第一封邀約信、等你確認後寄出、未回覆者依節奏排定第二次接觸。你在整條鏈上只出現一次，就是按下送出的那一刻。
兩者省下的時間差了一個量級，但更關鍵的差別是責任歸屬：聊天機器人的產出沒有人驗收，Agent 的產出有明確交付物與完成定義。
怎麼寫一份 Agent 的職掌
導入時最花時間、也最值得花時間的一份文件，是每個 Agent 的職掌書。寫法建議照徵才啟事的邏輯，包含五個段落：
一、負責什麼
一句話講完。「每週一產出下週社群貼文排程」比「協助行銷工作」有用一百倍。如果一句話講不完，代表這應該拆成兩個 Agent。
二、交付什麼
具體到可以驗收。「一週貼文排程，含文案、配圖、Hashtag 與建議發佈時段，週一上午十點前送審」——這樣寫，才有辦法判斷它做得好不好。
三、可以讀什麼
對應到知識庫的分級。客服 Agent 只能讀 L1，數據 Agent 可讀到遮罩後的 L3。這一條決定了它的能力邊界，也決定了出事時的調查範圍。
四、可以動什麼
它能呼叫哪些系統、能寫入還是只能讀取。「可讀取訂單系統、可寫入 CRM 備註、不可修改訂單金額」——權限寫得越細，事後越好稽核。
五、哪一步要停下來等人
把人工確認關卡明確標出來，並寫清楚由誰確認、多久內要確認、逾時怎麼辦。沒有寫逾時處理的關卡，實務上會變成任務永遠卡住。
常見的三個設計錯誤
看過的導入案裡，出問題的設計大多犯了以下其中一個。
錯誤一：做一個什麼都會的萬能 Agent
把所有工作交給同一個 Agent，權限自然要開到最大，於是它同時能讀客戶資料、改訂單、發社群貼文。這種設計的問題不只是資安，還有除錯——出錯時你不知道是哪一段邏輯出問題，因為所有邏輯混在一起。
正確做法是照職能拆開。拆開之後每一個的權限都可以縮到最小，出錯時的調查範圍也明確。
錯誤二：自動化程度追到滿
把所有人工關卡都拿掉，追求「完全不用人」。這在示範時很好看，但實際上線後只要出一次錯——誤發一封信給客戶、多退一筆款——整個專案的信任就會崩掉，而且很難重建。
留關卡不是不信任 AI，是承認任何系統都會出錯，而錯在哪一類事情上是你可以選擇的。
錯誤三：沒有定義「做完」
Agent 跑起來了，但沒有人說得出它什麼時候算完成任務。結果是它一直在跑、一直在花錢，而且沒有人知道該不該喊停。每一個 Agent 都要有明確的完成條件與逾時上限。
導入的順序：先訪談，再編制，最後才選工具
實務上一個可行的導入節奏大概是這樣。
第一到二週：流程盤點。不談 AI，只盤點現在的工作。哪些事每天在重複、哪些事需要判斷、哪些事現在卡在誰身上。這一步的產出是一張現況流程圖與一份「可規則化程度」的分級。
第三到四週：編制設計。依職能決定要幾個 Agent，寫出每一個的職掌書。這一步務必讓實際做這些事的人參與——他們知道哪些例外狀況是設計時想不到的。
第五到八週：知識與權限準備。Agent 要讀的知識整理好，權限矩陣定好。這一段通常會發現前面的職掌書要改，這是正常的。
第九週之後：建置與試運行。先讓 Agent 跑但不真的執行，只產出「它打算做什麼」的紀錄，由人審一到兩週。確認判斷邏輯正確後，才逐步開放它真的動手。
試運行階段的價值常被低估。讓 Agent 空跑兩週，你會看到一堆設計時完全沒想到的狀況，而這時候修正的成本最低。
成效怎麼看
Agent 導入的成效不要只看「省下多少人力」，那個數字既不好算也容易引起內部反彈。比較有說服力的是三組指標：
- 週期時間。一件事從發生到完成需要多久。名片進來到第一封邀約信寄出，從三天縮到兩小時，這個數字很具體。
- 一次做對率。需要返工、修正、重做的比例。這反映的是品質，也是決定能不能繼續擴大自動化範圍的依據。
- 人的工作內容改變。原本花在整理資料的時間，現在花在哪裡。如果答案是「花在別的整理工作」，那代表流程還沒有真的被改掉。
