选自 a16z.com
作者：Yoko Li
编译：凯文、2049
如今，随着基础模型变得越来越智能，人们越来越需要有一个用于执行、数据获取和工具调用的标准接口。
自 OpenAI 在 2023 年发布函数调用功能以来，AI 智能体与外部工具、数据和 API 的交互能力却日益碎片化：开发者需要为智能体在每个系统中的操作和集成实现特定的业务逻辑。
显然，执行、数据获取和工具调用需要一个标准接口。API 曾是互联网的第一个伟大统一者——为软件之间的通信创造了一种共享语言，但 AI 模型却缺乏类似的机制。
2024 年 11 月 Anthropic 推出的模型上下文协议（Model Context Protocol，简称 MCP），在开发者和 AI 社区中迅速获得了广泛关注，被视为一种潜在的解决方案。
近日，全球知名投资机构 a16z 发布了一篇博客文章，深度介绍了 MCP 以及 AI 工具生态的未来。
博客链接：a-deep-dive-into-mcp-and-the-future-of-ai-tooling/
本文将深入探讨 MCP 是什么，它如何改变 AI 与工具的交互方式，开发者已经用它构建了哪些应用，以及仍需解决的挑战。
让我们跟随博客一探究竟。
MCP 是什么？
MCP（Model Context Protocol，模型上下文协议）是一种开放协议，它允许系统以可泛化的方式为 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 去完成某件事」。MCP 服务器正是实现这一梦想的绝佳方式。
基于 MCP 服务器，开发者不再需要切换到 Supabase 来检查数据库状态，而是可以直接在 IDE 中使用 Postgres MCP 服务器执行只读 SQL 命令，或通过 Upstash MCP 服务器创建和管理缓存索引。在迭代代码时，开发者还可以利用 Browsertools MCP 服务器，让编程智能体访问实时环境，获取反馈并进行调试。
如上图所示，Cursor 智能体可以通过 Browsertools 访问控制台日志和其他实时数据，从而更高效地进行调试。
除了与开发工具交互的工作流，MCP 服务器还解锁了一种全新的应用场景：通过爬取网页或基于文档自动生成 MCP 服务器，为编码智能体提供高度准确的上下文信息。开发者无需手动配置集成，而是可以直接从现有文档或 API 中快速启动 MCP 服务器，使 AI 智能体能够即时访问这些工具。这意味着更少的时间花在样板代码上，更多的时间用于实际使用工具 —— 无论是拉取实时上下文、执行命令，还是动态扩展 AI 助手的能力。
全新体验
Cursor 等 IDE 并不是唯一可用的 MCP 客户端，对于非技术用户来说，Claude Desktop 是一个极好的切入点，它使 MCP 驱动的工具更易于普通用户使用。很快，我们可能会看到专门的 MCP 客户端出现，用于以业务为中心的任务，例如客户支持、营销文案、设计和图像编辑，因为这些领域与 AI 在模式识别和创意任务方面的优势密切相关。
MCP 客户端的设计及其支持的特定交互在塑造其功能方面起着至关重要的作用。例如，聊天应用不太可能包含矢量渲染画布，就像设计工具不太可能提供在远程机器上执行代码的功能一样。最终，MCP 客户端体验定义了整体 MCP 用户体验 —— 而对于 MCP 的体验，我们还有更多东西需要解锁。
一个典型的例子是 Highlight 如何通过实现「@」命令来调用其客户端上的任何 MCP 服务器。这创造了一种全新的用户体验模式，即 MCP 客户端可以将生成的内容直接导入到任何下游应用中。
另一个例子是 Blender MCP 服务器的用例：现在，几乎不了解 Blender 的业余用户可以用自然语言描述他们想要构建的 3D 模型。随着社区为 Unity 和 Unreal 引擎等其他工具实现服务器，我们正在实时见证「文本到 3D」工作流的落地。
虽然我们主要关注服务器和客户端，但随着协议的发展，MCP 生态系统正在逐步成型。当前的市场地图覆盖了最活跃的领域，但仍有许多空白。考虑到 MCP 仍处于早期阶段，我们期待随着市场的演变和成熟，将更多参与者加入这张地图。（我们将在下一部分探讨其中的一些未来可能性。）
在 MCP 客户端方面，目前我们看到的高质量客户端大多以编程为中心。这并不令人意外，因为开发者通常是新技术的早期采用者。但随着协议的成熟，我们预计会看到更多以业务为中心的客户端出现。
在 MCP 服务器方面，目前大多数服务器都以本地优先为主，专注于单一功能。这是由于 MCP 目前仅支持基于 SSE 和命令的连接。然而，随着生态系统将远程 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 的密钥管理和智能体。
未来可能性
智能体原生架构（agent-native architecture）的发展仍处于萌芽阶段。尽管业界已经对 MCP 展现出极大热情，但构建和部署 MCP 过程中仍面临诸多亟待解决的技术难题。协议在下一轮迭代中需要重点突破的领域包括：
托管与多租户
MCP 支持 AI 智能体与其工具之间的一对多关系，但多租户架构（例如 SaaS 产品）需要支持多用户同时访问共享的 MCP 服务器。近期解决方案可能是默认采用远程服务器，使 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 服务器注册表 (server registry) 和发现协议 (discovery protocol)。这项技术可能将为 MCP 服务器的应用推广开启崭新阶段。
执行环境
大多数 AI 工作流程需要按顺序执行多个工具调用，但 MCP 缺乏内置的工作流概念来管理这些步骤。要求每个客户端都实现可恢复性和可重试性是不理想的。尽管目前开发者正在尝试使用 Inngest 等解决方案来实现这一功能，但将有状态执行提升为一级概念将能为大多数开发者简化执行模型。
标准客户端体验
开发者社区经常提出的一个问题是：在构建 MCP 客户端时如何考虑工具选择 —— 是否每个开发者都需要为工具实现自己的 RAG，还是有一个等待标准化的层？
除了工具选择外，目前还没有统一的工具调用 UI/UX 模式（从斜杠命令到纯自然语言的各种方式都存在）。一个用于工具发现、排序和执行的标准客户端层可以帮助创建更可预测的开发者和用户体验。
调试
MCP 服务器的开发者经常发现，让同一个 MCP 服务器轻松地跨客户端工作是很困难的。通常情况下，每个 MCP 客户端都有自己的特性，而客户端跟踪要么缺失要么难以找到，这使得调试 MCP 服务器成为一项极其困难的任务。随着越来越多远程优先的 MCP 服务器被构建，需要一套新的工具来使开发体验在本地和远程环境中更加流畅。
AI 工具的影响
MCP 的开发体验让人联想到 2010 年代的 API 开发。这种范式虽然新颖且令人兴奋，但其工具链仍处于早期阶段。如果展望几年后，假设 MCP 成为 AI 驱动工作流的事实标准，会发生什么？以下是一些预测：
以开发者为中心的公司竞争优势将从最佳 API 设计转向提供最优工具集。若 MCP 能自主发现工具，API 提供商需确保其工具易于被发现，并具备差异化特性，使智能体能为特定任务选择它们。
当每个应用都成为 MCP 客户端、每个 API 都成为 MCP 服务器时，将出现新定价模式：智能体会基于速度、成本和相关性动态选择工具。这可能使工具采用过程更市场化，优先选择性能最佳和模块化的工具。
文档将成为 MCP 基础设施的关键，企业需设计具有清晰、机器可读格式的工具和 API，使 MCP 服务器成为基于现有文档的事实性产物。
仅有 API 还不够，但可作为良好起点。工具与 API 的映射很少是一对一关系。工具是更高层次的抽象，智能体可能选择包含多个 API 调用以最小化延迟的函数。MCP 服务器设计将以场景和用例为中心。
若软件默认成为 MCP 客户端，将出现新的托管模式。每个客户端本质上都是多步骤的，需要可恢复性、重试和长时间运行任务管理。托管提供商需跨不同 MCP 服务器进行实时负载均衡，优化成本与性能。
MCP 正在重塑 AI 智能体生态系统，而下一阶段的发展将取决于如何应对其基础性挑战。若实施得当，MCP 有望成为 AI 与工具交互的标准接口，并开创自主、多模态且深度整合的新一代 AI 体验。
如果 MCP 获得广泛应用，它将从根本上改变工具的构建、使用和商业化方式。业内专家正密切关注市场将如何引导 MCP 的发展方向。
今年将是决定性的一年：我们是否会看到统一的 MCP 市场崛起？AI 智能体的身份验证是否能实现无缝对接？多步骤执行能否被正式纳入协议标准？
0 条