从 OpenClaw 到 Home Assistant用开源大模型搭一个真正的家庭 AI 中枢0. 开篇你要的不是能听懂话的开关而是一个会决策的家庭中枢绝大多数智能家居玩家的终点是一套写满如果—那么规则的 Home Assistant晚上十点关灯、湿度低于 40% 开加湿器、门锁打开就开玄关灯。这套系统稳定、可预测但它的智能上限被规则条数锁死——你必须提前想到每一个场景并为每一种例外补一条规则。于是很多人开始给 Home Assistant 接大模型最常见的做法是语音开关灯说一句打开客厅灯模型解析出实体调用一次服务。这确实是进步但它本质上只是一个自然语言遥控器没有上下文、没有任务拆解、没有对结果的确认与解释。本文要讲的是再往前一步的形态把家庭 AI 中枢拆成四层——Agent 编排OpenClaw/ 设备中枢Home Assistant/ 工具协议MCP辅以 MQTT/ 推理引擎本地开源模型让一个常驻的 Agent 能理解模糊意图、跨设备编排动作、执行后回读状态并把决策过程留痕可审计。以一个贯穿全文的场景为例——你说我要睡了传统自动化需要预先写好睡觉场景绑死若干设备动作。你临时想加一条顺便看看门锁有没有锁就得回去改规则。Agent 化控制Agent 把意图拆解为若干步骤关公共区域灯、拉窗帘、空调切到睡眠模式、检查门锁与燃气报警状态、汇总反馈逐条调用工具执行后回读状态最后用自然语言汇报已完成门锁已上锁卧室空调 26 度睡眠风。需要先说清楚目标与非目标。目标是自然语言交互、跨设备跨域编排、决策可解释可审计、私有化部署。非目标是全自动无人值守、替代厂商网关、把所有家庭控制权交给模型。后面第 6 节会专门讲这条边界。本文全部结论基于公开的开发者社区文章与开源仓库见文末参考资料。需要说明的是本次采集到的来源没有可用的发布时间与热度数据因此文中不会出现全网热议现象级这类热度判断同时社区中存在一批标题高度同构的OpenClaw 某模型系列文章其技术细节无法逐一核实本文仅把它们作为该话题在开发者社区被持续讨论的存在性证据不引用其中的模型版本号与性能结论[4][5]。1. 架构总览家庭 AI 中枢的四层拆解1.1 四层各自的职责一个可长期运行的家庭 AI 中枢责任必须切干净。把想和做混在同一层是大多数自建方案后期难以维护的根源。层承担者输入输出失败时的表现替换成本Agent 编排OpenClaw用户自然语言、会话上下文任务计划、工具调用序列、最终回复意图理解错、选错工具、计划冗余中会话历史与技能需迁移工具协议MCP MQTT模型生成的结构化调用校验后的 API 请求、工具执行结果工具不可发现、参数校验失败低工具描述是声明式数据设备中枢Home Assistant服务调用请求实体状态、事件流设备不响应、状态不同步高设备迁移成本最大推理引擎本地开源模型提示词、工具定义、历史消息结构化输出、工具调用参数延迟高、幻觉出不存在的实体中模型可换接口保持兼容这个划分背后有三条设计原则第一Home Assistant 是设备状态的唯一事实源。模型的上下文里不应该长期缓存客厅灯是开着的任何需要确认的事实都要回读 HA 的实时状态。这是避免幻觉的最廉价手段。第二Agent 不直接操作设备只操作工具。模型不接触 HA 的令牌也不接触 MQTT 的主题它只能提出我要调用某个工具由编排层做权限与参数校验后放行。第三推理引擎可换接口必须收敛。只要推理服务暴露 OpenAI 兼容接口换模型就是改一个 base URL 的事。这条原则决定了后面第 3 节的选型思路按任务分工选模型而不是按榜单选模型。1.2 一次指令的完整链路以我要睡了为例链路上每一步的产物是ASR 或文本入口把用户输入交给 OpenClaw附带会话上下文房间、时间、上次说过什么。OpenClaw 把系统提示、工具列表、历史消息发给本地推理服务模型输出一次或多次工具调用。MCP 客户端执行tools/call编排层先过白名单与参数校验再把请求转成 HA 的服务调用。HA 执行light.turn_off、cover.close_cover、climate.set_preset_mode等服务。编排层回读相关实体状态把结果注入对话模型据此生成回复若某一步失败回复中必须明确指出失败项而不是含糊带过。社区里已经有大量把 OpenClaw 与 Home Assistant 串起来的实践文章[2]以及面向家庭场景的场景化自动化指南[3]、教程化教材[8]说明这条链路在开发者侧已经被反复走通。但要注意OpenClaw 的配置文件结构、MCP server 注册语法、是否内置 HA 专用集成均以其官方仓库与文档为准本文给出的配置片段是骨架示意不是可直接复制的最终格式。2. 协议层MCP 在家庭场景到底解决什么问题2.1 为什么不用在 Prompt 里写 API 文档最省事的做法是把 HA 的 REST API 说明直接塞进系统提示词让模型照着拼 HTTP 请求。这在 Demo 阶段可用但很快会遇到四个问题工具不可发现、参数无约束、提示词随接口膨胀、权限完全依赖模型自觉。MCPModel Context Protocol把能力变成声明式的工具清单server 声明tools/listclient 通过tools/call发起调用参数由 JSON Schema 约束。对家庭场景的实际收益是可发现换一个模型工具列表自动继承不需要重写提示词。可校验entity_id格式、domain枚举、数值范围在执行前就能拦住非法参数。可移植同一套 HA 工具既能给 OpenClaw 用也能给其他 Agent 框架用社区已经有把设备服务包装为 MCP 服务、再接入不同 Agent 平台的探索[6]。可授权编排层可以在工具执行前插入权限判断而不是事后审计。2.2 从 HA 服务到 MCP 工具粒度设计是关键工具粒度是最容易踩坑的地方过粗一个control_home(action)工具。模型要在一个字符串里表达全部意图几乎无法校验出错率高。过细每个实体一个工具。一套 200 实体的房子里会产生 200 个工具定义占用大量上下文模型选错的概率反而上升。务实的折中是按域 参数化并把只读与写入分开{name:ha_get_state,description:查询一个或多个 Home Assistant 实体的实时状态。在执行任何控制动作前应先用它确认目标实体存在且状态符合预期。,inputSchema:{type:object,properties:{entity_ids:{type:array,items:{type:string},description:形如 light.bedroom_main 的实体 ID 列表}},required:[entity_ids]}}{name:ha_call_service,description:调用 Home Assistant 的设备服务。仅允许白名单内的域与服务。,inputSchema:{type:object,properties:{domain:{type:string,enum:[light,switch,climate,cover,fan,media_player]},service:{type:string,enum:[turn_on,turn_off,toggle,set_temperature,set_preset_mode,open_cover,close_cover,stop_cover]},target:{type:object,properties:{entity_id:{type:string}},required:[entity_id]},data:{type:object,description:服务参数如 brightness_pct、temperature、preset_mode}},required:[domain,service,target]}}模型侧发起调用时走的是标准的 JSON-RPC 风格请求{jsonrpc:2.0,id:7,method:tools/call,params:{name:ha_call_service,arguments:{domain:light,service:turn_off,target:{entity_id:light.living_room_main}}}}MCP 的工具定义、tools/list与tools/call的确切字段与语义以官方规范为准实现时不要凭记忆手写 schema。Home Assistant 侧的服务调用本身是稳定的公开接口。以 REST API 为例# 查询状态只读curl-shttp://homeassistant.local:8123/api/states/light.bedroom_main\-HAuthorization: Bearer$HA_TOKEN# 调用服务写入curl-s-XPOST http://homeassistant.local:8123/api/services/light/turn_on\-HAuthorization: Bearer$HA_TOKEN\-HContent-Type: application/json\-d{entity_id: light.bedroom_main, brightness_pct: 30}HA_TOKEN是在 HA 用户资料页生成的长期访问令牌Long-Lived Access Token。它的权限粒度较粗等同于一个完整用户因此不应该出现在模型可见的上下文里只应由 MCP server 持有。这一点在第 6 节会展开。REST 调用规范请以 HA 开发者文档为准WebSocket API 能提供事件订阅与更细的调用反馈适合做状态回读与审计流。2.3 MQTT 的位置给 ESP32 们一条可扩展的接入路MQTT 不是 MCP 的替代品而是端侧设备的传输层。摄像头、麦克风、温湿度传感器这类 ESP32/嵌入式节点往往没有能力跑 HTTP server 或维护长连接到 Agent但它们天然适合发布/订阅模型。社区已有ESP32 MCP over MQTT的系列实践从语音交互、图像采集到多模态理解逐层扩展[7]。取舍很直接引入 broker 多了一跳换来设备解耦、离线缓冲和多客户端共享。对家庭场景这个交换通常是划算的。至于 A2A 这类 Agent 间协作协议在单家庭单 Agent 的场景里目前非必需。只有当你确实需要多个独立 Agent如安防 Agent、能耗 Agent、陪伴 Agent互相委托任务时才值得引入在此之前用编排层内的任务分解就够了。社区中出现的多 Agent 协作系统属于实验性探索成熟度需要自行验证。3. 本地开源模型的角色分工Qwen / GLM / Phi-3 各干什么3.1 家庭 Agent 对模型的真实要求家庭 Agent 对模型的要求和写文章、做问答完全不同优先级大致是工具调用可靠性能不能稳定输出结构化、参数正确的调用而不是自由发挥。中文指令鲁棒性口语、省略、指代“把它关了”要能还原成正确实体。结构化输出JSON 严格可解析不夹带解释文字。延迟常驻语音场景里超过几秒的响应会让人放弃使用。文采基本不重要。因此选型应该按任务分工而不是按榜单排名。下面的表只给维度与候选家族具体型号、参数量、量化方案必须在自己的硬件上实测各家族的工具调用支持状态与推荐调用格式请以官方文档为准。角色能力要求候选家族部署形态备注工具调用 / 意图理解主力强结构化输出、稳定 function calling、中文理解Qwen 系列 Instruct/工具调用版本、GLM 系列本地 GPU 或高性能 CPU承担绝大多数控制类请求轻量兜底 / 高频短指令低延迟、低资源、意图分类够用Phi-3 级别小参数量模型常驻内存、随时可唤醒处理开灯关窗帘这类高频短指令复杂规划 / 长文本强推理、长上下文更大规模模型本地或云端按需调用偶发的多步骤编排、自动化生成视觉 / 多模态可选图像理解、界面识别Qwen-VL 类多模态系列、Phi-3 视觉变体独立评估显存开销用于摄像头场景识别隐私代价见 5.2说明社区文章中出现过的若干具体型号命名如某些9B“Flash”Thinking后缀的版本号无法从官方来源核实本文不采用也不建议读者据此选型。这些同构文章更多反映的是OpenClaw 国产开源模型这条路线在开发者社区被持续讨论[4][5]。3.2 推理服务与 Agent 的接口OpenAI 兼容层是最省事的粘合剂用 Ollama 或 vLLM 之类的推理服务暴露 OpenAI 兼容接口是把本地模型接入 Agent 的最低成本路径# 以 Ollama 为例通过 OpenAI 兼容端点做一次带工具的对话curlhttp://localhost:11434/v1/chat/completions\-HContent-Type: application/json\-d{ model: 你的本地模型标签, messages: [ {role: system, content: 你是家庭设备控制助手只能通过工具操作设备。}, {role: user, content: 我要睡了} ], tools: [ { type: function, function: { name: ha_call_service, description: 调用 Home Assistant 设备服务, parameters: { type: object, properties: { domain: {type: string}, service: {type: string}, entity_id: {type: string} }, required: [domain, service, entity_id] } } } ], stream: false }长驻 Agent 有几个必须处理的工程点上下文截断策略会话历史不能无限增长。实践上可以把用户长期偏好压缩成短摘要常驻把每次工具执行的原始返回在若干轮后丢弃。工具结果注入格式工具返回的状态要以结构化、带实体 ID 的形式回填避免模型把卧室灯错认为客厅灯。并发会话多个家庭成员同时说话时推理服务要能排队或并行小模型跑并发会显著放大延迟。失败重试与幂等工具调用超时后重试可能导致重复执行写入类工具应尽量设计成幂等turn_on幂等toggle不幂等。3.3 本地 vs 云端一条务实的混合建议维度全本地混合全云端隐私最好家庭对话不出户取决于分流策略需明示家庭对话与设备状态外发延迟取决于硬件可能不稳定高频指令低延迟依赖网络通常较稳定离线可用有部分有无工具调用可靠性受本地模型能力限制可按任务择优通常最强成本一次性硬件投入硬件 少量 API 费用持续订阅/调用费用维护需自己维护维护面最大最省心务实的建议是高频、短指令、涉及隐私的设备控制走本地复杂规划、长文本、低频任务可以走云端但必须让用户知情并可关闭。反对为了本地而本地——当硬件不足以支撑一个可用的工具调用模型时体验倒退会直接摧毁可用性这时换更小的模型分工或者接受混合比硬撑更有价值。4. 动手落地最小可行链路MVP目标在一台机器上跑通一句话控制一盏灯并且每一层都能单独验证。不要一上来就做语音、视觉、记忆那会让故障点互相掩盖。4.1 第一步HA 侧准备——实体规范化与只读验证模型选对设备的前提是实体可读。请先做三件事命名语义化light.living_room_main比light.switch_3a2f可靠得多。区域Area、标签Label也要填它们是 Agent 理解卧室的灯的关键。收敛实体数量把不再使用的设备禁用实体越少工具选择越准。手工验证接口用第 2 节的 curl 依次跑通查状态、开灯、关灯确认令牌有效、实体 ID 正确。验收标准能在命令行里用 curl 开关这盏灯并查到状态变化。4.2 第二步部署本地模型与推理服务选一台机器NUC、带独显的主机或云主机均可起推理服务验证两件事普通对话可用带tools参数的请求能返回结构化的工具调用。# 验证服务存活curlhttp://localhost:11434/v1/models# 验证工具调用返回中应包含 tool_calls且参数为合法 JSON# 把上一节的请求原样发送检查响应结构验收标准响应中出现tool_callsarguments可被 JSON 解析。若模型输出夹带解释文本优先更换模型或调整工具描述而不是在编排层写复杂的正则去抠参数。4.3 第三步把 HA 能力包装成 MCP 工具并接入 OpenClaw顺序是先只读、后写入。先只注册ha_get_state确认 Agent 能查到状态再注册ha_call_service并只开放一个灯的白名单。编排层的 MCP server 注册是声明式的大致结构如下字段名与路径以 OpenClaw 官方文档为准此处仅示意{mcpServers:{home-assistant:{command:python,args:[-m,ha_mcp_server],env:{HA_URL:http://homeassistant.local:8123,HA_TOKEN:由编排层从环境变量或密钥文件读取}}}}接入后验证tools/list应当能看到你声明的工具且 schema 未被截断。社区已有 MCP 设备服务的实验性实现可供参考[6]也有专门的智能家居 MCP 实验仓库但具体实现细节需要读源码确认。4.4 第四步端到端验证与观测跑一次睡前模式把完整日志留下来。下面是一份自建演示日志样例非他人实测数据用于说明应当观测什么[10:41:02] user: 我要睡了 [10:41:03] model.plan: 1)查卧室与客厅灯状态 2)关公共区域灯 3)拉窗帘 4)空调睡眠模式 5)检查门锁 [10:41:03] tools/call ha_get_state [light.living_room_main,light.bedroom_main,lock.entry_door] [10:41:04] result: living_room_mainon, bedroom_mainon, entry_doorlocked [10:41:04] tools/call ha_call_service light.turn_off light.living_room_main [10:41:05] result: ok [10:41:05] tools/call ha_call_service cover.close_cover cover.bedroom_curtain [10:41:07] result: ok [10:41:07] tools/call ha_call_service climate.set_preset_mode climate.bedroom presetsleep [10:41:08] result: ok [10:41:08] state re-read: entry_doorlocked [10:41:09] reply: 已为你关闭客厅灯、拉上卧室窗帘卧室空调切换到睡眠模式。入户门当前是上锁状态。常见故障的定位树现象大概率故障层排查动作完全没反应推理服务检查端口、模型是否加载、请求是否超时回复正常但没动作工具协议检查tools/list是否包含工具、白名单是否拦截报实体不存在设备中枢用ha_get_state核对实体 ID检查命名动作执行了但状态不同步设备中枢查设备是否真的在线、是否被其他自动化改写参数格式错误模型缩小工具描述歧义或换更强的工具调用模型5. 进阶能力语音、视觉、记忆与自动化共存5.1 语音把中枢变成能对话的中枢语音链路是唤醒 → ASR → Agent → TTS。分层思路是唤醒与 ASR 尽量端侧唤醒词检测和语音转文本可以放在本地避免常驻麦克风持续外发音频。TTS 端侧优先播报内容包含家庭状态本地合成更可控。ASR 结果必须可编辑识别错误要在界面上可见可改否则 Agent 会忠实地执行错误指令。延迟预算是语音场景的核心指标唤醒到首字播报如果超过两三秒体感就是迟钝。这会反过来限制你选多大的本地模型。5.2 视觉与多模态收益与隐私代价视觉能带来真实价值识别有人离开客厅“灶台无人但火开着”但它是家庭隐私风险最高的能力。工程上可选的缓解手段包括本地推理图像不出设备推理在本地完成只上报结构化结论如客厅无人而非原始画面。脱敏处理在图像进入模型前做模糊化、打码或只保留骨架/姿态等抽象特征。非成像传感器替代用毫米波存在传感器、门窗传感器、功耗传感器推断状态很多时候比摄像头更合适。社区已有把摄像头接入 Agent 的多模态探索[7]也有面向智能空间的隐私处理讨论。原则是能用非成像传感器解决的不要上摄像头上了摄像头的不要把原始画面送进云端模型。5.3 记忆与个性化别让 Agent 每次失忆记忆应分三类放在不同层短期会话记忆放在 Agent 编排层的上下文里几轮后压缩或丢弃。长期偏好记忆如我睡觉时喜欢 26 度可以存为 HA 的辅助实体input_text、input_number或本地向量库供工具查询。设备与事件历史留在 Home Assistant 的历史数据库里Agent 通过工具按需查询不要复制一份到模型上下文。HA 生态里已有若干带记忆能力的开源方案可供参考home-llm[9]、hass-agent-llm含向量检索与自动记忆抽取、home-generative-agent、HA-Hybrid-Conversation 等。它们的维护状态、许可证与实际效果需阅读各自仓库确认本文只作为该方向存在多种实现路径的证据。5.4 与传统自动化共存确定性任务留给 HA模糊任务交给 Agent这是整套设计里最重要的一条工程纪律确定性强、涉及安全、有时间要求的任务写成 HA 原生自动化烟雾报警联动排风、离家自动关电、定时关闭取暖器。意图模糊、跨域编排、一次性任务交给 Agent“我要睡了”“帮我把周末的氛围调得轻松一点”。反过来说用 Agent 去实现本该由一条自动化完成的任务是在用不确定性的组件承担确定性的责任是典型的架构倒退。6. 安全与可靠性家庭场景的红线6.1 权限分级只读 → 可逆写入 → 高危操作需确认风险等级典型操作策略低查询状态、读取传感器Agent 可自主执行中开关灯、窗帘、空调、音箱Agent 可自主执行但需回读确认并留痕高门锁开锁、安防撤防、燃气阀门、大功率加热设备默认禁止必须人工确认或仅允许只读查询具体到工具设计HIGH_RISK_SERVICES{(lock,unlock),(alarm_control_panel,alarm_disarm),(switch,turn_on),# 需按实体再细分加热器、燃气类}defguard(service_call,actoragent):key(service_call.domain,service_call.service)ifkeyinHIGH_RISK_SERVICES:ifnotservice_call.human_approved:raisePermissionError(高危操作需人工确认)ifnotin_whitelist(service_call.entity_id):raisePermissionError(实体不在白名单内)validate_schema(service_call)# 类型、范围、枚举校验audit_log(service_call,actor)# 全量留痕returnservice_call6.2 白名单与 Schema 校验把幻觉挡在执行之前模型会幻觉出不存在的实体这是必然会发生的事不要指望提示词能根治。正确的做法是在执行层兜底实体白名单只允许操作预先审核过的实体。参数范围校验brightness_pct必须在 0–100temperature必须在设备允许区间。状态预检执行前查一次状态若目标已是目标状态则直接返回成功减少无效写入。失败要如实上报工具返回错误时必须把错误注入上下文让模型如实告知用户而不是编造已完成。6.3 故障降级Agent 挂了家还得能用设计目标是Agent 是增强层不是必需层。断网、模型宕机、MCP 崩溃时家庭的基本功能必须不受影响。保留物理开关与原生 App任何智能控制都不能取消物理入口。关键自动化由 HA 原生引擎承载不依赖模型。Agent 失效时进入只读模式能查状态、能解释不做写入操作。定期演练故意停掉推理服务确认家里还能正常生活。7. 冷静判断什么时候不该走这条路社区里已经出现对这类个人 Agent 的必要性质疑[10]。这类声音值得认真对待而不是当作泼冷水。判断自建是否值得看四个问题一、你的痛点是不会写规则还是规则太多如果只是几条固定场景HA 原生自动化的可靠性远高于任何 Agent成本也低得多。自然语言定义规则的增益在规则数量少、变更频率低的情况下非常有限。二、你有多少维护预算本地推理服务、MCP server、HA 插件、模型升级每一项都会持续消耗时间。这不是一次性项目而是一个长期运行的小系统。三、你的设备有多少是可控的设备不足十个、且都是同一品牌时厂商 App 加官方语音助手的体验通常更好。自建的价值在设备异构、跨品牌、需要跨域编排时才凸显。四、你的隐私要求有多强隐私是自建路线最硬的理由。如果这条不成立自建的性价比会大幅下降。维度开源自建路线厂商一体化路线可控性高可改可换低受厂商迭代节奏约束隐私可做到全本地通常依赖厂商云初始成本硬件 大量时间低稳定性取决于自身维护通常更高生态锁定低高能力上限受本地硬件限制由厂商能力决定厂商侧确实在集体押注这个方向小米公开了以摄像头为视觉源、连接全屋 IoT 的本地化探索方案 Miloco火山引擎推出嵌入式对话 AI 套件涂鸦开放 TuyaOpen七牛推出面向智能硬件的对话方案华为则在系统层做规则引擎与语言支持。这些方案的开放程度与实际能力差异很大选型时应以各自官方仓库与发布信息为准本文不做能力承诺。一个务实的自评清单可控智能设备数量 ≥ 15且跨 3 个以上品牌每周能投入 2–4 小时维护有闲置或专用的主机/NUC 可跑推理服务对家庭数据不出户有明确要求接受Agent 挂了不影响生活的设计而不是追求全自动若以上满足三条以上自建是值得的若只满足一两条先从 HA 原生自动化加一个轻量语音入口开始不要急着上 Agent。8. 落地路线图与清单8.1 三阶段演进阶段一MVP目标是一句话控制一盏灯。交付物一台跑 HA 的主机、一个本地推理服务、一个 MCP server、一个 OpenClaw 实例、一条可审计的完整日志。周期建议控制在两周内跑不通就回退不要硬扛。阶段二语音与多房间。交付物端侧 ASR/TTS、多房间实体规范化、Agent 与 HA 自动化的职责划分文档、失败降级演练记录。阶段三视觉、记忆与编排。交付物隐私方案评审结论哪些数据不出设备、长期偏好记忆、跨域编排任务、完整审计日志与回滚方案。8.2 硬件与软件清单项目作用选配建议HA 主机设备中枢树莓派级可起步设备多建议 NUC/小主机推理主机跑本地模型有独显优先纯 CPU 只适合小参数量模型麦克风 / 音箱语音入口阶段二再加优先支持本地 ASR 的方案ESP32 等节点传感器、语音采集、图像采集按需走 MQTT 接入摄像头视觉能力可选优先本地推理严格控制数据出口MQTT Broker端侧消息中转有 ESP32/多节点时再加反向代理 TLS远程访问安全必备禁止明文暴露 HA 到公网预算上不必追求一步到位。先用已有硬件把链路跑通确认自己真的需要更多算力再决定是否升级——这是这条路线里最省钱、也最容易被跳过的一步。结语家庭 AI 中枢的价值不在于能听懂话而在于把模糊的人类意图稳定地翻译成可校验、可回滚、可审计的设备操作。四层架构的意义是让每一层都能独立替换换模型不动设备换设备不动协议换 Agent 框架不动工具定义。OpenClaw 提供了编排与技能扩展的入口[1]Home Assistant 仍然是设备事实的权威来源MCP 把两者之间的契约显式化本地开源模型则在可控的硬件预算内承担意图理解与工具调用。这条路线需要时间与耐心也确实存在必要性的边界——但对那些设备异构、隐私敏感、愿意长期维护的用户来说它目前是把家庭自动化的控制权留在自己手里最现实的一条路径。参考资料[1] 一文读懂OpenClaw核心特性与原理解析附国产大模型聊天软件接入教程掘金https://juejin.cn/post/7602466689713078287[2] 再见手动开关用 Claude 驱动的 OpenClaw 让 Home Assistant 真正活过来保姆级教程CSDNhttps://blog.csdn.net/qq_38637122/article/details/157736536[3] 一人公司也能有家庭中控台OpenClaw 场景化自动化指南掘金https://juejin.cn/post/7607105207068311578[4] 智能家居中枢OpenClawQwen3.5-9B控制Home AssistantCSDNhttps://blog.csdn.net/weixin_42284380/article/details/159621094标题中的具体型号未获官方来源佐证本文仅作话题存在性证据[5] OpenClawGLM-4.7-Flash智能家居自然语言控制HomeAssistantCSDNhttps://blog.csdn.net/weixin_35414484/article/details/159296122标题中的具体型号未获官方来源佐证本文仅作话题存在性证据[6] 大模型Agent开发实战使用MCP协议构建智能家居控制系统CSDNhttps://blog.csdn.net/2301_80239908/article/details/155319899[7] ESP32 MCP over MQTT实现智能设备语音交互掘金https://juejin.cn/post/7550289374467702818[8] hello-claw 智能家居控制教程文档datawhalechina/hello-clawGitHubhttps://github.com/datawhalechina/hello-claw/blob/main/docs/en/university/smart-home-control/index.md[9] acon96/home-llmGitee 镜像仓库https://gitee.com/data_factory/home-llm[10] 你真的需要养一只龙虾openclaw吗掘金https://juejin.cn/post/7620364622602190898[11] jui-hung-yuan/smarthome-mcp-labGitHubhttps://github.com/jui-hung-yuan/smarthome-mcp-lab/blob/main/README.md[12] 活字格智能体集群 daedalus-agent-mqtt-channelOpenClaw MQTT 通道插件Giteehttps://gitee.com/low-code-dev-lab/daedalus-agent/blob/dev/extensions/openclaw-plugins/daedalus-agent-mqtt-channel/README.md[13] aradlein/hass-agent-llmOpenAI 兼容 LLM 集成 向量检索 记忆抽取GitHubhttps://github.com/aradlein/hass-agent-llm[14] goruck/home-generative-agent自然语言建自动化、人脸识别、异常预警GitHubhttps://github.com/goruck/home-generative-agent[15] DimaDoesCode/HA-Hybrid-Conversation本地意图执行 本地 LLM 响应GitHubhttps://github.com/DimaDoesCode/HA-Hybrid-Conversation[16] XiaoMi/xiaomi-milocoGitHubhttps://github.com/XiaoMi/xiaomi-miloco