A16z：深入理解MCP与AI工具生态的未来

架构师（JiaGouX）

我们都是架构师！
架构未来，你来不来？

本文作者是Yoko Li，Andreessen Horowitz 合伙人，专注于企业及基础设施领域。

A16z：深入理解MCP与AI工具生态的未来

自从 OpenAI 在 2023 年发布了 function calling 功能后，我一直在思考如何才能真正解锁一个以代理（agent）与工具为中心的生态系统。随着基础模型的日益智能化，AI 代理对外部工具、数据和 API 的交互能力越来越分散：开发者不得不针对每个系统定制特殊的业务逻辑，才能让代理完成在不同系统间的操作与整合。

显而易见，我们需要一个标准化的接口，用于执行指令、获取数据以及调用工具。在互联网早期，API 曾是软件之间通信的统一语言；但在 AI 领域，我们还缺少一个对应的标准。

自 2024 年 11 月发布以来，Model Context Protocol（MCP）迅速在开发者和 AI 社区中获得了广泛关注，成为解决上述问题的潜在方案。本文将探讨什么是 MCP，为什么它会改变 AI 与工具的交互方式，如今开发者如何使用它，以及仍亟待解决的挑战。

让我们开始吧。

什么是 MCP？

MCP 是一个开放协议，允许各种系统以一种可泛化的方式向 AI 模型提供上下文。它定义了 AI 模型如何调用外部工具、获取数据以及与服务进行交互。例如，下面展示了 Resend MCP 服务器与多个 MCP 客户端的协同工作方式：

A16z：深入理解MCP与AI工具生态的未来

这种思路并不新颖；MCP 的灵感源于 LSP（Language Server Protocol）。在 LSP 中，当用户在编辑器中输入时，客户端会向语言服务器请求自动补全或诊断信息。

A16z：深入理解MCP与AI工具生态的未来

MCP 相较于 LSP 的延伸在于：它采用了“以代理为中心”的执行模型。LSP 主要是被动的（根据用户输入和 IDE 的请求进行响应），而 MCP 支持自主的 AI 工作流。基于给定的上下文，AI 代理可以自由决定使用哪些工具、以怎样的顺序调用它们，以及如何将这些调用串联起来完成任务。MCP 还引入了“人类介入”环节，允许人在必要时提供额外数据并审批执行流程。

A16z：深入理解MCP与AI工具生态的未来

当下的主流应用场景

只要拥有适配的 MCP 服务器，用户就可以将每一个 MCP 客户端变成一个“全能应用（everything app）”。

以 Cursor 为例：虽然 Cursor 是一个代码编辑器，但它同时也是一个实现完善的 MCP 客户端。通过安装 Slack MCP 服务器，它可以变成一个 Slack 客户端；通过安装 Resend MCP 服务器，它可以发送邮件；通过安装 Replicate MCP 服务器，它可以生成图像。更强大的是在一个客户端上安装多个 MCP 服务器来解锁组合式任务：用户可以安装一个服务器来生成前端界面，同时让代理调用图像生成的 MCP 服务器为网站生成一个英雄图。

除了 Cursor，当下的大多数用例大致可分为两类：面向开发者的本地化工作流和利用 LLM 客户端构建的新型体验。

1. 面向开发者的工作流

对每天都沉浸在写代码的开发者来说，“我不想离开我的 IDE 去做 X 事情”是一种常见的心声。MCP 服务器为这种需求提供了强力支持。

例如，开发者无需再切换到 Supabase 界面检查数据库状态，可以直接通过 Postgres MCP 服务器在 IDE 中执行只读 SQL 命令；也可以利用 Upstash MCP 服务器创建和管理缓存索引。编写代码时，开发者还能结合使用 Browsertools MCP，为 AI 代理提供实时环境访问权限，以获取控制台日志和调试信息。

A16z：深入理解MCP与AI工具生态的未来

Cursor 代理如何使用 Browsertools 访问控制台日志和其他实时数据并更高效调试的示例。

除此之外，MCP 服务器还可以为开发者提供高度准确的代码上下文。例如，通过抓取某个网页，或根据文档自动生成相应的 MCP 服务器，就可以让 AI 代理即时获得所需的外部工具。这意味着开发者可以减少写样板代码的时间，把精力集中在实际使用这些工具上——无论是获取实时上下文、执行命令，还是为 AI 助手随时扩充新能力。

2. 新型应用体验

不仅 IDE（如 Cursor）可以成为 MCP 客户端，虽然它们在技术人群中关注度更高，但面向大众用户的客户端同样也在崛起。比如，对于非技术用户而言，Claude Desktop 就是一个友好易用的入口，让更多人能轻松使用基于 MCP 的工具。接下来，我们也很可能看到专门针对客户支持、营销文案、设计和图像编辑等业务场景的 MCP 客户端出现——这些领域与 AI 擅长的模式识别和创意写作天然契合。

MCP 客户端的设计以及支持的交互模式，在很大程度上决定了它的功能边界。比如，一个聊天应用通常不会提供矢量绘图画布，而设计工具也不太可能让你远程执行代码。因此，MCP 客户端的体验决定了最终用户与 MCP 交互的体验，而在这个层面上，我们还有大量创新空间未被探索。

一个有趣的例子是 Highlight 实现的“@命令”，用来调用其客户端所安装的任何 MCP 服务器。这样一来，MCP 客户端就能将生成的内容传输到任意下游应用中。

A16z：深入理解MCP与AI工具生态的未来

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

另一个例子是使用 Blender MCP 服务器：即使是对 Blender 基本操作都不熟悉的新手，也能用自然语言描述自己想要创建的 3D 模型。我们正目睹 text-to-3D 工作流的兴起，社区也在为 Unity、Unreal Engine 等工具实现类似的 MCP 服务器。

A16z：深入理解MCP与AI工具生态的未来

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

虽然我们常提到“服务器”和“客户端”，但随着协议的演进，MCP 生态系统正在逐步成形。下图展示了目前最活跃的领域（当然仍有许多空白），随着 MCP 逐渐成熟，我们期待看到更多新玩家的加入。（我们也将在下一章节探讨 MCP 潜在的更多可能性。）

A16z：深入理解MCP与AI工具生态的未来

市场地图示意图

就 MCP 客户端而言，如今大部分高质量的客户端依旧以代码开发为核心，这不足为奇——开发者往往是新技术的早期采用者。但随着协议完善，也必然会出现更多聚焦商业场景的客户端。

大多数现有的 MCP 服务器都偏向“本地优先”，并且大多由单个开发者或团队制作。这主要是因为当前 MCP 仅支持基于 SSE 和命令式的连接方式。然而，我们相信，随着远程 MCP 成为第一公民，以及 MCP 逐渐采用可流式传输的 HTTP 传输方式，整个生态的服务器也会越来越丰富。

与此同时，一批新的 MCP 市场和服务器托管解决方案正在崛起，推动 MCP 服务器的发现与分发。像 Mintlify 的 mcpt、Smithery、OpenTools 之类的市场平台正在为开发者提供更便捷的方式去发现、分享并贡献新的 MCP 服务器——类似当年 npm 之于 JavaScript 包管理或 RapidAPI 之于 API 发现。这层市场化对于标准化高质量 MCP 服务器的获取至关重要，也将让 AI 代理能动态选择并集成所需工具。

随着 MCP 的进一步普及，基础设施与开发工具链对可扩展性、可靠性与可访问性将至关重要。Mintlify、Stainless、Speakeasy 等服务器生成工具正在简化创建 MCP 兼容服务的过程；而 Cloudflare 和 Smithery 等托管服务则尝试解决部署与扩容问题。同时，像 Toolbase 这样的连接管理平台也开始着手简化本地 MCP 的密钥管理与代理等流程。

未来的可能性

需要指出的是，我们仍处于代理原生（agent-native）架构发展的早期阶段。虽然 MCP 如今广受追捧，但使用 MCP 开发并上线仍面临众多未解难题。

以下是 MCP 协议下一阶段可能需要解锁的一些关键问题：

1. 托管与多租户（multi-tenancy）

MCP 支持“一个 AI 代理对多工具”的场景，但多租户架构（如 SaaS 产品）却要求“多个用户对同一个 MCP 服务器”的高并发支持。默认采用远程服务器也许是短期内让 MCP 服务器触达更广用户的一种办法，但很多企业依然希望在自己的环境中部署 MCP 服务器，并将数据平面和控制平面独立分开。

要大规模地部署并维护 MCP 服务器，需要一个成熟的工具链，这也是广泛普及的下一个关键环节。

2. 认证（Authentication）

MCP 当前并未定义标准的身份认证机制，也没有规范如何在与第三方 API 交互时安全管理和委派授权。现阶段，身份认证通常由各自的实现和部署场景自行解决。实际上，目前 MCP 在本地集成场景中使用较多——而这类场景往往对身份认证的需求不算强。

若要真正普及远程 MCP，就需要一个更完善的认证范式。对开发者而言，一个统一的认证方法应包含：

客户端认证：使用 OAuth 或 API Token 等标准方式进行客户端与服务器交互
工具认证：提供用于第三方 API 认证的辅助函数或包装器
多用户认证：面向企业部署的租户级身份认证

3. 授权（Authorization）

即便工具完成了认证，谁有权使用它？使用权限的粒度有多细？MCP 尚未内置权限模型，目前的访问控制几乎都在会话层——工具要么可访问，要么完全被禁止。虽然将来可能会有更细粒度的权限控制机制，但目前常见的做法是基于 OAuth 2.1 的授权流程，一旦通过认证，整个会话就拥有该工具的访问权。

随着代理数量和工具数量的持续增加，这种会话级别的访问管理变得愈加复杂。目前，每个代理通常需要独立的会话和授权凭证，形成一张不断扩大的访问管理网络。

4. Gateway（网关）

当 MCP 应用规模扩大后，可能需要一个网关层来集中处理身份认证、授权、流量管理以及工具选择。类似传统的 API 网关，这个网关可以执行访问控制，将请求路由到正确的 MCP 服务器，并进行负载均衡和缓存。对于多租户环境来说，这点尤为重要，不同用户和代理往往需要不同的权限。一个标准化的网关能够简化客户端与服务器的交互，增强安全性，并且提供更好的可观测性，令 MCP 部署更容易扩展和管理。

5. MCP 服务器的可发现性（discoverability）与可用性

目前，要找到并设置 MCP 服务器依然比较繁琐：开发者需要定位相关端点或脚本，配置认证，并确保服务器与客户端兼容。集成新服务器费时费力，AI 代理无法动态发现或适配可用的服务器。

但从上个月 Anthropic 在 AI 工程师大会上的演讲来看，他们正在筹备 MCP 服务器注册表和发现协议。若能顺利推出，这极可能成为 MCP 大规模普及的下一个关键节点。

6. 执行环境

大部分 AI 工作流需要依次调用多个工具，但 MCP 并未内置“工作流”概念来管理这些调用步骤。若要求每个客户端都自己实现可恢复（resumability）和可重试（retryability）的机制，难免增加复杂度。虽然目前有开发者在尝试用 Inngest 等第三方方案，但如果能将有状态执行升级为 MCP 协议的核心概念，将大大简化大多数开发者的执行模型。

7. 标准化的客户端体验

来自开发者社区的一个常见问题是：在构建 MCP 客户端时，如何思考“工具选择”这件事？每个人都需要自己实现一套基于检索增强生成（RAG）的工具选型逻辑吗？还是说这块逻辑有机会被标准化？

不仅如此，业界也缺乏统一的 UI/UX 模式去调用工具（有些是斜线命令，有些是纯自然语言触发）。若能在客户端层面实现统一的工具发现、排序与执行能力，开发者与用户都能获得更一致的体验。

8. 调试（Debugging）

很多 MCP 服务器开发者都发现：要让同一个 MCP 服务器在不同客户端上正常工作，其实并不容易。大多数 MCP 客户端都有各自的实现细节，客户端侧的调试信息往往缺失或难以获取，导致调试过程异常艰难。随着更多 MCP 服务器开始“远程化”，我们需要一整套新的工具来简化本地与远程环境下的开发体验。

AI 工具生态的影响

MCP 的开发者体验让我想起 2010 年代的 API 开发。概念虽新且令人兴奋，但周边工具链依然处于初期。如果展望数年之后，假设 MCP 真的成为 AI 驱动工作流的事实标准，会发生什么呢？以下是一些可能的趋势预测：

开发者导向型公司的竞争优势将从“最好的 API 设计”演变到“最好的工具集合”。如果 MCP 能让代理自动发现工具，那么 API 或 SDK 提供商需要保证他们的工具能被轻松检索，并且在同类任务中表现出色，足以让代理选用。而且这将比人类开发者挑选更精细和即时。
如果每个应用都成为 MCP 客户端，而每个 API 都成为 MCP 服务器，我们可能会看到全新的定价模式：代理会基于速度、成本和相关性动态选择工具。这种更加市场化的采纳方式会让最“好用”的工具快速脱颖而出，打破只因用户基数或历史惯性而占主导的局面。
文档将成为 MCP 基础设施中的关键一环。公司需要提供机器可读（例如 llms.txt）的工具与 API 规范，并根据已有文档默认输出 MCP 服务器，这样 AI 才能迅速理解并使用这些功能。
API 不再是终点，而只是起点。开发者会逐渐意识到，API 和工具的映射并非一一对应。工具是一种更高层的抽象，它根据任务场景做出最优调用组合 —— 例如，代理调用 draft_email_and_send() 可能包含多个底层 API 调用，但却能大幅降低延迟。MCP 服务器的设计会更多地聚焦于具体场景和用例，而不是单纯的 API 封装。
如果每个软件默认都是 MCP 客户端，那么托管方式也会发生演变。工作负载的特征与传统网站有极大差异。每个客户端都可能需要多步执行，还需支持可恢复、可重试和长时间任务管理。托管商也需要对不同 MCP 服务器进行实时负载均衡，以兼顾成本、延迟和性能，从而让 AI 代理能动态选择最优工具。