MCP 與 API：兩者有何不同
模型內容協定 (Model Context Protocol, MCP) 是一項較新的技術，為 AIGNE 和 AI 提供了各種可能性。MCP 可能被視為 AI 驅動應用程式獲取數據、調用 API 和執行任務的新型 API 高速公路，將它們轉化為真正的問題解決者。但是，MCP 是如何運作的？它們與 API 又有什麼不同呢？
什麼是傳統 API？
傳統 API（Application Programming Interfaces，應用程式介面）是一組規則和協定，允許不同的軟體應用程式相互通訊。它們充當中介，使一個系統能夠向另一個系統請求數據或功能。最常見的傳統 API 是 RESTful，依賴 HTTP 來定義應用程式互動所需的特定端點（例如：GET /data）。這些 API 具備以下特點：
- 通用型：專為各種軟體整合而設計，從 Web 服務到行動應用程式皆適用。
- 預定義：開發者必須知道確切的端點和方法才能使用它們。
- 基於請求-回應：通常情況下，客戶端發送請求，伺服器做出回應，除非實施了 Webhooks 等額外設置，否則即時互動有限。
例如，天氣應用程式可能會使用傳統 API，透過固定端點從伺服器獲取當前的氣溫數據。這種方法一直是軟體開發的基石，從 SOAP 演進到 REST 及更遠的技術，每一次迭代都在解決特定的需求或限制。
什麼是 MCP？
模型內容協定 (MCP) 是一個開放標準，旨在將 AI 模型（特別是大語言模型，LLM）高效地連接到外部工具和數據源。可以將其想像為一個通用的連接器，通常被比作「AI 應用程式的 USB-C 連接埠」。MCP 使 AI 系統能夠：
- 存取外部資源：無縫地獲取即時數據或在其他系統中觸發操作。
- 動態發現工具：在無需事先配置的情況下識別可用工具。
- 進行即時通訊：支援類似 WebSockets 的雙向互動式交換。
MCP 是由 Anthropic 發起的開源專案，旨在標準化 AI 模型與外界整合的方式，減少傳統 API 通常需要的自定義代碼。
相似之處：為何 MCP 感覺像是新版的 API
從高層次來看，MCP 與傳統 API 共享一個核心目的：促進軟體組件之間的通訊。以下是為什麼 MCP 可能看起來「只是 API 的一個新版本」的原因：
- 標準化整合：兩者都為系統互動提供了結構化的方式。傳統 API 標準化了軟體對軟體的通訊，而 MCP 則標準化了 AI 對工具/數據的通訊。
- 互操作性：就像 API 培育了服務生態系統（例如支付閘道或社群媒體平台）一樣，MCP 鼓勵建立一個 AI 模型可以無縫接入各種工具的生態系統。
- 演進模式：API 一直在演進——從 SOAP 到 REST 再到 GraphQL——每一種都在應對新的需求。MCP 符合這一模式，是針對 AI 日益增長的重要性而量身定製的協定，建立在 API 的概念之上。
從 ArcBlock 的觀點來看（一個專注於去中心化應用程式的平台），MCP 將使 AIGNE（其無代碼 AI 應用平台）更易於使用，並賦予其立即存取外部數據源的能力。
不同之處：是什麼讓 MCP 脫穎而出
然而，MCP 並不僅僅是傳統 API 的翻版——它專為 AIGNE 的需求（特別是針對 LLM）引入了創新。以下是關鍵區別：
- 動態發現：MCP 允許 AI 模型動態發現可用的工具和資源，而無需預定義端點。傳統 API 則要求開發者預先了解並針對特定介面編寫代碼。
- 即時雙向通訊：MCP 支援互動式的雙向交換（例如，AI 獲取數據並發回指令），這超越了 RESTful API 典型的請求-回應模式。雖然 API 可以透過複雜的設置實現這一點，但 MCP 將其優雅地嵌入其中。
- AI 專用設計：MCP 是為 AI 模型量身打造的，簡化了 LLM 從外部系統獲取內容的方式。傳統 API 是通用的，服務於任何軟體，這可能導致 AI 用例中出現更多的自定義整合工作。
- 簡化整合：MCP 減少了將 AI 連接到外部系統所需的客製化代碼，而這正是傳統 API 常見的障礙。
例如，假設您使用 AIGNE 創建了一個代理 (Agent) 來管理 ArcBlock 平台上的去中心化市場。藉助 MCP，它可以動態發現庫存工具、獲取即時庫存數據並更新列表——這一切都透過標準化協定完成。傳統的 API 方法可能需要多個自定義整合，從而減慢開發速度。
比較表：MCP vs. 傳統 API
| 層面 | 傳統 API | MCP (現代 API 平台) |
|---|---|---|
| 架構 | 單體式 (Monolithic) 在單一單元中處理所有內容（例如用戶登入、數據、支付）的擴張系統。 | 微服務 (Microservices) 小型的獨立服務，每個服務處理特定任務（例如一個負責登入，另一個負責支付）。 |
| 擴展性 | 難以擴展 您必須同時擴展整個系統，即使只有一部分需要更多資源。 | 易於擴展 您可以根據需要擴展單個服務，而不影響其餘部分。 |
| 協定 | 通常使用 SOAP 較舊且較複雜的協定，可能顯得笨重且難以操作。 | 使用現代協定如 REST 或 GraphQL 更輕量、更快且更易於使用。 |
| 管理 | 手動管理 開發者必須親自處理安全性、路由等任務，這非常耗時。 | 透過 API 閘道自動化 自動處理安全性、路由和其他任務，節省時間和精力。 |
| 靈活性 | 較欠缺靈活性 做出更改可能會影響整個系統，因此更新具有風險且需要仔細規劃。 | 高度靈活性 您可以在不影響其他服務的情況下更新單個服務，使更改更快速、更安全。 |
| 部署 | 需要部署整個應用程式 即使是微小的更新也意味著要重新部署所有內容，這可能導致停機。 | 將更新部署到單個服務 您可以更新一部分而不觸及其他部分，減少停機時間。 |
| 故障隔離 | 故障可能影響整個系統 如果一個部分損壞，可能會導致整個 API 癱瘓。 | 故障是隔離的 如果一個服務失敗，其他服務仍能運行，防止出現大規模問題。 |
為什麼說 MCP “真的只是 API 的新版本”（帶有一點轉折）
那麼，為什麼 MCP 可能被視為 API 的新版本呢？從我的角度來看，這是因為 MCP 採用了熟悉的 API 概念（連接系統）並將其適配於 AI 時代。這是一種演進，就像 REST 改進了 SOAP 一樣，提供了一種標準化、對開發者友好的方式將 AI 功能整合到應用程式中。傳統 API 和 MCP 都旨在橋接系統，而 MCP 利用這一遺產，以一種讓熟悉 API 的開發者感到直觀的方式讓 AI 變得觸手可及。
然而，這種觀點可能低估了 MCP 的重要性。它不只是替 API 換上新包裝，而是一項以 AI 為核心功能、擴充 API 架構的專用協定。對 ArcBlock 而言，將 MCP 整合至去中心化生態系統，代表 AI 驅動的 dApp 能獲得傳統 API 難以同等效率實現的流暢即時互動。這項策略進展符合其打造可互操作去中心化解決方案的目標。ArcBlock 的 AIGNE + MCP，讓 AIGNE Framework、代理人等能力大幅提升。請造訪 https://www.aigne.io，開始體驗 AIGNE 無程式碼 AI 應用平台。敬請關注後續 MCP 更新。