Google 把 MCP 服务器接到 Home 上：物理世界第一次有了通用调用接口
Google 向 Home 生态开放 MCP server，Claude、ChatGPT 等任何支持 MCP 的 agent 都能控制家里的灯和门铃。这件事的意义不在智能家居，在于 MCP 第一次跨出了代码与文档的边界，进入物理空间——但它给出的只是离散调用，不是机器人需要的连续控制回路。
- 动作：Google 于 2026-09-16（北京时间 9 月 17 日凌晨）向 Google Home 生态推出 MCP server 早期访问，支持 MCP 的 agent——Claude、Hermes、OpenClaw、ChatGPT、Google Antigravity——可安全操作智能设备并访问事件历史。
- 能做什么：自然语言指令查看摄像头摘要、监控活动、控制连接设备、自建智能家庭 dashboard。
- 覆盖范围：Google Home 生态内所有设备，含 Nest 门铃与恒温器，以及「Works with Google Home」或 Matter 设备（如灯泡）。
- 门槛：需自建 Google Cloud 项目并配置 Home MCP，再由 agent 引导登录授权；首期仅面向美国 Google Home Premium Advanced 订阅用户，该档 20 美元/月。
- 未定事项：Google 未评论是否向其他订阅档或市场开放；发布方更正过一次推送起始日（周三而非周二）。
9 月 16 日上午，Google 做了一件看起来很小的事：向 Google Home 生态开放 Model Context Protocol 服务器。任何支持 MCP 的 agent，包括 Claude、ChatGPT、Hermes、OpenClaw 和 Google 自家的 Antigravity，都能通过它操作用户的智能家居设备，并读取事件历史。
在此之前，MCP 的活动范围基本是数字世界：Google Cloud 的产品接口、数据平台、开发者工具、Workspace 套件。这次的差别不在功能多少，在对象变了——灯泡、门铃、恒温器是物理设备，开灯和关灯是对物理世界的实际作用。MCP 从「让 agent 读文档、调接口」跨到了「让 agent 动东西」。
可以这样理解它的位置：过去两年，agent 的能力边界停在了屏幕边缘。它能在浏览器里点按钮、在终端里跑命令，但屏幕之外的事情需要人类代劳。Google Home MCP 把这条边往外推了一格——agent 现在有了第一批廉价、标准化、可远程调用的物理执行器。
用户侧的用法被描述为四类：查看摄像头摘要、监控家庭活动、控制已连接设备、自建 dashboard。这些都不新鲜，智能家居 App 早就能做；新鲜的是调用方从人变成了 agent，交互语言从图形界面变成了自然语言。
Google Cloud 产品接口、数据平台、开发者工具、Workspace。
共同点：对象都在数字世界内，操作可逆、可重放。
Nest 门铃、恒温器、Matter 设备（灯泡等）。
对象进入物理世界：动作不可逆，误调用有实际后果。
必须把话说清楚：Home MCP 提供的是离散能力调用，不是机器人控制需要的连续控制回路。两者的差别决定了这个接口能做什么、不能做什么。
离散调用的模型是「发一个请求、等一个结果、拿到一个状态」——开灯、关灯、查询摄像头摘要。它是无状态的，每次调用之间不共享时序信息，时延由网络决定且不承诺上界。机器人控制需要的是另一套模型：以固定频率读取传感器、在几十毫秒内完成闭环、动作之间要保持状态连续。开灯晚 500 毫秒没人察觉，抓取动作晚 500 毫秒就是摔杯子。
所以 Home MCP 不能当作机器人控制层的替代品，它更接近一个任务层的触发器。这个区分很重要，因为行业里已经出现把「agent 能控制设备」直接等同于「agent 具备具身能力」的混用。能下发指令和能闭环执行，是两件事。
但这不削弱它的价值。恰恰相反，对被挡在硬件门槛之外的团队，智能家居是当前最便宜的物理世界试验场：一套 Matter 灯泡加一个 Nest 门铃，就能验证 agent 在真实环境里的意图理解、多轮纠错、异常处理和长程记忆——这些都是具身智能软件栈的真问题，只是换了执行器。
| 维度 | MCP 离散调用 | 机器人连续控制 |
|---|---|---|
| 时序 | 无状态，调用间不共享时序 | 固定频率闭环，状态连续 |
| 时延 | 网络决定，不承诺上界 | 数十毫秒级硬实时约束 |
| 失败后果 | 灯没开，可重试 | 抓取失败即物体坠落 |
| 反馈 | 返回状态字段 | 需要力/位/视觉连续反馈 |
| 适用场景 | 任务层触发、环境状态查询 | 动作层执行、接触类操作 |
这个早期访问的门槛比看上去高。
用户要完成三步：创建一个 Google Cloud 项目、把它配置为使用 Home MCP、把 MCP 配置信息交给所选 agent 并请求它完成设置，再由 agent 引导登录授权。这三步里，第一步就把绝大多数普通用户挡在门外——「创建云项目」是开发者动作，不是消费者动作。
第二道门槛是订阅：功能从发布当天起、在未来数周内推送给美国的 Google Home Premium Advanced 订阅用户，这一档的价格是 20 美元/月，提供的是更长的事件视频历史、描述性通知与详细告警、视频历史搜索工具、每日摘要等能力。也就是说，要用 agent 控制家里的灯，先得每月付 20 美元。Google 未评论是否向其他订阅档或其他市场开放。
把两道门槛叠起来看，这次早期访问的目标用户并不是「想用 AI 控制家里的灯的人」，而是正在做 agent 产品的开发者。Google 提供的是一块标准化的试验田和一份事实上的接口规范；真正的价值发生在 agent 那一侧——谁先把这套能力接进自己的产品，谁就拿到了家庭场景的第一手交互数据。
三条可以直接落地的结论。
第一，把智能家居当作具身软件栈的低成本验证环境。多轮指令纠错、环境状态记忆、异常恢复——这些能力在仿真里测不出来，在真机上测很贵，在智能家居上几乎免费。一套 Matter 设备的成本远低于一台机器人，而它暴露的问题（指令歧义、状态同步失败、长程任务中断）是真机上的同类问题。
第二，接口标准化会重构集成成本结构。过去每接一类设备就要写一套适配，现在厂商把 MCP server 端做好，agent 侧是统一协议。对做异构设备接入的团队（这也是本站长期跟踪的方向），这是一个明确的信号：设备侧的标准化正在由厂商自己完成，平台方的价值从「写适配」转移到「管权限、管编排、管审计」。
第三，权限模型会成为下一个真问题。用户把 OAuth 凭证交给 agent 代持，agent 又具备自主决策能力——凭证的作用范围、撤销粒度、操作留痕，这三件事目前没有公开的标准答案。Google 在开发者社区收集早期反馈，说明它自己也在这个阶段摸索。对任何要做设备接入的产品，权限设计应该排在功能设计之前。