1. 工厂里的AI Agent到底在干什么1.1 从一条产线异常说起去年冬天我在一家做精密结构件的工厂里蹲了三天。产线上一台注塑机的良率突然从98.6%掉到94%出头班组长第一反应是原料批次有问题换了料还是不行第二反应是模具磨损停机检查模具也没发现明显异常。折腾了大半天最后是设备工程师翻出过去两周的振动数据发现某段轴承的频谱特征在缓慢漂移——问题出在机械传动跟原料和模具都没关系。这件事让我印象特别深。不是因为这个故障有多难而是因为从异常发生到定位根因中间隔了整整七个小时。这七个小时里产线在低效运转良率在持续损失而真正有用的那条线索一直躺在数据采集系统里没人看。AI Agent在工厂里要解决的恰恰就是这类问题。它不是又一个大屏可视化也不是把ChatGPT套个工业外壳。它要做的是把散落在PLC、SCADA、MES、传感器、维修工单、工艺文档里的信息串起来在异常发生时主动推理、主动追问、主动给出可执行的建议。研华在这块摸爬滚打了好几年从最早的边缘计算盒子到后来的WISE-PaaS平台再到现在的iFactory.AI Agent踩过的坑比走过的路还多。我结合他们的公开实践和自己接触过的一些落地案例把AI Agent在工厂里怎么工作这件事拆开讲清楚。如果你正在评估要不要上工业智能体或者已经立项但卡在某个环节这篇应该能帮你省下不少试错成本。1.2 先分清三个容易混淆的概念热词里有个高频问题AI Agent、LLM、AI模型有什么区别DeepSeek属于哪个这个问题不搞清楚后面全是糊涂账。我用一个工厂里的类比来说明AI模型相当于一台专用机床。你给它输入它给你输出但它只会干一件事。比如一个训练好的缺陷检测模型你喂它一张产品图片它告诉你合格/不合格。它不会跟你聊天不会自己决定下一步做什么。LLM大语言模型相当于一个读过很多书的工艺工程师。你问他注塑机良率下降可能有哪些原因他能给你列出一大串还能跟你讨论。但他没有手不能自己去查数据、不能自己去调设备参数。DeepSeek、GPT这类都属于LLM。AI Agent相当于给这位工程师配了手、眼睛和工具箱。他能自己去看MES里的工单、自己去查历史振动数据、自己调用诊断算法、自己生成维修建议甚至自己触发一个工单。LLM是Agent的大脑之一但Agent还包括记忆、工具调用、规划、执行这些模块。所以DeepSeek属于LLM它是Agent可以选用的大脑之一。一个完整的工业AI Agent通常由这几部分组成组成模块作用工厂里的具体体现感知层获取环境信息传感器数据、PLC状态、MES工单、摄像头画面记忆层存储历史与知识工艺文档、维修记录、历史报警、专家经验库规划层拆解任务、决定步骤先查振动→再查温度→对比同型号设备工具层执行具体操作调用诊断算法、查询数据库、生成报表、发工单执行层落地动作推送建议、调整参数、触发报警、通知人员MCPModel Context Protocol在这里扮演的角色是工具层和大脑之间的标准接口。以前每接一个工具就要写一套适配代码MCP相当于定了一个统一的插头标准让Agent能更方便地调用各种外部能力。热词里出现的figma mcpplaywright mcpblender mcp都是这个思路在不同领域的应用工业场景里对应的就是PLC mcpMES mcp数据库 mcp这类。2. 研华的工业智能体是怎么搭起来的2.1 为什么不能直接把通用Agent搬进工厂我见过不少团队的第一个想法是直接用现成的Agent框架接上我们的数据库不就行了结果无一例外都撞墙了。工厂环境和互联网环境有几个根本差异第一数据是时序的、强关联的。互联网上的文本是离散的工厂里的数据是连续采样的。一台设备过去72小时的温度、压力、振动、电流这些数据之间有物理约束关系不是随便拼一拼就能喂给模型的。第二错误的代价不对称。聊天机器人说错话用户笑一笑就过去了。工厂里Agent给错一个参数建议可能导致批量报废甚至安全事故。所以工业Agent必须有置信度评估和人工确认环节。第三实时性要求苛刻。有些场景要求毫秒级响应比如运动控制有些场景可以容忍分钟级比如质量分析。Agent的架构必须能区分这两类不能一刀切。第四现场网络和算力受限。很多工厂的车间网络不稳定边缘设备算力有限不能什么都往云端传。研华的iFactory.AI Agent架构本质上是在回应这四个约束。它的核心思路是**边缘感知云端推理工具调用人工兜底**而不是追求全自动无人化。2.2 四层架构拆解我把研华公开资料里的架构和我理解的实际落地方式结合起来画成下面这个逻辑第一层边缘数据层。这一层是研华的老本行。数据采集卡、边缘网关、协议转换模块把PLC、CNC、传感器、电表这些设备的数据统一采上来。关键点是协议兼容性——工厂里可能有Modbus、OPC UA、Profinet、EtherCAT好几种协议并存边缘层要能全部吃下。研华在这块的积累确实深很多采集卡和网关产品直接支持多种协议转换。第二层数据治理与特征层。原始数据不能直接喂给Agent。这一层要做的是清洗异常值、对齐时间戳、计算衍生特征比如振动频谱、温度变化率、打标签。研华的做法是在边缘侧先做一轮轻量处理把高价值特征传上去原始数据按需留存。这样既省带宽又保护了数据隐私。第三层Agent推理层。这是核心。LLM在这里做规划但不是让LLM直接看原始数据。而是把数据治理层输出的结构化特征、历史案例、工艺规则作为上下文喂给LLM让它做推理和决策。同时Agent会调用各种工具诊断算法、仿真模型、知识库检索、报表生成。第四层应用与交互层。最终输出给谁给产线班组长、设备工程师、工艺工程师。形式可能是聊天窗口、报警推送、工单系统、看板。研华的做法是不改变工人现有的操作习惯Agent的建议以辅助信息的形式出现在他们已经在用的界面里。这里有个关键设计原则Agent不直接控制设备。它给建议人确认后才执行。这是工业场景和互联网场景最大的区别也是很多团队容易忽略的安全底线。2.3 MCP在其中的位置MCP协议在工业Agent里的价值我理解是降低工具接入的边际成本。假设你的Agent要调用五个工具查MES工单、查历史振动、调用诊断算法、生成PDF报告、发企业微信通知。没有MCP的时候每个工具都要写一套适配代码接口变了还要改。有了MCP每个工具封装成一个MCP ServerAgent通过标准协议调用新增工具只需要注册不用改Agent核心逻辑。热词里mcp的mn说的就是这个意思M个Agent可以复用N个工具不用M×N次适配。在工厂里这意味着你可以先上一个Agent做质量分析后面再上设备诊断Agent、能耗优化Agent它们可以共享同一套工具库。但要注意MCP目前还在演进中工业场景对实时性、安全性、确定性的要求比互联网高得多。我的建议是核心控制链路不要依赖MCP辅助分析链路可以用。比如查数据、生成报告、推送通知这些可以用MCP但涉及设备参数下发的还是走传统的确定性通道。3. 一个完整的落地案例拆解3.1 场景选择为什么从良率异常分析切入研华在多个行业做过落地我挑一个最有代表性的注塑车间的良率异常根因分析。选这个场景有几个原因数据相对完整注塑机本身有丰富的传感器数据MES里有工单和质检记录。问题高频良率波动是车间每天都要面对的问题。根因复杂可能涉及原料、模具、设备、工艺参数、环境多个维度正好适合Agent发挥串联信息的优势。容错空间大分析建议不直接控制设备错了可以人工纠正风险可控。这个场景的Agent目标很明确当良率异常发生时在5分钟内给出按可能性排序的根因列表并附上每条根因的证据和建议的验证步骤。3.2 数据准备Agent的口粮怎么备Agent再聪明没有数据也是巧妇难为无米之炊。这个场景需要准备的数据分四类第一类实时时序数据。注塑机的关键参数包括料筒温度分段、注射压力、保压压力、冷却时间、开合模位置、螺杆转速等。采样频率从1Hz到100Hz不等。研华的采集方案是在每台设备旁部署一个边缘网关本地缓存最近72小时数据同时按秒级上传关键特征到中心。第二类批次与工单数据。从MES拉取当前生产的是哪个订单、用的哪批原料、哪套模具、哪个班组、什么时间段。这些是上下文没有它们Agent看到良率下降也不知道该往哪个方向查。第三类历史案例库。这是最容易被忽略但最有价值的部分。把过去两年的良率异常记录整理成结构化案例异常现象、排查过程、最终根因、解决措施。研华的做法是先用人工整理一批高质量案例然后让Agent在运行中不断积累新案例。第四类工艺知识。包括原料特性表、模具维护周期、设备参数标准范围、工艺窗口。这些通常以文档形式存在需要做结构化处理。实操心得数据准备阶段最耗时的不是技术对接而是跟老师傅聊天。很多关键经验只存在于老工程师的脑子里比如这种声音一般是液压问题这个季节湿度高原料要提前烘。把这些挖出来Agent的价值能翻倍。3.3 Agent的工作流程当MES检测到某批次良率低于阈值触发Agent。完整流程如下第一步上下文组装。Agent先拉取当前批次的基本信息产品型号、原料批次、模具编号、设备编号、生产时间段。同时拉取该设备过去72小时的时序特征、该模具的历史使用记录、该原料批次在其他设备上的表现。第二步异常定位。Agent调用诊断工具对比当前特征与历史正常批次的差异。比如发现保压压力波动标准差比正常高3倍这是一个信号。同时检查是否有报警记录、是否有参数被手动修改过。第三步根因推理。这是LLM发挥的地方。Agent把上一步发现的异常信号、相关历史案例、工艺知识作为上下文让LLM生成按可能性排序的根因假设。比如液压系统压力不稳定可能性高证据保压压力波动大且该设备液压油已使用超期原料含水率偏高可能性中证据近期湿度上升且该批次原料未做充分干燥模具磨损可能性低证据模具使用次数接近维护周期但未超限第四步验证建议生成。针对每条根因Agent给出具体的验证步骤。比如检查液压油状态若浑浊或粘度异常则更换查看原料干燥记录确认干燥温度和时间是否达标。第五步人工确认与反馈。建议推送给设备工程师和工艺工程师。他们确认或否定后结果回写到案例库Agent下次推理会更准。整个流程从触发到推送研华的目标是控制在5分钟内。实际落地中如果数据链路顺畅3分钟左右可以完成。3.4 关键参数与配置如果你要复现类似的方案下面这些参数值得参考环节参数建议值说明数据采集时序数据采样率关键参数10-100Hz振动类要高温度类可低边缘缓存本地留存时长72小时覆盖大多数异常回溯需求特征计算滑动窗口5-30分钟根据工艺周期调整异常检测阈值设定动态基线±3σ固定阈值容易误报LLM推理上下文长度8K-32K tokens太长会稀释关键信息响应时间端到端5分钟超过则工人会失去耐心置信度人工确认阈值0.7必须人工高于0.7可自动推送但不下发注意LLM的上下文不是越长越好。我试过把72小时原始数据全塞进去结果模型被噪声淹没推理质量反而下降。正确做法是先做特征提取和异常筛选只把高信息量的片段喂给LLM。4. 实操中踩过的坑和排查技巧4.1 数据质量Agent最大的敌人我接触过的项目里80%的失败案例根源在数据质量而不是算法。具体表现有时间戳不对齐。不同设备、不同系统的时钟不一致导致Agent看到的同一时刻数据其实是错位的。排查方法定期做NTP同步并在数据治理层做时间对齐校验。传感器漂移。用了两年的温度传感器读数可能偏了2度。Agent基于错误数据推理结论自然错。排查方法定期校准并在Agent里加入数据可信度评估。缺失值处理不当。网络抖动导致数据断点如果简单用前值填充可能掩盖真实异常。建议短断点用插值长断点标记为数据不可用让Agent知道这段不可信。标签错误。历史案例库里的根因标注如果是错的Agent会学错。这个只能靠人工审核没有捷径。4.2 LLM幻觉在工业场景的应对LLM会一本正经地胡说八道这在工业场景是致命的。比如它可能编造一个不存在的故障模式或者给出超出设备安全范围的参数建议。研华的应对策略我总结为三道防线第一道知识约束。不让LLM自由发挥而是把工艺知识、设备手册、历史案例作为参考文档喂进去要求它基于这些文档推理。相当于开卷考试而不是闭卷。第二道规则校验。Agent生成的建议要过一遍规则引擎。比如建议温度调整到300度规则引擎一查设备上限是280度直接拦截。第三道人工确认。高风险建议必须人工确认。低风险建议可以自动推送但也要留痕可追溯。实操技巧在Prompt里明确要求LLM如果证据不足必须说无法确定不要猜测。这一条能大幅降低幻觉率。我实测下来加了这句话之后错误建议减少了大概六成。4.3 常见问题速查表问题现象可能原因排查方向解决建议Agent响应超时数据查询慢/LLM调用慢看各环节耗时日志加缓存、换更快的模型、异步处理根因排序不准案例库质量差/特征提取不到位抽查历史案例标注人工整理高质量案例优化特征误报率高阈值太敏感/数据噪声大看误报案例的共同点调整动态基线加滤波工人不用建议不可操作/界面不友好跟班组长聊建议要具体到拧哪个螺丝模型效果衰减工况变化/设备老化对比新旧数据分布定期重新训练或微调工具调用失败接口变更/权限问题看MCP Server日志加监控告警接口版本管理4.4 组织层面的坑技术之外还有几个组织层面的坑我见过太多团队栽在这里坑一IT和OT各干各的。IT团队懂软件不懂工艺OT团队懂设备不懂AI两边语言不通。解法项目组必须有懂工艺的人全程参与最好是从车间提拔的。坑二期望值管理失败。老板看了演示觉得AI什么都能干上线后发现只能解决特定问题落差大。解法立项时明确边界先做窄而深再做宽而浅。坑三没有反馈闭环。Agent给出建议工人用了但没人记录结果Agent永远不进步。解法把反馈做成流程的一部分哪怕只是点个有用/没用。坑四过度追求自动化。一上来就想无人化结果风险不可控。解法从辅助决策开始逐步过渡到自动执行低风险动作。5. 从0到1搭建工业Agent的实操路线5.1 选场景的三个标准不是所有场景都适合上Agent。我的筛选标准是标准一问题高频且重复。每天都要处理的问题才值得投入。一个月出一次的问题人工处理更划算。标准二数据可得且质量尚可。如果关键数据根本没采集或者采集了但质量很差先补数据基础别急着上Agent。标准三容错空间足够。建议错了不会造成不可逆损失。质量分析、能耗优化、预测性维护都符合但安全联锁、运动控制就不适合。5.2 最小可行方案如果你想快速验证我建议这个最小配置数据侧先接一台设备采集5-10个关键参数积累一个月数据。Agent侧用现成的LLM API配一个简单的RAG检索增强生成把工艺文档和历史案例做成知识库。工具侧先接两个工具——查历史数据、查工单。交互侧先用企业微信或钉钉机器人把建议推给指定的人。反馈侧加一个有用/没用按钮收集反馈。这个配置一两周能搭起来成本可控能快速验证价值。跑通了再扩展。5.3 扩展路径验证有效后按这个顺序扩展增加数据源从一台设备扩展到一条线从时序数据扩展到MES、ERP。增加工具接入诊断算法、仿真模型、报表生成。增加Agent从质量分析扩展到设备诊断、能耗优化、排产辅助。引入MCP当工具数量超过5个考虑用MCP统一管理。边缘部署对实时性要求高的场景把部分推理下沉到边缘。我个人在实际操作中的体会是不要追求一步到位。工业场景的复杂性决定了任何大而全的方案都会在细节上翻车。小步快跑每个阶段都拿到实际价值才是可持续的路径。5.4 团队配置建议一个能落地的工业Agent团队最少需要这几类人工艺专家懂设备、懂流程、懂现场痛点负责定义问题和验证结果。数据工程师负责数据采集、治理、特征工程。AI工程师负责Agent架构、Prompt设计、工具开发。现场对接人负责跟班组长、操作工沟通推动落地。这四类人里工艺专家是最关键的也是最难找的。很多项目失败就是因为缺了这个人做出来的东西技术上很漂亮现场没人用。6. 工业智能体的边界与未来6.1 现在能做什么不能做什么根据我看到的落地案例当前工业Agent的能力边界大致是能做好的信息检索与串联把散落的数据快速聚合异常检测与根因假设给出可能性排序知识问答工艺文档、设备手册的智能检索报告生成自动生成分析报告、交接班记录辅助决策给出建议人工确认做不好的精确的物理量预测比如明天下午3点温度会是多少闭环控制直接调整设备参数跨工序的复杂优化涉及多个约束条件的全局优化处理从未见过的新问题没有历史案例时表现会下降认清这个边界很重要。Agent是增强人的工具不是替代人的方案。把它放在辅助的位置价值最大风险最小。6.2 2026年为什么被看作分水岭热词里提到2026是工业智能体从概念演示走向工程化落地的分水岭我理解这个判断背后的逻辑是技术侧LLM的推理成本在快速下降MCP等标准在成熟边缘算力在提升。三年前做不了的事现在成本可接受了。需求侧制造业面临老师傅退休、年轻人不愿进车间的问题经验传承的需求越来越迫切。Agent恰好能承接这部分需求。生态侧从芯片到平台到应用产业链在成型。研华这类厂商提供的是中间层让应用开发者不用从零造轮子。但分水岭不意味着爆发。工业的节奏比互联网慢得多一个方案从验证到规模化两三年是常态。2026年更可能是规模化验证的起点而不是全面普及的终点。6.3 给正在评估的团队的建议如果你正在考虑上工业Agent我的建议是先想清楚要解决什么问题再想用什么技术。不要因为AI很火就上要因为这个问题人工处理成本太高才上。从辅助决策切入不要碰闭环控制。风险可控价值可见团队有信心。把数据基础打牢。数据质量决定Agent上限这个投入省不得。让现场的人参与进来。从需求定义到验证全程参与。他们不认可再好的技术也落不了地。接受不完美。Agent不会100%准确80%的准确率加上人工兜底往往比追求99%但迟迟上不了线更有价值。最后再分享一个小技巧在Agent上线初期让它解释自己的推理过程。不只是给结论还要展示我看了哪些数据、对比了哪些案例、为什么得出这个结论。这样工人能判断建议是否可信也能帮你发现Agent的推理漏洞。等信任建立起来之后再逐步简化输出。这个领域变化很快我上面写的很多内容可能半年后就需要更新。但有些东西是不变的对现场的理解、对数据的敬畏、对人的尊重。技术会迭代这三点不会。