作者 | Gil Feig
編輯 | 云昭
出品 | 51CTO技術棧（微信號：blog51cto）
AI 助手在產品體驗中的重要性日益凸顯，而一種新的標準也應運而生，它助力 AI 助手的構建：模型上下文協議 (MCP)。隨著 Anthropic、OpenAI 和 Gemini 等主流大型語言模型 (LLM) 提供商的采用，該協議迅速在更廣泛的軟件生態系統中獲得了廣泛關注，各大公司紛紛構建自己的 MCP 服務器。
作為參與構建 MCP 服務器和 API 集成的人員，我親眼目睹了這種快速采用導致的混亂。一些開發人員和產品經理將 MCP 視為 API 的替代品，而另一些人則認為 MCP 不如 API。
實際情況則更加微妙：MCP 和 API 是互補的。許多設計良好的 AI 系統都需要兩者，而一些 AI 工程師構建的系統可能并不足以支持使用 MCP。
為了幫助您了解哪種解決方案適合您的特定場景，我將解釋每種解決方案的工作原理、局限性以及它們如何協同工作。
1.MCP 和 API 如何協同工作
MCP 的核心是為大型語言模型與外部數據源交互提供一種標準化的方式，但這些交互通常通過現有的 API 進行。當 LLM 從 MCP 服務器調用某個工具（例如在 Jira 中創建工單）時，仍然會向相關的 Jira 端點發出 API 調用。
Hasura 通過即時編寫由數據庫和服務支持的 GraphQL API，簡化數據訪問，從而使開發團隊（或 API 使用者）能夠立即投入工作。GraphQL 本身的特性以及 Hasura 的動態方法使集成和迭代變得簡單。
MCP 的價值在于它能夠管理 LLM 與數據源之間的上下文。它提供了一個標準化的框架，用于：
- 工具選擇和調用： MCP 允許 LLM 根據用戶提示動態選擇使用哪些工具，而不需要硬編碼的 API 調用。
- 上下文保留：該協議幫助 LLM 保留、更新和獲取上下文，這對于管理多步驟工作流程至關重要。
- 簡化交互： MCP 通過提供標準協議使 LLM 和應用程序更容易集成。
同時，API 仍然處理核心數據傳輸、身份驗證流程和與不同應用程序的連接。
2.MCP 的安全挑戰需要 API 級解決方案
MCP 靈活開放的架構帶來了獨特的安全挑戰。開發人員希望使用盡可能多的工具（API 端點）。這導致密鑰通常可以訪問電子郵件、機密規劃工具和銷售數據等敏感服務。再比如，LLM 可能會誤認為字段標簽（將“SN”誤認為是社保號碼而不是姓氏），從而無意中泄露敏感數據。
為了防止此類情況發生，工程師需要集成訪問控制級別、模式執行和數據丟失防護。最有效的方法是將 MCP 的上下文管理功能與強大的 API 基礎架構相結合。
例如，API 提供商的身份驗證方法（例如 OAuth 2.0）使 LLM 能夠確認用戶是否具有訪問底層 API 端點所需的權限。API 提供商的響應代碼可以幫助您的 LLM 診斷和解決問題（例如，在請求失敗時向用戶發出警報并提供解決方案）。
3.大多數 AI 用例僅需要 API
我看到一些 AI 團隊采用 MCP 來掩蓋更深層次的問題，例如混亂的檢索系統、失控的提示鏈以及團隊間缺乏清晰的約定。他們沒有修復架構，反而增加了另一層，導致抽象程度更高，清晰度更低。
這些 AI 團隊目前還不需要 MCP；他們只需要（通過構建強大的 API 集成）清理他們的提示和數據管道。如果一個團隊僅僅使用 MCP 來組織基礎設施層，那么現在可能還為時過早。
當您能夠應對復雜性時，MCP 會非常強大：需要處理多個模型、數據源和下游消費者，并且需要結構化的合約。但在此之前，請先考慮在整個基礎架構中構建一致性，然后實施自動化的歸檔、重復數據刪除和權限管理策略，以減少手動開銷并保持秩序。
4.API必不可少，MCP是暫選項
隨著我們構建日益復雜的人工智能助手，理解 MCP 和 API 在集成生態系統中是互補的層至關重要。
MCP 提供上下文管理層，幫助 LLM 更有效地與外部系統交互，而API 則提供與這些系統安全可靠的連接。
認識到兩者的關系對于成功構建AI產品至關重要。盲目追求 MCP 的做法并不可取，我們需要在構建有效的 MCP 實現之前，還得投入精力構建夠硬的 API 基礎設施、有組織的檢索系統和標準化約定。
參考鏈接：
https://thenewstack.io/author/gilfeig/
