a16z深入详解 MCP 和 AI 工具的未来

自OpenAI于2023年发布函数调用以来，业界一直在思考如何解锁代理与工具使用的生态系统。随着基础模型变得越来越智能，代理与外部工具、数据和API交互的能力却日益分散：开发人员需要为代理运行和集成的每一个系统，都实现带有特殊业务逻辑的代理。显然，业界需要一个用于执行、数据获取和工具调用的标准接口。API是互联网第一个伟大的统一者——它为软件通信创造了一种共享语言——但人工智能模型却缺乏与之对等的东西。

模型上下文协议（MCP）于2024年11月推出，作为一种潜在的解决方案，在开发者和AI社区中获得了极大关注。在本文中，我们将探讨什么是MCP、它如何改变AI与工具交互的方式、开发者已经用它构建了什么，以及仍需解决的挑战。

什么是MCP

MCP是一种开放协议，支持系统以跨集成通用的方式向AI模型提供上下文。协议定义了AI模型如何调用外部工具、获取数据以及与服务交互。下面是一个具体示例，展示了Resend MCP服务器如何与多个MCP客户端协同工作。

MCP的灵感来自LSP（语言服务器协议）。在LSP中，当用户在编辑器中输入内容时，客户端会查询语言服务器，以获取自动补全建议或诊断信息。

MCP超越LSP之处在于其以代理为中心的执行模型：LSP主要是被动的（根据用户输入响应来自IDE的请求），而MCP旨在支持自主AI工作流。根据上下文，AI代理可以决定使用哪些工具、以什么顺序使用，以及如何将它们链接在一起来完成任务。MCP还引入了人机交互功能，以便人类提供额外数据并批准执行。

热门流行用例

通过正确的MCP服务器，用户可以把每个MCP客户端变成”万能应用程序”。

以Cursor为例：虽然Cursor是一个代码编辑器，但它同时也是一个实现良好的MCP客户端。最终用户可以使用Slack MCP服务器把它变成Slack客户端，使用Resend MCP服务器把它变成电子邮件发送器，使用Replicate MCP服务器把它变成图像生成器。利用MCP更强大的方式，是在一个客户端上安装多个服务器以解锁新流程：用户可以安装服务器，从Cursor生成前端UI，还可以要求代理使用图像生成MCP服务器为网站生成英雄图像。

除了Cursor之外，当今大多数用例可以归纳为以开发为中心、本地优先的工作流，或是使用LLM客户端带来的全新体验。

以开发为中心的工作流程

对于每天生活在代码中的开发人员来说，一个普遍的感受是”我不想离开IDE去做x”。MCP服务器正是实现这一愿望的绝佳方式。

开发人员现在无需切换到Supabase来检查数据库状态，而是可以使用Postgres MCP服务器执行只读SQL命令，使用Upstash MCP服务器直接从IDE创建和管理缓存索引。在迭代代码时，开发人员还可以利用Browsertools MCP让编码代理访问实时环境，以获取反馈和调试信息。

这是Cursor代理如何使用Browsertools访问控制台日志和其他实时数据，从而更高效地进行调试的示例。

除了与开发人员工具交互的工作流之外，MCP服务器还解锁了一类新用途：通过抓取网页或根据文档自动生成MCP服务器，为编码代理添加高度准确的上下文。开发人员无需手动连接集成，就可以直接从现有文档或API启动MCP服务器，让AI代理立即访问工具。这意味着花在样板代码上的时间更少，真正使用工具的时间更多——无论是提取实时上下文、执行命令，还是动态扩展AI助手的功能。

全新体验

尽管像Cursor这样的IDE因MCP对技术用户的强烈吸引力而受到最多关注，但它们并不是唯一可用的MCP客户端。对于非技术用户来说，Claude Desktop是一个极好的切入点，它让MCP驱动的工具对普通用户而言更易获得、更易使用。很快，我们可能会看到专门的MCP客户端出现，用于处理以业务为中心的任务，例如客户支持、营销文案、设计和图像编辑，因为这些领域与AI在模式识别和创意任务方面的优势密切相关。

MCP客户端的设计及其所支持的特定交互，在塑造其功能方面起着至关重要的作用。例如，聊天应用程序不太可能包含矢量渲染画布，正如设计工具不太可能提供在远程机器上执行代码的功能一样。最终，MCP客户端体验决定了整体MCP用户体验——在MCP客户端体验方面，我们还有更多东西有待解锁。

其中一个例子是Highlight如何实现@ 命令，来调用其客户端上的任何MCP服务器。其结果是一种新的UX模式：MCP客户端可以把生成的内容传输到任意下游应用中。

Highlight实现Notion MCP（插件）的一个例子。

另一个例子是Blender MCP服务器用例：如今，几乎不了解Blender的业余用户也可以用自然语言描述他们想要构建的模型。随着社区为Unity和Unreal引擎等其他工具实现服务器，我们正在实时见证文本到3D工作流的展开。

将Claude Desktop与Blender MCP服务器结合使用的示例。

尽管我们主要考虑的是服务器和客户端，但随着协议的发展，MCP生态系统正在逐渐成形。这份市场地图涵盖了当今最活跃的领域，尽管仍有许多空白。我们知道MCP仍处于早期阶段，我们很高兴随着市场的发展和成熟，把更多参与者添加到这张地图中。

在MCP客户端方面，我们目前看到的大多数高质量客户端都是以代码为中心的。这并不奇怪，因为开发人员通常是新技术的早期采用者，但随着协议的成熟，我们期望看到更多以业务为中心的客户端。

我们看到的大多数MCP服务器都是本地优先的，专注于单人使用。这是MCP目前仅支持基于SSE和命令连接的表现。但是，随着生态系统把远程MCP提升为一等公民，并且MCP采用可流式HTTP传输，我们预计会看到更多MCP服务器被采用。

同时，新一波MCP市场和服务器托管解决方案正在出现，使MCP服务器的发现成为可能。Mintlify的mcpt、Smithery和OpenTools等市场让开发人员更容易发现、共享和贡献新的MCP服务器——就像npm改变了JavaScript的包管理，或RapidAPI扩展了API发现一样。这一层对于标准化对高质量MCP服务器的访问至关重要，让AI代理能够根据需要动态选择和集成工具。

随着MCP采用率不断提高，基础设施和工具将在让生态系统更具可扩展性、可靠性和可访问性方面发挥关键作用。Mintlify、Stainless和Speakeasy等服务器生成工具正在减少创建MCP兼容服务的摩擦，而Cloudflare和Smithery等托管解决方案正在解决部署和扩展挑战。与此同时，Toolbase等连接管理平台开始简化本地优先的MCP密钥管理和代理。

未来的可能性

我们仅处于代理原生架构演进的早期阶段。尽管如今MCP令人兴奋不已，但在使用MCP进行构建和交付时，仍存在许多未解决的问题。

协议下一次迭代中需要解锁的一些内容包括：

托管和多租户

MCP支持AI代理与其工具之间的一对多关系，但多租户架构（例如SaaS产品）需要支持多个用户同时访问共享的MCP服务器。默认拥有远程服务器，可能是让MCP服务器更易访问的短期解决方案，但许多企业也希望托管自己的MCP服务器，以及独立的数据和控制平面。

用于支持大规模MCP服务器部署和维护的简化工具链，是实现更广泛采用的下一块拼图。

验证

MCP目前尚未定义客户端与服务器进行身份验证的标准机制，也没有提供MCP服务器在与第三方API交互时应如何安全地管理和委托身份验证的框架。身份验证目前由各个实现和部署方案自行决定。实际上，到目前为止，MCP的采用似乎集中在本地集成上，而这些集成并不总是需要显式身份验证。

更好的身份验证范式，可能是远程MCP被广泛采用的一大优势。从开发人员的角度来看，统一方法应涵盖：

• 客户端身份验证：用于客户端与服务器交互的标准方法，例如OAuth或API令牌
• 工具身份验证：用于与第三方API进行身份验证的辅助函数或包装器
• 多用户身份验证：针对企业部署的租户感知身份验证

授权

即使工具经过了身份验证，谁应该被允许使用它？他们的权限应该有多细？MCP缺乏内置的权限模型，因此访问控制处于会话级别——意味着工具要么可访问，要么完全受限。虽然未来的授权机制可以形成更细粒度的控制，但当前方法依赖于基于OAuth 2.1的授权流程，该流程在经过身份验证后授予会话范围的访问权限。随着更多代理和工具的引入，这会带来额外的复杂性——每个代理通常都需要带有唯一授权凭据的自己的会话，从而导致基于会话的访问管理网络不断膨胀。

网关

随着MCP采用规模不断扩大，网关可以充当身份验证、授权、流量管理和工具选择的集中层。与API网关类似，它将强制执行访问控制、把请求路由到正确的MCP服务器、处理负载平衡并缓存响应以提高效率。这对于多租户环境尤其重要，因为不同的用户和代理需要不同的权限。标准化网关将简化客户端与服务器之间的交互、提高安全性并提供更好的可观察性，让MCP部署更具可扩展性和可管理性。

MCP服务器的可发现性和可用性

目前，查找和设置MCP服务器是一个手动过程，需要开发人员定位端点或脚本、配置身份验证，并确保服务器和客户端之间的兼容性。集成新服务器非常耗时，而且AI代理无法动态发现或适应可用的服务器。

不过，根据Anthropic上个月在AI工程师会议上的演讲，MCP服务器注册和发现协议似乎即将问世。这可能会开启MCP服务器应用的下一阶段。

执行环境

大多数AI工作流都需要按顺序调用多个工具——但MCP缺乏内置的工作流概念来管理这些步骤。要求每个客户端都实现可恢复性和可重试性并不理想。尽管今天我们看到开发人员正在探索Inngest等解决方案来实现这一点，但把有状态执行提升为一等概念，将为大多数开发人员理清执行模型。

标准客户端体验

我们从开发者社区听到的一个常见问题是：在构建MCP客户端时如何考虑工具选择？每个人都需要为工具实现自己的RAG，还是有一个等待标准化的层？

除了工具选择之外，调用工具也没有统一的UI/UX模式（我们已经看到从斜线命令到纯自然语言的各种模式）。用于工具发现、排名和执行的标准客户端层，可以帮助创造更可预测的开发人员和用户体验。

调试

MCP服务器的开发人员经常发现，很难让同一个MCP服务器轻松地跨客户端运行。通常，每个MCP客户端都有自己的怪癖，客户端跟踪要么缺失，要么很难找到，这使得调试MCP服务器成为一项极其困难的任务。随着世界开始构建更多远程优先的MCP服务器，需要一套新的工具来简化本地和远程环境中的开发体验。

AI工具的影响

MCP的开发体验让我想起了2010年代的API开发。这种模式新颖而令人兴奋，但工具链还处于早期阶段。如果我们快进到几年后，假设MCP成为AI驱动工作流的事实标准，会发生什么？以下是一些预测：

• 开发优先型公司的竞争优势，将从提供最佳API设计，发展到为代理提供最佳工具集合。如果MCP能够自主发现工具，那么API和SDK提供商将需要确保他们的工具易于通过搜索找到，并且具有足够的差异性，以便代理在特定任务中选择它们。这可能比人类开发人员所寻找的更加细致和具体。
• 如果每个应用程序都成为MCP客户端，每个API都成为MCP服务器，那么可能会出现一种新的定价模式：代理可以根据速度、成本和相关性等因素，更加动态地选择工具。这可能会导致一个更加以市场为导向的工具采用过程——选择性能最佳、模块化程度最高的工具，而不是采用最广泛的工具。
• 文档将成为MCP基础设施的关键部分，因为公司需要设计具有清晰、机器可读格式（例如llms.txt）的工具和API，并让MCP服务器成为基于现有文档的事实工件。
• 仅使用API已远远不够，但可以成为很好的起点。开发人员会发现，从API到工具的映射很少是1:1的。工具是一种更高级的抽象，在执行任务时对代理最有意义——代理可能会选择包含多个API调用的draft_email_and_send()函数，而不是简单地调用send_email()，以最大限度地减少延迟。MCP服务器设计将以场景和用例为中心，而不是以API为中心。
• 如果每个软件都默认成为MCP客户端，那么将会出现一种新的托管模式，因为工作负载特征与传统网站托管不同。每个客户端本质上都是多步骤的，并且需要执行保证，例如可恢复性、重试和长时间运行的任务管理。托管提供商还需要在不同的MCP服务器之间进行实时负载平衡，以优化成本、延迟和性能，让AI代理能够在任何给定时刻选择最有效的工具。

未来

MCP正在重塑AI代理生态系统，下一波进步将取决于我们如何应对这些基础挑战。如果做得好，MCP可以成为AI与工具交互的默认界面，开启新一代自主、多模式和深度集成的AI体验。

如果被广泛采用，MCP可以代表工具构建、使用和货币化方式的一次转变。我们很高兴看到市场将把它们带向何方。今年将是关键的一年：我们会看到统一的MCP市场崛起吗？身份验证对于AI代理来说会变得无缝吗？多步骤执行能否正式纳入协议？

原文链接：https://a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/