企業軟體如何成為 AI 可操作的工具？一次看懂 AI Agent、MCP 與 API

受訪專家｜叡揚資訊雲端服務事業處副處長 李宗青
內容企劃｜叡揚資訊雲端行銷團隊

先說結論：
AI Agent 負責理解工作目標、安排步驟與選擇工具；MCP 提供 AI 應用探索與呼叫外部能力的共同溝通方式；API 或服務層則常負責真正連回後端系統。三者不是互相取代，而是處在不同層次。企業評估重點應從「有沒有支援 MCP」，轉向「哪些能力能被 AI 安全、穩定地使用」。

當企業開始把 AI Agent 當成跨系統工作入口，接下來最常遇到的問題是：既有軟體要怎麼讓 AI 使用？是不是只要有 MCP 就可以？原本的 API 還需不需要？

要回答這些問題，必須先把 AI Agent、MCP 與企業系統放在同一條工作鏈上理解。模型可以理解使用者的語言，但真正的資料查詢、表單建立、狀態變更與簽核，仍要由企業軟體提供明確、受控的能力。

一、Agentic AI、AI Agent、MCP 與 API 分別是什麼？

．Agentic AI 談能力方向，AI Agent 承接具體任務

Agentic AI 通常用來描述 AI 從單純回答問題，進一步具備規劃、判斷與採取行動的能力方向。AI Agent 則是把這些能力運用在具體任務上的應用或系統。

在企業情境中，AI Agent 可能協助查詢待簽表單、建立請購、整理訂單進度，或把拜訪紀錄轉成 Call Report。它需要理解使用者的目標、判斷下一步、選擇工具，並依工具回傳結果決定是否繼續、改用其他方式或請使用者確認。

產業對 Agentic AI 與 AI Agent 沒有唯一分界，因此閱讀產品文件時，仍應確認供應商實際提供哪些能力，而不是只看名稱。

．MCP 統一溝通方式，API 提供系統能力

MCP 可以理解為 AI 應用與外部工具之間的一套共同溝通規則。它由 Anthropic 於 2024 年 11 月發布，現為 Linux Foundation 旗下 Agentic AI Foundation 治理的開放標準。它讓伺服器用較一致的方式公開工具、資源與提示等能力，讓 AI 應用知道有哪些功能、需要哪些參數，以及如何取得結果。

API 則是應用系統長期使用的介面方式，用來查詢資料或執行功能。實務上，MCP Server 背後經常仍需要透過既有 API、服務層或程式邏輯連回 ERP、CRM、表單與其他系統。

因此，AI Agent、MCP 與 API 可以簡單分工為：AI Agent 決定要完成什麼與使用哪個工具；MCP 處理 AI 與工具如何認識及溝通；API 或服務層負責系統內部資料與功能如何被執行。

二、AI Agent 如何完成一項跨系統工作？

．從工作目標找出需要的資料與工具

假設使用者對 AI Agent 說：「幫我建立出差申請，確認預算後送出簽核。」這不是單一系統操作，而是一項工作目標。

AI Agent 可能先取得出差日期與地點，再查詢預算或專案資料，接著呼叫表單系統建立申請，最後顯示送出內容並請使用者確認。每個步驟都可能使用不同工具，也可能因資料不足、權限不符或規則衝突而停止。

真正的價值不是 AI 一次呼叫很多系統，而是它能根據明確目標，在合適的順序下取得必要資料並接續流程。

．從 AI 入口一路連回企業系統

一項完整呼叫通常包含幾個層次：

• 使用者透過 ChatGPT、Claude、企業入口或其他介面提出工作目標。

• AI Agent 理解任務，判斷需要哪些資料與工具。

• MCP Host／Client 或其他整合層找到並呼叫適當能力。

• MCP Server、API 或服務層把請求送到實際企業系統。

• 後端系統依身分、權限與商業規則執行，再回傳結果。

這條鏈上的每一層都有不同責任。即使 AI 能正確選擇工具，後端仍必須驗證輸入、確認權限並處理錯誤；即使系統有 API，AI 也需要足夠清楚的工具描述，才能知道何時與如何使用。其中「MCP Server 如何描述與管理工具」這一層，將在本文第四節進一步展開。
▲ 從 AI 入口經 MCP、API 一路連回企業系統的分層架構。

三、既有企業軟體需要先準備什麼？

．有 API 不代表已經適合給 AI 使用

企業系統有 API，是重要基礎，但還不代表已經具備 AI 可操作性。有些 API 是為固定的系統對系統交換設計，可能使用高權限帳號、參數複雜，或回傳大量不適合直接交給模型的資料。

因此，企業仍要確認 API 是否能代表個別使用者執行、資料範圍能否縮小、錯誤是否清楚，以及重複呼叫會不會造成重複新增、付款或送出。對 AI Agent 而言，一個邊界清楚的小工具，往往比一個可以做很多事但難以控制的通用 API 更安全。

．沒有 API 時，不宜直接繞過原系統規則

有些使用多年的舊系統沒有正式 API。如果改由 AI 或中介服務直接存取資料庫，可能繞過原系統的商業規則、權限檢查與操作紀錄。

較穩妥的方式，是先建立受控的服務層、唯讀查詢介面或明確限制的整合能力。若不得不直接取得資料，也應採用最小權限、唯讀視圖、網路隔離與完整稽核等補償控制，而不是把資料庫帳號直接交給 AI 使用。

四、支援 MCP 之後，還要讓 AI「會用」：中間的工具工程

．工具不是越多越好，先決定 AI 看得到什麼

企業系統的 API 動輒數百支，如果全部直接變成 AI 工具，模型每次都要在數百個選項中判斷，不僅消耗大量 token，也更容易選錯。工具不是越多越好，先決定哪些能力值得讓 AI 看到，是支援 MCP 之後的第一項工程。

實務上有兩種收斂方式。一是逐支決定開放範圍，只把適合 AI 使用的能力暴露出來，例如一套系統有三百多支 API，實際只開放其中一百支；二是採用「探索式」工具設計——AI 先透過少數固定工具列出端點、查詢資料結構，確認後才真正送出請求。後端接了幾百支 API，AI 看到的工具數量仍維持不變，權限邊界也更容易管理。

▲ 端點逐支開關：只把適合 AI 使用的能力開放出來。（畫面為示範環境）

．API 文件是寫給工程師的，AI 需要另一層描述

原始 API 文件的描述通常只寫「取得站台清單」這類給工程師看的說明，AI 無法從中判斷什麼情境該用這支、參數該怎麼填、回傳結果代表什麼。因此工具描述需要另外經營：什麼時候該用、必要參數的業務意義、常見錯誤各代表什麼。

描述也適合分層——探索清單只給簡短摘要，完整提示等 AI 真正要使用時才提供，避免掃一次清單就吃掉大量 token。而降低 AI 誤填參數的一項有效做法，是直接附上使用範例：一段情境描述加一份正確的請求內容，往往勝過再多的參數說明。

▲ 在原始 API 文件之上，另外經營探索摘要、AI 提示與使用範例。（畫面為示範環境）

．業務術語要先對齊，領域知識放在設定而不是程式碼

每個企業都有一詞多義的詞彙。使用者口中的「表單」，指的是可以填寫的樣板，還是已經填好的資料？「客戶」是 CRM 裡的公司，還是聯絡人？這些對應若只存在員工的默契裡，AI 就會照字面猜。

把術語、同義詞與消歧義說明整理成可維護的對應表，AI 才能把口語需求翻成正確的系統操作；換一套業務系統時，也只需要換這張表，而不是修改程式。

▲ 術語對應與消歧義提示：把領域知識放在設定，而不是程式碼。（畫面為示範環境）

．常用操作可以預先封裝，高頻參數不必讓 AI 每次都填

AI 最容易出錯的，往往是那些「其實每次都一樣」的參數。把常用操作連同固定參數預先封裝成獨立工具——例如「查詢本月資料」固定日期範圍，只留關鍵字與頁數讓 AI 填——可以同時降低錯誤率與確認成本。

▲ 自訂工具：把常用操作連同固定參數封裝成獨立工具。（畫面為示範環境）

工具之間也可以加上流程引導：用完這個工具之後建議接哪一個、出錯時該往哪走，讓 AI 的多步驟操作有可預期的路徑。

．不是所有結果都適合用文字回，上傳檔案也不必經過模型

API 回傳一大包 JSON，AI 轉述費 token，使用者也讀得辛苦。查詢結果可以只挑必要欄位，以表格或卡片等介面直接呈現；需要逐欄填寫的流程，可以在對話中開出一張真正的表單，填完送出才把結果交回 AI；單純的檔案上傳與轉交，應由使用者直接選檔、系統直接接收，內容不經過模型；若任務本身需要模型理解檔案（例如摘要或比對），再於明確目的、權限與資料政策下處理。這些互動設計讓 AI 入口保有對話的彈性，又不失結構化介面的精確。
▲ 查詢結果以表格直接呈現，只顯示設定的欄位。（畫面為示範環境）

▲ 需要逐欄填寫的流程，在對話中開出真正的表單，填完送出才把結果交回 AI。（畫面為示範環境）

以叡揚資訊為 Vital BizForm 建置的 MCP Server 為例，上述工作——端點開放範圍、AI 描述與使用範例、術語對應、自訂工具與回應呈現——多數能以管理後台的設定完成，減少反覆修改整合程式的成本；同一個後台也涵蓋敏感資料防護（DLP）與稽核日誌等治理配套。這說明「支援 MCP」只是起點，真正決定 AI 用不用得好的，是這一層持續的工具經營。

．工具之外，還可以提供方法：Skill

除了把能力做成工具，軟體供應商也開始把「這類工作該怎麼做」整理成可下載的 Skill——一份 AI 入口可以載入的工作方法說明，內容包含操作步驟、判斷原則與常見情境。例如查詢表單前應先確認分類、遇到複雜欄位時如何逐步引導使用者補齊、送出前如何檢查附件完整性、連線異常時如何自我診斷與恢復。

工具描述回答的是「這支工具是什麼」，Skill 回答的是「這件工作該怎麼進行」，兩者互補。以 Vital BizForm 為例，官方已提供表單檢索、欄位引導、附件稽核與連線診斷等 Skill 供下載，使用者將其加入支援的 AI 工具後，有助於提升 AI 處理對應工作時的穩定度與正確率。

五、如何判斷一套軟體是否具備 AI 可操作性？

．能力邊界：AI 到底可以做什麼？

系統應把查詢與動作拆成用途清楚的能力，說明名稱、必要參數、資料範圍、前置條件與可能結果。避免只提供一個權限過大、行為模糊的通用入口。

．身分與權限：AI 代表誰做事？

企業需要區分使用者委派與系統帳號，並確認權限由後端真正執行。AI 的提示或工具說明可以提醒規則，但不能取代身分驗證與授權。

．結果與錯誤：AI 能不能知道發生什麼事？

成功結果要包含必要識別資訊，例如單號、狀態與時間；失敗時則應回傳可判斷的原因，例如缺少欄位、權限不足或資料已變更。清楚的錯誤能避免 AI 盲目重試或產生看似成功的回答。

．風險控制：哪些動作需要人確認？

付款、刪除、對外寄送、正式簽核、權限變更或大量匯出等動作，應在執行前顯示對象、範圍與影響，並由使用者確認。系統也要考慮冪等、撤銷與補償流程。

．維運與稽核：出了問題能不能追查？

企業應記錄使用者、工具、參數、執行結果、時間與核准資訊，同時管理版本、效能、費用與相依服務。AI 工具一旦成為正式流程的一部分，就需要和其他企業介面一樣被監控與維護。

六、企業應該如何安排第一個導入情境？

．選擇跨系統、可量化、風險可控的流程

第一個情境不必追求最複雜或最吸睛，而應選擇重複發生、需要跨系統查詢或搬運資料，而且改善成效可衡量的工作。

例如表單建立前查詢 ERP 預算、整合 CRM 與訂單狀態、彙整待簽項目，通常比直接讓 AI 執行付款、刪除或權限變更更適合先驗證。企業可以用處理時間、人工步驟、錯誤率或完成率作為指標。

．從最小可用範圍驗證，再逐步擴大

導入時可以先限制資料範圍、工具數量與使用者群組，保留人工確認，再觀察 AI 是否能正確選擇工具、處理錯誤並遵守權限。當流程與紀錄穩定後，再逐步增加系統、動作與自動化程度。
這種做法能同時驗證商業價值與治理能力，也比較容易找出問題究竟發生在模型判斷、工具描述、API、資料或流程設計。

結語：不要只問「支不支援 MCP」，要問「AI 能否可靠完成工作」

支援 MCP 是企業軟體面向 AI Agent 的重要能力，但它只是完整工作鏈的一部分。系統仍要提供可用的資料與功能，執行正確的身分與權限檢查，回傳清楚結果，並留下可追蹤紀錄。工具開放之後，描述、術語、範例與互動方式的持續經營，才是 AI 能否穩定完成工作的關鍵。
企業評估一套軟體時，真正該問的是：AI 能使用哪些能力？代表誰做事？失敗時會發生什麼？高風險動作如何確認？操作能否稽核與復原？
當這些條件清楚後，MCP 才能從技術規格變成降低整合成本、讓不同 AI 入口使用企業能力的實際工具。下一篇將進一步討論，當 AI 不只查詢而能執行工作時，權限、資料與資安治理應如何延續。

常見問題 FAQ

1. AI Agent 一定要使用 MCP 嗎？

不一定。AI Agent 也可以透過函式呼叫、API、SDK 或客製程式使用企業系統。MCP 的價值在於提供較一致的工具探索與溝通方式，降低不同 AI 應用重複開發連接層的成本。

2. 導入 MCP 後，企業還需要 API 嗎？

通常需要。MCP Server 常透過既有 API、服務層或其他受控介面連回企業系統；如果後端沒有可用能力，MCP 不會自動補上缺口。

3. 哪些流程最適合先導入 AI Agent？

優先選擇需要跨系統查詢、規則判斷或重複搬運資料，而且目標與成效可以量化的流程。不可逆、高影響或難以復原的動作，不適合一開始就完全自動化。

4. 為什麼有了 API 與 MCP，AI 還是會用錯工具？

常見原因是工具過多、描述只寫給工程師看、業務術語未對齊，或缺少使用範例。這些屬於工具設計與描述經營的範疇，需要像維護 API 文件一樣持續維護。

5. MCP 工具與 Skill 有什麼不同？

MCP 工具提供 AI 可呼叫的能力，例如查詢或建立資料；Skill 則是 AI 可載入的工作方法，說明特定類型的工作該依什麼步驟與原則完成。兩者互補，通常一起使用。

系列文章導讀

介面架構｜企業軟體如何成為 AI 可操作的工具？一次看懂 AI Agent、MCP 與 API（本文）

資安治理｜當 AI 不只回答、還能動手做：企業如何管理權限、資安與稽核？

資料價值｜AI 不只幫你填表：流程資料如何幫管理者更快掌握待辦、異常與商機？

資料來源與延伸閱讀

Model Context Protocol：What is the Model Context Protocol（MCP）?

Model Context Protocol Specification：Architecture Overview

Model Context Protocol Specification：Authorization

叡揚資訊：Vital BizForm MCP 介紹與 Skill 下載