数据智能与 AIoT

数据采上来、存进时序库之后，真正的价值才刚开始：把海量位号值变成"现在怎么了、接下来会怎样、该做什么" 。这一章讲应用层的智能——实时监控、历史分析、预测性维护、异常检测，以及大模型如何走进物联网运营。读完你会有一个判断框架：什么交给规则、什么交给模型、AI 算在哪一层，以及 IoT DC3 把这套智能落在了哪里。

你在这里：已经理解了时序数据与流处理怎么把值汇聚起来。这一章在数据之上做"决策"，是四层架构里应用层的智能部分。

这一层是什么 / 为什么存在

前几层解决的是"把物理世界搬进数字世界"：感知层采集、网络层传输、平台层存储与归一。到这里，你手上有了带语义的、连续的、可查询的位号值流。但数据本身不产生价值—— 没有人会为"昨天 8 点温度是 73.2℃"付钱，他们付钱是为了"锅炉再过两小时可能过热，先降负荷"。应用层智能存在的理由，就是把数据转成可执行的判断。

这一层做的事可以收敛成四类，按"看现在 → 看过去 → 看未来 → 不用人盯"递进：

实时监控：对当前值做阈值、状态、趋势判断，第一时间发现越界。要的是低延迟——值刚落库（甚至在落库的同一条流上）就要算出结论。
历史分析：在时间维度上做聚合、对比、关联，回答"这台设备这个月能耗为什么涨了""哪些工况下故障率最高"。要的是**大范围扫描 **与按维度切片。
预测性维护：从历史模式里学出"正常长什么样"，提前预判退化与失效，把"坏了再修"变成"快坏了先修"。要的是模型而非固定阈值。
异常检测与智能告警：识别偏离正常基线的行为，并把"一堆原始越界"压缩成"少量、有上下文、可处置"的告警，避免告警风暴淹没运维。

这四类不是并列的功能清单，而是一条内在的张力线：越往"看现在"一端，越要低延迟、越偏轻量计算；越往"看未来"一端，越要大数据量与模型能力。同一个系统里，实时监控可能跑在边缘的毫秒级回路上，而预测与历史分析跑在云端的离线任务里——理解这条张力，才知道每类智能该放在哪、用什么手段。

AIoT（AI of Things）是这一层的统称：让 AI 参与到物联网的感知—决策—执行闭环中，而不只是事后做报表。它的边界不在" 用了多高级的模型"，而在"模型的判断能不能回写到物理世界"——能下发命令、能触发动作，才算真正闭环。

关键技术与权衡

应用层智能不是单一算法，而是一条流水线：采集 → 分析/建模 → 决策 → 执行 ，再把执行结果反馈回采集，形成闭环。下面这张图是这套通用模式的骨架——无论工业、能源、楼宇还是城市，落地形态各异，但闭环结构一致。

把这条闭环拆开看，每一跳都有取舍：

规则还是模型？ 这是最先要做的选择，不是"模型更高级所以都用模型"。固定阈值、状态机、简单趋势这类确定性判断 ，用规则最划算——可解释、可审计、零训练成本、毫秒级。只有当"正常"难以用阈值描述（多变量耦合、随工况漂移、周期性波动）时，才值得上模型。多数生产系统是 规则托底 + 模型补强：规则覆盖已知的硬约束，模型负责发现规则写不出来的异常。

AI 算在哪一层？ 端侧、边缘、云侧的分工本质是延迟、带宽、算力、数据广度之间的权衡：

端侧 AI：跑在设备/传感器上，做最轻量的就地判断（如振动是否异常）。延迟最低、不依赖网络，但算力与模型规模受限，看不到全局。
边缘 AI：跑在现场网关/边缘盒子上，聚合一片设备做实时检测与预处理，把"原始流"压成"事件流"再上云。平衡了延迟与视野，还能在断网时自治。
云侧 AI：算力与数据最充分，适合训练模型、跨设备/跨厂区的全局分析、以及大模型驱动的运营。代价是延迟与带宽——不适合毫秒级闭环。

合理的架构往往是云侧训练、边缘推理、端侧响应：云上用全量历史训出模型，下发到边缘做低延迟推理，端侧只做最后一脚的快速反应。这条分工不是非此即彼，而是同一套模型在不同位置承担不同时延的职责。

同一套模式，不同行业。 工业、能源、楼宇、城市的应用看似千差万别，骨架却是同一条闭环——采集 → 分析 → 决策 → 执行 。与其逐行业堆砌，不如看清这套抽象怎么套到任何场景上：

采集变的是数据源——工业是 PLC 寄存器、能源是电表读数、楼宇是温湿度与门禁、城市是路侧传感器；不变的是都归一成带语义的位号值流。
分析变的是关心的指标——产线良率、负荷曲线、舒适度、车流密度；不变的是规则与模型这两种手段的组合。
决策变的是触发条件与阈值，执行变的是动作对象——降负荷、错峰、调风机、配灯时；不变的是"判断要能回写物理世界"这条闭环要求。

换句话说，理解了这条通用闭环，再看任何一个行业方案，都能一眼定位它在"采集—分析—决策—执行"里做了什么、缺了哪一环。IoT DC3 提供的正是这条闭环的通用底座，而非某个行业的成品方案。

大模型 + IoT 是近年新增的一层能力，它不替代上面的分析栈，而是给运营套了一个自然语言界面与自主编排能力：

自然语言运营：用"把 3 号锅炉过去一周的温度趋势画出来"代替写查询、点菜单，降低运维门槛。
工具调用（Tool/Function Calling）：模型不是凭记忆瞎答，而是调用平台真实 API 去查设备、读位号、下命令——答案有据可查，动作真实生效。
检索增强（RAG）：把设备手册、SOP、历史工单喂给模型作为上下文，让它的建议贴合本系统的实际，而非泛泛而谈。

大模型的"能说"不等于"能信"

大模型会"一本正经地编造"。在物联网里这尤其危险——它若编出一个不存在的位号值或下错命令，后果作用在物理世界。因此可信的做法是： 让模型只通过工具读真实数据（而非凭训练记忆作答），让高风险的写动作必须经人工确认。

工程要点

把上面的取舍落到工程上，有几条反复被验证的经验：

延迟分层对齐场景 ：毫秒级闭环（安全联锁、急停）绝不能依赖云端往返，必须下沉到边缘或端侧；分钟级的趋势预测、报表，放云端最合适。先问" 这个决策最坏能等多久"，再决定算在哪。
告警要降噪，不要更吵：原始越界往往成片出现。工程上要做**去抖动（持续 N 秒才算）、状态机（触发/恢复/关闭，避免反复跳变）、聚合与分级（P0–P3） **，把"一万条越界"收敛成"三条该处置的告警"。否则告警越多，越没人看。
预测性维护先有"正常基线"：模型的价值来自"知道正常长什么样" 。没有足够的、带标注的历史数据，再好的算法也学不出基线——所以数据采集与存储的质量，是预测能力的前提，而不是后置优化项。
AI 不能绕过权限与租户边界：模型代表某个用户/账号操作，它能看到、能动的，绝不能超过这个账号本身的权限。跨租户的数据，对 AI 也必须是看不见的。这条在多租户系统里是硬约束，不是可选项。
模型会随时间漂移，要持续校准：设备老化、工况变化、季节更替都会让"正常基线" 悄悄偏移，昨天准的模型今天可能频繁误报。预测与异常检测不是"训一次用一辈子"，要有重训与回放评估的机制，否则误报会逐渐侵蚀运维对告警的信任。
写动作必须可审计、可回退、可确认：读是安全的，写一旦做错就难收场。工程上要给写动作加上**人工确认、幂等键、超时过期、全程审计 **——AI 越自主，这层护栏越要厚。

在 IoT DC3 中如何落地

IoT DC3 的应用层智能集中在两条路径上，都建立在前几层已经归一好的位号值与统一鉴权之上。两者的共性是：AI 的所有动作最终都走平台真实 API，经网关注入主体上下文，再由鉴权中心做 RBAC 权限校验与租户隔离——模型拿不到比对应账号更多的权限。

第一条：Agentic 中心（平台内建的对话式 AI 运营）。 基于 Spring AI，把一个 OpenAI 兼容的大模型接到设备、位号、数据与命令上。用户用自然语言提问，模型按需调用平台内置工具去查元数据、读实时值，在受控授权下触发设备读写。这正是上文" 工具调用"模式的落地——模型读的是真实数据，不是训练记忆。

内置工具是 10 个，不是 8 个

智能中心内置 10 个 @Tool 工具类：TenantTool、UserTool、DeviceTool、DriverTool、ProfileTool、PointTool、 PointValueTool、SystemTool、CommandTool、EventTool。早期文案里出现过"8 个"的说法，以代码与目录为准的数量是 10。

工具调用默认开启，但可关

工具调用由环境变量 AGENTIC_TOOL_CALLING_ENABLED 控制，默认 true。设为 false 后模型退化为纯对话，不再触碰任何设备/数据接口——需要在受限环境里只放开问答时这样配。此外持久化会话记忆由 AGENTIC_MEMORY_ENABLED 控制：.env.example 部署模板将其置为 false（默认关闭）；若不提供该变量，框架内置默认为开启——以实际部署环境为准。

高风险写动作不直接执行

智能中心的写工具从不直接下发命令，而是先生成一个待确认的 Action（状态 PENDING，默认 now + 10 分钟 过期），返回 pendingConfirmation=true；必须由用户携带 action_id 调 POST /action/confirm 确认后，才真正执行写命令。这与下面 MCP 网关的风险门控是两套独立实现，细节见 Agentic 中心。

第二条：AI Agent / MCP（把工具安全暴露给外部 Agent）。 网关在 POST /mcp 提供 JSON-RPC 2.0 的 MCP Resource Server，工具目录由四个中心的 OpenAPI 自动聚合（约 150+ 个工具），由外部 Agent 自主决定调用哪个。它面向"自己搭 Agent 让模型自主编排"的场景，约束比对话式更严：

仅 OAuth 2.1：MCP 访问只接受 OAuth 2.1 颁发的短时 JWT（默认 15 分钟有效），公开客户端强制 PKCE（S256）、刷新令牌轮换。* *当前没有 Personal Access Token（PAT）等长期静态令牌**这一接入方式。
三层工具可见性过滤：tools/list 返回的工具 = 主体 RBAC 权限 ∩ 该 MCP 连接的工具白名单 ∩ 风险策略（HIGH 风险默认隐藏，需显式开启）的交集。Agent 看得见、调得动哪些工具，由这三层共同决定。
HIGH 风险两阶段确认：高风险工具调用先返回 CONFIRM_REQUIRED + confirmId，客户端须携 confirmId + 幂等键二次调用，服务端校验未过期、参数摘要一致、单次消费，并全程写入审计日志。

MCP 的 resources / prompts 尚未实现

MCP 协议里的 resources（资源暴露）与 prompts（提示词模板）在 IoT DC3 中尚未实现，属规划项；当前只提供 tools（工具）能力。此外 tools/list_changed 变更通知未做事件推送——工具目录不是实时同步给已连接的 Agent，刷新需经管理端接口 POST /mcp/tool/catalog/refresh 手动（或 API 注册变更后）触发重建（PT5M 是 HIGH 风险二阶段确认的 confirm-ttl，与目录刷新无关）。

告警与通知 则承接了上文"异常检测与智能告警"的工程要点。DC3 的告警与通知用规则引擎做确定性判断、用 dc3_rule_state 做状态机（触发/恢复/关闭）去抖动、用告警分级（P0–P3）与多渠道通知（邮件/SMS/Webhook）做降噪与分发——这是" 规则托底"的那一半，与上面"模型补强"的 AI 路径互补：规则覆盖写得出来的硬约束，AI 负责帮人理解与处置。

把三者放回那张闭环图：采集与分析由前几层与告警规则承担，决策在规则引擎或大模型，执行是告警通知或经确认的命令下发——AI 不是另起炉灶，而是接进了这条既有的"感知—决策—执行—反馈"链路。

数据智能与 AIoT ​

这一层是什么 / 为什么存在 ​

关键技术与权衡 ​

工程要点 ​

在 IoT DC3 中如何落地 ​

延伸阅读 ​

数据智能与 AIoT

这一层是什么 / 为什么存在

关键技术与权衡

工程要点

在 IoT DC3 中如何落地

延伸阅读