LangChain创始人激辩MCP： 这是行业新标准，还是昙花一现？

Agentic AI 正在成为行业最关注的热点，围绕着大模型如何调用工具，现在有 computer/browser use 和 agent 协议两种主流方案，后者以 Anthropic 在去年发布的 MCP 为主。

有部分观点认为，让 AI 使用为人用设计的电脑/浏览器是非常低效的方案，大模型一定会带来新的软件生态，新的生态也就需要新的标准。

本文来源于 LangChain 官方博客，内容是 LangChain 联合创始人、CEO Harrison Chase 与 LangGraph 负责人 Nuno Campos 针对 MCP 的辩论，探讨 MCP 究竟是昙花一现的热点还是注定成为未来的标准。

原文标题《MCP：是昙花一现，还是未来标准？》( MCP: Flash in the Pan or Future Standard?)

原文链接：https://blog.langchain.dev/mcp-fad-or-fixture/

Harrison：我的观点是，MCP 其实是很有用的。起初我持怀疑态度，但现在我开始看到它的价值。

从本质上讲：当你想为一个你不能控制的 agent 引入工具时，MCP 就会派上用场。

举个例子。对于 Claude 桌面端、Cursor 和 Windsurf 来说，作为用户，我控制不了底层的 agent，它们可以访问一些内置工具。

但如果我想要让它访问一个内置里没有的工具咋办？要做到这点，就需要存在某种协议——某则它怎么知道如何调用这个工具呢？

我相信这对非开发者创建 agent 也会很有用。我们看到的一个趋势是，人们希望让各个领域的专家都能参与 agent 的构建，无论他们的技术水平如何。我认为这些 builder 很少会想要（或者能够）去编辑 agent 的逻辑本身——但他们会希望让 agent 能够使用某些工具。在这方面，MCP 会很有用。

Nuno：我觉得，你还需要把 agent 的剩余部分与你接入的工具进行适配，你低估了这里需要进行定制的程度。当然，如果 Windsurf（但愿不会）本身有一个糟糕的网络搜索工具，而你想把它换成一个好的，那是可行的。但这并不是一个真正的应用场景。

那个看似很有吸引力的场景——仅仅通过注入一个神奇的工具，就能赋予 Cursor 连它的开发者都未曾想到的新能力——在大多数实际情况下其实是行不通的。在我见过的几乎所有生产环境中的 agent 中，你都需要根据你提供的工具来定制系统消息，甚至是架构的其他部分。

Harrison：嗯，这些 agent 可能达不到 99%的可靠性……但它们可能仍然足够好用吧？工具的描述和说明肯定很重要！但我们也知道：

1. MCP 有工具定义——而且好的 MCP 服务器可能会提供比你快速编写的更好的工具描述。

2. MCP 允许设置提示——所以你可以加入指令。

3. 随着底层模型的不断改进，现成的工具调用 agent 也会变得越来越好。

我不认为有人会仅仅基于 MCP 集成和一个工具调用 agent 来构建下一个 Cursor，但肯定还是有一些价值的吧？比如内部或个人使用的 agent。

插播：周三晚，开源复现 Manus 分享

Nuno：嗯，我们的工具调用的基准测试表明，当前的模型大约有一半的时间无法调用正确的工具——而且这还是在 agent 的架构和提示都是为那套特定工具量身定制的情况下。即使是一个有一半时间会出错的个人 agent ，也不是特别有用……

而且没错，模型会变得更好——但用户的期望也会提高。别光听我这么说，听听 Bezos 是怎么说的：“我喜欢客户的一点是，他们永远不满足。他们的期望永远不是一成不变的——而是不断提高的。这是人之常情。”

如果你拥有整个技术栈——用户界面、提示、架构、工具——你实际上才能满足这些期望。否则，祝你好运吧。

Harrison：模型会不断改进——我很有信心这一点。所以无论现在 agent 的成功率是多少，它只会提高。我认为正确的比较不应该是将我用 MCP 构建的 agent 与使用那些工具精心打造的 agent 进行对比。我认为真正的价值在于我想要进行的大量长尾连接和集成。

就像 Zapier（自动化工作流平台）一样，它是关于将电子邮件与谷歌表格、Slack 等连接起来。我可以创建无数的工作流程，而且不太可能为每一个流程都打造一个精心设计的 agent 。有了 MCP，我就可以创建自己的版本。

你觉得拿 Zapier 来类比怎么样？

Nuno：在 LangChain，我们有一个包含 500 个工具的库，已经有两年了，但我很少看到它们在生产环境中被使用。它们都是按照相同的“协议”实现的，与任何模型都兼容，而且可以互换。那么这里的区别是什么呢——难道是 MCP 那令人惊叹的形式吗，比如要在本地终端运行无数个服务器，而且只与桌面应用程序兼容？这对我来说可不算是一个优点。说实话，我确实认为 Zapier 是 MCP 潜力的上限。

Harrison：我认为 LangChain 的工具和 MCP 的工具之间的区别在于，MCP 不是为 agent 的开发者准备的。当你要为一个你无法开发的 agent 引入工具时，MCP 才是最有用的。

明确地说——如果我要编写一个执行某项任务的 agent ——我绝对不会使用 MCP。但我不认为这是 MCP 的目标应用场景。MCP 是为你无法控制的 agent 引入工具的。它还能让非开发者为 agent 引入工具（而 LangChain 的工具主要是面向开发者的）。非开发者的数量可比开发者多得多。

至于目前 MCP 的形式？它确实很糟糕。但它会变得更好，对吧？我想象着 MCP 的未来状态，你可以一键安装 MCP 应用程序（不用再在本地终端运行服务器了），而且可以在网页应用上使用它们。我敢打赌，这就是 MCP 的发展方向。

你认为 MCP 需要做出哪些改变，这些改变足以让你相信它是有用的吗？

Nuno：好吧，所以 MCP 需要变得更像 OpenAI 的定制版 GPT，到那时的热度才算是名正言顺。但定制版 GPT 也不是那么受欢迎。那么问题来了——MCP 有什么是 GPT 所没有的呢？

Harrison：我的意思是，MCP 更像是插件，而插件也没有成功过🙂 我有点忘了使用插件的体验（不确定我是否用过），所以我做的任何比较可能都不准确。但我想说：

• MCP 的生态系统已经远比插件的生态系统庞大得多了。

• 模型已经变得更好，也更有能力使用这些工具了。

Nuno：嗯，我不知道它的生态系统是不是真的更大。我在五秒钟内找到的一个随机目录显示，在撰写本文时，有 893 个服务器。我觉得你可能是在数你推特时间线上提到 MCP 的推文数量，而不是实际使用它构建的东西的数量🙂 但回到你还没得到答案的那个问题上，在我看来，如果 MCP 想要在 AI 的历史上不只是一个注脚的话，它需要做到以下几点：

• 变得不那么复杂。为什么一个工具协议还需要处理提示和大语言模型的补全呢？

• 变得更容易实现。为什么一个提供工具的协议需要进行双向通信呢？是的，我已经看过他们列出的所有理由了，但很抱歉，从服务器接收日志并不是一个足够好的理由。

• 能够在服务器上使用。无状态协议是关键——仅仅因为我们在使用大语言模型进行开发，并不意味着我们应该忘记在网络上进行扩展所积累的宝贵经验。一旦能够在服务器上使用，就会出现许多其他问题，比如身份验证（在分布式环境中这可不容易解决）。

• 弥补在一个对工具一无所知的 agent 中插入随机工具所带来的质量下降问题。

Harrison：你可能说得对，我在推特时间线上确实存在一些近因偏差。但上面也有很多人持怀疑态度啊！

所以，让我们把问题抛回给大家。MCP 是昙花一现，还是未来的标准呢？