為什麼企業 AI 不應該直接呼叫 API？談談 MCP 真正的價值

Posted on by Rico

最近看到不少人在討論：「MCP 只是多包一層 API，還會降低效能，直接讓 AI 呼叫 API 不就好了？」

這個問題其實很好，也是許多企業開始導入 AI 時最常提出的疑問。

我的答案是：

MCP 不會讓 API 更快，它的目的也從來不是讓 API 更快。

從一個收貨流程開始談起

假設一家公司的收貨人員收到一張採購送貨單。

未來，他不需要登入 ERP。

只要打開 AI 助理：

「幫我確認這張送貨單能不能收貨。」

AI 先利用 OCR 辨識：

  • 廠商
  • 採購單號
  • 料號
  • 數量

接著查詢 ERP。

最後回答：

「採購單存在，廠商一致，數量符合，目前可以收貨。」

甚至再問：

「請幫我完成收貨。」

AI 就直接完成 ERP 收貨作業。

看起來很簡單。

但真正的問題是：

AI 要怎麼跟 ERP 溝通？

最直接的方法：讓 AI 呼叫 API

很多人第一個想到的方法就是：

AI
    │
 SAP API

只要把 API 文件提供給 AI。

例如：

POST

/api/goodsreceipt

{
   ...
}

AI 理論上就可以自己呼叫。

這方法真的可以。

但是企業系統很少只有一套。

今天除了 SAP：

還有：

  • ERP
  • EIP
  • CRM
  • Workflow
  • LDAP
  • RAG
  • Git
  • Database

每一套都有不同 API。

不同 JSON。

不同 Authentication。

不同錯誤代碼。

AI 必須全部知道。

這時 Prompt 就會開始失控。

真正增加複雜度的不是 AI，而是企業

AI 並不怕學 API。

真正困難的是：

企業每天都在改系統。

例如：

SAP 今天升級。

API 改版。

EIP 換新版本。

CRM 換另一家。

如果 AI 直接依賴 API。

代表 Prompt 也要一直修改。

AI Agent 全部都要重新測試。

維護成本非常高。

MCP 真正解決的是「維護成本」

導入 MCP 後。

AI 不需要知道 SAP。

它只知道：

validate_receipt()

create_goods_receipt()

至於：

SAP 用 RFC？

REST？

SOAP？

甚至未來換 ERP？

全部都是 MCP Server 的事情。

AI 永遠不用改。

這就是 MCP 最重要的價值。

它把企業系統的不穩定性，隔離在 AI 外面。

那 MCP 不是多了一層嗎？

沒錯。

很多人批評：

多一層一定變慢。

這句話其實沒有錯。

MCP 確實增加了一次 Tool 呼叫。

增加了一些 JSON 包裝。

但是別忘了。

企業 AI 的整個流程通常包含：

  • OCR
  • LLM 推理
  • Database Query
  • SAP RFC
  • HTTP API

真正花時間的是：

SAP RFC。

LLM 推理。

資料庫查詢。

而 MCP 增加的通常只是幾毫秒。

如果整體流程需要兩秒。

MCP 多出的時間可能只有不到百分之一。

因此：

MCP 的成本很小。

但帶來的維護效益卻非常大。

我反而認為真正的效能問題不在 MCP

很多人說：

MCP 很慢。

我認為真正慢的是：

Tool 設計不好。

例如：

SAP RFC 回傳：

200 個欄位。

AI 真正需要：

  • 廠商
  • 採購單
  • 數量
  • 狀態

其他全部都是浪費 Token。

好的 MCP Server 應該先整理資料。

只把 AI 真正需要的資訊送回模型。

因此：

真正影響效能的是：

資料設計，而不是 MCP。

MCP 不應該只是 API 包裝器

這也是我認為很多人誤解 MCP 的地方。

如果 MCP 長這樣：

BAPI_PO_GETDETAIL()

BAPI_GOODSMVT_CREATE()

BAPI_PO_CHANGE()

那它真的只是 API Proxy。

沒有任何價值。

但是如果 MCP 提供的是：

validate_receipt()

approve_purchase()

cancel_receipt()

AI 完全不知道 SAP。

它只知道：

「我要完成收貨。」

至於裡面需要：

三個 RFC。

兩個 SQL。

一個 Workflow。

全部都是 MCP 處理。

這才是企業真正需要的 MCP。

MCP 比較像企業 AI 的 Service Layer

如果你有系統開發背景。

可以把 MCP 想成：

以前 SOA 的 Service。

或者現在微服務（Microservices）的 Service Layer。

它不是讓系統更快。

而是讓系統：

  • 更容易維護
  • 更容易管理
  • 更容易擴充

AI 世界其實也一樣。

我的建議

如果只是個人專案。

只有兩三個 API。

直接呼叫 API 沒問題。

但是如果企業開始導入：

  • ERP
  • EIP
  • Workflow
  • RAG
  • CRM
  • LDAP
  • 多個 AI Agent

那我會非常建議：

建立 MCP。

因為真正昂貴的從來不是 API。

而是：

未來五年的維護成本。

最後，我想分享一句我最近常說的話

很多人在討論 MCP 時，只看到：

「它多了一層，所以比較慢。」

但企業架構師看到的應該是：

它多了一層，所以未來更容易維護。

對企業而言，真正昂貴的通常不是多花幾毫秒，而是每次系統改版時，都需要重新修改 AI、重新測試、重新部署。

因此，我認為：

MCP 並不是一項效能最佳化技術，而是一項架構最佳化技術。

它以極小的執行成本，換取企業 AI 平台在可維護性、安全性、治理能力與長期擴充性上的巨大價值。

這也是我認為，未來企業 AI 平台幾乎都會採用 MCP 或類似架構的重要原因。