图片来源：LangChain
Z Highlights
当你想将tool带入一个你无法控制的Agent时，MCP就是有用的。
在我见过的几乎所有生产环境中的Agent中，你需要根据提供的工具调整系统消息，甚至调整架构的其他部分。
我想象一个未来的MCP状态：你可以一键安装MCP应用，不再需要在本地终端运行服务器，并且它们可以在Web应用中使用。
Model Context Protocol (MCP) 在Twitter上引起了不小的轰动——但它是否真正有用？还是说，只是一时喧哗？在这次讨论中，Harrison Chase（LangChain CEO）和Nuno Campos（LangGraph负责人）讨论了MCP是否实至名归。
适用场景
Harrison：MCP实际上有用。我最初对它持怀疑态度，但我已经看到了它的价值。从本质上来说：当你想将工具带入一个你无法控制的Agent时，MCP就是有用的。
举个例子：以Claude Desktop、Cursor、Windsurf为例——作为用户，我无法控制底层Agent，它只能访问一些内置工具。
但是，如果我想让它访问一个默认没有的工具怎么办？想做到这一点，就得有某种协议——否则它怎么知道如何调用这个工具？
这对非开发者创建Agent也很有用。能看到其中一个趋势：人们希望领域专家能够建立Agent，同时不需要太多技术知识。这些构建者很少想（或能够）编辑Agent逻辑本身——但他们可能想让Agent访问某些工具。这时候MCP就会有用。
局限性
Nuno：Agent的其他部分也许需要根据你提供的工具进行定制，在这方面你可能低估了。当然，如果Windsurf附带一个糟糕的网页搜索工具，而你想用一个好的替换它，这时候MCP也会有用，但这并不是真正的使用场景。
真正有说服力的使用案例——通过仅嵌入一个神奇的工具，就能给Cursor提供新增的能力，这是它的创建者们从未设想的——在实际操作中多数是行不通。在我见过的几乎所有生产环境中的Agent中，你需要根据提供的工具调整系统消息，甚至调整架构的其他部分。
Harrison：嗯，这些Agent可能并没有达到99%的可靠性……但它们大概还是很好用的吧？工具描述和指令的确很重要——但我们也知道：
MCP有工具定义——而好的MCP server可能会提供比你快速写出的还要好的tool description；
MCP允许使用提示——因此你可以加入特定指令；
随着基础模型的进步，现成的工具调用Agent会更好的。
没有人会仅仅基于MCP集成和工具调用Agent构建下一个Cursor，但这肯定有点价值吧？比如内部或个人Agent？
Nuno：嗯，我们自己的工具调用基准测试表明，在半数情况下，当前模型无法调用正确的工具——而这在一些Agent之中，它们有架构，并且有针对该特定工具集定制来了提示。即使是一个常常失败的的个人Agent也不太有用……
没错，模型是会变得更好——但用户的期望也会更高。别听我的，听Bezos的：“我喜欢客户的一点是，他们天生不会满足。他们的期望永远不会停滞，而会走高。这是人性。”
如果你拥有整个技术栈——UI、提示、架构、工具——那你就可以满足这些期望。否则——只能祝你好运。
未来展望
Harrison：模型会继续变得更好——我对这一点很有信心。所以，不管目前Agent的成功率如何，它只会变得更高。正确的比较方式，不是将我可以使用MCP构建的Agent与那些配备工具的成熟Agent进行比较，真正的价值将在我想要的那些大量小众或特定的连接和集成。
像Zapier，它是将email连接到Google Sheets、Slack等。我要创建的工作流是无穷无尽的，而且可能不会为每个工作流都提供成熟的Agent。有了MCP，我可以创建它们的自定义版本。你觉得这个Zapier类比怎么样？
Nuno：在LangChain，我们有一个包含500个工具的库。虽然已经两年了，但我并没有看到它们在生产环境中被广泛使用。它们都是按照相同的“协议”实现的，兼容任何模型，并且可以互换。那么，区别在哪里呢——是因为MCP需要在本地终端运行一百万个服务器，并且只兼容桌面应用吗？这对我并不是一个优点。说实话，我确实认为Zapier是MCP潜力的上限。
Harrison：LangChain工具和MCP工具的区别在于，MCP不是为Agent的开发者设计的；当你需要将工具引入一个你无法开发的Agent时，它最有用。
明确一点——如果我在编写一个代理来做XYZ，肯定不会使用MCP。但这不是MCP的目标用例。MCP是将工具带入你无法控制的Agent中，它还使非开发者能够将工具带入Agent（而LangChain工具则是面向开发者的）。非开发者的数量远大于开发者。
至于目前MCP的形式？没错，它很糟糕，但它会变得更好。我想象一个未来的MCP状态：你可以一键安装MCP应用，不再需要在本地终端运行服务器，并且它们可以在Web应用中使用。我敢赌，MCP一定会朝这个方向发展。
你认为MCP需要改变什么，这些足以说服你它们有用吗？
Nuno：MCP需要变得更像OpenAI的Custom GPTs，那样当前的炒作才会得到证明。但Custom GPTs也并不那么流行。那么问题来了——GPTs缺少了什么，但同时MCP拥有？
Harrison：MCP更像是插件，它也没有成功��我几乎忘了插件体验（不确定我是否曾用过），所以我做的任何比较可能都不准确。但：
MCP的生态系统已经比插件的生态系统大得多；
模型已经变得更好，更能使用这些工具；
Nuno：我不确定生态系统是否更大。我随便找的一个目录，只花了5秒钟，就列出了893台服务器（截至撰写时）。可能你是在计算Twitter时间线中提到MCP的推文数量，而不是实际构建的东西��但回到你没有回答的问题：如果MCP真的要成为AI历史中的里程碑，它需要：
变得不那么复杂。为什么一个工具协议还需要提供提示和LLM完成？
变得更容易实现。为什么一个工具服务协议需要双向通信？我读过它们列出的所有理由，但从服务器接收日志并不是一个足够好的理由；
在服务器上可用。无状态协议是关键——仅仅因为我们在构建LLM，并不意味着我们应该忘记所有在线扩展的艰辛经验。而一旦可以在服务器上使用，许多其他问题就会出现，比如认证（在分布式环境中解决认证问题并不很容易）。
将随机工具插入一个完全不了解它们的Agent中会带来质量损失，这个要弥补。
Harrison：你可能是对的，我最近确实有一些源自Twitter时间线的偏见。但那上面也有很多怀疑的声音！所以，让我们把问题交给大家。
原文：MCP：Flash in the Pan or Future Standard?
https://blog.langchain.dev/mcp-fad-or-fixture/
编译：Christine Liu
请注意，本文编译自文末载明的原始链接，不代表Z Potentials立场。如果您对本文有任何想法或见解，欢迎在评论区留言互动探讨。
Z Potentials将继续提供更多关于人工智能、机器人、全球化等领域的优质内容。我们诚邀对未来充满憧憬的您加入我们的社群，与我们共同分享、学习、成长。