Home Assistant 被移出核心：你的智能家居配置会怎样

早上你让 Hermes 把客厅的灯调暗，它回你一句 unknown platform: homeassistant。你没有改过任何配置，也没删过任何东西，只是昨晚跑了一次 hermes update。

这就是“核心瘦身”落到用户身上的样子：一个以前内置在 Hermes 里的平台适配器，被搬进了插件目录。好消息是官方给这次搬家配了自动迁移，绝大多数人的配置一个字都不用改。这篇文章说清楚它搬了什么、迁移是怎么跑的、以及万一没搬成功你该做什么。

搬走了什么

Home Assistant 过去是内核的一部分：plugins/platforms/homeassistant/（gateway 平台适配器）加上 tools/homeassistant_tool.py（agent 工具），还有对应的 homeassistant / hermes-homeassistant toolset、Platform.HOMEASSISTANT 枚举、HASS_TOKEN 的环境变量自动启用行、pip 的 homeassistant extra，以及散落在 dump、setup 摘要、dashboard 平台卡片、ACP 工具清单等处的一堆硬编码条目。

这些在 #132469 里全部移除，功能整体搬到官方插件目录里的 homeassistant 插件（仓库 NousResearch/hermes-homeassistant，评审时锁定在 2.0.1）。在你升级后的 plugins/platforms/ 里，已经看不到 homeassistant 这个目录了。

你的配置不用改

这是这次迁移最省心的地方：插件的目标是同名、同配置键、同环境变量。

  • HASS_TOKEN、HASS_URL 不变；
  • gateway 配置里的 platforms.homeassistant 不变；
  • 工具名 ha_* 不变。

换句话说，你不需要去翻文档找新的键名。你唯一需要确认的是那个插件确实装上了。

迁移是怎么自动跑的

官方新加了一个通用的“离开核心”迁移机制，文件是 hermes_cli/left_core_migration.py。它的设计很值得一看，因为它解决了插件化最难的一步：老用户怎么无感过渡。

迁移表叫 LEFT_CORE，每一行描述“哪个插件 + 怎么判断这个 home 用过它”。目前只有一行：

LEFT_CORE: tuple[LeftCoreFeature, ...] = (
    LeftCoreFeature(
        plugin="homeassistant", label="Home Assistant", in_use=homeassistant_in_use,
        unchanged="HASS_TOKEN/HASS_URL, platforms.homeassistant and the ha_* tool names are unchanged",
        secret_env=("HASS_TOKEN",), private_env=("HASS_URL",),
        toolsets=("homeassistant",), off_platforms=("acp", "webhook"), platform="homeassistant",
        enable_env=("HASS_TOKEN",), channel_env_prefixes=("HASS_",),
    ),
)

判断“这个 home 用过 Home Assistant”的依据是只读的：它的 .env 里有 HASS_TOKEN（这一个变量同时启用了适配器和工具）、gateway 配置里打开了这个平台（兼容旧的 gateway.json、gateway.platforms / platforms / gateway.homeassistant 几种写法，最后一个显式的 enabled 说了算）、或者 toolset 里选了 homeassistant。进程环境里来自 systemd / Docker 的 HASS_TOKEN 也算。

安装时机有三个：

  1. hermes update —— 为共享同一个 venv、且用过该功能的每个 profile home 安装；
  2. agent 启动时 —— 对当前 home 每个进程重试一次（桌面端用户从 app 更新、不会跑 hermes update，靠这条路补上），并遵守 security.allow_lazy_installs；
  3. gateway 启动时 —— 同样重试一次，结果排队等这个 home 的第一次 agent 会话投递。

安装走的是正常的目录安装通道，锁在评审过的 pin 上，会过一遍 kill list、依赖约束和启用步骤。有一个细节很体贴：依赖确认对这批行免交互——这些依赖在核心时代用户早就接受了。

另外两个防打扰设计：

  • 安装失败（目录里没有、网络不通、装不上）之后，启动时的重试会跳过 STARTUP_RETRY_SECONDS 的冷却期，这样离线机器只付一次网络往返，而不是每次 hermes chat 都等；hermes update 则永远重试。
  • 每个 home 只会被自动安装一次，记录在它 config.yaml 的 _left_core_installed 键里。之后再想卸载，是你自己的选择，不会被“修复性重装”。

升级后该怎么确认

hermes update
hermes plugins list | grep homeassistant

看到插件在列表里（启用状态）就结束了。如果因为 security.allow_lazy_installs: false、或者机器一直离线导致没装上，手动装一次同样有效：

hermes plugins install homeassistant
hermes plugins enable homeassistant

注意 plugins install 走的是插件目录（catalog）里的评审 pin，不是任意仓库，所以不会引入来路不明的代码。想看插件能力的隔离设计，可以读插件宿主隔离模式和插件目录指南。

这个表以后会长

LEFT_CORE 是一个通用表，Home Assistant 只是第一行。结合插件目录现在的评审与供应链检查流程（见插件目录的 CI 与供应链），可以预期以后还会有更多内置能力走同样的路径：先从内核移除，再由迁移机制自动给老用户装上。

对用户来说，这是一个更健康的形态：内核更小、更新更快，单个平台适配器可以独立发版，而不是等下一次 Hermes 主版本。代价是“内置”不再等于“一定存在”——升级后顺手确认一下你在用的平台插件，是个值得养成的习惯。

小结

  • Home Assistant 的 gateway 平台与 homeassistant 工具已从内核移除，改由官方目录插件提供；
  • hermes update 会为用过它的 profile 自动安装，agent / gateway 启动时会补一次，遵守 security.allow_lazy_installs；
  • 配置键、环境变量、工具名全部不变，hermes plugins list 能看到就说明迁移成功；
  • 装不上时 hermes plugins install homeassistant 手动补即可；LEFT_CORE 表后续还会接纳更多条目。