本地大语言模型驱动智能家居：Ollama与米家设备语义控制实践

1. 项目概述：当小米智能家居遇上本地大语言模型

最近在折腾智能家居的朋友，估计都绕不开小米这个生态。米家App里的自动化场景虽然强大，但总感觉少了点“灵魂”——那些预设的触发条件和执行动作，说到底还是我们提前编排好的剧本，设备只是按部就班地执行。有没有可能让家里的灯光、空调、音箱变得更“懂你”，能理解你随口一句“我有点热”或者“氛围搞温馨点”这样的自然指令，然后自动去执行一系列复杂的联动操作呢？

这就是idootop/mi-gpt这个项目吸引我的地方。它本质上是一个桥梁，一个将本地运行的大型语言模型（LLM）与小米/米家智能家居设备连接起来的智能中枢。简单来说，你不再需要去App里繁琐地设置“如果温度高于28度，则打开空调并调到26度”，你只需要像和朋友聊天一样，对电脑或手机说：“屋里好闷啊”，它就能理解你的意图，并自动调用相应的设备API来调节环境。

这个项目的核心价值在于“本地化”和“语义理解”。所有数据处理和“思考”过程都在你自己的设备上完成，隐私和安全更有保障；同时，借助大语言模型强大的自然语言处理能力，它能够解析你模糊的、口语化的指令，并将其转化为精确的设备控制命令。这不仅仅是简单的语音控制开关，而是向真正的“智能家居”迈出了一大步。接下来，我将详细拆解这个项目的实现思路、核心组件、搭建过程以及我踩过的那些坑，希望能给同样有兴趣打造个性化智能大脑的你，提供一份详实的参考。

2. 核心架构与方案选型解析

2.1 为什么是“本地大模型”+“米家”的组合？

在决定动手之前，我花了些时间评估市面上已有的方案。主流的智能家居语音助手，如某精灵、某同学，其云端语义理解服务固然方便，但也存在几个痛点：一是隐私顾虑，所有语音数据需上传至厂商服务器；二是响应延迟，受网络状况影响；三是最关键的——自定义能力弱，很难深度集成非生态链设备或实现高度个性化的复杂逻辑。

而纯本地的自动化方案，如使用Home Assistant配合Node-RED流程工具，虽然强大且隐私友好，但配置门槛较高，需要用户具备一定的编程和逻辑编排能力。idootop/mi-gpt选择了一条折中且更具潜力的路线：利用本地部署的大语言模型作为“大脑”，负责理解自然语言；利用成熟的小米生态接口作为“手脚”，负责执行具体操作。这个组合的优势非常明显：

1. 隐私与离线能力：所有对话和指令解析在本地完成，敏感信息不出家门。即使外网断开，基础的设备控制和场景理解依然可用。
2. 强大的意图理解：大模型能理解上下文、处理模糊指令。比如“我睡了”，它可以关联到“关闭客厅灯、打开卧室夜灯、设置空调睡眠模式”等一系列操作，这是传统规则引擎难以优雅实现的。
3. 低代码/自然语言交互：用户无需编写复杂的自动化规则，用最自然的说话方式就能创建交互逻辑，大大降低了智能家居的配置门槛。
4. 高可扩展性：理论上，只要能为设备编写控制插件，任何品牌的智能设备都可以被纳入这个体系，不局限于小米。

2.2 技术栈拆解与选型理由

项目通常依赖于几个核心模块，我的搭建也基于此：

1. 大语言模型（LLM）运行时：这是项目的“大脑”。我选择了Ollama。原因很简单，它是目前在个人电脑（尤其是带GPU的机器）上部署和运行开源大模型最方便的工具之一。它提供了简单的命令行和API，能轻松拉取、运行如Llama 3、Qwen、Gemma等主流模型，并且内存管理做得不错。

   注意：Ollama 对 Windows 的支持同样完善，但如果你用的是苹果 M 系列芯片的 Mac，它的性能优化会更好，因为能直接利用 Metal 框架进行 GPU 加速。

2. 智能家居集成框架：这是项目的“神经中枢”，负责与米家设备通信。这里我直接使用了项目本身可能依赖或推荐的Xiaomi Miot Auto集成。它是一个非常强大的开源项目，可以通过本地局域网通信协议（MIoT）或云端API控制小米/米家/米家生态链设备，避免了全部走云端的高延迟和不稳定问题。

3. 应用层与交互接口：这是项目的“五官和皮肤”。原项目可能提供了一个Web界面或API服务。为了更灵活，我选择用FastAPI快速搭建一个后端服务，用于接收用户的自然语言查询，调用本地LLM，再通过Xiaomi Miot Auto执行命令。前端则可以是一个简单的聊天界面，或者直接集成到Home Assistant的仪表盘里。

4. 提示词工程：这是让大模型“懂行”的关键。你需要精心设计一个系统提示词（System Prompt），告诉模型它的角色是一个智能家居助手，它拥有哪些设备（设备列表），每个设备能执行什么操作，以及它应该以什么样的格式（通常是JSON）来输出它的“思考”结果和执行命令。

这个技术栈的组合，平衡了能力、易用性和隐私性。Ollama让模型运行变得简单，Xiaomi Miot Auto解决了设备控制的难题，而自定义的应用层则让我们可以完全掌控交互逻辑和业务流程。

3. 环境准备与核心依赖部署

3.1 基础运行环境搭建

我的实验环境是一台搭载了 NVIDIA RTX 3060 显卡的台式机，系统是 Ubuntu 22.04 LTS。如果你使用 Windows 或 macOS，大部分步骤是类似的，只是包管理工具和个别命令有所不同。

首先，确保你的 Python 版本在 3.8 以上。我推荐使用conda或venv创建独立的虚拟环境，避免包冲突。

# 创建并激活虚拟环境 conda create -n mi-gpt python=3.10 conda activate mi-gpt

接下来，安装 Ollama。访问 Ollama 官网获取对应系统的安装包或安装脚本。对于 Linux，一条命令即可：

curl -fsSL https://ollama.com/install.sh | sh

安装完成后，启动 Ollama 服务，并拉取一个合适尺寸的模型。考虑到智能家居指令理解不需要太复杂的推理，但需要较好的中文理解能力，我选择了qwen2.5:7b这个型号，它在中文表现和资源消耗上取得了不错的平衡。

# 启动ollama服务（通常安装后已自动运行） sudo systemctl start ollama # 拉取模型 ollama pull qwen2.5:7b # 运行模型，测试是否正常 ollama run qwen2.5:7b

提示：首次运行ollama run会下载模型，需要一定时间和磁盘空间（约4-5GB）。你可以根据你的硬件选择更小的模型（如llama3.2:3b）或更大的模型（如qwen2.5:14b），但要注意显存和内存占用。

3.2 小米设备集成库安装与配置

这是连接物理世界的关键一步。我们使用Xiaomi Miot Auto的核心库miio和更高级的封装python-miio。首先安装必要的库：

pip install python-miio

配置设备连接有两种主要方式：局域网通信和云端API。强烈推荐使用局域网通信，因为它速度更快、不依赖外网、更安全。

1. 获取设备令牌（Token）：这是本地通信的密码。最方便的方法是使用安卓手机上的米家App 配合一些抓包工具（如MitmDump）来获取。也有第三方工具如Xiaomi Cloud Tokens Extractor可以通过小米账号云端获取，但涉及账号密码，需自行权衡风险。

   注意：获取Token的过程需要一些技术操作，网上有详细教程。这是整个流程中技术门槛相对较高的一步，请耐心查阅相关指南。

2. 发现设备IP：在你的路由器管理界面中，找到小米智能设备的局域网IP地址，或者使用miio提供的发现命令（需在同一局域网下）：

   python -m miio discover

   这个命令会列出网络上所有支持miio或miot协议的设备，显示其IP地址和部分信息。

3. 测试设备控制：拿到IP和Token后，就可以用命令行测试了。例如，控制一个Yeelight吸顶灯：

   # 假设IP是192.168.1.100，Token是abcdef1234567890 python -m miio --ip 192.168.1.100 --token abcdef1234567890 # 进入交互命令行后，可以尝试开关灯 > on > off > set_brightness 50

   如果这些命令能成功执行，恭喜你，最困难的部分已经过去了。

3.3 应用服务框架搭建

我们使用 FastAPI 来构建一个轻量的 Web 服务。首先安装依赖：

pip install fastapi uvicorn httpx pydantic

创建一个简单的main.py文件作为服务入口：

from fastapi import FastAPI, HTTPException from pydantic import BaseModel import httpx import json import asyncio app = FastAPI(title="Mi-GPT 智能家居助手") # 定义请求和响应的数据模型 class UserQuery(BaseModel): query: str # 用户的自然语言指令 class DeviceCommand(BaseModel): device_id: str action: str params: dict # 这里模拟一个设备列表，实际应从数据库或配置文件中加载 DEVICES = { "living_room_light": { "name": "客厅主灯", "type": "light", "ip": "192.168.1.100", "token": "abcdef1234567890", "actions": ["on", "off", "set_brightness", "set_color_temp"] }, "bedroom_ac": { "name": "卧室空调", "type": "air_conditioner", "ip": "192.168.1.101", "token": "token_for_ac", "actions": ["on", "off", "set_temperature", "set_mode"] } } @app.post("/ask") async def handle_query(user_query: UserQuery): """ 处理用户自然语言查询的核心端点。 1. 将查询发送给本地LLM（Ollama）进行意图解析。 2. LLM返回结构化的设备控制命令。 3. 执行命令并返回结果。 """ # 步骤1: 构造发送给LLM的提示词 system_prompt = f""" 你是一个智能家居控制助手。你可以控制以下设备： {json.dumps(DEVICES, indent=2, ensure_ascii=False)} 用户会用自然语言向你发出指令。你需要理解用户的意图，并决定需要操作哪个设备、执行什么动作、以及参数是什么。 请严格按照以下JSON格式回复，且只回复这个JSON对象，不要有任何其他解释： {{ "reasoning": "你的思考过程，简要说明为什么这样理解用户指令", "commands": [ {{ "device_id": "设备ID，如 living_room_light", "action": "动作名称，如 on", "params": {{}} // 动作参数，如 {{"brightness": 50}} }} ] }} 用户指令：{user_query.query} """ # 步骤2: 调用Ollama API ollama_url = "http://localhost:11434/api/generate" payload = { "model": "qwen2.5:7b", "prompt": system_prompt, "stream": False, "options": { "temperature": 0.1, # 低温度值使输出更确定，减少随机性 "num_predict": 500 } } try: async with httpx.AsyncClient() as client: response = await client.post(ollama_url, json=payload, timeout=30.0) response.raise_for_status() llm_output = response.json() # 提取模型回复的文本内容 response_text = llm_output.get("response", "").strip() except Exception as e: raise HTTPException(status_code=500, detail=f"调用语言模型失败: {str(e)}") # 步骤3: 解析LLM返回的JSON try: # 这里需要处理模型可能返回的非纯JSON内容（比如前面有思考过程） # 一个简单的办法是查找第一个'{'和最后一个'}' start = response_text.find('{') end = response_text.rfind('}') + 1 if start == -1 or end == 0: raise ValueError("未找到有效的JSON响应") json_str = response_text[start:end] parsed_response = json.loads(json_str) except json.JSONDecodeError as e: raise HTTPException(status_code=500, detail=f"解析模型响应失败，原始响应：{response_text[:200]}...") # 步骤4: 执行解析出的命令 results = [] for cmd in parsed_response.get("commands", []): device_id = cmd.get("device_id") action = cmd.get("action") params = cmd.get("params", {}) if device_id not in DEVICES: results.append(f"错误：未知设备 {device_id}") continue device_info = DEVICES[device_id] # 这里应调用具体的设备控制函数 # 例如：control_light(device_info['ip'], device_info['token'], action, params) result = await execute_device_command(device_info, action, params) results.append(result) return { "user_query": user_query.query, "llm_reasoning": parsed_response.get("reasoning"), "execution_results": results } async def execute_device_command(device_info: dict, action: str, params: dict): """执行具体的设备控制命令（此处为示例，需根据设备类型实现）""" # 实际实现需要调用 python-miio 或对应设备的SDK # 这里仅模拟 await asyncio.sleep(0.5) # 模拟网络延迟 return f"已向设备【{device_info['name']}】发送指令：{action}，参数：{params}" if __name__ == "__main__": import uvicorn uvicorn.run(app, host="0.0.0.0", port=8000)

这个框架搭建起来后，一个最基础的智能家居语义控制后端就成型了。你可以通过向http://localhost:8000/ask发送一个 POST 请求（Body 为{"query": "把客厅灯调暗一点"}）来测试它。

4. 核心功能实现与提示词工程

4.1 设计高效的系统提示词

大模型本身并不知道如何控制你的智能家居。系统提示词（System Prompt）就是它的“岗位说明书”和“操作手册”。一个设计良好的提示词，能极大提升模型的准确率和可靠性。我的提示词经历了多次迭代，核心要点如下：

1. 明确角色与能力：开宗明义，告诉模型“你是一个智能家居助手，可以控制以下设备”。这能将它从通用聊天模式切换到任务执行模式。
2. 提供结构化设备信息：将设备列表以清晰的JSON格式提供，包含设备ID、名称、类型、支持的操作。模型需要这些信息来做出决策。

   { “living_room_light”: { “name”: “客厅主灯”， “type”: “light”， “actions”: [“on”, “off”, “set_brightness”, “set_color_temp”], “params_hint”: {“set_brightness”: {“brightness”: “1-100”}, “set_color_temp”: {“kelvin”: “2700-6500”}} } }

3. 定义严格的输出格式：这是最关键的一步。你必须强制模型以指定的JSON格式回复。格式越严格、越简单，模型出错的概率就越低。我要求它只输出一个包含reasoning（思考过程）和commands（命令列表）的JSON对象。
4. 包含示例：在提示词中给出一两个例子非常有效。例如：“用户说‘我有点热’，你应该理解为需要打开空调或降低温度。”这能帮助模型更好地理解任务。
5. 限制与边界：明确告诉模型，如果指令不明确、无法执行或涉及不存在的设备，应该返回空命令列表或在思考过程中说明原因，而不是随意猜测。

我的最终版提示词模板大致如下：

你是一个专业的智能家居控制助手。你的唯一任务是根据用户的自然语言指令，操作家中的智能设备。 # 设备能力清单 以下是你可以控制的设备及其能力： {设备列表JSON} # 输出格式 你必须且只能输出一个JSON对象，格式如下： { "reasoning": "简要说明你是如何理解用户指令的，以及为什么选择这些操作。", "commands": [ { "device_id": "设备ID，必须来自上面的清单", "action": "动作名称，必须是该设备支持的动作", "params": {} // 动作参数对象，如无参数则为空对象 } ] } # 重要规则 1. 只输出上述JSON，不要有任何其他文字、标记或解释。 2. 如果用户指令不明确、无法执行或与设备无关，`commands` 列表应为空。 3. 优先选择最直接、最符合用户意图的操作。 # 示例 用户: “天黑了，开灯吧。” 输出: {"reasoning": “用户表示天黑了需要照明，客厅主灯是主要照明设备。”， “commands”: [{“device_id”: “living_room_light”， “action”: “on”， “params”: {}}]} 用户: “把卧室弄凉快点。” 输出: {"reasoning": “用户希望降低卧室温度，应打开卧室空调并设置较低温度。”， “commands”: [{“device_id”: “bedroom_ac”， “action”: “on”， “params”: {}}， {“device_id”: “bedroom_ac”， “action”: “set_temperature”， “params”: {“temperature”: 24}}]} 现在，请处理以下用户指令： 用户: {用户输入}

4.2 实现设备控制执行器

提示词让模型“想明白”了要做什么，接下来就需要代码去“执行”。我们需要为每种设备类型编写一个执行器函数。以米家台灯为例，使用python-miio：

from miio import ChuangmiPlug, Yeelight class DeviceExecutor: def __init__(self, device_info): self.device_info = device_info self.device = None async def connect(self): """根据设备类型初始化连接""" device_type = self.device_info.get("type") ip = self.device_info["ip"] token = self.device_info["token"] if device_type == "plug": self.device = ChuangmiPlug(ip, token) elif device_type == "yeelight": self.device = Yeelight(ip, token) # ... 其他设备类型 else: raise ValueError(f"不支持的设备类型: {device_type}") # 测试连接 try: _ = self.device.info() except Exception as e: print(f"连接设备 {self.device_info['name']} 失败: {e}") self.device = None async def execute(self, action: str, params: dict): """执行具体动作""" if not self.device: await self.connect() if not self.device: return f"错误：设备连接失败" try: if action == "on": self.device.on() return "成功：设备已开启" elif action == "off": self.device.off() return "成功：设备已关闭" elif action == "set_brightness" and hasattr(self.device, 'set_brightness'): brightness = params.get("brightness", 50) self.device.set_brightness(brightness) return f"成功：亮度已设置为{brightness}" elif action == "set_color_temp" and hasattr(self.device, 'set_color_temp'): kelvin = params.get("kelvin", 4000) self.device.set_color_temp(kelvin) return f"成功：色温已设置为{kelvin}K" else: return f"错误：设备不支持动作 '{action}' 或参数不正确" except Exception as e: return f"错误：执行动作 '{action}' 时发生异常 - {str(e)}"

在主服务中，维护一个设备执行器的字典，当收到LLM解析出的命令后，找到对应的执行器并调用其execute方法。

4.3 上下文记忆与多轮对话

一个真正智能的助手应该能记住对话的上下文。比如用户先说“打开客厅灯”，然后说“调暗一点”，助手应该知道“调暗一点”指的是刚才打开的客厅灯。

实现这一点，我们需要在服务端维护一个简单的会话上下文。可以为每个用户会话（或每个家庭）分配一个ID，并在内存或数据库中存储最近几次的交互历史。当新的查询到来时，不仅发送当前指令，还将历史对话（或至少上一次LLM的“思考”和“执行结果”）作为上下文一并发送给模型。

# 简化的上下文管理 from collections import deque class ConversationContext: def __init__(self, max_length=5): self.history = deque(maxlen=max_length) # 保存最近的对话轮次 def add_interaction(self, user_query, llm_response, execution_result): self.history.append({ "user": user_query, "assistant_reasoning": llm_response.get("reasoning"), "executed_commands": llm_response.get("commands", []) }) def get_context_prompt(self): """将历史记录格式化为给LLM的上下文提示""" if not self.history: return "" context_lines = ["之前的对话历史："] for i, entry in enumerate(self.history): context_lines.append(f"{i+1}. 用户: {entry['user']}") context_lines.append(f" 助理: {entry['assistant_reasoning']} (执行了{len(entry['executed_commands'])}个命令)") return "\n".join(context_lines) + "\n\n当前指令："

然后在构造给LLM的提示词时，将get_context_prompt()的结果拼接到用户当前指令之前。这样，模型就能基于历史来理解指代性的指令了。

5. 安全加固、优化与扩展思考

5.1 权限控制与安全边界

让一个AI模型控制你家的物理设备，安全是重中之重。以下几个措施必不可少：

1. 指令白名单/黑名单：在模型输出和执行之间，加入一个校验层。即使模型解析出了命令，也要检查该设备是否允许执行此动作。例如，你可以禁止通过语音直接开关智能门锁。
2. 关键操作二次确认：对于风险较高的操作（如“关闭所有电器”），可以在执行前通过前端界面进行二次确认，或者要求提供简单的语音确认码。
3. API访问鉴权：你的FastAPI服务不应该对公网开放。如果确实需要远程访问，必须设置强密码、API Token或OAuth2.0等鉴权方式。可以使用FastAPI的依赖注入系统轻松实现。
4. 网络隔离：将运行此服务的设备放在家庭网络的独立VLAN中，只允许它与智能设备进行必要的通信，限制其访问互联网或其他敏感内网资源。

5.2 性能优化实践

本地运行7B参数的大模型，对硬件有一定要求。以下优化措施能提升体验：

1. 模型量化：使用Ollama，你可以直接拉取量化版本的模型，如qwen2.5:7b-instruct-q4_K_M。量化能在几乎不损失精度的情况下，显著降低模型对显存和内存的占用，提升推理速度。
2. 缓存常用意图：很多家居指令是重复的（如“开灯”、“关灯”）。可以设计一个简单的缓存机制，将常见指令及其对应的结构化命令缓存起来，下次遇到相同或相似指令时直接返回，绕过LLM推理，极大降低延迟。
3. 异步处理：设备控制（尤其是通过云端API）可能有网络延迟。确保你的execute_device_command函数是异步的，并使用asyncio.gather来并发执行多个不依赖的命令，缩短整体响应时间。
4. 精简提示词：在保证效果的前提下，不断尝试压缩系统提示词的长度。更短的提示词意味着更少的Token消耗，推理速度更快，成本更低。

5.3 从“控制”到“自动化”与“预测”

目前的实现主要是一个“命令响应式”助手。你可以进一步扩展它，使其变得更智能：

1. 与自动化平台集成：将本服务作为Home Assistant的一个“虚拟助手”集成进去。这样，你既可以利用HA强大的设备集成和自动化引擎，又可以享受自然语言交互的便利。可以通过HA的RESTful API或开发自定义组件来实现。
2. 接入传感器数据：让模型不仅能“听”，还能“看”和“感知”。将温度传感器、人体传感器、时间等信息作为上下文提供给模型。例如，当模型知道现在是晚上11点，且卧室有人移动时，对于“开灯”的指令，它可能会选择打开夜灯而非主灯。
3. 实现简单预测：通过记录用户的历史指令和时间，可以训练一个简单的习惯模型，或者让大模型学习你的模式。例如，在工作日早上8点，自动播报天气并询问是否启动“上班模式”（关闭相关电器，打开空气净化器等）。

5.4 我踩过的坑与避坑指南

1. Token获取难题：这是第一个拦路虎。部分新款小米设备采用了更安全的通信方式，旧版抓包方法可能失效。多关注Xiaomi Miot Auto项目的官方文档和社区讨论，那里有最新的获取方法。对于实在无法获取本地Token的设备，可以暂时使用云端模式，但要注意速率限制和隐私问题。
2. 模型“胡说八道”：有时模型会忽略你的输出格式要求，或者生成不存在的设备ID。提高提示词中格式要求的权重（用加粗、重复强调），并在代码中做好异常处理和兜底逻辑。例如，当解析出的device_id不在清单中时，直接返回错误，而不是尝试调用。
3. 网络与延迟：家庭Wi-Fi网络不稳定会导致设备控制失败。在执行命令时，加入重试机制和超时设置。对于关键状态（如开关），在执行命令后，可以再调用一次查询状态的方法进行确认。
4. 中文指令理解偏差：某些开源大模型对中文口语的指令理解可能不如英文。尝试在提示词中加入更多中文示例，或者考虑使用在中文语料上微调过的模型，如Qwen系列或ChatGLM。
5. Ollama服务中断：如果发现突然无法调用模型，检查Ollama服务是否还在运行。可以写一个简单的守护脚本，或者使用systemd确保服务在异常退出后能自动重启。

搭建idootop/mi-gpt这样的项目，更像是在拼接一个属于你自己的智能家居大脑。它没有现成的完美产品，需要你不断地调试提示词、完善设备驱动、优化交互逻辑。但当你能用一句话就让整个房间的灯光、音乐、温度都配合你的心情时，那种成就感和便捷性，是任何预设自动化都无法比拟的。这个过程本身，就是智能家居玩法的精髓所在。