MQTT 只是入口：AI Agent 时代，IoT 平台要沉淀这五类资产

这组文章从 MQTT 写起。

设备消息进入平台后，我们陆续讨论了事件语义、设备说明书、异常处置、上下文、执行责任和云边分工。还有一个问题没有回答：这些能力最后会在 IoT 平台里留下什么？

可以从一次平台迁移说起。

一家企业准备更换用了多年的 IoT 平台。MQTT、Modbus、OPC UA 都能重新接入，网关配置好以后，数据也很快回到 Dashboard。

项目卡住的地方，不在协议。大家开始反复核对这些问题：

<span></span><code><span><span leaf="">T01 到底是哪一个温度？</span><span leaf=""><br></span><span leaf="">同一台设备为什么在三个系统里有三个编号？</span><span leaf=""><br></span><span leaf="">9℃ 在什么工况下算异常？</span><span leaf=""><br></span><span leaf="">这条告警为什么要和门磁、压缩机状态放在一起？</span><span leaf=""><br></span><span leaf="">谁有权远程重启？</span><span leaf=""><br></span><span leaf="">过去遇到同类问题，现场最后是怎么处理的？</span></span></code>

答案散在物模型、点位表、规则引擎、工单、Excel、代码，也散在现场人员的记忆里。

设备数据回来了，原平台对设备的理解却没有一起迁走。

以前尚且可以靠人补齐这层含义。Agent 开始参与判断和执行后，设备身份、事件含义、处置方法和动作边界都得由系统明确表达。否则，模型拿到的只是一批它并不熟悉的字段。

这些现场知识大致可以分成五类：

• 设备能力目录：说清设备是谁、在哪里、能读什么、能做什么；
• 事件模型：把状态变化组织成有业务含义的事件；
• 处置方法：告诉 Agent 遇到这类问题时怎么查、怎么处理；
• 执行规则：限定谁可以在什么条件下对哪些设备动手；
• 经过验证的记录：保留判断、审批、动作和现场结果。

它们比 Broker、数据库和大屏难搬，也更能看出一个平台对现场的理解到了哪一层。

01｜十万台设备在线，平台也可能看不懂现场

设备接入从来不是小事。

协议适配、连接稳定性、并发规模、数据存储和远程运维，任何一项做不好，平台都立不住。

接入量只能说明平台连了多少设备。它是否看得懂现场，要看另一组能力。

十万台设备持续上报：

<span></span><code><span><span leaf="">T01 = 9.4</span><span leaf=""><br></span><span leaf="">DI_07 = 1</span><span leaf=""><br></span><span leaf="">RUN = 1</span><span leaf=""><br></span><span leaf="">ALM_103 = true</span></span></code>

如果平台不知道字段含义、单位、设备关系、工况和业务影响，这十万台设备只是十万组持续变化的信号。

连接规模越大，这类噪声就越多。

过去很多平台项目依靠实施团队补上这层理解。工程师维护点位表，集成商写规则，现场人员看图判断，运维主管决定谁去处理。知识确实存在，只是没有被当成平台资产管理。

这种交付方式默认人会一直在场。Agent 遇到 ALM_103 时，却不应每次都去找人翻译，更不能凭一段告警文字决定是否控制设备。藏在配置和人脑里的知识，得先变成系统能查找、引用和校验的对象。

设备接入量是规模指标，不是设备理解能力。

02｜第一类资产：设备能力目录

平台首先要回答：这里有哪些设备，它们能做什么？

传统物模型、设备模板和点位表已经在做这件事的一部分，但经常停在“字段能不能采上来”。

给 Agent 使用的设备能力目录还要更完整：

• 设备是谁，属于哪个类型和版本；
• 安装在哪里，服务哪个业务对象；
• 有哪些属性、状态、事件和动作；
• 字段的单位、精度、更新时间和质量标记是什么；
• 与哪些设备、区域和系统有关；
• 动作参数有什么限制，结果如何返回。

例如，restart 不能只是一个按钮名称。

平台还要知道它重启的是传感器、网关还是控制器；会中断哪些数据；大约持续多久；是否影响下游设备；执行后用什么状态确认恢复。

W3C WoT Thing Description 用属性、动作和事件描述 Thing 的交互能力，OPC UA 则通过信息模型表达对象、关系和语义。平台不一定要照搬某一种标准，但分层思路值得保留：

通信协议负责“怎么连”，能力目录负责“连上来的东西到底是什么”。

这类资产最初可以来自设备厂商，现场实例和设备关系则需要平台与集成商补齐。设备换了位置、固件升级、动作参数变化以后，目录也要跟着更新。

一份多年不维护的设备说明书，比没有说明书更危险。

03｜第二类资产：事件模型

设备能力目录解释“它是什么”，事件模型解释“它发生了什么”。

还是冷柜温度：

<span></span><code><span><span leaf="">temperature = 9.4</span></span></code>

这是一条状态数据。

当平台知道正常温区是 2℃—8℃，温度已经连续 12 分钟超限，门磁关闭，压缩机持续运行，柜内还有高风险货品时，系统面对的才是一件需要处理的事。

一个有用的事件模型，至少要说清：

• 哪个对象发生了什么变化；
• 变化实际发生在什么时候；
• 从什么状态进入什么状态；
• 哪些证据支持这个判断；
• 可能影响哪些设备、人员或业务；
• 什么时候升级，什么时候可以结束。

CloudEvents 用 id、source、type、time 等属性统一描述事件上下文，Sparkplug 在 MQTT 之上补充 topic namespace、数据模型和状态管理。这些标准解决的是不同层的问题，但都说明了一件事：事件不能只剩一个没有出处的 payload。

事件模型没有必要追求字段数量。更实用的标准是：换一个项目，其中的骨架还能不能复用。

“温度连续超限”可以出现在冷库、冷链车、商超冷柜和实验室设备里。不同场景的阈值和影响不同，但对象、状态变化、证据、持续时间和恢复条件这些骨架可以共用。

平台每做一个项目都从零写告警规则，知识就留在项目里。

把它沉淀成可版本化的事件模型，下一次接入同类设备，平台才不是从头开始。

04｜第三类资产：处置方法

知道发生了什么，还不等于知道下一步怎么做。

温度持续升高，可能先查门磁、装卸作业和压缩机状态；网关频繁离线，可能先查供电、信号质量、固件版本和同站设备；电机振动异常，则要结合转速、负载和频谱判断。

这些检查顺序通常已经存在。

它们藏在 SOP、维修手册、工单模板、值班群记录和老师傅经验里。

在 Agentic IoT 里，这些方法可以整理成可复用的 Skill。但 Skill 不是一段万能提示词，也不是把整本说明书复制进去。

一份能长期使用的处置方法，要说清：

• 适用于哪类事件和设备；
• 开始前需要哪些证据；
• 先检查什么，后检查什么；
• 每一步如何记录结果；
• 缺少信息时问谁或查哪里；
• 满足什么条件可以结束；
• 哪些情况必须升级给人。

处置方法还要保留来源。

它来自设备厂商手册、企业 SOP，还是某次事故复盘？谁审核过？适用于哪一版设备和规则？如果没有这些信息，Agent 找到的只是一段看起来很像经验的文字。

Skill 还得引用设备能力目录和事件模型。

它不能自己假定所有冷柜都有相同传感器，也不能把某个现场特有的 topic 和设备编号写死。方法可以复用，设备事实必须从当前现场读取。

05｜第四类资产：执行规则

处置方法回答“建议怎么做”，执行规则回答“这一次能不能做”。

这两者经常混在一起。

SOP 里写着“必要时重启网关”，不代表任何 Agent 在任何时段都能执行重启。平台还要结合设备范围、当前状态、业务影响、人员权限和维护窗口作判断。

执行规则至少要管住：

• 哪个 Agent 可以申请什么动作；
• 哪些设备和参数在授权范围内；
• 什么状态下禁止执行；
• 是否需要人确认，由谁确认；
• 授权多久有效，能执行几次；
• 设备回执和现场结果如何验证；
• 超时或失败以后怎样停止、回退或升级。

这类规则过去分散在账号权限、Broker ACL、审批流程、代码分支和现场制度里。

平台如果只给 Agent 接一个工具接口，却没有把这些边界集中管理，工具越多，风险越难看清。

MCP 可以用名称、描述和输入 schema 把工具暴露给模型，也要求服务端校验输入、实施访问控制和限流。但“当前这台冷柜能不能调到 4℃”，仍然要由业务系统根据现场规则判断。

执行规则不能只留在安全部门的文档里。设备动作进入 Agent 调用链之前，平台就要用它完成校验。

06｜第五类资产：经过验证的事件与操作记录

平台里从来不缺日志。

缺的是能回答“上次到底发生了什么”的记录。

一条能被下次复用的历史，不能只写：

<span></span><code><span><span leaf="">温度告警，已处理。</span></span></code>

它应该能还原：

• 当时有哪些设备状态和业务条件；
• 哪些告警被归为同一次事件；
• Agent 和人分别作了什么判断；
• 使用了哪一版设备说明书、Skill 和执行规则；
• 谁批准了哪个动作；
• 设备返回了什么；
• 最后用什么条件确认恢复；
• 事后发现原判断哪里对、哪里错。

只有结果经过验证，这段历史才有资格进入下一次判断。

没有验证结果的工单，只能证明当时有人处理过，不能证明判断是对的。把这些记录全部放进向量数据库，Agent 只会更快地找到一批含糊的“已处理”。

经过验证的历史有两个作用。

一个是复盘。出了问题，系统能沿着证据、判断、批准、动作和结果还原全过程。

另一个是改进。平台可以发现某类事件经常缺少哪项证据，哪份 Skill 总被现场人员跳过，哪条执行规则过严或过松，再去更新前面四类资产。

<span></span><code><span><span leaf="">事件模型</span><span leaf=""><br></span><span leaf="">&nbsp; → 处置方法</span><span leaf=""><br></span><span leaf="">&nbsp; → 执行规则</span><span leaf=""><br></span><span leaf="">&nbsp; → 现场结果</span><span leaf=""><br></span><span leaf="">&nbsp; → 反过来修正前三者</span></span></code>

只有这条回路跑起来，现场经验才会进入下一版模型、Skill 和规则。

07｜模型可以换，现场知识不能每次重建

很多平台做 Agent，会先接入模型、增加聊天入口，再把说明书和工单放进向量数据库。这些组件都有用，也都可能更换。

模型接口、Agent 框架和检索组件会继续变。更换其中任何一项时，设备关系、事件含义、处置经验和执行边界应该继续可用。

提示词也要用同一个标准看待。没有来源、适用范围和测试用例的提示词，换个工程师就可能不敢改。它绑定了事件、设备、证据和验证结果以后，才是可维护的处置方法。

选哪个模型，影响的是当前效果。现场知识有没有管好，影响的是换了模型以后系统还能不能工作。

08｜叫它资产，就得能版本、能测试、能导出

五类内容若只能在配置页中查看和修改，还算不上受管理的资产。它们至少要满足下面几个条件。

有版本

设备固件、事件阈值、Skill 和执行规则发生变化，旧事件仍要能找到当时使用的版本。否则复盘时只能拿今天的规则解释昨天的决定。

有来源和负责人

谁提供、谁审核、适用于哪些设备和站点、多久没有更新，都要能查到。没有负责人的知识，很快就会过期。

能测试

事件模型要能用历史消息重放，Skill 要能用已知案例检查，执行规则要有允许和拒绝两类测试。不能只靠上线后看运气。

能关联

设备 ID、事件 ID、Skill 版本、策略版本、命令 ID 和工单 ID 要能串起来。五类资产如果仍然分散在五个系统里，Agent 每次都要重新猜关系。

能导出

客户要能拿走自己的设备模型、事件规则和处置方法。平台留住客户，应靠持续维护、验证和复用做得更好，不该靠客户无法导出。

能衡量

比起只看设备在线数，可以增加一些更接近理解能力的指标：

• 高价值设备的能力目录覆盖率；
• 高频异常的事件模型覆盖率；
• 处置方法被复用和验证的次数；
• 动作从申请到结果验证的成功率；
• 新站点接入后复用已有资产的比例；
• 有多少历史记录形成了可复用的结论。

这些指标不会替代连接稳定性和系统性能，但能告诉平台：接进来的设备，究竟有多少已经变得可理解、可处理和可追责。

09｜资产从项目里长出来

五类资产没有哪一家能单独写完。设备厂商掌握基础属性、状态和动作；集成商熟悉现场设备关系、协议差异和业务流程；用户决定风险边界、审批责任和什么结果才算问题解决。

平台要做的，是给这些知识提供统一表达、版本管理、运行时和审计链。Agent 可以整理资料、找出冲突、生成初稿，事实和边界仍然由掌握现场的人确认。

一套可行的分工是：

<span></span><code><span><span leaf="">设备厂商提供基础能力</span><span leaf=""><br></span><span leaf="">平台统一表达和运行</span><span leaf=""><br></span><span leaf="">集成商补齐现场关系</span><span leaf=""><br></span><span leaf="">用户定义业务边界并验证结果</span><span leaf=""><br></span><span leaf="">Agent 在这些资产之上判断和行动</span></span></code>

自动抽取可以加快建模，却不能一次完成建模。不经现场确认的目录，排版再整齐，也不会有人敢把它接入设备控制链。

这些资产会在交付和运维中持续变化。每接入一种设备、处理一次异常、批准一次动作，平台都应该留下一份经过验证的新知识。

10｜评估一个 IoT 平台，可以先问这五个问题

1. 更换平台时，能否连同设备含义、现场关系和动作限制一起导出？
2. 拿一段历史 MQTT 消息重放，能否稳定复现当时的事件和证据？
3. 每份 Skill 是否能查到来源、适用设备、版本、负责人和已验证案例？
4. 一次设备动作，能否从事件证据一直追溯到授权、命令、回执和现场结果？
5. 新项目接入同类设备时，有多少能力目录、事件模型和处置方法可以直接复用？

如果这五个问题都答不出来，平台接入的大多数还是信号，还没有变成 Agent 可以依赖的现场知识。

结尾｜MQTT 把消息送进来，平台要负责把知识留下来

连接、性能、稳定性和成本仍然是 IoT 平台的基本功。但 Agent 要进入现场，只有这些还不够。

它需要设备能力目录确认对象，需要事件模型理解变化，需要处置方法组织行动，需要执行规则限定边界，也需要经过验证的记录来修正下一次判断。

MQTT 把设备消息送进平台。一个项目做完以后，平台有没有留下可复用、可验证的现场知识，才是下一次交付能不能少走弯路的关键。

参考资料

1. 工业和信息化部，推动工业互联网平台高质量发展行动方案（2026—2028年）
https://www.miit.gov.cn/jgsj/xxjsfzs/wjfb/art/2026/art_fbb5945ae6344d0f8d171292c84a9389.html
2. W3C, Web of Things (WoT) Thing Description 1.1
https://www.w3.org/TR/wot-thing-description11/
3. OPC Foundation, OPC Unified Architecture
https://opcfoundation.org/about/opc-technologies/opc-ua/
4. Cloud Native Computing Foundation, CloudEvents Specification
https://github.com/cloudevents/spec/blob/main/cloudevents/spec.md
5. Model Context Protocol, Tools
https://modelcontextprotocol.io/specification/2025-11-25/server/tools
6. Eclipse Foundation, Sparkplug Specification 3.0.0
https://sparkplug.eclipse.org/specification/version/3.0/documents/sparkplug-specification-3.0.0.pdf

文章目录