深入探讨 MCP 与 AI 工具的未来

最新推荐文章于 2025-05-06 00:59:39 发布

原创最新推荐文章于 2025-05-06 00:59:39 发布

· 1.1k 阅读

11 ·

版权

文章标签：

#人工智能 #AI #大模型 #学习 #程序员 #MCP #Agent

自 OpenAI 于 2023 年发布函数调用功能以来，我一直在思考如何解锁代理和工具使用的生态系统。随着基础模型变得更加智能，代理与外部工具、数据和 API 交互的能力变得越来越分散：开发人员需要为代理操作的每个系统及其集成实现具有特殊业务逻辑的代理。

显然，需要为执行、数据获取和工具调用制定一个标准接口。API 是互联网的第一个伟大统一者——为软件通信创建了一种共享语言——但 AI 模型缺乏相应的等价物。

2024 年 11 月推出的 Model Context Protocol (MCP)在开发者和 AI 社区中获得了显著关注，被视为一种潜在的解决方案。在这篇文章中，我们将探讨 MCP 是什么，它如何改变 AI 与工具的交互方式，开发者们已经在用它构建什么，以及仍需解决的挑战。

什么是 MCP？

MCP 是一种开放协议，允许系统以可跨集成推广的方式为 AI 模型提供上下文。该协议定义了 AI 模型如何调用外部工具、获取数据以及与服务交互。作为一个具体示例，以下是 Resend MCP 服务器与多个 MCP 客户端协同工作的方式。

这个想法并不新鲜；MCP 从 LSP（Language Server Protocol）中获得了灵感。在 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 去做 x”。MCP 服务器是实现这一梦想的绝佳方式。

开发者现在无需切换到 Supabase 来检查数据库状态，而是可以直接在 IDE 中使用 Postgres MCP 服务器执行只读 SQL 命令，并通过 Upstash MCP 服务器创建和管理缓存索引。在代码迭代过程中，开发者还可以利用 Browsertools MCP 为编码代理提供实时环境访问，以便获取反馈和进行调试。

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

在与开发者工具交互的工作流之外，MCP 服务器开启的新用途是能够通过爬取网页或基于文档自动生成 MCP 服务器，为编码代理添加高度准确的上下文。开发者无需手动配置集成，可以直接从现有文档或 API 启动 MCP 服务器，使 AI 代理即时访问工具。这意味着减少在样板代码上的时间，更多时间实际使用工具——无论是拉取实时上下文、执行命令，还是动态扩展 AI 助手的能力。

全新体验

像 Cursor 这样的 IDE 并不是唯一的 MCP 客户端，尽管由于 MCP 对技术用户的强大吸引力，它们受到了最多的关注。对于非技术用户来说，Claude Desktop 是一个极佳的入门选择，它使 MCP 驱动的工具对普通用户更加易用和友好。很快，我们可能会看到针对以业务为中心的任务（如客户支持、营销文案、设计和图像编辑）的专门 MCP 客户端出现，因为这些领域与 AI 在模式识别和创造性任务方面的优势密切相关。

MCP 客户端的设计及其支持的特定交互在塑造其功能方面起着至关重要的作用。例如，聊天应用程序不太可能包含矢量渲染画布，就像设计工具不太可能提供在远程机器上执行代码的功能一样。最终，MCP 客户端体验定义了整体 MCP 用户体验——在 MCP 客户端体验方面，我们还有更多潜力待发掘。

一个例子是 Highlight 如何在其客户端上实现@command来调用任何 MCP 服务器。结果是一种新的用户体验模式，其中 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 服务器发现成为可能。像 Mintlify 的 mcpt、Smithery 和 OpenTools 这样的市场正在使开发者更容易发现、分享和贡献新的 MCP 服务器——就像 npm 改变了 JavaScript 的包管理方式，或者 RapidAPI 扩展了 API 发现一样。这一层对于标准化访问高质量 MCP 服务器至关重要，使 AI 代理能够动态选择和按需集成工具。

随着 MCP 的采用率增长，基础设施和工具将在使生态系统更具可扩展性、可靠性和可访问性方面发挥关键作用。诸如 Mintlify，Stainless 和 Speakeasy 等服务器生成工具正在减少创建 MCP 兼容服务的摩擦，而 Cloudflare 和 Smithery 等托管解决方案则正在应对部署和扩展的挑战。与此同时，像 Toolbase 这样的连接管理平台正开始简化本地优先的 MCP 密钥管理和代理。

未来可能性

然而，我们仍处于代理原生架构演进的早期阶段。尽管今天 MCPs 引发了大量关注，但在使用 MCP 构建和交付时，仍存在许多未解决的问题。

在协议的下一个迭代中需要解锁的一些内容包括：

托管与多租户

MCP 支持 AI 代理与其工具之间的一对多关系，但多租户架构（例如 SaaS 产品）需要支持多个用户同时访问共享的 MCP 服务器。默认情况下拥有远程服务器可能是短期内使 MCP 服务器更易于访问的解决方案，但许多企业也希望托管自己的 MCP 服务器，并分离数据平面和控制平面。

支持大规模 MCP 服务器部署和维护的简化工具链是推动更广泛采用的下一个关键环节。

认证

MCP 目前并未定义客户端如何与服务器进行认证的标准机制，也未提供 MCP 服务器在与第三方 API 交互时应如何安全管理和委派认证的框架。认证目前由各个实现和部署场景自行决定。在实践中，MCP 迄今为止的采用似乎主要集中在本地集成上，这些场景下并不总是需要显式认证。

更好的认证范式可能是远程 MCP 采用的一大关键。从开发者的角度来看，统一的方法应涵盖：

客户端认证：用于客户端与服务器交互的标准方法，如 OAuth 或 API tokens
工具认证：用于与第三方 API 进行身份验证的辅助函数或封装器
多用户认证：面向企业部署的租户感知认证

授权

即使工具经过认证，谁应被允许使用它以及他们的权限应有多细粒度？MCP 缺乏内置的权限模型，因此访问控制在会话级别——意味着工具要么可访问，要么完全受限。虽然未来的授权机制可能会形成更细粒度的控制，但目前的方法依赖于基于 OAuth 2.1 的授权流程，一旦认证，便授予整个会话的访问权限。随着更多代理和工具的引入，这带来了额外的复杂性——每个代理通常需要其自己的会话和唯一的授权凭证，导致基于会话的访问管理网络不断扩展。

Gateway

随着 MCP 的采用规模扩大，网关可以作为认证、授权、流量管理和工具选择的集中层。类似于 API 网关，它将强制执行访问控制，将请求路由到正确的 MCP 服务器，处理负载均衡，并缓存响应以提高效率。这对于多租户环境尤为重要，因为不同的用户和代理需要不同的权限。标准化的网关将简化客户端与服务器的交互，提高安全性，并提供更好的可观测性，使 MCP 部署更具可扩展性和可管理性。

MCP 服务器可发现性与可用性

目前，寻找和设置 MCP 服务器是一个手动过程，要求开发者定位端点或脚本、配置身份验证，并确保服务器与客户端之间的兼容性。集成新服务器耗时，且 AI 代理无法动态发现或适应可用服务器。

根据 Anthropic 在上个月的 AI 工程师大会上的发言，听起来 MCP 服务器注册与发现协议即将推出。这可能会开启 MCP 服务器采用的下一个阶段。

执行环境

大多数 AI 工作流程需要依次进行多个工具调用——但 MCP 缺乏内置的工作流程概念来管理这些步骤。要求每个客户端实现可恢复性和可重试性并不理想。尽管如今我们看到开发者探索如 Inngest 等解决方案来实现这一点，但将状态执行提升为一等概念将为大多数开发者理清执行模型。

标准客户体验

开发者社区中一个常见的问题是如何在构建 MCP 客户端时考虑工具选择：每个人都需要为自己的工具实现 RAG，还是存在一个等待标准化的层面？

除了工具选择之外，调用工具也没有统一的 UI/UX 模式（我们见过从斜杠命令到纯自然语言的各种方式）。一个标准的客户端层用于工具发现、排序和执行，有助于创造更可预测的开发者与用户体验。

调试

MCP 服务器的开发者们常常发现，很难让同一个 MCP 服务器轻松地跨客户端工作。通常情况下，每个 MCP 客户端都有其独特的问题，而客户端追踪信息要么缺失，要么难以找到，这使得调试 MCP 服务器成为一项极其困难的任务。随着世界开始构建更多远程优先的 MCP 服务器，需要一套新的工具来使本地和远程环境中的开发体验更加流畅。

AI 工具的影响

MCP 的开发体验让我想起了 2010 年代的 API 开发。范式新颖且令人兴奋，但工具链尚处于早期阶段。如果我们快进到几年后，如果 MCP 成为 AI 驱动工作流程的事实标准，会发生什么？一些预测：

以开发者为先的公司的竞争优势将从提供最佳 API 设计，扩展到提供最佳工具集合供代理使用。如果 MCPs 能够自主发现工具，API 和 SDK 的提供者需要确保他们的工具易于通过搜索被发现，并且足够差异化，以便代理为特定任务选择。这可能比人类开发者寻找的内容更加细化和具体。

如果每个应用都成为 MCP 客户端，每个 API 都成为 MCP 服务器，可能会出现一种新的定价模式：代理可能会根据速度、成本和相关性的组合更动态地选择工具。这可能导致一个更加市场驱动的工具采用过程，选择性能最佳和模块化程度最高的工具，而不是最广泛采用的工具。

文档将成为 MCP 基础设施的关键部分，因为企业需要设计具有清晰、机器可读格式（例如llms.txt）的工具和 API，并基于现有文档使 MCP 服务器成为事实上的工件。

仅靠 API 已不再足够，但它们可以成为很好的起点。开发者会发现，从 API 到工具的映射很少是 1:1 的。工具是一种更高层次的抽象，在任务执行时对代理最有意义——代理可能选择 draft_email_and_send()函数，而不是简单地调用 send_email()，该函数包含多个 API 调用以最小化延迟。MCP 服务器设计将以场景和用例为中心，而不是以 API 为中心。

如果每个软件默认都成为 MCP 客户端，将会出现一种新的托管模式，因为工作负载特征将与传统网站托管不同。每个客户端本质上都是多步骤的，并且需要执行保证，如可恢复性、重试和长时间运行的任务管理。托管提供商还需要在不同 MCP 服务器之间进行实时负载平衡，以优化成本、延迟和性能，使 AI 代理能够在任何给定时刻选择最高效的工具。

MCP 已经在重塑 AI 代理生态系统，但下一波进展将取决于我们如何应对基础性挑战。如果处理得当，MCP 可能成为 AI 与工具交互的默认接口，并开启新一代自主、多模态、深度集成的 AI 体验。

如果 MCP 被广泛采用，它可能代表工具构建、消费和货币化方式的转变。我们期待看到市场将它们带向何方。今年将是关键的一年：我们会看到一个统一的 MCP 市场崛起吗？AI 代理的认证会变得无缝吗？多步执行能否被正式纳入协议？