这份报告不讲华丽的行业案例，而是把底层的技术路线、最棘手的难点，以及已经被研究验证过的解法，一步步讲清楚。无论你有没有 AI 背景，都能读懂智能体在工厂数据链条上的真实作用。
在开始之前，先厘清几个会反复出现的词。它们听起来很"技术"，其实对应的都是很直观的概念。你可以随时回看这一节。
我们把整条工厂数据链路（采集 → 治理 → 分析 → 预测）研究了一遍，发现真正决定成败的，并不是某个炫酷的算法，而是下面这三件事。
无论是采集、治理、分析还是预测，它们其实都建立在同一套"数据底座"（DMK 湖）之上。就像四栋楼共用一个地基，地基不稳，上面都白搭。
最有效的做法，是把"统一语义底座 + 受控生成 + 人/数字孪生兜底"组合起来用，而不是指望某一项技术包打天下。
低风险的事可以放心交给 AI 全自动；一旦涉及写操作或对外下结论这种高风险环节，必须有人把关、有数字孪生兜底。
一个通用的 AI 智能体，可以拆成四个基本能力；而在工厂里，这些能力又被组织成"多智能体 + 统一数据底座 + 人把关"的形态。
下面这七个难题，几乎每一环都会碰到，是智能体能不能在工厂真正落地的关键瓶颈。我们给每个都配了一句大白话解释。
不同厂商、不同协议的设备，数据格式和单位都不一样，要让它们"说同一种话"非常难。这是后面治理、分析出错的根源。
→ 知识图谱 + 本体产线控制要求毫秒级响应，但数据绕到云端再回来就晚了。边缘算力又弱，跑不动大模型。
→ 边缘—云协同缺失、异常、格式混乱的数据直接拖垮 AI 的判断，必须靠规则校验兜底。
→ 数字孪生联动大模型可能一本正经地编出不存在的东西，放在生产场景后果很严重。
→ 检索增强 / 多智能体约束通用模型缺制造专业知识，而且它给的结论常常像个"黑箱"，让人不敢信。
→ 知识图谱 + 本体让 AI 去查数据库或调接口，很容易参数填错、越权操作，还很难发现。
→ 数字孪生 / 多智能体约束数据跨部门流通、AI 自己行动，会带来泄露和越权风险。
→ 人在回路 HITL这些解法不是和难点一一对应的——多数难题得"组合"着解。"统一底座 + 受控生成 + 人/孪生兜底"是贯穿全链的主线。
用"标准字典"把设备、工艺的语义固定下来，解决"语言不通"和"不懂行"（难点 ①⑤）。
让 AI 先查资料再开口，既压住幻觉、又把专业知识喂给它（难点 ④⑤）。
关键决策交真人兜底，对付幻觉和越权（难点 ④⑦）。
一个 AI 出方案、一个 AI 做检查，用规则拦住胡说（难点 ④⑥）。
边端小模型管急活、云端大模型管重活，解决慢的问题（难点 ②）。
先在虚拟分身里试一遍，校验预测和动作对不对（难点 ③⑥）。
一切的起点，是把车间里五花八门的信号，变成统一、带语义、能感知状态的数据流。底层路线分四步：接进来 → 边缘处理 → 统一汇聚 → 上云。
Modbus、OPC UA、MQTT 三套"方言"，数据模型、命名、单位各说各话，需要一层"信息模型/标准字典"来对齐。
云端来回加排队延迟，会破坏闭环控制；可边缘侧算力又弱，扛不住大模型。
生产网和办公网层级模型、网络隔离、安全策略都不同，打通不容易。
内存小、算力弱、还会断网，需要轻量运行时和"断网也能自治"（KubeEdge 内存可低至约 70MB）。
用 OPC UA 的 ISA-95 信息模型 + Modbus/MQTT 适配器，把异构设备封装成统一地址空间。
用 EdgeX / KubeEdge 做设备自动发现、协议互转、本地流式缓冲，不用事事上云。
以 MQTT 为骨干，用 Sparkplug B 状态机让"上线/掉线/变更"变得可感知。
边端 broker 就地决策，只把增量数据上云，模型/知识再回灌形成闭环。
采进来的原始数据还不能直接用。治理层要做的是：给数据贴标签、把不同来源对齐到同一套标准、用知识图谱固化语义、再自动编目。最稳妥的路线不是全交给黑箱模型，而是"标准字典 + 检索增强 + 多智能体校验 + 人把关"的组合。
设备、MES、ERP 多套系统各说各话，存在歧义和冲突。
老设备和历史资产没有结构化元数据，机器不认识。
主要表现为缺失和异常（注意：仅这两类，不要随意扩大成别的）。
本体工程依赖领域专家，周期长、投入大。
| 方法 | 效果 | 前提条件 |
|---|---|---|
| KG-RAG4SM | 精确率 +35.89% · F1 +30.50% | 医疗映射基准，对比 Jellyfish-8B |
| 多智能体 | 幻觉率降 85.5% | LLaMA-3-8B 块级 |
| Re-SHACL | 降时增效 | 推理 + 实体合并 + 形状校验结合 |
分析层要解决的，是把"业务人员的一句大白话"可靠地变成"可执行的数据操作"，再给出可信结论。四条主线要按顺序串起来：先取数并校验 → 再检索增强 → 复杂任务多智能体分工 → 关键处人把关。
把自然语言翻译成数据库查询，或映射到既有接口。DIN-SQL 用"拆解问题"的办法，CHESS 用四个各管一摊的智能体应对大库复杂查询。
让 AI 先查资料再分析，分反思、规划、调工具、多智能体四类模式，减少凭空编造。
AutoGen（会对话）、CrewAI（分角色）、LangGraph（状态编排）让"规划—取数—计算—校验"分头干。
写操作、对外结论、越权风险这些节点，设一道人工闸门。
预测环节正从"一次训好、静态不变"转向"以数据为中心、由智能体编排、能给出不确定范围、并交人把关"的新方式。最优路线是：轻量基础模型打底 + 智能体增强 + 数字孪生仿真 + 保形预测 + 人把关 + 服务化交付。
用 DCATS 式闭环，让 AI 自己清洗、增强数据，缓解"数据缺失"难题。
在虚拟分身里先预演，提前暴露"仿真和现实对不上"的风险。
用保形预测给出校准区间；数据变了（概念漂移）也能自适应。
关键预测由领域专家在 DMK 统一资源上审核、干预。
云端编排、边端小模型低延迟推理，做成随时可调用的服务。
把四环节合起来看，技术路线其实统一在一条主线上：以 DMK 湖为底座，沿着"协议适配/边缘 → 元数据抽取/本体 → 自然语言查数/检索增强/多智能体 → 提案验证精炼闭环/数字孪生"逐级贯通。最共性的解法，仍是"统一底座 + 受控生成 + 人/孪生兜底"。
先把 DMK 湖 / UNS 这套统一语义底座搭起来，别各建各的"烟囱"，后面才能互通。
低风险环节全自动；涉及写操作、对外下结论的高风险环节，强制人把关。
不必一上来就建全套本体，先"轻量字典 + 检索增强 + 人把关"，控制成本。
边端小模型管急活、云端大模型管重活，时延和可信性两头兼顾。