网硕互联帮助中心📝 Plain Language Large Model — MCP
深入浅出 MCP：从 C/S 架构到动态工具发现的完整技术解析
本文基于课堂实录整理，带你从零理解 Model Context Protocol（MCP）的架构本质、核心组件分工、通信部署差异，以及它相比传统工具调用为何能实现“零代码扩展”。
一、先搞清定位：MCP 为什么是 C/S 架构？
在聊 MCP 之前，老师先用两个我们每天都在用的应用，把 C/S（Client/Server） 和 B/S（Browser/Server） 的区别讲透了。
最典型的 C/S 架构 就是微信。无论你用 PC 端还是手机端，都必须先在本机安装一个“胖客户端”。你发朋友圈、传文件、开小程序，背后都依赖微信庞大的服务器集群做消息转发和业务处理。并且，微信的协议是专用或定制的——如果你抓过微信的包，会发现它的协议格式并不是通用的，而是私有协议。
而 B/S 架构 的代表是百度搜索。你不需要安装一个“百度 APP”才能搜索，只需在地址栏输入网址就能访问。这里的“客户端”已经退化为浏览器，因此也被称为瘦客户端，甚至无客户端。为什么叫无客户端？因为无论是手机、电脑、Windows 还是 Mac，系统都内置了浏览器，你不需要额外安装任何东西。
MCP 的定位非常明确：它属于典型的 C/S 架构。它包含 MCP Client（客户端）和 MCP Server（服务端），两者之间通过标准的 MCP 协议进行通信。在架构示意图中，绿色部分代表 MCP Client，红色部分代表 MCP Server。
这里会出现一个容易混淆的概念：MCP Host。你可以把 Host 理解为集成了 MCP Client 能力的宿主应用。比如实战中的 Trea 这个AI原生IDE，它内部集成了 MCP Client，右侧通过标准 MCP 协议连接高德地图的 MCP Server，完成能力拓展。Host 就是连接用户与服务端的桥梁。
二、三大核心组件：谁是翻译官，谁是苦力？
1. MCP Host：集成 Client 的“宿主”
MCP Host 本质上就是一个集成了 MCP Client 模块的应用程序。以 Trea 为例，你在设置里能看到专门的 MCP 配置页面。它之所以能配置 MCP，就是因为 Trea 内部集成（内嵌）了 MCP Client。
这里老师特别补充了一点：Host 的界面没有固定标准。如果你换成 Pass 或其他 IDE，MCP 的配置页面会完全不同。但只要你能制作出满足标准 MCP 客户端协议要求的应用，你就是一个合格的 MCP Host。它不像 QQ 或微信那样必须“长成一个聊天窗口的样子”才算客户端。
Host 的核心职责包括：
- 协议握手：与远端 MCP Server 建立连接。连接成功后界面通常会打上一个“对勾”，代表握手成功——这意味着你的客户端已经连通了高德服务器或飞友开放平台的 Server，服务可以直接使用。
- 工具能力发现：识别并列出 Server 提供了哪些能力。比如高德会提供骑行路径规划、驾车路径规划等；飞友平台也会提供自己的工具能力。Host 把这些能力展示出来，用户才知道能调用什么。
- 请求转发：接收用户的自然语言指令，处理后转发给 Server，并将最终结果返回给用户。比如你在输入框里用自然语言说“查询北京故宫博物院的坐标，并用这个坐标规划路线，测量两次旅游之间的距离”，Host 会接收这段文字，经由内部链路转发处理。
2. MCP Client：LLM 与 Server 之间的“翻译官”
如果说 Host 是面向用户的窗口，那么 MCP Client 就是专门负责协议转换与请求转发的代理。
Client 主要干两件事：
- 请求接收与转换：它接收来自 LLM（大模型，如豆包、DeepSeek 等）的诉求——可能是自然语言，也可能是已经工程化、结构化的标准格式。但 Server 只认 MCP 协议，所以 Client 必须把这些请求“翻译”成标准的 MCP 协议格式，再发送给 MCP Server。
- 响应处理：Server 处理完后，返回的是标准 MCP 协议数据。Client 再把它逆向转换，变成 LLM 或 Host 能识别的格式，最终返回给上层。
核心边界：Client 只专注于协议的“翻译”和双向转发，不直接执行业务逻辑。它是 LLM 与 Server 之间的通信桥梁。
3. MCP Server：真正干“苦活、脏活、累活”的执行者
名字里的“Server”就注定了它的角色——能力提供方。
- 提供工具能力：比如高德地图 MCP Server 会提供坐标查询、路径规划等工具；飞友平台有航班相关工具；甚至老师还举了一个有趣的例子：麦当劳服务，以后可能直接通过 MCP 在 Trea 里下单。
- 处理请求：当 Client 把标准协议请求发过来后，Server 真正去查北京故宫的坐标、计算两地距离、规划步行路线。处理完成后，再用标准 MCP 协议把结果打包返回。
一句话总结：真正负责干活、Query 数据库、做业务运算的，都是 MCP Server。
三、通信协议与部署模式：Server 到底跑在哪？
这一部分是课堂上的补充知识点，但非常重要，因为它直接决定了 Server 的物理位置。
SSE/HTTP 模式：远端部署
如果你使用的是基于流式 HTTP 的 SSE（Server-Sent Events）协议，那么 MCP Server 通常位于远端服务器集群中。比如连接高德 MCP Server 时，Server 运行在高德的云端，你本地的 Client 通过网络 HTTP 与高德的集群通信。飞友开放平台的 MCP Server 同样位于其远端服务器上。
Stdio 模式：本地部署
如果你使用的是 Stdio（Standard Input/Output，标准输入输出） 方式，那么它不支持跨网络通信。此时 MCP Server 就运行在你的本地机器上，与 MCP Client 同处一台设备。
为了验证这一点，老师现场做了一个小实验：通过 Node.js 启动本地 MCP Server（如飞友开放平台的本地服务），然后打开系统的任务管理器，你能看到对应的 Node 进程；一旦你把服务关掉，这两个进程就会立刻消失。这就直观地证明了：Stdio 模式下，Server 就在你的本机运行。
不要忽略的细碎知识点：老师专门提醒，虽然 Stdio 通常用于本地，但凡事都有例外。如果你自己编写了一个 MCP Server（比如一个 Local Host），虽然名字叫“Local”，但它内部也可能采用 HTTP 协议通信。具体是远端还是本地，要根据实际实现和协议去区分，不能只看名字。
四、MCP 完整工作流程：从提问到回答的七步闭环
理解了组件分工后，老师用“查询北京故宫坐标”和“计算故宫到天安门距离”的例子，把 MCP 的完整工作流跑了一遍。
第一步：需求发起（输入）
用户在 Host 界面输入自然语言指令，比如：“北京故宫的坐标是哪里？”“北京故宫到天安门有多远？”
第二步：握手与发现（连接）
Host 识别到需要调用 MCP 服务，于是让 MCP Client 与 MCP Server 进行握手。握手的本质是确认客户端与服务器之间的连通性是否正常。
这里老师补充了一个协议优化点：最新版本的 MCP 协议简化了握手过程，允许在首次请求工具时，把“握手确认”和“获取工具清单”一并完成，提升了交互效率。
连接成功后，Client 会主动询问 Server：“你现在有哪些可用工具？” Server 返回当前支持的工具清单（比如 Geo 地理工具、距离计算工具）。这一步彻底替代了传统方式里在 Prompt 中硬编码工具列表的做法。
第三步：模型决策（智能）
Host 将用户的原始问题加上获取到的工具清单整合在一起，发送给背后的 LLM（大模型）。大模型进行意图分析和决策，规划出需要调用的工具及顺序。比如：
第四步：工具执行（处理）
MCP Client 将 LLM 的决策“翻译”为具体的 MCP 协议请求，分步调用 Server 的工具。比如先发起第一个请求确定北京故宫位置，获取结果后，再发起第二个请求查询距离。这是一个循环调用的过程，直至获取所有必要结果。
第五步：结果整合与回答（输出）
所有工具的原始输出会被收集起来，连同 用户的原始问题 和 应用预设的提示词（Prompt） 一起，再次发送给 LLM。LLM 结合这些数据进行加工，生成一段用户友好的自然语言回答。
第六步：渲染与反馈
应用（Host）拿到 LLM 返回的内容（通常是 Markdown 格式）后，对页面进行渲染排版，最终把美观、易读的答案展示给用户，完成整个闭环。
工作流总结：
用户指令 → Host → Client（协议转换）→ Server（业务处理）→ Client（协议转换）→ Host → LLM 加工 → 渲染展示 → 用户
五、MCP 与传统工具调用：为什么协议化是降维打击？
为了突出 MCP 的价值，老师用一张对比表，把传统方式和 MCP 方式做了鲜明对比。
| 工具注册 | 必须在 Prompt 中硬编码列出所有工具（如工具1到工具10） | 启动时或首次请求时自动询问并获取工具清单 |
| 扩展性 | 依赖开发人员手动修改代码和提示词，新增工具极其困难 | 服务端提供新工具后，客户端可自动发现并调用，无需修改核心逻辑 |
| 格式标准 | 各工具格式千奇百怪，需要单独适配 | 遵循统一的标准 MCP 协议格式 |
| 握手机制 | 无特定标准化握手流程 | 最新协议简化了握手，可在首次请求工具时一并完成 |
| 耦合度 | 应用需要关心底层工具实现细节 | 应用只关心标准协议，彻底解耦 |
传统方式完全依赖开发者的工程能力做静态配置：你要先写 Tool1、Tool2……Tool10，然后在 Prompt 里告诉大模型“我有这 10 个工具，请你分析用哪个”。一旦新增第 11 个工具，你就得改代码、改 Prompt。
而 MCP 的优势在于动态发现与标准化：你只要遵循 MCP 协议，服务端上新能力后，Client 在启动或首次请求时就能自动拿到新工具清单。工具的格式虽然以前千奇百怪，但在 MCP 下必须按标准协议来，Client 都能认识。这极大地简化了扩展流程，实现了“简单配置即可连接不同服务”。
六、课堂总结：MCP 的本质与价值
课程最后，老师带着大家做了小结：
- MCP Host：集成 Client 的应用（如 Trea 编辑器），负责握手、能力发现及用户交互。
- MCP Client：负责协议“翻译”与请求转发，是 LLM 与 Server 之间的通信桥梁。
- MCP Server：负责提供工具能力并执行具体业务逻辑，是真正干苦活、脏活、累活的地方。
MCP 正在做的事情，本质上是为 AI 时代的应用与大模型之间，建立一门通用的“标准语言”。当协议统一了，能力的连接就不再是工程难题，而变成了一次简单的握手。
评论前必须登录！
注册