MCP深度解析：全面了解多控制流计算机程序设计原理与应用！

MCP(Model Context Protocol)是由Anthropic提出的标准化协议，旨在统一大模型与外部数据源和工具之间的通信。该协议采用客户端-服务端架构，其中MCPClient作为调用方(如Claude等AI应用)，MCPServer作为服务提供方(如GitHub、高德地图等)。MCP通过六个标准化步骤实现智能调用：用户提问→LLM推理选择工具→调用指定MCPTool→获取结果→LL

猿类崛起@

1031人浏览 · 2025-06-14 10:00:00

猿类崛起@ · 2025-06-14 10:00:00 发布

了解MCP之前，我们先来回顾一下AI Agent，需要具备什么样的能力，达到什么样的智能程度，才可以称为一个Agent。

AI Agent概念

AI Agent 是能主动解决问题的智能程序，核心在于感知→决策→行动→学习的闭环。未来它会像水电一样渗透到所有数字场景中，成为每个人的“智能伙伴”。

上图可简单划分为 Agent = LLM + 规划技能 + 记忆 + 工具使用，其中 LLM 扮演了 Agent 的“大脑”，在这个系统中提供推理、规划等能力。过多关于AI Agent概念就不过多介绍，读者可以关注公众号之前的文章。

MCP详细介绍

MCP来源

2024年11月底 Anthropic（Claude提供商）提出了MCP协议，并在Claude 客户端支持了MCP。

MCP协议，全称为“Model Context Protocol”，提供了一种将LLM连接到不同数据源（resource）和工具（tool）的标准化方法，旨在统一大模型与外部数据源和工具之间的沟通通信协议。

MCP 大概的工作方式：MCP Host，比如 Claude Desktop、Cursor 这些工具，在内部实现了 MCP Client，然后MCP Client 通过标准的 MCP 协议和 MCP Server 进行交互，由各种三方开发者提供的 MCP Server 负责实现各种和三方资源交互的逻辑，比如访问数据库、浏览器、本地文件，最终再通过标准的 MCP 协议返回给 MCP Client，最终在 MCP Host 上展示。

MCP 的核心架构

MCP 采用客户端-服务端架构，以下是 MCP 官方展示的架构：

MCP Client（客户端）：作为调用方，是用户与 MCP 生态的交互入口。例如，聊天应用类，提供自然语言交互服务，让用户通过对话调用 AI 能力；编码工具类，在 IDE 里调用外部应用和系统的能力；任务自动化类，帮用户自动化执行重复性任务，如数据处理、流程调度，以提升效率。
MCP Server（服务端）：作为被调用方，提供后端服务支撑，包含各类核心功能模块。例如，数据库类（如 ClickHouse、Supabase）负责数据存储、查询与管理；设计类（如 Figma、Blender）支撑设计创作、文件协作等功能；生产力工具类（如 Notion、Obsidian）提供笔记管理、知识整理等办公协作服务；支付类（如 Stripe），处理在线支付交易，支持商业场景的资金流转。
Local MCP Server（本地数据源）：MCP 服务器可以安全访问本地计算机上的文件、数据库和服务。
Remote MCP Server（远程服务源）：MCP 服务器可以通过互联网（例如通过 API）连接到外部系统。

MCP的Server一般由各大厂商按照规范提供，这样不同的MCP Client可以进行调用，这里列举一些MCP服务：

GitHub MCP Server：该server能够深度整合 GitHub API，实现文件操作、仓库管理、搜索等功能，从而支持代码仓库的自动化管理。
Google Drive MCP Server：允许用户浏览、读取和搜索 Google Drive 上的文件，并支持自动转换多种文件格式。
Fetch MCP Server：支持抓取网页内容，并能将 HTML 自动转换为易读的 Markdown 格式，便于内容整理与分享。
@amap/amap-maps ：高德地图是一个支持任何MCP协议客户端的服务器，允许用户轻松利用高德地图MCP服务器获取各种基于位置的服务。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

由于MCP Server比较多，国内国外的都有，这里就不一一列举，可以访问如下链接自行查看：

国外Github汇总MCP:https://github.com/modelcontextprotocol/servers
国内魔塔社区汇总MCP:https://modelscope.cn/mcp

MCP的工作机制

如上图所示，一次基于MCP的调用，一共有6个核心的步骤，假设我们的需求是：

我要开发一个获取时间的AI Agent，用户在使用这个AI Agent时，只需要问类似“现在几点了？”这种问题即可。
我已经有了一个关于处理时间的MCP Server，这个MCP Server里有2个MCP Tool，一个负责获取当前时区，一个负责获取当前时间。

调用步骤解析：

第一步：用户向AI Agent提问“现在几点了？”，此时AI Agent就是MCP Client，它会把用户的问题和处理时间的MCP Server以及MCP Tool的信息一起发送给LLM。
第二步：LLM拿到信息后开始推理，基于用户的问题和MCP Server的信息，选出解决用户问题最合适的MCP Server和MCP Tool，然后返回给AI Agent（MCP Client）。
LLM返回给AI Agent的信息是：“你可以使用time这个MCP Server里的get_current_time这个MCP Tool，它可以解决用户的问题”。
第三步：AI Agent（MCP Client）现在知道应该使用哪个MCP Server里的哪个MCP Tool了，直接调用该MCP Tool，获取结果。
调用名称为time的MCP Server里的get_current_time MCP Tool。
第四步：Time MCP Server返回结果（当前的时间）给AI Agent（MCP Client）。
第五步：AI Agent（MCP Client）把用户的问题和从Time MCP Server处拿到的结果再一次给了LLM，目的是让LLM结合问题和答案再规整一下内容。
第六步：LLM把整理后的内容返回给AI Agent（MCP Client），最后AI Agent（MCP Client）再原封不动地返回给用户。

在MCP的整个调用过程中有一个非常关键之处就是MCP Server 以及 MCP Tool 的信息。从第一步、第二步可以看出，这个信息非常关键，是它让LLM知道了该如何解决用户的问题，这个信息就是MCP中最重要的System Prompt，本质上就是优化提示词。

MCP主要解决什么问题

在MCP出现之前，如果要让大模型调用外部服务，需要获取各个外部服务的API的描述信息，如入参说明, 使用场景等，把用户的原始问题和工具的描述信息拼接成Prompt，发送给大模型。

没有MCP的场景

用户想查询北京飞往上海的航班信息和天气情况，传统做法需要以下步骤：

开发者需要先获取两个外部API的文档：航班查询API：

{
  "name": "flight_search",
  "description": "查询航班信息",
  "parameters": {
    "departure_city": "出发城市",
    "arrival_city": "到达城市", 
    "date": "出发日期（YYYY-MM-DD）"
  }
}

天气查询API：

{
  "name": "weather_query",
  "description": "查询城市天气",
  "parameters": {
    "city": "城市名称",
    "date": "查询日期（YYYY-MM-DD）"
  }
}

拼接Prompt，需要把用户问题和API文档信息一起发送给大模型：

用户问题：帮我查下明天北京飞上海的航班，还有上海的天气

可用工具：
1. flight_search：查询航班信息
   参数：
   - departure_city：出发城市
   - arrival_city：到达城市
   - date：出发日期（YYYY-MM-DD）

2. weather_query：查询城市天气
   参数：
   - city：城市名称
   - date：查询日期（YYYY-MM-DD）

请分析用户需求，选择需要调用的工具，并输出符合工具要求的参数JSON。

3.大模型输出大模型输出，模型会返回类似这样的结构化请求：

{
  "flight_search": {
    "departure_city": "北京",
    "arrival_city": "上海",
    "date": "2023-11-20"
  },
  "weather_query": {
    "city": "上海",
    "date": "2023-11-20"
  }
}

4.开发者处理，需要写代码将这个JSON分别发送给对应的API，然后再把结果整合后返回给用户。

这种方式的痛点：

每个新工具接入都要手动编写描述文档。
需要处理复杂的prompt工程。
参数转换和结果整合需要大量定制代码，无法复用。
不同模型的prompt格式可能不兼容。

有了MCP后:

AI Agent与工具（Tools）解耦，工具有了标准化的实现，解决了工具无法复用的问题。
统一的function calling标准，不同AI模型之间的无缝切换和无缝协作，减少对LLM平台的依赖。

MCP工作流程，实际场景

解决天气查询问题

为了解决上面查询航班和天气的问题，我们直接搜索对对应的使用MCP工具，如下：

将MCP服务集成到自己的大模型应用开发平台，或者是自己的AI Agent应用中，只需将一些配置参数，大模型即可自行调用对应的MCP工具来获取结果，就不需要自行拼接prompt，组装数据，如下是集成对应的MCP服务：

{
    "mcpServers": {
        "variflight": {
            "command": "npx",
            "args": [
                "-y",
                "@variflight-ai/variflight-mcp"
            ],
            "env": {
                "VARIFLIGHT_API_KEY": "your_api_key_here"
            }
        }
    }
}

然后再自己的大模型应用或者Agent中配置调用即可，大模型会根据你的输入和工具的描述，智能调用工具，如下图所示：

如图所示，左边的提示词并没有指定调用天气查询的接口，或者是指定调用的具体方法和参数，根据天气MCP的配置，大模型会自动调用对应的MCP工具，返回正确的结果，这就是MCP比function calling的优势之处。

支付场景

以下是一个虚构的简化使用场景，用于方便理解工具能力：

一位插画师希望通过提供定制的原创插画服务谋取收入。传统方式下，他/她需要和每位客户反复沟通需求、确定价格，并发送支付链接，然后再人工确认支付情况，这个过程繁琐且费时。
现在，插画师利用支付宝 MCP Server 与智能 Agent 工具，通过 Agent 搭建平台，开发了一个智能聊天应用（网页或小程序）。客户只需在应用中描述自己的绘画需求（如风格偏好、插画用途、交付时间等），AI 就会自动分析需求，快速生成准确且合理的定制报价，并通过工具即时创建出专用的支付宝支付链接。
客户点击并支付后，创作者立即收到通知，进入创作环节。无需人工往返对话确认交易状态或支付情况，整个流程不仅便捷顺畅，还能显著提高交易效率和客户满意度，让插画师更专注于自己的创作本身，实现更轻松的个性化服务商业模式。

例如，在Agent中引入对应的支付MCP，即可实现定制需求，提供报价，快速交易变现的场景。

结语

让我们在回顾一下MCP的整个概念和流程：

用户提问 → LLM通过MCP Client生成工具调用请求 → MCP Server路由到目标工具 → 工具返回结果 → LLM整合结果并回复用户

MCP宗旨：统一大模型与外部服务的智能桥梁

MCP协议的核心价值：标准化通信 MCP（Model Control Protocol）协议本质上是一种标准化接口规范，它统一了大模型（LLM）与外部数据源、工具服务之间的通信方式。通过MCP：解耦LLM与工具：不同厂商的大模型（如GPT-4、Claude、文心一言）可通过同一套MCP协议调用外部工具，无需为每个模型单独适配。
统一工具描述：所有外部服务（如航班查询、天气API、数据库）以标准化的MCP格式注册其功能、参数和权限，避免手动拼接Prompt的繁琐操作。
动态兼容性：当新增工具时，只需将其注册到MCP Server，所有接入MCP的LLM均可立即调用，无需重新训练或调整模型。

如何学习AI大模型？

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】