自 2023 年 OpenAI 推出函数调用功能以来，业界一直在探索如何打造一个智能体与工具协同使用的生态系统。随着基础模型日益智能化，智能体与外部工具、数据和 API 的交互也变得更加碎片化：开发人员需要为智能体操作和集成的每个系统实现特定的业务逻辑。
显然，我们需要一个用于执行、数据获取和工具调用的标准接口。API（应用程序编程接口）是互联网早期重要的整合者——它定义了一套标准的规则和方法，使得不同的软件系统之间可以相互通信和交换数据——但 AI 模型目前缺乏与之对等的标准。
模型上下文协议（MCP）于 2024 年 11 月推出，作为潜在的解决方案，迅速获得了开发者和 AI 社区的广泛关注。在本文中，我们将探讨 MCP 是什么，它如何改变 AI 与工具交互的方式，开发者已经用它构建了什么，以及尚待解决的挑战。
什么是 MCP？
MCP 是一种开放协议，允许系统以一种通用的方式向 AI 模型提供上下文，这种方式可以推广到各种集成场景。该协议定义了 AI 模型如何调用外部工具、获取数据以及与服务交互。例如，下图展示了 Resend MCP 服务器如何与多个 MCP 客户端协同工作。
这一概念并不新颖；MCP 从 LSP（语言服务器协议）中汲取了灵感。在 LSP 中，当用户在编辑器中键入时，客户端会查询语言服务器以获取自动完成建议或诊断信息。
MCP 相较于 LSP 的扩展之处在于其以智能体为中心的执行模型。LSP 主要是响应式的（响应来自 IDE 的、基于用户输入的请求）。而 MCP 则更进一步，旨在支持自主的 AI 工作流。基于上下文，AI 智能体可以决定使用哪些工具、以何种顺序使用，以及如何将它们组合起来完成任务。MCP 还引入了人工介入（human-in-the-loop）机制，允许人工提供额外数据并审批操作。
当前的流行用例
有了合适的 MCP 服务器集，用户可以将每个 MCP 客户端变成一个通用应用。
以 Cursor 为例：虽然 Cursor 是一个代码编辑器，但它也是一个良好实现的 MCP 客户端。最终用户可以使用 Slack MCP 服务器 将其变成 Slack 客户端，使用 Resend MCP 服务器 将其变成电子邮件发送器，以及使用 Replicate MCP 服务器 将其变成图像生成器。更强大的 MCP 用法是在一个客户端上安装多个服务器以实现新的工作流程：用户可以安装一个服务器从 Cursor 生成前端 UI，还可以要求智能体使用图像生成 MCP 服务器为网站生成题图或横幅图片。
除了 Cursor 之外，目前，大多数用例可以归纳为两类：以开发者为中心的本地工作流，以及基于 LLM 客户端的全新体验。
以开发为中心的工作流
对于每天沉浸在代码中的开发者来说，一个普遍的诉求是，“我不想离开我的 IDE 去做某件事”。MCP 服务器是实现这一目标的绝佳方式。
开发者现在可以直接在他们的 IDE 中使用 Postgres MCP 服务器 执行只读 SQL 命令。他们还可以使用 Upstash MCP 服务器 创建和管理缓存索引。这样，他们无需切换到 Supabase 就能检查数据库状态。在迭代代码时，开发人员还可以利用 Browsertools MCP 让编码智能体访问实时环境以进行反馈和调试。
_Cursor 智能体如何使用 Browsertools 访问控制台日志等实时数据，从而更有效地进行调试的示例。_
除了与开发者工具交互的工作流之外，MCP 服务器还带来了一种新的应用场景：通过抓取网页 或基于文档 自动生成 MCP 服务器，可以为编码智能体提供高度准确的上下文信息。开发者可以直接从现有文档或 API 启动 MCP 服务器，使工具立即可供 AI 智能体访问，而无需手动连接集成。这意味着减少了在样板文件上花费的时间，而将更多时间用于实际使用工具——无论是引入实时上下文、执行命令还是动态扩展 AI 助手的能力。
全新体验
Cursor 等 IDE 并不是唯一的 MCP 客户端，尽管由于 MCP 对技术用户的强烈吸引力，它们获得了最多的关注。对于非技术用户，Claude Desktop 提供了一个极佳的入门途径，使更广泛的用户群体能够轻松访问和使用 MCP 驱动的工具。很快，我们可能会看到专门的 MCP 客户端出现，用于以业务为中心的任务，如客户支持、营销文案、设计和图像编辑，因为这些领域与 AI 在模式识别和创造性任务方面的优势密切相关。
MCP 客户端的设计及其支持的特定交互在塑造其功能方面起着至关重要的作用。例如，聊天应用程序通常不包含矢量渲染画布，而设计工具通常也不提供在远程机器上执行代码的功能。最终，MCP 客户端体验定义了整体 MCP 用户体验——而在 MCP 客户端体验方面，还有很多潜力有待挖掘。
例如，Highlight 实现了 @ 命令来调用其客户端上的任何 MCP 服务器。由此产生了一种新的 UX 模式：MCP 客户端可以将生成的内容导入到任何选定的下游应用程序中。
_Highlight 实现 Notion MCP 插件的示例。_
另一个例子是 Blender MCP 服务器 用例：现在，几乎不了解 Blender 的业余用户可以使用自然语言来描述他们想要构建的模型。随着社区为 Unity 和 Unreal 引擎等其他工具实现服务器，我们可以看到文本到 3D 工作流的实际应用。
_将 Claude Desktop 与 Blender MCP 服务器 结合使用的示例。_
尽管我们主要关注服务器和客户端，但随着协议的演进，MCP 生态系统也在逐渐成形。这张市场地图涵盖了当今最活跃的领域。 虽然MCP 仍处于早期阶段，随着市场的发展和成熟, 预计将有更多的参与者加入到这个生态中。
目前，大多数高质量的 MCP 客户端都以编码为中心。这并不奇怪，因为开发者通常是新技术的早期应用者，但是，随着协议的成熟，我们希望看到更多以业务为中心的客户端。
大多数 MCP 服务器都支持本地部署，并且专注于单一应用场景。这反映出 MCP 目前仅支持基于 SSE 和命令的连接。但是，随着生态系统将远程 MCP 作为一等公民来对待，并且 MCP 应用流式 HTTP 传输，预计会看到更多的 MCP 服务器应用。
新一波 MCP 市场和服务器托管解决方案正在涌现，旨在实现 MCP 服务器的可发现性。这类似于 npm 如何变革 JavaScript 的包管理，以及 RapidAPI 如何扩展 API 的发现。像 Mintlify 的 mcpt、Smithery 和 OpenTools 这样的市场正在使开发者更容易发现、共享和贡献新的 MCP 服务器。这对于标准化高质量 MCP 服务器的访问至关重要，允许 AI 智能体按需动态选择和集成工具。
随着 MCP 的应用不断增加，基础设施和工具将在提升生态系统的可扩展性、可靠性和可访问性方面发挥关键作用。像 Mintlify、Stainless 和 Speakeasy 这样的服务器生成工具正在减少创建 MCP 服务的兼容性问题，而像 Cloudflare 和 Smithery 这样的托管解决方案正在解决部署和扩展挑战。同时，Toolbase 等连接管理平台也开始简化本地部署的 MCP 密钥管理和代理方式。
未来的可能性
然而，智能体原生架构的演进仍处于早期阶段。尽管现在人们对 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 服务器的可发现性和可用性
目前，查找和设置 MCP 服务器需要手动操作，包括查找端点或脚本、配置身份验证，以及确保服务器和客户端之间的兼容性。集成新服务器非常耗时，并且 AI 智能体无法动态发现或适应可用的服务器。
不过，根据 Anthropic 上个月在 AI 工程师大会上的演讲，MCP 服务器注册中心和发现协议似乎即将推出。这可能会开启 MCP 服务器应用的下一阶段。
执行环境
大多数 AI 工作流都需要按顺序调用多个工具——但 MCP 缺乏管理这些步骤的内置工作流概念。要求每个客户端都实现任务中断后继续执行（可恢复性）和自动重新尝试失败任务（可重试性）的功能是不现实的。 将有状态执行提升为协议的一等概念，将为大多数开发者简化执行模型。
标准客户端体验
开发者社区普遍关心的一个问题是，在构建 MCP 客户端时如何进行工具选择：是否每个开发者都需要实现自己的工具检索增强生成（RAG）机制，还是存在一个有待标准化的通用层？
除了工具选择，目前还没有统一的 UI/UX 模式来调用工具（目前已经出现了从斜杠命令到纯自然语言的各种交互方式）。建立用于工具发现、排序和执行的标准化客户端层，有助于创建更可预测的开发者和用户体验。
调试
MCP 服务器开发者经常遇到的一个难题是，难以让同一个 MCP 服务器在不同客户端上都能顺畅运行。通常情况下，每个 MCP 客户端都有自己的特性，而客户端的跟踪信息要么缺失，要么难以查找，导致 MCP 服务器的调试极为困难。随着越来越多的远程 MCP 服务器被构建，需要一套新的工具来简化跨本地和远程环境的开发体验。
AI 工具的影响
MCP 的开发体验与 2010 年代的 API 开发有相似之处。虽然这种模式新颖且令人兴奋，但工具链仍处于早期阶段。如果展望未来，假设 MCP 成为 AI 驱动工作流的业界标准，会发生什么？一些预测：
- 以开发者为中心的公司，其竞争优势将从提供最佳 API 设计，转变为同时提供最佳工具集供 AI 使用。如果 MCP 能够自主发现工具，API 和 SDK 提供商就需要确保其工具易于通过搜索发现，并且具备足够的差异性，以便 AI 能够针对特定任务做出选择。
- 如果每个应用都成为 MCP 客户端，每个 API 都成为 MCP 服务器，则可能会出现新的定价模型：AI 可能会根据速度、成本和相关性等因素，更动态地选择工具。这可能会导致更加市场化的工具采用过程，选择性能最佳、最易于组合的工具，而不是采用最广泛的工具。
- 文档将成为 MCP 基础设施的关键组成部分。需要以清晰的、机器可读的格式（如 llms.txt）来设计工具和 API，并使 MCP 服务器成为基于现有文档自动生成的标准组件。
- 仅有 API 已经不够了，但 API 可以作为良好的起点。 开发者会发现，从 API 到工具的映射很少是一一对应的。工具是更高层次的抽象，在执行任务时对 AI 更为有效。例如，AI 可能会选择包含多个 API 调用的 draft_email_and_send() 函数（例如，先调用 API 获取邮件模板，再调用 API 填充内容，最后调用 API 发送），以最小化延迟，而不是简单地调用 send_email()。 因此，MCP 服务器的设计应以场景和用例为中心。
- 如果每个软件默认都成为 MCP 客户端，将会出现一种新的托管模式，因为其工作负载特征将不同于传统的网站托管。每个客户端的工作流都将是多步骤的，并且需要可恢复性（任务中断后继续执行的能力）、重试（自动重新尝试失败任务的能力）和长期任务管理等执行保障。 托管提供商还需要在不同的 MCP 服务器之间进行实时负载均衡，以优化成本、延迟和性能，从而使 AI 能够在任何时刻选择最高效的工具。
MCP 正在重塑 AI 智能体生态系统，但下一阶段的发展将取决于我们如何解决这些根本性的挑战。MCP 有潜力成为 AI 与工具交互的默认接口，从而开启新一代自主、多模态和深度集成的 AI 体验。
MCP 的广泛应用，预示着工具构建、使用和商业化方式的转变。业界期待着市场如何引领其发展。今年将是关键的一年：我们能否见证统一的 MCP 市场的兴起？ 身份验证能否对 AI 智能体变得无缝？ 多步骤执行能否被正式纳入协议？让我们拭目以待
原文链接：https://a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/