阅读主题
1.5 IoT 产品背后的合作模式与长期责任
平台提供什么是一回事，企业怎样组合这些能力又是另一回事。同一款智能灯，可以依赖成熟方案快速上市，也可以逐步掌握产品研发和业务平台；面对家庭用户和面对酒店客户时，交付关系也会改变。
本节比较这些合作结构怎样影响控制空间、成本、收入和责任，并进一步说明平台服务与软件的生命周期。对于需要运行多年的 IoT 产品，选择怎样接入，也意味着将来怎样维护、迁移和退出。
1.5.1 这些角色怎样组成一门生意
前面讨论了芯片、模组、方案、制造、品牌、平台、渠道、集成和运营等角色。但现实中的一门生意，并不是把这些角色排成一条固定的链条。同样是一盏智能灯，不同企业可以选择完全不同的合作结构，也会因此承担不同的成本、风险和责任。
借助成熟供应商，先验证产品与市场
重新看晴川智能灯。如果晴川刚进入市场，它可以采购相对成熟的产品方案：方案商或制造商提供灯具设计与生产能力，第三方平台提供联网、设备管理和 App 开发支持，晴川则把主要精力放在产品定位、品牌、销售渠道和客户服务上。
这种方式不要求企业一开始就组建完整的硬件、嵌入式软件和云平台团队，可以先回答一个更直接的问题：这款产品是否有人愿意购买？ 如果成熟方案已经能够满足开关、调光和远程控制等基本需求，企业就可以把有限的资金与人员集中在市场验证上。
但减少前期建设，也意味着部分能力受制于合作方案。产品可以定制到什么程度、软件何时升级、新功能能否及时加入，以及将来更换供应商需要付出多大成本，都可能受到现有技术和合作关系的影响。
因此，采用成熟方案并不是认为技术不重要，而是选择由合作伙伴承担一部分技术工作。
掌握关键能力，换取更大的演进空间
当晴川拥有较稳定的用户和产品规模后，也可能逐步承担更多研发工作。例如，由自己定义关键硬件与产品模型，开发 App，建设产品后台和业务平台，同时继续采购芯片、通信模组、制造服务和云计算资源。
这样做需要更完整的工程团队和更长的建设周期，但企业可以更主动地决定：
- 不同型号怎样共享账号、设备和场景能力；
- 新功能何时推出，旧设备如何升级；
- 用户、设备与业务数据怎样组织；
- 多种设备怎样联动，产品体系向哪里演进。
这里的“自主”并不等于所有环节都要自己完成。晴川可以掌握产品研发和业务平台，同时不生产芯片、不自建工厂，也不运营自己的数据中心。更准确地说，企业把关系到产品差异化和长期发展的能力掌握在自己手中，把适合标准化采购的部分交给外部供应商。
这两种方式也不是非此即彼。企业可以在起步阶段更多采用成熟方案，随着规模与需求变化，再逐步调整分工，把部分关键能力转移到自己的团队中。
客户改变以后，生意的结构也会改变
如果晴川面对的客户不再是普通消费者，而是一家连锁酒店，合作结构又会发生变化。
酒店需要的通常不只是几千盏灯。它可能要求灯具安装到不同客房后能够统一管理，在入住和退房时自动切换场景，在设备故障时及时告警，还要与已有的客房控制、能源管理或物业系统对接。
这时，系统集成商可以采购晴川的灯具和平台能力，再负责现场勘测、设备部署、系统对接和项目验收。项目交付以后，日常运行可能由酒店自己的工程团队承担，也可能交给第三方运维服务商。
于是，同一盏灯进入了两种不同的生意：面向消费者时，晴川可能直接销售产品并提供配套服务；面向酒店时，它可能只是整个项目中的设备和技术供应商，集成商则负责把多方能力组织成可交付的系统。
产品没有发生根本变化，但客户需求、交付范围和责任边界改变了，商业关系也会随之改变。
每个角色都要回答：客户为什么愿意付钱
不同角色交付的内容不同，获得收入的方式也不同：
- 芯片和模组厂商通过器件供货获得收入；
- 方案商可能通过设计服务、软件授权、控制板或整套方案获得收入；
- 制造企业通过加工服务或成品交付获得收入；
- 品牌企业主要经营商品，也可能提供订阅、增值或配套服务；
- 云平台和软件供应商可能按照设备数量、消息量、计算资源、软件授权或服务期限收费；
- 系统集成商通过方案设计、设备集成、施工调试和项目管理获得收入；
- 运维服务商通过巡检、维护和故障处理等持续服务获得收入。
现实中的收费方式通常不会如此整齐。多种能力可能被打包在同一份产品价格或项目合同中。例如，一款智能设备的 App 对消费者可能完全免费，但支撑 App 运行的云资源、研发和维护成本并没有消失。这些成本可能已经包含在硬件售价中，也可能由后续设备销售、订阅服务或其他收入共同承担。
因此，用户有没有为某项能力单独付费，并不能直接说明这项能力是否具有商业价值。
平台价值怎样回收，成本又由谁承担
平台能力不一定以一项单独的“平台收入”回收。品牌企业可能通过更快推出产品、降低重复研发和维护成本、提高用户留存或支持增值服务来获得回报；独立平台供应商则需要让客户为设备数量、消息量、软件许可、项目交付或持续服务付费。
同一种技术放在不同企业中，收入和成本的归属也会不同。采用方需要把基础设施、研发、运维、销售支持和长期升级等成本纳入判断，不能只看采购合同上的一项价格。后续的服务变化还可能把原本由供应商承担的工作重新推回企业。
同一种技术，在不同企业中扮演不同角色
一项设备管理能力，在品牌企业内部可能是支撑产品销售的基础设施；在云厂商那里可能是按量计费的云服务；在方案商那里可能是整套产品方案的一部分；到了系统集成商手中，又可能成为项目交付所使用的工具。
技术本身没有发生根本变化，但它所处的业务位置改变了。分析一家 IoT 企业时，除了问“它拥有什么技术”，还应继续追问：
- 它究竟向客户交付什么？
- 客户为什么愿意为此付费？
- 这项能力直接创造收入，还是在支撑其他业务？
- 企业需要为它长期承担哪些成本和责任？
前面介绍的各种角色，最终都会回到这些问题。IoT 产业并不是由一串技术公司组成的固定链条，而是一张不断组合的分工网络：不同企业选择承担其中一部分工作，再通过产品、服务和合作关系，把这些能力组织成一门可以持续运行的生意。
而一门生意要持续运行，不仅取决于今天能够采购到什么能力，还取决于供应商是否继续维护产品、服务和合作关系。下一节将进一步讨论平台服务的生命周期。
1.5.2 平台服务也有生命周期
企业选择 IoT 平台时，很容易首先关注今天有哪些功能、价格是多少、设备能否接入。但对于需要运行多年甚至十几年的设备，还有一个同样重要的问题：
几年以后，这项服务还会不会以今天的方式存在？
平台和软件本身也有生命周期。托管服务可能退役，旧版本可能停止维护，产品可能限制新增客户，接口、价格和支持范围可能调整，软件许可与交付方式也可能发生变化。它们影响的范围并不相同，不能都简单概括为“平台不做了”，但都会改变采用方需要承担的工作。
服务可能退役，供给方式也可能调整
Google Cloud IoT Core 曾是 Google Cloud 直接提供的托管 IoT 服务，已于 2023 年 8 月退役，相关官方客户端仓库也随之归档。这里退役的是一项具体的托管服务，并不意味着 Google Cloud 的计算、数据和其他云能力一同消失；设备企业仍可通过其他软件和合作伙伴，在其云基础设施上建设 IoT 系统。Google 官方仓库、Google 发言人的媒体回应、Google IoT 平台架构说明
阿里云物联网平台则需要采用不同的表述。截至 2026 年 9 月 28 日，其中文帮助中心标注为“物联网平台（文档停止维护）”，但相关页面仍在说明公共实例和企业版实例的开通、购买与使用条件，并对部分实例类型和地域作出具体限制。因此，“文档停止维护”、某类实例限制新购与整项服务完全退役，不是同一种状态，不能相互替代。阿里云物联网平台文档、阿里云实例概述
这些案例说明，平台生命周期不是只有“正常运行”和“彻底关闭”两种状态。供应商可能停止某项服务，也可能继续维护存量客户、限制部分新购、调整产品组合，或者把能力转交给合作伙伴。采用方需要根据官方公告、合同和具体实例状态判断影响，而不能只依据一个模糊的“停止”标签。
产品继续存在，使用条件也可能变化
变化不一定表现为服务退出。EMQX 提供了另一种例子。
EMQX 官方在 2025 年宣布，从 5.9 版本起合并此前的社区版与企业版，并采用 BSL 1.1 商业源码许可证。对于原来使用 Apache 2.0 社区版的团队来说，升级到后续版本时，需要重新评估许可条件、部署方式和商业使用边界。讨论这类变化时，也需要区分“开源”与“源码可用”，不能因为能够查看代码，就认为许可条件与过去相同。EMQX 官方公告
因此，供应商即使继续提供同一个产品，版本、许可、价格、接口和交付方式也可能发生变化。 对企业来说，平台生命周期带来的问题不只是“以后还能不能用”，还包括“能够怎样使用、升级需要付出什么代价，以及新的条件是否仍然适合自己的业务”。
依赖外部平台，也是在接受外部变化
假设晴川已经售出几十万盏智能灯，并长期依赖某个第三方平台完成设备连接、消息传递和远程控制。供应商发生不同变化时，晴川面对的工作也会不同：
- 接口发生变化，云端程序和应用可能需要改造；
- 价格或计费方式调整，长期运行成本需要重新计算；
- 旧版本停止维护，系统需要安排升级和兼容性验证；
- 某类实例停止新增，新产品可能需要采用另一套方案；
- 托管服务最终退役，已有设备和业务则需要迁移。
最后一种情况尤其复杂。已经售出的灯仍然在用户家中，品牌不能简单地告诉用户：“平台没有了，所以设备以后不能用了。”
这也是 IoT 与许多普通软件项目不同的地方。手机应用可以要求用户更新版本，但大量安装在家庭、楼宇和工厂里的设备未必能够轻易更换。设备数量越多、分布越广、运行时间越长，迁移通常越困难。
因此，平台依赖不仅是技术依赖，也是一项需要长期管理的经营风险。
自行部署，也不能消除生命周期问题
这并不意味着选择开源软件或自行部署，就能彻底避开变化。
自行部署的软件同样可能停止维护，社区可能衰退，依赖组件可能出现安全漏洞，后续版本也可能改变许可。区别在于，企业面对变化时拥有的选择可能不同。
对于完全托管的平台，如果供应商终止服务，客户最终必须寻找替代方案并完成迁移。对于可以自行部署的软件，即使原供应商改变方向，企业有时仍能继续运行已有版本、维护自己的分支，或者寻找其他团队提供支持。
但这些选择也有成本。继续运行旧版本需要承担安全和兼容性风险；自行维护软件需要工程能力；更换维护方也需要代码、文档和运维体系能够顺利交接。
所以，不存在完全没有生命周期风险的平台选择，只有风险由谁承担，以及变化发生后企业还保留多少选择。
选平台时，也要提前考虑怎样离开
对于需要长期运行的 IoT 产品，一个容易被忽略的问题是：如果有一天不再使用现在的平台，系统能不能迁走？
这要求企业在选型和设计阶段，不只考虑“怎样接进去”，还要考虑“以后怎样出来”，例如：
- 设备是否依赖供应商特有的通信协议和设备模型；
- 设备端的服务器地址、证书和认证配置能否安全更新；
- 已售设备是否具备可靠的远程升级能力；
- 设备、用户、规则和历史数据能否完整导出；
- 业务系统是否大量依赖难以替代的专有接口；
- 哪些标准协议、数据格式和业务模块可以跨平台复用；
- 新旧设备能否在一段时间内分批迁移、并行运行和回退。
这些设计在产品刚起步时可能显得多余，但设备规模扩大以后，改造成本会迅速上升。尤其是设备端：如果服务器地址、认证方式和业务逻辑被固定在固件中，又缺少可靠的远程升级能力，更换平台可能远比迁移普通企业软件困难。
因此，对长期运行的 IoT 产品来说，可迁移性本身也是一种产品能力。 它不要求企业随时更换供应商，而是让企业在环境发生变化时仍然拥有选择。
平台的价值与风险需要一起评估
这些案例并不意味着企业应该拒绝外部平台。成熟的平台可以减少设备接入、消息系统、运维、安全和应用开发等重复建设，让团队更快推出产品。对于很多企业来说，从头建设所有基础能力既没有必要，也不经济。
但减少当前建设工作，并不等于消除了未来的依赖。企业实际上是在进行一种交换：
用供应商提供的成熟能力降低当前建设成本，同时接受一部分由供应商产品策略决定的不确定性。
反过来，自己承担更多建设工作可以增加控制空间，但也意味着长期承担更多研发、运维、安全和人才成本。
所以，真正的问题并不是简单选择“自建”还是“采购”，而是：哪些能力即使供应商发生变化，企业也必须保证自己的产品能够继续运行？ 对这些关键能力，需要更谨慎地设计接口、数据归属、设备升级、替代方案和迁移路径。
从产业角色，回到用户最终得到的产品
从一盏智能灯出发，我们已经依次看到芯片与模组供应商、方案商、制造商、品牌方、连接和平台服务商、应用开发者，以及渠道、系统集成商和运营者。
现实中的企业不会严格停留在某一个位置。品牌可以运营自己的平台，同时采购外部云服务；制造商可以提供设计方案；平台企业可以向应用开发延伸；系统集成商也可能拥有自己的软件产品。
因此，理解 IoT 产业，真正重要的不是给每家公司贴上唯一标签，而是看清三个问题：
- 它向客户提供了什么？
- 它替客户完成了哪些工作？
- 如果这种供给发生变化，剩下的工作由谁继续承担？
最后一个问题尤其重要。IoT 产品一旦售出，设备可能还要运行很多年。产业链上的一次产品调整，最终影响的可能不只是一套内部软件，而是大量安装在真实世界中的设备，以及仍在使用它们的人。
到这里，我们已经大致看清一款 IoT 产品背后的产业分工。接下来把视线重新放回用户最终得到的东西：同样是灯、传感器、网关和应用，为什么有时只是一件独立产品，有时组成全屋智能系统，有时进入楼宇、酒店或工厂项目，又有时成为开放生态的一部分？
接下来将转向连接 IoT 世界的技术地图，说明网络、通信协议和互操作标准分别解决什么问题。
前面已经看清产品由谁提供、平台由谁组织，以及长期变化会把工作推向哪里。接下来将转向连接 IoT 世界的技术地图，说明网络、通信协议和互操作标准分别解决什么问题。