a16z 观点：MCP 如何重塑 AI 工具交互

自 OpenAI 在 2023 年推出函数调用（Function Calling）功能以来，业界一直在思考如何构建一个繁荣的 AI 智能体（Agent）和工具使用生态系统。随着基础模型日益强大，智能体与外部工具、数据和 API 交互的能力却变得越来越碎片化。开发者需要为智能体运行和集成的每一个系统实现特殊的业务逻辑。

显而易见，执行、数据获取和工具调用需要一个标准接口。API 是互联网的第一个伟大统一者，为软件通信创造了共享语言，但 AI 模型缺乏类似物。

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

什么是 MCP？

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

这个想法并不新鲜；MCP 从语言服务器协议（Language Server Protocol, LSP）中汲取了灵感。在 LSP 中，当用户在编辑器中输入时，客户端会查询语言服务器以获取自动完成建议或诊断信息。LSP 的成功在于它解耦了语言特性（如自动补全、错误检查）的实现与编辑器本身，使得一种语言服务器可以服务于多种编辑器，极大地提高了开发效率和生态系统的活力。

MCP 相较于 LSP 的扩展之处在于其以智能体为中心的执行模型。LSP 主要是响应式的（根据用户输入响应来自 IDE 的请求），而 MCP 则设计用于支持自主的 AI 工作流。基于上下文，AI 智能体可以决定使用哪些工具、以何种顺序使用，以及如何将它们链接起来以完成任务。这一点是关键区别：LSP 辅助人类开发者，而 MCP 旨在让 AI 智能体更自主地行动。MCP 还引入了“人在回路”（human-in-the-loop）能力，允许人类提供额外数据和批准执行，增加了可控性。

当前的流行用例

通过配置合适的 MCP 服务器，用户可以将每个 MCP 客户端转变为一个“万能应用”（everything app）。

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

除了 Cursor，目前大多数用例可归纳为以开发者为中心、本地优先（local-first）的工作流，或使用大型语言模型（LLM）客户端创造全新的体验（net-new experiences）。

以开发者为中心的工作流

对于每天沉浸在代码中的开发者来说，一个普遍的感受是：“我不想离开我的 IDE 去做某件事”。MCP 服务器是实现这一梦想的好方法。

开发者现在可以使用 Postgres MCP 服务器执行只读 SQL 命令，使用 Upstash MCP 服务器直接在 IDE 中创建和管理缓存索引，而不必切换到 Supabase 或其他工具。在迭代代码时，开发者还可以利用 Browsertools MCP 让编码智能体访问实时环境以获取反馈和调试。

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

全新的体验

尽管 IDE 如 Cursor 因 MCP 对技术用户的强大吸引力而受到最多关注，但它们并非唯一可用的 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 客户端方面，目前看到的大多数高质量客户端都以编码为中心。这并不奇怪，因为开发者通常是新技术的早期采用者。但随着协议的成熟，预计将看到更多面向业务的客户端。

看到的大多数 MCP 服务器都是本地优先且专注于单用户场景。这是 MCP 目前主要支持基于服务器发送事件（SSE）和命令的连接的体现。然而，随着生态系统使远程 MCP 成为一等公民，并且 MCP 采用可流式 HTTP 传输（Streamable HTTP transport），预计 MCP 服务器的采用会增加。

同时，一股新的 MCP 市场（marketplace）和服务器托管解决方案浪潮正在兴起，以实现 MCP 服务器的发现。像 Mintlify 的 mcpt、Smithery 和 OpenTools 这样的市场，使得开发者更容易发现、共享和贡献新的 MCP 服务器——很像 npm 如何改变了 JavaScript 的包管理，或者 RapidAPI 如何扩展了 API 发现。这一层对于标准化高质量 MCP 服务器的访问至关重要，允许 AI 智能体按需动态选择和集成工具。

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

未来的可能性与挑战

然而，我们仅处于智能体原生架构演变的早期阶段。尽管今天对 MCP 充满热情，但在使用 MCP 构建和发布产品时，仍有许多未解决的问题。这些挑战的解决程度将直接影响 MCP 能否成为真正的行业标准。

协议下一阶段需要解决的一些关键问题包括：

托管和多租户（Multi-tenancy）

MCP 支持 AI 智能体与其工具之间的一对多关系，但多租户架构（例如 SaaS 产品）需要支持许多用户同时访问共享的 MCP 服务器。默认支持远程服务器可能是使 MCP 服务器更易于访问的近期解决方案，但许多企业也希望托管自己的 MCP 服务器，并分离数据和控制平面。

支持大规模 MCP 服务器部署和维护的简化工具链是解锁更广泛采用的下一步。

认证（Authentication）

MCP 目前没有定义客户端如何向服务器进行身份验证的标准机制，也没有提供 MCP 服务器在与第三方 API 交互时应如何安全管理和委派身份验证的框架。身份验证目前留给各个实现和部署场景自行处理。实践中，MCP 迄今为止的采用似乎集中在本地集成上，这些场景下并不总是需要显式身份验证。

一个更好的认证范式可能是远程 MCP 采用的一大突破。从开发者的角度来看，统一的方法应涵盖：

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

缺乏标准化的认证是目前阻碍 MCP 在更广泛、更安全的 SaaS 环境中应用的主要障碍之一。

授权（Authorization）

即使工具通过了身份验证，谁应该被允许使用它？他们的权限应该有多细粒度？MCP 缺乏内置的权限模型，因此访问控制是在会话级别进行的——这意味着一个工具要么可访问，要么完全受限。虽然未来的授权机制可能会塑造更细粒度的控制，但当前的方法依赖于基于 OAuth 2.1 的授权流程，一旦认证通过就授予会话范围的访问权限。随着更多智能体和工具的引入，这会增加复杂性——每个智能体通常需要自己的会话和独特的授权凭证，导致基于会话的访问管理网络日益庞大。

精细化的授权对于企业级应用和需要严格权限控制的场景至关重要。

网关（Gateway）

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

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

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

不过，根据 Anthropic 上个月在 AI 工程师大会上的演讲，似乎一个 MCP 服务器注册表和发现协议即将到来。这可能为 MCP 服务器的采用解锁下一阶段。标准化的发现机制对于实现智能体自主选择工具的愿景至关重要。

执行环境

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

标准客户端体验

开发者社区中一个常见的问题是如何在构建 MCP 客户端时考虑工具选择：是每个人都需要为工具实现自己的检索增强生成（RAG）系统，还是有一个层等待被标准化？

除了工具选择，对于调用工具也没有统一的 UI/UX 模式（从斜杠命令到纯自然语言，各种方式都有）。一个标准的客户端层，负责工具发现、排序和执行，有助于创建更可预测的开发者和用户体验。

调试

MCP 服务器的开发者经常发现，让同一个 MCP 服务器在不同客户端上轻松工作很困难。通常，每个 MCP 客户端都有自己的怪癖，而客户端侧的追踪要么缺失要么难以找到，使得调试 MCP 服务器极其困难。随着世界开始构建更多远程优先的 MCP 服务器，需要一套新的工具来简化本地和远程环境中的开发体验。

AI 工具化的深远影响

MCP 的开发体验让人联想到 2010 年代的 API 开发。范式新颖且令人兴奋，但工具链尚处早期。如果快进几年，MCP 成为 AI 驱动工作流的事实标准，会发生什么？一些预测：

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

MCP 已经在重塑 AI 智能体生态系统，但下一波进展将取决于我们如何应对这些基础性挑战。如果处理得当，MCP 可能成为 AI 与工具交互的默认接口，解锁新一代自主、多模态、深度集成的 AI 体验。

如果被广泛采用，MCP 可能代表着工具构建、消费和商业化方式的转变。市场将如何发展令人期待。今年将是关键的一年：我们会看到统一的 MCP 市场崛起吗？AI 智能体的认证会变得无缝吗？多步骤执行能否被正式纳入协议？这些问题的答案将决定 MCP 的最终形态和影响力。