MCP：昙花一现还是未来标准？

模型上下文协议 (MCP) 在 Twitter 上引起了不小的轰动 – 但它真的有用，还是仅仅是炒作？在这场辩论中，Harrison Chase（LangChain 首席执行官）和 Nuno Campos（LangGraph 负责人）就 MCP 是否名副其实展开了讨论。

Harrison： 我将持 MCP 实际上有用的立场。起初我对此持怀疑态度，但我已经开始看到它的价值。本质上：当你想为你无法控制的 Agent 引入工具时，MCP 非常有用。

让我举个例子。对于 Claude Desktop、Cursor、Windsurf - 作为用户，我无法控制底层的 Agent。该 Agent 可以访问一些内置工具。

但如果我想让它访问默认情况下没有的工具呢？为了做到这一点，需要存在某种协议——否则它怎么知道如何调用该工具？

我相信这对非开发人员创建 Agent 也很有用。我们看到的一个趋势是，人们希望让主题 matter 专家也能访问 Agent 构建，而无需考虑他们的技术专业知识。我认为这些构建者很少会想要（或能够）编辑 Agent 逻辑本身 - 但他们会希望让 Agent 访问某些工具。MCP 在这里将很有用。

Nuno： 我认为你低估了 Agent 的其余部分需要根据你赋予它的工具进行定制的程度。当然，如果 Windsurf（天哪）附带了一个糟糕的网络搜索工具，而你想用一个好的工具替换它，那会起作用。但这并不是一个真正的用例。

引人注目的用例——即使是 Cursor 的创建者也梦想不到，你仅仅通过注入你一个神奇的工具就能赋予它新功能——在实践中大多数时候都不会奏效。在我见过的几乎所有生产 Agent 中，你都需要定制系统消息，甚至架构的其他部分，以适应你提供的工具。

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

1. MCP 有工具定义 - 而且好的 MCP 服务器可能会提供比你快速编写的更好的工具描述。
2. MCP 允许提示 - 因此你可以包含说明。
3. 随着底层模型变得更好，开箱即用的工具调用 Agent 将会变得更好。

我不认为任何人会仅仅基于 MCP 集成和一个工具调用 Agent 来构建下一个 Cursor，但肯定存在一些价值？例如，内部或个人 Agent。

Nuno： 嗯，我们自己的工具调用基准测试表明，当前的模型大约有一半的时间无法调用正确的工具——即使是在架构和提示为该确切工具集量身定制的 Agent 中也是如此。即使是一个一半时间都会失败的个人 Agent 也不是很有用……

是的，模型会变得更好——但用户的期望也会如此。不要听我的，听听贝索斯的：“我喜欢顾客的一点是，他们天生就不满足。他们的期望永远不是静态的——它们会上升。这是人性。”

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

Harrison： 模型将继续变得更好 - 我很乐意为此下注。所以无论现在 Agent 的成功率如何，它只会上升。

我认为正确的比较不是将我可以用 MCP 构建的 Agent 与具有这些工具的完善 Agent 进行比较。我认为真正的价值将体现在我想建立的连接和集成的长尾中。

就像 Zapier 一样，它是关于将电子邮件连接到 Google 表格、Slack 等。我可以创建无数的工作流程，并且很可能不会为每个工作流程都创建一个完善的 Agent。有了 MCP，我可以创建我自己的版本。

你觉得 Zapier 的类比怎么样？

Nuno： 在 LangChain，我们已经拥有一个包含 500 个工具的库两年了，但我还没有看到它们在生产中被经常使用。它们都按照相同的“协议”实现，与任何模型兼容，并且可互换。那么这里的区别是什么——是 MCP 令人惊叹的外形，即必须在我的终端本地运行数百万个服务器，并且仅与桌面应用程序兼容？这听起来对我来说不是一个优点。老实说，我确实认为 Zapier 是 MCP 潜力的上限。

Harrison： 我认为 LangChain 工具和 MCP 工具之间的区别在于，MCP 不是为 Agent 的开发人员准备的。当为 Agent 引入你无法开发的工具时，它们最有用。

需要明确的是 - 如果我要编写一个 Agent 来执行 XYZ - 我绝对不会使用 MCP。但我认为这不是 MCP 的目标用例。MCP 是为 Agent 引入你无法控制的工具。它还使非开发人员能够为 Agent 引入工具（而 LangChain 工具则以开发人员为中心）。非开发人员比开发人员多得多。

至于当前的 MCP 外形？是的，它很糟糕。但它会变得更好，对吧？我正在想象 MCP 的未来状态，你只需一键安装 MCP 应用程序（不再需要在本地终端中运行服务器），并且可以在 Web 应用程序上访问它们。我敢打赌，这就是 MCP 的发展方向。

你认为 MCP 需要改变什么，并且这些改变足以让你相信它们是有用的吗？

Nuno： 好的，所以 MCP 需要变得更像 OpenAI 的自定义 GPT，那时当前的炒作才会被证明是合理的。但是自定义 GPT 也不是很受欢迎。那么问题出在哪里——GPT 中缺少什么而 MCP 拥有？

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

• MCP 的生态系统已经比插件的生态系统大得多
• 模型变得更好，并且更有能力使用这些工具

Nuno： 嗯，我不知道生态系统是否更大。我在 5 秒内找到的一个随机目录在撰写本文时列出了 893 个服务器。我认为你可能是在计算你的时间线上提到 MCP 的推文数量，而不是实际用它构建的东西 🙂 但回到你未回答的问题，在我看来，如果 MCP 要想不仅仅是 AI 历史上的一个脚注，它需要

• 变得更简单。 为什么工具协议还需要提供提示和 LLM 完成？
• 变得更容易实现。 为什么服务工具的协议需要双向通信？是的，我已经阅读了他们列出的所有原因，但是，对不起，从服务器接收日志不是一个充分的理由。
• 可以在服务器上使用。无状态协议是关键——仅仅因为我们正在使用 LLM 构建，并不意味着我们应该忘记在线扩展东西的所有来之不易的经验教训。一旦可以在服务器上使用，就会出现许多其他问题，例如身份验证（这在分布式环境中不容易解决）。
• 弥补质量损失，这种质量损失来自于将随机工具插入到一个对它们一无所知的 Agent 中。

Harrison： 你可能是对的，我的 Twitter 时间线让我产生了一些近因偏差。但那里也有很多怀疑的声音！

所以，让我们把它转回给他们。在下面的 Twitter 投票中投下你的一票 - MCP 是昙花一现还是未来标准？