分解模型上下文通訊協定 (MCP)

MCP 的用戶端伺服器架構

MCP 建構在客戶端伺服器模式上，可架構 AI 模型如何擷取外部資料來源並與之互動。

• MCP 用戶端是 AI 代理、應用程式或任何要求結構化資料的系統。
• MCP 伺服器扮演中介角色，從各種 API、資料庫或企業系統取得資料，並以一致的格式傳回。

MCP 伺服器不需要 AI 模型直接提出 API 請求，而是處理複雜的認證、資料擷取和回應正規化。這表示 AI 代理不再需要管理多重 API 認證、不同的請求格式或不一致的回應結構。

例如，如果人工智能模型需要從 Google Drive、Slack 和資料庫等多個服務中提取資訊，它不會單獨查詢每個 API。它會向 MCP 伺服器傳送單一的結構化請求，MCP 伺服器會處理請求、從必要的來源收集資料，並傳送組織良好的回應。

MCP 請求-回應生命週期

典型的 MCP 互動遵循結構化的請求-回應週期，可消除多餘的 API 呼叫，並將資料擷取標準化。

1.AI 代理向 MCP 伺服器傳送結構化的請求。代理不需要製作個別的 API 請求，而是以統一的格式定義它需要的資料。

{

  "request_id"："xyz-987"、

  「查詢」：[

    {"source": "github", "action": "get_recent_commits", "repo": "company/project"},

    {"source": "slack", "action": "fetch_unread_messages", "channel": "engineering"}

  ]

}

2.MCP 伺服器透過驗證認證、檢查權限和決定要查詢哪些外部系統來處理請求。

3.查詢以平行方式執行，這表示會同時從多個服務擷取資料，而不是依序擷取，從而減少整體延遲時間。

4.將來自不同來源的回應標準化成 AI 模型可以輕鬆處理的結構格式。

{

  "github": {

    "recent_commits"：[

      {"author": "Alice", "message": "Refactored AI pipeline", "timestamp": "2024-03-12T10:15:00Z"}

    ]

  },

  "slack": {

    "unread_messages"：[

      {"user": "Bob", "text": "Hey, can you review the PR?", "timestamp": "2024-03-12T09:45:00Z"}

    ]

  }

}

與需要手動解析的原始 API 回應不同，MCP 可確保所有擷取的資料都遵循可預測的結構化格式，讓人工智能模型更容易理解和利用。

查詢執行與回應聚合

MCP 旨在透過引入結構化的執行流程，優化 AI 模型與外部系統的互動方式。

1. 請求驗證可確保在擷取任何資料之前，AI 模型擁有必要的權限。
2. 查詢路由決定需要存取哪些外部服務。
3. 平行執行可同時從多個來源擷取資料，減少連續 API 請求所造成的延遲。
4. 回應聚合可將結構化資料整合為單一回應，省去人工智能模型手動處理多個原始 API 輸出的需要。

透過減少多餘的請求、將回應規範化並集中處理驗證，MCP 可消除不必要的 API 開銷，並使 AI 驅動的自動化更具擴充性。

驗證挑戰

MCP 最大的承諾之一，就是讓 AI 代理不再依賴特定 API 的整合。然而，驗證 (AuthN) 仍然是一大挑戰。

如今，API 認證是一個分散的過程 - 有些服務使用 OAuth，有些則依賴 API 金鑰，有些則需要基於會話的認證。這種不一致使得新 API 的上線非常耗時，而 MCP 目前並沒有內建的驗證框架來處理這種複雜性。

MCP 仍需要一些外部機制來驗證 API 請求，這表示使用 MCP 的 AI 代理必須仰賴 Composio 等其他解決方案來管理 API 認證。鑑定已列入 MCP 的發展藍圖，但在完全實作之前，開發人員仍需要變通方式來處理跨系統的鑑定。

身份管理不清晰

另一個尚未解決的問題是身分管理-當 AI 代理透過 MCP 提出請求時，外部系統會看到誰？

例如，如果 AI 助理透過 MCP 查詢Slack ，Slack 應該會識別該請求來自：

• 最終使用者？（意指人工智能是代表人類行事。）
• AI 代理本身？(Which would requireSlack to handle AI-based interactions separately)。
• 共用系統帳戶？（這可能會引發安全性和存取控制方面的問題）。

在企業環境中，這個問題更加複雜，因為存取控制政策會決定誰可以擷取哪些資料。如果沒有明確的身分對應，MCP 整合可能會面臨存取受限、安全風險或不同平台間的不一致。

MCP 已計劃支援 OAuth，這可能有助於釐清身分處理方式，但在完全實作之前，AI 模型可能會在以權限為基礎存取協力廠商服務的問題上掙扎。 

供應商鎖定與生態系統分裂

MCP 目前是由 Anthropic 領導的一項計畫，這讓人對其長期標準化產生疑問。隨著 AI 生態系統的演進，其他主要參與者（例如OpenAI 或 DeepSeek）很有可能會為 AI 與系統之間的互動開發自己的通訊協定。

如果出現多種相互競爭的標準，產業可能會分崩離析，迫使開發人員在不同且互不相容的方法之間做出選擇。MCP 是否仍是主流方法，或只是成為多種競爭選項之一，仍有待觀察。