OpenAI宣佈採用競對Anthropic協議，一夜將MCP送上熱搜！Karpathy：趕緊歇了吧

整理 | 冬梅

1 Altman 確認採用 Anthropic 的 MCP 協議

美國當地時間 3 月 26 日，OpenAI CEO Sam Altman 在 X（原 Twitter）帖子中確認，OpenAI 將在旗下產品（包括 ChatGPT 桌面應用）中整合 Anthropic 的模型上下文協議（MCP）。

Altman 指出，“MCP 的市場反響很好，我們也很高興能在自家產品中支援這項協議。目前此協議已經在 Agents SDK 中開放，對於 ChatGPT 桌面版應用以及 Responses API 的支援也即將推出！”

MCP 允許模型從業務工具和軟體等來源處提取資料以完成任務，並可從內容儲存庫和應用開發環境中提取資料。在該協議的支援下，開發人員能夠在資料來源和 AI 驅動的應用程式（例如聊天機器人）之間建立起雙向連線。

開發人員可以透過“MCP 伺服器”公開資料並構建起“MCP 客戶端”——例如例項、應用程式和工作流，再根據命令接入到這些伺服器。自從 Anthropic 開源 MCP 的這幾個月來，包括 Block、Apollo、Replit、Codeium 和 Sourcegraph 在內的多家廠商均已為其平臺添加了 MCP 支援。

Anthropic 公司首席產品官 Mike Krieger 在 X 上發帖表示，“很高興看到大家對 MCP 的喜愛延伸到 OpenAI——熱烈歡迎！MCP 已經成為一項蓬勃發展的開放標準，目前已經吸引到成千上萬的整合且仍在不斷增長。只有全面接入已經存在的資料和軟體當中，大語言模型才能最大程度發揮作用。”

OpenAI 則表示，他們打算在未來幾個月內陸續分享關於 MCP 支援計劃的更多資訊。

OpenAI 的整合意味著開發者可以更輕鬆地構建能呼叫即時資料的智慧助手，比如企業級聊天機器人或自動化工作流。

2 網友怎麼看？

OpenAI 宣佈支援 Anthropic 推出的模型上下文協議（MCP），在開發者社群引發激烈討論。這一協議被宣傳為"AI 工具整合的新標準"，但其實際價值正面臨兩極評價。

在 X 上，有使用者認為，MCP 的到來，是告別“LangChain 地獄”的解放。MCP 最直接的吸引力在於其宣稱能替代 LangChain 等傳統工具鏈。“LangChain 是個臃腫的噩夢，”一位 Hacker News 使用者說道，“招聘要求裡還把它列為必備技能，恰恰說明行業裡充斥不懂技術的人。” MCP 透過標準化介面分離 AI 核心與工具，開發者可以動態新增各類功能模組，理論上使大模型應用擴充套件更靈活。

儘管支持者稱讚 MCP 的客戶端 – 伺服器架構創新，但批評者指出其核心功能並無本質突破。“這不過是把工具呼叫標準化，”一位機器學習架構師說道，“LangChain、SmolAgents 等庫早已用不同方式實現了類似功能，”。實驗資料顯示，採用 MCP 的代理在工具選擇準確率上僅提升 3%，幻覺問題依然存在。

行業觀察家注意到，MCP 的熱度部分源於技術圈的跟風心理。“只要丟擲‘協議’、‘伺服器’這些術語，工程師們就會興奮”。一位技術評論員引用了 Joel Spolsky 的經典比喻，這讓人想起那些痴迷架構卻忽視實際問題的‘架構宇航員’。“Anthropic 的營銷資料中，‘雙向連線’、‘標準化協議’等術語出現頻率高達每百字 7.8 次，遠超技術白皮書平均水平。

連 AI 大神 Andrej Karpathy 也發表了自己關於 MCP 的看法，Karpathy 認為，MCP 沒什麼用，趕快停止吧。

在 Hacker News 社群中，也有不少使用者對 MCP 的實用價值提出質疑，有位使用者坦然，就是他自己的團隊也會“跟風”部署實施，但這並不是最佳方案。

“我完全同意（對 MCP 的批評）。MCP 的功能設計過度複雜，實際優勢並不明顯。它要求開發者自己定製工具，開發和除錯都會浪費大量時間。

嚴格來說，MCP 甚至算不上真正的技術協議——更像是一套行業約定俗成的規範。雖然我們團隊也會跟進實施（畢竟行業都在用），但我始終認為這不是最佳方案。相比之下，基於 HTTP 的 OpenAPI 服務簡單得多，而且所有主流框架都已經原生支援。

除非把 MCP 簡化到 STDIO（標準輸入輸出）那種級別的易用性，否則我實在看不出它的必要性。”

3 MCP 是什麼？

MCP 全稱為 Model Context Protocol（模型上下文協議），最初由 Anthropic 提出並開源，簡單來說，就是構建為 AI 助手提供額外背景資訊的工具的標準方法。

為什麼 Anthropic 會提出這樣一種協議？

Anthropic 認為你不需要依賴 LangChain 或 LlamaIndex 這樣的庫來整合大語言模型（LLM）和外部工具（比如向量資料庫、檔案系統或文件）。

他們的理念是：任何能給 AI 助手提供額外資訊或功能的東西，都可以直接變成一個 API 工具，讓 LLM 自己去呼叫。比如：你的向量資料庫可以是一個工具，檔案系統訪問也可以是一個工具。

這樣一來，在構建 AI 助手（或叫 AI 代理）時，工具呼叫就成了統一所有功能的核心方式，而不需要依賴複雜的中間框架。Anthropic 鼓勵開發者自己按需定製整合，而不是依賴現成的庫。

Anthropic 在一篇部落格文章中指出，儘管 AI 助手正在被廣泛採用，並且模型能力（如推理和質量）在快速進步，但即使是最高階的模型仍然受困於資料隔離問題——它們被限制在資訊孤島和舊有系統中。每次接入新的資料來源都需要定製化開發，導致真正互聯的 AI 系統難以規模化擴充套件。

而 MCP（Multi-Connection Protocol）旨在解決這一問題。它提供了一種協議，允許開發者在資料來源和 AI 應用（如聊天機器人）之間建立雙向連線。具體來說，開發者可以透過 MCP 伺服器對外提供資料訪問能力，然後構建 MCP 客戶端（如應用程式或自動化工作流），按需連線這些伺服器。

MCP 可以讓 AI 系統更靈活、高效地整合各類資料來源，打破資訊孤島的限制。

行業分析認為，此舉可能加速 AI 助手在複雜場景（如金融、醫療等）的落地，同時降低企業整合 AI 技術的門檻。

4 技術突破還是新瓶舊酒？

事實上，Anthropic 在 2024 年 11 月宣佈了這一協議時行業內對此的反應稍顯冷淡。但現在 MCP 正在流行，已經超過了 LangChain，並有望很快超越 OpenAPI 和 CrewAI。主要的 AI 參與者和開源社群都在支援 MCP，認為它是構建代理 AI 系統的潛在遊戲規則改變者。沉寂一年多，MCP 為什麼突然火了？

有人認為，MCP 之所以能火起來，有幾個主要原因：

整合問題解決器：AI 代理和代理工作流成為 2023～2024 年的主要流行語，但它們的致命弱點仍然存在：將這些代理與現實世界的業務系統和資料整合。最初，人們將注意力集中在模型功能和提示技術上，而不是整合上。MCP 透過定義“如何將現有資料來源”（檔案系統、資料庫、API 等）連線到 AI 工作流中，直接解決了這一差距。隨著人們消化了這一點，MCP 開始被視為嚴肅的、可用於生產的 AI 代理所缺失的一塊拼圖。（這是 HumanX 會議的要點之一：近年來，我們主要專注於構建單獨的 AI 模型，每個模型都專門用於特定任務。但隨著複雜性和需求的增長，正在向整合系統轉變——多個專門模型、軟體元件、API、資料來源和介面的編排協同工作。）
社群和採用：在短短幾個月內，MCP 從概念發展成為一個不斷發展的生態系統。早期採用者包括 Block (Square)、Apollo、Zed、Replit、Codeium 和 Sourcegraph 等公司，他們開始整合 MCP 以增強其平臺。快進到 2025 年，生態系統已呈爆炸式增長 – 到 2 月，已有 1000 多個社群構建的 MCP 伺服器（聯結器）可用。顯然，隨著行業朝著更加整合和情境感知的 AI 邁進，MCP 引起了共鳴。這種網路效應使 MCP 更具吸引力：透過 MCP 提供的工具越多，採用該標準就越有用。
事實上的標準勢頭：與另一個專有 SDK 或一次性框架不同，MCP 是開放的且與模型無關，並且得到了主要 AI 參與者的支援。這意味著任何 AI 模型（Claude、GPT-4、開源 LLM 等）都可以使用 MCP，任何開發人員或公司都可以在未經許可的情況下建立 MCP 整合。社群中的許多人現在認為 MCP 可能是標準化 AI 系統如何連線外部資料的競賽中的贏家（就像 USB、HTTP 或 ODBC 如何成為其領域中無處不在的標準一樣）。
快速發展和教育：Anthropic 並非只是釋出了 MCP 就放棄了；他們一直在積極改進它並教育開發人員。甚至在 3 月中旬的 AI 峰會上，Anthropic 的 Mahesh Murthy 舉辦了一場廣為流傳的研討會，也一定程度加速了 MCP 的採用。而隨著 OpenAI 的採用，這項協議的影響力還在擴大。