模型上下文协议（感知境）
欢迎来到以DeepSeek以代表的AI世界，我是doc-war.com的青樵，一个技术主义者。
知行合一，用DeepSeek写DeepSeek教程。
一、初识概念
我们先来看看Anthropic公司官方是怎么介绍模型上下文协议的。
听起来依然很模糊，对不对？
官方的文档直接进入了概念宣读和技术细节，没有遵循第一性原理给出一个全景图。我们需要落到更具象的架构和场景中去理解MCP的价值和位置、流程。
一、理解AI增强
AI不是万能的！
这种所谓的不万能，具体表现在知识上浮、信息下沉，尤其是实况信息。下图是一个典型的场景。
二、理解交互关系
下面以“查今天天气”为例，说明各个组件之间的交互过程和数据传输方式。
系统组成
系统中有以下角色：
- 用户：发起查询请求（例如通过对话界面）。
- Agent（MCP Client）：用户与系统交互的
业务前端，负责协调 LLM 与外部服务的调用。Agent可能是一个客户端形态，也可能是客户端+服务端的形态，但就AI处理这个业务而言是业务前端，需要遵循MCP 客户端调用协议。 - LLM：大型语言模型，Agent的
核心后端，负责理解用户意图并决定是否调用外部工具。 - MCP Server：提供标准化接口，接收外部 Agent 的工具调用请求，并转发到对应的服务。
- 天气服务：实际提供天气数据的后端 API。
误区
当我们问DeepSeek天气，他完成推理并返回答案，我们很容易陷入用户直觉误区，困惑于LLM怎么来调用天气服务，或者天气服务怎么来调用LLM。
LLM的核心价值是权重数据，所有的功能都是围绕权重数据生命周期展开的。LLM 的主要职责都围绕着如何获取、管理和利用其权重数据展开，从初始的预训练、后续的微调，到实际的推理服务，再到持续的监控和更新。
因此，架构上的第一个合理设计是所有跟权重数据无关的常规业务（典型如用户业务、模型切换、模型版本切换......），前移到Agent上层。
这个分层架构的设计，与有没有模型上下文协议（MCP）无关。
而模型上下文协议的位置，在Agent和LLM之间，在Agent和常规业务系统之间。其诞生是为了进一步解决一个标准化的问题。
交互流程
下面详细说明各个步骤以及数据如何在各系统组件之间传递。
核心业务流
用户发起查询 用户在聊天界面输入请求，例如：“查纽约今天天气”。
Agent平台 接收并转发请求给 LLM Agent 遵循MCP协议规范，充当
MCP client角色，将用户的查询与系统内注册的工具信息（例如：天气查询工具），通过函数调用申明的形式传递给 LLM。json/* 所谓注册一个工具，就是按规范传递一份格式，告诉LLM是干啥的，应该怎么调用 这个过程是预注册性质，在LLM会话初始化时发生 */ { "name": "get_weather", "description": "查询指定城市和日期的天气信息", "parameters": { "city": { //参数名 "type": "string", //类型 "description": "城市名称" //说明 }, "date": { "type": "string", "description": "查询的日期，例如 'today' 或 '2025-02-14'" } } }如此，LLM便知道了有一个天气查询工具，以及如何调用。接下来这些信息将作为LLM会话上下文的一部分存在。这也是为什么称之为
模型上下文协议的原因。LLM内核 推理并决定调用工具
LLM 解析用户查询后，判断需要调用外部天气服务来获得数据。它会使用标准的数据协议，生成一个“函数调用指令”，类似：
json{ "action": "get_weather", //函数名 "parameters": { //参数项 "city": "纽约", "date": "today" } }并将该指令返回给外部 Agent。
从职责上看，LLM是一个纯粹的数据内核。他并不会直接调用天气服务（
工具），也没有能力去鉴别该工具是否真的可用。Ta只是履行自己的决策角色，在认为需要的时候，反过来要求Agent执行调用。外部 Agent 调用 MCP Server 收到 LLM 的工具调用指令后，Agent 根据 MCP 协议，充当MCP client，把调用请求发送给 MCP Server。请求中包含具体参数（城市、日期等）。
MCP Server 转发请求到天气服务 MCP Server 接到 Agent 的请求后，充当中间件的角色，将请求参数转发给实际的天气服务 API。
天气服务返回数据 天气服务接收到请求后，查询数据库或第三方数据接口，返回例如温度、湿度、天气状况等数据。
MCP Server 将结果返回给 Agent 天气服务的返回结果经由 MCP Server 收到后，再转发回外部 Agent。
Agent 将数据反馈给 LLM 外部 Agent 收到天气数据后，将数据作为上下文信息再次传递给 LLM。这样，LLM 就可以利用查询结果生成最终响应。
这个传递方式，可以是LLM上下文形式，如
json{ "role": "system", "content": "天气服务返回的结果：纽约今天多云，最高温度25°C，最低温度18°C。请基于这个信息生成回答。" }也可以是函数响应方式
json{ "function": "get_weather", "parameters": { "city": "纽约", "date": "today" }, "result": { "temp_max": "25°C", "temp_min": "18°C", "condition": "多云" } }LLM 生成最终回复 LLM 整合用户原始查询与天气数据，生成完整的自然语言回答，例如：“纽约今天多云，最高温度 25°C，最低温度 18°C。”
Agent 将最终答案展示给用户 最后，外部 Agent 把 LLM 的回答展示在用户界面上。
时序图示意
下面给出一个时序图，用来直观展示整个流程：
sequenceDiagram
participant U as 用户
participant A as 外部 Agent (MCP Client)
participant L as LLM
participant M as MCP Server
participant W as 天气服务
U->>A: 输入“查纽约今天天气”
A->>L: 发送查询请求及工具列表
L->>A: 返回工具调用指令\n{ action: "get_weather", parameters: { city:"纽约", date:"today" } }
A->>M: 调用天气服务接口\n传递参数 { city:"纽约", date:"today" }
M->>W: 请求天气数据 for 纽约 today
W-->>M: 返回天气数据（例如：{"temp_max":25, "temp_min":18, "condition":"多云"}）
M-->>A: 将天气数据返回
A->>L: 提供天气数据作为上下文
L->>A: 生成最终回答\n“纽约今天多云，最高温度25°C，最低温度18°C”
A->>U: 展示最终回答整个流程分工非常清晰，Agent负责Client调度、LLM负责决策、MCP server负责提供天气数据。而且因为每次与AI的交互，都可以重新传递上下文，这意味着Agent完全可以在一次用户对话中，在多个LLM之间跨模型调用。比如，你先用DeepSeek推理用户的需求，再用Claude去回答代码问题，最终又使用可灵模型去生成图片，规范而不失灵活。
三、MCP的本质
OK，我们重新来回顾下官方的自我介绍
结构化协议
从示例可以看出，MCP的本质，首先是面向整个产业的一套标准化的接口协议，定义了结构化的请求和响应规范。所以MCP官方宣称自己是AI应用的USB-C端口。
SDK实现
其次，发布该协议的Anthropic公司提供一整套现成的开发框架，主要是client和server两侧的SDK，以帮助三方极简实现，你不需要重复造轮子了。并且该协议是开源的，这意味着，任何人任何公司也可以自行实现。
价值
Anthropic公司所发布的MCP（模型上下文协议），其核心作用是提供一套外部业务数据（或功能）的接入规范，为每一个新构建出来的MCP Server，间接赋予新的跨模型能力，避免每一个AI应用需要为每个数据源（或功能源）的接入写定制代码，或者反过来每一个通用业务系统都要每一个AI应用的调用写定制代码。
其价值，有点类似AI领域的极光推送公司或者银联清算公司了，可以将N-M-K的网状关系复杂度，打平成1-1-1星型结构，从而大幅降低技术成本和合作门槛。
接下来，我们将借助一个叫“全球天气”的AI代理应用，来进一步洞悉这个革命性意义。