模型上下文协议 (MCP) 近来在 Twitter 上引发热议，但它究竟是真有价值，还是仅仅是又一次炒作？ 在这场辩论中，LangChain 首席执行官 Harrison Chase 和 LangGraph 负责人 Nuno Campos 展开交锋，深入探讨 MCP 的前景与价值。
Harrison： 我认为 MCP 确实大有可为。最初我对它持保留态度，但现在我逐渐看到了它的潜力。 核心价值在于： 当你需要为你无法直接控制的智能体扩展工具时，MCP 就显得尤为重要。
举例来说，对于像 Claude Desktop、Cursor、Windsurf 这样的应用，作为用户，我们无法触及它们底层的智能体逻辑。 这些智能体只能使用预先集成的少量内置工具。
但如果我们希望它们能够使用默认配置之外的工具呢？ 这就需要一种协议规范来解决问题，否则智能体如何知晓并调用这些外部工具？
我相信 MCP 对于非开发者构建智能体也将大有裨益。 当前的一个趋势是，越来越多的行业专家希望能够参与到智能体的构建中来，无论他们是否具备深厚的技术背景。 这些"智能体构建者"通常不希望，或者说不具备能力，去修改智能体底层的代码逻辑，但他们一定希望能够为智能体赋予特定的工具能力。 而 MCP 正好可以满足这种需求。
Nuno： 我认为你可能低估了工具与智能体其他组件之间深度适配的重要性。 诚然，如果像 Windsurf 这样的应用（天哪！）内置了一个糟糕的网页搜索工具，你想用更好的工具来替换它，这或许可行。 但这并非 MCP 真正有价值的应用场景。
真正令人兴奋的应用场景是，用户可以通过注入你"独门秘籍"般的工具，赋予 Cursor 等应用开发者都意想不到的全新能力。 但在实际应用中，这种情况往往难以实现。 我所见过的几乎所有生产级别的智能体，都需要针对所集成的工具进行深度定制，包括调整系统提示，甚至是智能体的整体架构。
Harrison： 话虽如此，这些集成了 MCP 工具的智能体，即使不能达到 99% 的完美可靠，也可能已经足够好用，能够满足一定的需求，不是吗？ 工具的描述和使用说明固然重要！ 但我们也要看到：
- MCP 本身就支持工具定义。 优秀的 MCP 服务器提供的工具描述，很可能比我们临时编写的描述更加完善和有效。
- MCP 允许自定义提示 (Prompts)。 这意味着我们可以通过提示来引导智能体更好地使用工具。
- 随着底层大模型的不断进化，开箱即用的工具调用能力必将显著提升。 我不认为会有人仅仅依靠 MCP 集成和通用的工具调用智能体，就能打造出媲美 Cursor 的下一代应用。 但 MCP 肯定有其内在价值，尤其是在构建内部或个人智能体方面。
Nuno： 我们自己进行的工具调用基准测试表明，即使是那些架构和提示词都针对特定工具集量身定制的智能体，当前的模型在工具选择上的正确率也只有一半左右。 设想一下，一个工具调用成功率只有一半的个人智能体，其可用性实在令人担忧……
诚然，模型会不断进步，但用户的期望也会随之水涨船高。 正如杰夫·贝索斯所说："我欣赏顾客的一点是，他们天生就'不满'。 他们的期望从不是一成不变的，而是不断攀升的。 这就是人性。"
如果你掌控了整个技术栈——从用户界面 (UI) 到提示词，再到智能体架构和工具本身——你或许还能勉力满足这些日益增长的期望。 否则，恐怕只能祝你好运了。
Harrison： 模型性能持续提升是毋庸置疑的大趋势，对此我充满信心。 因此，无论当前智能体的工具调用成功率如何，未来都只会不断提高。
我认为，将 MCP 方案构建的智能体，与那些针对特定工具深度优化的成熟智能体直接比较，是不恰当的。 MCP 的真正价值在于其能够实现大量的、个性化的长尾连接和集成。
就像 Zapier 那样，它可以将电子邮件与 Google Sheets、Slack 等各种应用和服务无缝连接。 我们可以基于 MCP 构建出数量庞大、种类繁多的定制化工作流，而不可能为每一种工作流都开发一个完美打磨的专属智能体。 借助 MCP，我们就能快速创建满足自身特定需求的"定制版 Zapier"。
你觉得用 Zapier 来类比 MCP 恰当吗？
Nuno： 在 LangChain，我们早在两年前就推出了包含 500 多个工具的工具库，但遗憾的是，我并没有看到这些工具在实际生产环境中得到广泛应用。 这些工具都遵循相同的"协议"标准开发，与各种模型兼容，并且支持即插即用。 那么，MCP 的独特之处究竟在哪里呢？ 难道仅仅是它那"令人惊叹"的形式——需要在本地终端运行无数个服务器，而且只能在桌面应用中使用？ 这怎么看都不像是什么优势。 坦白说，我认为 Zapier 已经是 MCP 能够达到的上限了。
Harrison： 我认为 LangChain 工具和 MCP 工具的核心区别在于，MCP 并非为智能体的开发者而设计。 当你需要为你无法自行开发的智能体扩展工具能力时，MCP 的价值才能真正体现。
需要明确的是——如果我要开发一个全新的智能体来完成 XYZ 任务，我肯定不会选择 MCP。 因为我并不认为那是 MCP 的目标应用场景。 MCP 的目标是为那些你无法控制的智能体添加工具。 此外，MCP 还能够让非开发者也能轻松为智能体扩展工具能力（而 LangChain 工具主要面向开发者）。 要知道，非开发者的数量远超开发者。
至于 MCP 目前这种略显笨拙的使用形式？ 确实有待改进。 但它一定会变得更好，对吗？ 我设想的 MCP 未来形态是： 用户可以一键安装 MCP 应用（无需再在本地终端运行服务器），并且可以在 Web 应用中直接使用。 我相信这才是 MCP 的发展方向。
你认为 MCP 需要做出哪些改变，才能让你相信它真的有价值？
Nuno： 好吧，你的意思是 MCP 需要变得更像 OpenAI 的 Custom GPTs，这样当前的这波热潮才算师出有名。 但问题是，Custom GPTs 本身也并不算非常流行。 那么，Custom GPTs 究竟缺了什么，而 MCP 又拥有什么独特的优势呢？
Harrison： 我的意思是，MCP 其实更像是插件 (Plugins)，而插件的尝试也并未获得成功，不是吗？ 我对插件的体验已经有些模糊了（甚至不确定自己是否真正用过 Plugins），所以我的类比可能不完全准确。 但我认为：
- MCP 的生态系统已经远超插件。
- 如今的模型性能更强大，也更有能力有效地利用这些工具。
Nuno： 嗯，我不确定 MCP 的生态系统是否真的更大。 我随便在网上搜了一下，找到一个随机的 MCP 服务器目录，它在撰写本文时只列出了 893 个服务器。 我怀疑你是不是把 Twitter 时间线上提到 MCP 的推文数量，当成了实际基于 MCP 构建的应用数量了？ 🙂 言归正传，回到你刚才提出的问题，我认为，如果 MCP 不想仅仅成为人工智能发展史上的一个短暂注脚，它就必须做到以下几点：
- 降低复杂性。 为什么一个工具协议需要同时承担提示词处理和 LLM 补全 (completions) 的功能？
- 简化实现难度。 为什么一个服务于工具的协议需要双向通信？ 是的，我读过 MCP 官方列出的种种理由，但恕我直言，仅仅为了从服务器接收日志，并非一个充分合理的理由。
- 支持在服务器端部署。 无状态协议是实现服务器端部署的关键——不能因为我们现在都在用大语言模型 (LLM) 进行开发，就忘记了那些在 Web 服务规模化扩展方面积累的宝贵经验教训。 一旦支持服务器端部署，一系列新的问题也会浮出水面，例如身份验证 (Auth)（这在分布式环境下并非易事）。
- 解决集成随机工具带来的质量损失问题。 将未经适配的工具随意接入智能体，势必会影响智能体的整体性能和用户体验。
Harrison： 你说的或许有道理，我最近可能确实因为过于关注 Twitter 上的讨论，而产生了一些认知偏差。 但 Twitter 上对 MCP 的质疑声音也同样不少啊！
所以，不如让我们把这个问题抛给大众，听听大家的看法。 参与下面的 Twitter 投票，投出你的一票——你认为 MCP 会是昙花一现，还是会成为未来的行业标准？
