a16z 合伙人深入剖析 MCP：AI 工具的未来之路

自从 2023 年 OpenAI 推出函数调用（function-call）功能以来，我们便开始思考如何构建一个真正繁荣的 AI Agent 和工具生态系统。然而，随着 AI 基础模型日益强大，一个意想不到的挑战浮出水面：每一种模型都需要有一套函数调用接口的规范，这导致了AI 与外部世界的连接变得前所未有的割裂和碎片化。

我们迫切需要一个统一的“通用语”，打破 AI 与工具之间的藩篱，实现无缝衔接。正如互联网早期 API 的出现，为软件之间的互联互通奠定了基石，AI 世界也亟需一个类似的“统一协议”。

模型上下文协议 (Model Context Protocol, MCP)，正是在这样的背景下应运而生。自 2024 年 11 月发布以来，MCP 迅速吸引了开发者和 AI 社区的目光，被视为解决这一痛点的关键方案。

这篇 a16z 合伙人 Yoko Li 撰写本文深入解读 MCP 的本质，剖析它如何革新 AI 与工具的交互模式，揭示开发者们基于 MCP 正在构建的创新应用，并探讨 MCP 生态发展道路上仍需破解的挑战。让我们一起来学习。

MCP：AI 工具生态的“通用语言”

MCP 的核心理念，是为 AI 模型与外部系统构建一套通用的“对话”规则。 它定义了一套开放协议，使得各种系统能够以标准化的方式向 AI 模型提供上下文信息，并允许 AI 模型以统一的方式调用外部工具、获取数据、以及与各类服务进行交互。 这就像为 AI 智能体配备了一本“通用词典”和“语法书”，使其能够理解和使用各种工具，而无需针对每个工具学习特定的“语言”。

以下图 Resend MCP 服务器与多个 MCP 客户端的协同工作模式为例，我们可以更直观地理解 MCP 的运作方式：

MCP 的设计灵感来源于 语言服务器协议 (LSP)。 LSP 在代码编辑器中扮演着 “智能助手” 的角色，当你输入代码时，LSP 服务器会实时分析你的代码，并提供自动补全、错误提示等功能。 MCP 借鉴了 LSP 客户端-服务器的架构模式，但又超越了 LSP 的被动响应模式，MCP 旨在构建以 AI Agent 为中心的自主执行模型。

与 LSP 主要被动响应 IDE 请求不同，MCP 的目标是赋能 AI Agent 构建自主的工作流程。 基于丰富的上下文信息，AI Agent 可以主动决策调用哪些工具、以何种顺序调用、以及如何将多个工具串联起来完成复杂任务。 更重要的是，MCP 还引入了人机协作 (Human-in-the-Loop) 的机制，允许人类在必要时介入，提供额外的数据或对 Agent 的执行决策进行审批，确保 AI 的自主性与人类的掌控力之间达到平衡。

MCP 的 “魔力”：从 “万能应用” 到全新体验

有了 MCP 这套 “通用语言”，每一个 MCP 客户端都拥有了变身 “万能应用” 的潜力。

以 Cursor 这款代码编辑器为例，它不仅是一款优秀的开发工具，更是一个出色的 MCP 客户端。 通过集成不同的 MCP 服务器，Cursor 可以瞬间化身为 Slack 客户端（借助 Slack MCP 服务器）、邮件发送器（Resend MCP 服务器）、甚至是图像生成器（Replicate MCP 服务器）。 更进一步，在一个 Cursor 客户端上安装多个 MCP 服务器，就能解锁更强大的工作流：比如，用户可以指示 Agent 在 Cursor 中生成网站前端 UI 代码，同时调用图像生成 MCP 服务器，为网站自动生成精美的头图。

除了 Cursor 之外，当前 MCP 的主要应用场景可以归纳为两大类：以开发者为中心的本地优先工作流，以及 基于 LLM 客户端的全新用户体验。

解放开发者：打造 “永不离开 IDE” 的工作流

对于开发者而言，最常见的痛点之一就是需要在不同的工具和平台之间频繁切换，打断工作流。 MCP 服务器的出现，为解决这一痛点提供了完美的方案，让开发者可以真正实现 “永不离开 IDE” 的梦想。

过去，开发者需要离开 IDE，切换到 Supabase 才能查看数据库状态。现在，他们可以直接在 IDE 中使用 Postgres MCP 服务器执行 SQL 查询，或者使用 Upstash MCP 服务器管理缓存索引。 在代码迭代和调试阶段，开发者还可以借助 Browsertools MCP，让编码 Agent 能够实时访问运行环境的控制台日志等信息，从而更高效地进行调试和问题排查。

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

关注我，后续介绍安装使用方法

更令人兴奋的是，MCP 服务器还为编码 Agent 带来了全新的能力：更精准的上下文感知。 开发者可以通过抓取网页内容，或者基于 API 文档自动生成 MCP 服务器，从而让 Agent 能够即时获取最新的信息，并快速理解和使用各种工具。 这极大地降低了集成成本，开发者可以将更多精力放在真正重要的任务上，无论是获取实时数据、执行复杂命令，还是动态扩展 AI 助手的功能，都变得更加便捷高效。

创造新范式：探索 AI 应用的无限可能

虽然目前基于 IDE 的 MCP 客户端（如 Cursor）更受关注，但这仅仅是 MCP 应用的冰山一角。 对于非技术用户而言，Claude Desktop 这样的 MCP 客户端则降低了使用门槛，让更多人能够体验到 MCP 驱动的 AI 工具的强大之处。 展望未来，我们有理由期待更多面向特定业务场景的 MCP 客户端涌现，例如客户支持、营销文案、设计、图像编辑等等。 这些领域与 AI 在模式识别和创造性任务方面的优势天然契合，MCP 的引入无疑将加速这些领域的 AI 应用创新。

MCP 客户端的设计，直接决定了用户体验和应用场景的边界。 例如，一个聊天应用不太可能集成复杂的矢量图形渲染功能，而一个设计工具也无需具备远程代码执行能力。 客户端的形态和功能定义了 MCP 的用户体验，而在这方面，我们还有巨大的探索空间。

Highlight 客户端实现的 @ 命令，就是一个极具启发性的创新案例。 它允许用户在客户端中通过 @ 符号直接调用任何已安装的 MCP 服务器，并将生成的内容无缝 “管道” 到下游应用中，创造了一种全新的用户交互模式。

Highlight 实现 Notion MCP (插件) 的示例

Blender MCP 服务器 则展示了 MCP 在专业工具领域的巨大潜力。 即使是 Blender 的初学者，现在也可以通过自然语言描述想要创建的 3D 模型，AI Agent 将会调用 Blender MCP 服务器自动完成建模过程。 文本到 3D 的工作流正在加速普及，我们已经看到社区开始为 Unity、Unreal Engine 等更多专业工具开发 MCP 服务器，预示着 AI 将深刻变革专业内容创作领域。

虽然我们目前更多地关注 MCP 的客户端和服务器，但一个围绕 MCP 协议的生态系统正在逐步形成。 下方的市场地图展示了当前 MCP 生态中最活跃的领域，但仍有广阔的空白等待填补。 MCP 仍处于早期发展阶段，我们期待看到更多参与者加入，共同构建更加繁荣成熟的 MCP 生态。 

MCP 生态系统市场地图，展示客户端、服务器、基础设施和市场等关键领域

从市场地图中可以看出，目前高质量的 MCP 客户端主要集中在编码领域。 这并不意外，开发者群体通常是新技术的早期尝鲜者。 但随着 MCP 协议的成熟和普及，我们有理由相信，未来将涌现出更多面向商业应用场景的 MCP 客户端。

大多数 MCP 服务器仍然是本地优先的，并且服务于单个用户。 这主要是因为目前的 MCP 协议主要支持基于 SSE 和命令的连接方式。 不过，随着 MCP 生态对远程 MCP 的支持力度加大，并引入流式 HTTP 传输等更高效的连接方式，我们预计 MCP 服务器的采用率将迎来爆发式增长。

MCP 市场和服务器托管解决方案也开始崭露头角。 例如 Mintlify 的 mcpt、Smithery 和 OpenTools 等平台，正在努力构建 MCP 服务器的 “应用商店”，让开发者能够更方便地发现、分享和贡献新的 MCP 服务器，就像 npm 之于 JavaScript 包管理，RapidAPI 之于 API 发现一样。 这些平台将成为 MCP 生态的关键基础设施，有助于标准化高质量 MCP 服务器的访问，让 AI Agent 能够动态地选择和集成所需的工具。

随着 MCP 应用规模的扩大，基础设施和工具链的重要性日益凸显。 服务器生成工具 (如 Mintlify, Stainless, Speakeasy) 正在降低创建 MCP 兼容服务的门槛，托管解决方案 (如 Cloudflare, Smithery) 则致力于解决 MCP 服务器的部署和扩展难题。 连接管理平台 (如 Toolbase) 开始着手简化本地优先 MCP 的密钥管理和代理问题。 这些基础设施和工具的完善，将为 MCP 生态的蓬勃发展奠定坚实基础。

MCP 的未来之路：挑战与机遇并存

尽管 MCP 展现出巨大的潜力，但我们仍然处于 Agent 原生架构演进的早期阶段。 当前 MCP 的应用实践中，依然存在诸多挑战亟待解决。

下一阶段 MCP 协议迭代需要重点关注的关键问题包括：

• 托管与多租户： MCP 目前主要支持 AI Agent 与工具之间的一对多关系，但在 SaaS 等多租户场景下，需要支持多个用户同时访问共享的 MCP 服务器。 短期来看，默认支持远程服务器或许是提升 MCP 服务器易用性的有效方案，但长期来看，企业用户更倾向于托管自己的 MCP 服务器，实现数据和控制层面的隔离。
• 构建一套完善的工具链，支持大规模 MCP 服务器的部署和运维，将是推动 MCP 更广泛应用的关键一步。
• 身份验证： MCP 协议目前缺乏统一的客户端身份验证机制，也未提供 MCP 服务器与第三方 API 交互时的安全身份验证框架。 身份验证的实现方式，很大程度上依赖于具体的应用场景和开发者自身的选择。 目前 MCP 的应用主要集中在本地集成场景，对显式身份验证的需求尚不迫切。
• 客户端身份验证： 支持 OAuth、API 令牌等标准方法，用于客户端与服务器之间的身份验证。
• 工具身份验证： 提供辅助函数或封装库，简化与第三方 API 的身份验证流程。
• 多用户身份验证： 支持租户感知的身份验证机制，满足企业级应用的需求。
• 更完善的身份验证机制，将是推动远程 MCP 应用普及的关键因素之一。 从开发者的角度来看，统一的身份验证方案应涵盖：
• 授权： 即使完成了身份验证，仍然需要考虑权限控制问题：谁有权使用哪些工具？权限的粒度应该如何划分？ MCP 目前缺乏内置的权限模型，访问控制仍然处于会话级别，工具要么完全开放，要么完全受限。 未来的授权机制可能会引入更细粒度的权限控制，但目前的解决方案主要依赖基于 OAuth 2.1 的会话级授权，一旦完成身份验证，用户即可在整个会话期间拥有访问权限。 随着 Agent 和工具数量的增加，这种基于会话的访问管理方式将变得越来越复杂，每个 Agent 都需要独立的会话和授权凭证，形成庞大的会话管理网络。
• 网关： 随着 MCP 应用规模的扩大，网关 将扮演越来越重要的角色。 它可以作为集中化的入口，统一处理身份验证、授权、流量管理和工具选择等关键功能。 类似于 API 网关，MCP 网关可以强制实施访问控制策略，将请求路由到正确的 MCP 服务器，进行负载均衡，并缓存响应以提升性能。 对于多租户环境而言，网关尤为重要，它可以为不同的用户和 Agent 提供精细化的权限管理。 标准化的 MCP 网关将简化客户端-服务器交互，增强安全性，并提供更好的可观测性，提升 MCP 部署的可扩展性和可管理性。
• MCP 服务器的可发现性和易用性： 目前，查找和配置 MCP 服务器仍然是一个相对繁琐的手动过程，开发者需要手动查找端点、配置身份验证信息，并确保客户端与服务器之间的兼容性。 集成新的 MCP 服务器耗时费力，AI Agent 也无法动态发现或适应可用的服务器。
• 令人期待的是，Anthropic 在近期 AI 工程师大会上透露，MCP 服务器注册表和发现协议即将推出。 这将极大地提升 MCP 服务器的可发现性和易用性，有望开启 MCP 应用的新篇章。
• 执行环境： 大多数 AI 工作流都需要顺序调用多个工具才能完成复杂任务，但 MCP 协议本身缺乏内置的工作流管理机制。 要求每个客户端都自行实现工作流的恢复和重试机制显然是不现实的。 虽然目前已经有开发者尝试使用 Inngest 等工具来解决这个问题，但 将有状态的执行流程提升为 MCP 协议的核心概念，将有助于理清开发者的执行模型。
• 标准化的客户端体验： 开发者社区普遍关注的一个问题是：构建 MCP 客户端时，如何实现工具的选择和调用？ 是否每个客户端都需要自己实现一套工具的 RAG (Retrieval-Augmented Generation) 机制？ 是否存在一个可以标准化的通用层？
• 除了工具选择之外，目前工具调用的 UI/UX 模式也缺乏统一标准，从斜杠命令到自然语言指令，形式各异。 构建一个标准化的客户端层，用于工具发现、排序和执行，将有助于提升开发者和用户的体验一致性。
• 调试： MCP 服务器开发者 часто сталкиваются с 这样一个问题：难以确保同一个 MCP 服务器在不同的客户端上都能正常工作。 不同 MCP 客户端之间往往存在细微的差异，客户端的调用链路追踪信息要么缺失，要么难以获取，导致 MCP 服务器的调试工作异常困难。 随着远程 MCP 服务器的普及，我们需要一套新的工具链，提升本地和远程环境下的 MCP 开发调试效率。

AI 工具的未来图景：MCP 将如何重塑格局

MCP 的发展历程，让人不禁联想到 2010 年代 API 爆发式增长的时期。 彼时，API 开发范式新颖而激动人心，但工具链尚不成熟。 展望未来，如果 MCP 成为 AI 驱动工作流的事实标准，将会对整个 AI 生态带来哪些深远的影响？ 我们不妨大胆预测：

• 开发者优先的科技公司的竞争优势，将从 “最佳 API 设计” 进化为 “最佳 Agent 工具集”。 如果 MCP 具备了自主发现工具的能力，API 和 SDK 的提供商需要思考如何让自己的工具更容易被 Agent 发现和选择。 这意味着工具的设计需要更加精细化、更贴合 Agent 的使用场景，甚至比面向人类开发者的 API 设计要求更高。
• 新的定价模式可能会应运而生。 当每个应用都成为 MCP 客户端，每个 API 都成为 MCP 服务器时，Agent 可能会更加动态地选择工具，根据速度、成本、相关性等多种因素进行权衡。 这可能会催生一种更具市场驱动力的工具采用机制，性能最优、模块化程度最高的工具将更受青睐，而非仅仅是用户基数最大的工具。
• 文档的重要性将进一步提升，成为 MCP 基础设施的关键组成部分。 企业需要设计具有清晰、机器可读格式 (例如 llms.txt) 的工具和 API，并将 MCP 服务器作为基于现有文档的默认产物。 高质量、机器可读的文档将成为工具被 Agent 发现和使用的 “敲门砖”。
• 仅仅提供 API 已经不够，API 只是一个良好的开端。 开发者会逐渐意识到，API 与 Agent 所需的 “工具” 之间，并非简单的 1:1 映射关系。 “工具” 是更高层次的抽象，更贴合 Agent 在执行任务时的实际需求。 例如，Agent 可能更倾向于调用 draft_email_and_send() 这样的 “工具” 函数，而不是简单的 send_email() API，前者可能封装了多个 API 调用，以减少延迟，提升效率。 MCP 服务器的设计将更加以场景和用例为中心，而非仅仅是对 API 的简单封装。
• 托管模式将迎来变革。 如果每个软件都默认成为 MCP 客户端，工作负载特性将与传统的网站托管截然不同。 每个客户端的请求都将是多步骤的，需要可靠的执行保障，例如可恢复性、重试机制、以及长时间运行的任务管理。 托管服务提供商需要提供实时负载均衡能力，在不同的 MCP 服务器之间动态调度请求，以优化成本、延迟和性能，确保 AI Agent 能够随时选择最合适的工具。

MCP 正在重塑 AI Agent 生态的格局，而下一波浪潮将取决于我们如何应对这些基础性的挑战。 如果能够成功解决这些问题，MCP 有望成为 AI 与工具交互的默认接口，解锁新一代自主、多模态、深度集成的 AI 体验。

MCP 的广泛应用，预示着工具的构建、使用和商业模式都将迎来深刻的变革。 我们对 MCP 的未来充满期待。 今年将是至关重要的一年：我们是否会见证统一的 MCP 市场的崛起？ AI Agent 的身份验证能否变得无缝衔接？ 多步骤执行能否被正式纳入 MCP 协议？

现在，正是行动起来，共同构建 AI 工具生态的黄金时代！

本文根据 a16z 合伙人 Yoko Li 的原创文章改编。如对详细内容感兴趣，建议阅读原文^[1]。

新书推荐：

参考资料