本系列教程路线图
| 篇章 | 功能 | 难度 |
|---|---|---|
| 1 | 整体介绍：背景 + 环境准备 + 设备上线 | ★ |
| 2 | 从“命令式控制”到“语义控制”：MCP over MQTT 封装设备能力 | ★★ |
| 3 | 接入 LLM，实现“自然语言 → 设备控制” | ★★ |
| 4 | 语音 I/O：麦克风数据上传 + 语音识别 + 语音合成回放 | ★★★ |
| 5 | 人格、情感、记忆：从“控制器”到“陪伴体” | ★★★ |
| 6 | 给智能体增加“眼睛”：图像采集 + 多模态理解 | ★★★ |
回顾
在上一篇文章中，我们已经完成了基础准备工作：
- 搭建了开发环境，烧录 ESP32 并成功连接 MQTT Broker
- 实现了设备上线心跳，让云端可以感知设备是否在线
- 初步了解了 ESP32 + MQTT 的 IoT 通信模式
然而，传统的 IoT 控制是「命令式」的，存在明显的局限性。开发者必须事先定义主题（topic）、硬编码命令格式，这让 AI 难以「理解」和「调用」设备的真实能力。
如果我们想让大模型直接与设备对话，就需要让 AI 突破以下限制：
- 自动「发现」设备具备哪些功能（例如：调节音量、设定屏幕文字）。
- 通过统一的工具调用接口调用这些功能，而不是依赖硬编码指令。
在本文中，我们将前文搭建的 MQTT 基础扩展为 MCP over MQTT 架构，让设备的各种能力将以「工具（Tool）」的形式被注册、发现和调用，为 AI 与物联网设备的智能交互开辟新的可能。
为什么 IoT 需要 MCP？
目前，传统 IoT 设备大多依赖「命令式控制」模式：
- 应用通过硬编码主题 (topic) 发布指令，如
esp32/set/brightness，在消息体中指定设定的亮度的值。 - 每个设备、每个命令都需要实现该接口规范，后续扩展新功能时需要手动更新代码。
在 AI 大模型直接与 IoT 设备对话的过程中，会出现以下问题：
- AI 怎么知道设备有哪些能力？
- 调用时怎么理解参数的格式和范围？
- 如何做到像调用函数一样「自然」地控制设备？
MCP over MQTT 方案可以有效地解决这些问题：
- 它提供了标准化的工具描述（Tool Schema），让 AI 能「发现」设备能力。
- IoT 设备只需声明「我能做什么」（例如：调节音量、设定屏幕文字）。
- AI 通过 MCP 查询工具列表、调用工具，无需额外适配层。
MCP SSE：大模型通过封装的 HTTP 接口对接设备
目前 MCP 主要通过 SSE（Server-Sent Events）或标准输入/输出来对接第三方服务。最便捷的方式是复用现有 HTTP 接口，将设备数据和控制能力（如大部分物联网平台中已有的物模型服务）直接封装为 MCP 工具。该方案特别适用于已经通过 HTTP API 提供设备控制和状态查询能力的用户。
优点
- **快速集成：**无需对已出厂设备进行大规模改造，只需在服务器端增加 MCP 适配层，即可快速接入大模型。
- **兼容性高：**适配 HTTP 接口的 MCP 层可无缝复用已有物模型和 API 设计。
不足
- **架构冗余：**大模型与设备之间隔着 HTTP 物模型服务和 MCP 适配服务，导致消息在 MQTT 与 HTTP 之间需要多次协议转换，增加延迟并降低实时性。
- **复杂度上升：**多层适配让软件开发与调试难度增大。
- **安全与维护压力：**当前 SSE 方案需要重新设计认证与权限控制机制，无法直接复用 IoT 平台的原有认证体系，带来额外的开发、维护成本及潜在安全隐患。
MCP over MQTT：LLM 直接对接设备
针对 SSE 方案存在的多层转发、延迟和安全复杂性，我们提出 MCP over MQTT 架构。该方案让设备直接通过 MQTT 注册自身能力，大模型或应用可直接发现和调用这些能力，无需经过 HTTP 物模型服务或 MCP 适配层。
优点
- **架构更简化：**移除了云端「物模型服务」和「MCP 服务 (SSE)」，整体链路更轻量。
- **低延迟调用：**App 或 LLM 可直接通过 MQTT 调用设备端工具，无需中间转发。
- **开发效率高：**减少了协议转换和适配逻辑，缩短开发和调试周期，提高可扩展性。
- **集中化管理：**MCP 服务的注册、发现、服务类型归类，以及 MCP 消息流转、权限控制等功能统一在 MQTT Broker 上完成。
- **安全可复用：**可直接继承现有物联网平台的认证与权限控制机制，提高开发效率。
不足
- **设备需升级：**对于未内置 MCP 支持的已出厂设备，若无 OTA 能力，需要重新烧录或升级固件。
- **离线问题：**设备离线时无法调用，需要设计离线任务缓存、失败重试或状态同步机制。
MCP SSE vs. MCP MQTT
| 对比维度 | 方案 1：MCP SSE（基于 HTTP 接口） | 方案 2：MCP over MQTT（原生 AI 架构） |
|---|---|---|
| 架构复杂度 | 高：需 HTTP 物模型服务 + MCP 适配服务，协议栈较冗余 | 低：设备直接注册工具，去掉中间适配层 |
| 调用延迟 | 较高：MQTT ⇄ HTTP 多次协议转换 | 低：MQTT 原生通信，调用链更短 |
| 开发成本 | 高：云端需维护物模型服务和适配层，设备能力变动需同步更新 | 低：无需额外 HTTP 接口封装，开发和调试更高效 |
| 兼容性 | 高：适用于已通过 HTTP 暴露控制接口的存量设备 | 中：需设备端升级支持 MCP（无 OTA 需重新烧录） |
| 安全性 | 弱：SSE 原生认证/权限较弱，需额外设计安全机制 | 强：可直接复用 IoT 平台原有认证与权限控制 |
| 扩展性 | 一般：每新增设备能力都需更新 HTTP 层 | 强：设备动态注册工具，LLM 可自动发现设备能力 |
| 实时性 | 一般：延迟较高，适合非强实时任务 | 强：MQTT 原生架构，低延迟调用 |
目前还有一些方案采用基于 HTTP 的 WebSocket 协议实现设备到云端的通信，但相比之下，MQTT 在物联网场景中更具优势，尤其在协议轻量性、传输效率和低功耗等方面表现更优。
读者可参考：MQTT 与 WebSocket：关键差异与应用场景一文，了解二者的详细对比。
MCP over MQTT 封装能力
目标：通过 MCP over MQTT 封装调整音量以及让屏幕显示信息。
硬件
- ESP32 S3 开发版
- 功放 2-3W 以及 喇叭
- SPI 接口液晶显示屏
软件
- 在 ESP32 上开发两个 MCP 工具，并向 EMQX Servless 进行注册
display，用于调整显示内容set_volume，用于调整音量，参数可以设定为 0 - 100
- 云端开发使用 Python 实现的 MCP 客户端
- 列出设备端注册的工具列表
- 查看工具描述
ESP32 MCP 工具实现代码 (C 语言实现)
MCP over MQTT SDK
下载 MCP over MQTT SDK component
#include <stdio.h>
#include "freertos/FreeRTOS.h"
#include "esp_log.h"
#include "esp_system.h"
#include "nvs_flash.h"
#include "mcp.h"
#include "mcp_server.h"
#include "wifi.h"
const char *set_volume(
最低0.47元/天 解锁文章
扫一扫
1228
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
