过去十年，智能家居的接口一直是”只留给自家助手”的：Google Assistant、Siri、Alexa 各自圈一块地。
9 月 16 日，Google 把这块地开了一道门——Google Home 上线了 MCP Server 的早期访问。Claude、ChatGPT、OpenClaw 这些外部 Agent 第一次可以走进来，查摄像头事件、调恒温器、开关灯。
但同一份文档里还写着一句话：门锁不开放，任何 Agent 都不行。
先看开放了什么：五个 Agent，四类能力
Google 在发布时点名了五个已经测试并文档化的客户端：Claude、ChatGPT、Google 自家的 Antigravity、Hermes，以及 OpenClaw。技术上说，任何支持 MCP 并配好了 OAuth 凭据的 Agent 都能接，这五个是 Google 明确背书过的。
接上之后能做的事分四类：
- 设备控制：Nest 门铃、恒温器，以及所有”Works with Google Home”和 Matter 认证设备（灯、插座、开关）；
- 事件历史查询：不再需要手动拖时间轴，直接问”昨晚 10 点后有人到过前门吗”；
- 摄像头摘要：让 Agent 跨多个房间汇总摄像头画面，用自然语言回答具体问题；
- 自定义仪表盘：用一句人话生成一个面板，替代 Google 固定的那套 UI。
最后一条其实是被低估的。前面三条都是”把操作换个入口”，第四条是把界面的定义权交出去了——用户不再需要迁就厂商预设的那套布局。
怎么接上：四步配置，先建 Google Cloud 项目
这不是在 Google Home App 里点个开关的事。官方路径是开发者的活儿：
- 建一个 Google Cloud 项目，为 Home MCP 做配置；
- 在项目里启用 Home API；
- 配置 OAuth 同意屏（consent screen），为你要接的那个 Agent 生成 client credentials；
- 把 MCP 配置交给 Agent → 用 Google 账号登录 → 授予带范围的（scoped）权限。
Google 在 Home Developer Center 放了完整 setup guide。真实体验上，这套流程比”打开智能家居 App 点一下”重得多，更接近接一个企业内部系统。
还有一层门槛是钱和地域：Home MCP 需要 Google Home Premium Advanced 订阅，20 美元/月或 200 美元/年。Google AI Ultra 订阅用户自动包含这一档；AI Pro 用户默认拿到的是更便宜的 Standard 档，得单独升级。地域上目前仅限美国、仅英语，Google 没说什么时候扩到其他市场。
硬边界：门锁这一条，写死在协议里
这份文档里最值得单独拿出来讲的，是它明确拒绝的东西。
Google 的文档写得很直白：Home MCP 不提供开锁能力，无论哪个 Agent 请求、无论怎么请求。 没有权限申请流程、没有”高级模式”、没有隐藏开关。同时配了速率限制和认证控制。
在一个已经跑了一年半、安全记录并不漂亮的协议上，这算少见的一刀。想想 MCP 这一年多被念叨的问题：服务器不强制认证就上线、通过工具描述做提示注入、权限范围给得比需要的大。把同样一类工具从数据库挪到你家门锁上，风险等级完全不是一个量级。Google 选择在出事之前把这一条钉死，而不是先给能力再加一个警告标签。
对比一下国内的同类动作会更清楚：豆包手机当初被微信、支付宝集体拉黑，就是因为”硬闯”式调用——后来它改成先请 App 授权。授权边界这件事，现在中外厂商都在往同一个方向收。
一个值得学的设计：先划死线，再谈能力
从产品设计角度，Google 这次给出的模板值得抄下来：
大范围的读取与控制 + 一两条硬编码的拒绝 + 速率限制作为主要安全机制。
这个形状的聪明之处在于，它承认了 LLM 的不可控性，但没有因此放弃开放。它选择的不是”因为可能出问题所以不开”，而是”把绝对不能做的那件事先摘出去，剩下的开放”。
值得提醒的是速率限制的作用边界：它能挡住失控的循环调用，但挡不住一个已经通过认证的 Agent 老老实实照着一个坏提示词执行。这恰恰是今年所有 MCP 安全分析里反复出现的失效模式。所以对物理世界的 MCP Server 来说，硬性能力禁令的价值高于速率限制。
风险在哪：MCP 的老毛病没有先解决
必须说清一件事：Google 开放的是连接方式，不是安全性。
外部 Agent 能看到的东西里，最敏感的不是灯，是摄像头画面、在家与不在家的规律、进出记录。一个能跨全屋回答”谁什么时候到过门口”的 Agent，一旦被攻破或者只是被配错，泄露的就是一份够用来跟踪人的数据集。
给想上手的人两条实操建议：
- 先接设备控制，别急着把摄像头历史交出去。 控制灯和恒温器的风险可逆，摄像头的历史不可逆。
- 给自己留几周观察期。 早期访问的存在意义就是让问题在铺开之前暴露，让别人先踩。
顺带澄清一个容易混的概念：Google 同时还有一个 Home Developer MCP，那是给 Google Antigravity、Claude Code、Cursor、GitHub Copilot 这类编码工具喂 Matter 规范和 API 文档用的，帮你写智能家居集成，不是用来开你家灯的。名字像，用途完全不同。
优缺点、适合人群与替代方案
优点：
- 打破了智能家居”一家助手锁死一个生态”的老格局，用户第一次可以在 Google 的设备层上跑别家的 Agent；
- 权限模型有 OAuth 和范围控制，审计路径比私有协议清晰；
- 对开发者友好：不用再为每个品牌单独写集成，一套 MCP 规范接完。
缺点：
- 门槛高：Google Cloud 项目 + OAuth + 付费订阅，普通家庭用户基本劝退；
- 地域限制死：仅美国、仅英语，国内用户短期用不上；
- 底层协议的安全问题（提示注入、权限范围偏粗）并未因为这次开放而解决；
- 能力边界可能变动，官方也提示权限模型在早期会反复调整。
适合人群： 愿意折腾自建智能家居、同时已经在用 Claude 或 ChatGPT 的重度用户；以及做智能家居集成的开发者——这次开放的权限模型和接口设计，比起能不能用，更值得拿来当参考模板。
替代方案：
- 想留在官方体系里，就继续用 Gemini for Home，它是内置的默认语音界面，也是最省事的选择；
- 想要更彻底的自托管和跨品牌控制，Home Assistant 生态里的 MCP 方案更灵活，代价是全部自己维护；
- 只想把”AI + 物理设备”这件事跑通一次，可以先用腾讯开源的 BrowserSkill 这类浏览器层方案热身，成本低、可逆、不用碰硬件。
如果你是第一次接触 MCP，可以先读这两篇打底：MCP 协议无状态化改版讲的是协议本身为什么必须改，OpenAI 的 WebMCP讲的是网页怎么把自己变成工具接口——加上这篇的物理设备层，三段拼起来，MCP 从数据库到网页再到家里的路径就完整了。
老达点评
这次发布最容易被写偏的地方是”我的恒温器会听 Claude 的了”。那是演示，不是重点。
重点是 Google 做了一个价值判断：它承认自己在”一个助手统治你生活”这场仗里赢不了，于是选择做管道。 设备层我提供，智能层你们随便来。这在商业上是示弱，在战略上却可能是长期最稳的位置——路由器不需要赢过上面跑的应用。
但我想把一句提醒放在最后：硬性禁令比速率限制值钱，这条经验值得所有做 Agent 集成的人抄走。
不要等 Agent 找到一个聪明的问法才去补丁。在动手之前，先坐下来写清楚”这个集成绝对不做什么”。Google 选的是”开锁”，你的集成里对应的那件事是什么？发布之前想清楚，比出事之后再想便宜得多。
如果你是团队里负责这块的人，AI 工具评测专题和 AI 智能体与自动化专题里还有更多”Agent 接入真实系统”的案例可以对着看。
