MCP 的现状和未来

题外话

安全行业很多年没有新叙事了，AI 时代将大量没有受过系统计算机科学训练的伙计引入进来，不仅所有漏洞会被重新实现一遍（参考前端工程师写的后端框架 bushi），新技术的引入还会带来新的安全问题，从架构到方案到治理，外加 AI 加持的安全能力，这些都是安全从业人员的新机会。

前言

自 OpenAI 于 2023 年推出 function calling 功能以来，我一直在思考如何真正释放 Agent 与工具协同使用的生态潜力。随着基础模型不断变得更智能，Agent 与外部工具、数据、API 的交互也变得越来越碎片化：开发者需要针对每一个系统编写特定业务逻辑，使 Agent 能够适配和集成这些系统。

我们迫切需要一个标准化接口，用于执行操作、获取数据与调用工具。API 曾是互联网时代最伟大的统一工具：为软件间通信创建了共享语言，但 AI 模型尚未拥有这样的标准。

Model Context Protocol（MCP）于 2024 年 11 月提出，迅速在开发者和 AI 社区中获得关注，被视为潜在的解决方案。本文将深入探讨 MCP 是什么、它如何改变 AI 与工具的交互方式、开发者目前如何使用 MCP，以及 MCP 仍面临的挑战。

什么是 MCP？

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

以下是 Resend MCP 服务器与多个 MCP 客户端交互的实际示例。

MCP 的灵感部分来自于 LSP（语言服务器协议）。在 LSP 中，当用户在编辑器中输入内容时，客户端会向语言服务器发起请求，获取补全建议或诊断信息。

然而，MCP 超越了 LSP 的被动响应模型，采用了以 Agent 为核心的执行方式：LSP 多是响应用户输入，而 MCP 支持 AI 自主工作流。基于上下文，AI Agent 可以自主决定使用哪些工具、如何组合调用、以完成特定任务。此外，MCP 还引入了“人类参与环节”，让用户可补充数据或批准执行操作。

当前的热门应用场景

只要配置好 MCP 服务器，用户几乎可以将任何 MCP 客户端变成“全能应用”。

以 Cursor 为例：虽然它本质上是一个代码编辑器，但也是一个功能强大的 MCP 客户端。最终用户可以通过接入 Slack MCP 服务器，将其变为 Slack 客户端；借助 Resend MCP 服务器，实现发送邮件功能；利用 Replicate MCP 服务器，还能生成图像。更进一步的玩法是，在一个客户端中部署多个服务器以解锁全新工作流：例如，用户可以通过 MCP 生成前端界面，同时调用图像生成服务器来创建页面主图。

除了 Cursor，大部分 MCP 用例目前可分为两类：

• 开发者导向的、本地优先的工作流
• 基于大语言模型客户端的全新体验

开发者导向的工作流

很多开发者日常都在 IDE 中工作，常常会说：“我不想为了做某件事离开编辑器。” MCP 正是实现这一愿景的理想方案。

现在，开发者无需切换到 Supabase 查看数据库状态，而是可以直接通过 Postgres MCP 服务器 执行只读 SQL 查询，或用 Upstash MCP 服务器 来管理缓存索引。当进行代码调试时，还可以通过 Browsertools MCP 为 Agent 赋能，接入浏览器运行环境，实时反馈与 debugging。

MCP 服务器还解锁了给编码Agent添加上下文的能力。例如，Agent可以借助 Firecrawl MCP 服务器 抓取网页信息，或通过 Mintlify 的 MCP 生成器 根据文档自动构建 MCP 服务器。不再需要手动集成，只需引用现有文档或 API，即可快速让工具接入 AI Agent。这代表开发者能将更多时间花在使用工具，而非样板代码上。

全新用户体验

尽管 MCP 客户端中 IDE 占主导地位，但这并非唯一的使用场景。对于非技术用户，Claude Desktop 是一个很好的切入点，它让 MCP 工具更加亲民。未来我们很可能会看到更多面向业务的 MCP 客户端涌现，如客服、营销文案、设计和图像处理工具等，这些领域非常适合 AI 的模式识别和创意能力。

MCP 客户端的设计以及其所支持的交互类型，在很大程度上决定了其能力边界。例如，一个聊天工具不太可能内置矢量图形渲染功能，而设计工具也不会支持在服务器上执行代码。因此，MCP 客户端的体验定义了整个 MCP 用户体验的天花板。

一个值得关注的例子是 Highlight 推出的 @command，可在客户端中直接调用任意 MCP 服务器，形成了一个新的人机交互范式：生成内容直接流转到下游应用中。

还有 Blender MCP 服务器 的案例：即使是完全不会用 Blender 的用户，也可以通过自然语言描述想要的模型，并即时生成。我们正在亲眼见证“文本转 3D”从概念变为现实，社区正在为 Unity、Unreal 等工具实现类似服务器。

尽管目前我们谈论的是“服务器”和“客户端”，但 MCP 生态正随着协议演化不断成型。下图展示了当前最活跃的领域，虽然仍有不少空白，但我们期待更多参与者加入这个生态。

未来展望

尽管 MCP 的发展令人兴奋，但它仍处于早期阶段，仍有大量基础问题待解。接下来几个关键点，将是推动协议演化的核心：

托管与多租户

当前 MCP 主要支持“一对多”的Agent对工具关系，但如果要支持 SaaS 级的“多用户访问同一个 MCP 服务器”，就需要支持多租户架构。虽然默认启用远程服务器是一个可行的短期解法，但大企业往往希望在自有环境中部署 MCP 服务器，实现数据与控制 plane 的隔离。

一个便捷、标准化的工具链将成为推动企业级 MCP 部署的关键。

认证机制

目前 MCP 协议并未定义客户端与服务器之间的认证流程，也没有为调用第三方 API 提供通用的安全认证机制。实际情况是，当前大多数 MCP 部署偏向本地环境，不太依赖显式认证。

一个健壮的认证体系应包含：

• 客户端认证（如 OAuth、API Token）
• 工具层认证（第三方 API 的认证封装）
• 多用户认证（支持多租户部署）

授权与访问控制

即使完成了认证，MCP 也缺乏细粒度的访问控制机制。当前的权限模型仍是会话级的，要么完全可访问，要么完全受限。这在多 Agent、多工具场景下会迅速变得复杂。虽然目前 MCP 倾向使用 OAuth 2.1 授权流程，但更细粒度的权限模型仍待开发。

Gateway 网关机制

借鉴 API Gateway 的概念，未来 MCP 应引入统一网关，用于认证、授权、流量控制与工具路由等核心任务，特别适用于多租户环境。标准化的 MCP 网关能提升安全性、性能与可维护性。

Server 发现与易用性

目前开发者需手动查找 MCP 服务器、配置认证、测试兼容性，过程繁琐，AI Agent 也难以自动发现或适配。根据 Anthropic 的议题，MCP 注册中心和发现协议正在酝酿中，这有望大幅提升服务器的发现与接入效率。

执行环境与工作流管理

现实中的 AI 工作流往往涉及多个连续步骤，而 MCP 尚无内建的工作流管理机制。开发者需额外实现状态管理、重试机制、任务恢复等功能。当前一些团队正借助 Inngest 实现工作流处理。将有状态执行提升为最高优先级，是 MCP 可用性的关键提升。

标准客户端体验

一个常见问题是：构建 MCP 客户端时如何选择工具？每个客户端都需要自建 RAG 吗？是否存在更标准的工具发现与调用层？

此外，MCP 工具的调用方式也缺乏统一：有的使用斜杠命令，有的靠自然语言。一个统一的客户端工具调用 UI 层将极大优化开发与用户体验。

调试能力

由于 MCP 客户端差异较大，开发者常常发现一个 MCP 服务器难以兼容多个客户端，加上客户端日志和追踪不完善，导致调试变得异常困难。随着远程服务器的普及，开发者需要全新的工具链来调试本地与远程环境中的 MCP 服务。

AI 工具链的未来

MCP 的开发体验让我想起了 2010 年代的 API 开发，全新范式，工具生态仍在早期。如果未来 MCP 成为 AI 工作流的默认标准，可能会出现以下趋势：

• 开发者公司的竞争优势将不再只是 API 设计，而是提供最适合 AI Agent 使用的工具集合。
• 工具的选择将市场化：Agent 根据速度、成本与效果动态选择工具，形成新的定价模式。
• 文档将成为基础设施：清晰、结构化、机器可读的文档将是 MCP 工具发现的基础设施。
• API 不再是终点，而是构建 MCP 工具的起点。
• 托管方式将变革：AI Agent 多步骤调用特性将倒逼托管平台支持持久化执行、任务恢复与高效调度。

MCP 已在悄然重塑 AI Agent 生态。而下一轮浪潮，将由我们如何解决这些底层挑战所决定。如果做得好，MCP 有望成为 AI 与工具之间的默认接口，解锁下一代的自动化、多模态、深度集成 AI 体验。

以上内容编译自 a16z