上一篇文章《MCP 的應用場景，其實是一個巨大的賺錢機會》 發出後，後臺接到很多讀者留言，詢問能否寫一篇文章再詳細介紹下 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 工程師
00:37 什麼是 MCP？
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：好的。
-
Tool：讓模型自行決定什麼時候呼叫。對應用開發者而言，這類似“函式呼叫”，只是由模型發起的。如果一個 MCP 伺服器提供 “獲取天氣” 這種功能，模型在推理時如果覺得需要天氣資訊，就會直接呼叫這個工具。 -
Resource：相當於可以給模型或使用者引用的外部資料。可以是文字、檔案，也可以是資料庫記錄。它有唯一 URI 標識，應用可以在互動過程中讓模型選擇要不要用這些資料，也可以讓使用者從“資源列表”裡手動挑選注入對話。 -
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 的“私有協議”。現階段，我們先把程式碼放在一個公共倉庫裡，不少公司都在貢獻，比如 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 自己發起的。
如果覺得內容不錯，歡迎點個關注，分享和在看～