MCP 的应用场景，其实是一个巨大的赚钱机会

最新推荐文章于 2025-04-26 08:00:00 发布

程序员辣条

最新推荐文章于 2025-04-26 08:00:00 发布

阅读量1.2k

点赞数 13

文章标签：人工智能大模型学习大模型语言模型 MCP Agent AI大模型

本文链接：https://blog.csdn.net/m0_65555479/article/details/147018487

版权

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

有哪些问题

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

What is the MCP

无谓的复杂性

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

安全性

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

访问权限

企业用户更倾向于自行托管 MCP Server，并希望分离数据层和控制层确保安全性和合规性，以支持不同用户访问 MCP Server，从最新的规范[4]来看，对远程 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 上都提出了针对性方案[5]），那无疑潜力巨大，在此之前我保持谨慎乐观，继续投入我感兴趣的 Agent Network 和多轮持续对话场景下工具调用的研究。

问题就是机会

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

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

Server 网关

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

Zapier 推出MCP全流程方

Server 发现

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

Server 托管

提供远程 MCP Server 托管的服务，现有基础设施厂商已经在进入，比如Cloudflare 推出远程 MCP Server 部署功能[9]，提供四个核心组件来简化远程 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[10]定义的 6 种 Agent 模式，可以作为学习 MCP 的绝佳模板，毕竟 MCP 就是 Anthropic 自己发起的。