从 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 阶段可用，但很快会遇到四个问题：工具不可发现、参数无约束、提示词随接口膨胀、权限完全依赖模型自觉。
MCP（Model Context Protocol）把"能力"变成声明式的工具清单：server 声明tools/list，client 通过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\-H"Authorization: Bearer$HA_TOKEN"# 调用服务（写入）curl-s-XPOST http://homeassistant.local:8123/api/services/light/turn_on\-H"Authorization: Bearer$HA_TOKEN"\-H"Content-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\-H"Content-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_calls，arguments可被 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_main=on, bedroom_main=on, entry_door=locked [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 preset=sleep [10:41:08] result: ok [10:41:08] state re-read: entry_door=locked [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,actor="agent"):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–100，temperature必须在设备允许区间。 - 状态预检：执行前查一次状态，若目标已是目标状态则直接返回成功，减少无效写入。
- 失败要如实上报：工具返回错误时，必须把错误注入上下文，让模型如实告知用户，而不是编造"已完成"。
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 真正"活"过来（保姆级教程）｜CSDN｜https://blog.csdn.net/qq_38637122/article/details/157736536
[3] 一人公司也能有"家庭中控台"：OpenClaw 场景化自动化指南｜掘金｜https://juejin.cn/post/7607105207068311578
[4] 智能家居中枢：OpenClaw+Qwen3.5-9B控制Home Assistant｜CSDN｜https://blog.csdn.net/weixin_42284380/article/details/159621094（标题中的具体型号未获官方来源佐证，本文仅作话题存在性证据）
[5] OpenClaw+GLM-4.7-Flash智能家居：自然语言控制HomeAssistant｜CSDN｜https://blog.csdn.net/weixin_35414484/article/details/159296122（标题中的具体型号未获官方来源佐证，本文仅作话题存在性证据）
[6] 大模型Agent开发实战：使用MCP协议构建智能家居控制系统｜CSDN｜https://blog.csdn.net/2301_80239908/article/details/155319899
[7] ESP32 + MCP over MQTT：实现智能设备语音交互｜掘金｜https://juejin.cn/post/7550289374467702818
[8] hello-claw 智能家居控制教程文档｜datawhalechina/hello-claw｜GitHub｜https://github.com/datawhalechina/hello-claw/blob/main/docs/en/university/smart-home-control/index.md
[9] acon96/home-llm｜Gitee 镜像仓库｜https://gitee.com/data_factory/home-llm
[10] 你真的需要养一只龙虾（openclaw）吗｜掘金｜https://juejin.cn/post/7620364622602190898
[11] jui-hung-yuan/smarthome-mcp-lab｜GitHub｜https://github.com/jui-hung-yuan/smarthome-mcp-lab/blob/main/README.md
[12] 活字格智能体集群 daedalus-agent-mqtt-channel（OpenClaw MQTT 通道插件）｜Gitee｜https://gitee.com/low-code-dev-lab/daedalus-agent/blob/dev/extensions/openclaw-plugins/daedalus-agent-mqtt-channel/README.md
[13] aradlein/hass-agent-llm（OpenAI 兼容 LLM 集成 + 向量检索 + 记忆抽取）｜GitHub｜https://github.com/aradlein/hass-agent-llm
[14] goruck/home-generative-agent（自然语言建自动化、人脸识别、异常预警）｜GitHub｜https://github.com/goruck/home-generative-agent
[15] DimaDoesCode/HA-Hybrid-Conversation（本地意图执行 + 本地 LLM 响应）｜GitHub｜https://github.com/DimaDoesCode/HA-Hybrid-Conversation
[16] XiaoMi/xiaomi-miloco｜GitHub｜https://github.com/XiaoMi/xiaomi-miloco
