1.5 AI大模型带来的范式冲击
1.5.1 从被动连接到主动智能：大模型的推理能力
传统物联网的运作模式可以概括为“感知‑响应”的固定循环：设备采集数据，平台对照预设规则做出反应。这套模式在仓储温控、环境监测这类边界清晰的场景中运转良好——温度超限就报警，CO₂浓度超过阈值就开新风。但当连接设备数量从几十台增长到上万台，规则数量也随之急剧膨胀，维护成本迅速升高。可以粗算一笔账：N 台设备、每台 M 个状态，若要求任意两台设备的状态组合都能联动，规则数量就是 O(N²M²) 量级——哪怕只有 50 台设备、每台只有“开/关”两个状态，组合规则也已达到一万条，这还没有计入时间段、阈值等附加条件。更关键的是，规则引擎本质上是“If‑Then‑Else”的分支结构，无法处理模糊描述或依赖上下文的复合场景。用户说“有点闷”，规则引擎只能等待一个预先配置的测量值超标——它听不懂“闷”这个字，只能识别“CO₂ > 1000 ppm”。
当前主流大语言模型（Large Language Model, LLM）具备语言理解与生成能力，部分模型还支持图像、音频等多模态输入。接入物联网后，模型可以“理解”设备上报数据的上下文含义，而不是单纯查询数值。例如，用户说“感觉房间有点闷”，传统规则引擎不会动作；而大模型可以结合温湿度、CO₂、用户开窗习惯等上下文，推断出最佳操作——比如开启新风并微调百叶窗角度，而不是简单地触发一条预设规则。这背后依赖的是大模型的注意力机制和概率推理能力，它不是在匹配固定条件，而是在计算“给定当前状态，最合理的动作集合是什么”。
图1-16对比了两种模式的决策链路。左侧是传统的规则驱动路径：用户通过固定控制面板或App输入指令，规则引擎精确匹配后直接驱动设备执行。右侧是引入大语言模型后的新路径：用户用自然语言描述需求，大模型解析意图、查询设备实时状态，生成决策方案并展示推理依据，最后交由用户二次确认后再执行。
将推理能力植入物联网需要解决几个工程问题。数据格式标准化是前提：设备上报的是二进制位号值或JSON报文，必须通过提示模板转化为结构化自然语言描述。延迟与成本同样需要权衡：大模型推理通常需要数百毫秒到数秒，不适合秒级以下的实时控制。当前行业共识是将大模型置于平台层的“决策引擎”位置，实时闭环仍由边缘规则引擎或轻量模型负责。这本质上是一种混合决策架构——任务按响应时间窗口和复杂度分层。一些开源物联网平台已在探索这一路线：在平台侧集成大模型接口，将其作为高级决策层，实时控制回路仍保留在边缘端。
大模型的概率性输出不是万能的。同一段输入可能得到不同结果，也可能出现“幻觉”——生成看似合理但实际错误的判断。因此，物联网系统中引入大模型必须配合“沙箱验证”与“高风险动作确认”机制：模型可以建议动作，但执行前需操作员二次确认。这种设计将模型的推理优势与人的最终判断权结合起来，而不是让黑箱模型直接控制物理设备。从工程演进的角度看，这种“建议-确认”模式比全自动推理更符合当前行业的风险偏好。
当物联网从规则驱动转向推理驱动，系统架构是否需要重新定义？设备端是否需要本地模型？云端与边缘的协作模式如何调整？下一节将通过一个智能家居的示意案例，展示大模型控制如何改变日常交互方式，并由此引出架构层面的调整需求。
1.5.2 案例：智能家居从规则引擎到大模型控制
规则引擎长久以来是智能家居自动化的核心：温度低于预设阈值，开空调；门窗传感器检测到开启，关新风。这些预置逻辑可预测、运行稳定，但一旦用户表达超出预设条件，系统就彻底失能。大模型为控制边界打开了新路子。下面以一个例子（所有设备参数和控制温度仅作演示）对比两种路径，变化在哪里就很清楚了。
例子：用户说“我有点冷”。传统规则引擎需要把这句话映射到一条确定的 IF 分支。假设工程师写了这样一条规则：“当室内温度低于 20℃ 且时间段在 18:00‑22:00 时，启动空调制热模式并设定为 26℃”。如果用户说“冷”时室温略高于 20℃，这条规则不会被触发，系统毫无反应。更挑战的是，房间一扇窗户开着，室外冷风正往屋里灌——规则引擎压根不知道“窗户状态”和“冷”之间有联系，因为窗户状态不在那条规则的判定条件里。结果就是一张碎片化的控制逻辑表：温度走温度的规则，窗户走窗户的规则，两不相干。
大语言模型作为控制中枢，处理路径完全不同。用户发出“我有点冷”后，系统先做意图理解：识别出“冷”是关于热舒适度的意图，不是字面温度。接着拉取环境上下文：室内温度略低于舒适区间，湿度正常，窗户状态为打开，室外温度明显偏低、风力偏大。然后执行多步推理：开窗导致热量流失（原因），关闭窗户可以减少冷源进入（动作1），再启用空调制热补充热量（动作2），目标温度设为较低档位以避免关窗后升温叠加导致过热（动作3）。整个过程用户只含糊地表达了一个感受，没有指定任何设备参数。
代码实现对比
规则引擎需要工程师逐条预写组合逻辑，每新增一台设备或一种场景都意味着增改规则。以下为伪代码：
// 规则引擎伪代码：工程师需要预写每种组合
Rule: "Night_Heating"
WHEN:
time_slot IN ["18:00-22:00"] AND
indoor_temp < 20 AND
window_state IS "CLOSED"
THEN:
set_ac_mode("heat")
set_ac_temp(26)
END_RULE大模型通过 API 完成推理，不需要预设条件分支。以下为调用，接口与参数仅做演示：
# 大模型动态推理（代码）
user_text = "我有点冷"
env_context = """
室内温度：低于舒适区间，湿度正常；
窗户处于打开状态；
室外温度明显偏低，风力偏大。
"""
from openai import OpenAI
client = OpenAI()
resp = client.chat.completions.create(
model="your-model",
messages=[
{"role": "system",
"content": "你是一个智能家居中枢。根据环境上下文和用户意图，"
"生成设备控制指令JSON。可用设备："
"[空调(模式，温度), 窗户(开/关)]。"},
{"role": "user",
"content": f"当前状态: {env_context}\n用户说: '{user_text}'"}
]
)
# 返回结果：
# {"reasoning": "开窗导致冷气进入，应先关窗再加热。",
# "steps": [
# {"device": "window", "command": "close"},
# {"device": "ac", "command": "set_mode", "value": "heat"},
# {"device": "ac", "command": "set_temp", "value": "较低档"}
# ]}大模型扮演的是“数字管家”的角色：接收模糊意图，查询环境数据，推理出可行计划，再下发执行。这并不是说规则引擎被完全替代——在生产部署中，规则引擎仍然负责快速、可预测的设备执行控制；大模型接替的是需要工程师逐个编写规则和参数匹配的理解与规划工作。
工程关切点：生产环境部署大模型控制，需要处理时延、安全边界和成本问题。常见做法是用规则引擎兜底，LLM 只负责优先级判断和组合推荐，指令仍然通过原有执行通道下发。这种“推理层 + 执行层”分立的架构，是当前工业界落地大模型控制的主流方案。智能家居案例清晰地展示了：当用户需求是模糊感受而非精确数值指令时，大模型从架构上改变了人与物的交互方式——从“命令式”走向“意图驱动”。
图 1-17 回到 1.5.1 的「闷」案例，把规则引擎与大模型这两条链路并排画出——同一个「闷」字，两条链路的答案截然不同。
1.5.3 范式变革：架构层面的重构
大语言模型进入物联网，迎面撞上的第一堵墙不是算法精度，而是计算资源的分布方式。一个数十亿参数的模型，单次推理所需的算力和能耗，远超传统物联网设备的能力边界。硬把整个LLM塞进微控制器（MCU），在当前技术条件下既不现实也不经济。这迫使物联网的拓扑结构发生了根本性转变：不再是一条单纯的“端-云”数据管道，而是逐步演化为“边-端-云”三层协同的AIoT架构。
大模型推理的计算密集特性是架构重构的第一推力。单次响应需要大量浮点运算和内存带宽，与传统物联网设备上的轻量级推理（例如决策树分类器或简单的阈值判断）存在数个数量级的差距。大模型天然的“定居所”是云端数据中心。但这就带来了一个工程困境：如果每次设备侧的智能决策都要等待云端模型完成推理并返回结果，网络时延与带宽成本会卡住大部分实时应用。以工业场景为例，机械臂的异常振动检测，从传感器采集到执行急停制动的时间窗口非常短，根本等不起一次端到端的云端推理往返。
“边缘挡第一波，云端处理疑难”的分层策略是解决上述矛盾的关键。以一条工厂产线为例：云端大模型能精准诊断数十种设备故障，边缘侧的轻量模型则在本地完成大多数常见异常的识别和告警，只有无法判断的疑难情况才上传云端处理。云端调用频率和设备响应延迟由此大幅下降，而这套分工并不要求边缘设备拥有完整的大模型能力。
新架构的核心模式：端侧轻量模型 + 云端大模型协作。 端侧（MCU/传感器）保持最低功耗，只负责数据采集和关键唤醒事件；边缘侧（网关/计算盒）运行经过压缩的推理模型，承担实时决策和本地闭环控制；云侧则负责大模型的训练、微调与复杂多步推理，并定期将更新后的模型下推至边缘侧，形成持续优化闭环。轻量模型如何从大模型压缩而来——蒸馏、量化等具体技术手段，详见 1.6.2。
传统架构与AIoT新架构的差异，在图1-18中一目了然。
以 IoT DC3 项目为例，其 Agentic Center 基于 Spring AI，通过显式注册的 @Tool 提供租户、用户、设备、Driver、模板、位号、位号值和系统等受控查询或操作；源码中存在但未注册的 Command、Event Tool 不能算作当前可用能力。位号写入先形成待确认 Action，再进入平台命令链路，不能概括为 LLM 直接“动设备”。与此同时，Gateway 通过 MCP（Model Context Protocol）把另一套按权限和策略裁剪的平台 Tool 目录暴露给外部 AI Agent。两套入口复用平台治理，但目录来源并不相同。AI 的推理与行动由此嵌入既有 IoT 管线，并与边缘侧的确定性实时响应分工。
架构调整的关键，是把概率性模型放到合适的位置：端侧负责感知与执行，边缘承担低时延规则和轻量推理，云侧处理知识密集型分析；具体边界仍由安全、时延、带宽、隐私和成本决定。模型可以生成建议或候选动作，最终执行必须经过权限、策略和反馈闭环。