全球知名投资机构 a16z 最近发布了一篇博客文章，深度介绍了 MCP 以及 AI 工具生态的未来，文章主要探讨了 MCP 是什么，它如何改变 AI 与工具的交互方式，开发者已经在用它构建什么，以及当前仍待解决的问题。
特工宇宙将原文翻译如下。
值得注意的是，阅读此文章需要一定的前置知识。尽管我们已经尽可能翻译的通俗易懂，但阅读起来仍可能存在一定门槛。对于想要更详细了解 MCP 及 Agent 的读者，可以加入我们的 ima 知识库，其中我们精选了一些资料免费共享给大家。
自从 OpenAI 于 2023 年推出函数调用（Function Calling）以来，我一直在思考，一个围绕 Agent 与工具使用（Tool Use）的生态将是如何的？随着基础模型的智能程度不断提高，Agent 与外部工具、数据和 API 的交互能力却越来越碎片化：开发者需要为每一个 Agent 所使用的系统框架和工具集成，编写特定的业务逻辑。
很显然，我们需要一个用于执行、数据获取与工具调用的标准接口。API 曾是互联网的第一个“秦始皇”——它为软件之间的通信创造了一种通用语言——但对于 AI 模型而言，我们还缺乏这样一个这样的标准。
Model Context Protocol（MCP，模型上下文协议）于 2024 年 11 月首次发布，迅速在开发者和 AI 社区中获得了广泛关注，有成为这一标准的苗头。
什么是 MCP？
MCP 是一个开放协议，允许外部其他系统以一种通用的方式，向 AI 模型提供上下文（Context）。该协议定义了 AI 模型如何调用外部工具、获取数据和与外部其他服务交互。
注：我们曾在 什么是 MCP，Agent 通信协议的未来如何又如何？这篇文章中有介绍过：
MCP 像一个“转接头”或者“通用插座”，它的作用是让各种不同的外部服务（比如 Google Drive、GitHub、Slack、本地文件系统等）通过一个标准化的接口与 AI 模型对接。
这样，开发者只需要按照 MCP 的规范开发一次“插头”（MCP 服务器），就可以让任何支持 MCP 的模型（MCP 客户端）使用，不用为每个模型单独适配。
下面是一个具体的例子，Resend 的 MCP server（服务端）如何与多个 MCP client（客户端）协同工作。
MCP 设计的这个想法其实并不新颖；其借鉴了 LSP（语言服务器协议）。在 LSP 中，当用户在代码编辑器中输入内容时，client 会查询代码语言服务器以获取代码自动补全建议或诊断信息。
但 MCP 的强大之处在于其是以 Agent 为核心的执行模型：LSP 主要是被动式的（基于用户输入对 IDE 的请求做出响应），而 MCP 的设计上支持自主 AI Workflow。
基于上下文信息，Agent 可以决定使用哪些工具、以什么顺序调用它们，并将它们组合起来完成任务。MCP 还引入了人类参与机制（human-in-the-loop），让人类可以提供额外的数据，并同意任务的执行。
当下热门 Use Cases
只要拥有恰当的 MCP server（服务端），用户就可以把每一个 MCP client（客户端）变成“万能应用”。
以 Cursor 为例：虽然它是一个代码编辑器，但它也是一个很好的 MCP client。终端用户可以将其变成 Slack client（使用 Slack MCP server）、邮件发送器（使用 Resend MCP server）或图像生成器（使用 Replicate MCP server）。
更强大的使用方式是：在一个 client 上安装多个 server 来解锁新的工作流——例如，用户可以安装一个 server 来从 Cursor 生成前端 UI，同时请 Agent 使用图像生成 MCP server 来生成网页的头图。
除了 Cursor，当前大多数 MCP 的用例可以归为两类：以软件开发为中心，本地优先的工作流，和基于 LLM 客户端的全新体验。
开发为中心的工作流（Dev-centric workflows）
对每天都沉浸在代码世界中的开发者来说，一个常见的想法是：“我不想为了做某件事而离开我的 IDE。” MCP 服务器是实现这一梦想的绝佳方式。
不需要切换到 Supabase 来查看数据库状态，开发者可以直接使用 Postgres MCP server 来执行只读 SQL 命令，或使用 Upstash MCP server 来创建或管理缓存索引。代码迭代过程中，还可以利用 Browsertools MCP 给 Agent 提供访问实时环境的权限，以获取反馈和调试信息。
Cursor Agent 使用 Browsertools 获取控制台日志和其他实时数据并进行调试的示意图
除了与开发者工具交互的工作流之外，MCP 服务器的一个新能力是为编程 Agent 提供更准确的上下文信息，例如通过抓取网页或基于文档自动生成 MCP 服务器。
开发者无需手动配置集成，而是可以直接从现有文档或 API 中快速启动 MCP 服务器，使 Agent 能够即时访问这些工具。这样可以显著减少编写模板代码的时间，更多时间花在使用工具上——无论是拉取实时上下文、执行命令，还是动态扩展 AI 助手能力。
全新体验（Net-new experiences）
尽管像 Cursor 这样的 IDE 因 MCP 对技术用户的强烈吸引而受到最多关注，但它们并不是唯一可用的 MCP 客户端。对于非技术用户来说，Claude Desktop 是很好的入门方式，让 MCP 驱动的工具更易于普通用户使用。
未来我们可能会看到面向客户支持、市场营销文案、设计和图像编辑等业务的，垂直专业的 MCP 客户端的出现——这些领域正是 AI 擅长的地方。
MCP 客户端的设计及其支持的特定交互在塑造其功能方面起着至关重要的作用。例如，聊天应用通常不会包含矢量渲染画布，而设计工具通常也不会提供远程的机器代码执行功能。最终，MCP 客户端的体验定义了整个 MCP 的用户体验——而在这一方面，我们还有很多可以探索的空间。
例如，Highlight 实现了一个「@命令」来调用客户端上的任意 MCP 服务。这个新型 UX 模式允许 MCP 服务端将生成的内容传输至任何下游应用。
Highlight 实现 Notion MCP 插件的示意图
另一个例子是 Blender MCP server 的用法：现在，即使是对 Blender 几乎不熟悉的普通用户，也可以用自然语言描述他们想要构建的模型。随着社区的开发者正为 Unity 和 Unreal 等其他工具实现 MCP server，我们正在见证 text-to-3D 工作流的实时进步。
使用 Claude Desktop 与 Blender MCP server 交互的示意图
MCP 生态
虽然目前我们主要谈的是 server 和 client，但随着协议演化，MCP 生态的轮廓也逐渐清晰。以下是目前活跃领域的市场地图，虽然还有很多空白，但考虑到 MCP 仍处于早期阶段，随着市场发展，我们期待更多玩家加入其中。
关于 MCP 客户端，目前大多数高质量的 client 仍是代码相关的工具，这并不意外，毕竟开发者是新技术的早期采用者。但随着协议的成熟，我们预期将看到更多业务为中心的 client。
而 MCP server 目前多是本地优先、单用户设计。这部分原因是 MCP 目前仅支持 SSE 和命令式连接。然而，随着远程 MCP 支持的增强，以及 MCP 采用可流式 HTTP 传输协议，我们预期 MCP server 的使用会更加广泛。
此外，还有一波新的 MCP 市场和 server 托管解决方案正在兴起，以实现 MCP server 的发现能力。像 Mintlify 的 mcpt、Smithery 和 OpenTools 这样的市场，让开发者可以更容易发现、共享并贡献新的 MCP server——这就像 npm 改变了 JavaScript 包管理，或 RapidAPI 拓展了 API 的发现那样。这一层将是标准化高质量 MCP server 接入的关键，允许 Agent 动态选择并整合所需工具。
未来的可能性
尽管我们对 MCP 今天的表现感到兴奋，但这仅仅是 Agent 原生架构发展的初始阶段。在构建和部署 MCP 时仍存在许多待解问题：
托管与多租户支持
MCP 支持 AI Agent 与工具之间的一对多关系，但对于 SaaS 产品等多租户架构，还需要支持多个用户同时访问共享的 MCP server。近期解决方案可能是默认采用远程服务器，使 MCP 服务器更易于访问，但许多企业同样希望能够托管自己的 MCP 服务器并实现数据层面和控制层面的分离。
认证
MCP 目前没有定义统一的认证机制来规范 client 如何与 server 进行身份验证，也没有框架指导 server 如何安全管理与第三方 API 的交互身份认证。目前，身份验证由每个实现和部署场景自行决定。实际上，MCP 的应用多在本地集成中，并未严格要求认证。
要实现远程 MCP 的广泛应用，统一的身份验证框架将是重要解锁因素。理想的认证方案应该覆盖：
Client 认证：标准方式如 OAuth 或 API token
工具认证：与第三方 API 交互时的辅助认证封装
多用户认证：面向企业部署的租户级认证
授权
即便工具已通过身份验证，谁有权限使用它、权限的颗粒度多细仍是问题。MCP 当前没有内建权限模型，访问控制是基于 session 的——即工具要么可访问，要么完全受限。虽然当前大多采用 OAuth 2.1 的授权流程，但随着更多 Agent 和工具的加入，管理不同 session 的授权 token 变得愈发复杂。
网关
随着 MCP 规模的发展，一个 MCP 网关可成为集中式层，统一处理认证、授权、流量管理和工具选择。就像 API 网关一样，它可以加强访问控制、请求路由、负载均衡和缓存，特别适用于多租户环境，确保不同用户和 Agent 拥有不同权限。网关将极大简化 client-server 交互流程，提高安全性和可观测性，从而提升 MCP 部署的可扩展性和可管理性。
MCP 服务器的可发现性与易用性
目前，寻找和配置 MCP server 是一个手动过程，开发者需手动定位端点或脚本、配置身份认证，并确保 server 与 client 的兼容性。集成新 server 需要大量时间，Agent 也无法动态发现可用 server 或适应其能力。
不过，根据上月 Anthropic 在 AI 工程师大会上的演讲，MCP server 注册表和发现协议即将推出，这可能会推动 MCP server 进入下一个应用阶段。
执行环境
大多数 AI 工作流都需要顺序执行多个工具调用——但 MCP 并未内建工作流管理概念。目前，每个 client 都需要自行实现流程恢复、重试等机制。尽管目前开发者正在尝试使用 Inngest 等解决方案来实现这一功能，但将有状态执行提升为一级概念，将能为大多数开发者简化执行模型。
标准客户端体验
开发者社区常问的问题是：构建 MCP client 时，如何实现工具选择？是否每个 client 都需要实现自己的工具 RAG 系统，还是说这一层可以被标准化？
此外，在调用工具的 UI/UX 上也没有统一的设计模式（目前从斜杠命令到纯自然语言的方式都有）。一个用于工具发现、排序和执行的标准客户端层将帮助建立更加一致的开发和用户体验。
调试工具
MCP server 的开发者常发现，要让同一个 server 在不同 client 上兼容运行是非常困难的。通常，每个 MCP client 都有自己的特色，而客户端的 trace 数据不是缺失就是难以获取，导致调试 MCP server 十分痛苦。随着越来越多的远程优先 MCP server 在被构建，一整套新的调试工具将是开发体验的关键。
AI 工具化的影响
MCP 的开发体验让我想起了 2010 年代的 API 开发。虽然范式新颖又令人兴奋，但工具链仍处于早期阶段。如果我们快进几年，假设 MCP 成为 AI 工作流的事实标准，会发生什么？
一些预测：
1. 开发者导向公司的竞争优势将从“最好的 API 设计”转向“最好的工具集合供 Agent 使用”。如果 MCP 实现自主发现工具，那么 API 和 SDK 提供商需要让他们的工具更易被搜索发现，且对 Agent 足够有吸引力。
2. 新的定价模式可能出现：如果每个 App 都成为 MCP client、每个 API 都成为 MCP server，Agent 将动态地基于速度、成本和相关性选择工具，带来更市场化的工具采用流程。
3. 文档将成为 MCP 基础设施的核心，企业需以机器可读的方式（如 llms.txt）设计工具与 API，并基于现有文档默认生成 MCP server。
4. 仅有 API 不再足够，它们可以是起点，但 Agent 需要的是更高层的“工具”抽象。MCP server 的设计将以场景与用例为中心，而非仅仅反映 API 结构。
5. 新的托管模式将涌现：MCP client 的任务具有多步骤，需要可恢复、重试，长时间运行管理。托管服务需支持实时负载均衡，优化成本、延迟与性能，便于 Agent 动态选择最佳工具。
MCP 正在重塑 Agent 生态，但下一步如何发展，将取决于我们能否解决这些底层问题。如果做对了，MCP 可能成为 AI 与工具之间的默认接口，开启新一代自动化、多模态、深度集成的 AI 体验。
如果被广泛采用，MCP 将改变工具的构建、使用与变现方式。
2025 年将是关键一年：我们是否会看到统一的 MCP 市场出现？认证是否能变得无缝对接？多步骤执行是否能正式纳入协议？
