一句话总结
Google 在 9 月 16 日为 Google Home 开放了 MCP 服务器的早期访问：任何支持 MCP 的 AI Agent 在完成 OAuth 授权后，就能查询家庭结构、列出设备与指令、读取实时状态、执行控制动作、检索历史事件——官方文档给出的是一套 5 个工具的标准接口。同时它把边界写在了警告框里：开锁这类敏感动作被直接禁止，接口有速率限制，授权可以随时撤销。
数据来源
本文事实依据：
- Google Home Developers 官方文档《Google Home MCP Server》（Early Access，2026-09-16）
- TechCrunch《Your AI agents can now control your Google Home devices》（2026-09-16，作者 Sarah Perez）
- Google Home and Nest 社区公告《Introducing Home MCP: enabling your agent to interact with your home》（2026-09-16）
这次开放了什么：一条从「一句话」到「关灯」的链路
MCP（Model Context Protocol，模型上下文协议）是让 AI 应用安全访问外部数据源与工具的开放标准。以前的玩法是开发者自己写胶水代码调 Google Home API，现在是Google 把一套标准工具端出来，任何 MCP 客户端接上就能用。
关键参数（官方文档原文口径）：
- 服务器地址：
https://home.googleapis.com/mcp（配置引导中会先给出预发布沙箱地址） - 传输方式：SSE
- 授权方式：OAuth 2.0，作用域
https://www.googleapis.com/auth/home.platform.v2 - 官方点名的客户端：Google Antigravity、Claude Cowork、OpenClaw；TechCrunch 报道中还提到 ChatGPT、Hermes 等支持 MCP 的 Agent
5 个工具，分别能干什么
官方文档把核心能力拆成五块，工具名就是接口名：
| 工具 | 官方定位 | 人话版 |
|---|---|---|
list_homes | Structure discovery | 我名下有哪些家、哪些结构 |
list_home_resources | Resource discovery | 有哪些设备、房间布局、支持哪些指令 |
list_home_states | State monitoring | 设备现在连没连上、状态是什么 |
run_home_actions | Device control | 执行带参数的控制指令（开灯关灯等） |
list_home_history | Historical analysis | 查某个时间段发生过什么 |
官方给的示例问法非常「生活化」，也基本说明了产品经理心里的目标场景：
- 实体发现：「我家有多少盏灯？」
- 实时状态：「我家现在是安全状态吗？」
- 设备控制：「把室外的灯全关掉。」
- 历史事件：「我不在家的时候发生了什么？」
覆盖面包括 Google Nest 门铃与恒温器，以及所有 “Works with Google Home”（或 Matter）生态设备。
接入流程：四步，门槛在云端不在设备端
- 建 Google Cloud 项目，在 APIs & Services 里搜索并启用 Home API。
- 配置 OAuth 同意屏与凭据：受众选 External，应用类型 Web application，并填入目标客户端的回调地址——文档里直接给出了两个例子：Antigravity 用
https://antigravity.google/oauth-callback，Claude Cowork 用https://claude.ai/api/mcp/auth_callback，OpenClaw 用本地安装指定的重定向地址。填完记得把应用发布（Publish app）。 - 把 MCP 配置交给你的 Agent。文档给了一条很「2026」的路径：直接把配置信息粘进对话，让 Agent 自己配好；也给了 Antigravity、Claude、OpenClaw 三种手动配置写法。
- 完成 OAuth 授权并验收：在浏览器里选家庭结构、授予权限，然后用「关掉室外灯」这类指令试跑。
验收环节其实是一次能力自检：能回答「我家有多少盏灯」说明实体发现通了，能回答「我不在的时候发生了什么」说明历史查询通了。
安全边界：官方把风险写在了警告框里
这次最值得读的其实不是功能列表，而是官方那段 warning。它的要点是：把一个真实的家接给 AI Agent，等于把设备控制权交出去。
- 敏感动作被直接禁止：文档明确点名「开锁」（unlocking doors）这类操作不允许通过 MCP 执行。
- 有速率限制：接口层面做限流，避免 Agent 异常时疯狂刷指令。
- 同住成员需要知情：如果这个 Google Home 还有别人在用，官方建议你告知他们「你的 Agent 可以控制设备、访问家庭数据」；否则更稳妥的做法是另建一个家庭结构专门做开发测试。
- 授权可随时撤销：在 Google Home App 或 My Accounts 页面随时收回访问权。
- 「熟悉面孔」要单独同意：想访问 Nest 摄像头的人脸识别数据，需要走独立的 consent 流程——且要求授权人是结构管理员、至少有一台兼容的 Nest 摄像头/门铃，并开启 Familiar face detection，链接需要用你自己的 OAuth Client ID 与结构 ID 拼接生成。
这段设计其实很像本周另一条新闻的产品哲学：先给出可控的自主，再谈能力边界。
门槛在哪：订阅 + 地区 + 一个 Cloud 项目
- 订阅：需要 Google Home Premium Advanced，美国区定价 20 美元/月——这是该服务的较高档订阅，包含更长的录像历史、描述性通知、视频历史搜索、每日摘要等能力。
- 地区：早期访问先在美国向该档订阅用户滚动开放。Google 对「是否以及何时扩展到其他订阅档位或市场」不予置评。
- 技术前置：家中有已接入 Google Home 的设备、一个 Google Cloud 项目、以及一个支持 MCP 的客户端。
- 反馈渠道：Google 表示会在 Smart Home for Developers 社区收集早期用户反馈。
为什么这件事值得单独写一篇
第一，MCP 从「开发者工具」跨进了「消费者设备」。 过去一年 MCP 的主要战场是 IDE、命令行、企业数据平台；这次接上的是家里的灯、门铃、恒温器。协议没变，但用户画像彻底变了。
第二，智能家居的竞争焦点从「语音助手」变成「谁的 Agent 能接管」。 以前比的是唤醒词识别率与设备兼容数量；现在比的是能否被第三方 Agent 调用。Google 把 Home 变成 MCP 服务端，等于把自己从「唯一的控制者」转型成「能力的提供方」——这对生态是好事，对自家的 Gemini for Home 则是新的竞争压力。
第三，家庭数据的隐私边界第一次被写成产品流程。 「同住成员需要被告知」「熟悉面孔需单独同意」「授权可撤销」这三条，比任何一份隐私政策都更具体。智能家居 Agent 的真正瓶颈从来不是技术，而是家庭内部谁有权授权。
对国内用户的实际意义
- 短期用不上，但方向要记下。 美国区、特定订阅档、早期访问——三重门槛决定了这不是现在能上手的功能。
- Matter 生态是可迁移的经验。 文档覆盖面里明确包含 Matter 设备，国内厂商的 Matter 设备同样接入 Google Home，这条链路的技术前提是对齐的。
- 值得抄的是授权模型，不是功能列表。 自建智能家居 Agent 场景（例如本地 Home Assistant 类方案）里，「敏感动作白名单 + 速率限制 + 成员知情 + 可撤销授权」这四条是可以直接照搬的设计。
结论
Google 这次没有发布新硬件，也没有发布新模型，它发布的是一个标准接口：把家里的设备能力整理成 5 个 MCP 工具，然后用 OAuth、限流、动作黑名单与独立同意流程把风险框住。
如果本周两条新闻放在一起看——Anthropic 把 Claude 的入口合并成「一个 Claude」，Google 把家变成一个 MCP 服务端——会发现同一条主线：AI 正在从「你问它答」变成「你交任务、它办事情」，而所有厂商都在同一件事上较劲：如何把自主权交出去，又留得住最后一道控制。
相关工具
配图说明：正文两张截图来自 Google Home Developers 官方文档（公开页面），两张设备照片来自 Wikimedia Commons（CC BY-SA 4.0，已注明摄影者），示意图由 UU AI Hub 依据官方文档绘制。
