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/