也許未來回頭看，OpenAI 支援 MCP 協定會是 AI Agent 的重要里程碑。這件事情有其實非常多個解讀的角度，我最近兩周沉迷 MCP，體驗了很多 server，也手搓了不少工具。單純圍繞 MCP 都能寫上幾十篇文章（挖坑）。今天主要圍繞 OpenAI 來聊幾句吧，一些關於 MCP 的更基礎的普及文章回頭再寫。
我個人的幾個暴論（省流版）：
接下來我挨著展開論述一下這 5 點暴論（看完了再噴我）。
第一，MCP 的生態已經初具規模了，可以說 MCP 已經完成了一個通用協定的前半程採納，未來的前景和路線也已經比較明確了，MCP 的成功是大概率的事情。
如果說那些前半程主動接入的 early adopter 是出於早期嘗試或技術 sense，那麼接下來會有越來越多的企業、開發者、個人主動/被動地接入 MCP 的生態，這就是生態的威力，會把大家都捲進去。
我舉個例子，百度地圖率先推出了官方的 MCP Server[1]，首批支援了 8 個 tool，只需要填入百度地圖的 API_key 就可以使用。
這樣使用者就很便捷地讓 AI 調用起百度地圖的 tool 能力（地理編碼、地理逆編碼、地點檢索、詳情檢索、批量算路、路線規劃、天氣查詢、IP 定位），而不需要自己再去寫很多代碼。
百度地圖這樣做了幾天之後，高德地圖也宣佈推出了官方 MCP Server[2]。這明顯就是被捲到了，所以當 MCP 形成生態以後，不是自己做不做的問題，而是競品會捲著你做。
所以從現在開始，各家企業應該積極接入 MCP，開發者應該積極學習 MCP，個人用戶應該積極使用 MCP。晚做不如早做，被動做不如主動做。
第二，從 AI Agent 發展的長遠視角看，當下互聯網上所有的 API 服務，都值得也應該相容 MCP 協定。MCP 生態的繁榮，會極大地豐富 AI Agent 工具選擇，降低 AI Agent 開發能力，加速成熟 AI Agent 的到來。
API 是互聯網的基礎設施，那麼 MCP 的目標就是搭建起 AI Agent 選擇、使用工具時服務端和客戶端之間的中間層基礎設施，就像 Type-C 介面一樣，把外部世界、工具能力和底層模型無縫地銜接起來。
第三，MCP 的成功，是開源開放的成功，再次證明瞭開源共建的效果。我們常說，一流企業做標準，二流企業做品牌，三流企業做產品。過去，Anthropic 靠 Claude 這個產品可以算作三流企業，OpenAI 形成了自己的金字招牌，但有了 MCP 之後，Anthropic 就躋身了標準制定的層面。
儘管 Anthropic 的 Claude 並不開源，但 MCP 這步棋走的非常正確。MCP 作為一個協定，一個通用技術的宣導，與具體的 AI 模型、應用用戶端、提供工具服務的企業都不綁定。
這很重要，因為你制定協定是一件事，別人接納使用你的協定是另一件事。如果你沒點真東西，或者想把大家拖進閉源的生態裡，大家憑什麼認你當帶頭大哥。
現在，我們完全可以在全鏈路開源的場景（開源模型、開源用戶端、開源工具）下接入 MCP，這也是能夠吸引眾多開發者的地方。
我自己測試了一下小模型的 MCP 工具能力，在這裡給大家做一個最簡單的 demo 演示。舉個例子，我用 Qwen2.5-0.5B 的開源小模型，問它「9.8 和 9.11 哪個更大？」，顯然它回答是錯誤的。
然後我用 10 行代碼搓了一個 MCP 工具，功能只有一個，就是數位比大小。
from mcp.server.fastmcp import FastMCP mcp = FastMCP("numeric_comparison") @mcp.tool() def compare(a: float, b: float)->str: """compare two numbers, input float number, return result""" return f"{a}>{b}" if a - b > 0 else f"{b}>{a}" if __name__ == "__main__": mcp.run(transport='stdio')然後，我們在 Client 中接入這個工具：
再次提問，開源小模型就能做對比大小的題目了：
這隻是一個最簡單的演示，為了說明 MCP 可以在全鏈路開源的場景下實現很多操作，而不必要跟 Claude 3.5 模型，或者 Claude Desktop 用戶端綁定使用。
第四，OpenAI 原本有機會引領 AI Agent 的標準，他們只要多走半步，構建一個共用工具的開源生態就能成功，但恰恰他們的封閉生態導致了 Function call 的失敗。
OpenAI 毫無疑問是這一輪 LLMs（大語言模型）的引領者，其實 OpenAI 的先發優勢是極為明顯的，舉個例子，比如現在所有的模型都會相容 OpenAI API 的輸入輸出格式，開發者/使用者只需要替換 base_url、model、和 api_key 就能使用其他模型。
可以說，OpenAI 制定了大模型 API 的規範標準，包括流式輸出、Prompt、completion、tokens 等等。因為它的先發優勢，所有後來者都要遵守 openai SDK 的標準，以達到最佳的相容效果。
在 Agent 領域，OpenAI 應該說也是有點優勢的。他們最早開始搞 plugin，然後是 Function_call，GPTs，後來又有 Operator，Agents SDK 等等。
但是，他們始終沒有邁出去開源的那一步，始終沒有把目光、視野放到全部企業、全部應用、全部模型、全部使用者，沒有選擇構建 MCP 這樣的生態。
我看到很多人說，MCP 本質上和 Function_call 沒有區別。對啊，確實沒有區別，那 OpenAI 為什麼不做標準，不去維護好開源社區呢？
現在 MCP 已然成功，OpenAI 明白已經不可能再另起爐灶，讓大家都來相容自己的標準了，所以才選擇了相容 MCP，也算是「擁抱」了開源生態。
這對開發者和用戶來說自然是好事，學習成本低，開發的相容性更強。
但反過來，對於 OpenAI 來說，能做上游的標準制定者，誰願意做下游的跟隨採用者呢？
第五，某種程度上講，Manus 給 MCP 點了一把火。
當然，首先要說明的是，我知道 Manus 的技術棧里沒有使用 MCP[3]，我也知道 Manus 和 MCP 的成功之間沒有任何因果關係，我只是在表達，Manus 的出圈給 MCP 引流的相關性（哪怕只有一點點相關性）。
為什麼這麼說呢，因為 Manus 作為通用 Agent 吸引了大家的關注，給了大家「2025 Agent 可以落地」的希望，給 AI Agent 帶來了更高的關注度，也因而給 MCP 等協定層解決方案帶來了流量。
另一方面，Manus 的成功讓開發者意識到，Agent 依然需要大量的基礎設施層的工作。，我們需要一個統一的協議來連接 AI 模型與工具，而 MCP 作為現成的、已經具有一定規模的開源標準，進入了更多人的視野。
換句話說：Manus 的成功揭示了 AI Agent 與外部工具無縫交互的重要性，而 MCP 恰好提供了這樣的解決方案，天時地利人和，一切都剛剛好。
最後的一個開放題是，為什麼是 Anthropic？
我們簡單分析了 OpenAI 在 Agent 通用協議標準制定上的失敗，那反過來說，為什麼成功的是 Anthropic？他們家 Claude 也不開源啊，怎麼就想起來搞個 MCP，統一 Agent 協定呢？
這個問題沒有標準答案，畢竟選擇也好，成功也罷，都有歷史的偶然性。
我朋友提供了一個角度，那就是，儘管 OpenAI 的模型一直領跑，ChatGPT 做了很多應用工作，但在程式設計領域，Claude 是絕對的王者。
同時，Coding Agent 是最先落地的一個專用 Agent 方向，出現了 Cursor、Devin、Windsurf、cline 等大量的 Coding Agent 工具，而這些工具的首選模型，也是 Claude 3.5。
程式師是真的非常有「自我革命」精神，也是新技術最積極的採納者。比如，在 MCP 社區上[4]，一共分享有 4766 個 MCP Server，其中僅「開發者工具」分類下就有 2783 個，還不算其他各種程式設計分類。
MCP 的協定從提出，到規範，到開源，到廣泛採用，非一日之功。也許正是 Anthropic/Claude 長期以來在程式設計領域的領先，進而在 AI Coding Agent 取得成功，才促使他們構建起 MCP 這樣的開源標準。當然，這隻是一家之言，一個角度，供大家發散思考。
總之，MCP 挺好玩的，隨著 OpenAI 的表態，接下來應該會再迎來一波各家官方提供 MCP Server 的高潮。
寫了 3000 多字，感覺也只寫了個開頭。最近太忙了，有時間想多寫點，大家可以點點讚點點關注，給我上上壓力，哈哈。
最後，以大家吳恩達老師的慣用結尾作為結束吧：Keep Learning！