用n8n+MCP+ESP8266做一个能听懂人话的AI智能家居

一句话就能让房间里的灯全部亮起，抱怨一句「太暗了」它就知道该关哪盏灯——这不是科幻电影，而是一个大学生用 n8n、MCP 协议和一块 ESP8266 搭出来的真实项目。

项目概览：AI Agent「Bob」是什么

开发者 Mohamad Faisal Putra 在 YouTube 上展示了他的智能家居课程项目——一个名为 Bob 的 AI 语音助手。用户对着网页说话，Bob 能读取环境中的温度、湿度和距离数据，也能控制 6 个电器设备（以 6 颗 LED 灯模拟空调、洗衣机、冰箱等）。

整个系统的核心思路是：让大语言模型通过 MCP 协议调用真实硬件工具，而不是仅仅生成文字回复。这意味着当你问「现在室温多少」，Bob 不会瞎编一个数字，而是真的去读取 DHT22 传感器的数据再回答你。

ESP8266硬件搭建

四层架构拆解

第一层：语音输入与前端

用户通过浏览器页面说话，Web Speech API 负责将语音转成文本，然后通过 Webhook 把文字发送到 n8n 工作流。Agent 的文本回复最终也会被浏览器朗读出来，形成完整的语音交互闭环。

Web Speech API 是浏览器原生提供的 JavaScript 接口，其中 SpeechRecognition 负责把麦克风采集的音频转写为文本，SpeechSynthesis 负责把文本朗读出来，开发者无需引入第三方语音服务即可实现基础语音交互。需要注意的是，Web Speech API 的识别质量依赖浏览器实现，Chrome 等主流浏览器背后通常调用云端语音服务，因此并非完全离线；同时它目前对非英语语言和嘈杂环境的鲁棒性仍有限。在 Bob 这个项目中，浏览器承担了「耳朵」和「嘴巴」的角色，真正决定语义理解质量的仍是后端接入的 Gemini 模型。这种前轻后重的分工也是许多 Web 端 AI 应用的常见结构。

第二层：n8n 中的 AI Agent

n8n 工作流是整个系统的大脑。核心节点是一个接入了 Gemini 模型的 AI Agent，配备了对话记忆和工具调用能力。

这里有一个值得注意的设计选择：开发者接入了 Wikipedia 作为通用知识来源。原因是这样处理常识性问题最省事——不需要额外训练模型，Agent 遇到百科类问题直接查 Wikipedia，既避免了「幻觉」回答，又保持了轻量。

n8n 是一个开源的低代码工作流自动化平台，用户可以通过拖拽节点的方式把触发器（如 Webhook、定时器）、数据处理、API 调用和条件分支串联成一条自动化流程，很像可视化版的脚本语言。它的价值在于把「编排」这件事从写代码变成连线，同时仍保留在节点内嵌入自定义 JavaScript 或调用任意 HTTP 接口的能力。本文中的 n8n 工作流承担了系统总线的角色：Webhook 接收前端传来的文字，AI Agent 节点负责与 Gemini 模型交互并决定是否调用工具，MCP Client 节点则向下对接硬件。相比自己从零用 Python 写调度逻辑，n8n 让开发者把精力集中在提示词设计和工具定义上，这也是该项目能由一名学生独立完成的原因之一。

第三层：MCP 协议连接软硬件

MCP（Model Context Protocol）在这里扮演了关键角色。n8n 中的 MCP Client 节点连接到两个 MCP Server，对外暴露两个工具：

读取传感器：获取 DHT22 和超声波传感器的实时数据
控制设备：开/关指定的电器

Agent 根据用户意图自主决定是否调用工具。这种「工具调用」机制让 AI 的回答有据可依，而不是凭空猜测。

MCP工作流配置

MCP（Model Context Protocol，模型上下文协议）是由 Anthropic 在 2024 年底开源的一项标准，用于规范大语言模型与外部工具、数据源之间的通信方式。在 MCP 出现之前，每接入一个新工具往往需要为该模型定制一套接口代码，工具与模型之间是「点对点」的私有集成，复用性差。MCP 的做法是把工具提供方抽象为 MCP Server，把工具使用方抽象为 MCP Client，双方通过统一的协议描述工具的能力（名称、参数、返回格式）。这样任何兼容 MCP 的模型或 Agent 框架都能即插即用地调用同一个 Server，而无需关心底层是 HTTP、串口还是本地进程。在本项目中，传感器读取和设备控制被封装成两个工具，由独立的 MCP Server 暴露给 n8n 中的 MCP Client 节点，Agent 只需按协议声明调用即可，无需知道 ESP8266 的具体实现细节。这正是「工具调用」能够标准化、可移植的关键。

第四层：ESP8266 硬件端

硬件部分由一块 ESP8266 主导，连接了 2 个超声波传感器、1 个 DHT22 温湿度传感器和 6 颗 LED。ESP8266 通过 Wi-Fi 与 n8n 通信：每 3 秒上报一次传感器数据，每 1 秒检查一次设备状态变更。当 Agent 通过 MCP 工具修改了设备状态，ESP8266 在下一次轮询时读到指令并点亮对应的 LED。

LED设备模拟

ESP8266 是乐鑫科技推出的一款低成本 Wi-Fi 微控制器芯片，内置完整的 TCP/IP 协议栈，单芯片即可联网，常见模组（如 NodeMCU、ESP-01）售价仅十几元人民币。它通常被用作物联网设备的主控，通过 GPIO 引脚连接各类传感器和执行器，并借助 Wi-Fi 与云端或本地服务器通信。文中采用的 DHT22 是一款常用的数字温湿度传感器，测量精度约为 ±0.5°C 和 ±2% 相对湿度；超声波传感器（如 HC-SR04）则通过发射和接收声波的时间差来测算距离，常用于避障或液位检测。这类「廉价 MCU + 常用传感器」的组合是 AIoT 入门项目的标准配置，成本可控且生态成熟，这也是本方案整体造价极低的重要原因。

实际演示中的亮点

在演示环节，几个交互场景值得关注：

直接指令：「Bob，把家里所有设备都打开」——Agent 调用控制工具，6 个设备全部开启。

间接推理：「房间太冷了，把空调关掉」——Agent 理解「冷」对应的是「空调/制冷设备」，无需用户明确说出设备名称。

模糊需求：「太刺眼了，关掉一些灯」——Agent 自行判断并关闭部分灯光设备。

这几种交互展示了 LLM 在智能家居场景中的独特价值：用户不需要记住每个设备的名字，也不需要按照固定句式下指令，Agent 会结合上下文和常识去理解意图。

Agent通用问答能力

这个方案意味着什么

传统的智能家居控制依赖预设规则：如果温度高于 28°C 就开空调。这种方式僵化且需要穷举所有条件。而用 AI Agent + MCP 的方案，本质上是用语义理解替代了规则匹配。

n8n 的低代码工作流大幅降低了搭建门槛，MCP 协议则提供了标准化的工具调用接口。两者结合 ESP8266 这类廉价硬件，构成了一个成本极低但能力完整的原型。当然，目前用 LED 模拟真实电器，距离量产还有距离——接入继电器模块后即可控制真实电路。

对于想入门 AIoT 的开发者来说，这个项目的参考价值在于：它证明了「大模型 + 工具调用 + 微控制器」这条技术路径是通的，而且实现成本比想象中低得多。