去年接到一个广东调味品厂的咨询。他们的麻辣酱产品一直有个奇怪的问题：每个季度总有那么几批，成品的粘稠度会突然飙高或者掉下去。QC检验不合格，要返工调整，批次报废率大约在5-8%。问题出现得毫无规律，有时候连续3批都出问题，有时候一个月都没事。

品控主管跟我聊的时候说了一句让我印象很深的话："最难受的不是出问题，是出了问题找不到原因。我们开了4次根因分析会，每次都是"可能"——可能是辣椒原料批次问题，可能是蒸煮温度漂了，也可能是操作工手抖。但没有一次能确认。"

他们公司年营收接近2亿，管理上不算差。MES系统有、ERP有、IoT传感器也在部分产线上装了。但问题是——这些系统各自跑各自的，数据不互通。品控的同事去MES查工艺参数，要去ERP查原料批次，去IoT平台查设备数据，最后还要翻纸质交接班记录。查一圈下来，一整天就没了。

这篇文章记录我们怎么帮他们用AI Agent把数据串起来，找到那个藏了大半年的根因。

一、现场情况摸底

去工厂车间跑了两天，先搞清楚他们有什么系统、有什么数据、为什么查不到根因。

产线概况：麻辣酱生产包含10道工序——原料清洗→粉碎→炒制→蒸煮→调配→研磨→杀菌→灌装→封口→装箱。其中炒制和蒸煮是两个关键工序，粘稠度问题大概率出在这个区间。

现有系统：

为什么查不到：

教训：工厂不是没有数据，是数据被锁在各自的系统里。根因分析的第一步不是加传感器，是把数据打通。品控同学的原话——"信息孤岛比设备故障更耽误事"。

二、方案设计

我们的想法不是上一套数据中台——那太贵太重了。而是用一个AI Agent做"数据层中间人"，把这些系统的数据拉出来做关联分析。

方案核心：数据关联Agent

一个轻量级的AI Agent，部署在边缘AI网关上，通过API连接到各个系统：

Agent工作流程

每个N批不合格 → Agent自动触发：
  Step1: 拉取该批次的MES工艺参数
  Step2: 拉取对应时间段的IoT传感器数据  
  Step3: 拉取该批次的原料批次信息
  Step4: 拉取操作日志和交接班记录
  Step5: 将所有数据打包发给大模型做关联分析
  Step6: 输出【根因假设 + 置信度 + 数据证据链】
  Step7: 推送到品控主管的企业微信

听起来不复杂，但实际做的时候遇到了几个麻烦。

三、实施过程

第一周：数据打通

最花时间的事情不是写Agent代码，是接API。

这些API对接花了大概4天。加上打通纸质交接班日志的语音录入功能，第一周基本都在做集成。

教训：不要低估工厂系统API的可用性。我一开始觉得"接MES的API不就调几个接口吗"，结果每个系统都踩一遍坑。后来我学乖了——先去问IT负责人"这个系统最近有人调过API吗"，如果没人调过，预留1-2天的调试时间。

第二周：数据清洗和关联

数据接进来了，但质量比想象中差得多：

数据清洗做完后，我们有了一个关联数据集——每个批次一条记录，聚合了MES工艺参数、IoT实际温度曲线、原料信息、QC结果和操作备注。这是从前没有人做过的事情。

第三周：Agent分析和第一轮发现

Agent开始分析历史数据——把过去6个月、大约400个批次的数据喂进去。

第一轮分析结果出来的时候，品控主管看着屏幕沉默了大概10秒钟。

Agent发现了一个高度相关的模式：所有粘稠度异常批次，都发生在相对湿度超过75%的天气条件下。而且不是当天湿度高就会出问题——是前一天到前两天的持续高湿度，通过原料仓储环节间接影响了成品质量。

核心发现：根因是原料仓储吸湿
干辣椒和花椒在持续高湿天气中存放2天以上，吸水率增加约3-5%。这些吸湿后的原料在炒制阶段的升温曲线变缓——因为水分的比热容大，需要更多热能才能达到设定温度。炒制不充分→研磨后粒径分布偏粗→成品粘稠度不稳定。而之前所有人都以为是蒸煮工艺的问题。

为什么没人发现？因为之前从来没有人把气象数据和生产数据放在一起看。品控看QC数据，工艺看MES数据，采购看ERP数据——没有人想到湿度这个变量。

注：这个发现是通过关联分析得到的，不是气象API。我们后来帮他们拉了当地气象站的历史数据，和异常批次做了时间关联——阿豪相关性分析显示，批次生产前48小时的平均湿度与粘稠度异常之间的R²值约为0.78。虽然不是完美因果证明，但已经足够指导改进了。

第四周：方案验证和优化反馈

基于Agent的发现，工厂做了几件事：

改动实施后跟踪了2个月（4-5月，恰好是广东的回南天和梅雨季——全年最湿的时候），结果：

异常批次比例：从5-8%降至约1-2%
其中仅有的几次异常，Agent分析后确认是设备故障（蒸煮釜密封圈老化导致压力不稳）而不是原料问题。说明根因已经找准了。
Agent分析时间：从人工查一天到自动10分钟
现在每批不合格产品触发Agent自动分析，10分钟内输出根因假设，品控主管手机上就能看到。
意料之外的发现：原料批次稳定性差异
Agent在分析中还发现某供应商的干辣椒批次含水率标准差是其他供应商的2倍。品控主管直接拿着数据去和采购部谈供应商评估，淘汰了一个不稳定的源头。

四、遇到的问题和解决办法

问题1：批次ID关联——比想象中麻烦10倍

前面说了，4个系统的批次ID都不一致。我们建了一个映射表。但后来发现同一个ERP批次的原料被分成两批进了MES（因为一次进货做两次生产），映射关系从1:1变成了1:N。这种"一对多"关系在后续分析中需要特别处理，否则会引入关联错误。

问题2：语音日志没人用

操作工不愿意对着麦克风说话。有的是觉得"别扭"，有的是怕说错话被追责。后来调整方案：不强制语音，改为手机端勾选式交接（一个简单的问卷：今天设备正常吗？有异常现象备注）。减少了抗拒感，使用率从20%提到了85%。

问题3：Agent分析结果被质疑

第一次输出根因假设时，品控主管说"AI瞎编的吧"。我们需要让Agent不只说"湿度高了"，还要给出数据证据链——"这批原料入库时间是X日，当时湿度Y%，原料含水率Z%，炒制升温时间比基线慢了N分钟"。后来的版本增加了证据链可追溯功能，每条结论都标注了数据来源。

教训：在做工业生产AI时，只给结论是不够的。工厂的人需要看到证据链，才能建立信任。这不只是技术问题，也是产品设计问题。

问题4：数据闭环——改进了怎么知道做对了

工厂按Agent建议改了除湿和炒制补偿后，效果是好了。但怎么确认"确实是因为这个改好了"而不是因为别的因素？我们在IoT平台上加了湿度监测点，把改进前后的数据都拉了出来对比——一个简单的因果检验：改造前湿度>75%时异常率12%，改造后降到2%。这个对比报告用了说服管理层继续投入。

五、我的思考

这个项目做下来，几个感受特别深：

"找不到原因"比"没解决方案"更让人焦虑。工厂遇到问题不可怕——换了谁能理解？最怕的是不知道换什么。根因分析的核心价值不是"给出答案"，而是"把人的猜测范围从漫无边际缩小到可以验证的几条"。Agent给出的湿度假设，品控团队其实之前有人猜过，但没有数据支撑，被当作"瞎猜"否定了。Agent用4个系统的数据验证了这条假设。

AI Agent最大的价值在跨系统关联，不在单系统深度。单看MES，温度参数正常；单看IoT，传感器数据正常；单看QC，只是知道结果不正常。但把MES+IoT+QC+ERP+气象一关联——规律出来了。每个工厂现在都有3-5个系统，但很少有人做关联分析，因为太费人工。Agent在这里天然适合。

轻量方案比大平台方案更容易落地。这里没用数据中台、没换ERP、没改造MES。只是在边缘网关上跑了个数据关联Agent，通过API把现有系统串起来。总投入不到大平台方案的零头，上线时间以周计而非以月计。对中小型工厂来说，这个路径更现实。

数据打通之后的价值是连锁的。一开始只为了解决粘稠度问题。但数据关联系统建好之后，品控团队自己发现了很多"顺便"的价值——供应商评价有数据支撑了、工艺参数优化有了参考基准、甚至排产的时候可以根据天气预警主动调整生产计划。数据不打通就看不到这些。

六、给你的建议

如果你也在考虑用AI Agent做生产数据分析，几点实在的建议：

  1. 别一上来就追求实时分析。先做历史数据分析，找到问题规律再切实时。我们前3周都在做历史数据清洗和关联，实时是第4周加的
  2. 批次ID映射是绕不开的坑。至少预留1-2天做数据源之间的ID对齐。如果工厂有5个以上的业务系统，映射工作可能更久
  3. Agent要给证据链，别只给答案。每个根因结论都要能追溯到原始数据。这不光是信任问题——如果结论错了，有数据回溯才能找到是哪里出错了
  4. 语音/文字录入要有"低门槛"选项。别一开始就上高大上的AI语音方案，先试试手机表单。愿意用的人多了再升级技术
  5. 关注"跨系统关联"这样的隐形价值。很多工厂花大价钱上了MES和ERP，但它们之间的信息鸿沟一直没人填。一个轻量Agent就能做这件事，投入产出比很可能比买新设备还高
  6. 外部数据也很重要。在这个案例里，解决问题的关键数据（湿度）不是来自工厂内部系统，而是外部气象数据。做根因分析的时候，想想"和工厂无关的变量"里面有没有线索