银川建立网站温州网站制作企业
MCP服务发展现状的有趣发现
当前，MCP（Model Context Protocol）在AI领域逐渐成为一个热门话题。其核心意义在于赋予大模型直接调用外部工具的能力，从而打破“数据孤岛”，实现真正的工具增强型AI。然而，在深入了解MCP服务生态的过程中，我发现了一些令人深思的现象，尤其是关于本地化与远程化服务的分布格局。
从MCP服务器的分类说起
MCP服务器大致可分为两种类型：
-
本地服务器（stdio模式）：
基于进程间通信（IPC），通过标准输入输出流（stdin/stdout）进行交互。它以极低的延迟和高吞吐量著称，适合本地场景，例如IDE插件、嵌入式设备等。 -
远程服务器（HTTP/SSE模式）：
通过HTTP协议和SSE（Server-Sent Events）技术实现远程通信，支持多客户端并发访问，适合云服务、分布式系统等场景。高德地图的MCP Server就是典型例子，它通过SSE提供出行相关的12项核心工具，例如导航、路径规划、天气查询等。
我的直觉与现实的冲突
最初，我认为远程MCP服务将成为主流。理由如下：
- 技术复杂性：本地服务看似简单，但无法满足大规模、跨网络的协作需求。
- 资源限制：复杂任务（如大模型训练、高精度地图处理）需要远程服务器的强大算力。
- 行业趋势：互联网企业（如高德、阿里云）显然会优先构建远程MCP服务以拥抱AI时代。
然而，现实却给了我一个“耳光”。
现状观察
-
本地服务占据主导
在MCP服务生态中，本地服务（stdio模式）仍是主流。许多开发者倾向于在本地环境中部署工具，例如通过Python脚本封装远程API调用，而非直接使用远程MCP服务。 -
远程服务的“冷遇”
尽管高德、阿里云等平台提供了SSE远程服务，但实际应用中，这些服务并未广泛流行。例如，高德的MCP Server虽然功能强大，但开发者更倾向于在本地脚本中调用其REST API，而非通过MCP协议直接集成。 -
远程MCP服务的“稀缺性”
我曾搭建过一个远程MCP服务列表网站，试图收集优秀的远程MCP服务。然而，结果令人失望——真正独立存在的远程MCP服务寥寥无几，大多数开发者仍依赖本地脚本封装远程调用。
为什么远程MCP服务未成为主流？
1. 部署复杂性与成本
- HTTP/SSE的开销：远程服务需要维护长连接、处理TLS加密、应对防火墙限制，增加了部署难度。
- 资源消耗：高并发场景下，远程服务需要大量服务器资源，而本地服务通常更轻量化。
- 生态支持不足：目前缺乏成熟的工具链和社区支持，开发者更倾向于“就地取材”。
2. 本地化服务的“低门槛”优势
- 快速迭代：本地脚本可以快速封装现有API，无需等待远程服务的更新。
- 灵活性：开发者可以直接修改脚本逻辑，适应特定需求，而远程服务通常需要遵循固定接口规范。
- 安全性：本地服务天然隔离，避免了远程调用中的中间人攻击风险。
3. MCP协议的“中间态”定位
- 当前MCP协议更像是一个中间层协议，而非终端服务协议。开发者更倾向于将其视为“工具调用的桥梁”，而非直接暴露的远程服务接口。
- 例如，高德MCP Server的SSE接口本质上是对现有API的封装，而非完全独立的服务。
未来的MCP服务会如何发展？
尽管远程MCP服务尚未流行，但以下趋势值得关注：
1. Streamable HTTP的崛起
根据知识库内容，Streamable HTTP（2025年3月引入）正在逐步取代传统HTTP/SSE。它通过统一端点和按需流式传输，显著降低了远程服务的复杂性。例如，高德MCP Server的升级版本已采用Streamable HTTP，支持一键生成专属地图、导航唤端等操作。
2. 行业定制化服务的兴起
- 高德MCP Server的案例表明，垂直领域的远程服务（如出行、物流）可能率先实现规模化。
- 未来，各行业的龙头企业可能会推出领域专用的MCP服务，例如医疗、金融、教育等。
3. 标准化与生态整合
- 当前MCP服务缺乏统一标准，导致开发者重复造轮子。未来，随着MCP协议的演进（如OAuth 2.1强制认证、会话恢复机制），远程服务的标准化程度将提高。
- 工具链的完善（如LangChain、Higress对Streamable HTTP的支持）也将降低远程服务的使用门槛。
我的思考与疑问
1. MCP服务的“终极形态”是什么？
- 是全面转向本地化？还是通过标准化和优化推动远程服务普及？
- 会不会出现“混合模式”？例如，本地服务负责核心逻辑，远程服务提供补充能力。
2. 开发者为何选择“本地脚本封装”？
- 是否因为远程服务的性能或可靠性不足？
- 是否缺乏对MCP远程服务的宣传或教育？
3. MCP服务的“冷启动”困境
- 如何吸引开发者主动构建远程MCP服务？是否需要平台方提供更强大的基础设施支持？
结语
MCP服务的发展现状揭示了一个有趣的悖论：技术上更先进的远程服务并未占据主导地位，反而是本地服务因其简单性而成为主流。这种现象背后，既有技术复杂性的制约，也有开发者习惯的影响。
对于未来，我认为MCP服务的生态将逐渐分化：
- 本地服务将继续主导轻量级、单机场景。
- 远程服务将在垂直领域（如高德出行、物流调度）中实现突破。
- Streamable HTTP和标准化协议将为远程服务的普及铺平道路。
或许，MCP的真正价值不在于“远程”或“本地”的争论，而在于它如何帮助开发者高效地整合工具与AI。无论形式如何，只要能降低调用门槛、提升协作效率，MCP都将成为AI时代的“瑞士军刀”。
（PS:本文由QWQ3整理作者观点所得）