模型上下文协议 (MCP) 概述与问题分析
本文分析了模型上下文协议 (MCP) 的现状、问题以及未来趋势。尽管 MCP 作为 AI 集成标准化平台迅速发展,并被广泛支持,但作者认为其流行的趋势将是短暂的。
MCP 的起源与问题:
MCP 的流行并非源于其独特的功能,而是因为其服务器部署的便捷性,吸引了众多项目加入。MCP 旨在解决“NxM 问题”,即在 N 个代理和 M 个工具集之间建立连接的问题。然而,模型具备工具调用能力并不需要 MCP。工具调用模型通过向 LLM 提供可用工具列表,并在 LLM 调用工具时返回 JSON 格式的参数来实现。应用负责提供工具模式、解析参数和执行调用。
NxM 问题的核心在于不同代理的 API 差异。例如,Gemini API 使用 functionDeclarations 嵌套在 tools 数组中,而 OpenAI API 使用扁平的 tools 数组,其中 type 为 "function"。虽然差异存在,但 LangChain、LiteLLM 和 SmolAgents 等框架已经能够抽象这些差异,并且工具调用发生在与代理相同的运行时。
MCP 的架构与缺陷:
MCP 通过独立的进程处理工具的暴露和调用。应用负责协调代理循环并向用户展示结果。这种架构虽然抽象了模式生成和调用,但带来了以下问题:
- 资源管理不透明: 工具逻辑在单独的进程中运行,导致资源管理不透明。
- 失去控制: 应用失去对工具指令、日志和错误处理的控制权。
- 跨进程开销: 每次工具调用都需要跨进程边界。
- 工具箱不连贯: 独立的工具服务器无法了解其他工具的存在,导致工具指令缺乏上下文,影响了代理的工具使用效率。
- 运行时环境问题: 每个 MCP 服务器启动一个独立的进程,可能导致资源浪费、子进程悬挂、内存泄漏和资源争用。此外,MCP 服务器只继承有限的父环境变量,导致部署和运行环境依赖性问题。
- 安全风险: MCP 允许从 npm、pip 或 GitHub 下载服务器,存在供应链风险,且缺乏身份验证机制,导致安全漏洞。
MCP 的流行原因:
MCP 的流行主要归因于:
- 易于部署: 简单易用的服务器部署方式。
- 企业 AI 可信度: 帮助企业项目快速实现 AI 功能,提升市场竞争力。
- Anthropic 的支持: 增强了 MCP 作为开放标准的地位,吸引了投资者的关注。
替代方案:
作者认为,对于不同的用户群体,存在比 MCP 更好的替代方案:
- 技术用户: 使用本地脚本和命令运行器。
- 非技术用户: MCP 目前无法满足非技术用户的需求。
- 内部应用开发者: 使用第一方工具。
- 代理开发者: 使用 SDK 抽象(如 LangChain、LiteLLM)。
- 工具作者: 使用 OpenAPI 规范或库。
未来展望:
作者预测 MCP 的流行趋势将是短暂的, Claude Skills 和 OpenAI 的类似举措表明,模型提供商也正在寻求更高效的解决方案。 长期来看,人类开发者协作的经验和技术将继续发挥作用,并逐渐取代过度设计的 AI 专用技术。
总之,本文批判性地评估了 MCP 的架构和价值,并提出了更简单、更有效的替代方案,认为 MCP 的流行只是一个短暂的现象。