Google 在 2026 年 9 月 16 日正式上线了基于模型上下文协议(Model Context Protocol,简称 MCP)的智能家居集成服务,其开发者指南已于前一日更新。这项处于 Early Access 阶段的更新,允许 Claude、OpenClaw 或自研 AI Agent 通过标准化接口读取家庭设备的历史数据并下发控制指令。这意味着主流云端智能家居平台第一次将自家的家庭关系图谱(Home Graph)向第三方大模型开放。

但这并不是普通消费者在手机上勾选几个开关就能用上的免费功能。Google 把这项能力死死锁在每月 20 美元的高级订阅和复杂的开发者后台之后,并且在物理安全层面戴上了极为严格的镣铐。当外界以为可以用自然语言让 AI 彻底接管琐碎家务时,拿到手的其实是一个被层层设防、功能残缺的付费沙盒。

两套接口入局:在云端把硬件暴露给大模型

本次技术发布由两个互补的服务端点组成:专门用于设备控制的 Home MCP,以及面向代码与配置助手的 Home Developer MCP。后者仅开放了一个名为 search_documents 的文档检索工具,单页最多返回 30 条记录,集成了 Matter 1.5.1 规范、Thread 1.4.1 规范、OpenThread 代码库以及 Google 官方开发文档,用来辅助开发者编写智能家居代码。

大模型接管家庭硬件需每月支付二十美元高级订阅费
大模型接管家庭硬件需每月支付二十美元高级订阅费

真正牵动实体硬件的是 Home MCP 服务端。它直接暴露了 5 个核心工具接口:用于获取家庭列表的 list_homes、枚举设备拓扑的 list_home_resources、查询实时状态的 list_home_states、提取时序遥测的 list_home_history,以及下发硬件控制动作的 run_home_actions。

Google Home MCP 架构与权限边界 AI 代理接入端 Claude Cowork OpenClaw Google Antigravity OAuth 2.0 鉴权校验 Home MCP 控制层 list_home_states list_home_history run_home_actions MOST_FRESH 状态穿透 物理设备与防线 灯光 / 空调 / 音箱 门锁解锁(绝对封禁) 自动化编排(不支持)

要让大模型调通这 5 个工具,门槛并不低。使用者必须在 Google Cloud 控制台中创建专属项目,启用 Home API,并申请特定权限范围的 OAuth 凭证。目前官方文档仅适配了 Google Antigravity、Claude Cowork 以及近期在极客圈流行的 OpenClaw。

更核心的筛选机制在于商业门槛。该服务首批仅向使用美区英语的用户开放,且强制绑定 Google Home Premium Advanced 订阅计划,资费为每月 20 美元或按年支付 200 美元。虽然顶级的 Google AI Ultra 订阅涵盖了这项权益,但 Google AI Pro 用户每月仍需额外加购 10 美元才能激活。借着开放接口的名义,Google 顺理成章地将家庭物理控制权转化为了高客单价订阅与云服务绑定的抓手。

戴着镣铐跳舞:被禁用的门锁与缺失的自动化

许多用户期待 AI 能够代替自己写出高度复杂的家庭条件自动化,例如根据传感器状态、作息与天气动态开关设备。但现实与宣传存在明显落差。在当前接口规范下,Home MCP 明确不支持创建或管理任何自动化联动。换句话说,外部大模型可以作为单一指令的执行手,却不能沉淀为家庭内部长期运行的规则编排器。

无论提示词如何设计,云端接口都会强制拦截门锁解锁指令(剖面示意)
无论提示词如何设计,云端接口都会强制拦截门锁解锁指令(剖面示意)
物理世界容不下幻觉,因此这套控制协议在放开双手的同时戴死了脚镣。

不仅自动化能力缺位,安全边界也被锁得极死。Google 在云端强制拦截了针对智能门锁的解锁指令,外部 Agent 无论如何组织提示词都无法打开家门。涉及家庭安防的熟悉面孔识别数据,必须经由家庭管理者在控制台单独二次授权;同时,官方条款严禁开发者将调用过程中获得的家居遥测数据用于 AI 模型的后续训练。

针对物理状态同步的滞后问题,Home MCP 设计了 DEFAULT、STALE_READ 和 MOST_FRESH 三种数据新鲜度模式。针对插座或温度传感器,系统允许读取带有延迟的缓存读数;但对于门锁开闭等涉及核心安全的敏感状态检查,接口强制使用 MOST_FRESH 策略,强行绕过所有中间缓存层,直接穿透到底层硬件获取实时物理状态。

  • 风险.将家庭中枢接入第三方 Agent 会让全家成员的起居节奏暴露于指令注入攻击之下,且儿童与访客往往在毫不知情的状态下被动交出数据。

四大阵营分化:协议开放背后的生态防守

在过去十年中,智能家居领域充斥着各自为政的私有协议。Apple 依赖严格审查的 HomeKit,Amazon 依靠 Alexa 技能树,Google 则依托 Assistant 的硬编码卡片。随着 Anthropic 推出的 MCP 协议在大模型开发领域快速普及,智能家居的交互入口迎来了剧烈洗牌。

四大主流平台在面对开放协议时走向了截然不同的技术路线(示意图)
四大主流平台在面对开放协议时走向了截然不同的技术路线(示意图)
四大智能家居生态的 AI 架构分化 Google Home 云端 MCP 服务端 月费 20 美元门槛 严格限制物理动作 Amazon Alexa+ MCP 消费端集成 重点消耗外部工具 维持零售中枢属性 Apple Home 私有云计算 (PCC) 完全端侧加密保护 拒绝第三方直接调用 Home Assistant 本地双向 MCP 协议 零月费开源方案 完全由用户自主控制

主流阵营就此出现了截然不同的选择。Apple 选择依靠 Private Cloud Compute 将一切锁在端侧硬件与专属加密通道内,不给通用外部 Agent 开放直接控制权;开源的 Home Assistant 走通了纯本地局域网的 MCP 双向交互,受到追求绝对控制权的极客青睐;Amazon 试图让重塑后的 Alexa+ 成为调用外部服务的客户端;而 Google 则是第一家把自己积累多年的家庭拓扑与设备网络包装成云端 MCP 服务端的平台巨头。

这种策略的深层意图在于守住分发权。与其等待大模型通过各种逆向插件绕过生态壁垒,不如主动交出一根带有安全阀的标准化管线,把开发者和高端用户的算力请求留在 Google Cloud 之上。

  • 建议.普通家庭用户完全无需为这项早期功能支付每月 20 美元,等待系统放开自动化配置权限,或者观察竞对是否会把 MCP 下放到标准版免费生态中,才是当下更理性的做法。