智能家居AI化：从规则引擎到大模型Agent编排的技术路径

1. 论坛现场的真正议题智能家居开始拼大脑了前些天去京东智享AI家发展论坛转了一圈最强烈的感受是智能家居的话题重心变了。三年前这种场合大家聊的是怎么把设备连上网怎么打通不同品牌的App展台前面摆的是网关、开关、摄像头这些硬件。今年完全不一样台上台下聊的全是大模型、Agent、本地推理、私有化部署灵机一动这次带着自家的AI智能家居方案亮相展台围了不少人问得最多的问题不是你这设备支持什么协议而是你这个系统能不能让家自己拿主意。这其实是行业的一个分水岭。智能家居喊了这么多年之前的智能大多停留在自动化层面设个场景条件满足就执行本质上是if-then的规则引擎。比如光线暗了开灯人走了关空调这些是预设好的逻辑设备本身不具备理解能力。而这一轮AI化是打算把规则引擎换成会思考的大脑——让系统听得懂人话、读得懂场景、自己编排设备动作。这个转变看起来只是技术升级实际上把产业链上下游全搅动了。具体到这次论坛的内容有几个信息值得留意。一是大模型低门槛部署工具越来越多端侧跑得动小模型云侧有大模型兜底连中小厂商也有机会做出拟人化交互。二是Matter这类跨平台标准逐步落地设备互联的最后一公里问题开始被解决设备语义的标准化让上层AI有了更好的发挥空间。三是行业对隐私优先达成了比较一致的共识本地推理不再是极客玩家的自嗨而是产品化的刚需。文章后面我不打算复述论坛议程那没意思。我更想顺着这场论坛透出的信号把智能家居AI落地时真正绕不开的几条技术路径捋一遍。这些内容有一部分来自我自己做智能家居项目的实践有一部分是跟论坛上灵机一动等几家方案商交流时聊到的技术选型思路希望能给正在评估要不要给自家产品加AI的团队一些参考。会涉及硬件选型、模型部署、Agent编排、工程测试这些具体环节偏实战不扯概念。1.1 为什么前几年的智能家居不叫智能先把这个基础问题说透。传统智能家居的交互链路是人在App里点按钮或者喊一句固定口令系统匹配预定义场景并执行。整个过程里设备是听命令的机器系统是开关集合的管理员没有任何感知和理解。哪怕加了语音助手也只是做了关键词提取和固定指令映射换个说法、换个语境就听不懂了。我见过不少用户吐槽智能音箱说打开卧室空调没问题说屋里有点闷就完全没反应。这两种表达在人的语境里是同一个意图但在传统系统里前者有对应的设备指令后者没有意图映射。要处理这种开放式的表达必须让系统具备语义理解能力也就是把自然语言转成设备可执行的意图。这正是大模型擅长的事。所以智能家居的大脑化不是厂商造概念而是用户需求倒逼出来的升级路径。另外要注意的是自动化规则本身还有另一个天然缺陷规则的组合爆炸。家里有10种设备每台设备3种状态理论上可组合的场景就有上千种。普通用户根本没有精力和耐心去配置这么多规则最后常用的还是那两三个场景。这也是为什么很多智能家居产品买回家用了一两个月就退回手动模式——自动化规则设计太反人性了。AI方案要解决的正是把配置规则的负担从用户手里接过来这件事。1.2 AI进场后智能家居的体验会发生什么变化举一个直观的例子。传统的晚安场景是这样的用户在App里配置好23点关灯、关窗帘、空调调到睡眠模式、门锁执行反锁然后一键触发或用定时触发。看起来已经挺方便但一旦出现我今天想晚点睡孩子还在客厅写作业这类例外情况规则就失灵了用户必须手动调整体验反而更繁琐。换成AI理解层之后用户只需要说一句我准备睡觉了系统会结合当前时间、各房间传感器状态有人没人、灯光亮度、温度、用户历史作息习惯自动决定哪些设备执行什么动作。如果检测到客厅还有人活动它可能不会一刀切关掉所有灯而是只关闭卧室设备客厅保持夜灯亮度。这种看情况办的能力才是消费者真正想要的智能。我拿这个案例跟好几个从业者聊过大家的一致看法是前半段的意图理解靠大模型已经不难难的是后半段的设备编排——系统怎么决定优先执行哪些动作怎么判断客厅有人如果传感器数据冲突了听谁的这已经不是模型问题而是系统架构问题。后面第四节我会单独展开讲Agent编排这里先不展开。1.3 智享AI家论坛值得留意的几个信号论坛期间我特别留意了几类角色的发言。一类是做芯片和模组的他们在主推端侧AI能力内置把NPU直接做进通信模组省掉单独的网关盒子一类是做平台软件的他们在强调设备连接之上要长出智能层不能只做控制通道还有一类是像灵机一动这样直接做用户侧方案的思路更偏向这个功能放到真实家庭里到底好不好用。这三个视角刚好对应智能家居AI化落地的三个层次硬件层解决算力在哪平台层解决数据怎么通方案层解决体验怎么做好。论坛上不少讨论其实都是在三个层次之间找接口这也说明整个行业还处在磨合期。作为开发者我的建议是别急着站队先把三层各自的技术路径摸清楚再做选型决策。2. 硬件侧的AI底座MCU与边缘算力怎么选智能家居最大的特点是设备分散、形态各异不是所有设备都有条件接一个高性能处理器。从一颗温湿度传感器到带屏的智能中控屏算力跨度极大。想把AI能力铺到每个角落必须先搞明白每个位置需要什么等级的算力。2.1 低成本终端的TinyML路线大量智能家居末端设备用的是MCU芯片比如STM32系列主频几十到几百MHz内存以KB到MB计。这类设备本身跑不了大模型但可以做TinyML——把轻量级模型塞进MCU完成关键词识别、异常声音检测、人体活动识别等简单任务。我在一个智能开关项目里做过这样的尝试用STM32F4系列采集本地麦克风数据跑一个压缩过的唤醒词识别模型实现离线语音开灯/关灯。模型参数量控制在几十KB推理一次大概几十毫秒功耗和成本都在可接受范围。关键点在于模型压缩不能只看参数总量还要看峰值内存占用和推理时延。TensorFlow Lite for Microcontrollers这类框架会帮你做算子裁剪但具体任务的数据集质量直接决定端侧效果特别是环境噪音要提前采集否则模型在实验室评分再高上门实际用起来就是另一回事。有一个容易被低估的环节是音频前端。MCU上做语音识别真正的难点往往不在模型而在回声消除、降噪、声音活动检测这些预处理。家里环境千奇百怪有电视声、有空调声、有窗外马路噪音预处理做得不好再好的唤醒模型也会频频误唤醒或漏唤醒。我在测试时专门收集了厨房、客厅、卧室三组噪音样本还模拟了人离设备三米外轻声说话厨房水龙头开着时说话这些场景才把误唤醒率压到可接受范围。2.2 边缘网关是真正的AI主战场如果只让每个设备做唤醒词识别那还算不上系统级智能。真正的系统级AI需要部署在边缘网关上由一个算力稍强的盒子统一处理全屋的传感器数据和交互请求。市面上常见的选择有两类一类是瑞芯微RK3588、晶晨A311D这类带NPU的SoCNPU算力普遍在3到6 TOPS跑一些中等规模的检测和分类模型绰绰有余另一类是英伟达Jetson系列算力更高但成本和功耗也高适合高端场景或开发调试。智能家居网关为什么要本地推理核心原因是隐私和时延。全屋的语音、图像、人体感应数据如果全部上传云端用户心理上很难接受而且一旦外网抖动家里的基础控制就会失灵。把本地网关作为第一层处理既能保证断网也能用也能大幅降低云端带宽成本。以视觉方案为例一个1080p摄像头在本地做人形检测只需把有人/没人这种结果传到云端做业务逻辑流量成本能下降两个数量级。我见过一些团队在网关选型上纠结要不要上GPU。对智能家居这个场景来说GPU并不是标配。大部分任务——人形识别、人脸判断、区域入侵检测、语音识别——都是轻量级模型NPU完全扛得住。GPU的优势在训练和复杂多模态推理但那通常是云端的工作。边缘网关如果把预算烧在GPU上导致整机成本翻倍又在中低端市场卖不动最后方案只能停在Demo阶段。这里我建议按场景划分中控屏、智能音箱这类交互密集的设备可以配高一点的算力单纯的传感器网关RK3566级别的芯片已经够用。2.3 选型时要盯着的不只是算力很多团队选型时只盯着算力TOPS值忽略了三件同样重要的事内存带宽、工具链成熟度、以及NPU上算子兼容性。同样的模型在GPU上跑得好不一定能在某款NPU上顺利跑起来。有些NPU不支持的算子就得手工改写网络结构或者拆分模型这个工作量很容易被低估。我踩过这样的坑RK3588的NPU支持主流算子但某个自定义的注意力模块需要多次rearrange操作在NPU上编译后推理速度反而不如用GPU核跑。后来把模型精简成标准的卷积全连接结构推理速度才提上来。所以建议在做硬件选型之前先把目标模型在这块芯片上的benchmark跑一遍不要只看官方给的峰值数据。论坛上和灵机一动的工程师聊到这点他们也提到在做端侧方案适配时算子兼容性排查占了整个适配周期的三分之一这个比例很能说明问题。我在下面列一个简表把几种常见网关芯片的定位整理一下方便对照以下参数为实测与厂商数据混编不同版本型号会有差异以具体规格书为准芯片平台算力类型典型算力内存支持适配任务注意点STM32F4/H7MCU无NPU纯MCU主频168-480MHz512KB-1MB唤醒词、传感器分类只能跑几十KB模型ESP32-S3向量指令轻量NPU较小8-16MB关键词识别、简单分类便宜适合量产RK35661TOPS NPU约1TOPS2-4GB语音助手、轻视觉性能够用功耗低RK35886TOPS NPU约6TOPS8-32GB多路视觉语音本地模型算子兼容要提前验证Jetson Orin NanoGPU深度学习加速器40TOPS4-8GB高端开发、复杂多模态成本高适合高端产品这张表只是一个起点真的做选型时还是要以你自己那两三个核心模型的实际推理性能为准。不然参数表格再好看换到你的网络结构上跑不动一切都白搭。3. 大模型进家云端API与本地部署的路线取舍如果说边缘网关解决的是设备怎么感知大模型解决的就是系统怎么思考。到了这一层摆在开发者面前第一个选择题是用云端大模型API还是部署本地模型或者两者混合。3.1 云端API见效快但你需要想清楚三个账单接入GPT、文心、通义这类云端大模型API是目前最快让智能家居拥有自然语言理解能力的方式。开发成本低模型聪明联网信息也丰富。但智能家居场景下有三个账单必须算清楚。第一是时延账单。一次完整的语音交互从唤醒到ASR识别再到大模型生成回复最后转TTS下达设备指令如果每步都走云端整体时延很容易超过两秒。两秒在IT系统里不算什么但在居家场景中用户说关灯等了两秒灯才灭这种体验会被反复吐槽。第二是成本账单。智能家居设备交互频率远高于普通聊天应用一屋子设备每天的走量可能上万次调用即使单价很低一个月的云端费用累积起来也相当可观。第三是隐私和稳定性账单。全屋数据和对话内容全走云端产品在用户侧会遭遇信任阻力而云服务一旦波动家里的智能就变成半瘫。把三个账单摆到台面上不是说云端方案不能用而是要有明确的哪些话让它听、哪些设备让它管的边界。比如你是做中控大屏的本身屏幕上的内容交互天然更复杂云端大模型负责百科问答菜谱推荐完全合理但如果你做的是灯具、门锁、窗帘这类强控制类设备把每次指令都绕到云端成本和体验双双失控。3.2 本地部署需要跑多大模型量化参数怎么定本地部署大模型的问题是资源受限但智能家居场景的优势在于我们不需要一个通才只需要一个懂家庭事务的专才。所以本地模型选型不必盲目追求大参数主流做法是选7B到13B的模型做量化部署把模型体积从十几GB压缩到4到6GB配合边缘网关的16GB内存勉强能跑起来。如果是专用设备还可以用3B左右的轻量模型配合云端API做兜底。量化参数的取舍有讲究。4-bit量化能显著压缩体积和显存占用但对复杂推理的质量影响明显8-bit量化体积稍大胜在输出稳定。我实际测试下来在7B量级模型上4-bit和8-bit的日常指令理解差异不大但在多轮对话和复杂意图解析时4-bit偶尔会出现理解偏差。做产品的时候不妨做成可配置默认8-bit求稳在内存紧张时再切4-bit降载。还有一点容易被忽略本地部署不只是把模型文件放进设备那么简单还有Tokenizer、推理框架、模型热切换、内存池管理等一堆工程细节。推理框架选型上llama.cpp在CPU上的优化很成熟适合没有强力GPU的边缘设备如果网关带NPU就要重点看推理框架对这块NPU的支持度。另外模型加载本身就占几个GB内存启动和热切换要做好状态管理不然一次模型更新就会把整机拖垮。3.3 混合架构是目前最务实的做法把话说到这份上结论已经比较清晰了——纯云端和纯本地都不是答案混合架构才是目前最务实的路径。我推荐的架构是本地模型承载高频、隐私敏感、实时性要求高的任务唤醒词、短指令理解、敏感设备控制云端大模型承载低频、复杂、需要外部知识的任务多轮对话、模糊意图消解、菜谱/百科查询。本地与云端的切换逻辑要做好。比如用户说关灯本地模型直接处理响应速度控制在几百毫秒用户说今晚吃什么本地模型判断超出能力边界自动带到云端处理再把结果返回。这套切换如果设计得好用户是无感知的体验上是私密指令秒回、开放问题也能答。在设计切换逻辑时我建议在本地模型里加入一个置信度路由本地模型不光输出结果还附带自己对本次判断的置信度。置信度高就本地执行置信度低就转云端。这一步听起来简单实际调参时很费工夫——阈值定高了很多本来本地能处理的指令被白白丢到云端阈值定低了本地误判率又上去了。比较稳的做法是先用几千条真实用户语料做离线评测画出一条阈值-误判率曲线再结合成本预算选一个平衡点。4. AI Agent在智能家居里的真正形态不是聊天而是编排模型选好、部署到位之后下一个问题是怎么用。很多团队把大模型接入智能家居后只是做了一个更聪明的语音助手——用户问什么它答什么答完就结束了。如果仅限于此大模型的价值只是替代了关键词匹配还没有真正提升智能家居的自主性。4.1 从单一指令响应到场景自主编排我认为智能家居里AI Agent的核心价值是从听懂指令升级为编排场景。所谓编排就是系统拿到一个模糊的用户意图后自己去规划应该调用哪些设备、按什么顺序执行、遇到冲突时怎么决策。拿前面准备睡觉的例子展开。传统系统把晚安场景固化成一条规则执行顺序和参数全是用户预先设定好的。Agent方案里系统会自己拆解这个意图背后的任务链检测卧室还有人吗没人可以关灯空调当前温度是多少需要调整到睡眠曲线门锁是解锁状态吗需要反锁窗帘如果已经拉上就不用重复动作。这些检查项可以被看作一次工具调用序列Agent负责生成这个序列并逐步执行每步执行后还会验证结果失败就重试或降级。这个能力的技术核心是把设备控制抽象成工具Tool供大模型调用。每个设备能力描述成一个函数系统通过Function Calling机制让模型生成执行计划再回到设备sdk里按计划下发指令。难点在于设备描述怎么写——描述词不够准确模型就容易生成错误调用描述词太复杂Token消耗又控制不住。我在项目中踩过不少次后来总结了一套规范每个工具描述控制在50个字以内用设备动作参数范围的结构化格式效果稳定很多。4.2 Agent与其他智能家居系统的集成路径做Agent落地时会有团队纠结要不要自己从0写一套设备接入层。我的建议是如果不是自研硬件生态优先考虑成熟的智能家居平台做集成。Home Assistant是目前生态最开放的方案支持的设备极多而且有完善的事件总线、历史数据记录和自动化引擎很适合作为Agent的设备控制底座。集成方式大致是这样系统里的Agent通过Home Assistant的WebSocket API订阅设备状态变化同时把设备控制操作封装成工具暴露给大模型调用。Agent收到用户指令后先通过LLM解析出意图再生成工具调用序列工具层在Home Assistant里执行具体控制执行结果作为上下文回填给模型做下一步判断。这套链路实测能够把理解—规划—执行串起来而且由于Home Assistant的自动化也能照常运行Agent可以无缝叠加在已有习惯之上不用推翻原来的场景设置。这里我想多说一句用好Home Assistant的设备状态回调机制比轮询设备状态高效得多。轮询方式不仅浪费资源还会让Agent拿到的状态永远是上一个采样点的状态在设备快速变化时容易误判。事件驱动的回调方式则能保证Agent拿到的都是最新状态延时低一个量级。如果你的设备云平台没有事件回调能力建议至少把轮询周期缩到1秒以内并做好时间戳比对防止旧数据覆盖新数据。4.3 一个最小可用的Agent链路搭建思路如果要在自己项目里搭一个最小可用的Agent不用太复杂核心组件就四块语音/文本入口、意图解析模块、工具调用层、设备控制层。语音入口负责把用户声音转成文字可以用现成的ASR也可以用本地小模型意图解析模块由大模型承担负责把文字解析成意图和参数工具调用层维护一份设备能力清单按模型生成的JSON指令去匹配具体工具设备控制层对接具体的SDK或平台完成最终下发并上报结果。建议第一步不要追求全场景拿两三个高频场景灯光控制、空调调节、窗帘开关跑通闭环。这期间重点打磨两件事一是意图解析的准确率尤其是带模糊约束的表达把客厅灯光调亮一点中的一点怎么量化二是执行失败的兜底策略——工具调用失败了系统怎么跟用户解释怎么改成逐项确认而不是静默失败。这两件事打磨顺了再从3个场景扩到30个场景就只是设备接入的工作量了。5. 落地时踩过的坑设备语义、时延预算与误判控制最后这部分聊点我从各种项目和论坛交流里攒下来的实在经验。每一项都踩过、修过写出来帮后来人少花点冤枉时间。5.1 设备语义标准化品牌多不是问题描述混乱才是问题做智能家居AI方案绕不开多品牌设备的语义统一。A品牌的睡眠模式和B品牌的睡眠模式实际参数可能完全不同C品牌的离家模式可能只是关灯D品牌的离家模式会连水浸报警一起布防。同一个词在不同设备里语义千差万别AI再聪明也没法拿一套标准去指挥这些各自为政的设备。解决思路是建一层语义中间层。在系统内部定义一套统一的设备能力模型比如空调_模式_睡眠门锁_状态_反锁窗帘_开合_百分比再通过驱动层把各品牌的私有指令翻译成这套模型。Agent只跟语义中间层打交道不需要理解每个品牌的私有协议。这层抽象前期要多花些时间建模但后面的扩展效率会指数级上升。和设备语义相关的还有单位换算问题。有些设备的温度参数支持0.5℃步进有些只支持1℃有些灯光色温用绝对K值有些用百分比。如果语义中间层不统一单位Agent生成的参数就会被下游设备直接拒绝或错误解释。这块我建议在中间层定义的时候就写成规范文档每接入一个品牌就对照规范做一次映射别等接入到第20个品牌时再回头补那会是一场噩梦。5.2 时延预算每个环节都要有硬指标智能家居交互的体验时延是个硬骨头。从用户开口说话到设备做出响应我给自己定的目标是本地指令控制在800毫秒以内云端兜底的指令控制在2秒以内。要守住这个预算每段链路都得有明确的时间指标唤醒词识别不超过200毫秒ASR转写控制在300毫秒意图解析和工具生成本地模型跑100到200毫秒设备下发控制在100毫秒以内。这组预算值拿出来团队里每个模块的负责人就清楚自己该优化什么了。最怕的是没有预算意识整条链路每个环节都差不多最后叠加起来就变成用户可感知的迟钝。做性能压测的时侯要注意模拟真实工况比如同时有多个设备上报状态、Wi-Fi有一定丢包这种环境下测出来的数字才是用户实际体验的依据。还有一个和时延相关的细节设备执行反馈要尽早给。即使后台还有后续动作要处理第一步的设备反馈要尽快送达用户一旦感觉到说了没反应就会立刻质疑整个系统的可靠性。所以指令链路设计上可以把设备动作触发和状态确认刷新拆开前者优先保障后者后补视觉和语音反馈都及时跟上用户感知到的响应速度会明显提升。5.3 误判比不判更伤体验做AI功能最忌讳的是误触发、误操作。自动化场景下一次意外的开窗锁门用户容忍度极低。所以宁可系统少做一些聪明的事也不要做错事。我在上下文感知的规则设计里始终遵守一个原则涉及安全和隐私类的设备操作门锁、燃气阀、摄像头必须多重条件确认绝不单凭一个传感器数据就自动执行舒适类设备操作灯光、空调、窗帘可以相对激进但也要设置快速取消机制。这个原则放到了Agent的决策规则里效果很明显。用户对灯怎么开的宽容度远高于门怎么锁把决策权重往安全方向倾斜能大幅降低口碑风险。另外推理结果一定要有可解释性系统可以记下每次自动操作的触发依据方便用户在事后查看它为什么这么做这对建立信任非常关键。关于误判我还想特别提醒一点模型不确定时的沉默往往比错误回答更让人抓狂。用户说了一个指令系统既没执行也没反馈用户会非常迷惑。所以Agent要有明确的拒识策略当意图置信度低于阈值时主动反问澄清而不是假装没听见。比如你是想把客厅灯调亮20%还是调亮到最亮这种澄清式交互比让用户重复三遍指令好用得多。5.4 真实项目里最容易被低估的测试环节把AI Agent放进家庭环境测试难度比纯软件项目高出不少。因为家庭是长尾场景的聚集地一千户家庭可能有一千种布局、一千种生活习惯。测试不能只靠工程师自己模拟要尽早做真实用户内测收集设备日志和用户反馈。我见过一个团队把内测范围控制在30户家庭做了三个月的跟踪最终跑出了二百多个场景边界问题比如窗户开着时开空调要不要拦截、儿童房有声音时客厅电视要不要降低音量、半夜起床上厕所灯光应该多亮。这些问题是设计阶段根本推不出来的只能靠真实环境里的数据来暴露。所以我的建议是AI智能家居项目从第一个可运行原型开始就要设计好日志上报和远程调试通道别等到要优化时才发现没有数据支撑。日志设计上重点记录四类内容用户原始语音/文本、系统解析出的意图和参数、Agent生成的工具调用序列、每一步的实际执行结果。这四类数据是后续做模型调优和规则修正的唯一依据。没有这套日志任何线上问题都只能靠用户口头描述去猜效率极低。另外日志上报要注意脱敏很多语音和文本内容涉及个人隐私在上报之前要做本地化处理或者授权确认别踩了数据合规的线。6. 这次论坛之外我还在想的几件事顺着前面聊的这些最后说几个我在论坛结束之后仍一直在琢磨的方向。不算总结更像给我自己的后续功课。一是把历史数据用起来做个性化学习。现在很多智能家居系统每天都是新的一天用户调过的灯光亮度、空调温度第二天又恢复默认。如果能根据用户每天的实际操作自动调整偏好参数让智能越来越贴合具体的人用户留存会有明显变化。这个方向的数据基础正是前文强调的日志体系没有日志就没有个性化。二是把多模态能力加进来。目前大多数方案还停留在语音交互但家庭场景里看到和听到能提供更丰富的信息。比如通过摄像头画面判断阳台衣服没收通过声音识别水烧开了。这些能力会把智能家居的边界从控制扩到照料但多模态数据的隐私问题会更敏感本地处理的比例也要更高这跟前面讲的混合架构正好是同一条技术主线。三是安全性这个话题论坛上聊得少但我认为最需要提前布局。当AI能控制门锁、燃气阀、窗帘、摄像头这些设备时系统的漏洞一旦被利用威胁不再只是数据泄露而是物理安全。所以Agent的工具调用必须有严格的权限边界敏感操作要二次确认云端控制指令要做完整的身份校验和审计。这些能力宁可做得慢一点也不能省。我在论坛现场跟灵机一动的工程师聊的时候他们有一个说法我很认同智能家居里的AI不是要造一个无所不能的超级助手而是要先成为一个靠谱的管家。管家不见得多话但他说灯要关了你就一定能看到灯关掉他说门锁好了你就真的可以放心睡觉。这种确定性才是智能家居产品最该追求的体验。如果你正在做类似的智能家居AI项目我给的建议还是那句话先把两三个场景做到稳定到无聊再谈扩展。AI在智能家居里的价值最终要落到让居住更省心、更安全、更舒适这十二个字上。