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帮你用软件"。就像给那些年迈但关键的业务系统装了一个会说话的新入口，既保护了既有投资，又让老系统的数据活了起来。
我个人在实际操作中的体会是，工业大模型落地最难的不是技术，而是尊重——尊重产线的节奏、尊重数据的脏乱、尊重一线老师的经验、尊重每一步必须留痕的合规习惯。别急着证明模型多聪明，先证明它靠得住、用得上、留得下。如果你也正准备做类似的尝试，从一个小场景、一条线、一个月开始，拿到真实反馈再扩大，这条路会比想象中慢，但每一步都踩得实。
