“本地优先的反叛”：Home Assistant 如何成为你家中最重要的项目
Source: GitHub Blog
Franck Nijhof——更为人熟知的 Frenck——是那些因为帮助维系全球最活跃、文化意义最重大、技术要求最高的开源生态系统之一，而意外站在庞大开源项目中心的维护者之一。他并不是为了追逐聚光灯而成为焦点，而是因为他帮助把整个生态系统紧紧粘合在一起。作为 Home Assistant 的 负责人 以及 GitHub Star，Frenck 领航的项目不仅仅是增长——它是爆炸式增长。
今年的 Octoverse 报告证实了这一点：Home Assistant 是 按贡献者数量增长最快的开源项目 之一，排名与 vLLM、Ollama、Transformers 等 AI 基础设施巨头并列。它同样出现在 吸引首次贡献者的顶级项目 中，旁边是 VS Code 等大型开发者平台。在 AI 工具、代理工作流和强类型语言增长主导的一年里，Home Assistant 却以一种完全不同的姿态脱颖而出：它是一个面向物理世界的开源系统，增长速度堪比 AI 时代。
规模惊人。Home Assistant 现在已在 超过 200 万个家庭 中运行，协调从恒温器、门锁到运动传感器和灯光的所有设备——全部在用户自己的硬件上，而非云端。支撑这一路增长的贡献者群体同样非凡：单一年内有 21 000 名贡献者，在每秒都有新开发者加入 GitHub 的时代，形成了 GitHub 最活跃的生态系统之一。
“Home Assistant 是一个免费且开源的家庭自动化平台。它可以让你把所有设备连接在一起，无论它们来自哪个品牌……而且它在本地运行。”
—Franck Nijhof，Home Assistant 负责人
他说到它的易用性时会微笑：“把 Home Assistant 刷写到 SD 卡上，插进去，它就会开始扫描你的家。”
这种悖论——使用简单却技术庞大——让 Home Assistant 对开发者极具吸引力：一个本地优先、全球维护的家庭自动化引擎。
为数千种设备生态系统而构建的架构
从本质上讲，Home Assistant 面临的是组合爆炸问题。平台支持“数百、数千种设备… 超过 3000 个品牌”，正如 Frenck 所指出的。每一种设备的行为都不同，唯一的归一化方式是构建一个通用抽象层，以抵御供应商更迭、糟糕的 API 和不一致的固件。
与其把设备视为云账户背后的孤立对象，Home Assistant 将一切本地化为 实体（entities），拥有状态和事件。车库门不再是某个厂商的专有 API，而是一个结构化设备，向自动化引擎公开能力。恒温器不再是云端端点，而是一个带有元数据的传感器/执行器对，可以被推理。
正是这种一致性让人们能够构建极其高级的自动化。Frenck 讲了一个富有创意的例子：
“有些人会在沙发里装上重量传感器，这样他们就真的能知道你是坐下还是站起。你在看电影，站起来，系统会暂停影片并把灯光调亮一点，让你在去拿饮料时能看清。你回来坐下，灯光变暗，电影继续播放。”
能够编排这些交互的系统本质上是 面向物理空间的分布式、事件驱动运行时。Home Assistant 看起来像一个仪表盘，但其内部更像是家庭的实时操作系统。
本地运行不是一个特性，而是硬性约束
几乎所有主流设备制造商都已转向以云为中心的模型。Frenck 指出其中的荒谬：
“现在要调节恒温器居然需要互联网，真是疯狂。”
本地优先的架构意味着 Home Assistant 可以在像 Raspberry Pi 这样的小硬件上运行，却必须承担商业系统通常交给云端的工作负载：
- 设备发现
- 事件分发
- 状态持久化
- 自动化调度
- 语音管道推理（若本地）
- 实时传感器读取
- 集成更新
- 安全约束
如果这些工作被卸载到供应商的云端，系统的构建会更容易。但 Home Assistant 的理念恰恰相反：家庭即数据中心。
从 Pi 上的 SSD 磨损均衡到 MQTT 吞吐量再到 Zigbee 网络拓扑，一切都成为软件层面的挑战。因为系统必须在离线时仍能正常工作，根本没有回退方案——这是一种没有安全网的工程实践。
开放家庭基金会：治理也是技术需求
当你构建一个运行在数百万家庭中的系统时，最大的长期风险不是 bug，而是所有权。
“它永远不能被收购，永远不能被出售，” Frenck 在谈到 Home Assistant 加入 Open Home Foundation 时如此说。“我们想要在最终保护 Home Assistant 不被大公司收割。”
这种治理模型并非哲学层面的，而是架构层面的必然。商业收购会引入云锁定，破坏 API，废弃集成，导致多年构建的自动化全部崩溃。
基金会编码了三条工程约束，这些约束在每一次设计决策中都会产生涟漪：
- 隐私：“本地控制，隐私至上”。所有处理必须在设备上完成。
- 选择：“你应该能够自行选择设备”，并且期望它们能够互操作。
- 可持续性：如果某供应商关闭了云服务，设备仍必须能够工作。
Frenck 以 Nest 为例：“如果某厂商关闭了云服务… 那就会变成电子垃圾。”
这些约束决定了 API 的寿命、集成策略、逆向工程的优先级以及本地推理的选择，确保项目能够超越任何单一设备厂商的寿命。
“我们不可能为数百、数千种设备都写集成。我家里根本没有几万种设备，” Frenck 说。
开发者为自己拥有的设备编写集成。审阅者在自己家中的设备上测试贡献。弄坏了某个功能，就等于把自己的房子弄坏了。改进了某个功能，就提升了自己的日常生活。
“这就是质量的来源。人们在自己的家里运行它… 并且他们会确保它必须足够好。”
每位贡献者都能接触到真实的生产硬件；每位审阅者都有高风险的环境需要保护。没有任何预演环境能够复制数百万真实家庭的各种边缘情况。
Assist：在 AI 热潮之前就已诞生的本地语音助手
Assist 是 Home Assistant 内置的语音助手，一个模块化系统，让你可以通过语音控制家居，而无需将音频或文字稿发送到任何云提供商。
“我们在 AI 热潮之前就已经在打造语音助手… 我们想要构建一个注重隐私且本地化的方案。”
与直接复制 Alexa 或 Google Assistant 等商业助手不同，Assist 采用了两层结构，优先考虑确定性、速度和用户选择。