Home Assistant 2026.10 让 AI 连接更简单：先完成这些安全检查

Home Assistant 2026.10 改变了智能家居连接外部软件的方式。这个版本加入了更清晰的 AI 设置区域，让 Model Context Protocol 服务器更容易启用，也能自动发现一些自带 MCP 服务器的应用。同时，它还带来了一些普通维护功能，例如 Modbus 连接面板，以及信息更完整的仪表盘卡片。

一只手停在智能家居平板上方，屏幕显示通用的安全与权限控制，背景是明亮的客厅。

最受关注的功能不是新传感器，也不是新的无线标准，而是 Home Assistant 与 Claude、ChatGPT 或 Cursor 等 AI 应用之间的连接路径变短了。在合适的配置下，你可以更方便地询问设备状态、读取当前信息，或控制一组范围受限的实体。配置不当时，一个过于宽泛的管理员权限，可能会变成远程操作门锁、车库门、警报器、暖气和其他高影响设备的控制器。

合理的做法不是避开这次更新，而是把新的设置界面当作一次权限审查。如果你已经在使用 Home Assistant 的 MCP 集成，2026.10 正好提醒你检查当前暴露了哪些内容。如果你还没有使用它，也完全可以安装这个版本，同时不启用该功能。

Home Assistant 2026.10 改了什么

10 月版本于 10 月 7 日发布，在设置 > 系统下的 AI 页面加入了 Model Context Protocol 卡片。Home Assistant 将 MCP 描述为一种让外部 AI 应用连接 Home Assistant Assist API 的方式。新的卡片可以一键启用服务器，并显示需要复制到兼容客户端中的连接 URL。

这主要是一次易用性改进。MCP 服务器并不是在这个版本中才出现的；Home Assistant 文档说明，这项集成此前已经推出。真正重要的变化是，用户不再需要在集成列表中寻找它、判断哪个端点适用，再手动拼接连接信息。

新的配置默认暴露所有可用的 LLM API，包括之后新增的 API，并默认限制只有管理员账户才能连接。这两项设置都可以在集成配置中修改。这样的默认值适合作为起点，但不能替你决定连接后的应用究竟应该能够执行什么操作。

反向连接也变得更容易。现在，提供自有 MCP 服务器的应用可以由 Home Assistant MCP 集成自动发现。连接这类应用需要确认，不再需要较长的手动发现流程。这确实方便了，但也让阅读确认界面变得更重要，不要看到发现的服务就全部直接接受。

Home Assistant 2026.10 还改善了部分 AI 工具向客户端介绍自身的方式。开发者文档称，LLM 工具现在会返回结构化的 ToolResult，并可以声明工具是否只读、是否具有破坏性、是否幂等，或是否能够访问 Home Assistant 之外的资源。这些标签能让 AI 客户端更了解工具行为，但它们本身不会把不安全的权限边界变成安全边界。

MCP 不等于把整个 Home Assistant 交给 AI

AI 这个词可能让功能听起来比实际更宽泛。内置 Assist API 围绕 Home Assistant 暴露的实体和能力设计，并不会提供对整个 Home Assistant 安装的通用管理权限。官方开发者文档指出，内置 Assist API 无法执行管理任务。

这是一条有用的边界。连接到 Assist 的 AI 客户端可能可以读取温度、打开台灯，或运行一个已暴露的脚本，但这不表示它可以编辑自动化、重写仪表盘、查看所有日志，或修改操作系统。这些属于不同的能力，不能因为客户端可以控制某个设备，就默认它也拥有这些权限。

不过，这条边界仍可能比许多家庭预想的更宽。连接的客户端可以收到当前暴露上下文的快照，而一个实体可能包含住户是否在家、安防状态、能源使用情况或个人作息等信息。台灯通常影响较小；门锁、车库门、摄像头、警报器、总水阀或暖气则完全不同。

MCP 集成文档说明，客户端只能控制所选 LLM API 和暴露实体配置中提供的实体。这是实际应该使用的控制手段。问题不在于某个 AI 客户端抽象地说是否值得信任，而在于当前暴露的实体集合是否足够有限，以至于一次误操作仍然可以恢复。

第一项检查：审查暴露的实体

连接 AI 应用前，打开 Home Assistant 的语音助手或 Assist 暴露设置，逐一查看列表中的设备。移除所有不需要语音或 AI 控制的内容。Home Assistant 自己的最佳实践文档建议只暴露最少数量的实体，因为更小的集合能改善匹配、减少上下文，也能降低助手选错设备的可能。

从影响较小的设备开始。台灯、媒体播放器、风扇或温度传感器，比门锁或警报器更适合拿来测试。第一次实验的目标是证明连接能够工作，而不是让首次尝试直接变成安全事件。

接着检查名称和区域。AI 系统需要区分卧室灯、卧室风扇和卧室暖气。清晰的名称以及正确的房间归属可以减少歧义。避免让多个设备使用几乎相同的名称，尤其是它们造成的后果不同的时候。前门锁和门廊灯比两个都叫前面的实体更容易区分。

Home Assistant 的暴露文档特别提醒，不应让门锁、车库门等敏感设备被语音意外控制。这一谨慎原则同样适用于通过 MCP 连接的 AI 客户端。如果某个实体不需要以对话方式控制，就不要暴露它。仪表盘仍然可以保留手动控制，而不必把它变成 AI 工具。

脚本也要谨慎处理。Home Assistant 的 Assist 指南指出，暴露给 LLM 的脚本可以成为工具，而不只是普通实体。这很有用，因为设计良好的脚本能够代表完整流程；但这也意味着脚本的描述和行为都很重要。名为夜间模式的脚本不应在副作用中悄悄解锁门、停用安防设备，或关闭安全设备。

对于会影响多个设备的例程，创建一个目的明确、范围可预测的窄脚本。例如，关闭楼下灯光就比较清楚。离家模式则风险更高，因为它可能同时打开车库门、改变警报模式、调节暖气，并向其他人发送通知。把高影响操作分开，助手就有更少机会意外把它们组合起来。

第二项检查：确认是否真的需要管理员

Home Assistant 2026.10 对新的 MCP 配置默认启用仅管理员访问。这比把普通家庭账户视为所有 API 都足够要安全，也说明这类连接应该按照其他特权集成的标准来维护。

官方用户文档区分了管理员账户和普通用户。管理员可以配置集成、设备和系统设置，非管理员账户则无法完整访问配置区域和系统区域。MCP 文档说明，基础端点可以配置为要求管理员权限，而内置 Assist API 以外的 API 需要经过身份验证的管理员账户。

不要因为 AI 客户端提出要求，就把家庭成员日常使用的账户提升为管理员。如果客户端确实需要特权 API，可以为它创建一个单独账户，使用强度高且唯一的密码，并持续检查账户角色和实体暴露列表。没有绑定具体人员的服务账户可以用于集成，但不应变成无人跟踪的永久超级用户。

Home Assistant 的安全指南建议使用强度高且唯一的密码、启用多因素身份验证，并把管理员权限限制给确实需要它的账户。当客户端可以使用令牌或经过身份验证的远程连接时，这些建议更加重要。把访问令牌当作凭据处理，不要将它粘贴到公开的 issue、截图、聊天室或共享笔记中。

如果家庭并不需要外部 AI 控制，就没有理由启用 MCP。安装 Home Assistant 2026.10，以及使用普通仪表盘、自动化、Assist 功能或设备集成，并不要求连接外部 MCP 客户端。最安全的权限，往往是根本不需要授予的权限。

第三项检查：确认连接如何进入你的家庭网络

MCP 服务器会暴露在类似 /api/mcp 的端点上，客户端必须完成身份验证。同一网络中的本地客户端，与通过互联网连接 Home Assistant 的托管服务，风险特征不同。批准连接之前，先弄清楚自己正在配置哪一种。

Home Assistant 的安全文档建议使用安全的远程访问方式，不要把安装直接暴露到互联网。文档列出了 Home Assistant Cloud、带证书的 TLS、VPN 和 SSH 隧道等方案，它们在配置与维护成本上各有不同。为了测试 AI 功能，直接把 Home Assistant 实例通过端口转发暴露到公共互联网，并不是合理的捷径。

如果使用反向代理、隧道或托管 MCP 客户端，仔细检查主机名和身份验证流程。MCP 文档指出，远程客户端可能需要主机名与 Home Assistant 中配置的内部或外部 URL 相匹配。因为 URL 不匹配而失败的连接只是麻烦；通过未预期的公共路径成功连接，则是安全问题。

OAuth 支持并不会消除理解权限的必要。它可以让身份验证更容易，但客户端仍然会获得所选 API 和暴露实体所允许的全部内容。如果应用提供多种连接方式，选择能让账户、令牌和撤销控制最清晰的方案。

完成设置后，从客户端的工具列表或连接界面测试。确认它只能看到你打算暴露的实体。然后撤销或移除连接，再验证访问确实停止。只有同时测试允许路径和移除路径，权限系统才更值得信任。

面向真实家庭的更安全上线方式

可以分阶段完成上线。先更新 Home Assistant，让它正常重启。检查重要的自动化、仪表盘和设备集成是否仍然工作。版本说明包含不向后兼容的变化，其中包括用户名标准化：用户名现在会按小写处理，并移除开头和结尾的空格。如果 Home Assistant 显示修复提示或账户警告，先处理这些问题，再添加新的 AI 连接。

接着列出你真正希望 AI 客户端完成的任务。告诉我车库门是否打开，比管理我的房子具体得多。打开厨房灯，比运行离家流程更适合作为第一次控制测试。如果无法用一句话描述目标动作，第一次设置时它很可能过于宽泛。

只暴露这些任务所需的传感器和设备。先从只读检查开始。询问温度传感器、灯或门磁的当前状态，观察回答是否识别了正确的区域和设备。如果没有，先修正名称与暴露设置，再允许控制。

下一步只加入一个低风险控制。打开一盏灯或启动风扇，然后确认动作抵达了预期实体。不要使用门锁、车库门、暖气、烤箱、水阀或警报器进行测试。第一次命令成功，只能证明连接正常，并不能证明客户端总能正确理解自然语言请求。

如果之后要暴露高影响设备，应在周围流程中加入明确确认。例如，使用一个在改变警报状态前要求清晰确认的脚本，或者把最终动作保留为手动完成。不要依赖让房子安全这类含糊指令，因为最终结果取决于 AI 如何判断哪些门、窗、摄像头和警报器才算安全。

在家庭笔记中记录连接信息：连接了哪个客户端、使用哪个账户、暴露了哪些实体，以及如何撤销访问。家中某个人负责设置连接，另一个人负责维护智能家居时，这一点尤其有用。没有文档的集成，往往会在所有人都忘记它存在的原因后继续保留下去。

更新后值得检查什么

新的 AI 页面当然是最明显的检查位置，但这个版本还有几项非 AI 变化值得留意。设置 > 连接性下的新 Modbus 面板会列出串行和网络连接、连接上的设备，以及正在使用这些连接的集成。对于使用逆变器、能源电表、供暖设备或其他 Modbus 硬件的家庭，尤其是在多个集成共享一个连接时，这很有帮助。

Home Assistant 还改善了仪表盘可见性条件。可见性标签页现在会显示卡片当前是否可见，以及每个条件是否通过。这有助于诊断仪表盘中看似消失的控制项，而不必立即重写卡片或自动化。

媒体搜索行为也有所改善。Home Assistant 表示，当 AI 请求播放音乐时，可以收到搜索结果列表并选择更匹配的结果；在受支持的媒体系统中，艺术家、专辑和播放列表内部的搜索也得到改进。这仍然是评估 AI 连接的低风险场景。播放错歌只是麻烦；改变门锁状态则属于安全事件。

一些家庭还会遇到特定集成的变化。版本说明提到 Teslemetry 车辆行为发生变化、UniFi Network 的重新配置路径被移除，以及用户名标准化。自定义集成可能有自己的兼容性要求。如果安装依赖 HACS 组件或不常见的厂商集成，请先查看版本说明和修复提示，不要直接假设所有设备都不受影响。

权限变化后，备份更重要

在改变身份验证、添加新集成或暴露大量设备之前，先创建一份新备份。备份无法阻止 AI 做出错误决定，但如果配置变化导致安装损坏，它能提供一个恢复点。至少保留一份不在 Home Assistant 主机上的副本；只存放在故障设备上的备份，并不能构成完整的恢复方案。

还要明确备份能做什么、不能做什么。Home Assistant 的恢复文档警告，恢复完整备份会用备份内容替换当前的 Home Assistant 设置、应用及其数据。备份之后所做的改动会丢失。因此，恢复是一项恢复操作，不是撤销某次错误语音命令的按钮。

对于 AI 权限变化，记录原始暴露列表，或截取相关设置的屏幕截图。如果新的配置变得混乱，你可能需要手动恢复权限设置，而不是恢复整个家庭。问题如果只是我暴露了哪个实体，一份简单的书面清单通常比大型备份更有用。

现在应该启用 MCP 吗

如果你已经有明确的本地或远程 AI 工作流，理解账户和网络路径，并愿意维护一份较小的暴露列表，可以现在启用。2026.10 的界面应能让设置更容易，而 Assist API 也比通用管理员访问提供更窄的边界。先从只读传感器和影响较小的设备开始。

如果吸引你的理由只是这个功能刚刚出现，或者你还无法确定哪个客户端会连接，也没有可靠的撤销访问方式，可以先等待。推迟连接几乎不会损失什么。Home Assistant 仍然可以通过普通应用、仪表盘、自动化和兼容的语音路径控制家庭。

不要把它当作备份、安全系统或精心设计的自动化的替代品。AI 可以解释请求，但除非你明确规定并持续收窄工具边界，否则它并不知道家庭的安全规则。它也可能误解含糊的请求，却用听起来很确定的语气给出结果。

Home Assistant 2026.10 带来的有用启示，与其说是对 AI 的热情，不如说是权限设计。更短的设置流程是好的产品工作，但它应该减少已经做出的决定所带来的摩擦，而不是替你做决定。让客户端只看到需要的内容，使用能够工作的最低权限账户，有意识地处理远程访问，测试撤销流程，并在错误代价很高时，把高影响操作留在手动确认之后。

这样既能让新功能变得实用，也不会把智能家居变成网络上每个 AI 应用都可以未经审查延伸进去的空间。