a16z详解MCP，以及AI工具的未来

admin管理员组

文章数量:1443939

a16z详解MCP，以及AI工具的未来

点击蓝字

关注我们

文：Yoko Li

翻译：沉浸式AI翻译

配图：秘塔AI搜索

排版：绛烨

Yoko Li 是 Andreessen Horowitz 的合伙人，专注于企业和基础设施。

自从 2023 年 OpenAI 发布了函数调用功能以来，我一直思考如何解锁agent和工具使用的生态系统。

随着基础模型变得更加智能，agent与外部工具、数据和 API 交互的能力变得越来越碎片化：开发人员需要为agent在每个系统中运行和集成时实现特殊的业务逻辑。

很显然需要有一个执行、数据获取和工具调用的标准接口。API 是互联网的第一个大一统者，创造了一种软件通信的共享语言；但是目前的大模型缺乏同等的工具。

模型上下文协议（MCP），于 2024 年 11 月推出，已经在开发人员和 AI 社区中获得了广泛关注，被视为潜在的解决方案。

在这篇文章中，我们将探讨 MCP 是什么，它是如何改变 AI 与工具交互的方式的，开发人员已经用它构建了什么，以及仍然需要解决的挑战。

MCP 是一种开放协议，允许系统以通用的方式向 AI 模型提供上下文。 该协议定义了 AI 模型如何调用外部工具、获取数据以及与服务进行交互。

示例：与多个 MCP 客户端一起工作的 Resend MCP 服务器。

MCP 借鉴了 LSP（语言服务器协议）。在 LSP 中，当用户在编辑器中输入时，客户端会查询语言服务器以获取自动完成建议或诊断信息。

MCP 在LSP 的基础之上进行了扩展，特性是以 agent 为中心的执行模型：LSP 大多是反应性的（根据 IDE 中用户输入的请求进行响应），而 MCP 设计用于支持自主的 AI 工作流。

根据上下文，AI agent可以决定使用哪些工具、使用顺序以及如何将它们串联起来完成任务。 MCP 还引入了人机协作的能力，让人类可以提供额外的数据并批准执行。

以 Cursor 为例：

尽管 Cursor 是一个代码编辑器，但它也是一个很好的 MCP 客户端。终端用户可以使用 Slack MCP 服务器将其变成 Slack 客户端，使用 Resend MCP 服务器将其变成邮件发送器，使用 Replicate MCP 服务器将其变成图像生成器。

利用 MCP 的一种更强大的方式是，在一个客户端上安装多个服务器以解锁新的流程：用户可以在 Cursor 上安装一个生成前端 UI 的服务器，但也可以让代理使用图像生成 MCP 服务器生成站点的英雄图像。

开发者现在可以使用 Postgres MCP 服务器执行只读 SQL 命令，使用 Upstash MCP 服务器创建和管理缓存索引，而无需切换到 Supabase 检查数据库状态。在迭代代码时，开发者还可以利用 Browsertools MCP 给编码代理提供一个实时环境以获取反馈和调试。

Cursor 代理如何使用 Browsertools 获取控制台日志和其他实时数据以更高效地进行调试的一个例子

在与开发者工具交互的工作流之外，MCP 服务器解锁的一种新用途是能够通过爬取网页或根据文档自动生成 MCP 服务器，为编码代理添加高度准确的上下文。

开发人员无需手动设置集成，可以直接从现有文档或 API 启动 MCP 服务器，使工具瞬间对 AI 代理可用。这意味着开发人员将花费更少的时间在样板代码上，而更多的时间实际使用这些工具——无论是获取实时上下文、执行命令，还是即时扩展 AI 助手的功能。

MCP新的体验

MCP 客户端的设计及其支持的具体交互方式在塑造其能力方面起着关键作用。

例如，一个聊天应用程序不太可能包含向量渲染画布，就像一个设计工具不太可能提供在远程机器上执行代码的功能一样。

最终，MCP 客户端体验定义了整体 MCP 用户体验 ——我们还有许多关于 MCP 客户端体验的潜力可以挖掘。

这一个例子是 Highlight 如何实现 @命令来调用其客户端上的任何 MCP 服务器。结果是一种新的用户体验模式，在这种模式中，MCP 客户端可以将生成的内容管道传输到任何下游应用程序中。

Highlight 对 Notion MCP（插件）的实现示例

另一个例子是 Blender MCP 服务器的应用场景：现在，即使是几乎不懂 Blender 的初学者，也可以使用自然语言来描述他们想要构建的模型。随着社区为其他工具（如 Unity 和虚幻引擎）实现服务器，我们正在看到从文本到三维的实时工作流程。

随着 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 密钥管理和代理。

未来MCP协议的更多可能性

目前仍处于代理原生架构演化的早期阶段。尽管今天 MCP 有很多令人兴奋的地方，但在构建和发布 MCP 时也存在许多未解决的问题。

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

主机和多租户

MCP 支持一个 AI Agent与其工具之间的一对多关系，但多租户架构（例如 SaaS 产品）需要支持多个用户同时访问共享的 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 服务器注册和发现协议。这可能会推动 MCP 服务器的下一轮采用。

执行环境

大多数 AI 工作流需要按顺序调用多个工具，但 MCP 缺乏内置的工作流概念来管理这些步骤。要求每个客户端都实现可恢复性和重试性并不理想。尽管今天我们可以看到开发人员正在探索像 Inngest 这样的解决方案来实现这一点，将状态化执行提升为一等概念将为大多数开发人员清理执行模型。

标准客户端体验

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

除了工具选择之外，还缺乏统一的 UI/UX 模式来调用工具（我们看到的范围从斜杠命令到纯粹的自然语言）。客户端标准层用于工具发现、排名和执行，可以帮助创建更可预测的开发者和用户体验。

调试

开发 MCP 服务器的开发者经常发现很难让同一个 MCP 服务器在不同的客户端上正常工作。通常情况下，每个 MCP 客户端都有自己的怪癖，客户端的日志要么缺失要么难以找到，这使得调试 MCP 服务器变得极其困难。随着世界开始构建更多的远程 MCP 服务器，需要一套新的工具来使本地和远程环境的开发体验更加流畅。

AI 工具的影响

如果 MCP 成为 AI 驱动工作流的默认标准会发生什么？一些预测：

开发导向公司的竞争优势将演变，从提供最佳 API 设计，转变为提供最佳工具集合供Agent使用。

可能会出现新的定价模式如果每个应用程序都成为 MCP 客户端，每个 API 都成为 MCP 服务器：代理可能会根据速度、成本和相关性等因素更动态地选择工具。

文档将成为 MCP 基础设施的关键组成部分，因为公司将需要设计具有清晰且机器可读格式的工具和 API（例如，llms.txt），并将 MCP 服务器作为基于现有文档的默认产物。

MCP 服务器设计将根据场景和用例而非 API 来中心化设计。工具是一种更高的抽象层次，对于执行任务时的agent来说是最有意义的——而不是简单地调用 send_email()，代理可能会选择使用 draft_email_and_send() 函数，该函数包含多个 API 调用以减少延迟。

将出现一种新的托管模式，每个MCP客户端都将具有多步骤性质，并需要执行保证，如可恢复性、重试和长时间任务管理。托管提供商还需要在不同的 MCP 服务器之间进行实时负载均衡，以优化成本、延迟和性能，使 AI 代理能够在任何给定时刻选择最高效的工具。

MCP 已经在重塑 AI 代理生态系统，但下一波进展将由我们如何解决基础挑战来定义。如果做得正确，MCP 可以成为 AI 与工具交互的默认接口，并解锁新一代自主、多模态和深度集成的 AI 体验。

如果广泛采用，MCP 可以代表工具构建、使用和变现方式的转变。我们期待看到市场将如何发展。今年将是关键的一年：我们是否会看到统一的 MCP 市场的兴起？身份验证能否无缝应用于 AI 代理？多步骤执行能否被正式纳入协议？

本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。原始发表：2025-03-22，如有侵权请联系 cloudcommunity@tencent 删除代理服务器工具客户端协议

本文标签： a16z详解MCP，以及AI工具的未来