摘要：“在 MCP 出现之前，开发者必须编写代码，并通过 API 将 AI 工具与外部系统连接，这意味着每个集成都需要预先编码。”AI 代理开发者 John Rush 说道，而“MCP 是一个标准协议。这意味着每个 AI 工具只需实现一次，然后就可以通过这个协议连接
整理 | 褚杏娟 核子可乐
近期，MCP 热度极高。
“在 MCP 出现之前，开发者必须编写代码，并通过 API 将 AI 工具与外部系统连接，这意味着每个集成都需要预先编码。”AI 代理开发者 John Rush 说道，而“MCP 是一个标准协议。这意味着每个 AI 工具只需实现一次，然后就可以通过这个协议连接到数千个外部工具。”
开发者 Julian Harris 进一步补充道，MCP 提供了“一个将任何 API 转化为 LLM 工具插件的标准接口”，从而实现了“以超低摩擦的方式丰富 LLM 的上下文”。
然而，质疑声同样存在。有开发者将其类比为“为 AI 打造的 Zapier”，认为它不过是给 API 使用增加了额外步骤。
此外，部分人担忧，一些主流 LLM 服务商如 Grok 和 ChatGPT 等目前尚未支持该协议，且这些系统设计者极可能试图推行自有标准。不过，Anthropic 应用 AI 工程师 Mahesh Murag 曾表示，MCP 本身与 Anthropic 的 Claude 并无任何内在联系。
AI 领域瞬息万变。MCP 虽于去年发布，但近期突然爆火，也引发了人们对其“花期”能持续多久的讨论。LangChain 还在 x 上发起了一项投票：结合实际用例、与 OpenAI Plugin 的比较以及 MCP 自身的局限性，大家认为它到底是昙花一现、还是未来标准？
结果显示，有 40.8% 的人认为 MCP 是未来标准，25.8% 的人认为 MCP 只是昙花一现，剩下 33.4% 的人选择观望。
如何打败一众标准，脱颖而出？
任何新协议的影响力，取决于其被采纳的程度。
被广泛接受的标准，如 Kubernetes、React 和 HTTP，通过将爆炸性的 MxN 问题转化为可管理的 M+N 生态系统解决方案来适应开发者们各种各样的需求。一旦达到临界规模，它们便将具有巨大的价值。
目前，MCP 已经积累了足够的临界规模和动能，因此它被视为 2023-2025 年“代理开放标准”之争的潜在赢家。有人预计，按照当前的速度，MCP 将在 7 月超越 OpenAPI：
许多“老派开发者”起初会对 MCP 的成功感到困惑，因为从技术层面来看，MCP 基本上具备与现有标准（如 OpenAPI、OData、GraphQL、SOAP 等）相同的功能。然而，如果将 MCP 简单地完全等同于 OpenAPI ，并认为它的成功只是一种潮流的循环，就过于武断。
MCP 可以视为是一种“AI 原生”标准，能够体现出每个 Agent 中独立复现的模式，相比那些未考虑这些特性而设计的不可知论标准，这种原生标准在使用和开发工具时会更加便捷和高效，这方面表现要超过 OpenAPI。
MCP 的出现相较第一波 LLM 框架较晚，它拥有足够的战略空间，避免从大模型互操作性这种“显而易见”的点切入，而是专注于以动态上下文访问为核心的那些还未解的棘手难题。因此，MCP 一定程度上优于 LangChain 等。
Murag 表示，MCP 并不会取代代理框架，而是通过提供可插拔的连接器和适配器来补充，并通过提供一致的工具交互方式，让开发者的工作变得更轻松。
“拥有很多支持者的开放标准”也意味着，该标准不能有任何致命缺陷。与其临时创造一个全新的标准，并冒着重蹈过去错误的风险，Anthropic 团队调整并采用了微软非常成功的语言服务器协议 (LSP)。
“对于期待以最优方案胜出的理想主义者来说，有个令人沮丧的现实：由大型实验室制定的标准，其成功概率天然碾压其他任何来源的标准。即便竞争者坐拥数万 GitHub Stars、有顶级风投数千万美元加持，这种不公平依然存在——如果创业公司会将我锁在其设立的标准中，那我肯定不会采纳；但若标准的支持者体量庞大，甚至不关心是否要刻意锁定用户，我则会欣然接受。”swyx 和 Alessio 在博客中写道。
真正的“开放标准”必须配备规范的文档，而在一些开发者眼里，MCP 的规范堪称典范，甚至令 OpenAI 的函数调用文档相形见绌——后者的技术说明尚未达到真正完备的标准规范要求。正因如此，MCP 不仅超越诸多开源框架，某种程度上甚至优于 OpenAI 的现有方案。
还有一个微妙的观点是——Anthropic 一直明确强调其支持的工具数量比 OpenAI 更多。我们实际上没有关于大规模工具数量的基准测试或消融实验，因此并不清楚不同公司之间的能力差异，但直观上，MCP 可以在一次调用中支持更多的工具，比没有 MCP 的工具数要多。
昙花一现还是未来标准？
昨天，围绕“MCP 是真正的技术突破，还是 AI 炒作浪潮下的又一朵浪花？”这一话题，LangChain CEO Harrison Chase 与 LangChain 创始工程师、LangGraph 负责人 Nuno Campos 展开了讨论。
其中，Harrison 更为看好 MCP，认为如果需要向无法控制的智能体中引入工具，MCP 就是最好的选择。而 Nuno 则认为，MCP 的潜力上限也就到 Zapier 这个程度了，它至少得变得更像 OpenAI 的自定义 GPT，才配得上大家如今对它的关注和期待。
下面是两人的详细讨论过程，这种辩证对话希望可以对读者朋友们有所启发。
Harrison：我认为 MCP 确有真材实料。起初我也对它持怀疑态度，但在看到它的价值之后，我的想法也开始转变。总结来讲：如果需要向无法控制的智能体中引入工具，MCP 就是最好的选择。
这里我举个例子。对于 Claude Desktop、Cursor、Windsurf 之类的产品，身为用户的我们显然无法控制其底层智能体。也就是说，这些智能体只能访问少数内置工具。
但如果我想让它使用默认情况下不具备的工具，该怎么实现？为了做到这一点，就需要存在某种协议，让这些智能体知晓要如何调用其他外部工具。
我相信这一点对于非开发者创建的智能体同样意义重大。从目前的趋势来看，人们希望有更多主题专家能够参与到智能体构建中来，充分发挥自己的技术专长。我觉得这类创作者既没有编辑智能体逻辑的意愿、也缺少这种技术能力——但他们仍然希望智能体可以对接某些工具。这时候 MCP 就可以发挥作用。
Nuno：我觉得你可能低估了智能体在访问外部工具时，所带来的定制化调整工作量。当然，假设说 Windsurf 附带的网络搜索工具太差，用户想用更好的工具来替代，那这事确实成立。但这只能算是种改善，还称不上真正的变革性用例。
所谓变革性用例，就是只需引入一款神奇的工具，就能让 Cursor 实现其创作者都未曾设想过的新功能——但这在实践层面基本还行不通。在我接触过的几乎所有生产智能体当中，都需要根据提供的工具定制系统消息甚至是大量架构组件。
Harrison：确实，这些智能体的可靠性也许还不够高……但至少具备了一定的实用性。工具的描述和指令当然非常重要，但我们也得承认：
MCP 支持工具定义——好的 MCP server 往往拥有超越一般方案的高质量工具描述。
MCP 能够支持提示词——用户可以向其中添加更多指令。
随着底层模型的改进，现成工具在调用智能体方面的表现会越来越好。
我们当然不会指望有人能仅凭 MCP 集成加工具调用智能体就打造出下一款 Cursor，但其中的价值是不容忽视的，比如催生出更多内部或者个人智能体。
Nuno：也有道理，但我们自己的工具调用基准测试表明，当前模型约有一半的概率无法调用正确工具——这还是已经针对工具集量身定制了架构和提示词的测试场景。如果把这样的成功比例照搬到个人智能体这边，那基本就相当于不可用。
没错，模型会变得越来越好，但用户的期望也会水涨船高。这里我想引用贝索斯的说法，“我最喜欢顾客的一点，就是他们永远不会满足。他们的期望永远都是动态的、不断上升的，这是人性的反映。”
所以要想实现种种预期，我觉得唯一的可能性就是掌握完整技术栈——包括用户界面、提示词、架构、工具等。否则的话……就只能碰运气了。
Harrison：模型肯定会变得越来越好，我对这一点很有信心。所以无论目前智能体的成功率如何，未来这项指标只会逐步提升。
我觉得公平的比较不该把用 MCP 构建的智能体直接拿去跟拥有完善工具的智能体正面 PK。MCP 真正的价值，在于如何建立起中长期连接和集成能力。
就比如说 Zapier，它的功能是把电子邮件接入 Google Sheets、Slack 等平台。我可以创建无数个工作流，但并不是每个工作流都能拥有完善的智能体。而使用 MCP，我可以创建自己的智能体版本。那你如何评价 Zapier 这个例子？
Nuno：在 LangChain，这两年我们构建了一套包含 500 种工具的库，但我很少看到这些工具被频繁用于生产。它们都是按相同的“协议”实现，能够与任意模型兼容且灵活互换。那 MCP 到底有什么特别？是它强制要求在本地终端上运行上百万个 server，还是只跟桌面应用程序兼容？在我看来这甚至反而是个缺点。老实讲，我觉得 MCP 的潜力上限也就到 Zapier 这个程度了。
Harrison：我觉得 LangChaing 工具和 MCP 工具之间的最大区别，在于 MCP 并非面向智能体开发者。也就是说，它的主要服务对象，是那些无法直接把工具引入智能体的用户。
具体来讲，比如我要编写一款智能体来完成某项任务，那我使用 MCP 的可能性就是零。但这也不是 MCP 的目标用例。MCP 的意义是把工具引入我们无法控制的智能体，同时也让非开发者能够将工具跟智能体对接起来（LangChain 工具则更多以开发者为中心）。要注意，非开发者的数量要远远多于专业开发者。
至于目前的 MCP 使用形式？没错，我承认还不够好，但它肯定会变得更好。我会设想 MCP 的未来形态，比如只需单击一下就能安装 MCP 应用程序（而不再需要在本地终端运行 server），而且能在 Web 应用程序上开放访问。我敢打赌，这肯定会成为 MCP 接下来的发展方向。
那你觉得 MCP 需要做哪些改变，才能让你对它的作用和意义有所改观？
Nuno：这个嘛，我觉得 MCP 至少得变得更像 OpenAI 的自定义 GPT，才配得上大家如今对它的关注和期待。但自定义 GPT 甚至也没有多受欢迎。从这个角度看，MCP 又比 GPT 多了什么吸引力？
Harrison：其实在我看来，MCP 更像是种 Plugin 插件，当然插件也一直没太成功🙂，我都不确定自己有没有用过 Plugin，所以有些说法可能不够准确。但我觉得：
MCP 生态系统已经远远大于插件生态系统。
大模型会越来越好，在工具使用能力方面也会越来越强。
Nuno：好吧，我不确定你说的是否属实。但我花了 5 秒钟时间，就只搜到了 893 个 MCP server。你好像更多关注提到 MCP 的推文数量，却忽略了人们到底在用它构建出多少东西🙂 但回到你没回答的问题，我觉得如果 MCP 真想在 AI 发展史上留下足迹，那至少需要：
降低复杂性。为什么工具协议还需要涉及提示词和大模型补全？
降低实现门槛。为什么服务于工具的协议还需要双向通信？没错，我认真看了项目团队列出的所有理由，但不好意思，我觉得“需要从服务器接收日志”说服不了我。
要能在服务器上使用。要达成上述目标，无状态协议是关键——我们使用大模型来构建，并不代表我们就能舍弃长久以来积累到的业务扩展经验。历史告诉我们，一旦被搬上服务器就必然引发许多其他意外，比如身份验证等难以用分布式方式解决的问题。
弥补质量损失。如果放任用户把各种工具塞进自己并不了解的智能体，必然会带来质量损失。
Harrison：你说得没错，我可能太过关注 MCP 的“热度”，却忽略了它的实际应用曲线。但帖子里其实也有很多唱衰的声音，也算是对我观点的一种驳斥和补充。
今日好文推荐
来源：InfoQ
