MCP over MQTT：EMQX 开启物联网 Agentic 时代

前言

随着 DeepSeek 等大语言模型（LLM）的广泛应用，如何找到合适的场景，并基于这些大模型构建服务于各行各业的智能体成为关键课题。在社区中，支持智能体开发的基础设施和工具层出不穷，其中，Anthropic 推出的 MCP 在连接 LLM 与多源数据方面表现尤为突出。

本文将通过以下几个问题，探讨 MCP 在推动物联网智能化转型方面的潜力与应用前景：

能否利用 MCP 为大量设备赋予智能化的能力？
在物联网场景下，MCP 是否存在一些短板？
如何通过 MQTT 与 MCP 的深度集成，快速将新旧设备接入 AI 应用生态？

MCP 概览

MCP（Model Context Prototol）是由 Anthropic 公司在 2024 年 11 月份推出的开放标准协议‌‌，旨在建立 LLM 与外部数据源、工具和服务之间的标准化通信框架，解决数据孤岛问题，提升 AI 应用与多源信息的交互效率‌。其主要的技术架构与核心组件如下：

MCP Hosts‌：发起请求的 LLM 应用程序（例如 Claude Desktop、IDE 工具等）。
MCP Clients‌：在主机内运行的协议客户端，与服务器保持 1:1 连接‌。
MCP Servers‌：提供上下文、工具和提示信息的轻量级程序，支持本地和远程资源访问（如文件、数据库、API）。

MCP 技术优势与特性

开发简化‌： 一次编写可多次集成，无需为每个新工具重写定制代码‌。
动态交互‌： 支持实时上下文更新与交互，提升响应效率‌。
安全可控‌： 内置访问控制机制，仅允许 LLM 通过明确定义的接口执行授权操作‌。
扩展灵活‌： 通过新增 MCP Server 即可接入新功能，类似「插件化」扩展‌。

MCP 的 AI 应用场景

智能 IDE‌： 通过 MCP 连接代码库、文档，实现上下文感知的编程辅助‌。
数据分析‌： 安全访问本地数据库，执行 SQL 查询并生成可视化报告‌。
工作流集成‌： 与企业内部系统（如 CRM、ERP）集成，自动执行复杂任务‌。

自 MCP 推出以来，与其相关的 Server 服务快速增长。截至目前，mcp.so/servers 上共计有 4245 个相关服务，包含数据/数据库类、云平台、浏览器自动化等多种类型。基于这些服务，各种 Client 应用能够根据自身需求，轻松连接不同的外部数据源及工具，并利用 AI 的推理能力对工作流进行编排和调度，实现智能化应用的快速开发。

MCP 在 IoT 场景中的应用前景

物联网设备通过数据上报让数字世界能够感知实际物理环境，同时，通过暴露的操作接口，允许人类或数字世界对物理世界的设备进行控制和操作，以满足用户的特定需求。当前，大多数物联网系统主要依赖 MQTT 协议进行交互，而 MCP 架构设计与物联网的「物模型」概念非常吻合，这种天然的匹配让 MCP 在物联网领域大有可为，既能兼容现有 MQTT 系统，又能更好地连接设备和 AI 应用。

物模型介绍

物模型是物理空间中实体（如传感器、车载装置、楼宇、工厂等）在云端的数字化表示，它通过属性、服务和事件三个维度来描述实体的特性、功能及其对外提供的信息，从而完成产品功能的定义。

属性： 设备的实时状态数据。例如环境监测设备显示的温度和湿度、智能设备的开关状态等。
服务： 设备可执行的操作指令。服务调用支持设置输入参数（执行条件）和输出参数（执行结果）。例如空调的温度调节、电机的启停控制等。
事件： 设备主动上报给云端的信息。包含需要被外部感知和处理的信息、告警和故障，支持多参数上报。例如设备故障报警、环境异常预警等。

MCP 提供的能力

资源（Resources）： 可供客户端读取的数据内容，例如 API 返回的数据或文件内容等。
工具（Tools）： 在用户批准后，由大型语言模型（LLM）调用的功能模块。
提示词（Prompts）： 预设的模板，以辅助用户完成特定任务。

对比物模型的三个维度和 MCP 提供的能力，可以看出其对应关系：

物模型的属性和事件对应 MCP 的资源，为 LLM 理解物理设备提供了元数据和实时的状态信息；物模型的服务对应 MCP 的工具，允许 LLM 在用户授权后访问相关的信息或调用设备功能。

物模型与 MCP 的高度相似性，为构建 AI 时代的物联网系统提供了可行的结合点：

设备厂商可以提供与设备相关的 MCP 服务，也可以直接将现有的物模型接口（如 HTTP 接口）封装成 MCP 服务，并提供对应的资源、工具和提示词；智能手机等终端应用可以根据用户需求，灵活定义或者编排工作流，自动调用设备的 MCP 服务进行相关操作。

基于 MCP 为 AI 系统提供的设备接入能力，终端用户得以通过自然语言等方式直接与物理设备进行智能交互。例如：在智能家居场景中，用户可以使用自然语言和手机 App 对话「我一个小时后到家，把客厅的温度调整到 25 度，湿度保持在 40」。

MCP 出现之前，该功能的实现需要开发者针对不同的设备型号和版本进行繁琐的接口适配。
MCP 出现之后，诸如 DeepSeek 等 LLM 可以根据用户的自然语言描述，自动理解设备提供的能力，智能调度相关的 MCP 服务，实现设备控制和管理，无需人工编写特定规则或代码，提升了设备之间的互操作性和智能化水平。

MCP 在 IoT 场景中的限制

当前，MCP 协议的设计主要基于标准输入和输出 (stdio) 和 HTTP + SSE 两种方式，前者适合在本地的 MCP Client 与 Server 之间的调用，后者更适合网络远程通信。

在 IoT 场景中，理想的实现方式是在设备端部署 MCP Server，由移动应用等客户端作为 MCP Host 通过 MCP Client 与 MCP Server 进行交互，实现智能编排和调用。然而，在实际应用中存在多种制约：

HTTP 和 SSE 协议对设备资源要求较高，中低端设备受限于存储、计算和电力条件难以支持。
设备通常部署在移动、野外、工厂等网络条件较差的环境，现有方案无法保证服务的可靠性。
物联网已经基于 MQTT 建立起完整的生态，引入 SSE 需要额外构建权限访问控制体系，增加系统负担。
对于仅支持 MQTT 协议的客户端设备，为使用 MCP 协议需要额外引入对 HTTP 的支持。
物联网设备的规模通常达到数万至数十万量级，当前 MCP Client 直连 MCP Server 的设计模式，难以管理大量的设备。

MCP over MQTT 方案构想

为了解决上述问题，EMQ 提出 MCP over MQTT 方案，希望从底层协议上为设备的智能化升级提供帮助。

该方案为不同配置的设备提供差异化支持。

对计算能力受限的设备，提供两种不同的方案：

外置代理方案： 在 EMQX 外部开发和部署 MCP Server，通过 MQTT 协议处理相关的物联网数据，并通过 MCP over MQTT 协议与 MCP Client 进行交互。
内置代理方案： 在 EMQX 内部实现代理 MCP Server，由其代理相关设备的操作。

对于具有较高计算、存储能力的设备，直接提供 MCP over MQTT SDK 开发 MCP Server 的原生方案。

MCP over MQTT 方案将底层网络协议从 HTTP + SSE 转换为 MQTT，显著提升了弱网环境下的通信可靠性。同时，EMQX 作为消息中间件，能够为海量 MCP Server 提供完整的服务发现能力，以及内置的认证、权限管理等功能，提高系统的安全性和稳定性。

外置代理方案

MCP Server（Device 代理）
- 设备通过 MQTT 协议把数据上报给 EMQX，MCP Server 通过订阅相关主题获得设备信息，并利用 MCP 提供的资源（resources）或者工具（tools）将上传的数据暴露出来。
- 设备控制报文同样通过 MQTT 协议经由 EMQX 传递给设备，对外通过 MCP over MQTT 协议把这些工具（tools）暴露出来。
App 应用端
- 通过 MCP over MQTT 协议经由 EMQX 与远程的 MCP Server 进行通信，获取设备相关的状态，以及调用控制指令。
- 也可以通过标准的 MCP 和其他 MCP Server 进行通信，实现与其他系统的集成。

这一方案的最大优势在于，既有的物联网设备无需任何改造即可获得 AI 交互能力，完整保留了 MQTT 协议在低功耗和弱网环境下的固有优势。结合 EMQX 提供的高并发连接和高可用特性，该方案能够快速构建生产可用的智能物联网应用，有效解决了传统设备智能化升级的兼容性和实施成本问题。

内置代理方案

代理方案相较于外置方案，核心改进在于将 MCP Server 直接集成到 EMQX 内部运行，并提供一些内置的工具和能力来提升系统性能（而非减少 EMQX 和 MCP Server 之间跨越的节点数）。同时，由于 MCP Server 作为 EMQX 的内置组件运行，显著降低了运维复杂度，使得 MCP Server 应用的开发和管理更加便捷高效。

原生（Native）方案

原生方案面向具备高性能计算和存储能力的高附加值新型设备（如智能汽车、3D 打印机等），通过在设备端原生集成 MCP 服务，直接采用 MCP over MQTT 协议与 EMQX 建立通信连接。该方案中，MCP Client 通过标准化的 MCP over MQTT 协议直接与设备端的 MCP Server 进行交互，实现端到端的智能化控制。例如：

现在有两台 3D 打印机，service-name 分别为：

3D-Printer/ACH301/EECF7892AB1
3D-Printer/ACH301/CAED99C2EE2

其中 3D-Printer/ACH301/ 是分层级的设备类型，而 EECF7892AB1, CAED99C2EE2 是设备 ID。

客户端（移动端 App) 首先查询当前用户名的权限，比如，通过查询得知只能访问 ACH301 型号的打印机。然后通过订阅相关的主题来获取 ACH301 打印机支持的 tools（即该打印机的对外提供的能力），App 就可以实现对这个设备的智能化调用。

这种新型的智能化物联网平台架构，适用于 M2M 的场景： 设备厂商可以在设备里内置功能完善的 MCP Server（包括建议的提示词模板），物联网平台采购设备之后，无需为每种设备单独编写指令，通过统一的客户端智能化访问，实现了专业化的分工：

设备厂商专注于设备侧功能的实现；
物联网平台专注于提升智能客户端（包括语音交互等）的用户体验。

MCP over MQTT 协议初探

特性

MCP over MQTT 将会在保留 MCP 原有功能的基础上，增加以下能力：

服务发现：通过 MQTT 协议的保留消息和遗嘱消息等特性，MCP Clients 可以自动发现可用的 MCP Servers。
服务端线性伸缩：通过 MQTT 协议的共享订阅特性，MCP Server 在保持服务状态（Stateful）的情况下，实现了线性的扩容和缩容。
中心化认证：依赖 MQTT Broker 作为中心化的消息中间件，有更多成熟的认证和鉴权方案可用。

未来，通过在 MQTT Broker 中集成 MCP Server 插件的方式，还可以进一步简化 MCP Server 部署难度并优化数据传输效率。

限制

MCP over MQTT 协议主要面向远程部署 MCP Server 的场景，其架构设计依赖于中心化 MQTT Broker 的支撑。虽然本地部署的 MCP Server 也能够使用 MCP over MQTT 协议，但可能会增加部署上的复杂性。

总结和展望

目前，EMQ 已完成 MCP over MQTT 技术方案的初步验证，并构建原型系统进行测试。研发团队正聚焦协议架构的标准化设计与工程实现，下一阶段将针对关键的技术节点展开深度验证与性能优化。

我们可以预见，这一方案的落地将为物联网领域开启一个崭新的 Agentic 时代：EMQX Platform 提供协议适配与中心化服务管理能力，解决数据孤岛与碎片化瓶颈；DeepSeek 等 LLM 提供自然语言理解与推理能力，将用户需求动态转化为设备可执行的操作流。

通过两者结合，企业可以将海量异构设备无缝接入基于 MCP 的 AI 生态，大幅降低老旧设备智能化改造成本，同时获得快速构建跨场景、跨系统的智能应用能力。基于 MCP over MQTT 的 Agentic IoT 将真正实现从「万物互联」到「万物智联」的转变，重塑企业的智能化转型之路。

版权声明：本文为 EMQ 原创，转载请注明出处。原文链接：www.emqx.com/zh/blog/mcp...