2026 年 7 月，亚马逊在 Alexa+ 上开了 MCP；9 月 16 日，Google 把整个 Google Home 开放给了外部 Agent；Home Assistant 从 2026.9 版本起，把 MCP Server 做进了系统设置里。
三家路径不同、动机不同，但都指向同一件事：AI 调用家庭设备的方式，从“一个个 API”变成了“一组可被理解的工具”。
对国内厂家来说，这件事的难点从来不是“要不要接 MCP”，而是三件更现实的事：家里同时跑着 Zigbee、Wi-Fi、蓝牙 Mesh、PLC 和 KNX；一个网关动辄几百台设备；而你能暴露给模型的东西，远比你以为的少。
协议这场仗已经打完了，只是没人宣布结果。真正在发生的是：协议下沉成物理层，能力上浮成语义层。
一、同一件事，三种开法
先把三个平台各自开了什么说清楚。很多解读把它们混为一谈，实际上它们解决的是完全不同的问题，对应厂家的投入也完全不同。
1. Google：把“家”开放给外面的 Agent
Google 在 2026 年 9 月 16 日开始早期访问 Home MCP。开着之后，任何支持 MCP 工具的 Agent——Claude、ChatGPT、Google 自己的 Antigravity，以及 Hermes、OpenClaw 这类第三方 Agent——都能读到 Google Home 里的设备和事件历史，并且下达控制指令。
能做的事很具体：跨摄像头分析（“孩子放学回家后做了什么”）、查设备状态历史（“这周洗了几次衣服”“灯开了多久”）、通过 Google Home 音箱播报语音、用日常语言生成自定义仪表盘。
限制也很清楚：仅美国、仅 Google Home Premium Advanced 订阅用户（约 20 美元/月）、仅英文、需要自建 Google Cloud 项目并手动把配置交给 Agent、逐步放量。
要注意一个容易混淆的地方：Google 同期还发布了另一个东西叫 Home Developer MCP，那是把官方文档、Home API、Matter 规范做成一个“知识检索”服务，给 Cursor、Gemini CLI 这类开发工具用的。一个是给机器用的手，一个是给人的工具用的脑，不是一回事。
很多自媒体把两者混着写，会让厂家误判投入方向。Google 这条路的本质是：Google 自己做 MCP Server，把整个 Google Home 生态（含 Works with Google Home 和 Matter 设备）打包成一个工具集，卖给外部 Agent。
厂家在这条路上几乎没有主动权——你只要通过认证，就已经被包含在内了，不需要单独做什么。好消息是门槛低，坏消息是你的设备在 Agent 眼里和别人家的一样，只是“一盏灯”。
2. 亚马逊：让厂家自己交 MCP Server，平台帮你生成集成
亚马逊的动作分两步。2026 年 7 月 23 日，Alexa+ for Builders 上线，开出三条路：
① Category SDK：面向预订、票务这类标准化服务场景；
② MCP Toolkit：把你已有的 MCP Server 接进来，Alexa+ 会自动检查这个 server、提出集成路径、生成一个可直接进模拟器的包；
③ Smart Home AI Toolkit：从设备文档生成集成，让厂家把过去标准模板覆盖不到的高级能力暴露出来。第三条最值得国内厂家注意。
亚马逊举的例子是洗衣机：用户说“孩子的球衣要深度清洁，但标签写着只能冷水洗”，Alexa+ 自己去三十个程序里挑出“冷水酶激活 + 额外漂洗 + 低转速”。这种能力过去不可能通过固定指令模板实现，必须让模型理解设备的全部程序语义。
Alexa+ 首发 14 个品牌，中国品牌占近一半：
Bosch、Whirlpool、iRobot、Ecovacs（科沃斯）、Yale Home、Eufy（安克）、Tapo（普联）、Govee、SONOFF（易微联）、Delta、Moen Flo、PetSafe、Pila Energy、Twinkly。
亚马逊这条路的本质是：平台不替你建模，你交模型，它负责把你的模型翻译成对话体验。这比 Google 那条路对厂家更有利——因为能力是你定义的，差异化能保留下来。
顺带说一个治理层面的事实，很多人没注意：MCP 现在归 Agentic AI Foundation（Linux 基金会下属定向基金）治理，治理委员会主席是 AWS 的 David Nalley。
这意味着 MCP 不是某家 AI 公司的私有协议，亚马逊推它有主场优势。厂家押注 MCP，比押注任何一家的私有技能体系都安全。
3. Home Assistant：唯一双向、唯一可以不出云的一条路
HA 的做法和前两家都不一样，它同时做了三件事。
第一，HA 自己是 MCP Server。
从 2026.9 版本起内置“Model Context Protocol Server”集成，2026.10 版本把它挪到了“设置 → 系统 → AI”，多了一张卡片，一键开启，直接把 URL 复制走。它支持 OAuth 2.0 + PKCE，也支持 OAuth Client ID Metadata Documents，Agent 可以自动完成客户端注册。它暴露的工具只有八个，全是意图级的：
这八个工具是整篇文章最重要的一张表。它没有为每盏灯、每个开关各生成一个工具，而是用“一类能力一个工具 + 用 name/area 参数定位设备”的方式，把几万个实体压成了八个接口。这是解决工具爆炸的标准答案。
第二，HA 自己也是 MCP Client。
2026.10 版本起，如果某个应用自己跑着 MCP Server，HA 会自动发现，你确认一下就接上了。也就是说，HA 既能把家交出去，也能把外面的能力拉进来。
第三，也是最容易被忽略的：KNX 集成在 2026.10 版本自带了 AI 工具。
这套工具能做什么？查你 ETS 项目里的 group address、设备、功能；翻总线上电报的历史；解码你不认识的数值；甚至直接读写总线上的值。这些工具既可以给 HA 自己的对话 Agent 用，也可以通过 MCP Server 交给外部 AI 应用用。
这一条对国内的 KNX 代理商和集成商是重大信号：你们最值钱的东西从来不是那堆执行器，而是 ETS 项目文件里那套地址逻辑和十几年的调试经验。过去这套东西只能装在老师傅脑子里，现在它第一次变成了 AI 能读懂的上下文。
二、被忽略的门槛：一个全屋网关，会生成 1000 个工具
现在讲技术。这是决定“实施路径”长什么样的第一道关，也是 90% 的厂家第一次做 MCP 就会踩进去的坑。
MCP 的成本不在协议，在上下文
MCP 本身不复杂：JSON-RPC 2.0，三个原语——tools（可调用的动作）、resources（可读取的数据）、prompts（预设的提示模板），传输用 stdio 或 Streamable HTTP。一个后端工程师看两天文档就能跑通 echo server。
真正的问题是：每个工具的定义都会被塞进模型的上下文窗口，而且每一轮对话都要重新付一次钱。行业里实测出来的均值大约是每个工具 65 个 token（含名称、描述、完整的 JSON Schema）。
于是：一个中等规模的业务 API 暴露 270 个工具，约 17,500 token 在第一句话之前就烧掉了；同时挂三个这样的服务，就是 143,000 / 200,000 token，71% 的上下文没了。换算成钱：每天 1000 次请求、开销较重的情况下，光“加载工具定义”这一项大约是 170 美元/天、5,100 美元/月。比成本更糟的是质量。
有实测报告说，Claude 在工具定义超过 50 个之后，输出质量会出现肉眼可见的下降——开始跑题、开始引用工具而不是回答问题。
有个典型案例：挂了五个服务之后，Agent 面对一个数据库超时问题，非常自信地建议“创建一个 GitHub issue”。换算到智能家居，这个数字是什么量级一个 150 平方米的三居室，全屋智能的典型配置是 80—150 个设备节点。一个做 PLC 前装的别墅项目，主机两级级联可以接 2500 个设备。
按“一个设备五个能力”的朴素做法建模：
后一个数字已经不是“贵”的问题，是物理上装不进任何上下文窗口。在智能家居这个品类里，MCP 不是“给每个设备写一个工具”，那是必然失败的路线。厂家要做的第一件事不是写代码，是建模。
三种已经被验证的解法
解法一：能力族建模（服务端可控，最重要）。
回到 HA 那八个工具。它把“设备实例”这个维度从工具名里拿掉了，塞进参数：
对：HassLightSet(name=“客厅主灯”, brightness=60, color_temp=2700)
错：turn_on_living_room_main_light()
前者是能力，后者是实例。前者只需要一个工具，后者需要几百个。这个思路可以推广成一套建模原则，我把它总结成四句话：
① 按能力族建工具，不按设备实例建。灯、窗帘、温控、门锁、场景、查询，六个族就够覆盖绝大多数家庭。
② 设备用参数定位，用“区域 + 名称 + 别名”三级匹配。用户说“客厅的灯”，模型要能落到具体实体，靠的是给每个实体足够好的元数据，不是靠工具多。
③ 复合动作用“场景”封装，不让模型现场编排。“回家模式”是一个工具调用，不是四次调用。后者不但贵，中途失败还会留下半截状态。
④ 描述写得像给新员工的手册，不要像 API 文档。把 80 token 的描述压到 20 token，功能不变，省 75%。
解法二：渐进披露（客户端在做了，但你不能只靠它）。
2026 年 1 月，MCP 协议层有了 Tool Search：当工具定义超过上下文窗口的 10% 时，客户端自动把定义“延迟加载”，模型先用一个 search_tools 去检索，找到之后再拉完整 schema。Anthropic 在 2025 年 11 月先上了 Tool Search Tool，报告 token 用量下降 85%，2026 年 2 月 GA。
Claude Code 已经在工具定义超过 10% 上下文时自动启用。三层结构是标准做法：Catalog（搜索，只返回名称和一句话）→ Inspect（拉单个工具的完整 schema）→ Execute（调用）。
如果你的工具设计得足够“宽”，渐进披露会帮你兜住；如果设计得碎，渐进披露也只能让你不至于崩，检索准确率还是会掉。
解法三：Code Mode（对超大规模才划算）。
再极端一点，不给工具清单，给模型一个 search() + execute() 的编程接口，让模型写代码调你的 API。Anthropic 报的数字是 150,000 token 降到 2,000，降幅 98.7%；Cloudflare 的 Code Mode 报 99.9%。但有个大多数人不会告诉你的前提：programmatic tool calling 不兼容 MCP 工具。
这条路要你在自己的 API 上另外实现一层，不是在现有 MCP Server 上开个开关。2500 个端点值得，12 个端点不值得。对智能家居厂家来说，结论是：先把解法一做到位，解法二交给客户端，解法三暂时不用碰。
三、协议共存的真相：物理层不会统一，语义层必须统一
现在回答第二个问题：家里同时跑着 Zigbee、Wi-Fi、蓝牙 Mesh、PLC、KNX，怎么办？我的判断很直接：这一层永远统一不了，也不应该统一。厂家要做的是把协议“压下去”，把语义“提上来”。
先看这五种协议各自的位置
把公开参数摆在一起，各自的区位其实非常清楚：
口径说明：单点通信成本指每接入一个点位、为采用该协议而增加的通信硬件成本（模组／芯片及配套射频、耦合电路），不含设备本体、网关、施工与调试；均为量产批量价，不是零售价，也不是工程报价。
KNX 一行为设备端成本（总线耦合与执行器通道分摊到点位），其工程集成报价通常在 300—1500 元／点位，含面板、安装与 ETS 调试。
再看装机格局（第三方口径，不同机构差异较大，仅作量级参考）：PLC-IoT 在精装房前装的渗透率 2026 年已超过 65%，成为前装标配的有线底座；Zigbee 在传感器与开关品类仍是最主流；Wi-Fi 承载视频与中控屏；KNX 稳坐高端工建；Matter 全球支持设备突破 2800 万款，但在国内的实际用途主要是出海合规与跨品牌基础控制，深度场景联动仍然锁在各自生态里。
华为鸿蒙智家是 PLC 路线最完整的样本：2025 年全屋智能系统品牌份额 44.7%、连续四年精装房第一，2026 年高端精装房份额从 34.5% 升到 48.9%；生态汇聚 3200+ 合作品牌、400+ 品类；前装主机两级级联可接 2500 个设备，宣称连接稳定性 99.99%。
海思 PLC-IoT 芯片累计出货超 5000 万片，单节点通信成本从 2019 年的 30 元以上压到今天的 20 元上下（模组批量价，芯片级更低）。
而 PLC 的软肋同样明显：芯片方案高度集中于海思，可选性远不如 Zigbee（TI、Silicon Labs、NXP 几十家）；跨相、跨电表天然不通；变频家电的脉冲噪声在极端环境下仍可能造成 5%—15% 的丢包。
KNX 的软肋是成本与施工门槛，但换来的是 20 年以上设计寿命和 500 多家厂商的互操作历史。
所以“多模融合”不是妥协，是唯一解。行业里已经跑出来的实践架构是：PLC 或有线做控制骨干，Zigbee / BLE Mesh 做传感器末梢，Wi-Fi 做数据高速路，KNX 做高端工建交付。
关键判断：MCP 不能进实时控制回路
这是我见过最多厂家会踩的坑，必须单独讲。MCP 是“意图层”的协议。它的调用链是：用户说话 → 模型理解 → 生成工具调用 → 走 HTTP → 你的服务 → 下发指令 → 设备执行。这条链上任何一环抖动，延迟就是几百毫秒到几秒。而家里的灯，用户按开关的容忍度是 100 毫秒以内。人走过走廊，灯晚亮半秒就是“这系统不好用”。
所以正确的分层是这样：
实时控制回路：本地总线直连，PLC / KNX / Zigbee 本地网关执行，不进 MCP，不过云，不等模型。
意图与编排层：MCP 负责“理解用户要什么、调哪个场景、带什么参数”，一次调用触发一个已经校验过的本地场景。
数据与上下文层：MCP 的 resources 负责把设备状态、事件历史、能耗数据喂给模型做分析，这一层延迟不敏感，正好发挥大模型的长处。
一句话：MCP 管“想清楚”，总线管“做准确”。把这两件事混在一起做的厂家，做出来的东西会又慢又不稳。
四、能力语义层：厂家真正要补的那一层
到这里可以回答核心问题了。MCP 时代，智能家居厂家缺的不是协议适配器，是一层“能力语义层”。这层东西长什么样？我给一个可以直接照着画的参考架构，从上往下五层：
第一层：能力域（Capability Domain）
把全部 SKU 的能力归到不超过 10 个域里：照明、遮阳、温控、安防、门锁门禁、家电、能源、场景、查询、告警。每个域一个工具族。
第二层：能力定义（Capability Definition）
每个能力要有四样东西：动作（做什么）、参数（带什么）、约束（什么条件下不允许）、回执（做完怎么确认）。约束这一项是厂家最容易漏、也最值钱的——“洗衣机正在运行不能开门”“地暖水温超过 55 度不能直接关阀”“门锁只在主人在家时允许远程开”，这些安全边界如果不在能力层写清楚，就要靠提示词去求模型守规矩，那必然出事。
第三层：设备映射（Device Mapping）
把 Zigbee、Wi-Fi、BLE、PLC、KNX 的各自寻址方式，统一映射到“区域 + 设备 + 能力点”这三元组上。KNX 的 group address、PLC 的节点 ID、Zigbee 的 IEEE 地址，在这一层被抹平。这一层做完，上面几层就再也不用管协议了。
第四层：语义增强（Semantic Enrichment）
给每个实体配足够的“人类语言”：标准名、别名、口语叫法、所在房间、与其它设备的关系。用户说“把书房那个灯调暗点”，模型能不能落对，全靠这一层。这件事看起来琐碎，实际是体验差距的主要来源。
第五层：MCP 接口（Interface）
最后才是这一层：tools / resources / prompts 三件套，加上鉴权、限流、审计、幂等。注意顺序。
绝大多数厂家的做法是直接从第五层开始——“我们做个 MCP Server 吧”，然后发现没有能力模型可暴露，只好把 API 一个个包成工具，最后做出一个 500 个工具、模型不会用、自己维护不动的怪物。正确的顺序是从第一层往下，第五层是水到渠成的产物，不是项目的起点。
五、五级台阶：从“被调用”到“被依赖”
讲完架构，讲路径。我把它拆成五级台阶，每一级都有明确的交付物和验收标准。不要跳级，跳了会返工。第 0 级：能力盘点（1—2 个月，投入 2 人）不写代码。
做三张表：
能力族清单：现有全部 SKU 能做的事，按十个域归类，标出重复项；
危险动作清单：开锁、开燃气阀、开车库门、关地暖主阀、解除安防布防。这些默认不暴露，需要显式白名单；
语义词典：每个实体在真实用户嘴里可能被怎么叫（“主灯”“大灯”“顶上那个”）。
验收标准：能拿出一个不超过 40 个工具的设计稿，并且每个工具都能对应到至少三个真实 SKU。
这一级最容易失败的原因，是产品经理不在场。让后端去盘点能力，得到的一定是 API 列表；让产品经理去盘点，得到的才是用户意图。
第 1 级：云侧 MCP Server（2—3 个月，投入 3—4 人）
只做两件事：只读（查状态、查历史、查能耗）和低频写（执行预设场景）。技术要点：传输用 Streamable HTTP，为将来上云做准备；鉴权用 OAuth 2.1 / PKCE，不要图省事用长期 token（HA 的教训：长期访问令牌有效期十年，一旦泄漏就是永久的）。
每个工具做幂等，同一个 request id 重复调用不重复执行；加限流与全量审计日志——不是给合规看的，是给你自己 debug 用的，模型调错工具是常态。验收标准：接入一个外部 Agent，能完成“查一下客厅温度”“把全屋灯关掉”“上周有几次门锁开启”这三个任务，工具定义总 token 控制在 3000 以内。
第 2 级：网关侧本地 MCP Server（3—6 个月，投入 4—6 人）
这一级是分水岭。为什么必须做本地？三个理由，一个比一个硬：
① 断网可用。中国家庭的网络环境里，“云挂了全家瘫”是真实的高频问题，不是极端场景。
② 隐私。把全屋的设备名、区域、作息事件历史传给云端模型，这件事在很多场景下是过不了关的。本地跑一个小模型做意图解析，只把必要的结果传出去，是可解释的架构。
③ 时延。意图解析在本地做，能省掉一个来回。技术要点：网关侧同时做 MCP Server（把家交出去）和 MCP Client（把外部能力拉进来）；用 mDNS 或固定地址做本地发现；做设备级白名单，默认不含门锁、燃气、车库门（HA 的默认暴露域里包含 cover，也就是车库门和卷帘，这是个值得引以为戒的默认值）。
验收标准：断网状态下，本地 Agent 能完成全部场景类指令；网关的 MCP Server 在局域网内被外部客户端发现并连接成功。
第 3 级：场景包与订阅化（6—12 个月，投入 5—8 人）
到这一级才开始谈钱。把复合场景做成可调用的单元，而不是让模型现场编排。比如：
回家模式：玄关灯 30%、客厅灯 60%、空调 26 度、窗帘半开、播报当日天气与待办；
老人夜间起身：夜灯 10% 暖光、卫生间灯提前亮、若 15 分钟未回床则推送家属；
离家安防：全屋灯关、非必要插座断电、摄像头布防、门锁状态校验。
这些场景包的价值在于：它们是厂家十几年调试经验的结晶，是模型自己推不出来的东西。一个通用大模型不知道“南向主卧下午四点西晒要提前拉窗帘”，但你知道。到了这一级，商业模式才成立：硬件卖一次，场景包按年订阅。
这也是国内厂商从“制造业毛利率”往“软件毛利率”迁移的唯一现实通道。验收标准：场景包能通过 MCP prompts 或 Skill 机制分发；有独立的订阅开通率与续费率数据。
第 4 级：双向与生态位（12 个月以上）
最终形态是：你家的网关既是能力的提供方，也是能力的消费者。它调用外部 MCP 拿到天气预报、电网分时电价、家人健康数据、社区物业通知，结合本地的设备状态与历史，做出真正“主动”的判断。这时候你卖的不再是“一套能语音控制的灯”，而是“一个住在家里、了解这家人作息、能替他们做决定的 Agent 宿主”。
六、跟模型企业、平台企业怎么合作
这是最多厂家想不明白的地方。我把合作分成三种姿势，从轻到重。
姿势一：供能力——做 MCP Server，把自己变成工具
做什么：按上一章的路径做一个 MCP Server，挂到各个支持自定义 MCP 的客户端上。
成本：最低。3—4 个人、3 个月、一个后端团队就能干完。
拿到什么：被调用权。用户在任何支持 MCP 的 Agent 里都能调到你家的设备。
拿不到什么：品牌。在模型眼里，你的灯和别人的灯没有区别，都是“一个可调亮度的灯”。而且你永远不知道用户是谁——账号在平台手里。适合谁：出海品牌、白牌代工厂、想快速验证的团队。
姿势二：做端——把 Agent 装进网关，做“家庭侧宿主”
做什么：网关 / 中控屏里跑本地 Agent（小模型 + 规则引擎），对外同时提供 MCP Server 和 MCP Client。
成本：中高。需要一个懂端侧推理的团队，加上协议适配的工程量。
拿到什么：位置。这个位置是平台抢不走的。
理由前面讲过：家的约束——确定性时延、断网可用、隐私本地化、安装交付——和办公 Agent 的假设完全不同。腾讯不会来给你家装灯，也不会为了一盏灯的 100 毫秒延迟去优化模型。
在“家”这个场景里，模型公司是供应商，不是竞争者。你才是那个必须在场的人。适合谁：有前装渠道、有网关产品的厂家。这是国内头部厂商最该占的位置。
姿势三：共建场景——用平台的 Skill / Expert 机制分发场景包
这里要具体讲腾讯 WorkBuddy，因为它对中国厂家最友好。2026 年 9 月 2 日，WorkBuddy 开放平台（open.WorkBuddy.cn）上线，首批 100+ 生态伙伴，同时打通硬件、应用、开发者三层。
硬件侧围绕“听、看、记、聊、协”五类触点，接入智能眼镜、录音卡片、麦克风、耳机、桌面陪伴设备、键鼠、PC 与平板、智能穿戴、手机等十余个品类、30 多个品牌；开发者侧开放 Skill（技能）、Expert（专家）、Connector（连接器）三大能力。
这里有一个所有智能家居厂家都必须看懂的事实：WorkBuddy 首批接入的 30 多个品牌、十几个品类里，没有一个是“家里的设备”。
全是随身和办公场景的东西——眼镜、录音笔、耳机、键鼠、穿戴。这不是腾讯疏忽了，而是“家”这个场景和办公 Agent 的底层假设不兼容：办公场景可以容忍两秒的响应、可以强依赖云、可以默认用户自己会配置；家里这三条全都不成立。
所以厂家跟 WorkBuddy 合作，正确的姿势不是“等腾讯来做智能家居品类”，而是三条具体的接法：
接法 A：把自家云做成 Connector
WorkBuddy 的“专家 · 技能 · 连接器 → 自定义连接器 → 配置 MCP”支持粘贴 JSON、支持 HTTP。也就是说，你做好 MCP Server，用户在 WorkBuddy 里填一段配置就能用，不需要腾讯的商务审批。这是当下门槛最低、见效最快的一条路，很多厂家居然不知道。
接法 B：把“家的场景”做成 Expert 或 Skill
不是把设备接进去，而是把知识接进去：全屋智能怎么设计、不同户型的点位怎么布、什么情况下该用 PLC 什么情况下该用 Zigbee、验收要注意什么。
这些内容做成 Expert，用户在 WorkBuddy 里问“我家 140 平，想做全屋智能，预算 8 万，怎么配”，你的专家能给出一套方案——这才是真正能带来线索的分发。目前平台上已经有帆软这类公司这么做：先调专家，再通过连接器读数据，最后直接出报告。
接法 C：做 Buddy 应用
基于 WorkBuddy 的 Agent 底座做一个品牌化的“家庭 AI 工作台”。这一步重，但拿到的是一块自己的门面，不是别人货架上的一格。
两条横向合作线索：
模型企业侧：阿里云百炼已经开放 40 余款行业 MCP 服务、支持 MCP 服务接入；豆包 / Coze 走插件兼容 OpenAPI；混元、通义、GLM、Kimi、DeepSeek 都支持 OpenAI 兼容的 function calling。这意味着你做一套能力定义，可以低成本铺到多家模型上，不必绑定一家。
同行的实践：小米 miclaw 在 2026 年 4 月上线 PC / Mac / 有屏音箱版，内置 18 个 Skill、19 个三方 MCP 服务；涂鸦在 2026 年 4 月的开发者大会上推出 Hey Tuya、TuyaClaw 和 Vibe Coding；美的在 2026 年 6 月率先接入微信 AI。大厂已经在用 MCP 组织生态了，这不是未来时。
三种姿势怎么选
七、六个坑
这些都是已经在真实项目里出现过的，不是理论风险。
坑一：把 MCP 当选型，不做能力建模。
症状：立项名叫“XX 产品 MCP 化”，交付物是 500 个工具，模型不会用，维护成本爆炸。根因是跳过了第 0 级。解法是先出 40 个工具的设计稿，评审通过再写代码。
坑二：把 MCP 放进实时控制回路。
症状：语音说完到灯亮 1.5 秒，用户骂“不如按开关”。根因是把意图层和实时层混在一起。解法是 MCP 只触发本地场景，实时控制走总线。
坑三：默认暴露危险设备。
症状：Agent 误调“关闭门锁”（在很多实现里，turn_off 一个 lock 就等于开锁），或者把车库门打开了。根因是默认暴露清单没审。解法是危险动作走显式白名单 + 二次确认，默认只暴露照明、遮阳、温控、查询。
坑四：鉴权图省事。
症状：用长期 token、把 token 写进配置文件、网关暴露在公网无速率限制。现实参照：HA 的默认绑定是 0.0.0.0，登录失败默认不做限制（阈值是 -1），长期令牌有效期十年——这些都被安全研究者点过名。解法是 OAuth 2.1 + PKCE，短期令牌 + 刷新，强制限流，全量审计。
坑五：认为“接上 MCP 就有了 AI”。
症状：接完之后 DAU 没变化，用户还是用 App。根因是 MCP 解决的是“能被调用”，不解决“值得被调用”。用户没有理由每天跟家里的灯对话。解法是想清楚那个“每天都会发生”的场景是什么——是老人起夜？是空调电费？是宠物独自在家？没有这个场景，MCP 只是一个技术装饰。
坑六：跟平台合作时把账号和数据主权交出去。
症状：用户在你的设备上，但你在自己的后台看不到这个用户。根因是只做了姿势一，没做姿势二。解法是账号体系自己留一份，平台的账号做映射；设备状态与事件历史留在自己云上，只把必要结果给模型。
八、给国内厂家的八条建议
第一，先把“能力”当资产盘点，别把“接口”当资产盘点。
大多数厂家的技术资产清单是 API 列表、协议栈、云平台。这些在 MCP 时代都不是壁垒。真正的壁垒是：你知道“南向主卧四点西晒要提前拉窗帘”“老人起夜时卫生间灯要提前亮”“梅雨季除湿要配合新风”。把这些写进能力层，它们才第一次变成可分发、可计费的东西。
第二，工具少而宽，描述短而准。
40 个工具能管一个家，500 个工具会毁掉一个家。每省下的一个 token，在每一轮对话里都要再省一次。
第三，本地优先，云为补充。
网关侧跑 MCP Server + 本地小模型，把“断网可用”做成卖点。这件事在海外是差异化，在国内是刚需。
第四，危险动作永远不交给模型。
开锁、燃气、车库门、解除布防——这些不是“需要更好的提示词”，是“不该进工具列表”。能力层的约束条件要写死，不依赖模型守规矩。
第五，把 KNX / ETS 这类“老师傅知识”资产化。
HA 2026.10 已经证明这件事技术上可行：ETS 项目的地址逻辑、电报历史、数值解码，都可以变成 AI 能读的工具。国内做高端项目的集成商，你们手上最值钱的东西一直没被定价，现在有机会了。
第六，跟平台合作，从 Connector 开始，不要从商务谈判开始。
WorkBuddy 支持自定义 MCP 连接器、粘 JSON 就能用。先做出来、先让用户用上、先拿到调用数据，再谈更深度的合作。技术接入的速度，永远快于商务流程的速度——这是创业公司唯一的结构性优势。
第七，占住“家庭侧宿主”这个位置。
这是整篇文章最重要的战略判断。模型公司做的是通用智能，平台公司做的是入口和分发，但没有人会替你承担“这盏灯必须 100 毫秒亮”的责任。这个责任在谁身上，谁就是这个场景的实际控制者。
第八，别把 MCP 当营销词，把它当组织变革。
MCP 化真正难的不是技术，是让产品、硬件、云端、售后四个部门对“什么叫一个能力”达成一致。这件事做不成，MCP Server 做出来也是个壳。
结语：三个判断
判断一：协议这场仗已经打完了，只是没人宣布结果。PLC 拿下前装主干，Zigbee 守住传感器，Wi-Fi 拿走数据面，KNX 守住高端工建，Matter 管出海合规。这个格局在五年内不会变。再讨论“哪个协议会赢”是浪费时间，真正在发生的是：协议下沉成物理层，能力上浮成语义层。
判断二：MCP 的真正意义，是把厂家从“卖设备”推向“卖能力”。过去你卖一台面板，收入是一次性的，毛利率 30% 出头，每年被年降压一次。现在你把“老人夜间起身”这个能力做成场景包，它可以按年收费，毛利率是软件毛利。这是十几年来第一次，智能家居厂家手里有了一件能抵抗年降的东西。
判断三：这一轮真正的分水岭，不是谁先接上 MCP，而是谁先想清楚“用户为什么每天要跟家说话”。MCP 让家变得可被调用，但它不会自动创造调用。那个让用户每天开口的理由——是电费、是老人、是宠物、是睡眠、是安全——才是这一轮竞争的真正战场。技术门槛在降低，场景洞察的门槛在升高。
