关于MCP的调研
MCP简介
MCP其实就是一个基于Json的交互协议，为了方便大模型去生成相应控制指令，规定了一些字段。
MCP提供Client和Server，Client的职责相当于一个转接头，一边是LLM，一边是其他服务。
Server负责告诉Client自己有哪些服务，接受Client传来的命令，并执行相关动作。
典型交互的流程
sequenceDiagram
title MCP Client、大模型与MCP Server交互流程（LLM居左）
participant LLM as 大模型（LLM）
participant Client as MCP Client（应用程序）
participant Server as MCP Server（协议服务端）
Note over LLM,Server: 初始化阶段：建立协议连接
Client->>Server: 1. 发送MCP协议连接请求（携带版本信息）
Server-->>Client: 2. 返回连接成功响应（包含支持的集成类型）
Client->>LLM: 3. 同步MCP服务可用状态（告知可调用资源）
Note over LLM,Client: 任务触发阶段：明确上下文需求
LLM->>Client: 4. 接收用户任务（或主动发起处理需求）
LLM-->>Client: 5. 输出上下文依赖（需外部补充的数据/工具）
Note over Client,Server: 资源调用阶段：标准化集成交互
Client->>Server: 6. 按MCP规范发送集成调用请求（携带需求参数）
Server->>Server: 7. 执行对应集成操作（调用数据源/第三方工具）
Server-->>Client: 8. 返回标准化格式的集成结果（符合MCP数据规范）
Note over Client,LLM: 结果生成阶段：整合上下文输出
Client->>LLM: 9. 提交完整上下文（含集成结果+原始任务）
LLM-->>Client: 10. 基于完整信息生成最终结果
Client->>LLM: 11. （可选）同步上下文快照（支持跨应用复用）
Note over LLM,Server: 核心逻辑：MCP Client作为中间层，实现LLM与外部资源的标准化交互
可以观察到，MCP Client主要承担LLM和执行机构的沟通功能，同时也负责对用户的交互功能。
通信方式
MCP官方SDK已实现两种通讯方式，一个是SSE（基于HTTP server），一个是STDIO（标准输入输出，实质上是一种进程间通讯）。
SSE常用于服务部署在远端服务器的情况下，比如查询天气、查询路况等功能。STDIO常用于服务和Client部署在同一设备种的情况。
同时，MCP还提供了第三种自定义方式，用户可以根据接口自己实现通讯链路，目前看到的比较好的实践是基于MQTT进行通讯。这个方式无疑是嵌入式设备的最佳选择。可以基于原有的MQTT链路添加MCP协议。
对于IPC类产品的几种落地方案
-
MCP Server部署在云端，云端注册IOT指令为MCP服务，Client可以放在APP上，当用户进行交互，Client先访问大模型，再去调用云端的Server，Server给对应设备下发对应指令。
这种方式优点是固件不需要大改动，云端部署有现成SDK可以使用，比较快。
缺点是延迟可能会比较高。 -
MCP Server和MCP Client都部署在固件端侧，使用STDIO方式进行通讯。用户通过其他方式比如P2p将指令下发给固件，固件中的Client访问大模型并操作Server。
这种方式优点是延迟低，缺点是没有现成代码可以使用，需要用C从头实现一套MCP协议。开发时间会比较长。
-
MCP server部署在固件端侧，Client部署在云端，使用自定义方式（比如MQTT）进行通讯。用户将指令发送给云端，云端访问大模型后，再通过MQTT将指令发送给端侧的Server。
这种方式是最高效的，缺点是两边的代码都要重新写。没有现成方案。