暴论：2025年，程序员必学技能就是 MCP 原创 精华

MCP（模型上下文协议）就像是大模型世界里的“最后一公里”。大胆地说一句，MCP 应该是每个程序员在 2025 年必须掌握的知识点。

大模型的功能确实很强大，但它们也有明显的短板。例如，大模型在数学计算方面表现不佳。曾经有一个知名的测试，让大模型比较 9.8 和 9.11 哪个数更大，大约半年前，大部分大模型都会错误地回答 9.8 更小。如今，这种情况已经基本得到纠正，这主要得益于 RAG（检索增强生成）技术。RAG 的原理与 MCP 有异曲同工之妙，它们都像是一个“外挂程序”，只不过 RAG 挂在了 LLM（大型语言模型）端，而 MCP 挂在了客户端。

再比如，在大模型具备联网功能之前，它无法告诉你实时天气。大模型在处理推理工作时表现得更为出色，比如做总结、出报告、写文章等。这也很合理，毕竟 LLM 的全称是“大型语言模型”，它在处理语言方面自然更有优势。再看看多模态模型，比如生图模型，你让它画一幅画，画出的是梵高风格还是莫奈风格，对于很多人来说并不重要，只要画作好看就行。

总结来说，大模型更擅长处理推理类的工作，或者说它在处理那些形而上的事物时更为得心应手。然而，当涉及到特别精细化的工具化操作，尤其是定制化需求时，大模型的表现就不那么理想了。

1、MCP 机制剖析

第一、什么是 MCP？

MCP，全称 Model Context Protocol，是由 Anthropic 在 2024 年 11 月推出的一项创新技术。Anthropic 是目前公认的在代码生成领域表现最为出色的大模型 Claude 的开发公司。MCP 作为一个社区共建的开放协议，旨在提供一个通用的开放标准，用于连接大语言模型（LLM）和外部数据及行为。

MCP 的重要性在于它提供了一个标准化的接口，使得大语言模型能够更高效地与外部世界进行交互。这就好比电脑上的 USB 接口或手机上的 Type-C 接口，无论哪个厂家生产的数据线，只要遵循 USB 或 Type-C 标准，就能用来充电或传输数据。同样，无论哪个硬盘厂商生产的硬盘，只要支持 Type-C 接口，就能连接到电脑上使用。

再举一个开发中的例子，我们通常使用 JSON 格式进行接口调用。JSON 的格式就是一个标准，只要数据格式符合 JSON 规范，无论谁来接收数据，无论使用哪个 JSON 库，甚至手动解析，只要符合 JSON 格式，数据传输就能畅通无阻。

Anthropic 通过 MCP 制定了一套标准，使得开发者可以基于这一标准构建和连接各种工具和服务。这不仅简化了开发流程，还极大地扩展了大语言模型的应用场景。通过 MCP，开发者可以轻松地将 LLM 与各种外部数据源和工具集成，从而实现更复杂、更高效的任务处理。

第二、MCP 的核心组件

1.MCP 主机（MCP Hosts）

MCP 主机是那些希望通过 MCP 访问数据的程序，例如 Claude Desktop、IDE 或其他 AI 工具。目前，像 VsCode 中的 Cline 插件、Cursor、WindSurf 等都支持 MCP，未来支持 MCP 调用的终端都可以成为 MCP 主机。甚至，你自己也可以开发一个客户端。

2.MCP 客户端（MCP Clients）

MCP 客户端是通过协议与服务器保持 1:1 连接的程序。主机和客户端通常是一起的，客户端更偏重于编程概念中的解释。可以类比数据库工具，比如 Navicat 软件本身可以理解为主机，而一个 Navicat 可以同时连接多个数据库，每连接一个数据库需要一个连接（设置多个），这些连接可以理解为 MCP 里的客户端。

3.MCP 服务器（MCP Servers）

MCP 服务器是轻量级程序，每个程序通过标准化的模型上下文协议暴露特定功能。这部分是“最后一公里”的具体实现，需要根据具体需求开发。例如，如果你想让 LLM 访问自研系统的数据，就需要提供开放接口并供 LLM 使用，这部分就是 MCP 服务器。

MCP 服务可以用 Python、JavaScript（NodeJS）、Java 来开发，目前官方已经开放了这些语言的 SDK。未来，还会有 Go、Rust、.NET 等语言的 SDK。

4.本地数据源（Local Data Sources）

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

5.远程服务（Remote Services）

远程服务是可以通过互联网访问的外部系统（例如，通过 API），MCP 服务器可以连接到这些服务。例如，查询实时天气时，你的 MCP 服务器需要去国家气象局等第三方平台获取数据，这需要 API 调用。

第三、调用机制

MCP 的调用机制需要客户端、MCP 服务端和 LLM 三方配合。

1.启动 MCP 服务

例如，一个查询天气的 Spring Boot 应用，按照官方标准实现具体的服务接口，并在本地启动。

将服务在客户端进行配置，就像在注册中心注册一样，通常是启动命令，例如 npx 或 java。客户端打开后，在本地同时启动 MCP 服务。

配置文件示例：

{
  "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"
      ]
    }
  }
}
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.

2.调用流程

• 用户发送消息：用户通过客户端应用程序发送一条消息。
• 客户端传递消息：客户端将用户的消息传递给 LLM。
• LLM 请求工具或数据：LLM 可能需要额外的工具或数据来处理请求，因此向客户端发出请求。
• 客户端向 MCP 服务器请求：客户端根据 LLM 的需求，通过 MCP 协议向 MCP 服务器发送请求。
• MCP 服务器访问数据源：MCP 服务器根据请求访问相应的数据源。
• 数据源返回数据：数据源将所需的数据返回给 MCP 服务器。
• MCP 服务器返回工具或数据：MCP 服务器将获取到的工具或数据返回给客户端。
• 客户端提供工具或数据给 LLM：客户端将工具或数据传递给 LLM。
• LLM 返回处理结果：LLM 使用提供的工具或数据生成处理结果，并返回给客户端。
• 客户端显示最终结果：客户端将 LLM 的处理结果展示给用户。

整个原理其实比较简单，但通过这种机制，MCP 能够极大地扩展 LLM 的能力，使其能够处理更复杂的任务。

第四、为什么 MCP 重要？

文章开头提到，尽管大模型功能强大，但它们也有明显的短板。而这些短板往往对应着一部分用户的真实需求。例如，有人需要精确的实时天气信息，这正是大模型的一个短板。有人可能会说，查天气直接打开一个 APP 不就行了吗？当然可以，但如果能在一个应用或终端中直接完成，岂不是更方便，省去了拿起手机打开 APP 的麻烦。

再比如，在大模型聊天窗口中直接操作本地数据库，现在已经有多种 MCP 服务可以实现这一点。

又比如，想要建立自己的知识库。假设我对大模型说：“把我曾经写的关于 JVM 的文章找出来，并给我汇总成一篇带目录结构的文章合集。” 如果没有 MCP 的辅助，现有的任何大模型客户端都无法实现这一需求。但有了可以访问本地文件的 MCP，这个需求就有可能实现。

类似的需求数不胜数，几乎每一个现有 APP 的功能都可能成为 MCP 需要支持的功能。

2、MCP、Function Calling、Agent 区别

说到 MCP，就不得不提到 Function Calling 和 Agent。从表面上看，这三者似乎功能相似，目的也相近，都是为了弥补大模型的短板。

第一、MCP

MCP（Model Context Protocol）是一种开放协议，旨在提供一个通用的开放标准，用于连接大语言模型（LLM）和外部数据及行为。MCP 运行在本地（至少目前是），由像 Cursor 这样的主机（或统称为终端）调用，可以访问本地资源、个性化的 API 等。

第二、Function Calling

Function Calling 是 AI 模型与外部函数或服务交互的一种机制。在这种模式下，模型生成一个函数调用请求，宿主应用解析该请求并执行相应的操作，然后将结果返回给模型。Function Calling 通常具有以下特点：

同步执行：调用函数后，程序会等待函数执行完毕并返回结果，才继续执行后续代码。

紧耦合：模型与函数或服务之间的关系较为紧密，需要在代码中明确指定。

特定实现：函数调用的实现方式可能因平台或服务提供商而异，缺乏统一标准。

第三、Agent

Agent（智能体）是具备自主行动能力的系统，能够执行一系列复杂的任务，比如前一段时间很火的 Manus。Agent 通常具备以下特征：

自主性：能够根据环境变化和目标自主做出决策。

任务执行：能够执行多步骤、多环节的任务，往往需要调用多个工具或服务。

集成性：通常集成多种功能模块，如 MCP 和 Function Calling，以实现复杂的任务处理。

第四、主要区别

MCP：作为一种协议，主要解决模型与外部工具和数据源之间的交互问题，提供标准化的接口和通信方式。它非常灵活，只要遵循标准，几乎能实现任何功能。

Function Calling：是模型与特定函数或服务交互的具体实现方式，关注如何在代码层面实现功能调用。它需要大模型和特定客户端紧密绑定，灵活性较低。

Agent：是一个复杂的系统，能够自主执行任务，通常需要结合 MCP 和 Function Calling 等机制，以实现复杂的功能。

通过这些对比，我们可以更清晰地理解 MCP、Function Calling 和 Agent 的功能和应用场景。

3、MCP 发展预测

随着 AI 的迅猛发展，它将在未来生活的各个领域扮演越来越重要的角色，而 MCP（Model Context Protocol）也将顺应这一趋势不断进化。以下是对未来可能出现的几种情况的预测，其中一些已经在逐步成为现实。

第一、超级客户端的出现

目前，我们为了使用不同的功能，往往需要打开各种各样的 APP。然而，随着 AI 的普及，未来可能会出现超级客户端或终端，就像豆包或小爱同学这样的智能助手。这些超级客户端将集成多种工具和服务，为用户提供统一且无缝的体验。例如，用户可以在一个应用中轻松访问本地文件、数据库、浏览器以及其他服务，无需频繁切换不同的 APP，从而大大提高工作效率。

以小爱同学为例，目前它主要被用于设置定时提醒和查询天气。但如果借助 MCP 的方式，与更多的服务商进行打通，小爱同学将能够实现更多样化的需求，为用户提供更丰富的服务。

第二、MCP 市场的兴起

未来可能会出现类似现在应用商店的 MCP 市场。在这个市场中，无论是个人开发者还是公司，都可以提交自己的 MCP。例如，某短视频平台可以提交一个推荐视频的接口，用户就可以在一个支持 MCP 的客户端中直接刷视频。目前，Cline 插件已经具备了 MCP 市场的功能，用户可以查看并安装各种开源的 MCP。不过，这一功能还处于初级阶段，有时使用起来可能还不够便捷。

第三、远程运行能力的实现

MCP 支持多种通信方式，包括本地的 STDIO 和网络上的 HTTP/SSE。当需要跨机器通信时，MCP 可以利用 HTTP/SSE 实现工具的远程调用。这意味着，未来的 MCP 系统将能够在本地和远程环境中灵活地运行工具，为用户提供了更广泛的部署选项。

对于程序员来说，在本地运行 Node、Python、Java 等语言的程序并非难事。然而，对于那些没有编程经验的人来说，这无疑是一项艰巨的挑战。因此，如果希望让更多的人能够使用 MCP，就必须解决本地启动服务的问题，降低使用门槛，使 MCP 更加易于上手和使用。

本文转载自公众号玄姐聊AGI  作者：玄姐

原文链接：​​https://mp.weixin.qq.com/s/aH9L_9khY9J1X2Qldge9iQ​​