一个协议同时进了两端：用户侧与开发者侧
9 月 16 日，Google 宣布开放 Home MCP 的早开，这是一台开放的 Model Context Protocol 服务器。它做的事情说起来简单：让支持调用 MCP 工具的智能体，能够与 Google Home 生态中的设备以及事件历史交互。
更值得注意的是同一天发布的另一样东西。除了面向终端用户的 Home MCP，Google 还推出了 Home Developer MCP，后者的服务对象是编码工具——它把 Home API 完整参考与集成指南、Matter 规范，以及 OpenThread 与 Thread 的文档，直接喂给开发环境。按 Google 的说法，两者分工是：Home MCP 让个人智能体安全地与家居交互，Home Developer MCP 把技术资料直接送到编码工具里。
把两个服务器并排看，这次发布的实质就清楚了：Google 同时开放了「能操作什么」和「怎么开发」，把智能家居从一整套只对自家助手开放的接口，变成了一个对第三方智能体可编程、对第三方开发者可对接的环境。
接入侧的支持范围，官方点名的智能体包括 Google Antigravity、Claude、Hermes 与 Open Claw。Home Developer MCP 支持的工具更宽，含 Google Antigravity 套件（CLI、Antigravity 2.0 与 IDE）、Claude Code、Cursor，以及 VS Code 中的 GitHub Copilot。
四类能力与一句大白话
Google 的 MCP 服务器总览页把 Home MCP 的能力归纳为四块：实体枚举，列出某个住所内的房间与设备；实时状态监控，查询设备当下的状态，例如是否在线；设备控制，执行带参数的动作；历史分析，查询过去的状态与按时间排序的事件日志。每一类都配了示例提示语，比如「家里有多少盏灯」「房子是否已布防」「我不在家时发生了什么」。
官方给的使用场景也沿着这四类展开。一个例子是问智能体孩子放学回家后做了什么，智能体从各处摄像头汇总出摘要并附上相关片段；另一个是用设备状态历史统计一周洗了几次衣服、灯开久了多久；还有让智能体在完成某个异步或主动任务后，通过 Google Home 音箱播一条语音提醒；以及按个人偏好拼装自定义的家居看板。
几类能力里，历史分析是最容易被低估的一项。设备控制本身早已存在，只是入口不同；而把「过去发生了什么」做成智能体可查询的结构化数据，意味着智能体得以对物理环境做时间维度上的推理——这对家庭场景的自动化是必要前提。过去顺序触发的规则只能表达「如果门开了就开灯」，而无法表达「如果这周洗衣服的次数比平时多」。
设备范围：Matter 让这件事超出了 Google 自家硬件
Home MCP 支持的设备范围不限于 Google 自有产品。官方说明覆盖 Google Nest 门铃与恒温器，以及带有 Works with Google Home 标识或采用 Matter 标准的设备，例如灯泡。
这一点让发布的意义超出了 Google 的硬件生意。Matter 的设计目标就是跨平台互通，当智能体通过 MCP 访问一个兼容 Matter 的设备时，它访问的并不必然是一台 Google 生态专属设备。换句话说，Google 在这里提供的更像一层公共的智能体接入面，而不是自家产品的专属增值功能。这对整个智能家居行业的影响，可能比 Google 自身能获得的收益更大。
授权与隐私：OAuth、结构管理员与熟悉面孔数据
把家居环境的控制权交给第三方智能体，授权设计是绕不过去的部分。按官方用户指南，接入需要几个前置条件：一个已连接设备的 Google Home 家庭、Advanced 订阅、一个 Google Cloud 项目，以及一个兼容 MCP 的 AI 客户端。
配置流程依次是：创建 Cloud 项目、启用 Home API、为外部受众设置 OAuth 同意屏幕、创建带重定向 URI 的 Web 应用 OAuth 客户端 ID、发布应用。服务器地址为 home.googleapis.com/mcp，使用的 OAuth 权限范围为 home.platform.v2。Google 提供了针对 Antigravity、Claude Cowork 与 OpenClaw 的分步指引。
有一类数据需要单独同意：熟悉面孔信息。家庭结构的管理员必须显式授权，且住所内至少需要有一台启用面孔识别功能的兼容 Nest 摄像头或门铃。这条设计把最敏感的一类生物特征数据从默认授权里摘了出来，是个合理的处理；但它同时意味着这类数据的授权粒度是按家庭结构而非按智能体来管理的，不同智能体之间的隔离程度官方并未展开说明。
边界：不能做什么，以及为什么它不是默认能力
官方在公告与用户指南中都提到，Home MCP 会执行速率限制与安全保护，其中包括禁止开锁一类的敏感动作。
这条限制很重要。智能体接入物理世界的主要风险不是它读错数据，而是它对物理设备执行了不该执行的动作。把开锁划在能力之外，是把这个风险最集中的那类操作先排除掉。不过需要指出的是，禁止清单是否只有这一类、清单会不会随版本变化、以及误触发时是否有回滚机制，官方均未完整披露。
另一处边界是可用范围。早开阶段仅面向美国订阅 Google Home Premium Advanced 的用户，该档位月费 20 美元或年费 200 美元，包含 60 天基于事件的视频历史、10 天摄像头与有线门铃的 24 小时连续录制、描述性通知、视频历史搜索、事件描述与每日摘要等能力。Google 对是否、何时扩展到其他档位或其他市场不予评论，并在开早期通过其智能家居开发者社区收集反馈。
这说明它当前是一种面向愿意折腾的用户的实验性能力，而不是面向全部家居用户的默认功能。考虑到需要通过 Google Cloud 项目与 OAuth 配置才能接入，参与者大概率集中在开发者与重度用户群体。
对做 Agent 的人意味着什么
这次发布对智能体开发者的意义，可以从三个层面看。
接口层面，家居生态从此成为智能体可通过标准协议访问的一个系统，无需厂商单独定制的集成。这意味着把家居上下文接入自有对话或工作流界面的成本大幅下降。
能力层面，「读取状态历史 + 执行动作」的组合让基于真实发生情况的主动式任务成为可能。前面提到的语音播报场景就是一个例子：智能体完成一项耗时任务后，不再只能等用户打开应用查看，而是可以主动在环境里发出提示。
风险层面，把有物理后果的动作授权给智能体，对授权范围、提示注入暴露面、动作确认、审计日志与撤销路径的处理，都从加分项变成了必答题。官方对速率限制与禁止开锁的说明回应了其中一部分，但诸如动作是否需逐次确认、日志保留多久、权限如何回收等问题，仍需开发者自行设计。
值得注意的是，Google 并未把这件事当作单纯的消费者功能来推。它此前已在云与数据平台、开发者工具、Workspace 等业务里支持 MCP，家居只是新增的一块。当一家公司把 MCP 从开发者工具延伸到家庭物理设备时，实际上是在把 MCP 从工程协议推向通用基础设施——这个定位的抬升，比任何单个功能都更值得关注。
结语
把智能家居开放给第三方智能体，字面上是一次接口开放，实质上是让物理环境成为智能体的可编程对象。Google 这次的克制体现在两处：把开锁排除在能力之外，把最敏感的熟悉面孔数据放进单独同意；它的野心则体现在另外两处：不区分自有硬件与 Matter 设备，以及同时开放开发侧文档。接下来真正决定这件事价值大小的，不是有多少智能体能连上，而是当数十个来源不同的智能体都能读取同一户人家的设备状态历史时，权限、审计与责任如何被厘清。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。