把语音助手从Google Assistant换成Gemini，谷歌承诺的是对话式上下文和自然语言理解。但开关某一盏具体的灯、调恒温器的设定温度、触发自定义例程这类高频操作，要的是确定性精度，不是语言上的创造力。于是我把整套语音控制从Google Home这类云端平台搬到了本地自托管的自动化引擎Home Assistant上，图的是完整的数据隐私、不依赖互联网，以及更低的延迟。
Gemini成了压垮我的最后一根稻草。让它打开厨房的第二盏灯，结果是整个厨房的灯全亮了——它做的是一次笼统的高层级调用，最糟的是语音客户端还报告执行成功。这和旧版Google Assistant引擎形成了鲜明对比：后者通过Google智能家居API集成，能把结构化的语音模式可靠地映射到具体设备属性上。
迁移到Gemini之后，我那些绑定了明确短语触发词的自定义例程也经常失败或误触发。重新关联第三方设备账号、在Google Home应用里重建例程，都解决不了Gemini造成的核心实体映射退化。
Google Assistant本来就依赖云端，但瓶颈确实明显变严重了。每一次语音请求都要经过音频数字化、云端串流、Gemini模型推理、工具载荷格式化，再往返调用第三方云API。换成Gemini后，我遇到更多“抱歉，我无法连接X设备”的提示、虚假的成功确认，甚至站在一片漆黑里等灯亮、延迟超过8秒的情况。
从架构上看，本地方案的胜出几乎没有悬念。Google Home或Gemini依赖厂商专属的云对云OAuth账号关联来注册设备；它支持Matter和Thread设备，但很多集成仍走云端。Home Assistant则维护一个内部状态机，通过Zigbee、Z-Wave、Matter、Thread乃至ESPHome这类本地Wi-Fi API直接对接设备，完全绕开云服务器。
意图识别链路的差别同样关键。Google Home把音频流送到谷歌服务器，由Gemini处理文本、尝试把意图映射到暴露出来的智能家居API工具上，延迟就是这么来的。Home Assistant的语音架构是模块化流水线：本地唤醒词检测、语音转文字、意图解析、文字转语音，只要这样配置，全部在本地硬件上跑完。
可靠性也是重要因素。Google Home依赖网络，任何断网或上游厂商API故障都可能导致整体失灵。Home Assistant跑在你家四面墙内的硬件上，比如迷你主机或Home Assistant Green，响应更快，也不受网络接入影响。
迁移并不轻松，但收益远大于搭建过程的麻烦。先把硬件和操作系统装好：可以把Home Assistant OS直接部署在裸机上，比如Intel N100迷你主机或专用Home Assistant硬件，避免虚拟化开销，也为无线协调器留出直连USB口。接着接入专用的Zigbee/Thread USB适配器，搭一个离线的本地网状网络，然后解除设备与厂商云桥的绑定，按兼容性换成Zigbee、Z-Wave或Matter终端设备直连Home Assistant。这通常意味着要重新配网，有时还得换设备——部分Wi-Fi和私有协议设备并不支持本地架构。
设备都接入之后，就可以用细粒度自动化重建例程：把Google Home里简单的“如果这样，就那样”改写成带多条件触发、状态检查、数值阈值门限和模板化动作的自动化，并配置本地备份防止数据丢失。如果想替换掉Google Nest音箱，可以换成专用的本地语音硬件，比如运行ESPHome语音助手固件的ESP32-S3盒子；也可以走本地混合流水线，用Home Assistant Assist配合本地化意图模式，让语音触发确定性地映射到明确的实体ID。Assist内置的意图匹配是确定性的，只理解它有模板的句式，自然表达上不如Gemini灵活——这是我愿意接受的取舍。
我不需要一个大模型来掌管我的智能家居。大模型擅长开放式创作任务，而智能家居的核心基础设施要的是确定性精度、低延迟和严格的本地控制。自托管一套由Home Assistant驱动的本地语音处理栈，能摆脱云端依赖，让家在任何远程服务器出问题时都保持响应。
热门跟贴