本地AI接入Home Assistant：隐私与风险并存的实践

把大模型接进智能家居中枢，听起来像是科幻片的开场。Smart Home Solver 的这期视频给出了一个相当务实的答案：技术上已经跑通，但离“省心”还有距离。作者用完全本地的 AI 连接 Home Assistant，在保护隐私的同时，也踩到了不少坑。

为什么是本地 AI，而不是云端？

视频里把接入方式归为三类：语音助手挂 AI（能力有限）、在 Home Assistant 内跑应用（目前只能走云端）、以及独立 AI 通过标准协议接入。作者选择第三条路，核心动机是隐私——家庭数据不出户。

但作者对云端的警惕不止于数据泄露。他更担心的是依赖：如果日常的仪表盘和自动化都靠云端 AI 生成，而用户并不理解其运作方式，那么一旦服务涨价或停摆，维护成本会迅速放大。据其表述，这种“被锁定”的风险比数据外流更隐蔽。

Home Assistant 是一个开源的家庭自动化平台，核心特点是本地优先：所有设备控制和自动化逻辑默认在本地服务器（如树莓派或迷你主机）上运行，不依赖厂商云。正因如此，把 AI 放在本地与它的设计哲学天然契合，用户对数据和规则有完全控制权。反过来，若把 AI 推理放到云端，虽然模型能力更强，但每次交互都要把家庭状态、日志甚至摄像头画面外传，且响应依赖网络稳定性。理解这一架构前提，才能明白作者为何把“独立 AI 通过标准协议接入”视为最平衡的第三条路。

MCP：让 AI 与 Home Assistant 对话的标准

连接的关键是 Model Context Protocol（MCP），一个让 AI 与外部应用通信的开放标准。Home Assistant 已内置支持，但实际使用中存在两个版本：官方集成提供约七个工具，能力克制；社区版本则提供超过七十个工具，接入也更简单——复制 URL 粘贴即可，而官方版需要手动配置长期访问令牌。

能力越大，风险越大。社区版 MCP 默认拥有删除权限，作者的原话是“敲几个键就能把整个 Home Assistant 实例炸掉”。他的建议很直接：初期设为只读，先备份再放开写权限。

云端与本地模型的体验落差

作者用 Claude 桌面版测试云端连接，工具列表随即出现，流程顺畅。切换到本地则要经 Ollama 下载模型。他选用 Gemma 4 的 26B 版本，在 36GB 内存的 MacBook Pro 上运行，并特别提到 MLX 版本在 Apple Silicon 上更快。

实际任务中，差距明显：修复损坏的自动化、生成仪表盘这类工作，云端模型表现更稳；本地模型则“像家养小精灵多比”——有善意但需要引导。作者的办法是把云端模型完成的任务拆解成指令教给本地模型，并用一个 Markdown 文件记录 Home Assistant 的相关知识，让模型逐步积累上下文。

MCP（Model Context Protocol）由 Anthropic 于 2024 年底提出，本质是一套基于 JSON-RPC 的客户端-服务器协议：AI 应用作为客户端，外部工具或数据源作为服务器，双方通过标准化的“工具列表”和“调用”消息交换能力。它解决的是此前每个 AI 集成都要单独写适配器的碎片化问题——只要工具侧实现 MCP 服务器，任何支持该协议的模型都能即插即用。在 Home Assistant 场景中，MCP 服务器把实体查询、服务调用、自动化读写等能力包装成“工具”，模型根据任务自行选择调用，这也是文中“工具数量”直接对应“AI 能做什么”的原因。

文中提到的 Ollama 是一个开源的本地大模型运行框架，负责模型的下载、加载与推理调度，并通过兼容 OpenAI 的 API 对外提供服务。MLX 则是苹果为 Apple Silicon 芯片推出的机器学习数组框架，能充分利用统一内存架构，让模型权重直接驻留内存、由 GPU 高效计算，因此在 Mac 上通常比通用后端更快。Gemma 是 Google 发布的开源模型系列，26B 指约 260 亿参数，量化后仍需十几到二十几 GB 内存，这也解释了作者为何强调 36GB 内存的 MacBook Pro——本地推理的第一道门槛往往不是算力而是内存容量。

本地 AI 在智能家居里能做什么

作者演示了几类实用场景。一是排查与修复：AI 能识别出失效的自动化并直接改写，其中一条坏掉的自动化恰恰是另一个 AI 生成的。二是生成仪表盘，效果“不错但不算出色”，他提醒要用 YAML 而非 HTML/CSS，以便后续拖拽调整。

最让他兴奋的是习惯分析：AI 读取日志，发现灯和风扇总在电脑开机前后被手动打开，进而提出自动化建议。这正是他理想中“智能家居自己进化”的形态，但目前仍是进行中的工作。

在复杂自动化编写上，本地模型的表现超出预期。他使用一款包含多个实体的毫米波传感器，AI 第一次就选对了目标实体。

被低估的成本：时间与注意力

作者坦言，本地 AI 的“危险”不在安全层面，而在时间。调试和训练模型极其消耗精力，他形容这是“没有底的兔子洞”，甚至为此挤占了陪伴家人的时间。硬件层面，本地推理会让电脑风扇满载，他索性用 iPad 通过 SSH 远程操作，避免在机器旁工作。

视频由 Ugreen 赞助，其 home agent 定位为开箱即用的本地 AI 盒子，集成了家庭照片检索、第三方摄像头的人脸与包裹识别、Matter 设备控制与语音交互。这类产品说明本地 AI 的门槛正在被硬件厂商拉低，但对愿意动手的用户，自建方案仍然更灵活。

结论：值得尝试，但别急着全自动

作者的判断很清醒：AI 接入 Home Assistant 的可能性几乎是无限的，有人甚至让 AI 现写自定义集成来补足缺失功能。但现阶段，它更适合作为辅助工具，而非放手不管的自动驾驶。隐私、成本、可维护性三者之间需要用户自己权衡。

对想要尝试的人，路径已经清晰：启用 MCP、先只读、做好备份、从云端模型学思路、再用本地模型落地。剩下的，就是控制住自己别掉进兔子洞。