图片来源：Andreessen Horowitz

Z Highlights:

• MCP被视为可能成为AI与工具交互的默认接口，有望开启新一代自主、多模态、深度集成的智能体验。

• 随着MCP Client和server的快速发展，未来每个应用都有可能成为MCP Client，每个API都可能成为MCP Server，AI Agent将基于速度、成本和相关性动态选择最优工具。

• MCP正在推动工具从API向更高层抽象的“Agent友好型”形态演进，例如将多个API封装为draft_email_and_send()等更符合任务执行逻辑的调用方式。

• 类似Mintlify、Smithery和OpenTools的MCP工具市场正在形成，有望复制npm和RapidAPI的生态效应，为AI工具的发现与使用提供基础设施支撑。

Yoko Li是风投公司Andreessen Horowitz（a16z）的合伙人，专注于开发者工具、基础设施与人工智能领域，是推动AI原生工具生态的重要推动者之一。

自从OpenAI于2023年推出Function Calling功能以来，我一直在思考，如何才能真正激活一个agent与工具协同运作的生态系统。随着基础模型变得越来越智能，Agent与外部工具、数据和API的交互却日益碎片化：开发者需要为每一个系统单独编写特定的业务逻辑，才能让agent正常运行和集成。

很明显，我们迫切需要一个统一的标准接口（interface），来规范执行、数据获取和工具调用的方式。API曾是互联网时代的重要桥梁，为软件之间的通信建立了通用语言，而AI模型领域目前还缺乏类似的标准。

2024年11月推出的MCP（Model Context Protocol）在开发者（developer）和AI社区中快速引起关注，并有可能成为解决方案。在这篇文章中，我们将介绍什么是MCP，它如何改变AI与工具的交互方式，开发者已经基于它构建了哪些应用，以及目前仍需解决的挑战有哪些。

什么是MCP？

MCP是一个Open protocol（开放协议），它允许各类系统以可通用的方式向AI模型提供上下文情境。这个protocol定义了AI模型该如何调用外部工具、获取数据以及与服务进行交互。以Resend MCP server为例，它可以同时与多个MCP clients（MCP客户端）协同工作。

这个概念并不是全新的。MCP借鉴了LSP（Language Server Protocol，语言服务器协议）的设计思路。在LSP中，当用户在editor（编辑器）中输入内容时，客户端会向语言服务器请求自动补全建议或诊断信息。

图片来源：Andreessen Horowitz

相比LSP，MCP的创新之处在于它采用了以Agent为核心的执行模型，而LSP更多是被动地响应用户输入的请求，MCP能支持自主的AI workflows（AI工流程）。AI agent可以根据上下文自主判断使用哪些工具、以怎样的顺序组合使用，从而完成复杂任务。此外，MCP还引入了“人类参与环节”（human-in-the-loop），允许人类提供额外信息或对关键步骤进行确认与授权。

图片来源：Andreessen Horowitz

当前的热门案例

只要配置好合适的MCP servers，用户就可以将每一个MCP client变成一个“全能应用”（“everything app”）。

以Cursor为例，虽然它本质上是一个code editor，但它同时也是一个功能完善的MCP client。用户可以通过接入Slack MCP server，让Cursor变成一个Slack client；通过接入Resend MCP server，变成邮件发送工具；再接入Replicate MCP server，就能生成图像。更强大的用法是：在同一个客户端上安装多个MCP server，解锁更复杂的操作流程。例如，用户可以在Cursor上安装一个MCP server，用于生成front-end UI（前端界面），同时让agent调用另一个图像生成的MCP server，为网站生成主视觉图像。

除了Cursor，目前的大多数用例可以归为两类：一是以开发者为中心、本地优先的工作流；二是基于LLM客户端打造的全新体验。

开发者中心的工作流

对每天与代码打交道的开发者来说，常见的诉求是：“我不想离开我的IDE（Integrated Development Environment集成开发环境）就能完成某个任务”。MCP server正是实现这个目标的有效方式。

开发者现在无需切换到Supabase查看数据库状态，而是可以直接在IDE中使用Postgres MCP server执行read-only SQL commands（只读SQL命令），同时利用Upstash MCP server创建和管理缓存索引。在代码迭代过程中，开发者还可以借助Browsertools MCP，为coding agent提供实时运行环境，用于反馈和调试。

除了与开发工具交互的工作流，MCP server还解锁了一个新用途：通过爬取网页内容或基于文档自动生成MCP server，为coding agent提供高度精准的上下文信息。开发者无需手动配置集成，而是可以直接基于现有文档或API快速生成MCP server，使工具能即时供AI agents调用。这意味着开发者可以减少重复性boilerplate（样板代码的编写），把更多时间用在实际使用工具上——比如获取实时上下文、执行指令，还是即时扩展AI助手的功能。

图片来源：Andreessen Horowitz

全新体验场景

虽然像Cursor这样的IDE是目前最受关注的MCP客户端，但它并不是唯一的选择。这种关注主要来自技术用户的广泛兴趣。对非技术用户来说，Claude Desktop是一个很好的入门平台，它让基于MCP的工具更加易用、也更适合大众。未来，我们很可能会看到面向业务场景的专业MCP client陆续出现，比如客户支持、营销文案撰写、平面设计和图像编辑等领域——这些都是AI在图案识别和创意任务上最擅长的方向。

一个MCP client的设计方式，以及它支持的具体交互形式，将直接决定它的功能边界。例如，一个聊天应用通常不会内嵌矢量绘图画布，而一个设计工具也不太可能具备远程执行代码的能力。最终，MCP client本身的交互设计和能力架构将决定MCP的整体用户体验。而这一方面仍有大量潜力待挖掘。

一个典型的例子是Highlight的实现方式：它通过@ command来调用客户端上的任意MCP server。这带来了一个全新的用户体验模式——用户可以将AI生成的内容直接传输到任意下游应用中，实现自然、高效的协作流程。

图片来源：Andreessen Horowitz

另一个例子是Blender的MCP server：现在，即使是不懂Blender的新手用户，也能通过自然语言描述想要构建的模型，AI会帮助他们生成对应的3D内容。我们已经看到“文本生成3D模型”这一流程正在加速落地，并逐步扩展到Unity、Unreal Engine等其他工具中。

图片来源：Andreessen Horowitz

虽然我们通常将MCP理解为“clients + servers”的模式，但随着协议的不断演进，MCP正在逐步形成一个完整的生态系统。下图展示的是当前最活跃的市场领域，尽管还有许多空白区域尚待开发。考虑到MCP仍处于早期阶段，我们期待随着市场的成长，看到更多参与者加入生态。（我们将在下一节探讨其中一些未来的可能性。）

图片来源：Andreessen Horowitz

在MCP client方面，目前大多数优质客户端仍以coding-centric（编程开发）为核心，这并不令人意外——开发者往往是新技术的第一批尝试者。但随着协议的成熟，我们也预期会出现更多面向商业场景的客户端。

在MCP server方面，现阶段的MCP server大多是“local first（本地优先）”的架构，且由单一开发者或小团队搭建。这主要是因为当前MCP协议仅支持基于SSE（服务器发送事件）和指令的连接方式。不过，随着生态向远程连接和支持Streamable HTTP协议的发展，MCP server的部署和使用将更加广泛。

与此同时，一批新的MCP市场和server-hosting（服务器托管平台）也在快速崛起，使MCP server的发现与使用更加便捷。比如Mintlify的mcpt、Smithery和OpenTools等平台，正在帮助开发者更容易地发现、分享和贡献新的MCP server——正如当年的npm彻底改变了JavaScript package management，RapidAPI简化了API的发现方式。这一层平台将成为标准化接入高质量MCP server的关键，让AI agent能够按需动态选择并集成合适的工具。

随着MCP被更广泛采纳，相关基础设施和工具也将变得越来越重要，有助于整个生态实现更高的可扩展性、稳定性和可用性。Mintlify、Stainless和Speakeasy等工具正在降低创建兼容MCP的服务的门槛，而Cloudflare、Smithery等托管平台则在解决部署与扩展的问题。同时，Toolbase等连接管理平台也开始优化本地优先的密钥管理和代理流程，为开发者带来更流畅的接入体验。

未来的可能性

尽管MCP如今备受关注，但整个“原生agent架构”（agent-native architecture）仍处于发展的早期阶段。在实际构建和部署MCP的过程中仍有许多关键问题尚未解决。下一阶段协议的迭代需要重点突破的几个方向包括：

托管与多租户架构（multi-tenancy)

当前MCP支持“一个agent对多个工具”的使用关系，但在实际的多租户架构中（例如SaaS产品），则需要支持多个用户同时访问同一个MCP server。短期内，将MCP server默认部署为远程服务可能是提升可用性的解决方案之一。但对于许多企业用户来说，他们更希望能自行托管MCP server，并将数据层与控制层分离，保障安全与合规。

因此，打造一整套标准化工具链(streamlined toolchain)，以支持MCP server的大规模部署与维护，将是推动其广泛应用的关键。

身份验证机制（authentication）

当前MCP协议尚未定义统一的身份验证机制，客户端如何验证身份、服务器如何安全地管理与授权对第三方API的访问，全部依赖各自的具体实现和部署场景。在实践中，MCP目前多用于本地集成场景（localinteragtion），往往不需要复杂的验证流程。

但若要在远程部署场景下广泛推广，构建一个完善的认证体系将至关重要。对开发者而言，一个理想的统一认证方式应涵盖：客户端身份验证：使用OAuth或API Token等标准方式，完成客户端与服务器之间的身份确认；工具认证机制：提供便捷的辅助函数（helper functions）或封装组件（wrappers），以安全接入第三方API；多用户验证：面向企业级部署，实现支持租户隔离（tenant-aware authentication）的多用户身份验证。

权限控制机制

即使某个工具通过了身份验证，但是谁可以使用它？可以使用到什么程度？这些都需要更加细致的权限控制。但当前MCP尚未内置权限模型，只能在访问权限局限于session level，意味着要么工具完全开放，要么完全禁用。

未来的授权机制如果能支持更细致的权限控制，将极大提升灵活性。目前的做法通常依赖OAuth 2.1-based授权流程，一旦认证成功，整个session（会话过程）的访问权限便全面开放。

当agent和工具数量不断增加，这种方式会变得越来越复杂——每个agent通常需要独立的session和专属的权限凭证（authorization credentials），导致权限管理逐渐形成复杂的“蜘蛛网式结构”。

Gateway（网关，连接MCP成lient与多个server之间的中介组件，负责统一管理连接、任务分发与安全认证。）

随着MCP的广泛应用，gateway将成为关键的中间层，统一管理认证、权限控制、流量调度和工具选择。它的作用类似于传统API gatemways：可以强制执行访问控制、将请求路由到正确的MCP server、实现负载均衡，并缓存响应以提高效率。

这对多租户环境尤为重要，不同用户和agents往往拥有不同的访问权限。一个标准化的MCP gateway将简化客户端与服务器之间的交互（client-server interactions），提升系统安全性、可观察性和可扩展性，从而让MCP的部署更易于管理。

MCP server的发现与可用性

目前，要找到并配置MCP服务器仍是一个手动过程。开发者需要自行查找服务地址（endpoint）或脚本（scripts），配置认证信息，并确保客户端与服务器兼容。这不仅耗时，还让AI agents无法动态发现或适配可用服务器。

不过，根据Anthropic在上个月AI工程师大会（AI engineer conference）上的演讲来看，MCP server registry and discovery protocol（MCP注册与发现协议）即将推出。这将为MCP server的下一阶段普及打开大门。

执行环境（Execution Environment）

大多数AI workflow需要依次调用多个工具，但MCP目前还没有内建工作流管理机制。要想每个客户端都能独立地实现中断恢复、失败重试等功能并不现实。

虽然现在有开发者尝试使用Inngest等工具来实现流程控制，但如果将“有状态执行”（stateful execution）作为MCP协议中的首要要素（first- class concept），将极大优化执行模型（execution model），使之更清晰稳定。

统一的客户端体验（Standard Client Experience）

许多开发者关心一个问题：在构建MCP clients时，如何进行工具选择？是否每个人都需要为工具构建一套自己的RAG（Retrieval-Augmented Generation，检索增强生成）逻辑？是否存在一个可以被标准化的“中间层”？

此外，目前也没有统一的工具调用界面和UI/UX patterns（交互方式）：有的使用slash commands，有的使用自然语言指令。一个标准化的客户端层级，可以涵盖工具的发现、排序和调用，从而为开发者和终端用户带来更一致、更可预测的使用体验。

调试机制（Debugging）

MCP servers的开发者普遍反馈：让同一个MCP server兼容多个客户端非常困难。各个客户端实现存在差异，且客户端的trace（执行记录）要么缺失、要么难以定位，这让debugging MCP servers变得异常困难。

随着越来越多远程优先的MCP servers（remote-first MCP servers）开始部署，我们需要一整套新的开发工具，帮助开发者在本地与远程环境中更高效地调试、测试和管理MCP服务。

AI工具生态的潜在影响

MCP的开发体验让我想起了2010年代的API发展初期。这个新范式令人振奋，但当时的toolchains仍处于早期阶段。如果我们将时间快进几年，假设MCP已经成为了AI驱动工作流（AI- powered workflows），会发生什么？以下是几个预测：

以开发者为核心的公司将面临全新竞争维度：不仅要设计出优秀的API，还要打造一整套适合agents调用的高质量工具。如果未来MCP能自主发现工具，API与SDK的提供方就必须确保自己的工具是能被轻松检索的，并且具有足够的独特性，好被agent选中任执行特定的任务。相比人类开发者的判断标准，agent的选择会更细化和具体。

新的定价模式可能出现：如果每个应用都变成了MCP client、每个API都变成了MCP server，AI agent将根据速度、成本和任务相关性动态选择工具。这可能催生出一种更以市场为驱动的工具选择机制：不是选择最广泛的，而是选性能最优、模块化程度最高的。

文档将成为MCP infrastructure（基础设施的关键一环）：公司需要以清晰、机器可读的格式（如llms.txt）来设计工具和API，并基于现有文档生成MCP servers，使其成为de facto artifact（默认的开发产物）。

API不再是终点，而是起点：开发者将逐渐意识到，API与工具之间的关系并非一一对应。工具是一种更高层级的抽象，更符合agents执行任务时的逻辑。例如，agent不再只是调用send_email()，而是选择draft_email_and_send()这样的复合函数，用更少步骤完成任务、降低延迟。因此，未来MCP server的设计将以“使用场景”（scenario）和“任务需求”（use-case）为核心，而非单纯围绕API展开。

托管模式（Hosting mode）也将迎来变化：如果每款软件默认就是MCP client，它所需的workload characteristics（计算负载）将与传统website hosting（网页托管）完全不同。每个client都涉及多步骤的交互流程，需要支持任务可恢复、自动重试、长时间运行等执行保障。同时，hosting providers（托管服务商）还需要在多个MCP servers间实现real-time load balancing（实时负载均衡），以优化成本、延迟和性能，让agent始终能选用最优工具。

如今，MCP已在重塑AI-agent生态，而下一波变革将取决于我们如何解决这些底层挑战。如果推进得当，MCP有望成为AI与工具交互的默认接口，开启一代具备自主性、多模态、深度集成的AI新体验。一旦被广泛采纳，MCP将彻底改变工具的构建、使用与商业化方式。

我们非常期待它的市场走向。今年将是MCP的关键一年：我们是否会看到统一的MCP市场平台崛起？身份验证能否对AI agents实现真正的无缝支持？多步骤执行是否会正式被纳入protocol（协议标准）？

原文：A Deep Dive Into MCP and the Future of AI Tooling

https://a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/

编译：Cissy Zhao，用创意点亮世界，用探索定义自我。

请注意，本文编译自文末载明的原始链接，不代表Z Potentials立场。如果您对本文有任何想法或见解，欢迎在评论区留言互动探讨。

Z Potentials将继续提供更多关于AI、机器人、全球化等领域的优质内容。我们诚邀对未来充满憧憬的您加入我们的社群，与我们共同分享、学习、成长。

——-

（文：Z Potentials）