简介围绕AI大模型与数字化工厂融合的专题演示文稿面向智能制造、工业软件及数字化转型领域的从业者与方案架构师。内容以工业4.0为背景系统阐述MES、WMS、SCADA与IoT多系统协同下的智能化工厂建设思路从技术架构、智能生产优化、物流仓储管理到人机协同决策、环境安全升级与实施保障均给出模块化阐述并具体涉及生产计划动态预测、质量追溯、预测性维护、AGV路径规划、供应链风险预警等落地场景。整个资料包共1个文件为pptx演示文稿大小约614KB结构完整清晰便于方案汇报、内部培训或在此基础上做二次整理。已有37人学习可作为快速理解AI大模型在数字化工厂中应用路径的参考。通过数据流闭环与持续迭代思路读者能抓住从感知、分析、决策到执行的整体框架适合用于项目预研与方案规划。1. AI 大模型赋能数字化工厂这套方案解决的不仅是报表是人机协同的最后一公里在 MESWMSSCADAIoT 已经跑了一两年的工厂里最不缺的就是数据和报表最缺的反而是“人怎么跟这一堆系统对话”。AI 大模型进数字化工厂落点不是做一个花哨的聊天机器人而是把人从“扒数据、对字段、猜原因”里解放出来。这套人机一体化智慧解决方案本质是在已有的制造执行、仓储管理、过程监控和设备物联四层体系之上加一层 AI 推理与交互中枢。适合正在做数字化转型规划、或者已经在用 MES/WMS 但觉得系统越来越重的工厂 IT、MES 产品经理和售前方案人员。方案的价值不在 PPT 多华丽而在能不能回答一个最简单的问题车间里的普通人今天能不能用一句话拿到本来要翻三个系统才能凑齐的答案。2. 先理清四个系统的边界MES、WMS、SCADA、IoT 在 AI 大模型方案里各自扮演什么角色2.1 四个系统是数据源而不是终点AI 大模型要接哪几类数据数字化工厂的现状是MES 管工单和质量WMS 管物料批次和库位SCADA 管过程参数和报警IoT 管设备状态和点检。这四个系统本来就各拉各的数据报表上一看都是“数字化”。但 AI 大模型方案要的不是报表而是要在这四套数据之上形成推理能力。所以第一步不是选模型而是把数据边界画清楚。MES 系统这边AI 最需要的是未结工单、工艺路线、物料清单、质检记录这四类。工单是排产和调度推理的锚点质检记录是质量归因的样本工艺路线是 SOP 问答的依据。这里有个极易踩的坑MES 里字段名跟业务叫法不一致。比如系统里叫 res_code车间叫机台号提示词喂进去之前必须做一层字段映射否则大模型会理解错。WMS 系统给 AI 的是库存水位、批次效期、库区和出库波次。关键不是 WMS 的单据而是“齐套率”这种跨系统语义。齐套率等于物料可用量除以工单需求量可用量在 WMS需求量在 MESAI 要同时看到两边才能回答“3 号工单能不能开工”。这就决定了你在设计接入层时不能按系统分接口而要按语义组装上下文。SCADA 的数据比较特殊它是时序的每秒一条。AI 大模型没法把几百万条时序点塞进上下文窗口。常见的做法是让接入网关先做形态变换稳定段取均值波动段取最大值、最小值和斜率再把压缩后的特征文本送给大模型。国内主流的中控 SCADA、开源领域的 Rapid SCADA 都提供点位读取接口但读点位这个动作不能放在提示词里让模型自己来要通过程序把点位状态先翻译成文本。IoT 设备层给出的则是振动、温度、电流等传感器数据。相比 SCADAIoT 更偏设备健康管理数据分散在边缘网关或时序数据库里。AI 在这一层的主要用途是设备告警归因和设备手册问答。IoT 数据的单位、采集频率、传感器位置命名最好在接入层就统一掉否则模型会被“10 号传感器”这种歧义搞到胡言乱语。我给客户的第一个交付物从来不是模型而是一张数据地图包含四列系统、取数接口、关键字段、更新频率。这张图确定了再谈选哪个模型、上下文怎么做片段化。没有这张基础图后面提示词写得再漂亮也是空中楼阁。2.2 人机一体化落点AI 在制造执行层和仓储物流层的五个切入场景“人机一体化”不是把 AI 挂成系统旁边的一个问答框而是让人在关键决策点上用自然语言讲清需求系统拿真实数据加模型推理把结果回给用户。我从项目里筛出五个验证过最容易被业务接受的场景。场景一是排产辅助。计划员问“明天 A 线能不能插单”AI 要拉取 A 线当前工单、在制 WIP、物料齐套率、设备状态再结合交期输出一句话建议和理由。这个场景不需要模型自己写 SQL需要的是模型能组织并解释结构化数据所以上下文质量比模型智商更重要。场景二是质量异常的根因归因。检验员发现连续三件产品尺寸超差AI 把近两小时的压力、温度、转速特征曲线和这批次的物料批次、设备编号一起做关联分析。它不直接下结论而是给出“压力波动与尺寸超差相关性最高建议优先检查三号工位夹具”这类可操作线索。这里的边界是AI 是线索生成器不是质量判定系统。场景三是 SCADA 报警解释。半夜响起报警值班员最痛苦的是看不懂报警码。SCADA 触发 P-105 泵压力低报警时AI 结合设备台账、历史维修记录生成一段“报警原因、影响范围、建议处置”的解释。值班员能一眼决定是跑现场还是继续观察这是价值最直观的场景因为报警码翻译这件事没有歧义空间模型翻车也少。场景四是 WMS 波次策略。仓库主管问“今晚这批订单用边拣边分还是按单拣货”AI 看订单件型、库区分布、拣货设备忙闲给出建议。这里要非常克制模型只给建议执行还是由 WMS 完成人保留最终确认权。场景五是设备运维问答。维护员问“主轴异响一般先查什么”AI 基于设备手册、维修工单、备件库存做检索增强问答。这是最容易落地也最容易出效果的场景因为数据和答案边界都很清晰而且不涉及实时决策容错空间大。五个场景有个共性AI 大模型一定是在“有据可查”的上下文里输出。凡是靠模型自由发挥的最后都会翻车。这决定了方案里必须要有数据接入层、上下文组装层和模型调用层而不是直接把公开问答模型对着 ERP 数据库莽上去。3. 把 AI 大模型接进 MES/WMS/SCADA可落地的技术架构与调用链路3.1 基于什么技术栈封装 AI 交互逻辑RAG、工具调用和 SSE 流式输出的分工在工厂场景里谈技术栈最容易犯的错是把所有交互都做成“聊天框”。实际操作上我按三种场景拆交互逻辑。知识库类问答比如设备手册、工艺文件、工单查询用 RAG 检索增强。先根据问题向量召回相关片段再连同问句一起交给大模型。这类交互逻辑对实时性要求不高但对答案的可溯源性要求高用户要能点回原文。需要查实时数据或者触发动作的用工具调用。让大模型先输出一个结构化意图比如查询库存、查询设备状态再由网关里的函数去执行并拿结果返回给模型组织语言。这里的关键是工具清单要收敛不要放十几个函数进去模型会选错。我一般控制在三到五个核心工具。输出长内容时必须用 SSE 流式输出把增量文本一点点推到前端做实时渲染而不是等几十秒后一次性吐一屏。配合前端 AbortController 的 Abort 能力用户点击“停止生成”后前端中断渲染后端连接也断开不再继续空跑算力。这三个组合下来技术栈基本固定后端 Python FastAPI 做网关前端标准 EventSource 或 fetch ReadableStream模型层走 OpenAI 兼容协议方便在云端 API 和本地部署之间无痛切换。3.2 用 Python 搭一个 AI 推理网关对接 MES 工单、返回排产建议的代码骨架下面是一个最小可跑的 AI 推理网关读取 MES 未结工单组装上下文再通过 SSE 流式把大模型回答回给前端。这段代码只做一件事跑通 MES 到模型到浏览器的完整链路。# ai_gateway.py —— AI 推理网关最小骨架 from fastapi import FastAPI, Request from fastapi.responses import StreamingResponse import httpx app FastAPI() MES_API http://mes-service:8080 # MES 系统接口地址 LLM_API http://llm-server:8000/v1/chat/completions # 本地大模型 API def pull_open_orders(): 从 MES 拉取未结工单压缩成适合提示词的紧凑文本 resp httpx.get( f{MES_API}/api/v1/work-orders, params{status: OPEN, within: 48h}, timeout5 ) orders resp.json().get(data, []) lines [] for o in orders[:15]: # 最多 15 条防止上下文超过窗口限制 lines.append( f工单{o.get(order_no)}产品{o.get(product_name)} f数量{o.get(plan_qty)}设备{o.get(line_no, 未分配)} f交期{o.get(due_time)} ) return \n.join(lines) def stream_llm(messages): 把请求转发给大模型逐行读取 SSE 事件并转发给前端 payload { model: local-model-name, # 按实际部署的模型名替换 messages: messages, stream: True, temperature: 0.2, } with httpx.stream(POST, LLM_API, jsonpayload, timeout120) as resp: for line in resp.iter_lines(): if line.startswith(data: ) and line ! data: [DONE]: yield line[6:] \n app.post(/chat) async def chat(req: Request): body await req.json() question body.get(question, ) orders_ctx pull_open_orders() messages [ {role: system, content: 你是工厂排产助理。只能依据给定的工单信息回答不编造工单不修改物料编码。}, {role: user, content: f当前未结工单如下\n{orders_ctx}\n\n问题{question}} ] return StreamingResponse(stream_llm(messages), media_typetext/event-stream)这段代码里几个参数值得单独说。pull_open_orders 里 timeout5 是刻意设的MES 接口变慢时网关要快速失败而不是让用户等模型干等两分钟。[:15] 切片是为了控制上下文长度15 条工单约一千来个字给模型留出推理余量。temperature 设在 0.2排产建议这种场景要低随机性。stream_llm 里排除掉 [DONE] 标记只把有效内容转发出去。前端这边配合的是 fetch 加流式读取加上 AbortController 控制中断。// 前端流式渲染 Abort 控制 const controller new AbortController(); async function askAI(question) { const resp await fetch(/chat, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ question }), signal: controller.signal, }); const reader resp.body.getReader(); const decoder new TextDecoder(); let content ; while (true) { const { done, value } await reader.read(); if (done) break; content decoder.decode(value, { stream: true }); renderStreamingContent(content); // 把增量文本实时渲染到页面 } } // 用户点“停止”时调用 document.getElementById(stopBtn).onclick () controller.abort();AbortController 在这里的价值不只是省流量的。工厂现场工控机上网络不稳定用户发出一个长问题模型回答到一半用户已经拿到想要的判断这时候让他等完整回答是反人性的。有 abort 能力用户能随时打断后端 StreamingResponse 感知连接断开后也会停止生成算力不浪费。3.3 把 SCADA 与 IoT 实时数据喂给大模型时序切片与上下文窗口的取舍SCADA 和 IoT 数据是最难喂给大模型的根本原因是量级不匹配。一套中控 SCADA 系统一个车间就可能上万个点位一秒一条数据一天数据能到亿级。直接把原始序列丢给模型任何上下文窗口都撑不住。我的做法是三层处理。第一层是采样降频。对稳定运行的连续变量比如冷却水温直接取五分钟均值就够了。对波动型变量比如压力、电流额外记录最大值、最小值和变化率。第二层是事件切片。只在报警触发或质量异常时才把前后五分钟的特征值提取出来组装上下文平时不调用模型节省推理成本。第三层是点位映射。设备编号、传感器编码全部转换成业务语言再进提示词比如 sensor_03 写成“三号工位主轴温度”。IoT 侧还要多做一件事边缘网关先做清洗。振动传感器经常有毛刺数据不先做滤波模型会基于噪声做归因结论完全不可用。趋势大于精确值这是 SCADA 和 IoT 数据接入的准则。4. 本地部署与 API 调用怎么选算力、延迟和数据不出厂约束下的决策4.1 先算三笔账显存、并发、延迟本地部署 AI 大模型这件事在方案 PPT 里一句话落地时是纯算力问题。做决策前先算三笔账。第一笔是显存。模型参数量决定显存下限。工厂场景绝大多数任务用 7B 到 14B 参数量级别的模型就够不需要上超大模型。16G 显存的消费级卡刚好能跑 4bit 量化后的 7B 模型做验证但生产环境我建议至少 24G 起步留出并发余量。第二笔是并发。工厂里的 AI 方案不会像互联网那样有几万用户同时在线但早班交班那十分钟操作员会集中提问。并发哪怕只有五个显存也要按五份算。手里一张卡跑一个模型并发上来后每请求延迟成倍增加。第三笔是延迟容忍度。排产问答要求十秒内返回操作员等不了。质量归因分析可以接受一两分钟毕竟是离线式的深度分析。RAG 类问答要控制在五秒以内这里面大模型推理时间可能只占一半另一半是检索时间。三种场景混在一个模型服务里时我一般按最高要求设超时也就是十秒。再长就直接提示失败不要吊着用户。通用参考配置如下表。量化位数越低显存占用越少但输出质量会轻微下降核心业务场景别低于 4bit。模型规模显存需求16bit 全精度显存需求4bit 量化适合场景7B-8B 级别16-24GB6-10GB排产问答、报警解释、RAG 问答13B-14B 级别32-48GB12-20GB复杂归因、长文档理解70B 级别140GB 多卡40GB 多卡全场景统一模型代价高4.2 本地部署的推荐启动方式与参数一次别贪多本地部署我习惯用支持 OpenAI 兼容接口的推理框架这样上层代码不用绑死某个服务。下面是 vLLM 框架启动一个量化模型的参考命令生产环境我会加几个关键参数。# 本地部署大模型vLLM 启动参考命令 python -m vllm.entrypoints.openai.api_server \ --model /data/models/factory-7b-awq \ --served-model-name factory-llm \ --quantization awq \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --max-num-seqs 4 \ --host 0.0.0.0 \ --port 8000--max-model-len 设 8192这是工厂上下文的合理值。设太大显存不够设太小工单列表加系统提示词就溢出了。--gpu-memory-utilization 设 0.85不跑满显存给 KV cache 留余量也避免偶发峰值导致 OOM。--max-num-seqs 控制同时处理的请求数设 4 对企业内一个小团队足够峰值时后面的请求排队而不是挤爆显存。--served-model-name 是让网关调用的名字代码里 model 参数对应这个值。很多团队一上来就部署 70B 大模型结果一张卡跑不动量化后效果变差最后怪模型不行。我的实际经验先把 7B 级别在当前车间跑顺几个场景再评估要不要升级。工厂场景的专业性不在模型大小在上下文质量。4.3 用云端 API 快速验证效果再无缝切到本地方案初期可以用成熟大模型 API 验证提示词和场景效果。等确认了 prompt 模板和上下文组装逻辑后再切到本地部署。切换的成本几乎为零因为本地推理框架普遍提供 OpenAI 兼容接口。# 切换 base_url 就能从云端 API 迁移到本地模型 from openai import OpenAI client OpenAI( base_urlhttp://10.10.1.15:8000/v1, # 本地推理服务地址 api_keylocal-key-placeholder, # 本地服务通常不校验但参数必须存在 ) resp client.chat.completions.create( modelfactory-llm, # 对应 --served-model-name messages[ {role: system, content: 你是工厂车间调度助手能看懂 MES 工单上下文。}, {role: user, content: 帮我检查 3 号工单的物料是否齐套。} ], streamTrue, temperature0.3, ) for chunk in resp: if chunk.choices[0].delta.content: print(chunk.choices[0].delta.content, end)注意 api_key 这里纯粹占位。本地服务大多不校验密钥但 SDK 要求传这个字段。迁移时改动就 base_url 一行业务代码不用动这个便利性在方案验证阶段能省下大量返工。4.4 提示词温度与上下文窗口的参数设置分场景不要一套打天下模型参数不是玄学但在工厂场景里确实需要分场景设置。排产建议追求稳定可解释temperature 设在 0.2 附近。质量归因需要一点发散来找线索可以放到 0.4但再高就满嘴跑火车了。设备维修问答严格按照手册来0.1 比较稳。top_p 我一般不单独调保持默认即可。上下文窗口是更值得花心思的地方。8K 上下文对单个场景足够但要注意系统提示词本身会占掉一部分。MES 工单列表和 SCADA 特征值加起来控制在 3000 字以内给工具调用结果和模型回答留出空间。如果场景需要引入历史对话建议只在最后两轮内回放对话历史是上下文占用的隐形杀手。Prompt 模板也要工程化。我通用模板里固定三段角色定义、数据来源声明、约束条件。角色定义写明你是谁数据来源声明写明本次回答只能依赖哪些信息约束条件写明禁止做什么比如禁止编造工单、禁止修改物料编码。三段结构清晰后换场景只换中间的数据部分不用重新设计提示词。5. 避坑指南AI 大模型进工厂最常见的 5 个翻车现场5.1 现象模型一本正经地推荐参数对应 SCADA 点位却根本没采集方案验证时AI 对设备状态做了详尽的归因分析指出了某个变量异常。结果下车间核查发现那个点位压根不存在是设备台账里淘汰的传感器还在配置文件里留名。模型不知道实时点位在线状态只能凭历史文本里的“残影”推理。原因是接入层没有把点位在线状态追加进上下文。模型以为给它的数据都真实存在但历史数据里埋着废弃点位。解决在系统提示词前先注入一段点位状态表列出“在线点位清单和最后更新时间”并明确告知模型“不在清单内的点位不可引用”。同时接入层定期同步 SCADA 点位配置把废弃点位从历史数据源里标记掉。5.2 现象SSE 流式输出到一半断流界面一直转菊花前端通过 SSE 接大模型输出回答到一半就不动了刷新页面重问一次又正常但第二次断得更早。排查发现工厂现场网络走了转发代理代理对响应内容做了缓冲缓冲区一满就掐断。原因是中间链路不支持流式转发。厂区网络设备、反向代理默认会缓存响应体SSE 这种长连接被缓存策略埋在中间。解决在反向代理配置里关闭响应缓冲把 SSE 接口的代理缓存设为 off同时给响应头加上 cache-control 加 no-cache、x-加速-过期头等参数。前端侧也要做自动重连断流后基于已渲染内容重新发起请求而不是让用户手动刷新。注意重连时应带上最后一条已收到的消息序号避免重复生成。5.3 现象大模型把物料编码“好心”改成了不存在的编码质量归因场景里模型识别出某个物料批次号“疑似拼写错误”自动给它纠正成了另一串编码。这个问题最隐蔽因为结果看起来合理实际已经污染了 MES 里的追溯链。原因是模型默认在做一个“助手”倾向于修复它认为的错误。物料编码是工厂系统的强约束键一旦被修改关联关系就断了。解决在 system prompt 里明确写“所有编码类字段必须原样复制禁止修正”。同时在网关层加一道规则校验让模型输出经过一层实体校验器凡是不在 MES 字典里的编码一律拦截并提示人工确认。这是提示词和工程规则双保险缺一不可。5.4 现象把大模型当数据库问它“上周 A 线良率多少”时一本正经地编数据业务问“上周 A 线良率多少”AI 回了“约 95%”。后来核对实际只有 91%。模型也不是故意撒谎它根本看不到统计数据只能根据上下文里的只言片语“合理猜测”。原因是把模型当成了数据库引擎。大模型擅长归纳文本和生成建议不擅长精确查询特别是数值型结果。解决这类问题不应该让模型从记忆里生成答案而要走工具调用。网关里挂一个统计查询函数模型识别到意图后调用函数拉取 MES 的报表接口得到真实数字后再组织语言。核心原则是凡是数据库能直接回答的不让模型代劳。前端如果发现是查数类问题也可以直接走报表接口连模型都不用调。5.5 现象本地模型服务响应越来越慢最后直接显存溢出刚部署时响应三秒用了一个月后变成三十秒最后直接 OOM 崩溃。运维以为是模型被“聊傻了”重启后好一天又复发。原因是会话历史无节制地堆积。每次对话都把整个 session 历史一起发给模型上下文越积越长KV cache 占用越来越大。解决网关层做会话窗口管理。只保留最近三轮对话和最近一次工具查询结果超出部分摘要后丢弃。另外设置单会话最大 token 数接近阈值时强制截断并提示用户开了新会话。工厂场景的操作员会话都比较短通常两三轮就结束这个策略对业务无损但对系统稳定性帮助极大。6. 怎么验证这套方案值得投入三条评估线加一个记录表方案值不值得做不能只看演示时效果惊艳要看几个月后的使用率和业务认可度。我习惯用三条评估线来验证。第一条是决策支持覆盖线。把工厂里高频的排产、质量、设备、仓储问题列成清单统计 AI 能给出有效建议的比例。刚开始可能只有四成目标是通过迭代提示词场景到七成以上。覆盖率的提升速度直接反映方案投入的有效性。第二条是人机协同耗时线。记录一个排产员订一个工单全流程需要多长时间上线后同样流程缩了多少。这里要注意只看回答速度没用要看全流程闭环速度。AI 三秒给建议但操作员还要去 MES 里手工执行如果系统间没有联动那 AI 的价值就被砍掉大半。第三条是建议采纳线。统计 AI 给出的排产建议、报警解释被用户采纳的比例。这个比例低于五成说明提示词或者上下文数据没喂对高于八成说明场景选得准。建议采纳率比回答速度更能反映真实质量。配套做法是建一张 AI 输出日志表。字段包括问题、上下文摘要、模型回答、用户是否采纳、人工做了哪些修改。这张表积累一个月就能看清哪些场景真正创造价值哪些场景纯粹是花架子。我见过太多项目上线热两周第三周就没人用了原因就是没记录、没分析、没迭代。投入这套方案之前建议先用开源 MES 或现成测试环境跑通最小链路拿真实工单数据验证一到两个场景再决定是否全面铺开。工厂不像互联网可以随时回滚系统一旦上线就牵扯生产。先小范围试错再扩大战果。最后说一个我自己的习惯任何方案文档我都会多留一页写“不做什么”凡是涉及生产安全的决策AI 永远只给建议人永远握最终拍板权。守住这条项目就守住了底线。希望帮到你。本文还有配套的精品资源点击获取 AI大模型赋能数字化工厂：打通MES/WMS/SCADA人机协同最后一公里
简介围绕AI大模型与数字化工厂融合的专题演示文稿面向智能制造、工业软件及数字化转型领域的从业者与方案架构师。内容以工业4.0为背景系统阐述MES、WMS、SCADA与IoT多系统协同下的智能化工厂建设思路从技术架构、智能生产优化、物流仓储管理到人机协同决策、环境安全升级与实施保障均给出模块化阐述并具体涉及生产计划动态预测、质量追溯、预测性维护、AGV路径规划、供应链风险预警等落地场景。整个资料包共1个文件为pptx演示文稿大小约614KB结构完整清晰便于方案汇报、内部培训或在此基础上做二次整理。已有37人学习可作为快速理解AI大模型在数字化工厂中应用路径的参考。通过数据流闭环与持续迭代思路读者能抓住从感知、分析、决策到执行的整体框架适合用于项目预研与方案规划。1. AI 大模型赋能数字化工厂这套方案解决的不仅是报表是人机协同的最后一公里在 MESWMSSCADAIoT 已经跑了一两年的工厂里最不缺的就是数据和报表最缺的反而是“人怎么跟这一堆系统对话”。AI 大模型进数字化工厂落点不是做一个花哨的聊天机器人而是把人从“扒数据、对字段、猜原因”里解放出来。这套人机一体化智慧解决方案本质是在已有的制造执行、仓储管理、过程监控和设备物联四层体系之上加一层 AI 推理与交互中枢。适合正在做数字化转型规划、或者已经在用 MES/WMS 但觉得系统越来越重的工厂 IT、MES 产品经理和售前方案人员。方案的价值不在 PPT 多华丽而在能不能回答一个最简单的问题车间里的普通人今天能不能用一句话拿到本来要翻三个系统才能凑齐的答案。2. 先理清四个系统的边界MES、WMS、SCADA、IoT 在 AI 大模型方案里各自扮演什么角色2.1 四个系统是数据源而不是终点AI 大模型要接哪几类数据数字化工厂的现状是MES 管工单和质量WMS 管物料批次和库位SCADA 管过程参数和报警IoT 管设备状态和点检。这四个系统本来就各拉各的数据报表上一看都是“数字化”。但 AI 大模型方案要的不是报表而是要在这四套数据之上形成推理能力。所以第一步不是选模型而是把数据边界画清楚。MES 系统这边AI 最需要的是未结工单、工艺路线、物料清单、质检记录这四类。工单是排产和调度推理的锚点质检记录是质量归因的样本工艺路线是 SOP 问答的依据。这里有个极易踩的坑MES 里字段名跟业务叫法不一致。比如系统里叫 res_code车间叫机台号提示词喂进去之前必须做一层字段映射否则大模型会理解错。WMS 系统给 AI 的是库存水位、批次效期、库区和出库波次。关键不是 WMS 的单据而是“齐套率”这种跨系统语义。齐套率等于物料可用量除以工单需求量可用量在 WMS需求量在 MESAI 要同时看到两边才能回答“3 号工单能不能开工”。这就决定了你在设计接入层时不能按系统分接口而要按语义组装上下文。SCADA 的数据比较特殊它是时序的每秒一条。AI 大模型没法把几百万条时序点塞进上下文窗口。常见的做法是让接入网关先做形态变换稳定段取均值波动段取最大值、最小值和斜率再把压缩后的特征文本送给大模型。国内主流的中控 SCADA、开源领域的 Rapid SCADA 都提供点位读取接口但读点位这个动作不能放在提示词里让模型自己来要通过程序把点位状态先翻译成文本。IoT 设备层给出的则是振动、温度、电流等传感器数据。相比 SCADAIoT 更偏设备健康管理数据分散在边缘网关或时序数据库里。AI 在这一层的主要用途是设备告警归因和设备手册问答。IoT 数据的单位、采集频率、传感器位置命名最好在接入层就统一掉否则模型会被“10 号传感器”这种歧义搞到胡言乱语。我给客户的第一个交付物从来不是模型而是一张数据地图包含四列系统、取数接口、关键字段、更新频率。这张图确定了再谈选哪个模型、上下文怎么做片段化。没有这张基础图后面提示词写得再漂亮也是空中楼阁。2.2 人机一体化落点AI 在制造执行层和仓储物流层的五个切入场景“人机一体化”不是把 AI 挂成系统旁边的一个问答框而是让人在关键决策点上用自然语言讲清需求系统拿真实数据加模型推理把结果回给用户。我从项目里筛出五个验证过最容易被业务接受的场景。场景一是排产辅助。计划员问“明天 A 线能不能插单”AI 要拉取 A 线当前工单、在制 WIP、物料齐套率、设备状态再结合交期输出一句话建议和理由。这个场景不需要模型自己写 SQL需要的是模型能组织并解释结构化数据所以上下文质量比模型智商更重要。场景二是质量异常的根因归因。检验员发现连续三件产品尺寸超差AI 把近两小时的压力、温度、转速特征曲线和这批次的物料批次、设备编号一起做关联分析。它不直接下结论而是给出“压力波动与尺寸超差相关性最高建议优先检查三号工位夹具”这类可操作线索。这里的边界是AI 是线索生成器不是质量判定系统。场景三是 SCADA 报警解释。半夜响起报警值班员最痛苦的是看不懂报警码。SCADA 触发 P-105 泵压力低报警时AI 结合设备台账、历史维修记录生成一段“报警原因、影响范围、建议处置”的解释。值班员能一眼决定是跑现场还是继续观察这是价值最直观的场景因为报警码翻译这件事没有歧义空间模型翻车也少。场景四是 WMS 波次策略。仓库主管问“今晚这批订单用边拣边分还是按单拣货”AI 看订单件型、库区分布、拣货设备忙闲给出建议。这里要非常克制模型只给建议执行还是由 WMS 完成人保留最终确认权。场景五是设备运维问答。维护员问“主轴异响一般先查什么”AI 基于设备手册、维修工单、备件库存做检索增强问答。这是最容易落地也最容易出效果的场景因为数据和答案边界都很清晰而且不涉及实时决策容错空间大。五个场景有个共性AI 大模型一定是在“有据可查”的上下文里输出。凡是靠模型自由发挥的最后都会翻车。这决定了方案里必须要有数据接入层、上下文组装层和模型调用层而不是直接把公开问答模型对着 ERP 数据库莽上去。3. 把 AI 大模型接进 MES/WMS/SCADA可落地的技术架构与调用链路3.1 基于什么技术栈封装 AI 交互逻辑RAG、工具调用和 SSE 流式输出的分工在工厂场景里谈技术栈最容易犯的错是把所有交互都做成“聊天框”。实际操作上我按三种场景拆交互逻辑。知识库类问答比如设备手册、工艺文件、工单查询用 RAG 检索增强。先根据问题向量召回相关片段再连同问句一起交给大模型。这类交互逻辑对实时性要求不高但对答案的可溯源性要求高用户要能点回原文。需要查实时数据或者触发动作的用工具调用。让大模型先输出一个结构化意图比如查询库存、查询设备状态再由网关里的函数去执行并拿结果返回给模型组织语言。这里的关键是工具清单要收敛不要放十几个函数进去模型会选错。我一般控制在三到五个核心工具。输出长内容时必须用 SSE 流式输出把增量文本一点点推到前端做实时渲染而不是等几十秒后一次性吐一屏。配合前端 AbortController 的 Abort 能力用户点击“停止生成”后前端中断渲染后端连接也断开不再继续空跑算力。这三个组合下来技术栈基本固定后端 Python FastAPI 做网关前端标准 EventSource 或 fetch ReadableStream模型层走 OpenAI 兼容协议方便在云端 API 和本地部署之间无痛切换。3.2 用 Python 搭一个 AI 推理网关对接 MES 工单、返回排产建议的代码骨架下面是一个最小可跑的 AI 推理网关读取 MES 未结工单组装上下文再通过 SSE 流式把大模型回答回给前端。这段代码只做一件事跑通 MES 到模型到浏览器的完整链路。# ai_gateway.py —— AI 推理网关最小骨架 from fastapi import FastAPI, Request from fastapi.responses import StreamingResponse import httpx app FastAPI() MES_API http://mes-service:8080 # MES 系统接口地址 LLM_API http://llm-server:8000/v1/chat/completions # 本地大模型 API def pull_open_orders(): 从 MES 拉取未结工单压缩成适合提示词的紧凑文本 resp httpx.get( f{MES_API}/api/v1/work-orders, params{status: OPEN, within: 48h}, timeout5 ) orders resp.json().get(data, []) lines [] for o in orders[:15]: # 最多 15 条防止上下文超过窗口限制 lines.append( f工单{o.get(order_no)}产品{o.get(product_name)} f数量{o.get(plan_qty)}设备{o.get(line_no, 未分配)} f交期{o.get(due_time)} ) return \n.join(lines) def stream_llm(messages): 把请求转发给大模型逐行读取 SSE 事件并转发给前端 payload { model: local-model-name, # 按实际部署的模型名替换 messages: messages, stream: True, temperature: 0.2, } with httpx.stream(POST, LLM_API, jsonpayload, timeout120) as resp: for line in resp.iter_lines(): if line.startswith(data: ) and line ! data: [DONE]: yield line[6:] \n app.post(/chat) async def chat(req: Request): body await req.json() question body.get(question, ) orders_ctx pull_open_orders() messages [ {role: system, content: 你是工厂排产助理。只能依据给定的工单信息回答不编造工单不修改物料编码。}, {role: user, content: f当前未结工单如下\n{orders_ctx}\n\n问题{question}} ] return StreamingResponse(stream_llm(messages), media_typetext/event-stream)这段代码里几个参数值得单独说。pull_open_orders 里 timeout5 是刻意设的MES 接口变慢时网关要快速失败而不是让用户等模型干等两分钟。[:15] 切片是为了控制上下文长度15 条工单约一千来个字给模型留出推理余量。temperature 设在 0.2排产建议这种场景要低随机性。stream_llm 里排除掉 [DONE] 标记只把有效内容转发出去。前端这边配合的是 fetch 加流式读取加上 AbortController 控制中断。// 前端流式渲染 Abort 控制 const controller new AbortController(); async function askAI(question) { const resp await fetch(/chat, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ question }), signal: controller.signal, }); const reader resp.body.getReader(); const decoder new TextDecoder(); let content ; while (true) { const { done, value } await reader.read(); if (done) break; content decoder.decode(value, { stream: true }); renderStreamingContent(content); // 把增量文本实时渲染到页面 } } // 用户点“停止”时调用 document.getElementById(stopBtn).onclick () controller.abort();AbortController 在这里的价值不只是省流量的。工厂现场工控机上网络不稳定用户发出一个长问题模型回答到一半用户已经拿到想要的判断这时候让他等完整回答是反人性的。有 abort 能力用户能随时打断后端 StreamingResponse 感知连接断开后也会停止生成算力不浪费。3.3 把 SCADA 与 IoT 实时数据喂给大模型时序切片与上下文窗口的取舍SCADA 和 IoT 数据是最难喂给大模型的根本原因是量级不匹配。一套中控 SCADA 系统一个车间就可能上万个点位一秒一条数据一天数据能到亿级。直接把原始序列丢给模型任何上下文窗口都撑不住。我的做法是三层处理。第一层是采样降频。对稳定运行的连续变量比如冷却水温直接取五分钟均值就够了。对波动型变量比如压力、电流额外记录最大值、最小值和变化率。第二层是事件切片。只在报警触发或质量异常时才把前后五分钟的特征值提取出来组装上下文平时不调用模型节省推理成本。第三层是点位映射。设备编号、传感器编码全部转换成业务语言再进提示词比如 sensor_03 写成“三号工位主轴温度”。IoT 侧还要多做一件事边缘网关先做清洗。振动传感器经常有毛刺数据不先做滤波模型会基于噪声做归因结论完全不可用。趋势大于精确值这是 SCADA 和 IoT 数据接入的准则。4. 本地部署与 API 调用怎么选算力、延迟和数据不出厂约束下的决策4.1 先算三笔账显存、并发、延迟本地部署 AI 大模型这件事在方案 PPT 里一句话落地时是纯算力问题。做决策前先算三笔账。第一笔是显存。模型参数量决定显存下限。工厂场景绝大多数任务用 7B 到 14B 参数量级别的模型就够不需要上超大模型。16G 显存的消费级卡刚好能跑 4bit 量化后的 7B 模型做验证但生产环境我建议至少 24G 起步留出并发余量。第二笔是并发。工厂里的 AI 方案不会像互联网那样有几万用户同时在线但早班交班那十分钟操作员会集中提问。并发哪怕只有五个显存也要按五份算。手里一张卡跑一个模型并发上来后每请求延迟成倍增加。第三笔是延迟容忍度。排产问答要求十秒内返回操作员等不了。质量归因分析可以接受一两分钟毕竟是离线式的深度分析。RAG 类问答要控制在五秒以内这里面大模型推理时间可能只占一半另一半是检索时间。三种场景混在一个模型服务里时我一般按最高要求设超时也就是十秒。再长就直接提示失败不要吊着用户。通用参考配置如下表。量化位数越低显存占用越少但输出质量会轻微下降核心业务场景别低于 4bit。模型规模显存需求16bit 全精度显存需求4bit 量化适合场景7B-8B 级别16-24GB6-10GB排产问答、报警解释、RAG 问答13B-14B 级别32-48GB12-20GB复杂归因、长文档理解70B 级别140GB 多卡40GB 多卡全场景统一模型代价高4.2 本地部署的推荐启动方式与参数一次别贪多本地部署我习惯用支持 OpenAI 兼容接口的推理框架这样上层代码不用绑死某个服务。下面是 vLLM 框架启动一个量化模型的参考命令生产环境我会加几个关键参数。# 本地部署大模型vLLM 启动参考命令 python -m vllm.entrypoints.openai.api_server \ --model /data/models/factory-7b-awq \ --served-model-name factory-llm \ --quantization awq \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --max-num-seqs 4 \ --host 0.0.0.0 \ --port 8000--max-model-len 设 8192这是工厂上下文的合理值。设太大显存不够设太小工单列表加系统提示词就溢出了。--gpu-memory-utilization 设 0.85不跑满显存给 KV cache 留余量也避免偶发峰值导致 OOM。--max-num-seqs 控制同时处理的请求数设 4 对企业内一个小团队足够峰值时后面的请求排队而不是挤爆显存。--served-model-name 是让网关调用的名字代码里 model 参数对应这个值。很多团队一上来就部署 70B 大模型结果一张卡跑不动量化后效果变差最后怪模型不行。我的实际经验先把 7B 级别在当前车间跑顺几个场景再评估要不要升级。工厂场景的专业性不在模型大小在上下文质量。4.3 用云端 API 快速验证效果再无缝切到本地方案初期可以用成熟大模型 API 验证提示词和场景效果。等确认了 prompt 模板和上下文组装逻辑后再切到本地部署。切换的成本几乎为零因为本地推理框架普遍提供 OpenAI 兼容接口。# 切换 base_url 就能从云端 API 迁移到本地模型 from openai import OpenAI client OpenAI( base_urlhttp://10.10.1.15:8000/v1, # 本地推理服务地址 api_keylocal-key-placeholder, # 本地服务通常不校验但参数必须存在 ) resp client.chat.completions.create( modelfactory-llm, # 对应 --served-model-name messages[ {role: system, content: 你是工厂车间调度助手能看懂 MES 工单上下文。}, {role: user, content: 帮我检查 3 号工单的物料是否齐套。} ], streamTrue, temperature0.3, ) for chunk in resp: if chunk.choices[0].delta.content: print(chunk.choices[0].delta.content, end)注意 api_key 这里纯粹占位。本地服务大多不校验密钥但 SDK 要求传这个字段。迁移时改动就 base_url 一行业务代码不用动这个便利性在方案验证阶段能省下大量返工。4.4 提示词温度与上下文窗口的参数设置分场景不要一套打天下模型参数不是玄学但在工厂场景里确实需要分场景设置。排产建议追求稳定可解释temperature 设在 0.2 附近。质量归因需要一点发散来找线索可以放到 0.4但再高就满嘴跑火车了。设备维修问答严格按照手册来0.1 比较稳。top_p 我一般不单独调保持默认即可。上下文窗口是更值得花心思的地方。8K 上下文对单个场景足够但要注意系统提示词本身会占掉一部分。MES 工单列表和 SCADA 特征值加起来控制在 3000 字以内给工具调用结果和模型回答留出空间。如果场景需要引入历史对话建议只在最后两轮内回放对话历史是上下文占用的隐形杀手。Prompt 模板也要工程化。我通用模板里固定三段角色定义、数据来源声明、约束条件。角色定义写明你是谁数据来源声明写明本次回答只能依赖哪些信息约束条件写明禁止做什么比如禁止编造工单、禁止修改物料编码。三段结构清晰后换场景只换中间的数据部分不用重新设计提示词。5. 避坑指南AI 大模型进工厂最常见的 5 个翻车现场5.1 现象模型一本正经地推荐参数对应 SCADA 点位却根本没采集方案验证时AI 对设备状态做了详尽的归因分析指出了某个变量异常。结果下车间核查发现那个点位压根不存在是设备台账里淘汰的传感器还在配置文件里留名。模型不知道实时点位在线状态只能凭历史文本里的“残影”推理。原因是接入层没有把点位在线状态追加进上下文。模型以为给它的数据都真实存在但历史数据里埋着废弃点位。解决在系统提示词前先注入一段点位状态表列出“在线点位清单和最后更新时间”并明确告知模型“不在清单内的点位不可引用”。同时接入层定期同步 SCADA 点位配置把废弃点位从历史数据源里标记掉。5.2 现象SSE 流式输出到一半断流界面一直转菊花前端通过 SSE 接大模型输出回答到一半就不动了刷新页面重问一次又正常但第二次断得更早。排查发现工厂现场网络走了转发代理代理对响应内容做了缓冲缓冲区一满就掐断。原因是中间链路不支持流式转发。厂区网络设备、反向代理默认会缓存响应体SSE 这种长连接被缓存策略埋在中间。解决在反向代理配置里关闭响应缓冲把 SSE 接口的代理缓存设为 off同时给响应头加上 cache-control 加 no-cache、x-加速-过期头等参数。前端侧也要做自动重连断流后基于已渲染内容重新发起请求而不是让用户手动刷新。注意重连时应带上最后一条已收到的消息序号避免重复生成。5.3 现象大模型把物料编码“好心”改成了不存在的编码质量归因场景里模型识别出某个物料批次号“疑似拼写错误”自动给它纠正成了另一串编码。这个问题最隐蔽因为结果看起来合理实际已经污染了 MES 里的追溯链。原因是模型默认在做一个“助手”倾向于修复它认为的错误。物料编码是工厂系统的强约束键一旦被修改关联关系就断了。解决在 system prompt 里明确写“所有编码类字段必须原样复制禁止修正”。同时在网关层加一道规则校验让模型输出经过一层实体校验器凡是不在 MES 字典里的编码一律拦截并提示人工确认。这是提示词和工程规则双保险缺一不可。5.4 现象把大模型当数据库问它“上周 A 线良率多少”时一本正经地编数据业务问“上周 A 线良率多少”AI 回了“约 95%”。后来核对实际只有 91%。模型也不是故意撒谎它根本看不到统计数据只能根据上下文里的只言片语“合理猜测”。原因是把模型当成了数据库引擎。大模型擅长归纳文本和生成建议不擅长精确查询特别是数值型结果。解决这类问题不应该让模型从记忆里生成答案而要走工具调用。网关里挂一个统计查询函数模型识别到意图后调用函数拉取 MES 的报表接口得到真实数字后再组织语言。核心原则是凡是数据库能直接回答的不让模型代劳。前端如果发现是查数类问题也可以直接走报表接口连模型都不用调。5.5 现象本地模型服务响应越来越慢最后直接显存溢出刚部署时响应三秒用了一个月后变成三十秒最后直接 OOM 崩溃。运维以为是模型被“聊傻了”重启后好一天又复发。原因是会话历史无节制地堆积。每次对话都把整个 session 历史一起发给模型上下文越积越长KV cache 占用越来越大。解决网关层做会话窗口管理。只保留最近三轮对话和最近一次工具查询结果超出部分摘要后丢弃。另外设置单会话最大 token 数接近阈值时强制截断并提示用户开了新会话。工厂场景的操作员会话都比较短通常两三轮就结束这个策略对业务无损但对系统稳定性帮助极大。6. 怎么验证这套方案值得投入三条评估线加一个记录表方案值不值得做不能只看演示时效果惊艳要看几个月后的使用率和业务认可度。我习惯用三条评估线来验证。第一条是决策支持覆盖线。把工厂里高频的排产、质量、设备、仓储问题列成清单统计 AI 能给出有效建议的比例。刚开始可能只有四成目标是通过迭代提示词场景到七成以上。覆盖率的提升速度直接反映方案投入的有效性。第二条是人机协同耗时线。记录一个排产员订一个工单全流程需要多长时间上线后同样流程缩了多少。这里要注意只看回答速度没用要看全流程闭环速度。AI 三秒给建议但操作员还要去 MES 里手工执行如果系统间没有联动那 AI 的价值就被砍掉大半。第三条是建议采纳线。统计 AI 给出的排产建议、报警解释被用户采纳的比例。这个比例低于五成说明提示词或者上下文数据没喂对高于八成说明场景选得准。建议采纳率比回答速度更能反映真实质量。配套做法是建一张 AI 输出日志表。字段包括问题、上下文摘要、模型回答、用户是否采纳、人工做了哪些修改。这张表积累一个月就能看清哪些场景真正创造价值哪些场景纯粹是花架子。我见过太多项目上线热两周第三周就没人用了原因就是没记录、没分析、没迭代。投入这套方案之前建议先用开源 MES 或现成测试环境跑通最小链路拿真实工单数据验证一到两个场景再决定是否全面铺开。工厂不像互联网可以随时回滚系统一旦上线就牵扯生产。先小范围试错再扩大战果。最后说一个我自己的习惯任何方案文档我都会多留一页写“不做什么”凡是涉及生产安全的决策AI 永远只给建议人永远握最终拍板权。守住这条项目就守住了底线。希望帮到你。本文还有配套的精品资源点击获取