智能家居这个词这几年被说得有点烂了。打开任何一个电商平台搜智能家居跳出来的全是一句话开灯手机远程控制空调这类功能。说实话这些东西用起来并不智能——你还是得开口、得掏手机、得主动操作。真正的智能应该是你还没意识到自己需要什么环境已经替你调好了。这就是主动式智能家居和被动式智能家居的根本区别。我接触智能家居系统前后有六七年时间从最早的继电器模块加红外传感器到后来的Home Assistant自动化再到最近一年多在折腾生成式AI与家居系统的结合踩过的坑比走过的路还多。这篇文章想聊的就是怎么把LLM、RAG这些生成式AI技术真正落到智能家居场景里让系统从你命令它执行变成它判断你需要什么并主动执行。涉及的核心技术点包括主动式自动化的判定逻辑、LLM在意图理解中的角色、RAG如何解决家庭场景的个性化知识检索、以及整套系统的工程落地细节。不管你是刚入门想了解智能家居控制系统的设计思路还是已经在做LLM应用想找一个垂直场景落地这篇内容应该都能给你一些可以直接抄作业的东西。1. 为什么传统智能家居根本主动不起来1.1 规则引擎的天花板在哪里绝大多数人做智能家居自动化的方式是在Home Assistant、米家或者Apple Home里配一条条规则如果人体传感器检测到有人 且 时间在18:00-23:00之间 且 光照低于50lux则打开客厅灯。这种基于触发条件-动作Trigger-Condition-Action的规则引擎本质上是一个巨大的if-else树。问题在于真实生活不是if-else能覆盖的。我举几个我自己遇到过的场景夏天晚上我在客厅看电影人体传感器每隔几分钟就检测到无人因为我坐着不动灯自动关了。我不得不加一个媒体播放器正在播放时不关灯的条件但有时候我只是开着电视听个响人已经去厨房了灯又该关。家里来客人坐在沙发上聊天传感器检测到有人但光照充足灯不亮。但客人可能觉得暗想开灯又不好意思说。冬天早上闹钟响了我起床去洗漱。按照规则卫生间灯应该亮。但有时候我只是起来上个厕所就回去睡了灯亮了反而刺眼。这些场景的共同点是规则无法穷举条件之间存在冲突而且人的意图是动态变化的。你每加一条规则系统的复杂度就上升一个量级最终维护成本高到你想全部删掉。1.2 主动的本质是预测而非响应我后来想明白一件事主动式自动化的核心不是更快地响应而是提前预测。响应是被动的——事件发生了我处理。预测是主动的——我判断事件即将发生或需求即将出现提前处理。预测需要什么需要理解上下文。同样是人体传感器检测到有人在不同的时间、不同的历史行为模式、不同的环境参数下含义完全不同。传统规则引擎只能看到有人这个布尔值看不到背后的语义。这就是生成式AI切入的地方。LLM擅长什么擅长理解自然语言的上下文、做模糊推理、处理非结构化信息。RAG擅长什么擅长从大量个性化数据中检索出与当前情境最相关的信息。这两者结合起来就能让智能家居系统具备理解情境并预测需求的能力。1.3 从自动化到智能体的思维转变我现在的做法是把整个家居系统看作一个多智能体Multi-Agent系统。每个房间、每个设备组、甚至每个家庭成员都可以抽象成一个Agent。Agent之间通过消息传递协作由一个中央协调Agent基于LLM来做全局决策。这个思路的转变很关键以前我是写规则让设备执行现在我是定义Agent的能力边界和协作协议让它们自己协商出最优解。LLM在这里扮演的是协调者和翻译官的角色——把模糊的人类意图翻译成具体的设备指令把多个Agent的状态汇总成全局情境判断。2. 生成式AI在智能家居里的三个真实落点2.1 意图理解从开灯到我觉得有点暗传统语音助手最让人抓狂的地方是你必须说它认识的那几个词。开灯可以把灯打开可能也行我觉得有点暗它就懵了。因为传统NLU自然语言理解是基于意图分类和槽位填充的训练数据里没有我觉得有点暗对应开灯的样本它就识别不了。LLM天然解决了这个问题。你不需要训练数据只需要在System Prompt里告诉它用户表达暗看不清光线不好等含义时意图是调整照明。LLM就能理解各种变体。我实测下来用GPT-4级别的模型做意图理解准确率比传统NLU方案高出至少30个百分点尤其是在处理口语化、省略、指代等复杂表达时。但这里有个工程上的坑LLM的响应延迟。你不可能让用户说完我觉得有点暗之后等3秒钟灯才亮。我的做法是双通道本地跑一个轻量级的意图分类模型比如微调过的BERT或蒸馏后的小模型做快速响应同时把请求发给LLM做深度理解。如果本地模型置信度高直接执行置信度低等LLM的结果。这样既保证了响应速度又保证了复杂场景下的理解准确率。2.2 情境推理让系统知道现在是什么情况意图理解解决的是用户说了什么情境推理解决的是现在发生了什么。这两个是互补的。情境推理需要融合多源数据传感器数据温度、湿度、光照、人体存在、设备状态灯、空调、窗帘的开闭状态、时间信息几点、星期几、是否节假日、历史行为过去这个时间点用户通常在做什么、外部信息天气、空气质量。传统做法是给这些数据设阈值超过阈值就触发。但阈值是死的情境是活的。比如温度28度这个数据在夏天开空调的情况下是正常的在冬天没开暖气的情况下就是异常的。LLM可以结合上下文做推理当前是12月室内温度28度但暖气设定是22度且窗户传感器显示窗户开着——用户可能在通风不需要干预。我现在的系统里情境推理模块每5分钟跑一次把当前所有传感器的状态汇总成一个自然语言描述发给LLM做判断。LLM返回一个情境标签比如用户在客厅看电影用户准备出门用户已经入睡后续的自动化决策都基于这个标签来做。2.3 主动建议在用户开口之前就行动这是生成式AI在智能家居里最有价值但也最难做好的部分。主动建议意味着系统要判断用户接下来可能需要什么并提前执行或询问。我举一个我实际跑通的例子系统检测到以下信号——1工作日早上7:002卧室人体传感器检测到用户已起床3卫生间人体传感器在2分钟内被触发4天气预报显示今天下雨气温比昨天低5度5用户日历显示今天9:00有会议。LLM综合这些信息后判断用户正在洗漱准备出门上班今天天气不好需要带伞而且有会议不能迟到。于是系统执行卫生间灯调到暖光模式避免刚起床刺眼客厅窗帘打开30%让用户知道天亮了但不用全开玄关灯提前亮起同时在音箱里播报今天有雨气温12度比昨天低5度建议穿外套带伞。您9点有会议现在7:15建议7:40前出门。这个场景里没有任何一条规则是如果A则B能覆盖的。它是多个信号的综合推理结果而且每个信号单独看都不足以触发行动。3. RAG在家庭场景里的独特价值3.1 为什么家庭场景需要RAG而不是纯LLM你可能会问LLM不是已经能理解情境了吗为什么还需要RAG原因很简单LLM不知道你家的具体情况。它不知道你家客厅有几盏灯、分别是什么型号、你老婆对色温的偏好是暖光还是冷光、你儿子每天晚上几点必须上床睡觉、你家猫的活动规律是什么。这些信息是高度个性化的不可能通过预训练获得。RAG检索增强生成的作用就是在LLM做推理之前先从你的家庭知识库里检索出相关的个性化信息作为上下文一起发给LLM。这样LLM的推理就是基于你家的真实情况而不是泛泛的通用知识。3.2 家庭知识库该放什么、怎么组织我家的知识库目前包含以下几类数据我用一个表格来说明数据类型具体内容更新频率检索方式设备档案设备型号、位置、能力、通信协议设备增减时更新结构化查询成员偏好各家庭成员的照明/温度/音乐偏好手动维护行为学习向量检索行为模式历史传感器数据、设备操作记录实时写入时序向量混合场景规则用户定义的硬性规则如孩子房间22:00后必须关灯手动维护关键词向量外部信息天气、日历、交通定时同步API调用这里的关键设计决策是不是所有数据都适合向量化。设备档案这种结构化数据用传统数据库查询更快更准。行为模式这种时序数据需要结合时间窗口做检索。只有成员偏好和场景规则这种半结构化、语义丰富的数据才适合用向量检索。我用的技术栈是PostgreSQL pgvector。选它的理由很实际我本来就用PostgreSQL存设备状态和历史数据加一个pgvector扩展就能同时做结构化查询和向量检索不需要额外维护一个向量数据库。对于家庭场景这种数据量不大我家大概几万条记录的情况pgvector的性能完全够用。3.3 检索策略什么时候查、查什么、怎么用RAG在智能家居里的检索策略和通用问答场景不太一样。通用问答是用户提问→检索→生成回答家居场景是情境触发→检索相关个性化信息→辅助LLM推理→生成设备指令。我的实现是这样的# 情境触发时的RAG检索流程简化版 async def retrieve_context(situation_embedding, current_time, room): # 1. 检索与当前情境最相关的成员偏好 preferences await vector_search( tablemember_preferences, query_vectorsituation_embedding, filter{room: room}, top_k3 ) # 2. 检索当前时间窗口内的行为模式 behavior_patterns await time_series_search( tablebehavior_logs, time_range(current_time - timedelta(hours2), current_time), roomroom ) # 3. 检索硬性规则必须遵守的 hard_rules await keyword_search( tablescene_rules, keywords[room, 必须, 禁止], limit5 ) # 4. 组装成LLM可理解的上下文 context format_context(preferences, behavior_patterns, hard_rules) return context这里有个经验硬性规则必须用关键词检索而不是向量检索。因为硬性规则是必须遵守的不能因为语义相似度不够就漏掉。比如孩子房间22:00后必须关灯这条规则如果用户说把孩子的灯调暗一点向量检索可能匹配不到这条规则但关键词检索能匹配到孩子和灯。4. 搭建主动式智能家居系统的完整工程路径4.1 技术选型为什么我最终选了这套组合我试过不少方案最终稳定下来的技术栈是这样的消息层MQTT设备通信 Redis Streams内部事件总线数据层PostgreSQL pgvector结构化向量 InfluxDB时序数据AI层FastAPI LangChain LangGraphAgent编排 本地部署的7B模型快速意图分类 云端API复杂推理自动化层Home Assistant设备控制 自研的Agent协调服务选LangGraph而不是简单的LangChain Chain是因为主动式场景需要有状态的循环推理。比如系统判断用户可能想看电影需要先查一下当前灯光状态再决定要不要调暗调暗之后还要确认用户是否满意通过后续行为判断。这种多步骤、有状态、可能循环的推理流程用LangGraph的图结构来表达最自然。4.2 从传感器数据到主动决策的完整链路我把整条链路拆成五个阶段每个阶段都有明确的输入输出阶段一数据采集与清洗。传感器数据通过MQTT上报经过一个清洗层过滤掉抖动和异常值。比如人体传感器在2秒内连续上报有人无人有人这显然是抖动清洗层会合并成一次有人事件。阶段二情境构建。每5分钟或关键事件触发时把当前所有传感器状态、设备状态、时间信息汇总成一个结构化的情境描述。这个描述是自然语言的方便LLM理解。阶段三RAG检索。用情境描述的embedding去检索相关的成员偏好、行为模式、硬性规则。阶段四LLM推理。把情境描述RAG检索结果系统Prompt一起发给LLM让LLM输出一个决策。决策格式是结构化的JSON包含是否执行动作、执行什么动作、执行参数、置信度、是否需要询问用户。阶段五执行与反馈。根据LLM的决策执行设备控制同时记录执行结果和用户反馈用户是否手动覆盖了系统的决策用于后续优化。4.3 让LLM稳定输出JSON的实战技巧这是我在整个项目里踩坑最多的地方。LLM返回的JSON不稳定有时候多一个逗号有时候少一个引号有时候干脆返回一段自然语言解释而不是JSON。我试过以下几种方案方案一Prompt Engineering。在System Prompt里反复强调只返回JSON不要任何其他文字并给出严格的JSON Schema。效果一般大概80%的情况下能返回正确格式。方案二JSON Mode。OpenAI的API支持response_format{type: json_object}强制模型返回合法JSON。效果好很多但模型仍然可能返回不符合你Schema的JSON比如字段名拼错、类型不对。方案三Function Calling。把决策定义为一个Function让LLM通过Function Calling来输出。这是目前最稳定的方案我实测下来格式正确率接近100%。缺点是灵活性稍差复杂的嵌套决策需要定义多个Function。方案四输出后修复。不管用哪种方案我都会在代码里加一层JSON修复逻辑。用Python的json.loads尝试解析失败则用正则提取JSON部分再失败则调用一个轻量级模型做格式修复。这个兜底逻辑救了我无数次。import json import re def parse_llm_decision(raw_output: str) - dict: 解析LLM输出的决策JSON带多级兜底 # 第一级直接解析 try: return json.loads(raw_output) except json.JSONDecodeError: pass # 第二级提取JSON块 json_match re.search(r\{.*\}, raw_output, re.DOTALL) if json_match: try: return json.loads(json_match.group()) except json.JSONDecodeError: pass # 第三级修复常见问题后重试 cleaned raw_output.strip() cleaned re.sub(r,\s*}, }, cleaned) # 去掉尾逗号 cleaned re.sub(r,\s*], ], cleaned) cleaned cleaned.replace(, ) # 单引号转双引号 try: return json.loads(cleaned) except json.JSONDecodeError: pass # 第四级返回安全默认值 return {action: none, reason: parse_failed, confidence: 0.0}提示第四级兜底非常重要。当所有解析都失败时系统必须有一个安全的默认行为——什么都不做而不是执行一个可能错误的指令。在智能家居场景里错误执行比如半夜把灯全打开比不执行糟糕得多。5. 那些只有真正跑起来才会遇到的问题5.1 延迟用户等不了3秒钟这是主动式智能家居最大的工程挑战。用户说了一句话期望在500毫秒内得到响应。但LLM的推理时间通常在1-3秒如果加上RAG检索可能到5秒。我的解决方案是分级响应Level 0100ms本地规则引擎处理明确的、高频的指令。比如开灯这种直接走本地NLU规则不经过LLM。Level 1500ms本地小模型处理意图明确的指令。比如我觉得有点暗本地微调过的模型能识别为调亮灯光。Level 21-3sLLM处理复杂情境推理。比如我要看电影需要综合判断灯光、窗帘、音响、空调的状态。Level 3后台异步主动建议和长期学习。不要求实时响应可以在后台慢慢跑。关键设计是Level 2和Level 3的决策结果会缓存起来。如果同样的情境再次出现直接走缓存响应时间降到毫秒级。缓存的有效期根据情境的稳定性来定比如工作日早上7点这个情境的缓存可以管24小时有人移动这个情境的缓存只能管30秒。5.2 误报系统太主动反而烦人我刚开始跑主动建议的时候系统特别积极。我走到客厅它问我要不要开灯我坐下它问我要不要开电视我去厨房它问我要不要开抽油烟机。一天下来问了我几十次我烦得直接把主动建议关了。后来我总结了几条原则原则一主动执行被动询问。对于低风险、高确定性的动作比如开灯、调温度直接执行不要问。对于高风险、低确定性的动作比如锁门、关燃气先询问再执行。原则二设置静默期。同一个主动建议如果用户连续拒绝两次接下来24小时内不再提。如果用户接受了可以适当增加频率。原则三置信度阈值动态调整。刚开始跑的时候置信度阈值设高一点比如0.85只在高置信度时才主动。随着系统学习用户行为逐步降低阈值增加主动性。原则四给用户一个闭嘴按钮。我在每个房间都放了一个物理按钮按一下就是接下来1小时不要主动建议。有时候用户就是想要安静不想被系统打扰。5.3 隐私数据放本地还是放云端这是每个做智能家居AI的人都会纠结的问题。传感器数据、行为记录、语音指令这些数据如果全部上传云端隐私风险很大。但如果全部本地处理算力又不够。我的方案是分层处理敏感数据本地处理语音唤醒、语音转文字、人体存在检测这些全部在本地完成。我用的是一个本地部署的Whisper模型做语音转文字识别结果只保留文本原始音频立即删除。脱敏数据上传云端需要LLM做复杂推理时只上传脱敏后的情境描述比如客厅有人光照低时间晚上8点不上传原始传感器数据和个人身份信息。个性化数据本地存储成员偏好、行为模式这些数据存在本地PostgreSQL里RAG检索也在本地完成。只有检索结果已经脱敏的上下文才会和情境描述一起发给LLM。这样做的代价是本地需要一台性能还行的服务器。我用的是一个Intel NUC16GB内存跑一个7B的量化模型做本地意图分类同时跑PostgreSQL和Home Assistant负载大概在60%左右完全够用。5.4 模型更新LLM升级后行为变了怎么办这个问题很隐蔽但很致命。你花了一个月调好的Prompt和决策逻辑某天LLM提供商升级了模型版本行为突然变了。原来能正确输出的JSON现在格式不对了原来能理解的指令现在理解错了。我的应对策略是策略一锁定模型版本。如果用的是云端API尽量选择有版本号的模型比如gpt-4-0613而不是gpt-4避免自动升级到最新版。策略二建立回归测试集。我收集了200个典型情境期望决策的测试用例每次模型更新或Prompt修改后跑一遍回归测试确保核心场景的行为不变。策略三A/B测试。新模型先跑影子模式Shadow Mode也就是新模型和旧模型同时推理但只有旧模型的决策被执行。对比两者的决策差异确认新模型没有退化后再切换。6. 从单点智能到全屋智能体的演进路线6.1 第一阶段单房间的主动照明如果你刚开始做我建议从最简单的场景入手单房间的主动照明。选一个你待得最久的房间通常是客厅或卧室部署人体传感器、光照传感器、智能灯然后跑一个简单的主动照明逻辑。这个阶段的目的是跑通整条链路传感器→情境构建→LLM推理→设备控制。不要追求完美先让系统跑起来。我第一个版本只用了三天就搭好了虽然经常误判但至少验证了技术可行性。6.2 第二阶段多房间的情境联动单房间跑通后扩展到多房间。这个阶段的核心挑战是情境的跨房间传递。比如用户在客厅看电影然后起身去厨房系统需要判断用户是去拿饮料厨房灯调亮客厅灯保持还是去睡觉厨房灯调暗客厅灯关闭。我的做法是在Agent之间加一个意图广播机制。客厅Agent检测到用户离开广播一个用户离开客厅事件附带当前情境正在看电影。厨房Agent收到事件后结合自己的传感器数据用户进入厨房和广播的情境判断用户意图。6.3 第三阶段全屋智能体的自主协商最终形态是全屋Agent自主协商。每个房间的Agent有自己的目标比如保持舒适节约能源Agent之间通过协商达成全局最优。这个阶段我还在探索中。目前的做法是用LangGraph定义一个协商协议当多个Agent的目标冲突时比如客厅想开空调降温卧室想关空调省电由一个协调Agent也是LLM驱动的来做仲裁。仲裁的依据是全局优先级用户舒适度能源节约设备寿命。说实话这个阶段的技术挑战还很大。LLM做多Agent协商时有时候会陷入无限循环——两个Agent互相说服不了对方一直来回发消息。我目前的解决方案是设置最大协商轮数比如3轮超过就由协调Agent强制裁决。7. 我踩过的几个印象深刻的坑7.1 传感器抖动导致的幽灵触发人体传感器尤其是红外PIR类型的有个通病当环境温度接近人体温度时检测精度会大幅下降。夏天的时候我家客厅的PIR传感器经常在没人时误报有人导致灯莫名其妙地亮。我一开始以为是传感器坏了换了好几个都一样。后来查资料才知道这是PIR的物理特性决定的。解决方案是多传感器融合PIR 毫米波雷达 摄像头本地处理只输出有人/无人。三个传感器投票两个以上说有人才判定为有人。这样误报率从每天十几次降到了几乎为零。7.2 LLM的过度推理LLM有个毛病你给它一个简单的情境它非要推理出一堆有的没的。比如情境是客厅有人晚上8点灯关着LLM可能推理出用户可能刚回家需要开灯也可能用户准备出门不需要开灯还可能用户在找东西需要开灯但亮度要高……然后给你返回一个模棱两可的决策。我的解决方案是在Prompt里加约束如果情境信息不足以做出高置信度决策返回actionnone不要猜测。同时给LLM提供更多的上下文信息比如用户5分钟前从玄关进入减少不确定性。7.3 RAG检索到的信息互相矛盾家庭知识库里经常有矛盾的信息。比如成员偏好里写着用户喜欢暖光但行为模式显示用户最近一周都在用冷光。RAG检索会把两条都返回给LLMLLM就懵了。我的处理方式是给检索结果加时间权重和置信度权重。近期的行为模式权重高于早期的偏好设置用户手动设置的偏好权重高于系统学习的行为模式。在组装上下文时明确标注每条信息的来源、时间和置信度让LLM自己判断该采信哪条。7.4 设备离线时的决策降级智能家居系统不可能100%在线。网络断了、设备没电了、MQTT broker挂了这些都会发生。当系统检测到某个设备离线时LLM的决策需要降级。我的做法是维护一个设备可用性状态表在发给LLM的情境描述里明确标注哪些设备可用、哪些不可用。同时准备一套降级规则如果LLM不可用比如云端API超时自动切换到本地规则引擎如果某个设备不可用LLM会尝试用其他设备达到类似效果比如用智能插座控制台灯代替直接控制吸顶灯。8. 给想入坑的朋友几条实在建议如果你看到这里说明你对生成式AI智能家居这个方向是真感兴趣。我最后分享几条个人经验都是踩过坑之后总结出来的。第一条先做减法再做加法。不要一上来就想做全屋智能体。先选一个房间、一个场景、一个设备把整条链路跑通。我见过太多人买了一堆设备结果连最基本的自动化都没配好最后全部吃灰。第二条数据比模型重要。你用什么LLM其实没那么关键7B的本地模型和GPT-4在意图理解上的差距远没有你家的个性化数据质量带来的差距大。花时间整理你家的设备档案、成员偏好、行为记录这些数据才是让系统懂你的关键。第三条留好手动兜底。不管系统多智能一定要保留物理开关和手动控制。我家的所有智能灯都保留了物理开关所有智能插座都有手动按钮。系统出问题的时候你至少还能正常生活。第四条接受不完美。主动式智能家居不可能100%准确。我现在系统的准确率大概在85%左右也就是说每20次主动决策里有3次是错的。这个准确率已经让我觉得利大于弊了但如果你追求100%准确那还是回去用规则引擎吧。第五条关注成本。如果你用云端LLM API每次推理都是钱。我算过一笔账如果每5分钟推理一次一天288次一个月8640次按GPT-4的价格一个月大概几十美元。如果加上RAG检索和语音转文字成本更高。我的做法是本地模型处理80%的请求只有20%的复杂推理走云端这样成本降到了每月几美元。这个方向还在快速演进。我最近在试的是用Agentic RAG的思路让系统不仅能检索信息还能主动去问设备要数据、去查外部API获取信息。比如系统判断用户可能要出门会主动去查一下天气API、交通API然后综合判断要不要提醒用户带伞。这种主动获取信息的能力比被动等待检索又进了一步。等我这部分跑稳定了再找机会跟大家分享。 生成式AI+智能家居：从规则引擎到主动式Agent的工程实践
智能家居这个词这几年被说得有点烂了。打开任何一个电商平台搜智能家居跳出来的全是一句话开灯手机远程控制空调这类功能。说实话这些东西用起来并不智能——你还是得开口、得掏手机、得主动操作。真正的智能应该是你还没意识到自己需要什么环境已经替你调好了。这就是主动式智能家居和被动式智能家居的根本区别。我接触智能家居系统前后有六七年时间从最早的继电器模块加红外传感器到后来的Home Assistant自动化再到最近一年多在折腾生成式AI与家居系统的结合踩过的坑比走过的路还多。这篇文章想聊的就是怎么把LLM、RAG这些生成式AI技术真正落到智能家居场景里让系统从你命令它执行变成它判断你需要什么并主动执行。涉及的核心技术点包括主动式自动化的判定逻辑、LLM在意图理解中的角色、RAG如何解决家庭场景的个性化知识检索、以及整套系统的工程落地细节。不管你是刚入门想了解智能家居控制系统的设计思路还是已经在做LLM应用想找一个垂直场景落地这篇内容应该都能给你一些可以直接抄作业的东西。1. 为什么传统智能家居根本主动不起来1.1 规则引擎的天花板在哪里绝大多数人做智能家居自动化的方式是在Home Assistant、米家或者Apple Home里配一条条规则如果人体传感器检测到有人 且 时间在18:00-23:00之间 且 光照低于50lux则打开客厅灯。这种基于触发条件-动作Trigger-Condition-Action的规则引擎本质上是一个巨大的if-else树。问题在于真实生活不是if-else能覆盖的。我举几个我自己遇到过的场景夏天晚上我在客厅看电影人体传感器每隔几分钟就检测到无人因为我坐着不动灯自动关了。我不得不加一个媒体播放器正在播放时不关灯的条件但有时候我只是开着电视听个响人已经去厨房了灯又该关。家里来客人坐在沙发上聊天传感器检测到有人但光照充足灯不亮。但客人可能觉得暗想开灯又不好意思说。冬天早上闹钟响了我起床去洗漱。按照规则卫生间灯应该亮。但有时候我只是起来上个厕所就回去睡了灯亮了反而刺眼。这些场景的共同点是规则无法穷举条件之间存在冲突而且人的意图是动态变化的。你每加一条规则系统的复杂度就上升一个量级最终维护成本高到你想全部删掉。1.2 主动的本质是预测而非响应我后来想明白一件事主动式自动化的核心不是更快地响应而是提前预测。响应是被动的——事件发生了我处理。预测是主动的——我判断事件即将发生或需求即将出现提前处理。预测需要什么需要理解上下文。同样是人体传感器检测到有人在不同的时间、不同的历史行为模式、不同的环境参数下含义完全不同。传统规则引擎只能看到有人这个布尔值看不到背后的语义。这就是生成式AI切入的地方。LLM擅长什么擅长理解自然语言的上下文、做模糊推理、处理非结构化信息。RAG擅长什么擅长从大量个性化数据中检索出与当前情境最相关的信息。这两者结合起来就能让智能家居系统具备理解情境并预测需求的能力。1.3 从自动化到智能体的思维转变我现在的做法是把整个家居系统看作一个多智能体Multi-Agent系统。每个房间、每个设备组、甚至每个家庭成员都可以抽象成一个Agent。Agent之间通过消息传递协作由一个中央协调Agent基于LLM来做全局决策。这个思路的转变很关键以前我是写规则让设备执行现在我是定义Agent的能力边界和协作协议让它们自己协商出最优解。LLM在这里扮演的是协调者和翻译官的角色——把模糊的人类意图翻译成具体的设备指令把多个Agent的状态汇总成全局情境判断。2. 生成式AI在智能家居里的三个真实落点2.1 意图理解从开灯到我觉得有点暗传统语音助手最让人抓狂的地方是你必须说它认识的那几个词。开灯可以把灯打开可能也行我觉得有点暗它就懵了。因为传统NLU自然语言理解是基于意图分类和槽位填充的训练数据里没有我觉得有点暗对应开灯的样本它就识别不了。LLM天然解决了这个问题。你不需要训练数据只需要在System Prompt里告诉它用户表达暗看不清光线不好等含义时意图是调整照明。LLM就能理解各种变体。我实测下来用GPT-4级别的模型做意图理解准确率比传统NLU方案高出至少30个百分点尤其是在处理口语化、省略、指代等复杂表达时。但这里有个工程上的坑LLM的响应延迟。你不可能让用户说完我觉得有点暗之后等3秒钟灯才亮。我的做法是双通道本地跑一个轻量级的意图分类模型比如微调过的BERT或蒸馏后的小模型做快速响应同时把请求发给LLM做深度理解。如果本地模型置信度高直接执行置信度低等LLM的结果。这样既保证了响应速度又保证了复杂场景下的理解准确率。2.2 情境推理让系统知道现在是什么情况意图理解解决的是用户说了什么情境推理解决的是现在发生了什么。这两个是互补的。情境推理需要融合多源数据传感器数据温度、湿度、光照、人体存在、设备状态灯、空调、窗帘的开闭状态、时间信息几点、星期几、是否节假日、历史行为过去这个时间点用户通常在做什么、外部信息天气、空气质量。传统做法是给这些数据设阈值超过阈值就触发。但阈值是死的情境是活的。比如温度28度这个数据在夏天开空调的情况下是正常的在冬天没开暖气的情况下就是异常的。LLM可以结合上下文做推理当前是12月室内温度28度但暖气设定是22度且窗户传感器显示窗户开着——用户可能在通风不需要干预。我现在的系统里情境推理模块每5分钟跑一次把当前所有传感器的状态汇总成一个自然语言描述发给LLM做判断。LLM返回一个情境标签比如用户在客厅看电影用户准备出门用户已经入睡后续的自动化决策都基于这个标签来做。2.3 主动建议在用户开口之前就行动这是生成式AI在智能家居里最有价值但也最难做好的部分。主动建议意味着系统要判断用户接下来可能需要什么并提前执行或询问。我举一个我实际跑通的例子系统检测到以下信号——1工作日早上7:002卧室人体传感器检测到用户已起床3卫生间人体传感器在2分钟内被触发4天气预报显示今天下雨气温比昨天低5度5用户日历显示今天9:00有会议。LLM综合这些信息后判断用户正在洗漱准备出门上班今天天气不好需要带伞而且有会议不能迟到。于是系统执行卫生间灯调到暖光模式避免刚起床刺眼客厅窗帘打开30%让用户知道天亮了但不用全开玄关灯提前亮起同时在音箱里播报今天有雨气温12度比昨天低5度建议穿外套带伞。您9点有会议现在7:15建议7:40前出门。这个场景里没有任何一条规则是如果A则B能覆盖的。它是多个信号的综合推理结果而且每个信号单独看都不足以触发行动。3. RAG在家庭场景里的独特价值3.1 为什么家庭场景需要RAG而不是纯LLM你可能会问LLM不是已经能理解情境了吗为什么还需要RAG原因很简单LLM不知道你家的具体情况。它不知道你家客厅有几盏灯、分别是什么型号、你老婆对色温的偏好是暖光还是冷光、你儿子每天晚上几点必须上床睡觉、你家猫的活动规律是什么。这些信息是高度个性化的不可能通过预训练获得。RAG检索增强生成的作用就是在LLM做推理之前先从你的家庭知识库里检索出相关的个性化信息作为上下文一起发给LLM。这样LLM的推理就是基于你家的真实情况而不是泛泛的通用知识。3.2 家庭知识库该放什么、怎么组织我家的知识库目前包含以下几类数据我用一个表格来说明数据类型具体内容更新频率检索方式设备档案设备型号、位置、能力、通信协议设备增减时更新结构化查询成员偏好各家庭成员的照明/温度/音乐偏好手动维护行为学习向量检索行为模式历史传感器数据、设备操作记录实时写入时序向量混合场景规则用户定义的硬性规则如孩子房间22:00后必须关灯手动维护关键词向量外部信息天气、日历、交通定时同步API调用这里的关键设计决策是不是所有数据都适合向量化。设备档案这种结构化数据用传统数据库查询更快更准。行为模式这种时序数据需要结合时间窗口做检索。只有成员偏好和场景规则这种半结构化、语义丰富的数据才适合用向量检索。我用的技术栈是PostgreSQL pgvector。选它的理由很实际我本来就用PostgreSQL存设备状态和历史数据加一个pgvector扩展就能同时做结构化查询和向量检索不需要额外维护一个向量数据库。对于家庭场景这种数据量不大我家大概几万条记录的情况pgvector的性能完全够用。3.3 检索策略什么时候查、查什么、怎么用RAG在智能家居里的检索策略和通用问答场景不太一样。通用问答是用户提问→检索→生成回答家居场景是情境触发→检索相关个性化信息→辅助LLM推理→生成设备指令。我的实现是这样的# 情境触发时的RAG检索流程简化版 async def retrieve_context(situation_embedding, current_time, room): # 1. 检索与当前情境最相关的成员偏好 preferences await vector_search( tablemember_preferences, query_vectorsituation_embedding, filter{room: room}, top_k3 ) # 2. 检索当前时间窗口内的行为模式 behavior_patterns await time_series_search( tablebehavior_logs, time_range(current_time - timedelta(hours2), current_time), roomroom ) # 3. 检索硬性规则必须遵守的 hard_rules await keyword_search( tablescene_rules, keywords[room, 必须, 禁止], limit5 ) # 4. 组装成LLM可理解的上下文 context format_context(preferences, behavior_patterns, hard_rules) return context这里有个经验硬性规则必须用关键词检索而不是向量检索。因为硬性规则是必须遵守的不能因为语义相似度不够就漏掉。比如孩子房间22:00后必须关灯这条规则如果用户说把孩子的灯调暗一点向量检索可能匹配不到这条规则但关键词检索能匹配到孩子和灯。4. 搭建主动式智能家居系统的完整工程路径4.1 技术选型为什么我最终选了这套组合我试过不少方案最终稳定下来的技术栈是这样的消息层MQTT设备通信 Redis Streams内部事件总线数据层PostgreSQL pgvector结构化向量 InfluxDB时序数据AI层FastAPI LangChain LangGraphAgent编排 本地部署的7B模型快速意图分类 云端API复杂推理自动化层Home Assistant设备控制 自研的Agent协调服务选LangGraph而不是简单的LangChain Chain是因为主动式场景需要有状态的循环推理。比如系统判断用户可能想看电影需要先查一下当前灯光状态再决定要不要调暗调暗之后还要确认用户是否满意通过后续行为判断。这种多步骤、有状态、可能循环的推理流程用LangGraph的图结构来表达最自然。4.2 从传感器数据到主动决策的完整链路我把整条链路拆成五个阶段每个阶段都有明确的输入输出阶段一数据采集与清洗。传感器数据通过MQTT上报经过一个清洗层过滤掉抖动和异常值。比如人体传感器在2秒内连续上报有人无人有人这显然是抖动清洗层会合并成一次有人事件。阶段二情境构建。每5分钟或关键事件触发时把当前所有传感器状态、设备状态、时间信息汇总成一个结构化的情境描述。这个描述是自然语言的方便LLM理解。阶段三RAG检索。用情境描述的embedding去检索相关的成员偏好、行为模式、硬性规则。阶段四LLM推理。把情境描述RAG检索结果系统Prompt一起发给LLM让LLM输出一个决策。决策格式是结构化的JSON包含是否执行动作、执行什么动作、执行参数、置信度、是否需要询问用户。阶段五执行与反馈。根据LLM的决策执行设备控制同时记录执行结果和用户反馈用户是否手动覆盖了系统的决策用于后续优化。4.3 让LLM稳定输出JSON的实战技巧这是我在整个项目里踩坑最多的地方。LLM返回的JSON不稳定有时候多一个逗号有时候少一个引号有时候干脆返回一段自然语言解释而不是JSON。我试过以下几种方案方案一Prompt Engineering。在System Prompt里反复强调只返回JSON不要任何其他文字并给出严格的JSON Schema。效果一般大概80%的情况下能返回正确格式。方案二JSON Mode。OpenAI的API支持response_format{type: json_object}强制模型返回合法JSON。效果好很多但模型仍然可能返回不符合你Schema的JSON比如字段名拼错、类型不对。方案三Function Calling。把决策定义为一个Function让LLM通过Function Calling来输出。这是目前最稳定的方案我实测下来格式正确率接近100%。缺点是灵活性稍差复杂的嵌套决策需要定义多个Function。方案四输出后修复。不管用哪种方案我都会在代码里加一层JSON修复逻辑。用Python的json.loads尝试解析失败则用正则提取JSON部分再失败则调用一个轻量级模型做格式修复。这个兜底逻辑救了我无数次。import json import re def parse_llm_decision(raw_output: str) - dict: 解析LLM输出的决策JSON带多级兜底 # 第一级直接解析 try: return json.loads(raw_output) except json.JSONDecodeError: pass # 第二级提取JSON块 json_match re.search(r\{.*\}, raw_output, re.DOTALL) if json_match: try: return json.loads(json_match.group()) except json.JSONDecodeError: pass # 第三级修复常见问题后重试 cleaned raw_output.strip() cleaned re.sub(r,\s*}, }, cleaned) # 去掉尾逗号 cleaned re.sub(r,\s*], ], cleaned) cleaned cleaned.replace(, ) # 单引号转双引号 try: return json.loads(cleaned) except json.JSONDecodeError: pass # 第四级返回安全默认值 return {action: none, reason: parse_failed, confidence: 0.0}提示第四级兜底非常重要。当所有解析都失败时系统必须有一个安全的默认行为——什么都不做而不是执行一个可能错误的指令。在智能家居场景里错误执行比如半夜把灯全打开比不执行糟糕得多。5. 那些只有真正跑起来才会遇到的问题5.1 延迟用户等不了3秒钟这是主动式智能家居最大的工程挑战。用户说了一句话期望在500毫秒内得到响应。但LLM的推理时间通常在1-3秒如果加上RAG检索可能到5秒。我的解决方案是分级响应Level 0100ms本地规则引擎处理明确的、高频的指令。比如开灯这种直接走本地NLU规则不经过LLM。Level 1500ms本地小模型处理意图明确的指令。比如我觉得有点暗本地微调过的模型能识别为调亮灯光。Level 21-3sLLM处理复杂情境推理。比如我要看电影需要综合判断灯光、窗帘、音响、空调的状态。Level 3后台异步主动建议和长期学习。不要求实时响应可以在后台慢慢跑。关键设计是Level 2和Level 3的决策结果会缓存起来。如果同样的情境再次出现直接走缓存响应时间降到毫秒级。缓存的有效期根据情境的稳定性来定比如工作日早上7点这个情境的缓存可以管24小时有人移动这个情境的缓存只能管30秒。5.2 误报系统太主动反而烦人我刚开始跑主动建议的时候系统特别积极。我走到客厅它问我要不要开灯我坐下它问我要不要开电视我去厨房它问我要不要开抽油烟机。一天下来问了我几十次我烦得直接把主动建议关了。后来我总结了几条原则原则一主动执行被动询问。对于低风险、高确定性的动作比如开灯、调温度直接执行不要问。对于高风险、低确定性的动作比如锁门、关燃气先询问再执行。原则二设置静默期。同一个主动建议如果用户连续拒绝两次接下来24小时内不再提。如果用户接受了可以适当增加频率。原则三置信度阈值动态调整。刚开始跑的时候置信度阈值设高一点比如0.85只在高置信度时才主动。随着系统学习用户行为逐步降低阈值增加主动性。原则四给用户一个闭嘴按钮。我在每个房间都放了一个物理按钮按一下就是接下来1小时不要主动建议。有时候用户就是想要安静不想被系统打扰。5.3 隐私数据放本地还是放云端这是每个做智能家居AI的人都会纠结的问题。传感器数据、行为记录、语音指令这些数据如果全部上传云端隐私风险很大。但如果全部本地处理算力又不够。我的方案是分层处理敏感数据本地处理语音唤醒、语音转文字、人体存在检测这些全部在本地完成。我用的是一个本地部署的Whisper模型做语音转文字识别结果只保留文本原始音频立即删除。脱敏数据上传云端需要LLM做复杂推理时只上传脱敏后的情境描述比如客厅有人光照低时间晚上8点不上传原始传感器数据和个人身份信息。个性化数据本地存储成员偏好、行为模式这些数据存在本地PostgreSQL里RAG检索也在本地完成。只有检索结果已经脱敏的上下文才会和情境描述一起发给LLM。这样做的代价是本地需要一台性能还行的服务器。我用的是一个Intel NUC16GB内存跑一个7B的量化模型做本地意图分类同时跑PostgreSQL和Home Assistant负载大概在60%左右完全够用。5.4 模型更新LLM升级后行为变了怎么办这个问题很隐蔽但很致命。你花了一个月调好的Prompt和决策逻辑某天LLM提供商升级了模型版本行为突然变了。原来能正确输出的JSON现在格式不对了原来能理解的指令现在理解错了。我的应对策略是策略一锁定模型版本。如果用的是云端API尽量选择有版本号的模型比如gpt-4-0613而不是gpt-4避免自动升级到最新版。策略二建立回归测试集。我收集了200个典型情境期望决策的测试用例每次模型更新或Prompt修改后跑一遍回归测试确保核心场景的行为不变。策略三A/B测试。新模型先跑影子模式Shadow Mode也就是新模型和旧模型同时推理但只有旧模型的决策被执行。对比两者的决策差异确认新模型没有退化后再切换。6. 从单点智能到全屋智能体的演进路线6.1 第一阶段单房间的主动照明如果你刚开始做我建议从最简单的场景入手单房间的主动照明。选一个你待得最久的房间通常是客厅或卧室部署人体传感器、光照传感器、智能灯然后跑一个简单的主动照明逻辑。这个阶段的目的是跑通整条链路传感器→情境构建→LLM推理→设备控制。不要追求完美先让系统跑起来。我第一个版本只用了三天就搭好了虽然经常误判但至少验证了技术可行性。6.2 第二阶段多房间的情境联动单房间跑通后扩展到多房间。这个阶段的核心挑战是情境的跨房间传递。比如用户在客厅看电影然后起身去厨房系统需要判断用户是去拿饮料厨房灯调亮客厅灯保持还是去睡觉厨房灯调暗客厅灯关闭。我的做法是在Agent之间加一个意图广播机制。客厅Agent检测到用户离开广播一个用户离开客厅事件附带当前情境正在看电影。厨房Agent收到事件后结合自己的传感器数据用户进入厨房和广播的情境判断用户意图。6.3 第三阶段全屋智能体的自主协商最终形态是全屋Agent自主协商。每个房间的Agent有自己的目标比如保持舒适节约能源Agent之间通过协商达成全局最优。这个阶段我还在探索中。目前的做法是用LangGraph定义一个协商协议当多个Agent的目标冲突时比如客厅想开空调降温卧室想关空调省电由一个协调Agent也是LLM驱动的来做仲裁。仲裁的依据是全局优先级用户舒适度能源节约设备寿命。说实话这个阶段的技术挑战还很大。LLM做多Agent协商时有时候会陷入无限循环——两个Agent互相说服不了对方一直来回发消息。我目前的解决方案是设置最大协商轮数比如3轮超过就由协调Agent强制裁决。7. 我踩过的几个印象深刻的坑7.1 传感器抖动导致的幽灵触发人体传感器尤其是红外PIR类型的有个通病当环境温度接近人体温度时检测精度会大幅下降。夏天的时候我家客厅的PIR传感器经常在没人时误报有人导致灯莫名其妙地亮。我一开始以为是传感器坏了换了好几个都一样。后来查资料才知道这是PIR的物理特性决定的。解决方案是多传感器融合PIR 毫米波雷达 摄像头本地处理只输出有人/无人。三个传感器投票两个以上说有人才判定为有人。这样误报率从每天十几次降到了几乎为零。7.2 LLM的过度推理LLM有个毛病你给它一个简单的情境它非要推理出一堆有的没的。比如情境是客厅有人晚上8点灯关着LLM可能推理出用户可能刚回家需要开灯也可能用户准备出门不需要开灯还可能用户在找东西需要开灯但亮度要高……然后给你返回一个模棱两可的决策。我的解决方案是在Prompt里加约束如果情境信息不足以做出高置信度决策返回actionnone不要猜测。同时给LLM提供更多的上下文信息比如用户5分钟前从玄关进入减少不确定性。7.3 RAG检索到的信息互相矛盾家庭知识库里经常有矛盾的信息。比如成员偏好里写着用户喜欢暖光但行为模式显示用户最近一周都在用冷光。RAG检索会把两条都返回给LLMLLM就懵了。我的处理方式是给检索结果加时间权重和置信度权重。近期的行为模式权重高于早期的偏好设置用户手动设置的偏好权重高于系统学习的行为模式。在组装上下文时明确标注每条信息的来源、时间和置信度让LLM自己判断该采信哪条。7.4 设备离线时的决策降级智能家居系统不可能100%在线。网络断了、设备没电了、MQTT broker挂了这些都会发生。当系统检测到某个设备离线时LLM的决策需要降级。我的做法是维护一个设备可用性状态表在发给LLM的情境描述里明确标注哪些设备可用、哪些不可用。同时准备一套降级规则如果LLM不可用比如云端API超时自动切换到本地规则引擎如果某个设备不可用LLM会尝试用其他设备达到类似效果比如用智能插座控制台灯代替直接控制吸顶灯。8. 给想入坑的朋友几条实在建议如果你看到这里说明你对生成式AI智能家居这个方向是真感兴趣。我最后分享几条个人经验都是踩过坑之后总结出来的。第一条先做减法再做加法。不要一上来就想做全屋智能体。先选一个房间、一个场景、一个设备把整条链路跑通。我见过太多人买了一堆设备结果连最基本的自动化都没配好最后全部吃灰。第二条数据比模型重要。你用什么LLM其实没那么关键7B的本地模型和GPT-4在意图理解上的差距远没有你家的个性化数据质量带来的差距大。花时间整理你家的设备档案、成员偏好、行为记录这些数据才是让系统懂你的关键。第三条留好手动兜底。不管系统多智能一定要保留物理开关和手动控制。我家的所有智能灯都保留了物理开关所有智能插座都有手动按钮。系统出问题的时候你至少还能正常生活。第四条接受不完美。主动式智能家居不可能100%准确。我现在系统的准确率大概在85%左右也就是说每20次主动决策里有3次是错的。这个准确率已经让我觉得利大于弊了但如果你追求100%准确那还是回去用规则引擎吧。第五条关注成本。如果你用云端LLM API每次推理都是钱。我算过一笔账如果每5分钟推理一次一天288次一个月8640次按GPT-4的价格一个月大概几十美元。如果加上RAG检索和语音转文字成本更高。我的做法是本地模型处理80%的请求只有20%的复杂推理走云端这样成本降到了每月几美元。这个方向还在快速演进。我最近在试的是用Agentic RAG的思路让系统不仅能检索信息还能主动去问设备要数据、去查外部API获取信息。比如系统判断用户可能要出门会主动去查一下天气API、交通API然后综合判断要不要提醒用户带伞。这种主动获取信息的能力比被动等待检索又进了一步。等我这部分跑稳定了再找机会跟大家分享。