模型上下文协议(MCP)的现状、问题与掘金机会

模型上下文协议(Model Context Protocol, 简称 MCP)是一种正在迅速普及的协议,它允许模型客户端与外部服务和工具服务器进行交互,让模型客户端不再局限于对话和信息检索,而是能够采取实际行动,比如发送邮件、部署代码、或发布文章等,我在周刊的 30、35、43、44、45 期都曾介绍过。关于 MCP 介绍的文章已经很多了,本篇不再赘述,这里我想重点谈谈深度使用下来发现的一些问题,以及这些问题带来的潜在掘金机会。

有哪些问题

MCP 作为一个开放标准协议,任意的模型客户端都可以选择去支持,Sever 端也可以一次构建多处分发,节省开发者的精力,比起模型厂商各自提供的 function calling 或 tool use 确实方便多了,我从去年刚发布就在关注使用,但长期使用下来仍然存在一些问题。

无谓的复杂性

有点为了标准而标准(这也是新进者应对现存守成者的常见策略,可以理解),如果想让 LLM 使用现有服务,为什么不让 LLM 直接调用它的 API 呢,利用成熟的 RESTful 和 Swagger/OpenAPI 规范生成工具所需的 JSON schema 不是更简洁( 比如使用 agents.json),专门新建 MCP Server 包装现有的 API 显得多此一举,因此也延伸出新的安全性和访问权限的问题。

安全性

创建时通过注册与合法MCP Server相似或相同的名称,欺骗用户安装恶意Server;代码注入攻击发生在MCP Server的源代码或配置文件中。运行时多个工具可能使用相同或相似的名称,导致在选择工具时发生冲突,进而执行错误的操作或泄露敏感数据,多个工具注册了相同或类似的命令,导致执行时出现歧义,出现错误操作。在MCP Server更新后,过时或撤销的权限未被及时清除,可以继续利用这些过时权限执行恶意操作,关于这部分的讨论更多细节可以查看论文《Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions》

访问权限

企业用户更倾向于自行托管MCP Server,并希望分离数据层和控制层确保安全性和合规性,以支持不同用户访问MCP Server,从最新的规范来看,对远程Server已经做了更多的支持,但还存在问题。

基于 OAuth 2.1 的身份验证机制

将之前的 HTTP+SSE 传输方式替换为流式 HTTP 传输

支持 JSON-RPC 批处理

即使某工具通过了身份验证,还需明确其使用范围,由于MCP尚未内置细粒度权限控制,当前仅局限于会话级别,这意味着工具要么完全开放,要么完全禁用,随着工具数量增加,权限管理将变得日益复杂。

持久连接与状态性

最初设计更偏向本地运行(uv/uvx 的使用),让本地服务作为独立进程进行集成,但子进程会带来安全隐患。在MCP中,连接是有状态的,支持在连接的生命周期内进行多次请求和响应。这种设计使得客户端和服务器之间可以进行持续的交互,维护上下文信息,从而提高交互的效率和连贯性,不过这与当前流行的无状态 API 架构(如 AWS Lambda, Cloudflare Workers)不太契合。

工具过多占用上下文

MCP 当前是将所有工具都塞入模型上下文,缺乏优先级或路由机制,这不仅浪费 token,还可能导致模型行为不稳定,当我让 Claude Desktop 从超过 60 种的工具列表中的选择5 种工具调用时,性能明显下降,大多数时候它不会选择最适合的工具,需要一种分级路由(逐步、选择性暴露tool选项)的方式(社区目前在探索通过命名空间和拓扑感知方式进行分层)。

总结

MCP 目前存在的问题还有很多,MCP 社区如果能把上面的问题都能解决好(Roadmap 上都提出了针对性方案),那无疑潜力巨大,在此之前我保持谨慎乐观,继续投入我感兴趣的 Agent Network 和多轮持续对话的工具调用项目的研究。

What is the MCP

问题就是机会

模型上下文协议(MCP)的核心仍然是模型,其主要目标是抢占下一个用户交互入口,使模型客户端成为主要的交互界面。通过这种方式,用户可以通过API完成操作,而无需依赖各个垂直SaaS软件的图形用户界面(GUI)。在长链条任务中,这种设计与用户利益一致,因此,OpenAI没有理由不支持MCP,因为在这一点上,它与Anthropic的利益是一致的。不过这种模式可能会受到拥有海量用户的平台类产品的抵制,因为现有的守成者并不希望大模型成为新的入口,MCP的阳谋在于“挟开发者和用户以令巨头”:即使某些平台不愿意,标准协议也能帮助它们实现更体面的交互方式🤡(比如 mcp-browser-use),这种模式对开发者和新创产品具有吸引力。

接下来,除了完善协议本身,模型厂商还需要围绕消费级需求提供更优化的存储、Server商店等配套设施,由于这些领域单靠模型厂商自身难以完全覆盖,这便为现有基础设施厂商和开发者创造了机会。

Server 网关

作为MCP Client与Server之间的中介组件,其主要职责包括统一管理连接、分配任务以及执行安全验证。随着MCP的广泛应用,网关逐渐成为系统中的关键中间层,负责统一认证、权限控制、流量调度和工具选择。其功能类似于传统的API网关,具体包括访问控制、请求路由、负载均衡,并通过缓存响应提升效率。在多租户环境中,网关的作用尤为重要,因为不同用户和 Agent 可能具有不同的访问权限,一个标准化的 MCP 网关能够简化Client与Server之间的交互,从而增强系统的安全性、可观测性和可扩展性,同时让MCP的部署和管理更加便捷。反应迅速的厂商已经提供类似的能力了,比如 Zapier 推出MCP全流程方案,通过一个动态的 MCP 端点将 AI 助手与 Zapier 的广泛集成网络连接起来,实现了对超过 8000 个应用的直接访问。它允许 AI 执行真实动作,如发送 Slack 消息或管理 Google Calendar 事件,Zapier让开发者能够专注于编码,同时由 Zapier 管理身份验证、API 限制和安全性,国内的腾讯轻联、集简云等iPaaS平台也都可以快速实现类似改造。

Zapier 推出MCP全流程方

Server 发现

用户要找到并配置MCP服务器仍是一个手动过程,需要自行查找服务地址或脚本,配置认证信息,可以构建安装工具(比如 mcp-get),简化跨不同 MCP 客户端的 Server 安装流程,或者构建一个 Server 目录导航站,用于发现和访问可用的 MCP 服务器。不过根据 官方2025上半年的Roadmap,在分发和发现方面,MCP 包管理(MCP Server的标准化打包格式)、安装工具、沙盒安全和服务器注册表已经在日程上了,到时候按照标准做体验更好的工具就是机会。

Server 托管

提供远程 MCP Server 托管的服务,现有基础设施厂商已经在进入,比如Cloudflare 推出远程 MCP Server部署功能,提供四个核心组件来简化远程 MCP Server 的构建过程,workers-oauth-provider 作为一个 OAuth 2.1 库,简化了用户认证和授权流程,使得开发者无需自行实现复杂的 OAuth 认证;McpAgent 类集成在 Cloudflare Agents SDK 中,负责处理远程传输,使得 MCP Server能够接收和处理来自 MCP Client 的消息;mcp-remote 是一个适配器,它允许本地 MCP Client使用远程 MCP Server,让这些客户端能够连接和使用远程服务器;AI playground 作为一个远程 MCP Client,提供了一个在线聊天界面,允许用户连接到远程 MCP Server,并进行必要的认证检查,从而使得用户可以直接在网页上与远程 MCP Server交互和测试。

Cloudflare 推出远程 MCP Server部署功能

Server 安全

MCP Server 安全可以参考 DevSecOps,需要一大堆安全工具,围绕MCP Server的生命周期,创建阶段(包括Server注册、安装部署和代码完整性验证,确保Server正确配置并安全准备好处理请求)、运行阶段(MCP Server根据AI应用请求执行工具操作,处理命令,执行沙箱机制以保证环境安全,并稳定地与外部资源交互)、更新阶段(确保MCP Server持续更新并适应需求变化,包含授权管理、版本控制和旧版本管理,防止安全漏洞和权限问题)。

图来自论文 《Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions》

工具调用管理

在构建MCP客户端时,工具选择是一个关键问题,面对海量服务,工具显然不能全丢进上下文自动选择(我遇到60选5已经奔溃了),也不能依赖人工决策,难道每位开发者都需要为工具实现一套独立的检索逻辑?是否存在一个可标准化的“中间层”,以减少重复开发并提升效率?其其次缺少工具调用接口和一致的UI/UX设计模式,一些工具依赖slash commands,而另一些则采用自然语言指令。通过引入一个标准化的客户端层级,可以覆盖工具的发现、排序和调用过程,从而为开发者和终端用户提供更一致、更可靠的体验。

交互需要依次调用多个工具(单轮对话的多步骤工具调用 & 多轮对话的工具分批调用),但当前MCP尚未提供内建的工作流管理机制,期望每个客户端独立实现中断恢复、失败重试等功能既不现实也低效。因此,构建一个统一的工作流管理系统显得尤为重要。

写在结尾

如果对 MCP 的使用和理解还不清楚,可以后台回复「MCP」,手把手教你使用 MCP 搭建 Anthropic 官方博客Building effective agents定义的6种 Agent 模式,可以作为学习 MCP 的绝佳模板,毕竟 MCP 就是 Anthropic 自己发起的。

模型上下文协议(MCP)的现状、问题与掘金机会

https://liduos.com/mcp-problems-and-opportunities.html

作者

莫尔索

发布于

2025-04-02

更新于

2025-04-03

许可协议

评论