AI 智能体 + Home Assistant：一份现实的接入方案

2026 年的 Home Assistant 生态

Home Assistant 已经内置了自己的对话代理。自 2025 年 9 月发布"AI in Home Assistant"起，你可以把 OpenAI、Anthropic、Google 或本地的 Ollama 服务器直接接入 Assist 流水线，让它控制设备、编写自动化，并回答关于你家的问题。如果一直在关注这个方向，今年最大的变化是：像 Qwen3 8B 这样的小型 function-calling 模型现在能在一台 mini PC 上可靠地完成工具调用，因此整条闭环都可以留在本地。

这已经覆盖了不少人在搜索"ai agent home assistant integration"时的诉求，但并非全部。Home Assistant 开箱不能提供的，是一个持久的、由消息驱动、住在家外的智能体：能跨季节记住事情，能按计划执行检查，并在你没站在墙面控制屏前时通过手机联系你。这正是外部智能体通过 MCP 接入所要占据的位置。

内置对话代理擅长什么

在增加任何东西之前，先看看你已经拥有什么。Home Assistant 的 Assist 流水线是路由层：麦克风进、动作出。你把一个对话代理挂到它上面，由这个代理决定如何把口语指令变成服务调用。

目前支持的三种路径：

OpenAI、Anthropic、Google 对话集成 - 云端模型，速度快，tool-calling 表现好。语音和文本都会发送到服务商那里。
Ollama 集成 - 指向本地的 Ollama 服务器。2026 年，对拥有 mini PC 或 NUC 的家庭已经具备生产可用性。Qwen3 8B 是当前工具调用延迟的甜点。
Local LLM Conversation - 通用的 OpenAI 兼容客户端。如果你自托管的是 Ollama 之外的东西（llama.cpp、vLLM、LM Studio），这个很有用。

上述任何一条都足以覆盖基础场景："关掉厨房灯"、"把温度调到 20"、"车库门开着吗？"这些需求用不上 Hermes。如果你的目标只是一个私密、家内、能与设备对话的语音助手，选 Ollama 那条路，然后可以直接停下不用继续读了。

内置代理在哪里力有不逮

内置代理在设计上就有意保持窄范围：它们回答、执行，然后等待下一句话。这个模型会在三个地方失灵。

没有跨时间的持久上下文。 问 Assist"我们上个月电费花了多少"，它只会看到当前上下文允许它看到的东西。它不会记得上个月你曾要求降低待机功耗，也不会记得四月你换了冰箱。每次会话都是从零开始。
没有主动的时间表。 Assist 流水线是被动响应型的。你可以用触发器搭建经典自动化，也可以用 Suggest 按钮让 LLM 帮忙起草自动化，但你没法轻易地要求一个代理："每周日早上看一下这周的能耗数据，告诉我哪些设备开得最久，并把任何看起来异常的东西标出来。"这属于智能体的活，不是自动化的活。
家外没有对话入口。 Assist 生活在 App 和 Voice 硬件上。想在办公室查一下锅炉，或者让代理准备一份周报并通过聊天发给你，就要完全离开 Home Assistant 这一层。

这些缺口不是 bug。这是当一个对话代理被设计成控制层而不是副驾时的自然结果。

改变格局的 MCP 桥梁

Home Assistant 在 2025 年推出的 Model Context Protocol 集成正是那块缺失的拼图。Home Assistant 现在内置运行一个 MCP 服务器，把设备、状态、区域以及 Assist 的意图作为 MCP 工具暴露出来。任何兼容 MCP 的智能体都可以连接到这个服务器，用与 Assist 完全相同的原语来控制你的家。

这就是让真正的外部智能体成为可能的关键一步。你不再需要为每一个 AI 产品单独写一份 Home Assistant 集成，而是把一个 MCP 智能体指向你的 Home Assistant URL，交给它一个长效访问令牌，它就继承了 Assist 的整套工具集。Home Assistant 的 MCP 服务器目前已经暴露了 95 个以上的工具，覆盖照明、气候、安防、媒体、传感器和场景。

如果你用 Hermes Agent 搭配 MCP 接过 GitHub 或 Slack，那这里的心智模型是一样的。家，只不过是另一台 MCP 服务器。

像 Hermes 这样的外部智能体在什么位置

外部智能体并不会取代 Home Assistant。Home Assistant 依旧掌管设备、状态和物理硬件，那是它擅长的部分。外部智能体坐在它之上，处理 Assist 没有为之设计的那几部分：跨会话的记忆、按计划的思考，以及一个能跟着你走出四面墙的聊天界面。

具体推荐的搭建方式：

Home Assistant 跑在 Raspberry Pi、NUC 或你现有的 homelab 上。运行 MCP 服务器（mcp_server 集成），继续掌管自动化和面板。
Hermes Agent 跑在一台 5 美元 VPS、同一台 homelab 主机，或作为一个 Hermify 托管实例。配置里把 Home Assistant MCP 服务器作为它的工具来源之一。
Telegram 作为对话入口。你跟 Hermes 说话，Hermes 再去和 Home Assistant 说话。

有了这种形状，三件原本别扭的事情会变得轻松：

属于家的持久化记忆。 Hermes 会维护 USER.md 之类的记忆文件，记住你只讲过一次的事实："冰箱是 Bosch KGN，2026 年 4 月换的"、"夏季设定 24 度、冬季 20 度"、"上学日孩子 20:30 睡觉"。这些事情 Assist 在每次调用之间会忘光，Hermes 会记住。
带真正推理的计划任务。 "每周日上午 10 点，总结上一周的能耗，告诉我用得最久的三台设备，并标出高于上月基线的部分。"Home Assistant 触发日程，Hermes 通过 MCP 调用推理数据，结果落进 Telegram。
家外的聊天界面。 你在开会，有人问办公室的灯是不是还亮着。问 Hermes。它去查 Home Assistant 的 MCP 服务器，取到状态，然后回答。用的正是你日常那条 Telegram 会话。

何时选哪条路

诚实地选一条。当 Assist 已经够用时再叠一个外部智能体，只会徒增活动部件。

只要本地语音控制设备，私密且快？ Ollama + Assist。到此为止。
本地语音控制加上按计划的自动化？ Assist + Home Assistant 的经典自动化，不需要外部智能体。写自动化时用 Suggest 按钮。
本地语音控制、持久化记忆、外部聊天入口，加上按计划的推理？ wake-word 那一段用 Assist，其余部分交给通过 MCP 接入的 Hermes。这正是这篇文章讲的搭法。
没有 wake-word 硬件，主要靠聊天，但仍想控制设备？ 你可以完全跳过 wake-word 那一侧，全部走 Telegram 上的 Hermes。开口、执行、回复。

关于自己跑 Hermes 还是让 Hermify 托管这个更深层的选择，我们已经在 Hermes Agent 自托管 vs 托管里拆解过。和 Home Assistant 的接入方式并不会改变这个权衡。两种情况下 MCP 配置都是一样的。

接线示意

完整方案是按组件分别文档化的，但配置的形状很短，值得放在这里，让你直观看到"把 Hermes 接到你家"到底意味着什么。

在 Home Assistant 这一侧，启用 MCP 服务器集成，并生成一个长效访问令牌。你会得到一个可访问的 MCP 端点和一个 bearer token。

在 Hermes 这一侧，把 Home Assistant 的 MCP 服务器加进智能体的配置里：

{
  "mcpServers": {
    "home-assistant": {
      "url": "https://ha.your-domain.tld/mcp_server/sse",
      "headers": {
        "Authorization": "Bearer <long-lived-access-token>"
      }
    }
  }
}

重启智能体。它会向服务器做 introspection，学习你的设备名，把它们加入自己的工具列表。下一条 Telegram 消息里，"关掉门廊灯"就会变成一次真正的 Home Assistant 服务调用，权限与 Assist 一致。

安全面就是标准的 MCP 安全面：令牌很强大，别提交进版本控制，把 Home Assistant 的 URL 放在反向代理或 Tailscale 后面，而不是直接暴露到公网。如果想要私网路径的端到端方案，可以参考我们的私有自托管助手实操，那里覆盖了 Hermes 通用的同一套模式。

这套方案不做什么

在你决定之前，先把边界讲清楚：

它不替代 Home Assistant。 没有面板、没有 ZigBee 栈、没有内置蓝图。这一切依旧留在 Home Assistant。
它不是房间里的实时语音流水线。 环境中的 wake-word 监听依然属于 Assist 和你的语音硬件。Hermes 是 chat-first，Telegram 上有可选语音模式，而不是墙面控制屏的替代品。
如果你为 Hermes 使用托管 LLM，它不会彻底去除云端。 MCP 调用留在你的网络内，但如果你把 Hermes 指向 OpenRouter 之类的模型服务商，推理会发生在家外。要做到全部本地，就让 Hermes 用基于 Ollama 的模型服务商，栈就变成完全本地。

下一步去哪里

如果你想端到端地试一次这套方案，同时省掉服务器维护，从 Hermify 开始。你会得到一个跑在 Telegram 上的托管 Hermes Agent，把 Home Assistant 的 MCP 服务器接上，剩下的就是对话。如果你更想自己跑完整栈，同样的 MCP 接线在本地也一样能跑；唯一要决定的，是要不要让 Hermify 也把 VPS 那一侧帮你管理起来。

无论选哪种，那条有用的分界都在同一条线上：Home Assistant 继续做你家的事实来源，AI 智能体则住在它之上一层，那里才是记忆、日程和对话真正应该在的地方。