您今天已經是第十次重新佈線您的 AI 代理程式管線了 - 又一次脆弱的 API 整合，又一輪手動情境傳遞，只為了避免事情毀損。硬體編碼認證流程、規範 API 回應、拼接端點，這不是 AI 開發，而是整合地獄。
建立可從多個來源無縫擷取資料的AI 代理應該不費吹灰之力，但現今的現實卻是零散、重複且難以擴展。每種工具都有自己的語言，迫使您不得不湊合各種變通方法，而非建立真正的自動化。
Anthropic 正試圖以模型上下文協定 (Model Context Protocol, MCP) 來改變這種情況 - 這是一種標準化的方式，可讓 AI 代理擷取和使用外部資料，而無需永無止境的整合噩夢。但它能解決問題嗎？讓我們來分析一下。
什麼是協定？
通訊協定是一組定義系統如何溝通和交換資料的規則和慣例。與 API（特定於實作的介面）不同，通訊協定建立了互動的通用標準。一些著名的例子包括
- HTTP (超文字傳輸通訊協定)- 定義網路瀏覽器與伺服器的通訊方式。
- OAuth（開放授權協定）- 跨不同平台的安全驗證標準。
協定可確保互操作性 - 而不是每個系統都重新設計資料交換的方式，協定可將流程標準化，降低複雜性並使整合更具擴充性。
雖然通訊協定不是強制性或強制執行的，但隨著時間的推移，通訊協定的採用可以塑造系統在全球範圍內互動的基礎，我們看到 HTTP 演變成更安全且廣為接受的 HTTPS 就說明了這一點，從根本上改變了資料在網際網路上的傳輸方式。
什麼是模型上下文通訊協定 (MCP)？
Model Context Protocol (MCP) 是Anthropic 開發的開放標準，用來簡化 AI 模型存取外部資料來源並與之互動的方式。
MCP 不需要 AI 系統依賴自訂 API 整合、手動結構化請求，以及每項服務的驗證，而是提供統一的框架，讓 AI 代理以標準的方式擷取、處理結構化資料並採取相關行動。
簡單來說，MCP 定義了 AI 模型應如何請求與消耗外部資料 - 無論是來自資料庫、API、雲端儲存或企業應用程式 - 而無需開發人員為每個來源硬體編碼 API 特定邏輯。
為何創立 MCP？
AI 模型，尤其是LLMs （大型語言模型）和自主代理，需要存取外部工具和資料庫，才能產生準確的情境回應。然而，目前的人工智能與應用程式介面 (AI-to-API) 之間的互動效率不高，並為開發人員製造了龐大的開銷。
如今，將 AI 代理與外部系統整合需要：
- 每個工具的客製 API 整合（CRM、雲端儲存、票務系統等）。
- 每個 API 的驗證設定 (OAuth、API 金鑰、會話令牌)。
- 手動格式化資料，使 API 回應可用於 AI 模型。
- 跨不同服務的費率限制管理和錯誤處理。
這種方法無法擴充。每個新的整合都需要自訂邏輯、除錯和維護，使得 AI 驅動的自動化變得緩慢、昂貴且脆弱。
透過定義通用通訊協定，MCP 可讓人工智慧模型更具資料感知能力，而無須強迫開發人員為每個與之互動的系統建立自訂 API 橋接。
MCP 如何運作？
今天，AI 代理依賴自訂 API 呼叫、每項服務驗證和手動回應解析，創造了難以擴充的脆弱整合網路。
MCP 並非強迫人工智慧代理與 API 單獨互動，而是建立統一的通訊協定，將驗證、請求執行和資料格式化的複雜性抽象化，讓人工智慧系統能專注於推理，而非低階的整合邏輯。
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",
"queries": [
{
"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 模型與外部系統的互動方式。
- 請求驗證可確保在擷取任何資料之前，AI 模型擁有必要的權限。
- 查詢路由決定需要存取哪些外部服務。
- 平行執行可同時從多個來源擷取資料，減少連續 API 請求所造成的延遲。
- 回應聚合可將結構化資料整合為單一回應，省去人工智能模型手動處理多個原始 API 輸出的需要。
透過減少多餘的請求、將回應規範化並集中處理驗證，MCP 可消除不必要的 API 開銷，並使 AI 驅動的自動化更具擴充性。
MCP 的限制
模型上下文協定 (Model Context Protocol, MCP) 是讓人工智慧模型更有能力以結構化與可擴充的方式與外部系統互動的重要一步。然而，就像任何新興技術一樣，它也有一些限制，需要在廣泛採用前加以解決。
驗證挑戰
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一項計畫，這讓Anthropic對其長期標準化產生疑問。隨著 AI 生態系統的演進，其他主要參與者（例如OpenAI 或 DeepSeek）很有可能會為 AI 與系統之間的互動開發自己的通訊協定。
如果出現多種相互競爭的標準，產業可能會分崩離析，迫使開發人員在不同且互不相容的方法之間做出選擇。MCP 是否仍是主導方法，或只是成為多種競爭選項之一，仍有待觀察。
AI 供應商會圍繞 MCP 進行標準化嗎？
MCP 提供通用框架，可減少 AI 整合的分散性，目前每個連接都需要自訂解決方案，增加了複雜性。
要讓 MCP 成為廣泛接受的標準，主要的 AI 供應商必須採用 MCP。OpenAI、Google DeepMind 和 Meta 等公司尚未作出承諾，因此其長期可行性尚不確定。如果沒有全產業的合作，出現多種競爭協定的風險仍然很高。
有些公司已經開始使用 MCP。Replit、Codeium 和 Sourcegraph 已將其整合，以簡化其 AI 代理與結構化資料互動的方式。然而，MCP 要超越早期實驗，還需要更廣泛的採用。
除了 AI 公司之外，全球標準化工作也可能影響 MCP 的未來。ISO/IEC JTC 1/SC 42 等組織正在努力定義 AI 整合框架。中國的 AI 標準委員會等國家倡議，則凸顯了塑造下一代 AI 協定的競賽。
MCP 仍在發展中。如果整個產業都能圍繞 MCP 進行協調，AI 整合就能變得更具互操作性和擴充性。但是，如果出現相互競爭的標準，開發人員可能會面臨分散的生態系統，而非統一的解決方案。
建立與 API 整合的 AI 代理程式
MCP 簡化了 AI 互動，但驗證和結構化 API 存取仍然是主要的挑戰。Botpress 提供 OAuth 和 JWT 支援，讓 AI 代理能夠安全地進行驗證，並與Slack、Google Calendar、Notion 等進行互動。
有了 Autonomous Node，AI 代理就能做出LLM決策，並動態執行任務。Botpress 提供了一種結構化的方式來建立跨系統連結的 AI 代理。
今天就開始建立 - 這是免費的。
常見問題
1.MCP 是否可設定為符合 SOC 2、HIPAA 或 GDPR 標準？
是的，但這取決於您如何實施和託管它。由於 MCP 只是一種通訊協定，您需要確保 MCP 伺服器安全地處理資料，並進行加密、存取控制和稽核記錄，以符合法規要求。
2.AI 代理如何決定何時觸發 MCP，還是依賴內部記憶體？
通常，它們依賴提示邏輯或自訂規則，例如檢查資訊是否過時或內部無法取得。如果問題需要新資料或外部資料，這時AI 代理就會呼叫 MCP 來取得資料。
3.MCP 是否與現有的 RAG（檢索增量生成）架構相容？
是的。MCP 可直接插入 RAG 設定，作為結構化資料擷取器，以更一致、更精簡的方式取代手動 API 呼叫。
4.哪些類型的業務工作流程最受益於 MCP 整合？
任何涉及大量工具或資料孤島的工作，例如客戶支援、內部 IT 作業、銷售啟動或知識管理，都可以從 MCP 簡化 AI 代理如何獲得所需資訊的方式中獲益良多。
5.初創企業如何在不徹底改變整個資料架構的情況下採用 MCP？
從小處開始。您可以先將 MCP 用於一或兩個關鍵整合，例如Slack 或 CRM，然後視需要擴充。由於它將大部分雜亂的 API 工作抽象化，因此一開始就能輕鬆上手。
