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

Harrison Chase & Nuno Campos2024年5月1日大约 6 分钟

Model Context Protocol (MCP) 在Twitter上引起了轩然大波——但它真的有用，还是只是噪音？在这场辩论中，Harrison Chase（LangChain CEO）和Nuno Campos（LangGraph负责人）讨论了MCP是否名副其实。

Harrison的观点：MCP确实有用

我一开始对MCP持怀疑态度，但我已经开始看到它的价值。本质上：当你想为自己无法控制的agent添加工具时，MCP就很有用。

举个例子。对于Claude Desktop、Cursor、Windsurf这些应用，作为用户，我无法控制底层agent。这些agent默认只能访问几个内置工具。

但如果我想让它访问默认没有的工具怎么办？为此，需要存在某种协议—否则它怎么知道如何调用工具？

我相信这对非开发人员创建agent也会很有用。我们看到的趋势之一是，人们希望让agent构建对所有领域专家accessible，无论他们的技术专业知识如何。我认为这些构建者很少想要（或能够）编辑agent逻辑本身—但他们会希望让它访问特定工具。MCP在这里会很有用。

我认为你低估了agent其他部分需要为工具而定制的程度。当然，如果Windsurf（上帝保佑）配备了一个糟糕的网络搜索工具，你想用一个好的替换它，那会起作用。但这不是真正的用例。

真正有吸引力的用例—你通过注入一个神奇工具就能给Cursor带来其创造者都没想到的新能力—在实践中大多数时候都行不通。在我见过的几乎所有生产环境中的agent，你都需要根据可用的工具来调整系统提示信息，甚至架构的其他部分。

好吧，这些agent可能不会99%可靠...但它们可能仍然足够好用？工具描述和指令确实很重要！但我们也知道：

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

嗯，我们自己的工具调用基准测试表明，目前的模型大约有一半时间无法调用正确的工具—而这还是在为特定工具集量身定制架构和提示的agent中。即使是个人agent，失败率50%也不怎么实用...

是的，模型会越来越好—但用户的期望也会越来越高。别听我的，看看贝佐斯怎么说："我喜欢顾客的一点是，他们永远不满足。他们的期望永远不是静态的—它们只会上升。这是人性。"

如果你拥有整个技术栈—UI、提示、架构、工具—你才能真正满足这些期望。否则，祝你好运。

模型会继续变好—我敢打这个赌。所以无论agent现在的成功率是多少，它只会上升。

我认为正确的比较不是我用MCP构建的agent与那些工具打磨过的agent。我认为真正的价值在于我想要创建的长尾连接和集成。

就像Zapier，它是关于将电子邮件连接到Google Sheets、Slack等。我可以创建无数个工作流，而且可能不会有一个完善的agent适用于每一个工作流。有了MCP，我可以创建自己的版本。

你觉得Zapier这个类比如何？

在LangChain，我们已经有了500个工具库两年了，我很少看到它们在生产中使用。它们都实现了相同的"协议"，与任何模型兼容，可以互换。那么区别是什么—是MCP那种在本地终端运行百万个服务器并且只与桌面应用兼容的神奇形式吗？对我来说这不是优势。老实说，我确实认为Zapier是MCP潜力的上限。

我认为LangChain工具和MCP工具的区别在于，MCP不是为agent的开发者设计的。当你将工具引入一个你无法开发的agent时，它们最有用。

明确一点—如果我正在编写一个agent来做XYZ—我绝对不会使用MCP。但我不认为这是MCP的目标用例。MCP是将工具引入你无法控制的agent。它还使非开发者能够将工具引入agent（而LangChain工具是面向开发者的）。非开发者比开发者多得多。

至于当前的MCP形式？是的，它很糟糕。但它会变得更好，对吧？我想象中的MCP未来状态是，你可以一键安装MCP应用（不再在本地终端运行服务器），它们在网络应用上也能访问。我敢打赌MCP正朝着这个方向发展。

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

好的，所以MCP需要变得更像OpenAI的自定义GPTs，那时当前的炒作才会被证明是合理的。但自定义GPTs也不是那么受欢迎。那么，GPTs缺少了什么是MCP拥有的呢？

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

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

变得不那么复杂。为什么工具协议还需要提供提示和LLM补全？
变得更容易实现。为什么一个服务工具的协议需要双向通信？是的，我读过他们列出的所有理由，抱歉，从服务器接收日志不是一个足够好的理由。
能在服务器上使用。无状态协议是关键—仅仅因为我们用LLMs构建并不意味着我们应该忘记所有关于在线扩展的经验教训。一旦可以在服务器上使用，就会出现其他问题，如身份验证（在分布式方式中不容易解决）。
弥补将随机工具插入一个对它们一无所知的agent所带来的质量下降。

你可能是对的，我的Twitter timeline有一些近期偏见。但那上面也有很多质疑！