一份由 Agent 整理完成的營運異常報告，資料齊全、格式正確，也在預定時間內送出，到了跨部門會議卻無法使用。營運團隊以為 Agent 已經判斷原因，技術團隊只把它當成初步分類，主管則以為高風險案件早已有人確認。每一個環節都完成了自己的動作，卻沒有人真正接受最後的結果。
我在管理系統開發與跨部門專案時，越來越常看到這類問題。表面上像是 Agent 判斷不準，往下追才會發現，工作流程裡沒有清楚定義誰執行、誰審核、誰核准，以及出現例外時要交給誰。換一個模型或增加一個工具，通常不會解決這個問題。
企業導入 AI Agent 的成敗，不取決於工具清單有多完整，而取決於是否建立一套能清楚分配責任、權限、交付與問責的人機 Operating Model。工具決定 Agent 能做什麼，Operating Model 才決定組織能不能放心讓它做事。
先設計工作系統，再決定使用什麼 Agent
許多導入計畫從產品展示開始：哪一套 Agent 可以查資料、寫程式、產生報告或操作系統。這些能力當然重要，但如果一開始只談工具，團隊很容易把「功能可用」誤認為「工作可交付」。
管理者更應該先回答四個問題：這項工作要產生什麼成果、誰接受成果、什麼條件算完成、失敗後由誰接手。答案清楚之後，才能判斷流程需要的是 Agent、規則式自動化，還是原本的人工作業。OpenAI 的 Agent 實務指南也建議先確認使用情境是否真的需要 Agent；若工作可以由明確、固定的規則完成，確定性較高的系統可能更合適。
我會把 Agent 視為工作系統中的一個執行角色，而不是額外加進組織的一項功能。角色一旦進入流程，就必須有輸入、輸出、權限、驗收與交接規則。這也是為什麼導入順序應該是「工作、角色、成果、控制點」，然後才是能力與工具。
分工不看工作名稱，要看風險與可逆性
同樣是「整理資料」，可能只是彙整公開資訊，也可能涉及客戶個資；同樣是「修改內容」，可能是更新內部草稿，也可能直接改動對外公告。工作名稱相同，責任配置不能相同。
我在判斷哪些工作可以交給 Agent 時，會同時看五件事：結果是否容易驗證、動作是否可以回復、錯誤影響有多大、是否需要理解組織情境，以及最終責任由誰承擔。可驗證、可回復、影響範圍小的任務，可以讓 Agent 有較完整的執行空間；涉及付款、客戶權益、正式承諾、敏感資料或不可逆操作時，人就必須保留判斷與核准責任。
這也說明 human-in-the-loop 不等於每一步都要人工確認。如果 Agent 每整理一筆資料、每產生一段摘要都要等人按下同意，人工審核很快會成為新的瓶頸。比較有效的做法，是依風險與可逆性安排控制點：低風險結果可抽樣檢查，中風險結果在交付前審核，高風險或不可逆動作則必須事前核准。
Google Cloud 將 human-in-the-loop 描述為在預先設定的檢查點暫停流程，讓人員核准、修正或補充必要資訊。這個設計支持的不是「人要看過所有步驟」，而是「人在關鍵決策點擁有控制權」。
用 Execute、Review、Approve、Escalate 畫出責任
管理者不需要先畫一張複雜的組織圖，可以先把每一段工作拆成四類責任：
- Execute：誰執行資料蒐集、分類、分析、產出或系統操作。
- Review：誰依照驗收標準檢查內容、證據、品質與風險。
- Approve：誰有權接受結果，並允許流程進入下一個不可逆或對外階段。
- Escalate：當信心不足、規則衝突、超出權限或發生異常時，交給誰判斷。
Agent 可以承擔 Execute，也可以協助部分 Review，例如檢查欄位是否完整、數字是否超出門檻、輸出是否符合格式。但 Approve 不是一個按鈕，而是責任的承接；只要結果會影響客戶、財務、法遵、品牌或重大系統狀態，核准者就必須是有權也有能力承擔後果的人。Escalate 則不能只寫「轉人工」，而要寫出接手角色、回應時限、需要附上的紀錄，以及逾時後的下一層負責人。
NIST AI Risk Management Framework 要求組織明確記錄人與 AI 配置中的角色、責任與監督方式，也指出高階主管需要對 AI 系統開發與部署的風險決策負責。這與我的實務判斷一致：Agent 可以執行工作，不能成為責任的終點。
一個端到端流程，必須看得見每次 handoff
以企業營運異常監控為例，假設每天需要整合訂單、流量與系統告警，找出可能影響商業成果的異常。導入前，分析人員花大量時間下載資料、比對報表、整理截圖，再把結果交給技術與營運主管判斷。
導入後，可以把流程設計成這樣：
- Agent Execute：依排程讀取已授權資料，根據既定門檻找出異常，整理證據、影響範圍與初步分類，並保留資料來源與操作紀錄。
- 人員 Review：營運分析人員檢查資料完整性、分類依據與商業情境，確認它不是促銷、活動或已知維護造成的正常波動。
- 主管 Approve：若處置涉及暫停活動、調整預算、通知客戶或改動正式系統，由具權限的主管選擇方案並接受影響。
- 異常 Escalate：資料缺漏、規則互相衝突、影響超過門檻，或 Agent 連續嘗試仍無法完成時，自動把證據、歷程與未解問題交給指定的技術或營運負責人。
這個流程的重點不是 Agent 做了多少，而是每一次 handoff 都有可接受的交付物。Agent 交出的不應只有一句「發現異常」，而要包含使用哪些資料、依據什麼規則、做過哪些操作、信心與限制是什麼。Review 也不能只寫「人工確認」，而要有 acceptance criteria，例如資料期間完整、異常可重現、影響估算有依據、建議動作未超出權限。
當一次異常因為分類不清而被退回時，管理問題通常不是要求人再看仔細一點，而是修正輸入、驗收或升級條件。返工紀錄應回到工作系統，成為下一輪規則、測試與權限調整的依據。
Operating Model 至少要有七個構成
一套可運作的人機 Operating Model，至少要把以下七件事寫清楚：角色與責任、輸入與交付、權限邊界、驗收標準、人工審核、例外升級、稽核紀錄。
角色與責任回答誰做、誰接、誰負責；輸入與交付定義 Agent 可以使用哪些資料，以及結果要以什麼格式進入下一站；權限邊界限制它能讀取、建立、修改與對外送出什麼。驗收標準讓品質可以被判定，而不是靠感覺；人工審核決定哪些控制點需要什麼專業；例外升級確保失敗不會停在無人處理的佇列；稽核紀錄則保留資料來源、工具呼叫、版本、核准者與後續動作。
OpenAI 的指南把 guardrails 視為分層防線，並強調仍需搭配身分驗證、授權、嚴格存取控制與標準軟體安全措施。Anthropic 對可信任 Agent 的討論也把人的控制、透明度、安全與隱私放在同一個治理架構中。這些官方做法共同提醒管理者：不能期待一條提示或一個審核步驟承擔全部風險。
權限設計也不應一次到位。新的 Agent 可以先只有讀取權與草稿權，通過一段時間的測試與觀察後，再開放有限範圍的寫入；只有在品質、例外與稽核機制穩定後，才評估是否允許更高影響的操作。權限擴大應該是管理決策，不是技術團隊順手打開一個 API。
最終責任不能交給 Agent
組織可以把任務交給 Agent，但不能把責任寫成「由 Agent 負責」。Agent 不會設定公司的風險偏好，不會接受績效結果，也不會對客戶、董事會或主管機關說明一項錯誤決策。
最終責任至少包含三個人類角色：有人設定目標與限制，有人接受交付結果，有人對錯誤與商業影響負責。三個角色可能由同一位主管承擔，也可能分屬業務、技術與風險單位，但不能消失在流程圖裡。
這並不代表人要親自完成所有工作。管理的價值是決定哪些判斷能制度化、哪些權限能委派、哪些例外必須回到人。當責任清楚，Agent 的自主程度才能提高；責任模糊時，越高的自主程度只會讓問題更快、更大規模地發生。
衡量成果，不要只計算使用量與節省工時
如果導入成果只看 Agent 使用次數、產出數量或節省多少工時，團隊很容易把更多工作丟進系統，卻忽略返工、誤判與人工救火。真正要衡量的是整條流程是否變得更好。
我會把指標分成四組。效率看端到端週期時間與等待時間；品質看一次通過率、返工率與抽查結果；控制看例外率、人工介入成本、權限違規與風險事件；商業成果則回到流程原本要改善的目標，例如異常處理時間、轉換損失、客訴、系統穩定性或決策速度。
這些指標要一起看。週期時間縮短，但返工率與風險事件上升，不叫效率改善；人工審核時間下降，但例外案件長期無人接手，也不叫自動化成功。NIST 將治理、情境盤點、衡量與風險管理視為持續循環，這個觀點很適合企業用來檢查：每一次擴權之前，是否已經有足夠的紀錄、測量與應變能力。
從低風險流程開始，逐步擴大自主權
我建議第一批流程同時符合三個條件：低風險、可驗證、可回復。例如內部資料整理、需求初步分類、測試草稿、程式碼建議或營運告警彙整。這些工作即使出錯，也能在對外或正式執行前被發現與修正。
試行時先建立基準值，記錄原本的週期時間、品質與人工成本，再用真實案例測試 Agent。接著觀察哪些案件順利通過、哪些需要人工介入、哪些例外沒有被規則涵蓋。只有當 acceptance criteria 穩定、handoff 清楚、升級機制真的有人接手，才逐步增加資料範圍、操作權限與自動化程度。
常見的失敗模式其實都能從這套順序看出來：工具先行，會找不到適合的工作；責任模糊，結果沒有人接受；權限過大，錯誤直接進入正式系統；沒有 acceptance criteria，審核只能憑感覺；每一步都人工確認，審核者變成瓶頸；只設計正常路徑，例外發生時便無人接手。
企業真正需要建立的，不是一張 AI Agent 採購清單，而是一套可以持續調整的人機工作制度。當 Execute、Review、Approve、Escalate 都有明確角色，輸入、交付、權限、驗收與稽核也能被追蹤，Agent 才會從個人工具變成組織能力。
FAQ
企業應如何建立人與 AI Agent 的分工？
先定義工作成果、接受者、驗收標準與風險，再用 Execute、Review、Approve、Escalate 四類責任逐步標示每個 handoff。之後才決定 Agent 能執行哪些任務、可以使用哪些資料與工具，以及什麼情況必須交回人員處理。
哪些工作適合交給 AI Agent？
優先選擇低風險、容易驗證、可以回復，而且輸入與交付明確的工作，例如資料彙整、初步分類、草稿產出、測試協助與異常監控。涉及付款、客戶權益、敏感資料、正式承諾或不可逆操作的工作，應保留人工核准與明確的升級機制。
Human-in-the-loop 是否代表每一步都要人工確認？
不是。人工控制點應依風險、可逆性與錯誤影響安排。低風險工作可採抽樣檢查，中風險交付可在進入下一階段前審核，高風險或不可逆動作則應事前核准。每一步都確認，反而可能讓人工審核成為流程瓶頸。
AI Agent Operating Model 應包含哪些項目？
至少應包含角色與責任、輸入與交付、權限邊界、驗收標準、人工審核、例外升級與稽核紀錄。管理者還應明確指定誰設定目標、誰接受結果，以及誰對錯誤與商業影響負責。
企業如何衡量 AI Agent 分工是否有效？
不要只看使用次數或節省工時。應同時衡量端到端週期時間、等待時間、一次通過率、返工率、例外率、人工介入成本、風險事件，以及流程原本要改善的商業成果。