Hermes Agent 内置四个 Home Assistant 工具——设置一个 Token,就能用自然语言控制全屋智能设备、实时监听传感器事件、通过语音下达指令、用定时任务执行早晚例程。这篇文章从接入配置讲到生产级部署,覆盖你需要知道的一切。
如果你还不了解 Hermes Agent 的整体架构和核心能力,建议先读 Hermes Agent 完全指南。
一句话理解 Hermes + Home Assistant 能做什么
传统智能家居助手(Alexa、Google Home、Siri)本质上是语音命令中继器——你说一条指令,它翻译成设备操作。Hermes Agent 不一样,它是一个拥有记忆、能学习、会推理的 AI 管家。
💡 通俗讲:Alexa 只能执行"开灯",Hermes 能理解"我要睡了"——它记得你的习惯是关客厅灯、调卧室灯到 20%、把恒温器降到 20 度、检查前门是否锁好,然后一次全做完。下次你再说同样的话,它会把这套操作自动保存为"睡前例程"技能,执行更快。
Reddit 的 r/homeassistant 社区有一篇标题为 "Hermes and HomeAssistant: killer move" 的帖子,发帖者从其他 AI 方案切换到 Hermes 后用 "killer move" 来形容体验差距。差距的根源不是模型更聪明,而是 Hermes 的 Agent 架构——工具调用、持久记忆、技能学习、跨平台 Gateway 四个能力同时作用于智能家居场景。
两种接入模式:REST 主动控制 + WebSocket 被动响应

Hermes 通过两种互补的通道与 Home Assistant 交互:
| 通道 | 协议 | 方向 | 用途 |
|---|---|---|---|
| Smart Home Tools(智能家居工具) | REST API | Hermes → HA | 主动查询和控制设备:开灯、调温、查状态 |
| Gateway Platform(网关平台) | WebSocket | HA → Hermes | 被动接收实时事件:门窗触发、温度变化、报警触发 |
两者从同一个 Token 激活——在 ~/.hermes/.env 中设置 HASS_TOKEN 后,四个工具和 Gateway 平台同时可用。
💡 通俗讲:REST 工具是你对管家说"帮我开灯",管家去执行。WebSocket Gateway 是管家自己盯着门窗传感器,发现异常主动告诉你"前门打开了,我已经开了走廊灯"。两种模式结合才是完整的智能家居 AI。
三步完成接入

第一步:创建 Home Assistant 长期访问令牌
打开 Home Assistant → 点击左下角用户名 → Profile → 滚动到 Long-Lived Access Tokens → Create Token → 命名为 "Hermes Agent" → 复制 Token。
第二步:配置 Hermes 环境变量
# ~/.hermes/.env
# 必需:长期访问令牌
HASS_TOKEN=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
# 可选:HA 地址(默认 http://homeassistant.local:8123)
HASS_URL=http://192.168.1.100:8123
第三步:配置 Gateway 事件监听并启动
在 ~/.hermes/config.yaml 中配置 Home Assistant 平台的事件过滤规则。这段配置决定 Gateway 监听哪些设备域、关注哪些特定实体、屏蔽哪些噪音源:
提示词:生成 Hermes Gateway 的 Home Assistant 事件监听配置
请帮我生成 ~/.hermes/config.yaml 中 platforms.homeassistant 段的配置。要求:
enabled:设为trueextra.watch_domains:监听的实体域列表,建议从以下 6 个开始——climate(温控)、binary_sensor(门窗传感器)、alarm_control_panel(报警面板)、light(灯光)、lock(锁具)、cover(窗帘/卷帘)extra.watch_entities:额外监听的特定实体 ID,如sensor.front_door_battery(前门电池)、sensor.living_room_temperature(客厅温度)extra.ignore_entities:屏蔽高频但无用的实体,如sensor.uptime、sensor.cpu_usage、sensor.memory_usage、sensor.cpu_temperature(优先级最高,会覆盖 watch 规则)extra.cooldown_seconds:同一实体两次事件的最短间隔,建议 30 秒
# 验证连接
curl -sH "Authorization: Bearer $HASS_TOKEN" "$HASS_URL/api/" | jq
# 启动 Gateway
hermes gateway
Home Assistant 会作为已连接平台出现,与 Telegram、Discord 等消息平台并列。
Gateway 事件过滤机制
Gateway 默认不转发任何事件。必须至少配置一个 watch_domains、watch_entities 或 watch_all 才能接收事件。未配置时启动会记录警告,所有状态变化被静默丢弃。
| 设置 | 默认值 | 作用 |
|---|---|---|
watch_domains |
无 | 只监控这些实体域 |
watch_entities |
无 | 只监控特定实体 ID |
watch_all |
false |
接收所有状态变化(不推荐,噪音太大) |
ignore_entities |
无 | 始终忽略这些实体(优先级最高) |
cooldown_seconds |
30 |
同一实体两次事件之间的最短间隔 |
建议从 climate、binary_sensor 和 alarm_control_panel 三个域开始。这三个域覆盖最有实用价值的自动化场景——温度异常、门窗开关、报警触发。用 ignore_entities 屏蔽 CPU 温度、系统运行时间等高频但无用的传感器更新。
事件格式化:状态变化按域格式化为人类可读消息,Agent 直接理解语义而非原始数据:
| 域 | 格式示例 |
|---|---|
climate |
"HVAC mode changed from 'off' to 'heat' (current: 21, target: 23)" |
binary_sensor |
"triggered" / "cleared" |
light / switch |
"turned on" / "turned off" |
alarm_control_panel |
"alarm state changed from 'armed_away' to 'triggered'" |
连接稳定性:WebSocket 带 30 秒心跳保活,断线后自动重连,退避序列为 5 秒 → 10 秒 → 30 秒 → 60 秒。出站通知走独立的 REST 会话(persistent_notification.create),避免 WebSocket 读写竞争条件。
WolframRavenwolf 的 HA Add-on:另一种部署方式

社区开发者 WolframRavenwolf 将整个 Hermes Agent 打包为 Home Assistant Add-on,目前已更新到 v1.1.0。这种方式把 Hermes 运行在 HA 内部而非外部独立进程。
Add-on 包含四个组件:
- Hermes Gateway——持久 AI Agent 守护进程,每个 Profile 独立运行
- Hermes Dashboard——浏览器管理界面(FastAPI + React),支持多 Profile 切换
- ttyd——每个 Profile 两个 Web 终端(tmux 持久会话)
- nginx——HTTP、HTTPS 和 HA Ingress 代理
通过 HA 侧边栏直接访问,支持嵌入式终端和状态显示。v1.1.0 新增多 Profile 支持——可在同一 Add-on 中并行运行多个 Hermes Agent 实例。
WolframRavenwolf 还发布了一个独立的 HACS 自定义集成(Custom Integration),让 HA 的 Assist 语音管线直接调用 Hermes Agent 作为 Conversation Agent。两种集成方式的定位不同:
| 维度 | 官方内置集成(ha_* 工具) | HACS 自定义集成(Conversation Agent) |
|---|---|---|
| 方向 | Hermes 主动控制 HA | HA 主动请求 Hermes |
| 触发方式 | 用户通过消息平台发指令 | 用户通过 HA Assist 语音/文字发指令 |
| 适合场景 | 远程控制、跨平台统一入口 | 本地语音卫星设备、HA Dashboard 交互 |
| 安装方式 | 内置(设置 HASS_TOKEN 即激活) |
HACS 安装或手动安装 |
两者可以同时使用,互不冲突。
ha_* 工具集详解:四个工具掌控全屋


Hermes Agent 注册了四个智能家居控制工具,每个工具映射到 Home Assistant REST API 的一个端点。Agent 用 LLM 原生的工具调用(Function Calling)机制触发它们——你用自然语言说需求,Agent 自己推理该调哪个工具、传什么参数。
ha_list_entities:列出实体
列出 Home Assistant 中的实体,支持按域或区域过滤。
| 参数 | 必选 | 说明 |
|---|---|---|
domain |
否 | 按实体域过滤:light、switch、climate、sensor、binary_sensor、cover、fan、media_player 等 |
area |
否 | 按区域/房间名过滤(匹配友好名称):living room、kitchen、bedroom 等 |
典型用法:"列出客厅所有的灯"——Agent 调用 ha_list_entities(domain="light", area="living room"),返回实体 ID、当前状态和友好名称。
ha_get_state:查询状态
获取单个实体的详细状态,包括所有属性——亮度、颜色、温度设定点、传感器读数、最后变更时间等。
| 参数 | 必选 | 说明 |
|---|---|---|
entity_id |
是 | 要查询的实体,如 light.living_room、climate.thermostat、sensor.temperature |
典型用法:"恒温器现在什么状态?"——Agent 调用 ha_get_state(entity_id="climate.thermostat"),返回当前温度、目标温度、HVAC 模式、所有属性和时间戳。
ha_list_services:列出可用服务
列出 Home Assistant 支持的所有服务操作,展示每种设备类型能做什么以及接受哪些参数。
| 参数 | 必选 | 说明 |
|---|---|---|
domain |
否 | 按域过滤,如 light、climate、switch |
典型用法:"空调设备支持哪些操作?"——Agent 调用 ha_list_services(domain="climate"),返回 set_temperature、set_hvac_mode、turn_on、turn_off 等服务清单及每个服务接受的参数。
ha_call_service:执行操作
调用 Home Assistant 服务来控制设备。这是最核心的工具——所有实际的设备控制都通过它完成。
| 参数 | 必选 | 说明 |
|---|---|---|
domain |
是 | 服务域:light、switch、climate、cover、media_player、fan、scene、script |
service |
是 | 服务名:turn_on、turn_off、toggle、set_temperature、set_hvac_mode、open_cover、close_cover |
entity_id |
否 | 目标实体,如 light.living_room |
data |
否 | 附加参数的 JSON 对象 |
实际交互示例:
用户:把客厅灯调成蓝色,亮度 50%
Agent 自动推理并调用:
ha_call_service(
domain="light",
service="turn_on",
entity_id="light.living_room",
data={"brightness": 128, "color_name": "blue"}
)
用户:家里安全吗?
Agent 自动执行多步推理:
1. ha_list_entities(domain="binary_sensor")
→ 检查所有门窗传感器状态
2. ha_get_state(entity_id="alarm_control_panel.home")
→ 检查报警面板状态
3. ha_list_entities(domain="lock")
→ 检查所有锁具状态
4. 汇总报告:"所有门窗已关闭,报警系统已布防,全部锁具已锁定。"
注意第二个例子——这不是简单的命令中继。Agent 自主决定需要查询哪些设备、按什么顺序执行、最后生成一份人类可读的安全报告。这种多步编排能力是 Hermes 和传统语音助手的本质差异。
安全机制
Hermes 对 HA 工具的安全设计值得单独说明。六个危险的服务域被硬编码封锁:
| 被封锁的域 | 封锁原因 |
|---|---|
shell_command |
可执行任意 Shell 命令 |
command_line |
传感器/开关中嵌入的命令执行 |
python_script |
Python 脚本执行 |
pyscript |
更广泛的 Python 脚本集成 |
hassio |
插件控制、主机关机/重启 |
rest_command |
HA 服务器发起的 HTTP 请求(SSRF 攻击向量) |
实体 ID 通过正则表达式 ^[a-z_][a-z0-9_]*\.[a-z0-9_]+$ 验证,防止注入攻击。
根据 GitHub Issue #25913 的路线图,后续还会加入审批闸门(approval gate)和服务白名单机制——显式域/服务白名单加上默认拒绝姿态,不因为 Token 存在就允许写操作。
🔥 翔宇判断:这个安全设计比 Alexa 和 Google Home 的黑盒模型透明得多。你能明确看到哪些操作被允许、哪些被封锁、封锁原因是什么。对于在生产环境中使用 AI 控制物理设备,这种可审计的安全模型是必要条件。
语音控制完整流程:从说话到设备响应

Hermes 的语音模式和 HA 工具结合,构成完整的 AI 语音管家循环。完整流程如下:
用户语音 → CLI / Telegram / Discord 语音输入
→ faster-whisper 本地转写(STT)
→ Hermes Agent 推理 + 工具调用管线
→ ha_call_service / ha_get_state(控制/查询设备)
→ LLM 生成自然语言回复
→ Edge TTS / ElevenLabs / OpenAI TTS(TTS)
→ 语音回复到用户
语音提供商矩阵
Hermes 支持 6 种语音转文字和 6 种文字转语音提供商,可以任意组合。
语音转文字(STT):
| 提供商 | 运行位置 | 成本 | 中文支持 |
|---|---|---|---|
| faster-whisper(推荐) | 本地 | 免费 | 支持 |
| OpenAI Whisper API | 云端 | 付费 | 支持 |
| Groq | 云端 | 付费 | 支持 |
| Mistral | 云端 | 付费 | 支持 |
| xAI | 云端 | 付费 | 有限 |
| 本地命令包装器 | 本地 | 免费 | 取决于模型 |
文字转语音(TTS):
| 提供商 | 质量 | 成本 | 需要 API Key |
|---|---|---|---|
| Edge TTS(默认) | 良好 | 免费 | 不需要 |
| NeuTTS | 良好 | 免费 | 不需要 |
| ElevenLabs | 优秀 | 付费 | ELEVENLABS_API_KEY |
| OpenAI TTS | 良好 | 付费 | VOICE_TOOLS_OPENAI_KEY |
| MiniMax | 良好 | 付费 | MINIMAX_API_KEY |
| xAI TTS | 良好 | 付费 | XAI_API_KEY |
零成本方案:faster-whisper(本地 STT) + Edge TTS(免费 TTS)。中文场景选 zh-CN-XiaoxiaoNeural(Edge TTS)效果已经相当自然。
Discord 语音频道实时对话
Hermes 支持加入 Discord 语音频道进行实时语音交互——这是最接近"智能音箱"的体验,但能力远超音箱。
macOS 系统依赖安装:
brew install portaudio espeak-ng opus ffmpeg
pipx inject hermes-agent pyaudio PyNaCl
在 Discord 文字频道中发送命令:
/voice join # 加入你所在的语音频道
/voice tts # 开启文字转语音回复
/voice status # 查看状态
/voice leave # 退出
加入语音频道后,你可以直接用中文说"打开客厅的灯",Hermes 会通过 faster-whisper 转写 → Agent 推理 → ha_call_service 执行 → 语音回复"客厅灯已打开"。
关于语音模式的完整配置和进阶用法,请参考 Hermes 语音模式完全攻略。
被动响应:Gateway 事件触发自动操作
语音控制是主动模式。Gateway WebSocket 提供的被动模式同样重要——Agent 监听 HA 事件并自主决定如何响应。
[Home Assistant] 前门传感器:triggered(之前是 cleared)
Agent 自动执行:
1. ha_get_state(entity_id="binary_sensor.front_door")
→ 确认前门确实打开了
2. ha_call_service(domain="light", service="turn_on",
entity_id="light.hallway")
→ 自动打开走廊灯
3. 通过 Telegram 推送通知:"前门已打开,走廊灯已自动开启。"
这种主动推理 + 被动响应的组合,让 Hermes 真正成为 24 小时在线的 AI 管家,而不只是一个等待指令的语音工具。
Cron 定时任务 + 智能家居自动化

Hermes 内置的 Cron 调度器可以创建定时的智能家居自动化任务。和 Home Assistant 原生自动化的区别在于:Cron 任务用自然语言定义、由 Agent 智能执行,支持多步推理和跨平台通知。
关于 Cron 系统的完整能力和高级用法(任务链、预运行门控、无 Agent 模式),请参考 Hermes Agent Cron 定时自动化。
智能家居场景配方
以下四个场景覆盖了最常用的智能家居定时自动化。每个任务都通过 hermes cron create 创建,用自然语言定义操作内容,Agent 自行推理需要调用哪些 ha_* 工具:
提示词:生成 Hermes 智能家居定时任务配方
请帮我用 hermes cron create 命令创建以下四个定时任务。每个任务需要 --schedule(cron 表达式)、--prompt(自然语言操作指令)和 --deliver(结果投递目标)三个参数:
- 早间例程:每天 7:00 执行(
0 7 * * *),操作内容为"卧室灯调到 50% 亮度、恒温器设到 22 度、厨房音箱开启播放新闻",投递到telegram,homeassistant - 夜间安全检查:每天 22:00 执行(
0 22 * * *),操作内容为"检查全屋安全状态——查所有门窗传感器、报警面板、锁具,如有未关的门窗先自动锁定再报告",投递到telegram - 工作日恒温器:工作日 8:00 执行(
0 8 * * 1-5),操作内容为"恒温器设为工作日模式——白天 20 度,无人在家时降到 18 度",投递到local;周末恒温器:周末 9:00 执行(0 9 * * 0,6),操作内容为"恒温器设为周末模式——全天 22 度",投递到local - 每小时能耗监控:每小时整点执行(
0 * * * *),使用--no-agent无 Agent 模式(零 LLM 调用),用--script直接执行 curl 查询sensor.total_power状态,投递到local
其中第 4 个使用 [SILENT] 静默模式,不触发 LLM 推理,直接执行脚本。前三个用自然语言定义,Agent 智能执行。
投递目标
Cron 任务的执行结果可以投递到多个目标:
| 目标 | 语法 | 说明 |
|---|---|---|
| 来源对话 | origin |
创建任务的对话(默认) |
| 本地文件 | local |
保存到 ~/.hermes/cron/output/ |
| Telegram | telegram 或 telegram:<chat_id> |
指定群组或频道 |
| Discord | discord 或 discord:#channel |
指定频道 |
| Home Assistant | homeassistant |
投递到 HA 通知面板 |
| 所有平台 | all |
广播到所有已连接的频道 |
| 组合 | origin,telegram,discord |
逗号分隔多目标 |
技术细节:Gateway 模式下调度器在专用后台线程运行,每 60 秒 tick 一次。任务在隔离的 Agent 会话中执行,拥有完整的工具和技能访问权限。调度状态持久化到 SQLite 数据库,Gateway 重启后自动恢复。
Apple 生态 Skill 联动:Notes、Reminders、iMessage
如果你使用 Apple 设备,Hermes 的 Apple 生态 Skill 矩阵可以和 HA 工具产生强大的联动效果。
Apple Notes Skill
通过 memo CLI 管理 Apple Notes,笔记通过 iCloud 跨所有 Apple 设备同步。
智能家居联动场景:
- Agent 检测到异常事件(凌晨 3 点前门打开)→ 自动创建 Apple Note 记录事件详情、时间戳和 Agent 采取的措施
- 通过 Telegram 说"把今天的家电使用情况记到 Notes"→ Agent 查询 HA 能耗传感器 → 生成报告 → 写入 Apple Notes → 自动同步到 iPhone
Apple Reminders Skill
通过 remindctl CLI 管理 Apple Reminders,任务通过 iCloud 跨设备同步。
智能家居联动场景:
- "提醒我明天下班前关掉花园灌溉"→ Agent 同时做两件事:创建 Apple Reminder(到时提醒你)+ 设置 Hermes Cron 任务(到时自动执行
ha_call_service关闭灌溉) - HA 检测到洗衣机完成(传感器从高功率变为待机)→ Agent 通过 Apple Reminders 添加"取出衣物"提醒,推送到 Apple Watch
iMessage 入口(BlueBubbles 桥接)
Hermes 通过 BlueBubbles 服务器桥接 iMessage——需要一台常开的 Mac 运行 BlueBubbles Server。
消息流向:
iMessage → Messages.app → BlueBubbles Server → Webhook → Hermes
Hermes → BlueBubbles REST API → Messages.app → iMessage
配置只需两个环境变量:
# ~/.hermes/.env
BLUEBUBBLES_SERVER_URL=http://192.168.1.10:1234
BLUEBUBBLES_SERVER_PASSWORD=your-server-password
智能家居联动:用 iPhone iMessage 给 Hermes 发"家里安全吗?"→ Agent 查询 HA 门窗传感器、报警面板和锁具 → 通过 iMessage 回复安全状态报告。这是 Apple 生态用户最自然的交互入口——不需要打开任何额外的 App。
FindMy Skill
通过 FindMy.app 追踪 Apple 设备和 AirTag。智能家居联动:结合地理围栏实现"离家自动布防"——FindMy Skill 提供位置感知,HA 工具执行锁门和启动报警。
完整 Apple Skill 矩阵
| Skill | 路径 | 智能家居联动价值 |
|---|---|---|
| Apple Notes | skills/apple/apple-notes |
事件日志、状态报告同步到 iPhone |
| Apple Reminders | skills/apple/apple-reminders |
设备维护提醒、场景触发提醒 |
| FindMy | skills/apple/findmy |
地理围栏自动化、离家/到家检测 |
| iMessage | skills/apple/imessage |
iMessage 控制入口 |
| macOS Computer Use | skills/apple/macos-computer-use |
GUI 自动化(HA Dashboard 截图等) |
米家设备通过 Home Assistant 桥接 Hermes
中国用户的典型需求——家里大量米家(Xiaomi)设备,如何让 Hermes 控制它们?
路径很清晰:米家设备 → HA 的 Xiaomi Miot Auto 集成 → HA 实体 → Hermes ha_* 工具。
米家设备 → WiFi / 蓝牙网关
→ Xiaomi Miot Auto(HA HACS 集成)
→ HA 实体(如 light.yeelink_xxx、climate.lumi_xxx)
→ Hermes ha_* 工具 → 自然语言控制
HA 端配置(HACS 安装 Xiaomi Miot Auto):
- HACS → 搜索 "Xiaomi Miot Auto" → 安装
- Settings → Integrations → Add → Xiaomi Miot → 输入米家账号
- 设备自动发现并创建实体
Hermes 端无需额外配置——只要设备在 HA 中可见,ha_list_entities 能发现它,ha_call_service 就能控制它。
💡 通俗讲:把米家设备想象成普通的 HA 设备。Hermes 不关心设备是什么品牌、用什么协议连接的——它只看 HA 暴露的实体。小米空调、Yeelight 灯泡、Aqara 门窗传感器,在 Hermes 眼里和任何其他 HA 设备没有区别。
这意味着你不需要替换现有的米家设备,只需要加一层 HA 作为桥接,所有设备就能被 AI 管家统一控制。
竞品对比:Hermes vs 其他 AI 智能家居方案

2026 年的 AI 智能家居赛道选择很多,但它们在 Agent 能力维度上差异巨大。
| 方案 | AI 层 | 记忆 | 技能学习 | 控制入口 | 增量成本 | 设备兼容 |
|---|---|---|---|---|---|---|
| Hermes Agent + HA | 30+ LLM 提供商 | 三层持久记忆 | Skill 自动创建 | 20+ 消息平台 | 可零成本 | HA 兼容(4000+ 品牌) |
| HA + OpenAI Conversation | GPT-4o | 无 | 无 | HA 内部 | $20+/月 | HA 兼容 |
| HA + home-llm | 专用微调模型 | 无 | 无 | HA 内部 | 零(本地运行) | HA 兼容 |
| Apple HomeKit + Siri AI | Apple Intelligence | 有限 | Shortcuts | Apple 设备 | 零 | HomeKit 设备 |
| Alexa | 私有模型 | 有限 | Routines | Echo 设备 | 零(含广告) | Alexa 兼容 |
| Google Home + Gemini | Gemini Nano | 有限 | Routines | Nest 设备 | 零 | Google 兼容 |
| 小爱同学(米家) | 私有模型 | 无 | 无 | 小爱音箱 | 零 | 米家设备 |
Hermes vs HA + OpenAI Conversation Agent
这是最常见的对比场景。两者都让 AI 控制 HA,但架构完全不同:
HA + OpenAI Conversation Agent:HA 内部运行一个对话代理插件,用户通过 HA 的 Assist Pipeline 发起请求。AI 层依赖 Intent 模板匹配——预定义好"开灯"对应什么操作,AI 做的是识别意图然后分发到对应的预设动作。没有持久记忆,每次对话独立。功能固定,不会随使用而改善。
Hermes Agent:Hermes 作为独立 Agent 运行在 HA 外部,通过 REST API 和 WebSocket 双通道与 HA 交互。AI 层使用 LLM 原生的工具调用机制——Agent 自己推理"用户想做什么"然后选择调用哪些工具。三层持久记忆让 Agent 记住你的偏好("我通常 7 点起床""客厅灯我喜欢暖白色")。完成 5 次以上工具调用的复杂操作后,Agent 自动将解决方案抽象为可复用的 Skill。
核心差异总结:
- 主动推理 vs 被动匹配——Hermes 用 LLM 推理用户需求然后调用工具,不依赖预定义模板
- 多步编排——"检查房子安全吗"需要查门窗 → 查报警 → 查锁具 → 汇总报告,Intent 匹配方案做不到
- 跨平台统一入口——出门用 Telegram 语音、在家用 Discord、工作时用 CLI,同一个 Agent
- 学习进化——用得越多越聪明,自动沉淀操作为可复用 Skill
- LLM 自由切换——不绑定 OpenAI,可用本地 Ollama(零成本)、DeepSeek(低成本)、Claude(高质量)等 30+ 提供商
Hermes vs home-llm
home-llm 是 HA 社区的另一个方案——包含一个 HA 自定义集成和一个专门为设备控制微调的小模型。
home-llm 的优势:深度 HA 集成、资源消耗极低(小模型即可运行)、完全本地化。
Hermes 的优势:通用 Agent 能力(记忆/技能/多平台)、可选 30+ LLM 提供商、不仅限于设备控制(同一个 Agent 还能处理其他任务)。
🔥 翔宇判断:如果你只需要"用自然语言控制灯和空调",home-llm 是更轻量的选择。但如果你想要一个记得你习惯、会学习新操作、能从 Telegram 远程控制家里设备的 AI 管家,Hermes 是目前唯一的开源选择。
Apple WWDC26 的智能家居更新

Apple 在 WWDC26 宣布了 iOS 27 / macOS 27 的智能家居更新:Apple Intelligence 整合 Home App、Siri AI 升级、"Describe a Shortcut"功能(用自然语言描述需求,Apple Intelligence 自动组装 Shortcuts 步骤)。
Hermes 相对 Apple 方案的差异化在于:覆盖所有 HA 兼容设备(4000+ 品牌,不限于 HomeKit),不锁定 Apple 生态,同时通过 Apple Skill 矩阵深度桥接 Apple 用户体验。你可以用 iMessage 控制非 HomeKit 设备——这是 Apple 自己的方案做不到的。
完整配置参考:从零到生产
以下是一套完整的 Hermes + HA + Apple 生态联动配置,可以直接参考。
config.yaml
~/.hermes/config.yaml 是 Hermes 的主配置文件,整合了模型选择、平台连接、事件过滤和工具优化的所有设置:
提示词:生成 Hermes + Home Assistant + Apple 生态的完整 config.yaml
请帮我生成 ~/.hermes/config.yaml 的完整配置。要求包含以下段落:
model 段(主模型):
default:主模型名称,如deepseek-v4-proprovider:提供商,如deepseek
auxiliary 段(辅助模型):
vision.provider和vision.model:视觉模型用于图像理解,如 Google 的gemini-2.5-flash
platforms.homeassistant 段(HA 事件监听):
enabled: truewatch_domains:监听 6 个域——climate、binary_sensor、alarm_control_panel、light、lock、coverwatch_entities:额外监听前门电池和客厅温度传感器ignore_entities:屏蔽 uptime、cpu_usage、memory_usage、cpu_temperaturecooldown_seconds: 30
platforms.discord 段:
enabled: truechannel_prompts.smart-home:定义智能家居专用频道的 Agent 角色提示词(控制设备、异常通知、定时安全检查、联动 Apple Notes 和 Reminders)
platforms.bluebubbles 段:enabled: true(iMessage 桥接)
tool_search 段(工具 Token 优化):
mode: autopinned_tools:始终加载的核心工具列表——terminal、read_file、write_file、send_message、memory、skills,加上 3 个 HA 工具 ha_list_entities、ha_get_state、ha_call_serviceevict_after_turns: 3(工具调用后 3 轮未再使用则卸载 Schema)
.env
~/.hermes/.env 存放所有外部服务的凭据,Hermes 启动时自动加载:
提示词:生成 Hermes 智能家居场景的 .env 环境变量文件
请帮我生成 ~/.hermes/.env 文件。要求包含以下环境变量:
Home Assistant 凭据:
HASS_TOKEN:HA 长期访问令牌(在 HA → Profile → Security → Long-Lived Access Tokens 创建)HASS_URL:HA 实例地址,如http://192.168.1.100:8123(默认http://homeassistant.local:8123)
iMessage 桥接(BlueBubbles):
BLUEBUBBLES_SERVER_URL:BlueBubbles Server 地址,如http://192.168.1.10:1234BLUEBUBBLES_SERVER_PASSWORD:BlueBubbles 服务器密码
LLM 提供商:
DEEPSEEK_API_KEY:DeepSeek API 密钥(主模型)GOOGLE_API_KEY:Google API 密钥(辅助视觉模型 Gemini)
注意:环境变量只在进程启动时读取,修改后必须重启 Gateway。
验证清单
# 1. 验证 HA 连接
curl -sH "Authorization: Bearer $HASS_TOKEN" "$HASS_URL/api/" | jq
# 2. 启动 Gateway
hermes gateway
# 3. 验证 HA 工具可用
hermes tools
# 应看到:ha_list_entities, ha_get_state, ha_list_services, ha_call_service
# 4. 测试设备控制
# 在任意消息平台对 Hermes 说:"列出所有灯"
故障排除
环境变量未生效
适配器从 ~/.hermes/.env(启动时自动合并)或 config.yaml 读取凭据。检查文件路径是否正确、值两端是否有多余引号。环境变量只在进程启动时读取——修改后必须重启 Gateway。
conversation entity not found
HA 的对话 API 需要配置 Assist 对话代理。在 HA 中打开 Settings → Voice assistants → Add assistant,记下实体 ID(如 conversation.home_assistant),在适配器的 conversation_entity 设置中填入。
REST 认证失败(401 Unauthorized)
Token 必须是 Long-Lived Access Token(Profile → Security 页面创建),短期 UI 会话 Token 不行。验证 URL 包含协议和端口(如 http://homeassistant.local:8123)。可以用 curl 独立测试:
curl -H "Authorization: Bearer <token>" http://homeassistant.local:8123/api/
WebSocket 频繁断连
检查 HA 实例是否在同一局域网内。如果 Hermes 部署在远程服务器上,确保 HA 的 WebSocket 端口(默认 8123)对外可达。Gateway 有自动重连机制(退避序列 5s → 10s → 30s → 60s),偶尔断连不影响正常使用。
常见问题
Q1:Hermes Agent 连接 Home Assistant 需要安装插件吗?
不需要。设置 HASS_TOKEN 即激活四个内置 ha_* 工具,HA 端零安装。反向调用(HA 调 Hermes)可选装 WolframRavenwolf 的 HACS 自定义集成。
Q2:Hermes 控制 Home Assistant 安全吗?
三层机制:6 个危险服务域(shell_command、python_script 等)硬编码封锁,实体 ID 正则验证防注入,路线图中还计划加入审批闸门和服务白名单。
Q3:支持语音控制 Home Assistant 吗?
支持。语音输入 → faster-whisper 转写 → Agent 推理调用 ha_* 工具 → 设备操作 → TTS 语音回复。零成本方案用 faster-whisper + Edge TTS。
Q4:米家设备能通过 Hermes 控制吗?
可以。米家设备通过 HA 的 Xiaomi Miot Auto 集成暴露为实体后,ha_* 工具即可控制,Hermes 端无需额外配置。
Q5:和 HA 内置的 OpenAI 对话代理有什么区别?
Hermes 用 LLM 原生工具调用做多步编排,有持久记忆和技能自动学习,支持 20+ 消息平台远程控制。HA 内置对话代理依赖 Intent 模板匹配,无记忆、无学习、仅限 HA 内部交互。
Q6:Gateway 监听会不会收到大量无用通知?
不会。默认不转发任何事件,必须显式配置 watch_domains 或 watch_entities。配合 ignore_entities 和 cooldown_seconds 可精确控制噪音。
Q7:Hermes 定时任务和 HA 原生自动化有什么不同?
HA 原生用 YAML/GUI 编写确定性规则。Hermes Cron 用自然语言定义、Agent 智能执行,支持多步推理和跨平台通知。
Q8:Hermes HA Add-on 和官方内置集成是什么关系?
内置集成是核心代码(Hermes → HA 方向),Add-on 是 WolframRavenwolf 社区项目(HA 侧边栏管理完整 Hermes 实例)。两者可同时使用。
延伸阅读
- Hermes Agent 完全指南:让 AI 编程助手接管你的全部消息平台——Hermes 架构全景、核心能力和系列教程导航
- Hermes 语音模式完全攻略——三种语音交互表面的完整搭建指南
- Hermes Agent Cron 定时自动化——任务链、预运行门控和零成本触发的完整配方
- Hermes Agent 深度测评——从 0 到生产的实战复盘
下一步
- AI 编程实操课:Claude Code + Codex + Agent 工作流,覆盖一人公司、自媒体自动化、AI 副业全场景。237 篇实战教程 + 最佳实践 + 源码包,跟着做就出成果。国内版-FlowUS | 国际版-BMC
- YouTube 频道:翔宇工作流
- 微信公众号:搜索「翔宇工作流」




















