Plain Language Large Model — MCP深入浅出 MCP从 C/S 架构到动态工具发现的完整技术解析本文基于课堂实录整理带你从零理解 Model Context ProtocolMCP的架构本质、核心组件分工、通信部署差异以及它相比传统工具调用为何能实现“零代码扩展”。一、先搞清定位MCP 为什么是 C/S 架构在聊 MCP 之前老师先用两个我们每天都在用的应用把C/SClient/Server和B/SBrowser/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 或其他 IDEMCP 的配置页面会完全不同。但只要你能制作出满足标准 MCP 客户端协议要求的应用你就是一个合格的 MCP Host。它不像 QQ 或微信那样必须“长成一个聊天窗口的样子”才算客户端。Host 的核心职责包括协议握手与远端 MCP Server 建立连接。连接成功后界面通常会打上一个“对勾”代表握手成功——这意味着你的客户端已经连通了高德服务器或飞友开放平台的 Server服务可以直接使用。工具能力发现识别并列出 Server 提供了哪些能力。比如高德会提供骑行路径规划、驾车路径规划等飞友平台也会提供自己的工具能力。Host 把这些能力展示出来用户才知道能调用什么。请求转发接收用户的自然语言指令处理后转发给 Server并将最终结果返回给用户。比如你在输入框里用自然语言说“查询北京故宫博物院的坐标并用这个坐标规划路线测量两次旅游之间的距离”Host 会接收这段文字经由内部链路转发处理。2. MCP ClientLLM 与 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 的 SSEServer-Sent Events协议那么 MCP Server 通常位于远端服务器集群中。比如连接高德 MCP Server 时Server 运行在高德的云端你本地的 Client 通过网络 HTTP 与高德的集群通信。飞友开放平台的 MCP Server 同样位于其远端服务器上。Stdio 模式本地部署如果你使用的是StdioStandard 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大模型。大模型进行意图分析和决策规划出需要调用的工具及顺序。比如先调用 Geo 工具查询故宫位置再调用距离工具计算故宫到天安门的距离判断应该步行还是乘坐公交车。第四步工具执行处理MCP Client 将 LLM 的决策“翻译”为具体的 MCP 协议请求分步调用 Server 的工具。比如先发起第一个请求确定北京故宫位置获取结果后再发起第二个请求查询距离。这是一个循环调用的过程直至获取所有必要结果。第五步结果整合与回答输出所有工具的原始输出会被收集起来连同用户的原始问题和应用预设的提示词Prompt一起再次发送给 LLM。LLM 结合这些数据进行加工生成一段用户友好的自然语言回答。第六步渲染与反馈应用Host拿到 LLM 返回的内容通常是 Markdown 格式后对页面进行渲染排版最终把美观、易读的答案展示给用户完成整个闭环。工作流总结用户指令 → Host → Client协议转换→ Server业务处理→ Client协议转换→ Host → LLM 加工 → 渲染展示 → 用户五、MCP 与传统工具调用为什么协议化是降维打击为了突出 MCP 的价值老师用一张对比表把传统方式和 MCP 方式做了鲜明对比。维度传统工具调用方式MCP 协议方式工具注册必须在 Prompt 中硬编码列出所有工具如工具1到工具10启动时或首次请求时自动询问并获取工具清单扩展性依赖开发人员手动修改代码和提示词新增工具极其困难服务端提供新工具后客户端可自动发现并调用无需修改核心逻辑格式标准各工具格式千奇百怪需要单独适配遵循统一的标准 MCP 协议格式握手机制无特定标准化握手流程最新协议简化了握手可在首次请求工具时一并完成耦合度应用需要关心底层工具实现细节应用只关心标准协议彻底解耦传统方式完全依赖开发者的工程能力做静态配置你要先写 Tool1、Tool2……Tool10然后在 Prompt 里告诉大模型“我有这 10 个工具请你分析用哪个”。一旦新增第 11 个工具你就得改代码、改 Prompt。而 MCP 的优势在于动态发现与标准化你只要遵循 MCP 协议服务端上新能力后Client 在启动或首次请求时就能自动拿到新工具清单。工具的格式虽然以前千奇百怪但在 MCP 下必须按标准协议来Client 都能认识。这极大地简化了扩展流程实现了“简单配置即可连接不同服务”。六、课堂总结MCP 的本质与价值课程最后老师带着大家做了小结架构本质MCP 是基于C/S 架构的标准协议体系区别于浏览器-based 的 B/S 架构。核心组件分工MCP Host集成 Client 的应用如 Trea 编辑器负责握手、能力发现及用户交互。MCP Client负责协议“翻译”与请求转发是 LLM 与 Server 之间的通信桥梁。MCP Server负责提供工具能力并执行具体业务逻辑是真正干苦活、脏活、累活的地方。扩展机制通过标准化的协议格式和动态握手机制新服务接入无需修改应用核心代码解决了传统硬编码方式扩展性差的痛点。应用场景无论是连接高德地图查坐标、连接飞友平台查航班还是未来连接麦当劳点餐只要双方遵循 MCP 协议应用侧只需简单配置即可实现能力拓展。MCP 正在做的事情本质上是为 AI 时代的应用与大模型之间建立一门通用的“标准语言”。当协议统一了能力的连接就不再是工程难题而变成了一次简单的握手。 
长河君 · 2026/11/3 2:49:51 · 阅读 1.2k 【Plain Language Large Model】【MCP架构解析：从C/S模式到动态工具发现的完整技术要点】流食般投喂
Plain Language Large Model — MCP深入浅出 MCP从 C/S 架构到动态工具发现的完整技术解析本文基于课堂实录整理带你从零理解 Model Context ProtocolMCP的架构本质、核心组件分工、通信部署差异以及它相比传统工具调用为何能实现“零代码扩展”。一、先搞清定位MCP 为什么是 C/S 架构在聊 MCP 之前老师先用两个我们每天都在用的应用把C/SClient/Server和B/SBrowser/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 或其他 IDEMCP 的配置页面会完全不同。但只要你能制作出满足标准 MCP 客户端协议要求的应用你就是一个合格的 MCP Host。它不像 QQ 或微信那样必须“长成一个聊天窗口的样子”才算客户端。Host 的核心职责包括协议握手与远端 MCP Server 建立连接。连接成功后界面通常会打上一个“对勾”代表握手成功——这意味着你的客户端已经连通了高德服务器或飞友开放平台的 Server服务可以直接使用。工具能力发现识别并列出 Server 提供了哪些能力。比如高德会提供骑行路径规划、驾车路径规划等飞友平台也会提供自己的工具能力。Host 把这些能力展示出来用户才知道能调用什么。请求转发接收用户的自然语言指令处理后转发给 Server并将最终结果返回给用户。比如你在输入框里用自然语言说“查询北京故宫博物院的坐标并用这个坐标规划路线测量两次旅游之间的距离”Host 会接收这段文字经由内部链路转发处理。2. MCP ClientLLM 与 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 的 SSEServer-Sent Events协议那么 MCP Server 通常位于远端服务器集群中。比如连接高德 MCP Server 时Server 运行在高德的云端你本地的 Client 通过网络 HTTP 与高德的集群通信。飞友开放平台的 MCP Server 同样位于其远端服务器上。Stdio 模式本地部署如果你使用的是StdioStandard 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大模型。大模型进行意图分析和决策规划出需要调用的工具及顺序。比如先调用 Geo 工具查询故宫位置再调用距离工具计算故宫到天安门的距离判断应该步行还是乘坐公交车。第四步工具执行处理MCP Client 将 LLM 的决策“翻译”为具体的 MCP 协议请求分步调用 Server 的工具。比如先发起第一个请求确定北京故宫位置获取结果后再发起第二个请求查询距离。这是一个循环调用的过程直至获取所有必要结果。第五步结果整合与回答输出所有工具的原始输出会被收集起来连同用户的原始问题和应用预设的提示词Prompt一起再次发送给 LLM。LLM 结合这些数据进行加工生成一段用户友好的自然语言回答。第六步渲染与反馈应用Host拿到 LLM 返回的内容通常是 Markdown 格式后对页面进行渲染排版最终把美观、易读的答案展示给用户完成整个闭环。工作流总结用户指令 → Host → Client协议转换→ Server业务处理→ Client协议转换→ Host → LLM 加工 → 渲染展示 → 用户五、MCP 与传统工具调用为什么协议化是降维打击为了突出 MCP 的价值老师用一张对比表把传统方式和 MCP 方式做了鲜明对比。维度传统工具调用方式MCP 协议方式工具注册必须在 Prompt 中硬编码列出所有工具如工具1到工具10启动时或首次请求时自动询问并获取工具清单扩展性依赖开发人员手动修改代码和提示词新增工具极其困难服务端提供新工具后客户端可自动发现并调用无需修改核心逻辑格式标准各工具格式千奇百怪需要单独适配遵循统一的标准 MCP 协议格式握手机制无特定标准化握手流程最新协议简化了握手可在首次请求工具时一并完成耦合度应用需要关心底层工具实现细节应用只关心标准协议彻底解耦传统方式完全依赖开发者的工程能力做静态配置你要先写 Tool1、Tool2……Tool10然后在 Prompt 里告诉大模型“我有这 10 个工具请你分析用哪个”。一旦新增第 11 个工具你就得改代码、改 Prompt。而 MCP 的优势在于动态发现与标准化你只要遵循 MCP 协议服务端上新能力后Client 在启动或首次请求时就能自动拿到新工具清单。工具的格式虽然以前千奇百怪但在 MCP 下必须按标准协议来Client 都能认识。这极大地简化了扩展流程实现了“简单配置即可连接不同服务”。六、课堂总结MCP 的本质与价值课程最后老师带着大家做了小结架构本质MCP 是基于C/S 架构的标准协议体系区别于浏览器-based 的 B/S 架构。核心组件分工MCP Host集成 Client 的应用如 Trea 编辑器负责握手、能力发现及用户交互。MCP Client负责协议“翻译”与请求转发是 LLM 与 Server 之间的通信桥梁。MCP Server负责提供工具能力并执行具体业务逻辑是真正干苦活、脏活、累活的地方。扩展机制通过标准化的协议格式和动态握手机制新服务接入无需修改应用核心代码解决了传统硬编码方式扩展性差的痛点。应用场景无论是连接高德地图查坐标、连接飞友平台查航班还是未来连接麦当劳点餐只要双方遵循 MCP 协议应用侧只需简单配置即可实现能力拓展。MCP 正在做的事情本质上是为 AI 时代的应用与大模型之间建立一门通用的“标准语言”。当协议统一了能力的连接就不再是工程难题而变成了一次简单的握手。