1.7 工程收束与实践指南
1.7.1 本章核心要点的回顾与实践建议
从PC互联网到移动互联网，再到万物互联，这三次浪潮不是简单的技术升级，而是每次重新定义了“谁在联网”与“联网做什么”。前两次浪潮的终端是人，第三次浪潮的终端是物——这个区别决定了物联网的技术栈、设计思路和工程挑战，与所有人积累的Web和移动开发经验有根本性不同。
AI大模型的引入进一步放大了这种差异。过去物联网系统的“智能”停留在规则引擎层面——温度超过阈值就发告警，设备离线就记录日志。现在，一个能理解上下文、拆解模糊意图、调用工具执行操作的AI Agent，正在把物联网从“被动响应”推向“主动干预”。这不是在旧架构上贴一个AI标签，而是从数据采集到决策执行的全链路重构。
全书的四个关键词——感知、推理、行动、进化——就从这句话展开：感知负责让数据可信，推理只产生候选判断，行动必须穿过确定性边界，进化是这条闭环逐级放权的时间轴。后续各章的收束处会回到这四个词。
下面这张矩阵图帮助你把本章讨论的三次浪潮、定义要素和AIoT趋势，浓缩成一个可执行判断框架。它不是一个技术选型表，而是一个决策坐标——无论你正在规划新产品还是评估旧系统改造，都可以用它快速定位当前阶段和下一阶段。
实践清单：5条可立即用于行动的建议
1. 用三次浪潮框架重新定位你的项目
放下技术栈，先回答：系统核心价值是让用户获取信息、让人们互动，还是让物理设备协同？一个只推送温度告警到手机上的“智能家居”，本质还是移动互联网项目，只不过用了Wi-Fi传感器。定位错了，技术选型跟着错。
2. 给数据打标签，区分“感知值”和“推理值”
规划数据库时，原始位号值与平台计算、模型推理产出分开存储。前者走时序库，后者可以进向量或关系库。这个分层会让你在未来引入AI时省掉大量数据清洗时间（可参考第5章“平台层与数据处理”关于数据链路闭环的讨论）。
3. 提前验证规则引擎的承载极限
规则条件数量不是引入 Agent 的门槛。固定、可枚举且涉及安全后果的逻辑，即使条件很多，也应优先使用规则、状态机或形式化 Workflow；需要跨系统检索证据、解释自然语言意图、生成排查方案时，才评估受治理的 Agent。评估指标应包括任务成功率、越权率、错误参数、人工接管和成本，而不是“超过 5 个条件”这类任意阈值。
4. 动手搭建一个最小闭环原型
找一块ESP32和一只DHT11，用MQTT协议将数据上报到开源物联网平台（IoT DC3社区维护的开源版本是一个不错的选择）。先说清这块硬件的边界：DHT11精度约±2℃，且没有长期漂移指标，仅适合练手，不要用于真实项目（量产建议改用Sensirion SHT系列等工业级温湿度传感器）。验收标准可以定得很具体：让设备连续上报24小时数据，画出丢包随时间的分布曲线，并核对设备时钟与平台时钟的漂移量。设备供电、断网恢复、时区处理，这些环节的工程真相都会在这两条曲线里现形。踩一遍坑比读十篇文档更能理解物联网的工程全貌。
5. 现在开始为项目预留AI接入点
即使暂不用大模型，设计API和工具接口时也请遵循能被Agent远程调用的规范（如OpenAPI）。标准的RESTful接口、清晰的出入参定义、完善的鉴权机制——这些基础工作，决定了项目一年后能否低摩擦地接入MCP或Tool-Calling协议。在需要AI时才改造，成本高、风险大。
本章聊概念、讲历史、谈趋势，但工程世界最终验证一切的只有代码和实物。读完这一章，关闭窗口之前，打开ESP32的开发环境，把第一行代码写下去。