上一篇文章 發出后，后臺接到很多讀者留言，詢問能否寫一篇文章再詳細介紹下 MCP 設計細節，湊巧的是搜索過程中發現 AI Engineer 頻道剛好在上周五（4 月 4 日，新鮮熱乎的 ）采訪了MCP 團隊的兩位發起工程師（地址：https://www.latent.space/p/mcp） ，談到了 MCP 的方方面面。 本篇內容是訪談的脫水版文字稿，移除了和 MCP 無關的話題和口頭表達時的語癖，基本能夠解答大家對 MCP 的起源、技術細節與設計思路、與 Agent 的關系及未來迭代方向的疑問，也比大多數能讀到的二手內容權威多了。

人物介紹

• 主持人 Alessio (A) ，Decibel 合伙人兼 CTO

• 主持人 swyx (S) ，Small AI 創始人

• 嘉賓 David (D) ，Anthropic 工程師

• 嘉賓 Justin (J) ，Anthropic 工程師

S：能否先給大家一個簡明的定義？MCP 是做什么的？

J：好的。MCP 全稱是 Model Context Protocol，我們想解決的是“如何讓 AI 應用快速而靈活地擴展功能”。具體而言，MCP 提供了一套通信協議，讓 AI 應用（我們叫“客戶端”）和各種外部擴展（我們叫“MCP 服務器”）能彼此協作。這里的“擴展”可以是插件、工具或者其它資源。MCP 的目的就在于讓大家在構建 AI 應用時，能夠輕松引入外部服務、功能，或者調取更多數據，讓應用擁有更豐富的能力。我們的命名中有“client-server”的概念，主要是為了強調交互模式，但本質就是在做一個“讓 AI 應用更易擴展”的通用接口。

D：簡單說，MCP 對應的場景就是：當我們在用一個 AI 應用時，常常想讓它接入更多外部工具、數據或特性。但如果每次都要單獨做對接，就會很繁瑣。MCP 類似于“USB-C 接口”，它以統一的方式讓不同 AI 應用對接到各種工具和資源。而且，它面向的是 AI 應用，不是直接去修改底層模型。

02:00 MCP 的起源

D：我在加入 Anthropic 之前，一直在做開發者工具，特別關注如何讓開發者提升效率。加入后，我在內部使用 Claude Desktop，發現在某些場景下，我需要在 IDE 與 Claude Desktop 之間反復地復制粘貼，才能夠獲得我想要的上下文或工具訪問權限，這樣的體驗讓人感覺很割裂。于是我開始思考：能不能做一個類似 LSP（Language Server Protocol）的東西？把這種“AI 應用與擴展之間的通信”標準化。當時我還在看如何把 LSP 部分思想應用在內部工作，就跟 Justin 在一個小會議室聊了這個想法，他也很感興趣。我們快速迭代，做出了 MCP 的雛形，先寫了個簡單協議和測試版 SDK。期間還做了對 Claude Desktop 和 IDE 的初步集成。后來我們內部辦了一場黑客松，一些同事用 MCP 編了可以控制 3D 打印機的服務器，還有實現“記憶功能”之類的擴展。這些原型大受歡迎，讓我們相信這個想法能帶來很大潛力。

J：對，我接到 David 的想法后，也覺得特別有價值。前期開發基礎設施很枯燥，比如要定義協議、實現 SDK、多語言互通等。但當我們終于把最初版本跑起來時，就能在很短時間內編寫新工具、讓它們跟 Claude 或其它 AI 應用對接。內部黑客松的那些有趣項目，讓我們看到 MCP 的可塑性和落地價值。

05:18 開發挑戰與解決方案

S：提到 LSP，你們的 MCP 看上去也采用了 JSON-RPC、雙向通信等模式。為什么還要花很多精力設計呢？能否具體談談開發時遇到的挑戰？

J：LSP 解決的核心是編輯器與編程語言的“M×N”難題：不同編輯器都要適配各種語言，很容易重復造輪子。LSP 就統一了協議，讓“編輯器-語言”各自只需要實現一次。而我們的目標類似，只不過場景換成了“AI 應用-擴展”之間的對接。然而，LSP 本身只解決了開發者工具中的一種形態。我們需要在 MCP 中加入更多“AI 場景”所需的原語，比如工具（Tool）、資源（Resource）、可插入的提示（Prompt）等。每一個概念代表不同的交互方式，工具讓模型主動調用函數，資源可以讓用戶或模型在聊天時插入額外數據，提示則更像可插入的文本模板。要把這些都抽象好，并保證可擴展性和易用性，需要大量設計和取舍。

D：我們參考了針對 LSP 的諸多批評意見，盡量在 MCP 中改進。例如 LSP 在 JSON-RPC 上的某些做法太復雜，我們就做了一些更直接的實現方式。但真正花時間的是如何確定 MCP 應該提供哪些功能原語、如何讓它們在應用層表現得簡單并且強大。最初幾個月，我們主要都在討論和打磨這部分，像“工具調用如何體現給用戶？資源應該怎樣標識和加載？提示能否支持多步文本？”等等，保證了現在 MCP 雖然結構不大，卻能表達豐富的 AI 交互模式。

08:06 技術細節與設計思路

S：你們反復提到“工具”“資源”和“提示”三個核心原語，能不能詳細說說你們為什么要這樣區分？

J：好的。

1. Tool ：讓模型自行決定什么時候調用。對應用開發者而言，這類似“函數調用”，只是由模型發起的。如果一個 MCP 服務器提供 “獲取天氣” 這種功能，模型在推理時如果覺得需要天氣信息，就會直接調用這個工具。

2. Resource ：相當于可以給模型或用戶引用的外部數據?？梢允俏谋尽⑽募部梢允菙祿煊涗洝Ｋ形ㄒ?URI 標識，應用可以在交互過程中讓模型選擇要不要用這些數據，也可以讓用戶從“資源列表”里手動挑選注入對話。

3. Prompt ：這是人為觸發的提示文本，相當于“提示片段庫”。在編輯器里，可能以 / 命令 或模板形式出現。當用戶想使用這個提示時，可以直接注入給模型。

D：我們發現很多人對“函數調用”非常關注，但其實在實際場景中，有很多是用戶或應用希望主動插入的上下文——這并不一定讓模型自己調用。所以 Resource 和 Prompt 就變得非常必要。Prompt 還能支持多步鏈式的文本，這樣我們可以預先設計復雜提示場景，避免每次都手動復制黏貼大段文本。這些都讓 MCP 能表達更豐富的體驗。

29:45 MCP 與 OpenAPI

S：很多人會問，MCP 和 OpenAPI 對比如何？或者說它們會不會沖突？

J：OpenAPI 在傳統 RESTful 領域很成熟，但如果你想針對 AI 場景，構建那種可多輪調用、可調取不同數據上下文的擴展，OpenAPI 可能太細粒度了。它并沒有“提示”“資源”“工具”的高級抽象。我們更希望為 AI 應用提供專門的協議能力。
當然，OpenAPI 還是很有用，很多人已經實現了從 OpenAPI 自動轉成 MCP 服務器的適配器。如果你只需要一次性的函數調用，OpenAPI 很好。但是如果你需要讓模型在上下文中混合使用外部數據、多步推理、用戶插入提示等場景，就會發現 MCP 更加自然。

D：兩者其實是互補而不是對立。MCP 允許工具端更靈活地表達自己可提供的功能和數據，也支持模型和用戶在多輪對話中隨時獲取或調用。OpenAPI 仍能保留自己在描述 API 方面的優勢，只是對于 AI 應用場景，有時 MCP 更貼近需求。

32:48 如何構建 MCP 服務器

A：你們有許多示例服務器，比如“文件系統服務器”“記憶服務器”之類。對想要自己做 MCP 服務器的開發者，你們有什么建議？

D：最好的辦法就是直接動手寫一個最小可用版。你可以挑選任意語言，看看是否已有對應的 MCP SDK，然后實現一個簡單的“工具”即可。比如你想給模型一個“把某些表格數據返回并總結”的接口，你只需創建一個 MCP 服務器，提供一個返回數據的函數描述，用幾行代碼就能跑通。后續再慢慢完善，比如增加更多資源、提示、或更靈活的工具描述。

J：對，而且你還可以把 MCP 的相關文檔和 SDK 代碼復制進一個 AI 模型，比如 Claude 里，告訴它“幫我寫個 MCP 服務器，支持某個功能”，它一般會給出一個可行的初始版本。然后你再手動做一些修改就行。 MCP 一開始就故意做得很簡潔，讓開發者能快速上手。

40:39 MCP 與 Agent 的關系

S：說到可嵌套的客戶端與服務器，如果一個 MCP 服務器本身也能調用別的 MCP 服務器，這會不會像“Agent”？

D：可以這么理解，但也要看你怎么定義“Agent”。MCP 自身只是一種通信協議，讓“上下文管理”和“調用邏輯”能靈活組合。如果你在服務器里加一套多步推理或遞歸調用邏輯，就可以做出一個“Agentic”的 MCP 服務器，比如對接數據庫時多次查表、總結，然后再把結果返回給客戶端。但 MCP 本身并不會強制你一定要這樣做。

J：我們希望先把協議打磨好，用來連接 AI 應用和外部擴展。Agent 常常包含更多策略或推理機制。MCP 只是提供一個底層“雙向通信”的能力，讓你能在需要的時候實現 Agent 化的功能，但并不把所有 Agent 邏輯都裝進協議中。

43:13 MCP 中的“工具”與“提示”

D：很多人覺得“工具調用”是最直接的方式，但其實“資源（resource）”和“提示（prompt）”也很重要。例如，如果你要讓用戶自行決定何時引入某份文件或信息，用 Resource 會更自然，讓用戶選完后注入給模型。
提示（Prompt）則更像編輯器里 / 命令 或“模板插入”的概念，可以是一段固定文本，也可以是多步或帶變量的提示，這樣用戶一鍵就能把復雜提示加入對話。

J：這些原語背后都有各自適用場景。工具是“模型自己想用時隨時可調”，資源更像“額外可選上下文”，提示則是“用戶顯式想插入的預設文本”。我們希望把這些都抽象出來，給應用開發者提供更多可控的用戶體驗，而不是所有事情都丟給模型自由調用。

45:45 MCP 中的嵌套調用與工具混淆

S：如果我在同一個上下文里掛載了很多 MCP 服務器，里面可能有幾十個工具，模型可能會混淆，該怎么解決？

J：在現階段，可能需要應用側做些輔助，比如只在恰當時機暴露特定工具，或者對工具說明做嚴格區分，或者用個輕量模型先判斷該用哪個工具，再把結果交給大模型。 畢竟，如果全都一次性扔給模型，難免出現混淆。而且實際可用多少工具，也取決于模型的上下文能力和對描述的理解程度。

D：如果兩個工具功能或描述太相近，就很容易讓模型搞錯。隨著模型變得更強大，這個問題可能會逐漸緩解。但目前看來，讓客戶端對工具做些篩選或優化描述是一種不錯的做法。也有開發者嘗試做“ Agentic 服務器”，幫你在眾多工具里選擇，再調用真正的功能。

49:11 客戶端如何控制工具調用

J：我們非常強調一件事：雖然 MCP 里“工具”是由模型發起調用，但應用和用戶擁有最終控制權。客戶端完全可以決定哪些工具暴露給模型，也可以決定如何描述這些工具。如果用戶不想讓模型訪問某些工具，或者想對工具做額外安全檢查，應用端可以直接過濾或修改工具信息。

D：對，MCP 設計中保留了應用端最大化的自主性。我們不希望模型直接“越權操作”，也不希望開發者在做安全或隱私控制時束手束腳。協議只是把“雙向溝通”的通路打通，但何時允許、如何允許，都可以在客戶端層面管理。

52:08 MCP 服務器的授權與信任問題

A：那在授權和安全上，你們怎么處理？比如我要用一個第三方 MCP 服務器，該怎么確保它是可信的？

D：我們在下一版協議里加入了對 OAuth 2.1 的最簡支持，讓用戶在瀏覽器里完成授權流程就行。這樣服務器就能有一把令牌來確認訪問權限。當然，若在本地場景，也可以通過本地通信來處理。更復雜的需求，像細粒度授權、訪問范圍等，可能還需要做擴展。我們想先解決最普遍的場景，看社區是否有針對特定需求的方案，然后再考慮要不要寫進協議。

J：確實，任何軟件供應鏈都有可能被攻擊或濫用。我們或許需要一些“信譽”或“簽名認證”，讓大家知道某個 MCP 服務器是不是官方或社區認可的安全實現。但這又牽涉到“誰來背書”“誰來維護”等問題。我們傾向先讓協議保持靈活，等社區積累足夠經驗后，再考慮更完善的治理或認證機制。

01:01:34 無狀態服務器與未來發展

S：你們最近更新了“無狀態”或“可斷開重連”的傳輸方式，以前用 SSE 做長連接有沒有問題？

J：最初我們用 SSE（Server-Sent Events）做長連接，讓客戶端和服務器保持持續的會話，這樣服務器可以隨時推送。但對大規模分布式部署可能不太友好。 社區反饋也提出希望有無狀態 HTTP，這樣部署會更靈活。因此我們和社區討論后提出一種可流式 HTTP 傳輸，讓服務器和客戶端可以在需要時重連并恢復會話，既能做到狀態追蹤，也更便于橫向擴容或處理斷線情況。

D：對，我們相信 AI 應用未來一定需要相當程度的“有狀態”支持，尤其當涉及多模態或更復雜的任務。但我們也理解很多人想用傳統無狀態 HTTP 部署模型服務。所以現在我們就折衷出一套“可流式+可斷線重連”的方案，保留了兩邊的優點。

01:10:07 開源治理與社區參與

A：MCP 開源后，你們怎么看待多方共建、標準化組織等話題？有可能像 GraphQL 那樣進入基金會嗎？

D：我們非常希望 MCP 成為真正的開放標準項目，而不僅是 Anthropic 的“私有協議”?，F階段，我們先把代碼放在一個公共倉庫里，不少公司都在貢獻，比如 Microsoft 做了 C# SDK，JetBrains 做了 Kotlin 版本，Block、Shopify 等都對協議提出過改進意見。我們也給很多核心貢獻者直接的提交權限。
真正要把它放進某個正式的標準化組織時，就會涉及很多流程——這可能減緩創新速度。我們當下更想用更靈活的開源社區模式，快速試錯迭代。

J：對，而且治理也是一個漸進過程。當前重點是維持社區活力和高速迭代。我們并不排斥未來成立專門基金會，也不排斥和更多企業一起共建。但我們要讓協議在真正需求的驅動下演進，而不是陷入“委員會式開發”的泥潭。

01:18:12 “理想”的 MCP 實現或項目

A：你們還有哪些希望社區做的 MCP 實現或項目？

D：我個人一直想要更多關于“采樣推理”（sampling loop）的客戶端，也希望有人寫一些能自動匯總 Reddit 或游戲動態的 MCP 服務器，讓模型讀外部信息再做總結。另外，我也希望看到更多人用資源、提示等原語，做出真正“上下文豐富”的體驗。別只停留在工具調用。

J：我做游戲開發愛好者項目時，特別想要一個對接 Godot 引擎或 Unity 的 MCP 插件，能讓模型對游戲環境進行自動測試、調試甚至寫關卡腳本。對于我來說，這才是把 AI 應用的能力最大化的場景。當然還希望有更多客戶端能完整支持 MCP 的所有原語，讓社區建起多種不同類型的應用。

A：非常感謝你們兩位詳細分享，讓我們對 MCP 的設計初衷、發展方向和潛力都有了更多了解。祝你們未來一切順利，也期待 MCP 生態越做越大！

寫在結尾

如果對 MCP 的使用和理解還不清楚，可以后臺回復 「MCP」，手把手教你借助 MCP 構建 Anthropic 官方博客Building effective agents定義的 6 種 Agent 模式，可以作為學習 MCP 的絕佳模板，畢竟 MCP 就是 Anthropic 自己發起的。

如果覺得內容不錯，歡迎點個關注，分享和在看～