如今，隨著基礎(chǔ)模型變得越來(lái)越智能，人們?cè)絹?lái)越需要有一個(gè)用于執(zhí)行、數(shù)據(jù)獲取和工具調(diào)用的標(biāo)準(zhǔn)接口。

自 OpenAI 在 2023 年發(fā)布函數(shù)調(diào)用功能以來(lái)，AI 智能體與外部工具、數(shù)據(jù)和 API 的交互能力卻日益碎片化：開(kāi)發(fā)者需要為智能體在每個(gè)系統(tǒng)中的操作和集成實(shí)現(xiàn)特定的業(yè)務(wù)邏輯。

顯然，執(zhí)行、數(shù)據(jù)獲取和工具調(diào)用需要一個(gè)標(biāo)準(zhǔn)接口。API 曾是互聯(lián)網(wǎng)的第一個(gè)偉大統(tǒng)一者——為軟件之間的通信創(chuàng)造了一種共享語(yǔ)言，但 AI 模型卻缺乏類似的機(jī)制。

2024 年 11 月 Anthropic 推出的模型上下文協(xié)議（Model Context Protocol，簡(jiǎn)稱 MCP），在開(kāi)發(fā)者和 AI 社區(qū)中迅速獲得了廣泛關(guān)注，被視為一種潛在的解決方案。

近日，全球知名投資機(jī)構(gòu) a16z 發(fā)布了一篇博客文章，深度介紹了 MCP 以及 AI 工具生態(tài)的未來(lái)。

博客鏈接：https://a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/

本文將深入探討 MCP 是什么，它如何改變 AI 與工具的交互方式，開(kāi)發(fā)者已經(jīng)用它構(gòu)建了哪些應(yīng)用，以及仍需解決的挑戰(zhàn)。

讓我們跟隨博客一探究竟。

MCP 是什么？

MCP（Model Context Protocol，模型上下文協(xié)議）是一種開(kāi)放協(xié)議，它允許系統(tǒng)以可泛化的方式為 AI 模型提供上下文信息，從而跨越不同集成場(chǎng)景實(shí)現(xiàn)通用性。該協(xié)議定義了 AI 模型如何調(diào)用外部工具、獲取數(shù)據(jù)以及與服務(wù)交互。舉個(gè)具體的例子，以下展示了 Resend MCP 服務(wù)器如何與多個(gè) MCP 客戶端協(xié)同工作。

這一理念并非創(chuàng)新，MCP 從語(yǔ)言服務(wù)器協(xié)議（LSP）中汲取了靈感。在 LSP 中，當(dāng)用戶在編輯器中輸入時(shí)，客戶端會(huì)向語(yǔ)言服務(wù)器查詢以獲取自動(dòng)補(bǔ)全建議或診斷信息。

而 MCP 超越 LSP 的地方在于其以智能體為中心的執(zhí)行模型：LSP 主要是被動(dòng)的（基于用戶輸入響應(yīng) IDE 的請(qǐng)求），而 MCP 則旨在支持自主的 AI 工作流。根據(jù)上下文，AI 智能體可以決定使用哪些工具、以什么順序使用，以及如何將它們串聯(lián)起來(lái)以完成任務(wù)。

此外，MCP 還引入了人機(jī)協(xié)作能力，允許人類提供額外數(shù)據(jù)并批準(zhǔn)執(zhí)行。

當(dāng)前熱門應(yīng)用場(chǎng)景

通過(guò)使用合適的 MCP 服務(wù)器，用戶可以將每一個(gè) MCP 客戶端變成「萬(wàn)能應(yīng)用」。

我們以 Cursor 為例：雖然 Cursor 本質(zhì)上是一個(gè)代碼編輯器，但它也是一個(gè)功能強(qiáng)大的 MCP 客戶端。終端用戶可以通過(guò) Slack MCP 服務(wù)器將其變成 Slack 客戶端，通過(guò) Resend MCP 服務(wù)器將其變成郵件發(fā)送器，使用 Replicate MCP 服務(wù)器將其變?yōu)閳D像生成器。

利用 MCP 的更強(qiáng)大方法是在一個(gè)客戶端上安裝多個(gè)服務(wù)器以解鎖新流程：用戶可以安裝服務(wù)器以從 Cursor 生成前端 UI，也可以要求智能體使用圖像生成 MCP 服務(wù)器為站點(diǎn)生成主頁(yè)橫幅。

當(dāng)然，除了 Cursor 以外，當(dāng)前的應(yīng)用場(chǎng)景大致可以分為兩類：以開(kāi)發(fā)者為中心、本地優(yōu)先的工作流，以及基于 LLM 客戶端的全新體驗(yàn)。

以開(kāi)發(fā)者為中心的工作流

對(duì)于開(kāi)發(fā)者來(lái)說(shuō)，一個(gè)普遍的愿望是：「我不想離開(kāi)我的 IDE 去完成某件事」。MCP 服務(wù)器正是實(shí)現(xiàn)這一夢(mèng)想的絕佳方式。

基于 MCP 服務(wù)器，開(kāi)發(fā)者不再需要切換到 Supabase 來(lái)檢查數(shù)據(jù)庫(kù)狀態(tài)，而是可以直接在 IDE 中使用 Postgres MCP 服務(wù)器執(zhí)行只讀 SQL 命令，或通過(guò) Upstash MCP 服務(wù)器創(chuàng)建和管理緩存索引。在迭代代碼時(shí)，開(kāi)發(fā)者還可以利用 Browsertools MCP 服務(wù)器，讓編程智能體訪問(wèn)實(shí)時(shí)環(huán)境，獲取反饋并進(jìn)行調(diào)試。

Cursor 智能體使用 Browsertools 訪問(wèn)控制臺(tái)日志和其他實(shí)時(shí)數(shù)據(jù)并更有效地進(jìn)行調(diào)試的示例。

如上圖所示，Cursor 智能體可以通過(guò) Browsertools 訪問(wèn)控制臺(tái)日志和其他實(shí)時(shí)數(shù)據(jù)，從而更高效地進(jìn)行調(diào)試。

除了與開(kāi)發(fā)工具交互的工作流，MCP 服務(wù)器還解鎖了一種全新的應(yīng)用場(chǎng)景：通過(guò)爬取網(wǎng)頁(yè)或基于文檔自動(dòng)生成 MCP 服務(wù)器，為編碼智能體提供高度準(zhǔn)確的上下文信息。開(kāi)發(fā)者無(wú)需手動(dòng)配置集成，而是可以直接從現(xiàn)有文檔或 API 中快速啟動(dòng) MCP 服務(wù)器，使 AI 智能體能夠即時(shí)訪問(wèn)這些工具。這意味著更少的時(shí)間花在樣板代碼上，更多的時(shí)間用于實(shí)際使用工具 —— 無(wú)論是拉取實(shí)時(shí)上下文、執(zhí)行命令，還是動(dòng)態(tài)擴(kuò)展 AI 助手的能力。

全新體驗(yàn)

Cursor 等 IDE 并不是唯一可用的 MCP 客戶端，對(duì)于非技術(shù)用戶來(lái)說(shuō)，Claude Desktop 是一個(gè)極好的切入點(diǎn)，它使 MCP 驅(qū)動(dòng)的工具更易于普通用戶使用。很快，我們可能會(huì)看到專門的 MCP 客戶端出現(xiàn)，用于以業(yè)務(wù)為中心的任務(wù)，例如客戶支持、營(yíng)銷文案、設(shè)計(jì)和圖像編輯，因?yàn)檫@些領(lǐng)域與 AI 在模式識(shí)別和創(chuàng)意任務(wù)方面的優(yōu)勢(shì)密切相關(guān)。

MCP 客戶端的設(shè)計(jì)及其支持的特定交互在塑造其功能方面起著至關(guān)重要的作用。例如，聊天應(yīng)用不太可能包含矢量渲染畫布，就像設(shè)計(jì)工具不太可能提供在遠(yuǎn)程機(jī)器上執(zhí)行代碼的功能一樣。最終，MCP 客戶端體驗(yàn)定義了整體 MCP 用戶體驗(yàn) —— 而對(duì)于 MCP 的體驗(yàn)，我們還有更多東西需要解鎖。

一個(gè)典型的例子是 Highlight 如何通過(guò)實(shí)現(xiàn)「@」命令來(lái)調(diào)用其客戶端上的任何 MCP 服務(wù)器。這創(chuàng)造了一種全新的用戶體驗(yàn)?zāi)Ｊ?，?MCP 客戶端可以將生成的內(nèi)容直接導(dǎo)入到任何下游應(yīng)用中。

Highlight 實(shí)現(xiàn) Notion MCP（插件）

另一個(gè)例子是 Blender MCP 服務(wù)器的用例：現(xiàn)在，幾乎不了解 Blender 的業(yè)余用戶可以用自然語(yǔ)言描述他們想要構(gòu)建的 3D 模型。隨著社區(qū)為 Unity 和 Unreal 引擎等其他工具實(shí)現(xiàn)服務(wù)器，我們正在實(shí)時(shí)見(jiàn)證「文本到 3D」工作流的落地。

使用 Claude Desktop 與 Blender MCP 服務(wù)器的示例

雖然我們主要關(guān)注服務(wù)器和客戶端，但隨著協(xié)議的發(fā)展，MCP 生態(tài)系統(tǒng)正在逐步成型。當(dāng)前的市場(chǎng)地圖覆蓋了最活躍的領(lǐng)域，但仍有許多空白?？紤]到 MCP 仍處于早期階段，我們期待隨著市場(chǎng)的演變和成熟，將更多參與者加入這張地圖。（我們將在下一部分探討其中的一些未來(lái)可能性。）

在 MCP 客戶端方面，目前我們看到的高質(zhì)量客戶端大多以編程為中心。這并不令人意外，因?yàn)殚_(kāi)發(fā)者通常是新技術(shù)的早期采用者。但隨著協(xié)議的成熟，我們預(yù)計(jì)會(huì)看到更多以業(yè)務(wù)為中心的客戶端出現(xiàn)。

在 MCP 服務(wù)器方面，目前大多數(shù)服務(wù)器都以本地優(yōu)先為主，專注于單一功能。這是由于 MCP 目前僅支持基于 SSE 和命令的連接。然而，隨著生態(tài)系統(tǒng)將遠(yuǎn)程 MCP 提升為首要支持對(duì)象，并采用可流式 HTTP 傳輸，我們預(yù)計(jì)會(huì)看到更多的 MCP 服務(wù)器被廣泛采用。

此外，一波新的 MCP 市場(chǎng)和服務(wù)托管解決方案正在涌現(xiàn)，使 MCP 服務(wù)器的發(fā)現(xiàn)成為可能。像 Mintlify 的 mcpt、Smithery 和 OpenTools 這樣的市場(chǎng)，正在讓開(kāi)發(fā)者更容易發(fā)現(xiàn)、分享和貢獻(xiàn)新的 MCP 服務(wù)器 —— 就像 npm 徹底改變了 JavaScript 的包管理，或 RapidAPI 擴(kuò)展了 API 的發(fā)現(xiàn)一樣。這一層對(duì)于標(biāo)準(zhǔn)化訪問(wèn)高質(zhì)量 MCP 服務(wù)器至關(guān)重要，使 AI 智能體能夠動(dòng)態(tài)選擇和集成所需工具。

隨著 MCP 的普及，基礎(chǔ)設(shè)施和工具將在使生態(tài)系統(tǒng)更具可擴(kuò)展性、可靠性和可訪問(wèn)性方面發(fā)揮關(guān)鍵作用。像 Mintlify、Stainless 和 Speakeasy 這樣的服務(wù)器生成工具正在減少創(chuàng)建 MCP 兼容服務(wù)的摩擦，而像 Cloudflare 和 Smithery 這樣的托管解決方案則正在解決部署和擴(kuò)展的挑戰(zhàn)。與此同時(shí)，像 Toolbase 這樣的連接管理平臺(tái)正在開(kāi)始簡(jiǎn)化本地優(yōu)先 MCP 的密鑰管理和智能體。

未來(lái)可能性

智能體原生架構(gòu)（agent-native architecture）的發(fā)展仍處于萌芽階段。盡管業(yè)界已經(jīng)對(duì) MCP 展現(xiàn)出極大熱情，但構(gòu)建和部署 MCP 過(guò)程中仍面臨諸多亟待解決的技術(shù)難題。協(xié)議在下一輪迭代中需要重點(diǎn)突破的領(lǐng)域包括：

托管與多租戶

MCP 支持 AI 智能體與其工具之間的一對(duì)多關(guān)系，但多租戶架構(gòu)（例如 SaaS 產(chǎn)品）需要支持多用戶同時(shí)訪問(wèn)共享的 MCP 服務(wù)器。近期解決方案可能是默認(rèn)采用遠(yuǎn)程服務(wù)器，使 MCP 服務(wù)器更易于訪問(wèn)，但許多企業(yè)同樣希望能夠托管自己的 MCP 服務(wù)器并實(shí)現(xiàn)數(shù)據(jù)面和控制面的分離。

為促進(jìn) MCP 的廣泛采用，下一個(gè)關(guān)鍵要素是開(kāi)發(fā)簡(jiǎn)化的工具鏈，用于支持規(guī)模化的 MCP 服務(wù)器部署和維護(hù)。

認(rèn)證

MCP 目前尚未定義客戶端與服務(wù)器之間認(rèn)證的標(biāo)準(zhǔn)機(jī)制，也沒(méi)有提供框架說(shuō)明 MCP 服務(wù)器在與第三方 API 交互時(shí)應(yīng)如何安全地管理和委托認(rèn)證。目前，認(rèn)證問(wèn)題留給各個(gè)實(shí)現(xiàn)和部署場(chǎng)景自行解決。在實(shí)踐中，MCP 的應(yīng)用主要集中在不需要顯式認(rèn)證的本地集成場(chǎng)景。

更完善的認(rèn)證范式可能是推動(dòng)遠(yuǎn)程 MCP 廣泛采用的關(guān)鍵突破點(diǎn)之一。從開(kāi)發(fā)者視角，統(tǒng)一的認(rèn)證方法應(yīng)包括：

• 客戶端認(rèn)證：用于客戶端-服務(wù)器交互的標(biāo)準(zhǔn)方法，如 OAuth 或 API 令牌
• 工具認(rèn)證：用于第三方 API 認(rèn)證的輔助函數(shù)或包裝器
• 多用戶認(rèn)證：適用于企業(yè)部署的租戶感知式認(rèn)證機(jī)制

授權(quán) 

即使工具已通過(guò)認(rèn)證，我們?nèi)孕杩紤]誰(shuí)應(yīng)被允許使用它，以及如何精細(xì)劃分用戶權(quán)限。MCP 缺乏內(nèi)置的權(quán)限模型，導(dǎo)致訪問(wèn)控制僅限于會(huì)話級(jí)別 —— 即工具要么可訪問(wèn)，要么完全受限。雖然未來(lái)可能會(huì)出現(xiàn)更精細(xì)的授權(quán)機(jī)制，但目前的方法依賴基于 OAuth 2.1 的授權(quán)流程，一旦認(rèn)證成功即授予整個(gè)會(huì)話的訪問(wèn)權(quán)限。隨著智能體和工具數(shù)量增加，系統(tǒng)復(fù)雜性隨之提高 —— 每個(gè)智能體通常需要獨(dú)立會(huì)話和唯一授權(quán)憑證，造成基于會(huì)話的訪問(wèn)管理網(wǎng)絡(luò)不斷擴(kuò)大。

網(wǎng)關(guān)

隨著 MCP 采用規(guī)模的擴(kuò)大，網(wǎng)關(guān)可作為集中化層，負(fù)責(zé)認(rèn)證、授權(quán)、流量管理和工具選擇。與 API 網(wǎng)關(guān)類似，它將執(zhí)行訪問(wèn)控制、將請(qǐng)求路由到適當(dāng)?shù)?MCP 服務(wù)器、處理負(fù)載均衡，并緩存響應(yīng)以提高效率。這在多租戶環(huán)境中尤為重要，因?yàn)椴煌脩艉椭悄荏w需要不同權(quán)限級(jí)別。標(biāo)準(zhǔn)化網(wǎng)關(guān)將簡(jiǎn)化客戶端 - 服務(wù)器交互，增強(qiáng)安全性，并提供更好的可觀測(cè)性，使 MCP 部署更具可擴(kuò)展性和可管理性。

MCP 服務(wù)器的可發(fā)現(xiàn)性和可用性

目前，查找和設(shè)置 MCP 服務(wù)器仍是一個(gè)手動(dòng)過(guò)程。開(kāi)發(fā)者需要定位端點(diǎn)或腳本、配置認(rèn)證，并確保服務(wù)器與客戶端之間的兼容性。集成新服務(wù)器不僅耗時(shí)較長(zhǎng)，而且 AI 智能體無(wú)法動(dòng)態(tài)發(fā)現(xiàn)或適應(yīng)可用的服務(wù)器。

不過(guò)，根據(jù) Anthropic 上個(gè)月在 AI 工程師大會(huì)上的演講，他們似乎正在開(kāi)發(fā)一套 MCP 服務(wù)器注冊(cè)表 (server registry) 和發(fā)現(xiàn)協(xié)議 (discovery protocol)。這項(xiàng)技術(shù)可能將為 MCP 服務(wù)器的應(yīng)用推廣開(kāi)啟嶄新階段。

執(zhí)行環(huán)境 

大多數(shù) AI 工作流程需要按順序執(zhí)行多個(gè)工具調(diào)用，但 MCP 缺乏內(nèi)置的工作流概念來(lái)管理這些步驟。要求每個(gè)客戶端都實(shí)現(xiàn)可恢復(fù)性和可重試性是不理想的。盡管目前開(kāi)發(fā)者正在嘗試使用 Inngest 等解決方案來(lái)實(shí)現(xiàn)這一功能，但將有狀態(tài)執(zhí)行提升為一級(jí)概念將能為大多數(shù)開(kāi)發(fā)者簡(jiǎn)化執(zhí)行模型。

標(biāo)準(zhǔn)客戶端體驗(yàn) 

開(kāi)發(fā)者社區(qū)經(jīng)常提出的一個(gè)問(wèn)題是：在構(gòu)建 MCP 客戶端時(shí)如何考慮工具選擇 —— 是否每個(gè)開(kāi)發(fā)者都需要為工具實(shí)現(xiàn)自己的 RAG，還是有一個(gè)等待標(biāo)準(zhǔn)化的層？

 除了工具選擇外，目前還沒(méi)有統(tǒng)一的工具調(diào)用 UI/UX 模式（從斜杠命令到純自然語(yǔ)言的各種方式都存在）。一個(gè)用于工具發(fā)現(xiàn)、排序和執(zhí)行的標(biāo)準(zhǔn)客戶端層可以幫助創(chuàng)建更可預(yù)測(cè)的開(kāi)發(fā)者和用戶體驗(yàn)。

調(diào)試

MCP 服務(wù)器的開(kāi)發(fā)者經(jīng)常發(fā)現(xiàn)，讓同一個(gè) MCP 服務(wù)器輕松地跨客戶端工作是很困難的。通常情況下，每個(gè) MCP 客戶端都有自己的特性，而客戶端跟蹤要么缺失要么難以找到，這使得調(diào)試 MCP 服務(wù)器成為一項(xiàng)極其困難的任務(wù)。隨著越來(lái)越多遠(yuǎn)程優(yōu)先的 MCP 服務(wù)器被構(gòu)建，需要一套新的工具來(lái)使開(kāi)發(fā)體驗(yàn)在本地和遠(yuǎn)程環(huán)境中更加流暢。

AI 工具的影響

MCP 的開(kāi)發(fā)體驗(yàn)讓人聯(lián)想到 2010 年代的 API 開(kāi)發(fā)。這種范式雖然新穎且令人興奮，但其工具鏈仍處于早期階段。如果展望幾年后，假設(shè) MCP 成為 AI 驅(qū)動(dòng)工作流的事實(shí)標(biāo)準(zhǔn)，會(huì)發(fā)生什么？以下是一些預(yù)測(cè)：

• 以開(kāi)發(fā)者為中心的公司競(jìng)爭(zhēng)優(yōu)勢(shì)將從最佳 API 設(shè)計(jì)轉(zhuǎn)向提供最優(yōu)工具集。若 MCP 能自主發(fā)現(xiàn)工具，API 提供商需確保其工具易于被發(fā)現(xiàn)，并具備差異化特性，使智能體能為特定任務(wù)選擇它們。
• 當(dāng)每個(gè)應(yīng)用都成為 MCP 客戶端、每個(gè) API 都成為 MCP 服務(wù)器時(shí)，將出現(xiàn)新定價(jià)模式：智能體會(huì)基于速度、成本和相關(guān)性動(dòng)態(tài)選擇工具。這可能使工具采用過(guò)程更市場(chǎng)化，優(yōu)先選擇性能最佳和模塊化的工具。
• 文檔將成為 MCP 基礎(chǔ)設(shè)施的關(guān)鍵，企業(yè)需設(shè)計(jì)具有清晰、機(jī)器可讀格式的工具和 API，使 MCP 服務(wù)器成為基于現(xiàn)有文檔的事實(shí)性產(chǎn)物。
• 僅有 API 還不夠，但可作為良好起點(diǎn)。工具與 API 的映射很少是一對(duì)一關(guān)系。工具是更高層次的抽象，智能體可能選擇包含多個(gè) API 調(diào)用以最小化延遲的函數(shù)。MCP 服務(wù)器設(shè)計(jì)將以場(chǎng)景和用例為中心。
• 若軟件默認(rèn)成為 MCP 客戶端，將出現(xiàn)新的托管模式。每個(gè)客戶端本質(zhì)上都是多步驟的，需要可恢復(fù)性、重試和長(zhǎng)時(shí)間運(yùn)行任務(wù)管理。托管提供商需跨不同 MCP 服務(wù)器進(jìn)行實(shí)時(shí)負(fù)載均衡，優(yōu)化成本與性能。

MCP 正在重塑 AI 智能體生態(tài)系統(tǒng)，而下一階段的發(fā)展將取決于如何應(yīng)對(duì)其基礎(chǔ)性挑戰(zhàn)。若實(shí)施得當(dāng)，MCP 有望成為 AI 與工具交互的標(biāo)準(zhǔn)接口，并開(kāi)創(chuàng)自主、多模態(tài)且深度整合的新一代 AI 體驗(yàn)。

如果 MCP 獲得廣泛應(yīng)用，它將從根本上改變工具的構(gòu)建、使用和商業(yè)化方式。業(yè)內(nèi)專家正密切關(guān)注市場(chǎng)將如何引導(dǎo) MCP 的發(fā)展方向。

今年將是決定性的一年：我們是否會(huì)看到統(tǒng)一的 MCP 市場(chǎng)崛起？AI 智能體的身份驗(yàn)證是否能實(shí)現(xiàn)無(wú)縫對(duì)接？多步驟執(zhí)行能否被正式納入?yún)f(xié)議標(biāo)準(zhǔn)？