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

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

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

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

让我们开始吧。

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

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

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

1. 面向开发者的工作流

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

2. 新型应用体验

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

使用 Claude Desktop 与 Blender 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 服务器开始“远程化”，我们需要一整套新的工具来简化本地与远程环境下的开发体验。

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