大模型+智能家居：从意图理解到执行编排的落地架构

1. 为什么要在智能家居里塞进大模型

我接触智能家居这套东西有几年了，从最早的继电器模块、红外转发，到后来的网关+传感器+场景联动，一路折腾下来，最深的感受是：自动化规则越写越多，人反而越来越累。你想想，一个普通三居室，灯光、窗帘、空调、新风、地暖、热水器、扫地机、门锁、摄像头，随便一数就是十几个设备。每个设备三五个状态，组合起来几千种情况，靠"如果A且B则C"的规则去枚举，根本写不完。今天加个"阴天客厅灯自动补光"，明天又想"晚上十点后有人经过走廊只亮地脚灯"，规则表长得像天书，改一条牵动三条，维护成本高得离谱。

这就是大模型介入的切入点。大模型在智能家居里的核心价值，不是"让设备联网"，而是把人的模糊意图翻译成设备能执行的具体动作。传统方案里，你得告诉系统"客厅灯亮度调到40%、色温3500K、打开窗帘30%"，这是命令式交互；而大模型能做的是，你说"我想在客厅看会儿书，光线别太刺眼"，它去综合判断当前环境光、时段、窗帘开合、灯具能力，反推出一组参数下发。这个差别是本质性的——前者的智能在用户脑子里，后者的智能在系统里。

适合读这篇内容的人，我大致分三类：一类是家里已经有一套智能家居、被场景规则折磨过的折腾党，想看看大模型能带来什么增量；一类是做物联网/嵌入式开发，想了解大模型如何跟设备控制链路对接的工程师；还有一类是产品侧的人，想知道这套东西的能力边界在哪、哪些能落地、哪些是PPT。不管你是哪一类，我下面都会把链路拆到能动手的程度，包括意图解析、设备能力建模、执行编排、失败兜底这些关键环节，以及我自己踩过的那些坑。

先说清楚一个前提：大模型不是万能的，它在智能家居里扮演的是"决策层"，不是"执行层"。真正控制灯的开关、调节空调温度的，还是网关、单片机、继电器这些老伙计。大模型负责的是理解你要什么、决定该动哪些设备、按什么顺序动、动到什么程度。搞混了这两层，方案设计一定会跑偏——我见过有人试图让大模型直接下发MQTT报文，结果一个幻觉把空调温度设成80度，这种架构从根上就不对。

还有一个容易被忽略的点：为什么是现在。两年前做大模型控制家居，成本和延迟都不可接受，一次推理几毛钱、响应好几秒，体验还不如手动按开关。现在小参数量的模型能在本地设备上跑，量化后几百兆内存占用，推理延迟压到几百毫秒，加上流式输出和意图缓存，才勉强达到"可用"的门槛。这个背景很重要，因为它决定了方案选型——你不可能每个动作都调一次云端大模型，成本和延迟都撑不住，必须做分层设计。这也是我后面要重点讲的架构思路来源。

2. 整体架构怎么搭：分层与职责边界

2.1 三层结构：理解层、决策层、执行层

我最终跑通的架构是三层，不是两层。最早我按"大模型+设备"两层做，结果发现中间缺了一层，导致大模型的输出和设备能接受的动作之间有一道鸿沟，每次都得在代码里硬编码转换逻辑，越写越乱。后来引入中间层，把"设备能力"抽象成结构化描述，整个链路才顺起来。

理解层负责接收用户的自然语言输入，做意图识别和槽位抽取。比如"把卧室弄凉快点"，抽取出来是{意图: 调温, 位置: 卧室, 方向: 降低, 幅度: 未指定}。这一层要处理的问题包括口语化表达、指代消解（"那个灯"指的是哪个）、多意图混合（"关灯开空调"是两个动作）。

决策层是核心，负责把意图转换成具体的设备动作序列。它需要知道三件事：当前有哪些设备可用、每个设备支持什么操作、当前环境状态是什么。这三样信息喂给大模型，让它输出一个结构化的动作计划。我这里用的是受限生成，不是让它自由发挥——给模型一个动作schema，让它往里填，而不是让它写一大段自然语言再去解析。这一点极其重要，后面会详细讲。

执行层就是传统的那套东西，网关、协议适配、设备驱动。它接收决策层下发的结构化指令，转成具体协议报文发出去，同时把执行结果回传。

三层的职责边界一定要划清。理解层不做设备判断，决策层不做协议转换，执行层不做意图推理。我见过最乱的设计是让大模型既理解又决策还顺带生成控制代码，出了问题根本没法定位是哪一环的锅。分层之后，每一层都可以单独测试、单独替换，模型换了不影响执行层，设备换了也不影响理解层。

2.2 为什么用"受限生成"而不是自由文本

这是我在实际项目里改得最狠的一处。最初的设计很朴素：让大模型返回一段JSON，我解析后执行。跑起来才发现，模型的输出格式稳定性极差——有时候多一个字段，有时候把枚举值写成同义词（"开"写成"打开"、"启动"），有时候嵌套层级对不上，JSON解析失败的比率能到百分之十几。对一个控制类系统来说，这个失败率是灾难性的，因为用户说"关灯"你没关，体验直接崩。

后来改成受限生成（constrained decoding），思路是给模型一个严格的动作schema，把可选的动作类型、参数范围、枚举值都限死，模型只能在这个空间里生成。具体做法有几种，我用的是"提示词约束+schema校验+失败重试"的组合拳：

动作schema示例（简化）： { "action": "set_light" | "set_ac" | "set_curtain" | "query_status", "target": "设备ID列表", "params": {...} // 按action类型限定 }

提示词里把这个schema完整给出，并要求"只能输出符合schema的JSON，不要任何解释文字"。同时在调用侧设一个校验器，输出不合法就打回重试，最多两次，两次都失败就降级到规则匹配。实测下来，加了schema约束之后，格式合法率从八成多提到接近百分之百，剩下的极少数靠重试和降级兜住。

注意：不要把"让模型自由发挥再解析"当成默认方案。控制类场景里，输出的可解析性比输出的丰富性重要一个数量级。宁可模型笨一点、只会输出固定格式，也不要它聪明但格式乱飞。

2.3 本地模型还是云端模型：一次真实的取舍

这个选择题我纠结了很久，最后是混合方案。理由不复杂，算一笔账就清楚：

我实际的做法是：高频、固定模式的指令走本地小模型或规则引擎，低频、复杂的自然语言走云端。比如"开灯""关空调""窗帘拉到一半"这种，本地就能处理，延迟低、成本零；而"我明天早上七点要出门，帮我看看今晚空调该开多久、几点关合适"这种带推理和规划的，才走云端。这个分流的判断本身也可以用一个轻量分类器做，不需要每次都调大模型。

还有一个现实约束：家庭网络不是数据中心，断网是常态。云端方案的可用性天然受限，所以本地必须有兜底能力，至少要保证基础设备控制不受影响。这是工程上的硬要求，不是可选项。

3. 意图理解与设备能力建模：两个最容易被低估的环节

3.1 意图解析的真实难点在哪

很多人以为意图解析就是"把话分类"，实际做下来，难点集中在四个地方：

第一是歧义与指代。"把灯关了"——关哪个灯？客厅的还是全屋的？"那个"指的是哪个设备？这类问题需要结合上下文和空间信息。我的处理方式是给模型喂当前房间+最近操作的设备列表作为上下文，让它做指代消解，而不是孤立地理解一句话。

第二是隐含约束。用户说"我要睡觉了"，这句话里没有任何设备指令，但隐含了一堆动作：关主灯、开夜灯、调空调到睡眠温度、拉窗帘、锁门、关电视。这种"意图级"指令比"设备级"指令难处理得多，因为它依赖大量的家庭习惯知识。我的做法是给模型一份习惯配置文件，里面写清楚"睡觉"这个场景在你的家里对应哪些动作，模型负责把习惯和当前状态结合，生成实际动作序列，而不是每次都从零推理。

第三是多意图混合。"关灯然后把空调调到26度再拉上窗帘"，一句话三个动作，需要拆解成动作列表并确定执行顺序。这里有个坑：有些动作有依赖关系（比如先关灯再开夜灯，顺序反了会闪一下），有些可以并行。我的方案是让模型输出带depends_on字段的动作列表，执行层按依赖拓扑排序，无依赖的并行下发。

第四是模糊量词。"调凉快点""灯再亮一点""声音小一些"，这些没有具体数值。处理方式是相对量+边界约束：模型输出{action: "adjust", direction: "up/down", magnitude: "slight/medium/large"}，执行层再根据当前值和设备范围换算成具体数值，比如"稍微凉一点"对应降1-2度，"大一点"对应降3-4度，并且卡在设备的合法范围内。

3.2 设备能力建模：别让模型猜设备能干什么

这一块是很多方案失败的地方。你不能指望大模型知道你家空调支持不支持摆风、窗帘是百分比控制还是只有开合两档。设备能力必须显式建模，作为知识喂给模型。

我用的是一份结构化的设备能力描述，每个设备一条：

{ "device_id": "ac_bedroom_01", "type": "air_conditioner", "location": "bedroom", "capabilities": { "power": {"type": "enum", "values": ["on", "off"]}, "temperature": {"type": "range", "min": 16, "max": 30, "step": 1, "unit": "celsius"}, "mode": {"type": "enum", "values": ["cool", "heat", "fan", "dry", "auto"]}, "fan_speed": {"type": "enum", "values": ["low", "medium", "high", "auto"]}, "swing": {"type": "enum", "values": ["on", "off"]} }, "state": {"power": "off", "temperature": 26, "mode": "cool"} }

这份描述有两个作用：一是约束模型的输出空间，模型只能针对设备真实存在的能力下发参数，不会出现"给不支持摆风的空调设置摆风角度"这种幻觉；二是给执行层提供校验依据，下发前先校验参数是否在范围内，不合法直接拒绝并回传原因。

提示：设备能力描述建议做成配置化，而不是写死在代码里。新设备接入时只改配置，不动代码。我一开始写死在代码里，后来加一个新品牌的窗帘电机，改了三处逻辑，还引入了一个bug，血的教训。

3.3 环境状态怎么喂给模型

决策依赖状态。同样的"开空调"，夏天中午和冬天晚上，参数完全不同。所以我给模型的状态上下文包括：

• 时间与日期：时段、工作日/周末、节假日
• 环境传感：室内温湿度、光照度、有人/无人（人体传感器或毫米波雷达）
• 设备状态：所有设备的当前状态
• 近期操作：最近几分钟用户手动操作过什么（避免自动化和手动冲突）
• 家庭模式：在家/离家/睡眠/观影等全局模式

这里有个细节要提：状态上下文要精简，不能全量塞。早期我把所有设备所有字段都塞进prompt，token消耗大不说，模型还容易被无关信息干扰。后来改成只塞"相关设备"（按位置和意图筛选）+ 关键状态字段，效果好很多，成本也降下来。

4. 自动化控制的执行编排：从决策到落地

4.1 动作计划的生成与校验

决策层输出的不是单条指令，而是一个动作计划：一组动作，带顺序、依赖、条件。我用的结构大致是这样：

{ "plan_id": "p_20240115_001", "intent": "准备睡觉", "steps": [ {"step": 1, "device": "light_living_01", "action": "power", "params": {"value": "off"}, "depends_on": []}, {"step": 2, "device": "light_bedroom_02", "action": "brightness", "params": {"value": 15}, "depends_on": []}, {"step": 3, "device": "ac_bedroom_01", "action": "temperature", "params": {"value": 26}, "depends_on": []}, {"step": 4, "device": "curtain_bedroom_01", "action": "position", "params": {"value": 0}, "depends_on": []}, {"step": 5, "device": "lock_front_01", "action": "lock", "params": {}, "depends_on": []} ], "fallback": "manual_notify" }

生成之后不是直接执行，要过三道校验：

1. schema校验：结构和字段类型对不对
2. 能力校验：动作和参数在设备能力范围内吗
3. 安全校验：有没有危险操作（比如门锁在有人在家时被锁死、空调温度设成极端值、地暖在夏天被打开）

三道都过了才进执行队列。这个校验层的价值在于把模型的幻觉挡在执行之前。模型再聪明也可能抽风，校验层是最后一道闸。

4.2 执行顺序与并发控制

动作计划里有依赖关系的按拓扑排序执行，无依赖的并发下发。并发数不能太大，我设的是每批最多4个设备，因为家庭网络和网关的处理能力有限，一次下发太多容易丢包。实际测试中，8个设备同时下发，大约有5%的指令需要重发，控制在4个以内基本不失手。

还有一个容易被忽略的问题：设备响应是有延迟的。空调收到指令到真正开始工作，中间有好几秒；窗帘电机走到位可能需要十几秒。执行层不能下发完就认为成功，要做状态回读确认。我的做法是下发后轮询设备状态，超时（比如10秒）未确认就标记为"疑似失败"，进重试队列，重试两次仍失败就通知用户。

4.3 自动化与手动的冲突处理

这是实际使用中最烦人的问题。系统按规则自动开了灯，用户觉得不需要手动关了，结果两分钟后规则又把它打开，来回拉锯。我的处理原则是手动操作有更高的优先级，并且要有一个静默窗口：

• 用户手动操作某个设备后，该设备进入手动接管状态，自动化规则在这个设备上暂停生效
• 静默窗口默认30分钟，可配置
• 窗口结束后，如果环境状态发生明显变化（比如人离开房间），自动化才重新接管
• 用户显式说"恢复自动"则立即解除

这个机制听起来简单，但没有它，自动化系统用起来会非常"犟"，用户很快就烦了。我在自己家里跑了三个月，前两周几乎天天跟系统较劲，加上静默窗口后才消停。

4.4 一个完整的执行实例

拿"我要看会儿书"举例，走一遍完整链路：

1. 理解层解析：{意图: 阅读场景, 位置: 未指定→推断为客厅（当前有人房间）, 隐含需求: 光照适宜、环境安静}
2. 决策层拿上下文：当前客厅光照320lux（偏暗）、时间晚上8点、电视正在播放、窗帘半开
3. 生成计划：客厅主灯开到70%亮度、色温4000K；落地灯打开补光；电视音量降到20；窗帘保持
4. 校验：主灯支持亮度和色温，落地灯只有开关，电视音量范围0-100，全部合法
5. 执行：3个设备并发下发，2秒内完成，回读确认全部成功
6. 反馈：语音播报"已为你调好阅读光线"（简短，不啰嗦）

这个例子里，用户只说了一句话，系统动了三个设备、六个参数。这就是大模型相对传统规则的优势——规则做不到这么细的意图到动作的映射，除非你为每个场景写一堆规则，而场景是无穷的。

5. 用户交互层的设计：语音、多轮与反馈

5.1 语音交互的关键不只是识别准确率

语音是智能家居最自然的入口，但真正决定体验的不是ASR准确率，而是端到端的响应节奏。我实测过，用户说完话到设备动作，如果超过2秒，体感就明显"卡"；超过3秒，用户会怀疑没听到，重复说一遍，然后触发两次执行。

压延迟的手段有几个：

• 流式识别+流式推理：用户说话过程中就开始处理，不等说完
• 意图缓存：高频指令（开灯、关灯、调温度）走缓存直达，不调大模型
• 预热：模型常驻内存，避免每次加载
• 执行与反馈解耦：设备动作先下发，语音反馈后到，不要让用户等播报

还有一个反直觉的点：反馈要短。早期我让系统播报"好的，已为您将客厅主灯亮度调整为百分之七十，色温调整为四千开尔文"，用户直接嫌烦。后来改成"灯调好了"，满意度反而高。信息密度不是越高越好，在交互层，简洁即体验。

5.2 多轮对话与上下文管理

单轮能解决大部分指令，但有些场景必须多轮。比如：

用户：空调太冷了 系统：要调高两度吗？ 用户：嗯，再开个风扇

这里系统需要记住上一轮的"空调"指代，还要理解"嗯"是确认。多轮的关键是上下文窗口的管理：不能无限累积，也不能每轮清空。我的做法是保留最近3轮对话+当前场景状态，更早的做摘要压缩。超过窗口的老信息用一句摘要带过，避免token爆炸。

多轮里还有一个必须处理的情况：追问的收敛。系统不能无限追问，"你要调哪个房间的灯？""客厅还是卧室？""是主灯还是氛围灯？"三连问下来用户早烦了。原则是最多追问一次，第二次必须给出默认值并执行，同时告知用户可以纠正。宁可做错让用户改，也不要让用户答题。

5.3 反馈机制：让用户知道系统在干什么

自动化的黑箱感是用户不信任的根源。解决方式是适度的可视化反馈：

• 执行成功：轻量提示（语音短句/APP内一条记录），不打断
• 执行失败：明确告知哪个设备没成功、可能原因、是否需要重试
• 自动触发：说明触发原因（"检测到室内光照低于阈值，已补光"），让用户理解逻辑
• 可追溯：所有自动动作留日志，用户能查"刚才为什么开灯"

这套反馈机制我调整过好几版。最初是全静默，用户完全不知道系统在动，产生不信任；后来改成每次都播报，又太吵。最终定的是分级：常规动作静默+日志，异常动作提示，用户主动询问时详细解释。

6. 常见问题与排查实录

6.1 问题速查表

6.2 几个我踩过的坑

坑一：让模型直接生成设备指令字符串。早期图省事，让模型输出"turn_on_light_living_01"这样的字符串，结果模型经常把设备ID记错，或者编造不存在的ID。改成"模型只输出逻辑动作，设备ID由执行层按位置和类型映射"之后，这个问题彻底消失。模型不该知道设备ID这种底层细节，它只需要说"客厅主灯"，映射交给确定性代码。

坑二：忽略"无人"状态。有次出门忘了关空调，系统按定时规则一直在调温，浪费了一整天电。后来加了"全屋无人超过30分钟自动进入节能模式"，并且这个判断要多重确认（人体传感器+门锁状态+手机定位，任一显示有人就不触发），单靠一个传感器误判率太高。

坑三：语音指令和环境噪音混淆。电视里说"关灯"，系统真去关了。这个问题靠纯ASR解决不了，需要声纹/唤醒词+置信度阈值双重过滤，低于阈值的不执行，只记录。宁可漏执行，不要误执行——误执行的代价比漏执行高得多。

坑四：模型幻觉生成危险动作。测试阶段出现过模型把门锁"解锁"当成"锁定"理解的反向错误。这类问题必须在安全校验层硬拦：门锁、燃气、大功率电器这几类设备，动作必须经过白名单校验，模型输出什么都要过这道闸。安全相关的判断不要交给模型。

6.3 性能与成本的实际数据

贴一组我自己环境下的实测数据，供参考（不同硬件差异较大，仅作量级参考）：

• 本地小模型（量化后）单次意图解析：300-600毫秒
• 云端大模型复杂规划：1.5-3秒
• 设备指令下发到状态确认：1-15秒（视设备类型）
• 规则引擎处理高频指令：<50毫秒
• 分流后云端调用占比：约15%（其余本地或规则处理）
• 意图解析准确率（含指代和多意图）：约92%，剩下8%靠追问或降级

这个准确率听起来不算高，但要结合场景看——92%里绝大部分是简单指令，复杂指令的准确率大概在80%左右，所以追问和纠错机制必须有，不能指望一次就对。系统的健壮性不取决于准确率有多高，而取决于错了之后能不能优雅地兜住。

6.4 一个常被问到的边界问题

经常有人问：能不能让大模型完全接管，不要规则引擎了？我的答案是不能，至少现在不能。原因有三个：

一是确定性要求。安防、门锁、燃气这类操作，必须100%确定，模型的概率性输出不适合这个场景。这类操作永远走确定性规则，模型最多做建议不做执行。

二是成本与延迟。全走模型，每次开关灯都要推理，成本和延迟都撑不住。规则引擎处理高频简单指令，又快又稳。

三是可解释性。出了问题要能定位。规则是白盒，模型是黑盒，两者结合才能在保证灵活性的同时保留可维护性。

我的经验是：规则打底，模型增强。规则覆盖80%的确定场景，模型处理20%的模糊和复杂场景，这个配比在实际使用中比较平衡。想让模型接管一切，等它的确定性和成本都到位了再说。

7. 落地时我反复提醒自己的几件事

这套东西从想法到能用，我前后折腾了大半年，中间推翻重来过两次。回头看，有些教训值得单独拎出来说。

别追求"全自动"，先做好"半自动"。一开始我想做的是"系统什么都懂、什么都不用管"，结果处处不靠谱，用户（包括我自己）很快就失去信任。后来改成"系统做建议+一键确认"，用户点一下就好，信任度反而上来了。完全自动是终态，不是起点。

模型能力要留余量，但不能全靠模型。设备能力建模、安全校验、冲突处理、失败兜底，这些确定性逻辑必须自己写扎实。模型再强，遇到它不擅长的场景也会掉链子，底层逻辑是最后的安全网。我见过一些方案把校验层省了，指望模型自觉，这种方案上线就是事故。

把"用户纠正"当成宝贵数据。用户改了系统的动作，说明系统判断错了。这些纠正记录攒下来，是优化提示词和习惯配置的最好素材。我在系统里专门留了一个纠正日志，每周回看一次，比凭空想优化方向有效得多。

隐私和本地化不是选做题。家庭场景的语音、视频、作息数据敏感度极高，能本地处理的绝不上云。我在设计分流策略时，把"涉及摄像头和语音原始数据"的路径全部放在本地，云端只收结构化意图，不收原始数据。这是底线。

最后分享一个我自己在用的配置习惯：每个自动化规则都给它配一个"为什么"的注释，写清楚这条规则是为解决什么场景加的、什么条件下应该失效。半年后回头看，没有这条注释的规则基本都成了僵尸规则，没人知道它为什么存在、能不能删，最后整个规则系统变成一坨不敢动的历史包袱。这个习惯救过我很多次。

这套东西现在在我家里跑着，不算完美，复杂指令偶尔还是会翻车，但日常用下来已经比纯规则方案省心太多。它的价值不在于多酷炫，而在于让"说话就能控制"这件事，从演示变成了可日常使用。至于再往后怎么走，等我把能耗优化那块跑通再聊。