小米要给智能体一套设备语言

11 月 10 日，小米联合北京大学正式发布《物联网设备模型（Thing Model）技术白皮书》，把在超过 11.6 亿台 AIoT 设备上验证过的物模型技术经验开放给行业。与普通的智能家居协议升级不同，这份白皮书瞄准的是一个更具体的问题：当 AI 从回答问题的聊天机器人变成能够执行任务的智能体，它究竟该如何理解、发现和安全调用现实世界里的设备？(ithome.com)

白皮书由中国计算机学会泛在操作系统开放社区牵头，小米科技与北京大学共同编写，覆盖小米 200 多个设备品类和超过 10000 家合作伙伴的实践。小米集团合伙人、总裁卢伟冰称，小米将 11.6 亿台设备上验证过的技术和经验正式开放给全行业。需要注意的是，公开信息没有说明 11.6 亿是当前在线连接量、累计接入量还是其他统计口径，因此不宜将其直接理解为实时活跃设备数。(ithome.com)

物模型不是设备说明书，而是机器能执行的语言

物模型是把物理设备的属性、事件、动作和服务，翻译成软件可读取、可验证、可调用结构的描述体系。 一台空调在人类眼中有开关、温度、模式和风速，在物模型中则会被拆成可读写属性、可执行动作、可订阅事件以及相关参数约束。

传统物联网之所以能实现 App 控制和自动化联动，底层依赖的正是这套结构化描述。小米现有 MIoT Spec 已经将设备抽象为 Property、Action、Event、Service 和 Device 等层级：开关状态可以是属性，启动烹饪可以是动作，门锁被打开可以是事件，而照明、风扇和电池等相关功能可以组成不同服务。

问题在于，过去的物模型主要是写给 App、云平台和规则引擎看的，并不是为大模型准备的。App 可以把某个固定编号对应成“打开客厅灯”，规则引擎也可以执行“温度超过 28 摄氏度时开空调”，但 AI 智能体需要理解更模糊的用户意图，例如“家里有点闷，处理一下”或者“我要睡了，把家里收拾到适合睡觉的状态”。

这意味着设备不能只告诉 AI“我有一个编号为 2 的动作”，还要说明这个动作能做什么、需要哪些参数、执行后可能产生什么影响、当前是否可用，以及调用前是否需要用户确认。

Dynamic Service 解决设备能力变化问题

Dynamic Service 是允许设备在运行期间动态增加、移除或调整服务，并让上层系统实时发现这些变化的机制。 小米在白皮书中提出四层物模型架构与 Dynamic Service 动态服务机制，试图突破传统静态模型必须预先定义全部能力的限制。(ithome.com)

静态物模型适合功能稳定的灯泡和插座，却不完全适合正在快速软件化的汽车、机器人和复杂家电。一台扫地机器人可能通过固件升级获得地毯深度清洁、机械臂拾取或宠物区域避让能力；一辆汽车可能在购买后增加座舱场景、辅助驾驶功能或新的传感器服务。如果平台仍然使用出厂时固化的能力清单，每次更新都可能需要同步修改 App、云端接口和自动化规则。

动态服务的价值在于把设备从“固定功能集合”变成“可以持续发布能力的运行节点”。例如，一台清洁机器人升级后新增“洗拖布”服务，家庭智能体可以重新读取设备能力并发现该服务，而不是等待控制端发布新版本，再由用户手动添加一条自动化。

这个方向并非单纯追求灵活性，而是在为长期运行的智能体提供基础条件。智能体面对的环境必然不断变化：设备会上线和离线，功能会升级，权限会被调整，同一台设备在不同状态下能够执行的动作也不一样。只有能力描述本身可以动态更新，智能体的计划才不会建立在过期信息上。

小米想把物模型升级成“能力契约”

能力契约是设备向智能体明确声明可用能力、调用参数、执行条件、权限边界和风险等级的机器可读协议。 白皮书提出将物模型从设备描述语言升级为面向 AI 智能体的能力契约，并制定“AI 友好物模型”的四项标准和三类评价机制。当前公开报道尚未完整披露这些标准和评价指标的具体名称，因此其工程可执行性仍要等待白皮书全文或后续规范文件验证。(ithome.com)

这一步比接入一个大模型更关键，因为模型的语言理解能力并不能自动解决设备接口混乱的问题。一个模型可以理解“把卧室调得舒服一点”，但如果空调将制冷模式标记为 cooling，加湿器使用 wet_mode，新风机又把风量分成六个厂商私有等级，智能体仍然要为每个品牌编写适配逻辑。

AI 友好物模型需要提供的不只是字段名称，还包括语义。智能体至少要知道：某项能力对应什么现实效果、参数的单位和合法范围是什么、执行动作是否可撤销、预计耗时多久、设备当前是否满足执行条件，以及失败后该如何恢复。

例如，“打开热水器”并不是一个风险完全相同的动作。在家中有人、设备水量正常时，它可能是低风险操作；在设备故障、家中无人或儿童模式开启时，它可能需要额外确认。能力契约的作用，就是把这些约束从产品经理的文档和 App 代码中提取出来，变成智能体能够直接读取的规则。

MCP 能接工具，但不能替设备定义自己

MCP 是一种让大模型应用发现并调用外部数据源和工具的开放协议。 MCP 的工具机制允许服务端公开工具名称、参数结构和描述，模型可以读取工具列表，并根据用户意图决定是否调用；其官方规范同时建议，高风险工具调用应保留用户确认和人工介入能力。(github.com)

小米白皮书明确提出支持 MCP 和 Function Calling 等接口对接，但物模型与 MCP 并不是同一层技术。物模型负责定义一台设备“是什么、有什么能力、当前处于什么状态”，MCP 负责把这些能力暴露给智能体；前者更像设备的标准化简历，后者更像智能体访问工具的通用插座。

Function Calling 是让模型按照预定义参数结构生成工具调用请求的机制。 它解决的是模型如何输出可执行参数，却不会自动统一不同厂商的设备语义。如果设备能力缺少标准化描述，开发者仍然要手动把数千种私有接口包装成工具。

小米方案真正值得关注的地方，是试图让物模型直接生成或映射为智能体可调用工具。理论上，一台新设备加入家庭后，智能体可以读取其能力契约，将“开关”“设置温度”“启动清洁”等服务转换成工具，再结合房间、用户权限和设备状态完成任务编排。

它与 Matter、MCP 有什么区别

不同技术都在描述设备或工具，但它们解决的问题并不相同。

| 技术或方案 | 核心定位 | 能力发现方式 | 主要调用者 | 对 AI 智能体的适配 | 关键限制 | |---|---|---|---|---|---| | 传统厂商物模型 | 描述设备属性、事件和动作 | 多数在产品接入时静态定义 | App、云平台、规则引擎 | 需要额外封装 | 厂商语义不统一，能力更新依赖平台同步 | | Matter 数据模型 | 通过设备类型和 Cluster 提升跨品牌互操作 | 按规范声明端点、设备类型和 Cluster | Matter 控制器与设备 | 可作为设备语义基础 | 重点是互联互通，不等同于智能体任务规划 | | MCP | 连接大模型应用与外部工具、资源 | 客户端读取服务端工具列表 | AI 应用和智能体 | 原生面向模型工具调用 | 不负责定义底层设备语义和物理风险 | | Function Calling | 让模型生成结构化调用参数 | 应用预先提供函数定义 | 大模型应用 | 适合执行单次工具调用 | 不是跨厂商设备标准 | | 小米 AI 友好物模型 | 将设备能力描述升级为智能体能力契约 | Dynamic Service 动态发布与发现 | App、平台和 AI 智能体 | 强调语义、动态性和安全分级 | 仍需验证开放程度、跨厂商治理与落地成本 |

Matter 的开源实现已经维护机器可读的数据模型，包括设备类型、端点和大量 Cluster；截至 2026 年 6 月，Matter SDK 的全设备示例文档列出了 159 个 Cluster。它证明统一设备语义是可行的，但 Matter 更关心不同品牌的控制器能否控制设备，小米白皮书则进一步关心智能体能否理解能力并自主编排任务。(github.com)

两者并非必然竞争关系。理想状态下，Matter 可以负责底层跨品牌互联，物模型负责补充更丰富的设备语义与运行状态，MCP 则把这些能力暴露给上层智能体。真正困难的不是协议之间能否转换，而是不同生态是否愿意共享足够完整、稳定且可验证的能力描述。

一句话控制多设备，难点不在“一句话”

“一句话自主编排多设备联动”最容易展示，却不是最难实现的部分。让模型把“准备看电影”拆解为关闭窗帘、调暗灯光、打开电视和切换音响输入并不困难，难的是确认这些设备是否在线、动作是否执行成功、多个动作是否存在依赖，以及执行到一半失败后如何回滚。

一个可靠的家庭智能体需要持续处理真实世界的不确定性。窗帘可能被异物卡住，空调可能处于维护模式，电视可能由其他家庭成员使用，门锁操作也不能与灯光控制采用相同权限。智能体必须先读取状态，再生成计划，逐步执行并检查结果，而不是一次性发出全部命令后宣布任务完成。

Dynamic Service 可以帮助智能体获得更新后的能力列表，但它不能单独保证任务可靠性。行业还需要统一动作幂等性、超时、错误码、状态回报、补偿操作和并发冲突等工程规则，否则复杂联动仍会停留在演示层面。

安全是这套方案能否落地的分水岭

物理世界智能体安全是限制 AI 对设备的权限，并根据操作后果实施身份认证、风险分级、用户确认和审计追踪的机制。 白皮书以小米 MiTEE 可信安全体系为基础，结合设备身份认证、权限控制和 AI 操作风险分级确认，提出五层安全屏障。(ithome.com)

设备控制与普通工具调用的最大区别，是错误可能产生不可逆的现实后果。模型误读一份文件，通常只会给出错误答案；模型误开门锁、误关冰箱、误启动烤箱或误调整汽车设置，则可能直接影响财产和人身安全。

风险分级因此不能只是弹出一个统一确认框。查看空气质量、读取室温等只读操作可以默认执行；打开灯光和调节空调可以在用户授权范围内自动执行；门锁、燃气、摄像头、汽车和高功率电器则应增加身份验证、设备侧校验或二次确认。涉及多个设备的复合任务，还要按照其中风险最高的动作确定确认等级。

权限管理也需要细化到用户、空间、时间和设备状态。儿童可以控制卧室灯光，但不能解锁大门；访客可以使用客厅电视，但不能查看摄像头；家庭智能体可以在晚上十点关闭公共区域灯光，却不能在检测到有人洗澡时关闭热水器。

小米开放的是方法论，还是新的生态标准

小米发布白皮书的现实意义，在于它拥有足够大的设备规模来验证物模型的工程细节。覆盖 200 多个品类和超过 10000 家合作伙伴，意味着这套模型面对过大量设备差异、固件版本和自动化场景，其经验比一个从零设计的实验室协议更接近产业实际。(ithome.com)

但“开放技术经验”与“形成开放标准”之间仍有明显距离。行业真正关心的是白皮书是否会进一步开放完整规范、Schema、验证工具、参考实现、兼容性测试和治理流程，以及其他品牌是否能够在不依赖小米云平台的情况下实现同等能力。

如果规范只能服务于小米生态，它依然可以显著提升米家和“人车家全生态”的智能体体验，却很难成为跨行业标准。如果核心模型、评测方法和测试工具能够由 CCF 社区持续维护，并允许家电、汽车、机器人和工业设备厂商共同参与，它才有机会成为中国 AIoT 领域的公共基础设施。

真正的竞争从模型参数转向设备调度权

这份白皮书释放的更大信号，是消费级 AI 的竞争正在从“谁的模型更聪明”转向“谁能让模型可靠地调用最多设备”。大模型的语言和推理能力逐渐趋同后，设备覆盖、实时状态、权限系统、场景数据和执行闭环会成为更难复制的壁垒。

小米的优势不是单独拥有一个大模型，而是同时拥有手机、汽车、可穿戴设备、家庭网关和大量家电节点。物模型如果能够统一这些设备的能力描述，智能体就不再只是系统中的聊天入口，而会变成调度“人车家全生态”的控制层。

这套方案目前仍更像一次方向明确的技术宣言，而不是已经完成验证的行业标准。Dynamic Service 和能力契约抓住了智能体进入物理世界的两个核心问题，但最终价值取决于三个结果：规范是否真正开放，跨品牌设备是否愿意采用，以及安全分级能否在真实场景中经受住错误调用和攻击。

对于开发者来说，最值得关注的不是“一句话控制全屋”的演示，而是后续是否会出现可下载的 Schema、能力契约示例、MCP 映射规范、兼容性测试套件和设备侧参考实现。白皮书提出了正确的问题，接下来要看的，是小米能否把 11.6 亿台设备积累的内部经验，变成其他厂商也能实施、验证和共同治理的公共规则。

参考来源

• IT之家：小米联合北京大学发布《物联网设备模型技术白皮书》——白皮书发布时间、参与机构、设备规模及三项核心技术方向。
• Model Context Protocol 官方 GitHub 仓库——MCP 协议、Schema 与官方文档的开源仓库。
• MCP Tools 规范——工具发现、模型调用和人工确认机制说明。
• Matter SDK 数据模型说明——Matter 机器可读数据模型及规范版本管理方式。
• Matter Cluster 实现列表——Matter SDK 中设备能力 Cluster 的实现情况。