别再卷Python了！2025年程序员逆袭的唯一机会，竟是MCP？

最后一公里

MCP（模型组合编程）在大模型的应用中可以被视为“最后一公里”的解决方案。从一个激进的角度来看，到2025年，每位程序员都应当掌握这一知识。

虽然大模型的功能相当强大，但它们仍然存在一些不足之处。例如，许多大模型在进行简单数学比较时可能犯错，像是判断9.8和9.11哪个更大。尽管经过一段时间的改进，现今的大多数模型已经能够正确回答，但这也显示了它们的局限性。RAG（检索增强生成）技术在这个过程中发挥了重要作用，它的机制与MCP类似，都可以看作是外挂程序，只不过RAG是在大型语言模型（LLM）端，而MCP则是在客户端。

此外，在没有联网的情况下，大模型无法提供实时信息，例如天气预报。这表明，大模型更擅长于处理语言和艺术类的工作，比如写作、总结和生成报告等，这也符合它们的基本特性。相对来说，对多模态模型而言，无论它生成的是梵高风格还是莫奈风格的画作，关键在于结果是否美观。

总体来看，大模型在艺术和语言领域表现出色，但在处理细致的、个性化的需求时则显得力不从心。因此，MCP的重要性在于它可以填补这些空白，为程序员提供更强大的工具去应对多样化的需求。

再说 MCP 是什么

MCP，全称为模型上下文协议（Model Context Protocol），是由Anthropic于2024年11月推出的，Anthropic是一家以其卓越的编程能力而闻名的大模型Claude的开发公司。MCP是一个由社区共同构建的开放协议，旨在提供一个通用的开放标准，以连接大语言模型与外部数据和行为。

值得注意的是，MCP作为一个开放标准，类似于我们电脑上的USB接口或手机的Type-C接口。无论哪个厂家生产的数据线，只要遵循USB或Type-C标准，就可以用于充电或数据传输。同样地，不论哪个硬盘厂商只要提供一个支持Type-C的接口，就能顺利连接到电脑上使用。

再以开发中的接口调用为例，JSON格式就是一个广泛使用的标准。只要将数据构造成符合JSON格式，不论数据接收方使用的是哪种JSON库，正确解析这些数据就变得毫无障碍。

简而言之，Anthropic制定了这个标准，期望大家都能够遵循，从而实现无缝连接和高效交互。

图片

MCP 主机（MCP Hosts）

MCP主机是指那些能够支持MCP协议的程序，例如Claude Desktop、IDE及一些希望通过MCP访问数据的AI工具。而像VSCode中的Cline插件、Cursor和WindSurf等也被视作MCP主机。未来，任何能够支持MCP调用的终端都有可能成为MCP主机，甚至你自己也可以开发相应的客户端。

MCP 客户端（MCP Clients）

MCP客户端是与MCP服务器保持一对一连接的程序。从整体架构来看，主机与客户端通常是结合在一起的，客户端更偏向于编程的描述。可以将它们与数据库工具进行类比，比如Navicat软件本身可以理解为一个主机，而Navicat可以同时连接多个数据库，每个连接对应一个客户端，这些连接在MCP框架中则相当于MCP客户端。

MCP 服务器（MCP Servers）

MCP服务器是轻量级程序，通过标准化的MCP协议来暴露特定功能。MCP服务器是实现“最后一公里”的关键部分，需要根据具体需求进行开发。例如，如果想要让LLM访问自研系统的数据，就需要提供开放的接口供LLM使用。MCP服务可以用多种编程语言来开发，如Python、JavaScript（NodeJS）和Java，目前官方已提供SDK，未来可能还会推出Go、Rust、.NET等其他语言的SDK。

本地数据源（Local Data Sources）

本地数据源包括计算机文件、数据库和服务，MCP服务器能够安全地访问这些数据源。

远程服务（Remote Services）

远程服务是指可以通过互联网访问的外部系统，例如通过API进行交互的系统。比如查询实时天气时，MCP服务器需要连接国家气象局等第三方平台，这就需要通过API进行调用。

调用机制

MCP的调用机制需要客户端、MCP服务器和LLM三者的合作。首先，MCP是一个服务，例如一个查询天气的Spring Boot应用，按照官方标准实现服务接口并在本地启动。接下来，需要在客户端进行配置，类似于在注册中心注册服务，通常通过启动命令（如npx或java）来实现。这意味着客户端启动时会同时启动MCP服务。例如，以下配置文件中配置了两个服务，一个是用Java实现的，另一个是用Node实现的。

{
  "mcpServers":{
    "spring-ai-mcp-weather":{
      "command":"java",
      "args":[
        "-Dspring.ai.mcp.server.stdio=true",
        "-jar",
        "/Users/fengzheng/model-context-protocol/weather/starter-stdio-server/target/mcp-weather-stdio-server-0.0.1-SNAPSHOT.jar"
      ]
    },
    "brave-search":{
      "command":"npx",
      "args":[
        "-y",
        "@modelcontextprotocol/server-brave-search"
      ],
      "env":{
        "BRAVE_API_KEY":"xxxx"
      },
      "autoApprove":[
        "brave_web_search"
      ]
    }
}
}

随后，客户端将能够依据MCP标准获取可用的MCP服务和工具接口。一旦收到了符合需求的请求，客户端就可以调用相应的MCP接口。

整个流程的原理相对简单，以下是一个关于调用流程的示意图。

图片

1. 用户发送消息：用户通过客户端应用程序发送一条请求消息。
2. 消息传递：客户端将用户的消息转发给大型语言模型（LLM）。
3. LLM 请求额外资源：LLM在处理请求时，可能需要更多的工具或数据，因此向客户端提出相应的请求。
4. 客户端向MCP服务器发起请求：客户端根据LLM的需求，使用MCP协议向MCP服务器发送请求。
5. MCP服务器访问数据源：MCP服务器根据收到的请求，访问所需的数据源。
6. 数据源返回所需数据：数据源将所需的信息反馈给MCP服务器。
7. MCP服务器将数据反馈给客户端：MCP服务器将获取的工具或数据传输回客户端。
8. 客户端将数据传递给LLM：客户端将从MCP服务器获得的工具或数据传递给LLM。
9. LLM 生成处理结果：LLM利用提供的工具或数据生成相应的处理结果，并将结果返回给客户端。
10. 客户端展示最终结果：客户端将LLM生成的处理结果展示给用户。

为什么MCP 重要

在文章开头提到，尽管大型模型（大模型）在很多方面表现出色，但它们依然存在一些短板。这些短板往往反映了不同用户的真实需求。举个例子，某些用户希望获取精确的实时天气信息，这一需求就难以通过大模型直接满足。虽然可以通过搜索天气APP来获取这些信息，但如果在一个统一的应用或终端内实现这一功能，就能省去打开其他应用的步骤，使得使用更加高效。

另外，许多现有的MCP（模型连接器平台）服务已经允许用户直接在大模型的聊天窗口中操作本地数据库。这种集成化的体验为数据操作带来了便利。

再例如，用户可能希望整理自己曾写的关于JVM的文章。通过对大模型的指令，希望将这些文章整合成一份带有目录结构的汇总。如果没有MCP的支持，这样的需求在当前的大模型客户端中是无法实现的。然而，有了可以访问本地文件的MCP，就能够满足这样的需求。

实际上，类似的需求还有很多，任何现有APP的功能都有可能成为MCP服务所需的能力。通过整合这些功能，MCP能够大幅提升用户体验，使得大模型的应用场景更加广泛和灵活。

图片

MCP 和 Function Calling、Agent的区别

谈到MCP（模型连接器平台），我们不可避免地会提到Function Calling（函数调用）和Agent（智能体）。乍一看，这几者似乎功能相似，都是为了解决大模型的一些短板。

MCP是一种在本地运行的系统（至少目前是这样的），像Cursor这样的主机或终端可以调用它。它能够访问本地资源和个性化的API，帮助用户实现特定需求。

Function Calling则是AI模型与外部函数或服务之间互动的一种机制。在这个模式中，模型会生成一个调用请求，宿主应用会解析这个请求并执行相应的操作，最后将结果返回给模型。其特点包括：

1. 1. 同步执行：模型在发起函数调用后，会等待该函数执行完成并返回结果，才能继续执行后面的程序。
2. 2. 紧耦合：模型与函数或服务的关系较为密切，需要在代码中明确指定。
3. 3. 特定实现：不同平台或服务提供商的函数调用实现方式可能各有不同，缺乏统一的标准。

而智能体（Agent）则是一种具备自主决策能力的系统，能够执行一系列复杂的任务，例如近期受到关注的Manus。智能体通常具有以下特征：

1. 1. 自主性：根据环境变化和目标自主做出决策。
2. 2. 任务执行：能够处理多步骤和多环节的任务，往往需要同时调用多个工具或服务。
3. 3. 集成性：通常结合多种功能模块，如MCP和函数调用，以实现更复杂的任务完成。

从主要区别来看：

• • MCP作为一种协议，主要处理模型与外部工具和数据源的交互，提供标准化的接口和通信方式，非常灵活，可以根据标准实现几乎任何功能。
• • Function Calling则是关注于模型与特定函数或服务之间的具体交互实现，强调在代码层面的功能调用，与大模型及其服务端、特定客户端紧密结合，灵活性较低。
• • 智能体则是一个更复杂的系统，能够自主执行任务，通常整合MCP和Function Calling等机制来实现复杂功能。

综上所述，这三者各自有不同的定位和应用场景，虽然都是为了解决大模型的短板，但在实现方式和功能灵活性上有明显差异。

MCP 发展预测

随着AI技术的不断深入，未来生活的方方面面都将更加依赖于AI。因此，MCP（模型连接器平台）必然会跟随这一趋势继续演进。以下是对MCP未来发展的一些预测，部分已经开始显现。

超级客户端的兴起

目前，大部分功能需要通过特定的应用程序来实现。但随着AI的普及，未来可能会出现集成多种工具和服务的超级客户端，例如豆包或小爱同学。这些客户端将为用户提供统一的操作体验，用户可以在一个应用中无缝访问本地文件、数据库、浏览器及其他服务，从而显著提升工作效率。

目前，小爱同学的功能主要集中在定时和天气查询。但如果能够通过MCP与更多服务商连接，这样的智能助手将能够处理更多的需求。

MCP市场的形成

未来的MCP市场可能类似于现在的应用商店，个人和企业都能够提交自己的MCP服务。例如，一个短视频平台可以提供推荐视频的API，用户则可以在支持MCP的客户端中直接观看视频。现阶段，Cline插件已经具备了一些MCP市场的功能，用户可以浏览和安装开源MCP服务，但其使用体验仍然相对初级，有待进一步优化。

远程运行能力的发展

MCP不仅支持本地STDIO的通信，还能通过HTTP/SSE进行网络交互。这意味着，未来的MCP系统将具备在本地和远程环境中灵活运行工具的能力。对于程序员而言，在本地运行Node、Python或Java代码并不困难，但对于缺乏编程背景的用户来说，这可能是一项挑战。因此，要让更多人能普遍使用MCP，必须解决本地启动服务这一问题。

综上所述，随着科技的发展和用户需求的增加，MCP将朝着更加智能、便捷的方向演进，成为未来数字生活中不可或缺的组成部分。