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

MCP与AI工具未来的深度探析

　　 自OpenAI在2023年发布函数调用功能以来，我一直在思考如何才能打造一个完整的代理和工具使用生态系统。随着基础模型变得越来越智能，代理与外部工具、数据和API交互的能力变得日益分散：开发者需要为代理在每个运行系统和集成环境中实现特定的业务逻辑。

　　显然，我们需要一个用于执行、数据获取和工具调用的标准接口。API是互联网的第一个重要统一器——为软件通信创造了共享语言——但AI模型缺乏相应的标准。

　　模型上下文协议（Model Context Protocol，简称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服务器是实现这一梦想的绝佳方式。

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

　　除了与开发工具交互的工作流之外，MCP服务器解锁的一个新用途是通过爬取网页或基于文档自动生成MCP服务器，为编码代理添加高度准确的上下文。开发者可以直接从现有文档或API生成MCP服务器，而不必手动连接集成，使工具对AI代理立即可用。这意味着花更少的时间在样板代码上，花更多的时间实际使用工具——无论是引入实时上下文、执行命令，还是扩展AI助手的功能。

全新体验

　　尽管由于MCP对技术用户的强烈吸引力，IDE如Cursor已经受到最多关注，但它们并不是唯一可用的MCP客户端。对于非技术用户，Claude Desktop是一个极佳的入口，使MCP驱动的工具对普通用户更加易用。不久后，我们可能会看到专为业务为中心的任务而生的专业MCP客户端出现，例如客户支持、营销文案、设计和图像编辑，因为这些领域与AI在模式识别和创意任务方面的优势高度契合。

　　MCP客户端的设计及其支持的特定交互对塑造其功能至关重要。例如，聊天应用不太可能包含矢量渲染画布，就像设计工具不太可能提供在远程机器上执行代码的功能一样。最终，MCP客户端体验定义了整体MCP用户体验——而在MCP客户端体验方面，我们还有很多潜力有待开发。

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

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

　　虽然我们主要考虑服务器和客户端，但随着协议的演进，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驱动工作流的事实标准，会发生什么？一些预测：

　　1. 以开发者为先的公司的竞争优势将从提供最佳API设计演变为同时提供最佳代理工具集合。如果MCP能够自主发现工具，API和SDK提供者需要确保他们的工具在搜索中易于发现，并且有足够的差异化，以便代理为特定任务选择它们。这可能比人类开发者寻找的内容更加细化和具体。

　　2. 如果每个应用都成为MCP客户端，每个API都成为MCP服务器，可能会出现新的定价模型：代理可能会基于速度、成本和相关性的组合来更动态地选择工具。这可能导致更加市场驱动的工具采用过程，选择性能最佳和最模块化的工具，而非最广泛采用的工具。

　　3. 文档将成为MCP基础设施的关键部分，因为公司需要设计具有清晰、机器可读格式（例如，llms.txt）的工具和API，并使MCP服务器成为基于现有文档的事实上的产物。

　　4. 仅有API不再足够，但可以是很好的起点。开发者将发现API到工具的映射很少是一对一的。工具是一个更高级的抽象，在任务执行时对代理最有意义——代理可能会选择draft_email_and_send()函数而不是简单调用send_email()，该函数包括多个API调用以最小化延迟。MCP服务器设计将以场景和用例为中心，而不是以API为中心。

　　5. 如果每个软件默认都成为MCP客户端，将出现一种新的托管模式，因为工作负载特性将与传统网站托管不同。每个客户端都将是多步骤的，需要可恢复性、重试和长时间运行的任务管理等执行保证。托管提供商还需要在不同MCP服务器之间进行实时负载均衡，以优化成本、延迟和性能，允许AI代理在任何给定时刻选择最有效的工具。

　　MCP已经在重塑AI代理生态系统，但下一波进展将由我们如何解决基础挑战来定义。如果做得好，MCP可能成为AI与工具交互的默认接口，并解锁新一代自主、多模态和深度集成的AI体验。

　　如果被广泛采用，MCP可以代表工具构建、消费和变现方式的转变。我们很期待看到市场将它们带向何方。今年将是关键性的一年：我们会看到统一的MCP市场崛起吗？AI代理的认证会变得无缝吗？多步执行能否被正式纳入协议？

　　如果您在这个领域构建或对这个领域的发展有想法，请联系yli@a16z.com。是时候构建了！