1. 为什么工业大模型必须变成车间里的工种才能活这几年做工业数字化项目被身边同行问得最多的一个问题已经变了大模型到底能不能在车间里真的干活而不是只活在演示PPT上。这个问题的答案不取决于模型本身跑分多高、对话多流畅而取决于它有没有真正融入车间的作业流、数据流和决策流。今天想结合我们自己交付的一个制造业Agent落地项目内部代号就叫实在Agent认真梳理一下工业大模型从实验室走向车间的完整路径包括选型、架构、案例、工程化坑点和成本结构给正在做类似评估的朋友一个可参考的底稿。先说结论工业大模型落地本质上不是模型选型问题而是交付形态问题。实验室里跑得再好的模型如果不能变成车间里一个具体工种的角色——比如点检助手、参数顾问、质量文员——它就永远停留在Demo阶段。这个认知是我们用三个多月、三个场景、一条完整产线的代价换来的。1.1 实验室Demo和车间可用的差距比想象中大得多我见过太多团队把大模型演示做得漂漂亮亮输入一段设备故障描述模型唰唰给出排查步骤界面干净响应流畅。但到了车间现场问题马上变味。首先是输入极其不规范。实验室里你设计的问题是注塑机射出单元油温过高请给出排查建议但一线操作工真实的输入是三号机又高温报警了咋整。别小看这种差异模型对口语化、缺主语、带方言和错别字的文本理解能力直接影响可用性。我们统计过现场真实提问文本超过四成是无标点缺关键词混着设备编号的碎片化表达。其次是数据断供和脏数据。设备的点检记录、维修工单、报警台账听着都是现成的知识源但真去抽数据的时候会发现一半以上的记录是扫描件或者手写照片关键字段经常是空的同一台设备在不同系统里的编号还不一致。知识库建设不是把文档喂给模型那么简单80%的精力都消耗在清洗、对齐、补全这些看似不起眼的工作上。然后是容错率完全不同。Demo里答错了可以重来车间里一个错误建议可能导致停机时间拉长、甚至引发安全风险。所以我们从第一天就定了一条铁律Agent可以给建议但在任何涉及参数下发、设备启停的动作上必须留人工确认节点。这也是为什么最终我们把产品定位为辅助决策工具而不是自动控制系统。1.2 制造业的硬约束决定了Agent的最终形态制造业场景和办公场景的Agent有个本质区别办公Agent追求的是把事做完比如写邮件、订会议、填报表制造车间里的Agent首先要保证别把事搞砸。这个差异体现在三条硬约束上。第一条是数据不出内网。绝大多数制造企业的工艺配方、设备参数、质量数据是核心资产不允许传到外部服务。这意味着大模型必须私有化部署或者至少是混合部署通用能力可以在可控区域内调用涉及工艺和质量的推理必须在厂内完成。第二条是响应要快但动作要小。车间里工人问一句这台设备的保养周期到了没有你能接受3秒以内的响应但如果系统要基于实时传感器数据判断设备异常原因则需要分钟级甚至秒级的数据链路不能靠人手动上传。而动作要小指的是Agent默认只做查询、推荐、提醒、生成报告不默认做控制、下发、执行。控制类操作留给原有PLC和MES系统Agent只充当交互入口和决策辅助。第三条是链路必须可审计。制造企业做质量追溯、安全检查、设备维护每一步都要经得起审核。Agent给过什么建议、操作工采纳了什么、最终执行了什么这些必须有日志、有留痕。说白了车间里的Agent不能像聊天机器人那样说了就说了它说的每一句话都要对得上工单、批次和设备编号。这三条约束叠加起来结论很清晰工业Agent的形态不是一个能聊天的模型而是一个能对话、能查数、能调用工具、能生成结构化记录、又处处留痕的数字员工。我们在实在Agent项目里把这种形态拆成了五个模块模型底座、知识库、工具调用层、工作流引擎、审计与权限控制。下一章具体讲每个模块怎么选、怎么搭。2. 项目选型与系统架构一个能进车间的Agent由哪些模块组成很多人一上来就问你们用的哪个大模型其实模型只是这栋房子的地基而且地基还不是最难的部分。按我们的经验工作量占比大概是数据清洗和知识库建设占四成工具集成和场景编排占三成模型底座和微调只占两成剩下的一成是部署调优和推广培训。所以这一章把架构讲清楚比单纯推荐某个模型更有价值。2.1 模型底座选型通用底座加行业知识库比盲目训垂直小模型更划算我们在项目启动时做过一次严肃的选型评估是花大力气训练一个垂直行业的工业大模型还是采用通用底座行业知识库的组合方案最后选了后者核心原因有三个。第一制造业场景的知识更新频率远超想象。工艺卡会改、设备会换、材料会变如果用微调方式把知识灌进模型权重里每一次工艺变更都要重新训练成本高且周期长。而用知识库RAG方式改文档就等于改知识当天更新当天生效。第二通用底座的理解和推理能力远比一个数据量有限的行业小模型靠谱。工业语料虽然专业性强但总量和多样性远不如通用语料微调出来的小模型很容易偏科——对训练过的场景答得很好对没见过的表达方式立刻失灵。通用底座负责听懂人话、组织语言行业知识负责答得专业各干各的活。第三合规风险更可控。我们选底座时优先考虑能私有化部署、许可模式清晰的方案避免把核心对话数据送到外部。这也是许多制造业客户的先决条件。微调我们并没有完全放弃但只用在两个地方一是把设备点检的固定话术调成更简洁的口语二是在生成质检报告时让输出格式固定成客户惯用的模板。记住一个原则能用知识库解决的不用微调微调只干知识库干不了的事。2.2 知识接入把工艺手册、设备档案、维修工单变成可用语料知识库建设是整个项目里最耗时、最不性感、但决定成败的环节。我们刚开始天真地以为把PDF手册扔进一个向量数据库就行结果第一轮测试的准确率惨不忍睹。原因不是向量检索不好用而是语料的质量和结构根本不合格。后续我们总结了一套四步法这里直接给出来。第一步是领料盘点。搞清楚车间里到底有哪些可用的知识源设备操作手册、保养规程、历史维修工单、报警代码表、质检标准、工艺卡、安全规范、老师傅的口头经验。哪怕是一张贴在机台上的手写注意事项只要高频被用到都值得录入。第二步是清洗对齐。把扫描件做OCR把不同系统的设备编号统一成一套主数据把加油加润滑油打油这类同义表达归并成标准术语。这一步没有捷径只能逐条过。第三步是拆分入库。文档不是按页存而是按可检索的知识点拆。比如一台设备的操作手册要拆成启动步骤日常点检项常见报警及处理等条目每个条目对应一个设备型号和场景标签。第四步是混合检索。我们在向量检索之外加了一层关键词检索和一结构化查询。比如工人输入三号机这个编号系统先通过结构化映射定位到具体设备再结合语义检索定位到相关知识片段。纯靠向量的效果不稳定工业场景一定要叠加确定性的过滤条件。这也是我反复强调的一点工业知识库不是更像搜索引擎而是比搜索引擎更懂设备和流程。2.3 工具调用与系统集成Agent怎么动手干活如果Agent只能回答问题它的价值会大打折扣。真正的Agent必须能调用工具、读取数据、生成工单。我们在实在Agent里实现了三类工具调用。第一类是数据库查询。Agent通过自然语言转SQL或直接对接API查询MES里的工单状态、ERP里的物料信息、设备管理系统里的点检记录。比如工人问三号机上次保养是什么时候Agent自动查数据库返回结果而不是靠文档猜。这类调用必须做权限控制什么角色能查什么表提前配好。第二类是业务系统操作。比如在巡检发现异常时Agent可以自动创建一条待确认的维修工单推送到车间主管的待办列表。但这里要设计一个关键交互AI先把草稿写出来人工确认后才能真正写入系统。我们把这个节点叫做人工审批闸门是避免AI误操作的安全垫。第三类是数据接入。对于PLC、传感器这类实时数据我们通过消息中间件做单向接入Agent只读取实时的温度、压力、振动值。这样在设备问答里Agent就可以说当前电机温度是78度已接近预警值建议检查冷却回路。这种回答的现场价值是纯文档问答给不了的。2.4 四条架构红线权限最小化、全链路日志、双人复核、灰度发布最后把这四条架构红线单列出来因为它们是用来救命的。权限最小化。Agent系统的权限模型必须比普通软件更细。操作工能看到什么、班长能审核什么、工程师能改什么全部按角色切分不允许有万能管理员。我们甚至在Agent的Prompt层也做了限制防止通过对话套出越权信息。全链路日志。每一次用户提问、检索了哪段知识、调用了哪个接口、生成了什么内容、是否被人工采纳全部落库。这不仅是合规要求更是后续做效果评估的数据基础。双人复核。凡是涉及工艺参数建议、设备异常的处置建议输出给用户之前必须先经过规则引擎校验再由有资质的工程师审核。规则校验是兜底人工审核是最后一道门。灰度发布。新场景上线先在一条产线试运行两周对比历史基线数据没有问题再推广到其他车间。别一上来搞全厂铺开出了问题你连回滚都来不及。3. 三个落地场景的完整案例拆解从点检助手到质量文员架构说完了来看看真正在车间里跑起来的三个场景。我们选了三个完全不同的方向分别对应知识问答型、决策建议型、文档生成型Agent这样能验证架构的通用性也为后续扩展积累经验。3.1 汽车零部件工厂的设备点检与故障诊断助手第一个场景选在某汽车零部件工厂的机加工车间主要设备是几十台数控机床和一批辅助设备。选这个场景的原因很简单高频、知识密集、痛点明显。设备报警代码有一百多种维修工经常要翻厚厚的手册新员工培训周期长老师傅一退休经验就断了。我们做了一个点检助手核心功能有两个一是点检引导现场人员说出设备号和点检项Agent按标准流程引导作业并自动记录结果二是故障诊断输入报警代码或现象描述Agent结合历史维修工单和手册给出排查建议。知识库里灌了设备手册、报警代码表、过去三年的维修记录还从老师傅那里录了几十条经验型问答。实际效果超出预期故障诊断首答准确率在验证集上达到七成以上配合人工复核后的处置采纳率接近八成。最有价值的是排查时间明显缩短新员工排查一个常见报警的平均时间从四十分钟降到十五分钟以内。但我们也发现准确率最差的场景集中在多种故障并发和历史维修记录里没记录过的罕见报警这种情况Agent会很自信地给出一个错误方向。后来我们给Agent加了一条元规则当检索到的知识置信度不够高时必须明确说该情况在历史记录中匹配度不高建议联系设备工程师现场确认而不是硬答。3.2 电子装配车间的工艺参数顾问第二个场景是某电子装配车间的回流焊温度曲线优化这是一个典型的决策建议型Agent。回流焊的温区参数直接影响焊接良率工程师每天要根据产品类型、板卡厚度、环境温湿度调整曲线。以前全凭经验新来的工程师经常要反复试错。这个Agent的难点在于它不能只讲道理要给出具体的、落在规范区间内的参数建议。我们做了这样三步第一步把过往一年良率最高的参数组合作为训练样本配合工艺规范形成推荐模型第二步Agent通过工具调用实时读取当天的车间温湿度、设备状态和产品批次信息第三步Agent生成几组建议参数并标明每组参数的历史良率参考最后由工艺工程师在系统里确认后再下发执行。结果是参数初调的试错次数减少了大约一半尤其是对新手工程师相当于给了一个有历史数据背书的老法师助手。这场景最大的心得是Agent不要直接下发参数哪怕它对得离谱一旦背了锅这个产品在车间里就做不下去了。让工程师点击确认这个动作既给了技术兜底也给了人的体面。3.3 注塑车间的质检报告自动生成与缺陷归因第三个场景我们选了文档密集型的注塑车间的质量巡检。质检员每天要写几百条巡检记录每条要记录产品型号、模号、缺陷类型、数量、处理方式还要拍照片。这些记录大部分是重复劳动但因为要追溯一条也不能少。我们做的质量文员Agent做了两件事第一把现场的语音描述自动转写成结构化巡检记录比如质检员说三号机这批产品有黑点大概两成已经隔离了Agent直接生成符合模板的记录草稿第二Agent会结合历史缺陷数据给出归因提示黑点缺陷在过去六个批次里出现过三次关联模号都是03号模建议检查模具排气和料筒温度。这个场景的价值很直观质检员每天写记录的时间从两小时降到四十分钟以内而且记录的结构化程度大幅提升以前是自由文本现在直接能进质量分析报表。另外缺陷归因让以前老师傅脑子里才有的规律变成了系统里的可查询资产。我们也踩了一个坑语音转写会把黑点听成黑店后来把所有缺陷术语做了一次强制词汇映射这类问题才算压住。4. 部署与工程化的五个关键坑POC到量产之间隔着一整条产线很多项目死在从POC到量产这一步。模型在测试环境跑得好好的一进车间就各种翻车。这一章不讲高深理论全是我们交过的学费。4.1 算力与私有化部署先用好量化别急着买一堆卡私有化部署意味着GPU得自己掏钱。我们的经验是先用模型量化把部署成本压下来。一个中等规模的底座模型用INT8量化之后显存占用能降一半推理速度也能接受大部分对话场景的延迟能控制在3秒以内。如果场景更简单只做分类和抽取甚至可以上INT4跑在工控机上。先别追求满血精度先让业务转起来再按需升级。我们最终部署方案是两套推理服务主服务跑在GPU服务器上处理对话、检索和长文档生成边缘节点跑一个轻量级小模型只做语音转写、意图识别、设备编号抽取这类简单的预处理。简单任务不走大模型既能省算力也能降低高峰期的并发压力。4.2 数据接入的现实问题脏数据比模型能力更影响效果前面说过知识库要清洗这里再补充系统集成层面的问题。我们接MES数据时发现同样的工单号在不同子系统里格式不一样有的带前缀有的不带PLC点位表用的是老的编号体系和现在设备铭牌上的编号对不上。这些脏数据不处理Agent就经常查错数、答非所问。处理办法是建一层工业数据中间层把ERP、MES、PLC、质量系统的数据先同步到统一的数据底座里做了主数据对齐和字段标准化Agent只面向这一层查数据。表面多了一道工序实际上后续每个新场景都受益。如果让Agent直接面对十几个原始系统每接一个场景就痛苦一次。4.3 延迟与并发车间高峰时段的抢答问题车间里的使用高峰和办公场景完全不一样。早班会刚结束那半小时可能十几个班组长同时打开Agent查问题、汇报状态瞬时并发放到二十以上。我们的私有化推理服务一开始扛不住出现过排队等待和超时。解决用了三招一是把简单查询类问题走规则引擎和数据库直答不经过大模型这一下分流了超过一半的请求二是给大模型推理服务做了异步队列高峰时段用户会看到正在查询请稍候的反馈而不是无限等待三是把高频问题做了缓存比如三号机保养周期这批物料在哪个库位相同问题直接返回缓存结果。测下来高峰期的平均响应时间从8秒降到了2秒以内。4.4 效果评估准确率不是KPI采纳率和故障闭环率才是项目做效果评估时甲方一开始想看准确率。我们坚持把指标体系拆成三块技术指标、业务指标、采纳指标。技术指标就是检索命中率、答案准确率这个我们自己内部测业务指标包括点检耗时、报告编写耗时、参数试错次数采纳指标是操作工和工程师实际采纳Agent建议的比例。后来甲方也认可了准确率高但没人用等于零。真正反映价值的是采纳率因为一线人员只有在觉得有用、可信、顺手的时候才会采纳。我们在每个场景里都设了采纳/不采纳的按钮让数据反馈比问卷真实得多。4.5 一线推广让老师傅愿意用比算法优化更重要最后一个坑是最容易被技术团队忽视的推广。我们刚开始上线时一些老师傅根本不碰理由很直接我干了二十年需要它教我后来我们调整了策略把Agent的定位从教老师傅干活改成帮老师傅省事——比如自动写点检记录、自动生成报告、查历史工单。它变成了老师的记录员和资料员而不是指手画脚的新师傅。我们还做了一次经验反向录入请两位老师傅把各自的独门判断经验讲出来整理后进入知识库并在结果里标注该建议来源于张师傅经验。这两位老师傅之后成了Agent最积极的推广者因为产品里有了他们的贡献。这件事给我的启发很大技术落地的最后一公里往往是尊重的艺术而不是算法的艺术。5. 成本结构与推广路径从单点场景到多车间复用最后聊聊钱和规模。很多企业问落地一个工业Agent到底花多少钱这笔账其实是可以算清楚的。5.1 一次落地到底花了多少钱成本拆给你看我们按一个中等规模制造企业、三条场景、私有化部署来估算成本大致分四块。第一块硬件和基础软件GPU服务器、存储、推理框架和底座模型授权一次性投入大约占项目总成本的三成。第二块数据工程包括知识库建设、数据清洗、主数据对齐这块占比最大大约四成而且往往被低估。第三块场景开发和系统集成每个场景大概一到两个月包括Prompt调优、工具开发、测试和部署占比两成。第四块培训和推广别看只占一成但省了很容易变成玻璃楼阁。这个结构说明一个道理Agent项目的成本重心不在模型而在把模型接进现实的过程。后两块成本是一次性的第二块会随着知识资产积累形成复利越往后越便宜。5.2 为什么说先选场景再做平台是对的不少企业一上来就想建一个工业大模型平台什么场景都想覆盖。我们的建议恰恰相反先选两三个高价值的单点场景跑通做深做透再回头看哪些模块可以复用到下一个场景。以实在Agent为例第一个点检助手跑通后我们沉淀出了设备知识库的构建方法、故障问答的Prompt模板、数据中间层的取数接口。做第二个工艺参数场景时设备知识库直接复用新增的只是工艺参数推荐流程。做第三个质检场景时工具调用层和报告生成模板也是现成的。这就是场景带动平台的路径每做一单新场景平台能力厚一层。5.3 和传统工业软件的关系不是替代是给旧系统装上新入口最后说一句务实的Agent不是来取代MES、ERP、质量系统的这些系统的数据资产和流程逻辑仍然值钱。Agent做的是把人必须学软件才能干活变成说出需求Agent帮你用软件。就像给那些年迈但关键的业务系统装了一个会说话的新入口既保护了既有投资又让老系统的数据活了起来。我个人在实际操作中的体会是工业大模型落地最难的不是技术而是尊重——尊重产线的节奏、尊重数据的脏乱、尊重一线老师的经验、尊重每一步必须留痕的合规习惯。别急着证明模型多聪明先证明它靠得住、用得上、留得下。如果你也正准备做类似的尝试从一个小场景、一条线、一个月开始拿到真实反馈再扩大这条路会比想象中慢但每一步都踩得实。
