MCP：炒作還是AI新行標？

發布于 2025-4-7 00:34

瀏覽

0收藏

Model Context Protocol（MCP）最近在全網引發熱議——它真有實際價值，還是只是營銷號的氛圍感？LangChain 的 CEO Harrison Chase 和 LangGraph 負責人 Nuno Campos 針鋒相對，探討 MCP 是否真的值得關注。

Harrison：MCP 在你想要為一個你無法控制的智能體提供工具時就會變得有用。

如對Claude Desktop、Cursor 和 Windsurf 這些應用，用戶無法控制底層的智能體，而智能體本身只具備一些內置工具。

但若我想讓它使用一個默認沒有的工具呢？就需要某種協議，否則智能體根本不知咋調用這工具。

此外，我認為 MCP 對非開發者創建智能體也會很有幫助。目前趨勢，讓領域專家能夠構建智能體，而無需技術背景。這些用戶可能不會（或不愿）直接修改智能體的邏輯，但他們肯定希望給智能體添加一些工具。MCP此時就很有價值。

Nuno：我覺得你低估智能體與工具的適配度。確實，如果 Windsurf（假設它自帶的網頁搜索工具很差）支持用戶替換成一個更好的，那可行。但這不算真正的使用場景。

更吸引人的場景：用戶能僅靠一個神奇工具，就讓 Cursor 獲得連其開發者都沒想象過的新能力。但現實大多行不通。我見過的生產環境下，智能體的系統消息、架構甚至其他部分都必須根據所使用的工具進行調整。

Harrison：好吧，這些智能體的準確率可能達不到 99%……但即使不完美，它們仍可足夠實用，不是嗎？工具的描述和指令確實很重要，但我們也知道：

我不認為 MCP 及其工具調用能力能直接催生出下一個 Cursor，但它仍有一定價值，尤其在內部或個人智能體場景。

Nuno：但我們的工具調用測試表明，即便在專門為某些工具優化的智能體，當前模型的調用正確率只有 50%。如換成 MCP 這種通用協議，成功率恐怕更低。而即使個人智能體，一半的調用都失敗，這也沒啥用吧？

而且的確，模型會變更強，但用戶期望值也提高。貝索斯說：“客戶的期望永遠不會靜止不變——它們只會不斷上升。這是人性。”

如果你能掌控整個產品——UI、提示詞、架構、工具——你就能滿足這些期望。否則，Good luck！

Harrison：模型能力會持續進步，我愿意賭這點。所以無論當前智能體的成功率多少，未來只會更高。

我覺得正確比較方式不是拿 MCP 智能體 V.S 高度定制化智能體，而是看 MCP 能否提供靈活的集成能力。

就像 Zapier 讓你能將郵件連接到 Google Sheets、Slack 等。現實中有無數可能工作流，而 MCP 可讓用戶自己去創建它們，而不必等一個專門智能體來適配每種需求。

你覺得這個 Zapier 的類比如何？

Nuno：LangChain兩年前就已提供包含 500 個工具的庫，但我很少看到它們被真正用于生產環境。這些工具都遵循同樣的“協議”，可兼容任何模型，也可隨意替換。那 MCP 又有啥不同？是因為 MCP 的“優秀形態”要求用戶在本地終端里跑無數個服務器，還只能兼容桌面應用？這可不算優勢……

老實說，我覺得 Zapier 已經是 MCP 的上限 。

Harrison：MCP 工具和 LangChain 工具最大區別在：MCP 不是為智能體開發者設計。其最大價值在于讓用戶能為一個自己無法開發的智能體添加工具。

若我是一個開發，要從頭構建一個智能體，我不會用 MCP。但 MCP 目標用戶不是開發者，而是希望拓展現有智能體能力的普通用戶。MCP 讓非開發者也能給智能體添加工具，而 LangChain 工具更適合開發者使用。市場規模，非開發者數量遠大于開發者。

至于 MCP 目前形態，確實糟糕。但它未來會改進，設想的 MCP 未來形態：用戶可一鍵安裝 MCP 應用（無需再在本地終端跑服務器），而且能在 Web 端使用。我相信 MCP 正朝這方向發展。

你覺得 MCP 需要哪些改進？如果改進到位，你會認為它有價值嗎？

Nuno：好吧，聽起來 MCP 需要變成 OpenAI 的 Custom GPT，那它現在的熱度才合理。但Custom GPT 本身也沒那么火。MCP 又有啥獨特？

Harrison：其實，MCP 更像 OpenAI 的 插件（Plugins），但它們也沒成功 ?? 說實話，我幾乎沒用過插件，所以可能對它們的情況了解不深。但我認為：

Nuno：嗯，我不太確定 MCP 生態真的比插件更大。我隨便搜了一下，就找到一個 MCP 服務器目錄，目前上面列出 893 個服務器。而你可能只是看到 Twitter 上 MCP 相關的討論比較多 ??。

回到你的問題，如果 MCP 想要成為 AI 發展史上的一個重要章節，而不僅僅是個小插曲，它需要：

降低復雜度——為啥一個工具協議還要負責處理提示詞和 LLM 生成？
簡化實現——為啥一個工具協議需要雙向通信？我看過官方解釋，但光是為能接收服務器日志就這么做？不合理。
支持服務器端部署——一個無狀態協議才是關鍵，LLM 時代也不能忽視已有的在線擴展經驗。而一旦能用于服務器，還涉及身份認證（auth），分布式環境下不易解決。
彌補質量損失——智能體隨意調用陌生工具，往往會導致體驗下降，如何彌補？

Harrison：你說的對，我可能確實受到 Twitter 上最近 MCP 討論的影響。但同時，Twitter 上也有很多懷疑的聲音！

所以，你認為 MCP 是曇花一現，還是未來標準？

本文轉載自??JavaEdge??，作者：JavaEdge

標簽

贊

回復