AI Agent 如何串接 ERP：讓 Agent 安全讀寫進銷存、訂單、庫存的架構與權限邊界

當一個團隊決定讓 AI Agent 去接 ERP，腦中浮現的畫面通常很美好：以後問庫存、查訂單、改數量都用講的，Agent 自己去系統裡讀寫，省下一大堆翻畫面、key 資料的時間。但真正讓人睡不著的，從來不是「接不接得上」這個技術問題——接上其實不難。真正危險的是接太大、權限給太寬：一個 Agent 如果能直接改整批庫存、能直接送出採購單、能直接改訂單金額，那麼它任何一次誤判，傷害的就不是一格欄位，而是一整批進銷存資料的正確性。ERP 是公司的帳本，帳本錯了，後面所有的決策都跟著錯。這篇文章站在要為這本帳負責的業務角度，講清楚怎麼讓 Agent 安全地讀寫 ERP，以及最關鍵的——該在哪裡把權限邊界畫死。

一、先把「Agent 接 ERP」拆成讀與寫兩件事

要安全地接 ERP，第一個該建立的觀念是：讀資料跟寫資料，是風險完全不同的兩件事，必須分開對待。讀資料（查庫存、查訂單狀態、查客戶的歷史交易）就算 Agent 抓錯，最多是回答錯一次，不會動到帳本本身；但寫資料（改庫存數量、建立採購單、修改訂單）只要錯一次，就直接改變了系統裡的真實狀態，而且往往會連動到出貨、財務、報表。

┌──────────────┐
│   AI Agent    │
└──────┬───────┘
       │ 經過權限閘門
       ▼
┌──────────────────────────────────────────┐
│              ERP 系統                       │
├──────────────────────┬────────────────────┤
│   讀取區（低風險）       │   寫入區（高風險）      │
│  ├ 查庫存 / 訂單狀態     │  ├ 改庫存數量          │
│  ├ 查歷史交易           │  ├ 建立 / 送出採購單     │
│  └ 查客戶基本資料        │  └ 修改訂單金額         │
│   → 可較大方放行         │   → 預設一律先擋，需核可  │
└──────────────────────┴────────────────────┘

這張圖想說的核心是：讀取區可以較大方地放行給 Agent，因為它頂多答錯、不會壞帳；但寫入區必須預設「一律先擋」，每一個寫入動作都要明確決定它是「Agent 可自動執行」還是「Agent 只能提案、要人核可」。把讀與寫切開來看，你才能對症下藥，而不是糊成一團一起給或一起不給。

二、最該畫死的，是「寫入動作」的權限邊界

接 ERP 真正的功夫，全在寫入區這一塊。這裡的關鍵不是「要不要讓 Agent 寫」，而是「哪些寫入可以自動、哪些必須人核可」。判斷的依據，是這個動作一旦錯了、後果有多難收回。我自製了一張權限對照表，把常見的 ERP 寫入動作，依風險高低排出建議的權限層級，方便你照著對到自己的處境：

這張表最該記住的原則是：愈是「一次影響一大批、且很難回復」的動作，愈要往下推到人工。Agent 適合做的是那些「就算錯了也容易發現、容易改回」的小動作，以及把高風險動作「整理成一份清楚的提案」讓人快速核可。讓 Agent 提案、讓人按下確認，這個分工才是安全與效率的平衡點。

三、用一段限定權限的 Prompt，把邊界寫進 Agent 的行為裡

權限邊界除了靠系統層的設定，也要寫進 Agent 自己的行為準則裡，讓它在動手之前先自我約束。以下這段 Prompt 可以放進 Agent 的系統設定，讓它在面對 ERP 寫入時，先分辨自己該自動做、還是該轉成提案：

你是一個被授權操作 ERP 的助理。面對任何「會改變 ERP 資料」的請求，請先依下列規則判斷，再行動：

【可直接執行】只有以下這類低風險動作可自動做：加備註、查詢、產生報表草稿。執行後回報你做了什麼。

【必須轉成提案，不可自行送出】以下動作一律改成「提案模式」：修改訂單數量或金額、建立或送出採購單、調整實際庫存。
  提案時請輸出：要改什麼、改前與改後的值、影響範圍、為什麼。等人回覆「確認」後才執行。

【一律拒絕】大批量修改、刪除資料、跨多筆訂單的連動修改：直接拒絕並建議由人工處理。

【遇到不確定】只要你對「這算高風險還低風險」沒把握，一律當成高風險，轉成提案。

這段 Prompt 沒有放任何框線字元，所以它就是一段乾淨的可用工具，不會被站台當成架構圖。把它寫進 Agent 的行為裡，等於是在系統權限之外，又多了一層「Agent 自己會先踩煞車」的保險。

四、導入 SOP：從唯讀開始，一步步放寬

知道了讀寫要分、邊界要畫，接下來是務實地決定「怎麼開始接」。最安全的導入順序，是從風險最低的唯讀開始，確認穩了再一格一格往寫入放寬。以下這套 SOP 可以直接照做：

第一步，先只給唯讀權限。讓 Agent 只能查、不能改，跑一段時間，觀察它查出來的資料準不準、會不會誤解欄位的意思。這一步沒有任何寫入風險，是建立信任最便宜的方式。第二步，盤點所有寫入動作並分級。把 Agent 可能會碰到的每一個 ERP 寫入動作列出來，照上一節那張表分成「可自動、需核可、禁止」三類。第三步，先開放最低風險的自動寫入。只把「加備註」這類錯了也無傷的動作開給 Agent 自動做，其餘全部維持提案模式。第四步，建立提案核可流程。對需核可的動作，明確規定 Agent 的提案要顯示哪些資訊、由誰看、在哪裡按確認，讓核可這件事快到不會變成瓶頸。第五步，全程留稽核軌跡。Agent 對 ERP 的每一次讀與寫，都要有紀錄可查：誰要求的、Agent 做了什麼、改了哪些值。出事時能追，平時能檢討。

這套順序的精神是：信任是一步步給出去的，不是一次梭哈。先讓 Agent 在唯讀區證明它可靠，再讓它在低風險寫入區證明它穩定，最後才談更大的授權。

五、設想情境：一個沒分讀寫就全開的庫存助理

設想一個情境，幫你把上面的邊界對到實際工作。某個團隊想省下倉管每天回報庫存的時間，於是接了一個 ERP Agent，圖方便，一開始就把讀寫權限全開，讓它可以直接依現場回報去改庫存數字。前期確實很順，直到某天有人用口語跟它說「那批貨幾乎都出掉了」，Agent 把「幾乎都出掉」理解成「歸零」，直接把那個品項的庫存改成 0，連帶觸發了系統的補貨提醒與一連串下游動作，等到財務對帳時才發現整批數字錯了。

這個設想情境（非真實公司、非真實數據）想凸顯的，不是 Agent 笨，而是它被放在一個「寫入沒有任何閘門」的位置。如果當初照前面的分級，把「大批量改庫存」這種動作劃進「禁止自動執行、只能提案」，那麼 Agent 頂多是送出一則「建議將某品項庫存改為 0，請確認」的提案，由倉管看一眼就會發現語意被誤解，根本不會真的動到帳本。問題從來不在 Agent 會不會誤解語意——它一定會偶爾誤解；問題在於你有沒有在它誤解時，留一道讓人攔下來的閘門。

六、ROI 評估：把「省下的操作時間」和「一次改錯帳的代價」放在同一張表上比

替 ERP Agent 算划不划算時，最容易犯的錯，是只盯著它每天替你省下多少查單、key 單的時間，卻沒把另一邊——萬一它在寫入區改錯一次帳，要花多少力氣追查、回補、對帳，以及這段期間根據錯誤庫存做出的補貨或出貨決策——一起放進來算。對 ERP 這種牽一髮動全身的系統，後面這項風險成本不能當成可以忽略的小數點，它一旦發生，往往一口氣就把好幾個月省下的時間全吃回去。

所以比較聰明的算法，是把兩種授權策略並排估：一種是「讀寫全開、追求最大省時」，另一種是「讀放寬、寫嚴格核可、犧牲一點速度換安全」。把這兩條路各自的預估省時、預估出錯機率與單次救火成本，帶進站內的 AI ROI 計算機與自動化效益計算機分別跑一遍，你算出來的多半不是「該不該接 Agent」，而是「該用哪一種授權策略接」。當你把那筆被忽略的改錯帳成本一筆筆列出來時，會發現多花一點時間做核可流程，買到的其實是讓整本帳睡得著覺的安心。

❓ 讀完後，先問自己這幾個問題

1. 你打算開給 Agent 的 ERP 動作裡，哪些是「讀」、哪些是「寫」，你分得清楚嗎？　引導思路：先把這兩類切開，你才知道哪些可以大方放行、哪些要嚴防死守，別讓它們糊成一團一起授權。

2. 在所有寫入動作裡，哪一個一旦 Agent 改錯就「很難回復、影響一大批」？　引導思路：把這個動作找出來，它就是你第一個該劃進「禁止自動、只能人工或提案」的對象，安全要從最貴的那一格守起。

3. 如果 Agent 哪天誤解了你的口語指令，你的流程裡有沒有一道讓人攔下來的閘門？　引導思路：誠實回答這題，你就會知道自己現在這套接法，是有提案核可的保險，還是把帳本直接交給了一個會偶爾誤解的助理。

結語：接 ERP 的功夫，全在權限邊界怎麼畫

讓 AI Agent 接 ERP，技術上接得上從來不是難題，難的是接得安全。安全的關鍵，是把讀與寫分開對待、把高風險的寫入動作劃進「只能提案、要人核可」、從唯讀開始一步步放寬，並且全程留下可追的稽核軌跡。Agent 該扮演的角色，是替你把繁瑣的查詢與整理做掉、把高風險的動作整理成一份清楚的提案，而不是握著一支能直接改動整本帳的筆。把權限邊界畫對，Agent 才會是替你省事的好幫手，而不是一顆隨時可能改錯帳的不定時炸彈。