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

本文译者为 360 奇舞团前端开发工程师  
原文标题：A Deep Dive Into Mcp and the Future of AI Tooling
原文作者：Yoko Li
原文地址：https://a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/

自从OpenAI在2023年推出函数调用功能以来，我一直在思考如何构建智能体（Agent）与其相关工具的生态。基础模型变得越来越智能，但智能体与外部工具、数据和API交互的能力却变得越来越割裂：开发者不得不为智能体运行的每个系统单独编写特定的业务逻辑代码。

显然，业界需要一套标准化的执行、数据获取及工具调用接口。API曾是互联网的首个伟大统一者——它创建了软件通信的通用语言——但AI领域至今缺乏同等级别的标准。

2024年11月发布的模型上下文协议（Model Context Protocol, MCP）作为潜在解决方案，已在开发者和AI社区引发强烈关注。本文将深入探讨MCP的本质，它如何改变AI与工具的交互模式，开发者基于MCP的实践成果，以及仍需解决的挑战。

接下来，我们深入探讨MCP。

什么是MCP？

MCP是一个开放协议，支持系统跨集成通用化的方式为AI模型提供上下文。该协议定义了AI模型如何调用外部工具、获取数据和交互服务的规范。以下案例直观展示了Resend MCP服务器如何与多个MCP客户端协同工作：

这个理念并非首创；MCP的灵感来源于语言服务器协议（Language Server Protocol，LSP） 的设计思想。在LSP中，当用户在编辑器中输入时，客户端会向语言服务器查询以获取自动补全建议或诊断信息。

MCP的创新之处在于其智能体中心执行模型：LSP本质是响应式（根据IDE的用户输入响应请求），而MCP则旨在支持自主的AI工作流。AI智能体可以根据上下文决定工具的选择、调用顺序与组合方式以实现目标任务。协议还引入了人机协作功能，允许人工补充数据并批准执行。

当前主流应用场景

通过适当的配置MCP服务器，用户可将任意MCP客户端转化为“全能应用”。

以Cursor为例：虽然Cursor是一个代码编辑器，但它同时也是一个优秀的MCP客户端。终端用户可以使用Slack MCP服务器将Cursor转变为Slack通讯客户端，使用Resend MCP服务器实现邮件发送功能，以及使用Replicate MCP服务器生成图像。更强大的是，用户可以在同时安装多个服务器以解锁新的工作流：用户可安装服务器在Cursor中生成前端UI，同时要求智能体使用图像生成MCP服务器为网站配图。

除了Cursor之外，当前大多数用例可以归为两类：以开发者中心的本地优先工作流，或者基于大语言模型（LLM）客户端的全新体验。

以开发者为中心的工作流程

对于每天沉浸在代码中的开发者来说，一个普遍的诉求是：“我不想离开我的IDE去处理其他任务”。MCP服务器正是实现该愿景的绝佳途径。

想要检查数据库状态，开发者无需切换到Supabase，现在他们可以直接使用Postgres MCP服务器执行只读SQL查询。使用Upstash MCP服务器在IDE中创建和管理缓存索引。在代码迭代时，开发者还可以使用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的零基础用户通过自然语言描述即可建模。随着社区陆续为Unity和Unreal Engine等工具开发MCP服务器，文本转3D工作流正加速落地。

使用Claude Desktop与Blender MCP服务器的一个示例。

尽管焦点主要在服务器和客户端，但随着协议的发展，MCP生态正在逐渐成形。这张市场地图涵盖了今天最活跃的领域（尽管仍有很多空白）。考虑到MCP仍处于早期阶段，我们期待随着市场成熟，能有更多的参与者加入。（我们将在下一节探讨部分的未来可能性。）

在MCP客户端方面，当前高质量产品多聚焦编程领域（开发者通常是最先尝试新技术的群体）。但随着协议的成熟，我们预计会有更多以业务为中心的客户端出现。

现有的大多数MCP服务器是本地优先、面向单人的架构。这是受限于目前MCP仅支持SSE和命令式连接。然而，但伴随生态将远程MCP视为一等公民（first-class），以及Streamable HTTP传输协议的应用，预计MCP服务器的使用率将显著提升。

新兴的MCP市场与服务器托管方案正推动服务器发现（server-discovery）的进程。像Mintlify的mcpt、Smithery和OpenTools等平台使得开发者更容易发现、分享和贡献新的MCP服务器——就像npm重构了JavaScript包管理生态，或是RapidAPI革新了API发现模式一样。该层对于标准化访问高质量的MCP服务器至关重要，支持AI智能体根据需要动态选择和集成工具。

随着MCP协议的普及，基础设施与工具链将在构建可扩展、可靠和易用的生态中发挥关键作用。像Mintlify、Stainless和Speakeasy这样的服务器生成工具显著降低了创建与MCP兼容服务的门槛；Cloudflare和Smithery等托管解决方案致力于解决部署和扩展的挑战。同时，像Toolbase这种连接管理平台则着手于优化本地优先策略下的MCP密钥管理与代理机制。

未来的可能性

然而，我们目前仅处于智能体原生架构演化初期。尽管当前MCP协议热度高涨，但在构建和部署MCP时仍存在许多待解决的难题。

想要协议进一步迭代升级，还有以下领域正待突破：

托管与多租户

MCP支持AI智能体与其工具之间的一对多关系，但多租户架构（如SaaS产品）需要支持多个用户并发访问共享的MCP服务器。默认使用远程服务器提升可访问性的短期解决方案，但许多企业仍倾向于托管自己的MCP服务器，并将数据和控制平面分离。

一套简化的、支持大规模MCP服务器部署和维护的工具链，将是推动MCP普及的关键一环。

认证

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

更完善的认证范式可能成为远程MCP普及的关键突破点。从开发者视角出发，统一的方案应涵盖以下三个层级：

• 客户端认证：用于客户端-服务器交互的标准方法，如OAuth或API令牌

• 工具认证：用通过辅助函数或封装器处理第三方API的认证流程

• 多用户认证：面向企业部署场景，提供租户感知（tenant-aware）认证机制

授权

即使某个工具已经通过认证，谁应该被允许使用它？其权限应该精细到何种程度？MCP缺乏内置的权限模型，因此目前的访问控制在会话级别——意味着一个工具要么可访问，要么完全受限。未来的授权机制可能会形成更精细的控制，但当前的方法依赖于OAuth 2.1的授权流程，一旦认证就授予整个会话周期的访问权限。随着更多智能体和工具的引入，这带来了额外的复杂性问题——每个智能体都需要有一个独立的、拥有独特授权凭证的会话，这会导致基于会话的访问管理网络日趋庞大。

网关

MCP规模化应用时，网关可以充当一个认证、授权、流量管理和工具选择的集中层。和API的网关类似，它将实施访问控制，将请求路由到正确的MCP服务器，执行负载均衡，并通过缓存响应提升效率。这对于多租户环境尤其重要，因为不同的用户和智能体需要不同的权限。标准化的网关将简化客户端-服务器交互流程，提高安全性，并使可观测性更好，从而使MCP部署具备更强的扩展性和可管理性。

MCP服务器的可发现性和可用性

目前，查找和设置MCP服务器仍需手动完成：开发者需要自行定位端点或脚本，配置身份验证，并确保服务器与客户端之间的兼容性。集成新服务器耗时耗力，且AI智能体无法动态发现或适配可用的服务器。

不过根据Anthropic上个月在AI工程师大会上[发表的讲话]透漏(https://youtu.be/kQmXtrmQ5Zg?t=4927)，服务器注册中心和发现协议(MCP server registry and discovery protocol)即将推出。这可能会使MCP服务器进一步普及。

执行环境

大多数AI工作流需要按顺序调用多个工具——但MCP缺乏内置的工作流机制来管理这些步骤。要求每个客户端自行实现执行可恢复性与重试能力并不合理。尽管当前我们可以看到开发者探索使用类似Inngest的解决方案来实现此类功能，但将状态化执行（stateful execution）提升为一等概念（first-class concept），将为绝大多数开发者厘清执行模型。

标准客户端体验

开发者社区中一个常见的问题是：构建MCP客户端时，应该如何设计工具选择机制？是否每个开发者都需要自行实现工具的RAG（检索增强生成）方案？还是说可以用一个标准化的中间层统一解决该问题？

此外，工具调用也缺乏统一的UI/UX交互模式（当下有很多种解决方案——从斜杠命令（/command）到自然语言指令）。若能建立一个标准化的客户端层，用于工具发现、排序与执行管理，可以显著提升开发者和最终用户体验的稳定性。

调试

MCP服务器开发者经常发现，让同一个MCP服务器方便的适配不同客户端非常困难。通常情况下，每个MCP客户端都有自己的特性，而客户端的日志要么缺失，要么难以查找。这使得调试MCP服务器成为一项极其困难的任务。随着业界开始构建更多“远程优先”的MCP服务器，需要一套新的工具集，以优化开发者在本地和远程环境中的体验。

AI工具的影响

MCP的开发体验让我想起了2010年代的API开发。这种范式既新颖又令人兴奋，但工具链仍处于早期阶段。如果我们展望未来数年，若MCP成为AI驱动工作流的事实标准，将会发生什么？以下是部分预测：

• 开发优先公司的竞争优势将从提供最佳API设计，演变为同时提供最优质的智能体工具集。若MCP具备自主发现工具的能力，API和SDK提供商必须确保其工具易于被搜索发现，并具备足够差异性以使智能体能为特定任务选择它们。这比人类开发者所需的工具更为细致和具体。

• 全新定价模型可能诞生：如果每个应用程序都成为MCP客户端，每个API都成为MCP服务器，智能体可能会根据速度、成本和相关性动态选择工具。这将催生更受市场驱动的工具采用机制——选择性能最优且模块化程度最高的工具，而非当前最流行的方案。

• 文档将成为文档将成为MCP基础设施的核心，公司需要以清晰的机器可读格式（例如llms.txt）来设计工具和API，使现有文档能直接转化为MCP服务器实例。

• 仅靠API已不足够，但它还是重要的起点。开发者将发现API到工具的映射很少是1:1关系。工具作为更高层级的抽象，对任务执行中的智能体更具意义——相较于简单调用send_email()，智能体可能选择包含多次API调用的draft_email_and_send()函数以降低延迟。MCP服务器设计将转向以场景和用例为中心，而不是以API为中心。

• 如果所有软件默认成为MCP客户端，将出现一种新的托管方式，因为其工作负载特征与传统网站托管截然不同：每个客户端本质都是多步骤流程，需具备可恢复性、重试机制和长期任务管理等执行保证。托管商还需在不同MCP服务器间实施实时负载均衡，以优化成本、延迟和性能，使AI智能体能在任意时刻选择最高效的工具。

MCP已经在重塑AI智能体生态，但下一波进展取决于基础性挑战的应对。若成功实施，MCP将成为AI与工具交互的默认接口，开启具备自主性、多模态和深度集成的新一代AI体验。

如果被广泛采用，MCP将彻底改变工具的构建、消费和商业化模式。我们期待见证市场的发展方向。今年将会是关键的一年：我们会看到统一的MCP市场崛起吗？AI智能体的认证能否实现无缝衔接？多步骤执行机制会否正式纳入协议？

如果你在这个领域工作或对这个领域的发展有想法，请联系yli@a16z.com。是时候行动了！

-END -

如果您关注前端+AI 相关领域可以扫码进群交流

添加小编微信进群😊

关于奇舞团

奇舞团是 360 集团最大的大前端团队，非常重视人才培养，有工程师、讲师、翻译官、业务接口人、团队 Leader 等多种发展方向供员工选择，并辅以提供相应的技术力、专业力、通用力、领导力等培训课程。奇舞团以开放和求贤的心态欢迎各种优秀人才关注和加入奇舞团。