大家追问的那件事，Google 挡住了：通过 Home MCP 接进来的智能体，开不了你家的门锁。而这台服务器的五个工具里有四个是读，其中一个会把一份可查询的日志交到第三方智能体手上——动静、有没有人在家、门什么时候开过，时间窗任它开口；那里没有对应的闸门，因为没人写下过「敏感的读」是什么。能被人想象出来的那个执行风险，恰恰是有边界、看得见、且多半可撤销的那个。读的那个风险，一条都不占。
一览
整个接口面，按那个决定你该怎么推理它的形状摆出来。
| 工具 | 方向 | 返回什么／做什么 |
|---|---|---|
list_homes | 读 | 智能体够得着哪些家庭与结构 |
list_home_resources | 读 | 设备、区域布局、trait、属性、命令 schema |
list_home_states | 读 | 实时连接状态与当前 trait 状态 |
list_home_history | 读 | 指定时间范围内的历史状态变化与事件日志 |
run_home_actions | 写 | 对目标设备执行带参数的动作命令 |
Google 在 9 月 16 日上了什么
Home MCP 是面向 Google Home 生态的一台 MCP 服务器，于 2026 年 9 月 16 日开放早期访问。一个会说 MCP 的智能体可以发现账号下的结构、枚举设备及其命令 schema、读取实时状态、查询事件历史，并执行命令——覆盖 Nest 门铃与恒温器，以及任何 Works with Google Home 或 Matter 设备。
关于这次发布的形状，有三件事值得记住。
- 它明确是给 Google 管不着的智能体用的。Google 自己举的例子点名了 Google Antigravity、Claude、Hermes 与 OpenClaw。这不是一个套了 MCP 壳的 Gemini 功能；这是一个第一方界面，从设计上就准备好让第三方模型来驱动。
- 它被钱和麻烦挡了一道。早期访问面向美国的 Google Home Premium Advanced 订阅者，语言为英语——每月 20 美元或每年 200 美元——而配置过程要求你起一个 Google Cloud 项目、启用 Home API、创建 OAuth 同意屏与客户端凭据、发布应用，然后把 MCP 配置交给你的智能体。
- 确实有安全限制，而它们装在写这一侧。服务器会施加速率限制并阻止敏感动作；Google 给的例子是：智能体不得开门锁。
最后这个决定是对的，值得记一功。开锁是唯一一个「模型出错」与「物理安防失守」属于同一事件的动作；干脆不暴露它，好过把它放在一个疲惫的人随手就点掉的确认框后面。在写这一侧，Google 把线画在了对的位置上。
而写这一侧，并不是这个接口面的大头。
四比一这个比例，才是正题
执行是人能在脑子里画出来的那个风险，而这恰恰是它可控的原因。开一盏灯是有界的——设备数量有限，每台设备的命令有限，每条命令都能用相反的那条撤回。它是可读的：你会注意到。它是可归因的：状态在某个时间戳变了，旁边挂着调用者。而最坏的那些情形是可枚举的——正因如此，Google 才写得出一份阻止清单。
现在把 list_home_history 拿来对同样这四条性质。
它没有边界
一次状态读告诉你这个家此刻是什么样。一次在选定范围上的事件历史查询，告诉你的是这个家一直以来是什么样——哪些灯几点亮起、前门什么时候开过、动静什么时候停下、哪几天家里没人。一次宽窗口的调用返回的是一份行为记录，任何单张快照都重建不出它。「读一下恒温器」与「读六周的门事件」之间的体量差距，不是两倍的关系。
它不可撤销
一次错误的执行可以纠正。一次读没法「读回去」。一旦六周的在家／不在家数据进了某个智能体的上下文窗口，它就进了这个智能体接下来做的每一件事：一份摘要、一次记忆写入、可观测后端里的一条 trace、模型提供方的日志、一次调试导出。要紧的边界不是那次 MCP 调用；而是它下游的每一个系统，而这些 Google 一个都看不见。
它没有阻止清单，而且也不容易有
「不许开门锁」写得出来，因为开锁是一个有名字的动作。而真正要紧的那个读，没有对应的名字。「别告诉智能体家里什么时候没人」不是一条能被阻止的命令——它是智能体从一堆单看都无伤大雅的事件数据里推出来的结论。日志里的每一条事件都很无聊。敏感的那个对象是模式，而模式不是服务端白名单拒得掉的东西。
这是一种普遍的不对称，不是 Google 独有的毛病。每一次把智能体接进一套记录系统，都会有一个被人认真琢磨过的写面，和一个「因为读起来感觉安全」就发出去的读面。读之所以感觉安全，是因为在没有智能体的世界里，读的那一方是一个有屏幕、且胃口有限的人。而现在读的那一方，是一个会乐呵呵地把 API 允许的上限拉满、做成摘要、再把摘要带去别处的进程。
动作空间是被发现的，不是被声明的
这份设计里还有第二个结构性的点，而它传播得越远就越要紧。run_home_actions 执行的是带参数的命令，而参数来自 list_home_resources 在运行时逐设备、逐 trait 报出来的命令 schema。
所以智能体可用的动作集合，并不是这台 MCP 服务器的属性。它是「你今天下午插了什么进去」的属性。买一个支持 Matter 的百叶帘、配对上，你那个智能体的动作空间就长大了一圈——而你整条技术栈里没有发生过一次部署、一次评审，或者一次版本号变更。
对任何想在这上面套策略的人来说，这就是全部的难处。你没法事先写一份动作白名单，因为你事先并不知道有哪些动作。你写得出来的，是一份针对 trait——也就是能力类别——的策略，外加对任何策略没见过的 trait 一律默认拒绝。这与「这是我们批准的十二个工具」在控制设计上有实质区别，而这个界面逼着你用后面那种。只要工具目录是动态的，这个问题就会冒出来；工具目录生命周期是它的运维形态。
乐观的读法是：物理环境一向如此运作，只不过软件现在才追上来。现实的读法是：一份环境权限式的授予——一个 OAuth 令牌、所有设备、全部历史——正被交给一个长期存活的进程，而它的能力集合会在有人买了一盏灯的时候改变。
事件历史是不可信输入
真正会先抵达生产环境的风险，不是一个恶意的智能体。是一个正确的智能体读到了被投毒的数据——而一个家在生产这种数据上出奇地在行。
- 设备名是攻击者可供的字符串。任何能在这个账号上添加或重命名设备的人，都控制着一段会落进智能体上下文的文本。一位客人、一个装修工、一个前租户、一个被攻陷的第三方集成。把设备名起得像一条指令，是 MCP 反模式目录里最老的一招；而这里，命名这个接口面属于一个从未做过对抗性输入评审的消费级应用。
- 摄像头与门铃事件本身就是模型输出。一段描述摄像头看到什么的事件摘要，自己就是生成出来的文本。把一个模型的描述喂进另一个模型的上下文，这是一条供应链；而上游那个模型完全不知道自己的输出会被一个握有工具权限的东西当作事实来读。
- 那份历史就是踩点。一旦真有一条注入的指令落了地，承载它的那条连接，同时也承载着这户人家的作息表。不可信文本 + 行为记录 + 执行工具，这个组合就是完整的闭环；而把遥测当作不可信输入正是它所属的那个模式。
这里头没有哪一条需要谁做错了事。这只是「一个为手机应用而建的数据源，变成了一个会动手的程序的数据源」之后会发生的事。
最强的反驳
Google 本来就有这些数据。Nest 摄像头、门铃与恒温器把事件历史往 Google 的基础设施里送已经送了十年，而 Home 应用在手机上给你看的就是同一条时间线。加一个 MCP 端点并没有制造新的隐私暴露；它只是把一份你在买下那个门铃时就已经接受的暴露又摆了一遍。
关于数据，这话是对的；关于暴露，这话是错的，原因只有一个：接收方变了。那份历史上原有的每一道管控——Google 的保留策略、它的访问控制、它面对法律程序的姿态、它公开作出的承诺——约束的都是 Google。而一份已经被交到某个智能体手上的副本，身上一道都不带；那个智能体由另一家公司运营，适用另一份隐私政策，很可能还在另一个司法辖区。
而且这份授予很粗。一个人在这里点下同意，同意的是「我的智能体可以使用我的家」，听上去像是那个开关灯的故事。而那个令牌实际赋予的，是一项长期的、只能整体撤销的权利：读取住在这里的所有人的行为历史。这是两份不同的同意，而消费级 OAuth 屏幕并不是一件适合把它们分开的仪器——为什么「授予了什么」的记录与授予本身同样要紧，见委托访问与同意记录。
这个反驳确实在一处站住了脚，值得承认：与其说这是一项新能力，不如说这是一项新近变得方便的能力。相应地，修法也就朴素：不是「别发」——是把作用域拆开。
该怎么做
如果你这周就要把智能体接进自己家
- 能用一个单独的 Google 账号做这个集成就用。只把最小必要的设备共享进去。这里爆炸半径的单位是账号，那就把账号做小。这是把爆炸半径用在一栋房子上。
- 默认历史才是敏感的那部分，并照此行事。要窄时间窗。不要让一个长期运行的智能体带着「可以定时、无需提示地去查历史」的常设权限。
- 搞清楚那段记录去了哪里。如果你那个智能体的提供方会为滥用监控或训练而保留对话，那你的门事件日志就落在那份策略的范围里，而不是 Google 的策略里。
- 把设备名起得无聊一点。这不花钱，却拿掉了这套系统里最廉价的那个注入面。
- 看看这个账号上还有谁。一个家是多人的，一份 OAuth 授予不是。凡是被传感器记录了行踪的人，在这里都是数据主体，而他们谁都没看见那块同意屏。
如果你在为一套记录系统设计智能体接口面
- 给读定作用域，要像给写定作用域一样上心。历史查询配得上自己的 scope、自己的速率限制、自己的同意文案。「读当前状态」与「读半年历史」不该是同一项权限，而今天在几乎每一个产品里，它们就是同一项。
- 返回窗口，不要返回消防水管。在服务端给历史查询的宽度设一个上限，是一行就能写完、却能扛住下游每一次失误的管控。让智能体想要更多就再问一次，并把「它又问了」记下来。
- 把策略写在能力类别上，而不是工具名上。如果你的动作集合是运行时发现的，基于名字的白名单就是装饰。对未知类别一律默认拒绝——见 MCP 工具设计。
- 把阻止清单的内容公开。「敏感动作已被阻止」是不可审计的。一份具名、带版本的清单，是运营方能拿来搭东西、研究者能拿来核查的东西；这也正是「一条安全性质」与「一句安全主张」之间的差别。
如果你只从这次发布里带走一样东西，就带走这个要拿去问自家集成的问题：我的哪个读工具，返回的东西聚合起来比它任何一行都更敏感？那就是那个身上没有闸门的工具——而你几乎肯定有一个。
常见问题
AI 智能体能通过 Home MCP 开我家的门锁吗？
不能。Google 会施加速率限制并阻止敏感动作，而它举的被阻止动作的例子正是开门锁。这份阻止清单作用在写工具 run_home_actions 上。
Home MCP 要多少钱，谁能用？
早期访问面向美国的 Google Home Premium Advanced 订阅者，语言为英语，并在随后的几周内逐步放开。该档位每月 20 美元或每年 200 美元。配置还要求一个启用了 Home API 的 Google Cloud 项目，以及创建好的 OAuth 凭据。
哪些智能体能连？
任何具备 MCP 能力的客户端。Google 自己举的例子点名了 Google Antigravity、Claude、Hermes 与 OpenClaw——这才是值得注意的部分：这个界面是为 Google 并不运营的智能体设计的。
既然执行被设了闸，还有什么好担心的？
那些读。list_home_history 返回你所选时间范围内的历史状态变化与事件日志，那是一份关于这户人家的行为记录。它确实有速率限制，但没有「敏感读」的阻止清单，读也撤不回来；而这些数据在进入第三方智能体上下文的那一刻，就离开了 Google 的掌控。
Google 为什么不干脆把敏感的读也挡掉？
因为敏感的那个对象是模式，不是某一行。单看每一条事件——一盏灯亮了、检测到动静、一扇门开了——都无伤大雅，而「家里什么时候没人」是在这个集合上的一次推断。服务器拒不掉一次推断；它只能给窗口设上限——正因如此，一个宽度限制才是真正帮得上忙的那道管控。
这比我已经在用的 Google Home 应用更糟吗？
数据是同一份；接收方不是。Google 的保留、访问控制与法律承诺约束的是 Google 手里那份副本。它们不会跟着那份被交给另一家公司、适用另一份政策的智能体的副本走；而那份 OAuth 授予也并不把「控制我的设备」与「读取我家的历史」分开。
延伸阅读
本站：
- 智能家居与 IoT 智能体——在这一类界面上开发，先做读路径。
- 把遥测当作不可信输入——为什么一份事件日志是一条注入通道。
- 物理执行安全——写的那一侧，怎么做才算做对。
- MCP 安全反模式——包括工具目录里由攻击者控制的名字。
- 环境权限——一个长期存活的令牌究竟赋予了什么。
- WebMCP 把你的页面变成了 API——换一个界面的同一个问题。
信息来源：
- Google Home Developers — Home MCP Server
- TechCrunch — Your AI agents can now control your Google Home devices
- Engadget — Google Home is going agentic via integration with the MCP standard
- 9to5Google — Google Home MCP lets Antigravity, Claude, OpenClaw and more control your smart home
- Model Context Protocol — 2026-07-28 规范