API 還是 MCP：你的 AI Agent 何時該直接呼叫服務商
Model Context Protocol 贏了。它現在是「無聊的基礎設施層」——78% 的企業 AI 團隊在生產環境跑 MCP，最近更迎來史上最大更新：為「真的大玩家」、成千上萬個 agent 而做的全無狀態重寫。 所以獨立開發者面對一個尖銳的問題：如果這就是標準，我為什麼還要自己寫 API 呼叫？ 直接抓 API 的直覺，比行銷話術暗示的更常是對的。下面是規則。 你其實在做兩個決定 大家把「API vs MCP」壓成一個問題，其實是兩個： 傳輸——位元組怎麼從你的 agent 到那個能力。 護欄——你的 agent 被允許做什麼。 MCP 不會讓你的 agent 更安全。「阻止它刪光我的雲端硬碟」這個性質，存在於你授予的授權範圍和你暴露的工具介面裡——不在協議裡。一個 scope 收緊的原生 API 呼叫，和一個只暴露 read 工具的 MCP server，做得一樣好。 所以「MCP 更安全」是偽命題。MCP 真正買到的是一致性——agent 和每個 client 都用同一種方式跟每個工具講話。這有價值，但只是有時。 規則 用原生 API、scope 收緊，當： 你是一個 agent、配上少數幾個資源。 你是唯一的消費者，而且會一直是。 護欄就只是收緊一個 token——自己來很簡單。 你要服務商完整原生的介面，不是一層翻譯。 用 MCP，當： 多個 client 或多個 agent 需要同一個資源。 你想換模型或服務商，卻不想重寫呼叫邏輯。 已經有成熟的 server 處理某個棘手環節（認證流程、串流、分頁邊界）。 你在組合很多工具，想要單一呼叫慣例。 為什麼這對獨立開發者最關鍵 MCP 的核心價值是 N×M → N+M 的收縮：與其為每一組 (client, resource) 客製一個整合，不如每個資源建一個 server。這個回報只有在 N 和 M 都大時才成立。 ...