夜雨聆风hab——AI操控Home Assistant的瑞士军刀
如果你玩 Home Assistant 有一阵子了，应该对 Paulus Schoutsen（圈内常叫他 balloob）不陌生。这位 HA 的创始人兼项目领航员，最近搞了个有意思的新玩意儿——一个叫 hab 的命令行工具。
全称是 Home Assistant Builder，缩写 hab。
初看名字我还以为是 Home Assistant 的构建工具，仔细一看 README 才发现，这玩意儿定位非常特别：它不是给人用的传统 CLI，而是专门给 AI Agent（大语言模型/LLM）用的。
该项目在 README 中标注为"凭感觉写的，风险自负"，实际已提交超过 100 次 commits，从 2026 年 1 月起持续活跃更新。
hab 是什么？
hab 是一个用 Go 语言写的命令行工具，通过 Home Assistant 的 REST API 和 WebSocket API 跟你的 HA 实例通信。它的设计初衷很明确：让 AI 能像人操作界面一样，去管理和配置 Home Assistant。
输出上，默认返回人类可读的文本，也支持 --json 输出机器能解析的标准格式。
独立安装也很简单，Go 环境装好，一行命令搞定：
go install github.com/balloob/home-assistant-build-cli@latest也可以直接在release里找到适配你平台的二进制文件
装好之后连上 HA 实例就能开始玩了。认证方式支持 OAuth 登录、长期令牌，如果用 Supervisor 插件跑的话还能自动获取凭证，挺省事的。
能做什么？功能一览
我仔细翻了项目的功能列表，发现 hab 覆盖的面非常广，几乎你能想到的 HA 管理操作它都涉及了。我按照功能类别大致梳理一下：
1. 资产概览和实体管理
最基础也最实用的功能：hab overview 一眼扫清你家 HA 实例的全貌——几个楼层、多少区域、挂了哪些设备、注册了多少实体、配了多少自动化等等。
实体方面从 list、get、search、history 到 logbook 一应俱全。比如你想查传感器最近一段时间的状态变化：
hab entity history sensor.temperature --start "2025-01-01T00:00:00Z"还能直接重命名、启用、禁用实体，改区域划分什么的也不在话下。
此外，hab 的所有 --json 输出都使用统一的 success/error 信封格式，对 LLM 解析极其友好。
2. 自动化、脚本、场景全套 CRUD
这是我觉得最有价值的一块。hab automation 子命令极其完整，不仅支持创建、查看、更新、删除自动化，还能对每个自动化的 trigger、condition、action 进行细粒度的增删改查。
啥概念呢？AI 可以通过 hab 一条命令一条命令地：新建一个自动化 → 加个状态触发器 → 加个条件判断 → 加个执行动作 → 保存 → 运行测试。整个过程不需要打开 HA 的 Web 界面。
脚本（script）和场景（scene）也是一样的操作模式。模板渲染（template render）也支持，甚至可以从标准输入读取模板内容。
3. 仪表盘（Lovelace）编辑
这是另一个让人眼前一亮的功能。hab dashboard 子命令可以完成对仪表盘的完整 CRUD，包括视图（view）、分区（section）、徽章（badge）、卡片（card）的创建和修改。
特别巧妙的设计是：如果你想在最后一个视图的最后一个分区里加一张卡片，hab 能自动推断出位置。如果需要的视图或分区还不存在，它会自动帮你创建缺失的那一层。配合 --plan 参数还能先预览修改效果，确认没问题再执行。
4. 辅助工具（Helpers）
Input Boolean、Input Number、Input Text、Counter、Timer、Schedule…… 这些 HA 里的辅助实体，hab 全包了。而且分类很清晰，用 hab helper types 能列出所有支持的类型和对应的创建参数。
举个例子，想创建一个叫"亮度"的数值输入，设置范围 0-100、步长 5：
hab helper input-number create "Brightness" --min 0 --max 100 --step 5 --unit "%"5. ESPHome 深度集成
这一块是真下了功夫的。hab esphome 子命令涵盖的东西非常全：设备创建、导入、配置、验证、编译、上传、迁移、串口恢复，甚至支持 Tasmota 设备的转换。
还有个很实用的功能：hab esphome catalog search 可以搜索社区 1000 多种已知 ESPHome 设备的配置模板。创建新设备时也能用预制模板，比如 hab esphome create --preset relay 快速生成继电器固件骨架。
编译和上传支持流式输出 NDJSON 事件，对 CI/CD 场景非常友好。
6. 运维和其他
通知管理、系统管理、备份管理、事件管理、修复项查询……做了个集成管理工具 hab integration，HA 里装了哪些集成、什么状态一目了然。还有日历和待办事项的 CRUD。
最特别的设计：LLM 合约（LLM Contracts）
这里我想重点聊聊 hab 最核心的设计亮点。
普通的 CLI 工具输出五花八门，AI 解析起来很头疼。hab 引入了 LLM 合约 的概念，通过 hab schema <命令> --json 输出命令的调用元数据和返回契约。也就是说，AI 在执行一个命令前，可以先查一下这个命令接受什么参数、返回什么格式的数据。
更牛的是 hab guide <主题> --json，它返回的是 可执行的工作流配方。这个配方里包含了所需能力、输入、步骤、分支条件、验证步骤、恢复步骤——AI 照着这个配方一步步走，不需要去理解自然语言文档。
从 hab 的项目文件可以看出，balloob 很早就关注 AI 与 HA 的交互可靠性——项目中包含了专门的 AI 合约机制和验证闭环，确保 AI 的操作是可控和可验证的。
所有 JSON 响应都用一个统一信封封装，包含 success、operation、resource_type、data、error 等字段。格式化的好处是机器解析起来毫无歧义。
安全设计：先预览，再执行
我自己最欣赏的设计是 hab 对安全的重视。修改操作几乎都支持 --plan 或 --dry-run 参数，先预览会改什么，不会实际执行。破坏性操作需要确认，非交互模式下直接返回结构化的"需要确认"错误。如果确信没问题，--force 跳过确认。
这套机制让 AI 可以在"预览模式"下操作，人类确认后再真正执行，容错率大大提升。
hab 跟 MCP 是什么关系？
可能会有人问：HA 已经有 MCP（Model Context Protocol）工具了，为什么还需要 hab？
可以这么理解：MCP 是"对话式"的，hab 是"工具式"的。 MCP 适合 AI 在对话中执行单个操作，但如果你要做一系列有状态的操作，比如创建仪表盘然后加视图再加卡片，或者编译上传 ESPHome 固件，MCP 那套交互就有点使不上劲了。
hab 的输出是结构化的 JSON 信封，支持 --plan 预览、--dry-run 安全模式、内置验证闭环，这些设计让它在自动化工作流和复杂操作场景下比 MCP 更顺手。两者不是替代关系，而是互补。
总结
它的核心理念很清晰：打造一个 AI 能理解、能操作、能信任的 HA 管理工具。 无论是 LLM 合约、--plan 安全预览、还是那套统一的 JSON 信封，都在解决同一个问题——让 AI 跟 HA 的交互变得可靠和可预测。
如果你也在探索 AI 如何跟智能家居结合，我建议去 GitHub 上翻翻这个项目。说不定你用的 AI 助手下次操作 HA 的时候，背后跑的就是 hab。
项目地址：github.com/balloob/home-assistant-build-cli
想让你的AI操作你的HA的可以去试试。更多好工具，记得关注我哟。
