2.1 从经典四层到AI时代新架构
在进入具体架构之前，先交代本书的工程参照物。全书以开源工业物联网平台 IoT DC3（github.com/pnoker/iot-dc3，AGPL-3.0 许可证）为贯穿性参照——它是一个多协议接入、云原生、正向 AI 智能体能力演进的开源平台，也是作者维护多年的真实工程。选它不是因为它完美，而是因为它的每一层都能拆开看：协议如何归一、服务如何拆分、数据如何流转、智能如何受控。本章 2.3 节将解剖其微服务架构，第 10 章与第 14 章分别从工业适配与端到端实战的角度回到它；后文各章出现“工程上如何落地”的追问时，多半能在 DC3 中找到对应实现。
2.1.1 经典四层架构的定位与局限
一个常见的物联网项目开局：团队花了不少精力把传感器选型、网关部署和网络调通跑了下来，结果在应用开发环节卡住了——设备数据源源不断上传，但温度字段名叫 temp，振动传感器是 vib_value，电流又是 I_A，不同厂家给的裸字段没有统一语义。运维人员手工配了一条规则“电机温度超过75℃就发告警”，到了夏季车间温度升高，报警响个不停。想查过去一周产线综合效率，数据分散在设备日志、时序库和 MES 系统里，跨系统查一个趋势要半天。（此为示例场景，非真实项目案例。）
这些困境不是项目管理的疏漏，根子在架构层面。物联网（Internet of Things, IoT）的体系架构，到底覆盖了从数据采集到决策执行的完整链条吗？经典四层架构在这个追问下暴露出的结构性短板，正是推动它继续演进的底层动力。
2.1.1.1 从三层到四层：一个不得不加的中间层
物联网的体系架构并非生来就是四层。早期项目借鉴 IT 分层思维，大多套用三层模型——感知层（Perception Layer）、网络层（Network Layer）、应用层（Application Layer）。这直接沿袭了互联网和电信网的分层思路：采集（边缘）、传输（管道）、处理（云端）。三层模型在小规模原型验证、几百个节点时走得通，但一旦进入生产阶段，问题就冒出来了：设备注册谁来管？海量时间序列数据往哪存？多租户怎么隔离？这些公共能力没有固定归宿，每个应用项目都自己搭一套“底座”，结果是重复造轮子、维护成本失控。
许多团队意识到必须把公共能力抽象出来。翻阅国内外几份共识度较高的参考架构，各方不约而同地在传输层和应用层之间增加了一个平台支撑层（Platform Support Layer）——负责设备管理、数据存储、消息路由等基础能力。两套术语体系最终殊途同归：在“传输”和“应用”之间，必须有一个承上启下的基础设施层。
这就是经典四层参考架构（Classic Four-Layer Architecture）的由来：感知层、网络层、平台层、应用层，外加安全能力贯穿各层。它成为许多物联网产品说明和技术文档引用的基础框架。
2.1.1.2 每层各司其职
感知层是物联网的“神经末梢”——温度传感器、RFID 标签阅读器、GPS 模块、摄像头，以及负责信号汇聚的现场网关。它的使命是可靠采集。不同场景采集对象天差地别——工厂是 PLC 寄存器里的电流值（位号值，Point Value），楼宇是温湿度传感器的串口数据，城市是路侧雷达的车流密度——但落到架构层面，不变的是“把模拟世界的物理状态转换成一个带时间戳的数字信号”。
网络层是数据传输的“高速公路”。它覆盖 ZigBee、Wi-Fi 等短距离无线技术，LoRaWAN、NB-IoT 等低功耗广域技术，以及 4G/5G、光纤以太网等远距离有线与蜂窝技术。网络层不关心数据内容，它只保证数据包从 A 点送达 B 点，以及指令从 B 点下发到 A 点。
平台层是三层模型中没有对应位置的新层。设备注册与管理、时序数据存储与查询、消息路由与分发、规则引擎与事件处理、多租户隔离与基于角色的访问控制（RBAC, Role-Based Access Control）——标准组织推动平台层独立后，应用层开发者不必再关心“数据存哪、设备怎么注册”这类基建问题，可以集中精力写业务逻辑。这是整个架构从“能用”走向“好用”的关键一步。
应用层是面向用户的界面，与行业深度绑定。它可以是一条生产线的制造执行系统（MES, Manufacturing Execution System）、一栋楼宇的能源管理后台、一个城市的交通调度大屏。每个行业有自己特定的业务流程、界面风格和认证规范，但这些差异都被平台层屏蔽了，应用层可以只关心“做什么”，不关心“怎么接”。
2.1.1.3 三条裂缝：从“能用”到“好用”的追问
经典四层架构在过去支撑了无数物联网项目，从智能电表到车联网调度。但这套架构的设计哲学是“数据向上传，指令向下发”——本质上是一条感知→传输→存储→展示的线性管道，而非理解→决策→执行的闭环。这种设计在面对复杂物联网场景时，暴露出三条结构性裂缝。
第一条裂缝：数据处理滞后。 数据从感知层出发，经网络层到平台层，入库后才能被应用层消费。一个冷链监控场景：冷柜温度传感器每30秒上报，经过 Wi-Fi 网关到云平台入库，应用层轮询查询——从温度超限到运维人员看到告警，中间隔了多轮传输、排队和查询延迟。对于需要快速响应的场景（电机过载保护、冷库温度越界），平台层不负责实时推理，应用层离数据又太远。架构层面没有给“就近判断”留位置，设备可能等不到决策窗口就进入不可逆的危险状态。
第二条裂缝：智能决策能力弱。 应用层可以写规则，但规则由人手工定义，覆盖不了复杂动态环境。设备状态间的关联、趋势预测、异常模式自动发现，这些能力在四层架构中没有固定归宿。一条包装产线的电机振动升高、电流波动、气压下降——三个参数单独看都在正常阈值内，但组合在一起，意味着轴承即将失效。经典架构里的规则引擎只能处理“单变量上阈值”的判断，无法在架构层面集成多模态联合推理。项目团队要么自己搭一套机器学习流水线挂到平台层旁边，要么依赖人工看板做手动决策。
第三条裂缝：闭环缺失。 经典架构默认的交互模式是“人看数据→人做判断→人操作设备”。即便引入了自动化规则，那也是人预先写死的逻辑，不是系统自主感知环境变化、重新规划动作。数据从感知层流到应用层就停了，没有回头路径——感知和行动之间，缺少一个持续的自适应循环。现实中的工业控制回路需要快速决策，没有闭环支撑的物联网系统，只能做“事后诸葛亮”式的分析报告，无法形成对物理世界的实时干预。
表2-1 经典四层架构勘界检查清单
| 核查项 | 典型问题 | 架构根源 |
|---|---|---|
| 感知层 | 数据格式不统一，字段名无语义 | 架构未强制物模型抽象，各厂家各行其道 |
| 网络层 | 协议碎片化，网关栈膨胀 | 网络层不关心应用语义，无统一接入抽象 |
| 平台层 | 规则引擎仅支持单变量阈值 | 架构未规划多源联合决策的模块位置 |
| 应用层 | 业务逻辑与数据治理耦合 | 平台层未足够抽象，应用层被迫处理底层细节 |
| 安全层 | 鉴权策略分散在各层，审计困难 | 安全贯穿是理念，实际缺乏统一策略点 |
经典四层架构解决了物联网从无到有的问题。但当 AI 开始渗透到每一行代码时，能否把物联网从“采集→展示”升级到“理解→行动”？这个问题的答案，取决于在平台层与应用层之间，再开辟一层领地——智能层。
2.1.2 AI时代对架构的新需求：智能层
经典四层架构通常把业务判断留在应用层，却没有规定语义治理、模型运行、工具授权和执行审计应如何分工。规模扩大后，团队常遇到数据缺乏统一语义、规则随工况变化而误报、趋势分析缺少上下文等问题。大语言模型和边缘智能提供了新的交互与分析手段，但模型“理解”和“规划”是概率性输出，执行仍需受确定性策略、权限与安全边界约束。因此这里增加智能层，是为了明确责任，而不是宣称机器可以无条件自主执行。
2.1.2.1 来自云端和边缘的两股驱动力
这条闭环必须存在，因为要同时应对两个方向的技术压力。
第一个方向来自云端：大语言模型的实用化。一张位号值表记录着“37.5℃”，但一个在技术文档和运维日志上训练过的模型，能理解这对应哪个设备、位于哪条产线、同类设备在这个数值的历史故障率，以及运维手册里“≥38℃”意味着需要降载运行。它把裸数据翻译成了可行动的情报——但前提是，架构中有一种机制能把LLM的推理结果与实际设备控制指令对接。如果必须由应用层在每次调用LLM前手工拼装上下文、在得到结果后手写几百行代码去下发指令，那“智能”就变成了各应用项目的重复劳动，架构的通用性大打折扣。
第二个方向来自边缘：边缘智能的实用化。不少工业场景对时延的要求在毫秒或亚秒级——一台高速冲压机若在下一个冲程周期内未能识别振动异常，后果可能是模具损坏。云端往返加上推理处理，边缘推理虽然也有消耗，但至少避开了广域网时延的不确定性。这要求架构中有一个位置能在近端运行轻量化模型或规则引擎，并直接或近端影响设备行为。业界常见的分工是“云侧训练、边缘推理、端侧响应”三级协同：云端用全量历史数据训练模型，下发到边缘节点做低延迟推理，端侧只做最后一脚的快速反应。
两条线单独看，一个推高了“理解”的天花板，一个压缩了“执行”的时间窗。合在一起，它们指向同一个结论：需要在应用层内部划出一个专门的职能层，把“理解数据→做出决策→推动执行”这条逻辑从分散的代码中抽离出来，统一在那里完成。
2.1.2.2 智能层的三项核心职责
本书在参考架构中把智能层（Agentic Layer）画成平台层与应用层之间的第五个逻辑层，用来明确 AI 推理、任务编排和受控执行的责任边界。部署时它不要求对应一个固定进程：小系统可以把它作为应用内部子模块，大系统可以拆成独立 Agent Runtime。后文所有“五层”都指职责上的逻辑分层，不把部署拓扑误当成架构定义。其核心职责拆成三块：理解（Understand）→规划（Planning）→执行（Execution）。
理解（Understand）：基于平台层汇聚的结构化位号值流，结合设备元数据、历史模式与领域知识，形成对当前状态的可解释描述。它可覆盖阈值判断、异常检测、趋势外推和根因候选排序；相关性或时间先后不能单独证明因果，根因结论还需机理、试验或现场证据验证。
规划（Planning）：在理解状态后，生成一个或多个可执行的动作序列。规划需要处理多目标冲突——节能与舒适度、产量与设备寿命、降负荷与不停机。规划引擎可以是一套数学模型（如线性规划），也可以是由LLM生成的步骤描述，取决于场景复杂度与可解释性需求。
执行（Execution）：将规划转换为平台层可理解的设备指令，并通过现有命令链路下发到执行器。执行完成后必须收集反馈——设备是否响应该指令、响应后的新状态是什么——形成闭环修正。
这三个步骤不是一次性的三段式流水线，而是不断循环：执行反馈给理解，理解修正后续规划，规划生成新动作。智能层的价值不在于它运行了多大的模型，而在于它把这个循环收敛为有明确输入、输出和治理边界的能力，让业务应用聚焦工作流。模型选型、工具调用、权限、审批和恢复将在第 7 章展开，此处只建立职责模型。
2.1.2.3 智能层的交互：四层架构的AI增强
增加智能层后，应用层的内部结构变为“业务逻辑组件 + 智能层”。数据流不再只是向上的单行道。一条“上行采集流”从物理世界通向数字侧，另一条“下行执行流”带着推理结果返回物理世界。反馈流再把执行后的新状态带回推理模块。
在架构角色上，智能层与平台层、业务应用的分工非常清楚：智能层从平台层读数据、写指令，向业务应用暴露推理结果与可干预的决策入口。平台层不必理解“为什么写这个值”，智能层不必关心数据在数据库里的分区策略。各层将架构中长久的模糊地带——决策与执行的衔接——变成了一个标准化接口。
IoT DC3 用 Agentic Center 展示了这种分工的一种实现：它管理模型与会话，并通过受控工具调用平台能力。以 2026-08 的 987c96d50 源码快照为边界，Agentic 内部的 Spring AI @Tool 与 Gateway 对外的 MCP 工具目录是两条相关但不同的入口；后者从平台 API/资源目录和版本化 OpenAPI 快照形成候选工具，并且只声明 Tools 能力。项目没有默认订阅实时位号流或自动执行闭环。设备查询、位号写入是否可用以及风险等级，取决于实际目录、鉴权、策略和平台 API，不能从参考架构反推为开箱即用能力。工具目录、任务状态、审批和恢复留到第 7 章展开。
2.1.2.4 是否每个项目都需要在应用层内划分智能层？
把智能层概念放进架构图，不等于每个 IoT 项目都需要一个与 LLM 交互的页面。它的本质是在应用层中划出一个专有的逻辑区域，负责“理解→决策→执行”的循环。如果这个循环当前全靠人工完成——运维人员盯着大屏发现问题、打电话让现场操作——那么经典四层架构够用。但一旦项目规模到了需要跨系统拼接上下文、或响应时间要求在秒级以内，人工循环就会成为瓶颈。
智能层的实现方式可以是轻量级的异常分析与决策服务，也可以是对接 LLM、支持多轮任务和多目标规划的 Agent Runtime。逻辑位置确定后，部署形态可以随场景弹性选择。这正是架构设计的基本思路：先划职责，再定实现，不把某个进程或模型当成架构本身。确定性阈值和安全联锁仍属于规则、PLC 或 SIS，不因引入智能层而迁移给概率模型。
表2-2 引入智能层的决策检查清单
| 判断条件 | 若偏向“是” | 建议 |
|---|---|---|
| 单点决策是否依赖人工切换多个系统查上下文？ | 单个决策需要查看两个以上系统的数据 | 建议引入智能层 |
| 规则是否随季节、工况或负荷频繁调整？ | 每月调整一次以上 | 建议引入智能层 |
| 执行动作是否需要在同一系统内完成？ | 决策与执行分离在不同系统中 | 建议引入智能层 |
| 用户是否需要自然语言交互查询设备状态？ | 运维人员反馈“查一次数据要点七八个菜单” | 建议引入智能层 |
| 决策周期是否高于5秒？ | 人工巡检周期在分钟级或小时级 | 经典四层够用 |
这个清单不提供绝对的门槛值——不同行业的时延容忍度差异极大——但它给出了一个结构化的思考框架，帮助团队在架构评审会上问对问题。
判断一个物联网项目是否需要引入这套闭环机制，核心不是“是否用了 AI”，而是是否存在跨系统理解、非确定性判断和受治理执行的独立职责。若只有固定阈值、硬实时联锁或人工低频查看，经典四层足够；若多个应用都要复用上下文、工具和审批策略，才值得把智能层作为第五个逻辑层独立治理。第 7 章会给出深度实现，本章只完成概念落位。
2.1.3 五层架构模型总览：感知、网络、平台、智能、应用
上一节分析了经典四层架构在AI时代的核心矛盾：数据上来了，但理解与决策的执行缺乏标准层。工业现场的工况自适应、跨设备协同、事前预测与主动干预需要一个能收敛推理与行动能力的独立逻辑层。本书提出的五层参考架构（Five-Layer Reference Architecture）正是为这个矛盾画出的一个工程断面——它在平台层（Platform Layer）与应用层（Application Layer）之间嵌入“智能层（Agentic Layer）”，使架构从单向数据管道变为闭环决策系统。下面从上至下拆解各层职责与边界。
应用层（Application Layer） 是物联网与人类用户的交互界面。经典架构中，应用层内嵌规则引擎、数据分析流程、工单系统等模块，数据经平台层到达后直接终止。五层架构下，应用层不再需要自己封装复杂推断逻辑，而是直接调用智能层的推理结果或执行状态来驱动运营看板、工单派发、生产报表等业务流。应用层的开发重心从“写判断逻辑”转向“设计人与AI协同的工作流”。
智能层（Agentic Layer） 是本模型的核心新增层，统一处理三件事：理解（Understand） ——将位号值序列还原为设备状态与场景语义；规划（Planning） ——基于规则或模型输出一组动作序列；执行（Execution） ——通过平台层的命令下发接口把动作送出去，并收回执行反馈。智能层的引入把经典四层中应用层必须承担的决策负担剥离出来，形成一个可复用、与业务场景解耦的决策中枢。它不限定AI技术——可以是大语言模型驱动，也可以是传统规则引擎加实时分析模型，关键在于把“理解”与“执行”的接口标准化。IoT DC3 的 Agentic Center是这一层的具体实践：基于 Spring AI 框架连接大语言模型，内置设备查询、位号读写、命令执行等工具。
平台层（Platform Layer） 定位于基础设施收敛。它负责设备注册与生命周期管理、位号模板维护、时序数据存储与查询、消息路由、命令分发、租户隔离等任务。平台层不关心数据“表达了什么含义”，只关心数据“从哪里来、该存到哪里、该发给谁”。它向上暴露数据查询接口与命令下发接口——这两组接口恰好是智能层的入口和出口。平台层的设计直接影响系统的可伸缩性与数据一致性。IoT DC3 的 Data 中心和 Manager 中心（Manager Center）在架构上承担了平台层的核心职责。
网络层（Network Layer） 负责把数据从现场搬到云端。物联网部署中，这一层直接决定传输时延、带宽消耗以及设备能否安全地与平台层互联。网络层不改变数据内容，只负责按约定协议封包、路由、送达。在 IoT DC3 实践中，“统一接入”由两类网关分工完成，用词需要先分清：设备侧的物联网网关部署在现场，负责把末梢设备的异构连接就近汇聚成统一的数据通道，承担的是现场接入聚合；平台侧的 Gateway 服务则是微服务体系的 API 网关，只负责路由分发、令牌校验这类入口职责——MQTT、CoAP、HTTP 等协议的解析并不在它这里完成，而是由对应的设备驱动服务承担（2.3.2 节详述）。
感知层（Perception Layer） 是物理世界的入口。传感器、RFID 标签、PLC 寄存器、摄像头等末梢设备负责采集原始信号，物联网网关则把这些信号转换成带语义标签的位号值（Point Value）。这一层的核心产出是结构化的数据流——包含设备标识、时间戳、量程和单位的数据对象。可以理解为给物理世界装了一套数字感知系统，所有上层决策的起点都依赖于这一层的数据质量与完整性。
五层架构最关键的改变，不是层数多了一，而是数据流多了一条水平闭环回路。经典四层中，数据从感知层一路向上到应用层即终止；应用层如果想把决策回写给设备，必须自己跨过平台层、网络层返回感知层，这种“回流代码”在每个项目中重复实现且容易出错。五层架构中，智能层承担回流的协调：数据从感知层经网络层进入平台层，平台层将数据向上递送给智能层；智能层理解数据后生成决策指令，再经平台层向下转发回感知层。同时，智能层也可将处理结果向上提交给应用层，形成完整的数据链路。这条闭环在同一架构层内完成逻辑收敛，减少了跨层调用带来的延迟和不一致。把决策回路集中在智能层，还能使平台层保持相对稳定，减少因业务逻辑变化而引起的频繁调整。
下表展示四层与五层架构在关键维度上的差异。表中的阈值和性能对比为参考值，实际数字因项目规模、技术选型和部署条件而异。
表2-3 四层与五层架构能力对比
| 对比维度 | 经典四层架构 | AI 时代五层架构 |
|---|---|---|
| 层数 | 4 层（感知、网络、平台、应用） | 5 层（感知、网络、平台、智能、应用） |
| 数据处理模式 | 单向采集→存储→展示；应用层承担全部决策逻辑 | 闭环采集→理解→决策→执行；智能层收敛推理与行动能力 |
| 决策触发方式 | 规则引擎或人为操作；响应速度受规则预设与人工介入影响 | 模型推理与规则组合驱动；支持实时自动决策并执行，回写路径标准化 |
| 跨层调用复杂度 | 应用层需自行协调向下回写，涉及平台层和网络层的多次 API 调用 | 智能层通过标准化接口调用平台层完成回写，上层应用无需关心执行路径 |
| 智能能力集成 | 每个应用需重复对接并开发 AI 集成，形成重复性劳动 | 智能层统一提供推理与执行能力，多应用共享同一决策中枢 |
| 典型适配场景 | 定时数据上报、固定阈值告警、静态看板展示 | 工况自适应调节、跨设备协同、事前预测与主动干预 |
并非所有物联网系统都需要完整引入五层架构。对数据量小、业务逻辑固定、仅需人工监控的场景，经典四层架构足够简洁，增加智能层反而会引入不必要的复杂度与维护成本。但一旦系统开始面对数据丰富、工况多变、响应要求高的压力——工业设备自调节、产线实时协同、安全预警——智能层的缺失就会成为瓶颈。五层模型给出的不是必须照搬的模板，而是一条可增量引入的演进路径：可以先在平台层保持现有服务，额外启动一个智能层模块，逐步将决策逻辑从应用层剥离。理解了这一取舍，后续章节关于 IoT DC3“一个网关 + 四个中心服务”的实践讨论才有了真正的架构上下文——它不是工具堆叠，而是五层模型在微服务框架下的一次具体落地。智能层对应 Agentic Center，Data 中心和 Manager 中心承载平台层核心职责，平台侧 Gateway 服务把守统一接入入口，Auth 中心（Auth Center）则贯穿各层实现统一的安全控制。
Agentic IoT 与 AIoT 融合（前瞻）。 越来越多平台把模型、工具调用和治理作为独立能力，但这不等于智能层会在某个年份成为所有项目的默认组件。五层模型的价值，是在确有自然语言交互、跨数据源分析或受控自动化需求时，为模型运行、工具授权和审计划出边界；没有这些需求时，四层架构加确定性规则仍然成立。任何“直接对设备执行”的能力都应从只读开始，经离线评测、影子运行、人工确认和有限自动化逐级放权。