转载自「信天创投」
译者按：去年年底开始，我开始非常关注和看好刚刚推出的MCP协议。随着近期Manus等各种智能体的大火，背后的MCP开始被大部分人所认识和重视。正好今天a16z这篇关于MCP的文章详细讨论了背后的原理、使用场景，现有的不足，以及未来的想象空间，非常适合阅读。
作者：a16z合伙人Yoko Li，主要负责企业和基础设施。
自 2023年OpenAI发布函数调用功能以来，我一直在思考如何开启智能体和工具使用的生态系统。随着基础模型变得越来越智能，智能体与外部工具、数据和API交互的能力却日益碎片化：开发人员需要为智能体运行和集成的每个系统都实现具有特殊业务逻辑的智能体。
很明显，需要有一个用于执行、数据获取和工具调用的标准接口。API曾是互联网第一个伟大的标准统一者，为软件通信创造了一种共享语言，但人工智能模型却缺乏类似的标准。
模型上下文协议（MCP）于2024年11月推出，作为一种潜在的解决方案，在开发者和人工智能社区中获得了极大关注。在本文中，我们将探讨MCP是什么，它如何改变人工智能与工具的交互方式，开发者已经用它构建了哪些应用，以及仍需解决的挑战。
-
高浓度的主流模型（如 DeepSeek 等）开发交流；
-
资源对接，与 API、云厂商、模型厂商直接交流反馈的机会；
-
好用、有趣的产品/案例，Founder Park 会主动做宣传。
01
什么是MCP？
MCP是一种开放协议，允许系统以一种可跨集成通用化的方式为AI模型提供上下文。该协议定义了AI模型如何调用外部工具、获取数据以及与服务进行交互。举个具体例子，以下是Resend MCP服务器与多个MCP客户端配合的工作方式。
MCP这个想法并不新鲜，MCP的灵感来源于LSP语言服务协议。在LSP中，当用户在编辑器中输入内容时，客户端会向语言服务器查询自动补全建议或诊断信息。
MCP超越LSP的地方在于其以智能体为中心的执行模型：LSP大多是被动响应的（根据用户输入响应来自IDE的请求），而MCP旨在支持自主AI工作流。基于上下文，智能体可以决定使用哪些工具、按什么顺序使用，以及如何将它们链接起来以完成任务。MCP还引入了人机协同功能，以便人工提供额外的数据并批准执行。
02
常见使用案例
借助合适的MCP服务器组合，用户可以将每个MCP客户端转变为一个“全能应用程序”。
以Cursor为例：虽然Cursor是一款代码编辑器，但它也是一个出色的MCP客户端。终端用户可以使用Slack MCP服务器将其转变为Slack客户端，使用Resend MCP服务器将其变为电子邮件发送器，使用Replicate MCP服务器将其变成图像生成器。更强大的利用MCP的方式是在一个客户端上安装多个服务器，以解锁新的工作流：用户可以安装服务器从Cursor生成前端UI，还可以让智能体使用图像生成MCP服务器为网站生成主图。
除了Cursor之外，如今大多数用例可以概括为以开发人员为中心、本地优先的工作流，或者使用大语言模型客户端的全新体验。
03
以开发人员为中心的工作流
对于每天沉浸在代码中的开发者来说，一种常见的想法是“我不想离开我的IDE去做事”。MCP服务器是实现这一梦想的好方法。
开发人员现在无需切换到Supabase去检查数据库状态，而可以使用Postgres MCP服务器来执行只读SQL命令，使用Upstash MCP服务器直接在IDE中创建和管理缓存索引。在迭代代码时，开发人员还可以利用Browsertools MCP让编码智能体访问实时环境，以获取反馈和调试。
Cursor代理如何使用Browsertools访问控制台日志和其他实时数据并更高效地进行调试的示例
除了与开发工具交互的工作流之外，MCP服务器还解锁了一种新用途，即通过抓取网页或根据文档自动生成MCP服务器，为编码智能体添加高度准确的上下文。开发者无需手动连接集成，而是可以直接从现有文档或API快速搭建MCP服务器，使智能体能够立即访问工具。这意味着开发人员花在样板代码上的时间更少，而实际使用工具的时间更多，无论是提取实时上下文、执行命令，还是动态扩展AI助手的功能。
04
全新体验
像Cursor这样的IDE并非唯一的MCP客户端，尽管由于MCP对技术用户的强大吸引力，它们受到了最多关注。对于非技术用户而言，Claude Desktop是一个绝佳的切入点，使MCP驱动的工具对普通大众来说更易于访问和使用。很快，我们可能会看到专门的MCP客户端出现，以执行业务为中心的任务（如客户支持、营销文案撰写、设计和图像编辑），因为这些领域与人工智能在模式识别和创意任务方面的优势紧密契合。
MCP客户端的设计及其支持的特定交互在塑造其功能方面起着至关重要的作用。例如，聊天应用程序不太可能包含矢量渲染画布，就像设计工具不太可能提供在远程计算机上执行代码的功能一样。最终，MCP客户端体验定义了整体MCP用户体验，而在这方面，我们还有很多有待挖掘的地方。
其中一个例子是Highlight如何实现@命令来调用其客户端上的任意MCP服务器。结果产生了一种新的用户体验模式，MCP客户端可以将生成的内容传输到任何选定的下游应用程序中。
Highlight的Notion MCP（插件）实现示例
另一个例子是Blender MCP服务器用例：现在，几乎不懂Blender的业余用户可以用自然语言描述他们想要构建的模型。随着社区为Unity和虚幻引擎等其他工具实现服务器，我们正在见证文本到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服务器的访问至关重要，它允许智能体按需动态选择和集成工具。
随着MCP应用率的不断增加，基础设施和工具将在使生态系统更具可扩展性、可靠性和可访问性方面发挥关键作用。像Mintlify、Stainless和Speakeasy等服务器生成工具正在减少创建与MCP兼容服务的难度，而像Cloudflare和Smithery等托管解决方案正在解决部署和扩展方面的挑战。与此同时，像Toolbase这样的连接管理平台开始简化本地优先的MCP密钥管理和代理。
05
未来的可能性
然而，我们目前仅处于原生智能体架构发展的早期阶段。尽管如今人们对MCP充满期待，但在使用MCP进行构建和发布时，仍有许多未解决的问题。
该协议的下一次迭代中需要解决的一些问题包括：
-
托管和多租户
MCP支持智能体与其工具之间的一对多关系，但多租户架构（如SaaS产品）需要支持多个用户同时访问共享的MCP服务器。默认使用远程服务器可能是短期内提高MCP服务器可访问性的一种解决方案，但许多企业也希望托管自己的MCP服务器，并分离数据和控制平台。
一个简化的工具链对于支持大规模MCP服务器的部署和维护至关重要，这将推动更广泛的应用。
-
认证
MCP目前没有定义客户端如何向服务器进行认证的标准身份验证机制，也没有提供MCP服务器在与第三方API交互时应如何安全管理和委托认证的框架。认证目前取决于各个实现和部署场景。实际上，到目前为止，MCP的应用似乎主要集中在本地集成上，在这种情况下，显式身份认证并不总是必需的。
对于远程MCP而言，更好的身份认证范式可能会是重大突破。从开发人员的角度来看，统一的方法应涵盖：
-
客户端认证（客户端-服务器交互的标准方法，如OAuth或API令牌）
-
工具身份验证（用于与第三方API进行认证的辅助函数或包装器）
-
多用户认证（适用于企业部署的租户感知认证）
-
授权
即使工具经过认证，谁应该被允许使用它，以及他们的权限应该有多细粒度呢？MCP缺乏内置的权限模型，因此访问控制基于会话级别，这意味着工具要么可访问，要么完全受限。虽然未来的授权机制可以实现更细粒度的控制，但目前的方法依赖于基于OAuth 2.1的授权流程，一旦认证通过，就会授予会话范围的访问权限。随着引入更多的智能体和工具，这会增加复杂性，因为每个智能体通常需要具有唯一授权凭据的自己的会话，从而导致基于会话的访问管理网络越来越复杂。
-
网关
随着MCP应用规模的扩大，网关可以作为一个集中层，用于认证、授权、流量管理和工具选择。类似于API网关，它将实施访问控制，将请求路由到正确的MCP服务器，处理负载均衡，并缓存响应以提高效率。这对于多租户环境尤为重要，因为不同的用户和智能体需要不同的权限。标准化的网关将简化客户端-服务器交互，提高安全性，并提供更好的可观察性，使MCP部署更具可扩展性和可管理性。
-
MCP服务器的可发现性和可用性
目前，查找和设置MCP服务器是一个手动过程，开发人员需要定位端点或脚本，配置认证，并确保服务器与客户端之间的兼容性。集成新服务器非常耗时，并且智能体无法动态发现或适应可用的服务器。
不过，根据Anthropic在上个月的AI工程师会议上的发言，似乎即将推出MCP服务器注册表和发现协议。这可能会开启MCP服务器应用的新阶段。
-
执行环境
大多数AI工作流需要按顺序调用多个工具，但MCP缺乏管理这些步骤的内置工作流概念。要求每个客户端都实现可恢复性和可重试性并不现实。尽管如今我们看到开发人员正在探索像Inngest这样的解决方案，但将有状态执行提升为一个重要概念将为大多数开发人员理清执行模型。
-
标准客户端体验
我们从开发人员社区听到的一个常见问题是，在构建MCP客户端时如何考虑工具选择：每个人都需要为工具实现自己的RAG吗？是否有一个等待标准化的层？
除了工具选择之外，调用工具也没有统一的UI/UX模式（我们看到了从斜杠命令到纯自然语言等各种方式）。一个用于工具发现、排序和执行的标准客户端层可以帮助创造更可预测的开发人员和用户体验。
-
调试
MCP服务器的开发人员经常发现，很难让同一个MCP服务器在不同客户端上轻松运行。通常情况下，每个MCP客户端都有自己的特点，客户端的跟踪信息要么缺失，要么难以找到，这使得调试MCP服务器成为一项极其困难的任务。随着世界开始构建更多远程优先的MCP服务器，需要一套新的工具来使本地和远程环境中的开发体验更加流畅。
06
AI工具的影响
MCP的开发体验让我想起了2010年代的API开发。这种范式新颖且令人兴奋，但工具链仍处于早期阶段。如果我们展望未来几年，如果MCP成为人工智能驱动工作流的事实标准，会发生什么呢？以下是一些预测：
-
开发优先型公司的竞争优势：开发优先型公司的竞争优势将从提供最佳的API设计，演变为提供供智能体使用的最佳工具集合。如果MCP能够自主发现工具，那么API和SDK的提供者需要确保他们的工具易于通过搜索发现，并且具有足够的差异化，以便智能体在特定任务中选择。这可能比人类开发人员所寻找的更加细致和具体得多。
-
新的定价模型：如果每个应用程序都成为MCP客户端，每个API都成为MCP服务器，可能会出现一种新的定价模型。智能体可能会根据速度、成本和相关性的综合因素更动态地选择工具。这可能会导致一个更由市场驱动的工具采用过程，选择性能最佳和最模块化的工具，而不是最广泛采用的工具。
-
文档的重要性：文档将成为MCP基础设施的关键部分，因为公司需要以清晰的、机器可读的格式（例如llms.txt）设计工具和API，并使MCP服务器成为基于现有文档的实际产物。
-
API的演变：仅靠API已经不够了，但它们可以是很好的起点。开发人员会发现，从API到工具的映射很少是一对一的。工具是一种更高层次的抽象，在任务执行时对智能体最有意义。例如，智能体可能不会简单地调用send_email()，而是选择draft_email_and_send()函数，该函数包含多个API调用，以最大限度地减少延迟。MCP服务器的设计将以场景和用例为中心，而不是以API为中心。
-
新的托管模式：如果每个软件默认都成为MCP客户端，将会出现一种新的托管模式，因为工作负载特征将与传统网站托管不同。每个客户端本质上都是多步骤的，需要可恢复性、重试和长时间运行任务管理等执行保证。托管提供商还需要在不同的MCP服务器之间进行实时负载均衡，以优化成本、延迟和性能，让智能体在任何给定时刻都能选择最有效的工具。
MCP已经在重塑AI智能体生态系统，但下一波进展将取决于我们如何应对这些基础性挑战。如果处理得当，MCP可能会成为人工智能与工具交互的默认接口，并开启新一代自主、多模态且深度集成的人工智能体验。
如果被广泛采用，MCP可能代表着工具构建、使用和货币化方式的转变。我们期待着看到市场将如何发展。今年将至关重要：我们会看到统一的MCP市场兴起吗？人工智能智能体的身份认证会变得无缝吗？多步骤执行能正式纳入协议吗？
原文链接：https://a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/
（文：Founder Park）