「AI原生」標準MCP突然爆紅，引爆LangChain大佬「內戰」：是顛覆OpenAI的技術突破，還是配不上當前關注的玩具？

近期，MCP 熱度極高。

「在 MCP 出現之前，開發者必須編寫代碼，並通過 API 將 AI 工具與外部系統連接，這意味著每個集成都需要預先編碼。」AI 代理開發者 John Rush 說道，而「MCP 是一個標準協議。這意味著每個 AI 工具只需實現一次，然後就可以通過這個協議連接到數千個外部工具。」

開發者 Julian Harris 進一步補充道，MCP 提供了「一個將任何 API 轉化為 LLM 工具插件的標準接口」，從而實現了「以超低摩擦的方式豐富 LLM 的上下文」。

然而，質疑聲同樣存在。有開發者將其類比為「為 AI 打造的 Zapier」，認為它不過是給 API 使用增加了額外步驟。

此外，部分人擔憂，一些主流 LLM 服務商如 Grok 和 ChatGPT 等目前尚未支持該協議，且這些系統設計者極可能試圖推行自有標準。不過，Anthropic 應用 AI 工程師 Mahesh Murag 曾表示，MCP 本身與 Anthropic 的 Claude 並無任何內在聯繫。

AI 領域瞬息萬變。MCP 雖於去年發佈，但近期突然爆火，也引發了人們對其「花期」能持續多久的討論。LangChain 還在 x 上發起了一項投票：結合實際用例、與 OpenAI Plugin 的比較以及 MCP 自身的局限性，大家認為它到底是曇花一現、還是未來標準？

結果顯示，有 40.8% 的人認為 MCP 是未來標準，25.8% 的人認為 MCP 只是曇花一現，剩下 33.4% 的人選擇觀望。

如何打敗一眾標準，脫穎而出？

任何新協議的影響力，取決於其被採納的程度。

被廣泛接受的標準，如 Kubernetes、React 和 H湯臣P，通過將爆炸性的 MxN 問題轉化為可管理的 M+N 生態系統解決方案來適應開發者們各種各樣的需求。一旦達到臨界規模，它們便將具有巨大的價值。

目前，MCP 已經積累了足夠的臨界規模和動能，因此它被視為 2023-2025 年「代理開放標準」之爭的潛在贏家。有人預計，按照當前的速度，MCP 將在 7 月超越 OpenAPI：

許多「老派開發者」起初會對 MCP 的成功感到困惑，因為從技術層面來看，MCP 基本上具備與現有標準（如 OpenAPI、OData、GraphQL、SOAP 等）相同的功能。然而，如果將 MCP 簡單地完全等同於 OpenAPI ，並認為它的成功只是一種潮流的循環，就過於武斷。

MCP 可以視為是一種「AI 原生」標準，能夠體現出每個 Agent 中獨立複現的模式，相比那些未考慮這些特性而設計的不可知論標準，這種原生標準在使用和開發工具時會更加便捷和高效，這方面表現要超過 OpenAPI。

MCP 的出現相較第一波 LLM 框架較晚，它擁有足夠的戰略空間，避免從大模型互操作性這種「顯而易見」的點切入，而是專注於以動態上下文訪問為核心的那些還未解的棘手難題。因此，MCP 一定程度上優於 LangChain 等。

Murag 表示，MCP 並不會取代代理框架，而是通過提供可插拔的連接器和適配器來補充，並通過提供一致的工具交互方式，讓開發者的工作變得更輕鬆。

「擁有很多支持者的開放標準」也意味著，該標準不能有任何致命缺陷。與其臨時創造一個全新的標準，並冒著重蹈過去錯誤的風險，Anthropic 團隊調整併採用了微軟非常成功的語言服務器協議 (LSP)。

「對於期待以最優方案勝出的理想主義者來說，有個令人沮喪的現實：由大型實驗室製定的標準，其成功概率天然碾壓其他任何來源的標準。即便競爭者坐擁數萬 GitHub Stars、有頂級風投數千萬美元加持，這種不公平依然存在——如果創業公司會將我鎖在其設立的標準中，那我肯定不會採納；但若標準的支持者體量龐大，甚至不關心是否要刻意鎖定用戶，我則會欣然接受。」swyx 和 Alessio 在博客中寫道。

真正的「開放標準」必須配備規範的文檔，而在一些開發者眼裡，MCP 的規範堪稱典範，甚至令 OpenAI 的函數調用文檔相形見絀——後者的技術說明尚未達到真正完備的標準規範要求。正因如此，MCP 不僅超越諸多開源框架，某種程度上甚至優於 OpenAI 的現有方案。

還有一個微妙的觀點是——Anthropic 一直明確強調其支持的工具數量比 OpenAI 更多。我們實際上沒有關於大規模工具數量的基準測試或消融實驗，因此並不清楚不同公司之間的能力差異，但直觀上，MCP 可以在一次調用中支持更多的工具，比沒有 MCP 的工具數要多。

曇花一現還是未來標準？

昨天，圍繞「MCP 是真正的技術突破，還是 AI 炒作浪潮下的又一朵浪花？」這一話題，LangChain CEO Harrison Chase 與 LangChain 創始工程師、LangGraph 負責人 Nuno Campos 展開了討論。

其中，Harrison 更為看好 MCP，認為如果需要向無法控制的智能體中引入工具，MCP 就是最好的選擇。而 Nuno 則認為，MCP 的潛力上限也就到 Zapier 這個程度了，它至少得變得更像 OpenAI 的自定義 GPT，才配得上大家如今對它的關注和期待。

下面是兩人的詳細討論過程，這種辯證對話希望可以對讀者朋友們有所啟發。

Harrison：我認為 MCP 確有真材實料。起初我也對它持懷疑態度，但在看到它的價值之後，我的想法也開始轉變。總結來講：如果需要向無法控制的智能體中引入工具，MCP 就是最好的選擇。

這裏我舉個例子。對於 Claude Desktop、Cursor、Windsurf 之類的產品，身為用戶的我們顯然無法控制其底層智能體。也就是說，這些智能體只能訪問少數內置工具。

但如果我想讓它使用預設情況下不具備的工具，該怎麼實現？為了做到這一點，就需要存在某種協議，讓這些智能體知曉要如何調用其他外部工具。

我相信這一點對於非開發者創建的智能體同樣意義重大。從目前的趨勢來看，人們希望有更多主題專家能夠參與到智能體構建中來，充分發揮自己的技術專長。我覺得這類創作者既沒有編輯智能體邏輯的意願、也缺少這種技術能力——但他們仍然希望智能體可以對接某些工具。這時候 MCP 就可以發揮作用。

Nuno：我覺得你可能低估了智能體在訪問外部工具時，所帶來的定製化調整工作量。當然，假設說 Windsurf 附帶的網絡搜索工具太差，用戶想用更好的工具來替代，那這事確實成立。但這隻能算是種改善，還稱不上真正的變革性用例。

所謂變革性用例，就是只需引入一款神奇的工具，就能讓 Cursor 實現其創作者都未曾設想過的新功能——但這在實踐層面基本還行不通。在我接觸過的幾乎所有生產智能體當中，都需要根據提供的工具定製系統消息甚至是大量架構組件。

Harrison：確實，這些智能體的可靠性也許還不夠高……但至少具備了一定的實用性。工具的描述和指令當然非常重要，但我們也得承認：

MCP 支持工具定義——好的 MCP server 往往擁有超越一般方案的高質量工具描述。
MCP 能夠支持提示詞——用戶可以向其中添加更多指令。
隨著底層模型的改進，現成工具在調用智能體方面的表現會越來越好。

我們當然不會指望有人能僅憑 MCP 集成加工具調用智能體就打造出下一款 Cursor，但其中的價值是不容忽視的，比如催生出更多內部或者個人智能體。

Nuno：也有道理，但我們自己的工具調用基準測試表明，當前模型約有一半的概率無法調用正確工具——這還是已經針對工具集量身定製了架構和提示詞的測試場景。如果把這樣的成功比例照搬到個人智能體這邊，那基本就相當於不可用。

沒錯，模型會變得越來越好，但用戶的期望也會水漲船高。這裏我想引用貝索斯的說法，「我最喜歡顧客的一點，就是他們永遠不會滿足。他們的期望永遠都是動態的、不斷上升的，這是人性的反映。」

所以要想實現種種預期，我覺得唯一的可能性就是掌握完整技術棧——包括用戶界面、提示詞、架構、工具等。否則的話……就只能碰運氣了。

Harrison：模型肯定會變得越來越好，我對這一點很有信心。所以無論目前智能體的成功率如何，未來這項指標只會逐步提升。

我覺得公平的比較不該把用 MCP 構建的智能體直接拿去跟擁有完善工具的智能體正面 PK。MCP 真正的價值，在於如何建立起中長期連接和集成能力。

就比如說 Zapier，它的功能是把電子郵件接入 Google Sheets、Slack 等平台。我可以創建無數個工作流，但並不是每個工作流都能擁有完善的智能體。而使用 MCP，我可以創建自己的智能體版本。那你如何評價 Zapier 這個例子？

Nuno：在 LangChain，這兩年我們構建了一套包含 500 種工具的庫，但我很少看到這些工具被頻繁用於生產。它們都是按相同的「協議」實現，能夠與任意模型兼容且靈活互換。那 MCP 到底有什麼特別？是它強製要求在本地終端上運行上百萬個 server，還是只跟桌面應用程序兼容？在我看來這甚至反而是個缺點。老實講，我覺得 MCP 的潛力上限也就到 Zapier 這個程度了。

Harrison：我覺得 LangChaing 工具和 MCP 工具之間的最大區別，在於 MCP 並非面向智能體開發者。也就是說，它的主要服務對象，是那些無法直接把工具引入智能體的用戶。

具體來講，比如我要編寫一款智能體來完成某項任務，那我使用 MCP 的可能性就是零。但這也不是 MCP 的目標用例。MCP 的意義是把工具引入我們無法控制的智能體，同時也讓非開發者能夠將工具跟智能體對接起來（LangChain 工具則更多以開發者為中心）。要注意，非開發者的數量要遠遠多於專業開發者。

至於目前的 MCP 使用形式？沒錯，我承認還不夠好，但它肯定會變得更好。我會設想 MCP 的未來形態，比如只需單擊一下就能安裝 MCP 應用程序（而不再需要在本地終端運行 server），而且能在 Web 應用程序上開放訪問。我敢打賭，這肯定會成為 MCP 接下來的發展方向。

那你覺得 MCP 需要做哪些改變，才能讓你對它的作用和意義有所改觀？

Nuno：這個嘛，我覺得 MCP 至少得變得更像 OpenAI 的自定義 GPT，才配得上大家如今對它的關注和期待。但自定義 GPT 甚至也沒有多受歡迎。從這個角度看，MCP 又比 GPT 多了什麼吸引力？

Harrison：其實在我看來，MCP 更像是種 Plugin 插件，當然插件也一直沒太成功，我都不確定自己有沒有用過 Plugin，所以有些說法可能不夠準確。但我覺得：

MCP 生態系統已經遠遠大於插件生態系統。
大模型會越來越好，在工具使用能力方面也會越來越強。

Nuno：好吧，我不確定你說的是否屬實。但我花了 5 秒鍾時間，就只搜到了 893 個 MCP server。你好像更多關注提到 MCP 的推文數量，卻忽略了人們到底在用它構建出多少東西但回到你沒回答的問題，我覺得如果 MCP 真想在 AI 發展史上留下足跡，那至少需要：

降低複雜性。為什麼工具協議還需要涉及提示詞和大模型補全？
降低實現門檻。為什麼服務於工具的協議還需要雙向通信？沒錯，我認真看了項目團隊列出的所有理由，但不好意思，我覺得「需要從服務器接收日誌」說服不了我。
要能在服務器上使用。要達成上述目標，無狀態協議是關鍵——我們使用大模型來構建，並不代表我們就能捨棄長久以來積累到的業務擴展經驗。歷史告訴我們，一旦被搬上服務器就必然引發許多其他意外，比如身份驗證等難以用分佈式方式解決的問題。
彌補質量損失。如果放任用戶把各種工具塞進自己並不瞭解的智能體，必然會帶來質量損失。

Harrison：你說得沒錯，我可能太過關注 MCP 的「熱度」，卻忽略了它的實際應用曲線。但帖子裡其實也有很多唱衰的聲音，也算是對我觀點的一種駁斥和補充。

本文來自微信公眾號「InfoQ」，整理：褚杏娟核子可樂，36氪經授權發佈。