讓系統能被 AI Agent 操作：後台 API 與權限設計的 8 個原則（2026）｜山葵組
重點摘要
AI Agent 操作企業系統有兩種方式：透過 API（包含 MCP），或像人一樣操作網頁介面。好的系統設計能同時支援兩者。
核心原則是「人和程式用同一套介面」：後台的每個動作都有對應的 API，而不是另外開發一套給機器用的介面。
權限要細到模組與動作，AI 代表使用者操作時，只能做該使用者本來就能做的事。
操作紀錄要區分是人還是 AI 執行，高風險操作要能確認、能復原。
AI Agent 怎麼操作系統：兩種方式
方式 | 運作原理 | 優點 | 限制 |
|---|---|---|---|
透過 API 或 MCP | AI 呼叫系統提供的工具或 API，直接傳送結構化資料 | 快速、穩定、結果可預期，權限與紀錄容易控管 | 系統必須有完整的 API，沒有的功能就無法操作 |
操作網頁介面 | AI 讀取畫面或網頁結構，模擬點擊與輸入 | 不需要額外開發，任何網頁都能嘗試操作 | 速度較慢，介面改版就可能失效，非標準元件容易操作失敗 |
實務上，重複性高、需要穩定執行的作業適合走 API；臨時性、跨多個系統的查詢，則常由能操作網頁的 AI 處理。系統設計得好，兩種方式都能順利運作。
系統設計的 8 個原則
一、介面上的每個動作，都有對應的 API
最常見的問題是：網頁上能做的事，API 做不到。例如後台可以批次修改狀態，但 API 只能一筆一筆更新。最根本的解法是讓網頁介面本身就呼叫同一套 API，人能做的事，程式自然也能做，不需要另外維護一套「給機器用的版本」。
二、欄位定義寫清楚，讓 API 能自我說明
每個欄位的型別、是否必填、可選的值、格式與用途都要明確定義，並能透過 API 文件或欄位定義查詢。AI 不會猜測「status 填 1 代表什麼」，定義越清楚，呼叫錯誤越少。
三、表單使用標準的 HTML 元件
能操作網頁的 AI，多半是讀取網頁的結構與無障礙資訊來判斷「這是什麼欄位、按鈕做什麼」。使用標準的輸入框、下拉選單、按鈕，並正確標示欄位名稱，AI 就能準確操作；用自訂元件拼湊出來的介面，對 AI 和使用輔助工具的使用者都不友善。
四、權限細到模組與動作
權限至少要能區分「哪個模組」與「讀取、新增、修改、刪除」。這樣才能做到：AI 助手可以查詢訂單，但不能取消訂單；可以建立工單草稿，但不能直接送出。
五、AI 代表使用者操作，不使用萬用帳號
AI 執行的每個動作，都應該以某位實際使用者的身分進行，沿用他原本的權限。常見的授權方式如下：
方式 | 適合情境 | 注意事項 |
|---|---|---|
OAuth 代理授權 | AI 應用代表使用者操作，例如透過 MCP 連線的 AI 工具 | 使用者明確同意授權範圍，可隨時撤銷 |
個人存取權杖 | 使用者自行設定的自動化腳本 | 限制權限範圍與有效期限，避免長期有效的萬用權杖 |
專用服務帳號 | 無人值守的排程作業 | 只給完成該作業需要的最小權限，並在紀錄中清楚標示 |
六、高風險操作要能確認、能復原
刪除、批次修改、對外寄送、金額異動這類操作，執行前要讓使用者確認。資料層面則建議採用軟刪除與版本紀錄，就算 AI 做錯，也能回溯到修改前的狀態。
七、操作紀錄區分人與 AI
每筆操作紀錄除了記下使用者，也要記錄是否透過 AI 執行、由哪個 AI 應用發起。發生問題時才能釐清責任，也能從紀錄中觀察 AI 最常做哪些操作、哪些常出錯。
八、錯誤訊息要說明原因與下一步
「操作失敗」對 AI 沒有幫助；「訂單已出貨，無法修改收件地址，請改為建立退換貨申請」則能讓 AI 自行調整做法。另外，API 要能安全地重試：網路中斷後重送同一個請求，不應該建立兩筆重複的資料。
檢查清單：系統準備好了嗎？
項目 | 怎麼檢查 |
|---|---|
API 涵蓋率 | 列出後台最常用的操作，確認每一項都能透過 API 完成 |
欄位定義 | 不看程式碼，只看 API 文件或欄位定義，能否正確填寫每個欄位 |
介面元件 | 用鍵盤能否完成表單操作、欄位是否有清楚的名稱 |
權限粒度 | 能否建立「只能查詢、不能修改」的角色 |
操作紀錄 | 能否查到某筆資料被誰、在什麼時候、以什麼方式修改 |
可復原性 | 誤刪或誤改的資料能否還原 |
既有系統怎麼改造
大部分系統不需要重寫，可以分階段補強：
盤點高頻操作：找出使用者最常做、最重複的後台作業，作為第一批開放給 AI 的範圍。
補齊 API：確認這些操作都有對應的 API，缺的先補上。
細化權限：把權限拆到模組與動作，並建立適合 AI 使用的角色範本。
補上紀錄與復原：加入操作紀錄、軟刪除與版本紀錄，可參考資料版控與稽核。
包成 AI 工具：在 API 之上開發 MCP Server，讓 AI 應用可以直接使用，做法可參考MCP Server 開發實作。
常見錯誤
錯誤 | 後果 |
|---|---|
另外開發一套「給 AI 用」的 API | 兩套介面的商業規則逐漸不一致，維護成本加倍 |
讓 AI 使用管理員帳號 | 權限控管形同虛設，出問題也無法追溯是誰的操作 |
只在介面上擋權限，API 沒有檢查 | 透過 API 就能繞過限制 |
錯誤訊息只有代碼 | AI 無法判斷該怎麼修正，只能反覆重試或放棄 |
常見問題
能操作網頁的 AI 越來越多，還需要做 API 嗎？
需要。操作網頁的方式適合臨時性的任務，但速度較慢、介面一改版就可能失效。需要穩定、大量執行的作業，透過 API 仍然是最可靠的方式。
一定要做 MCP 嗎？
不一定。API 完整、權限清楚是基礎；MCP 是讓 ChatGPT、Claude 等 AI 應用更容易使用這些 API 的一層包裝。先把 API 與權限做好，之後要接 MCP 只是多一層轉接。
AI 操作出錯怎麼辦？
從設計上降低影響：高風險操作需要確認、資料有版本紀錄可以還原、每筆操作都有紀錄可以追溯。同時從紀錄中找出常出錯的操作，調整工具說明或權限範圍。
舊系統要全部重寫嗎？
多數情況不需要。從最常用的幾項操作開始補 API、細化權限、加上紀錄，就能逐步開放給 AI 使用。
結語
讓系統能被 AI Agent 操作，關鍵不在導入哪一套 AI 工具，而在系統本身的設計：介面與 API 同源、欄位定義清楚、權限細緻、紀錄完整。這些原則同時也讓系統更好維護、更容易與其他系統整合。規劃新系統或改造既有系統時，可參考客製化系統開發；想在後台直接加入 AI 助手，則可參考全域後台 AI 助手。