企业官网建设流程全解析

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，通常由这几部分组成：

MCP（Model Context Protocol）在这里扮演的角色，是工具层和大脑之间的"标准接口"。以前每接一个工具就要写一套适配代码，MCP相当于定了一个统一的插头标准，让Agent能更方便地调用各种外部能力。热词里出现的"figma mcp""playwright mcp""blender mcp"都是这个思路在不同领域的应用，工业场景里对应的就是"PLC mcp""MES 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 Server，Agent通过标准协议调用，新增工具只需要注册，不用改Agent核心逻辑。

热词里"mcp的m+n"说的就是这个意思：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生成按可能性排序的根因假设。比如：

1. 液压系统压力不稳定（可能性高，证据：保压压力波动大，且该设备液压油已使用超期）
2. 原料含水率偏高（可能性中，证据：近期湿度上升，且该批次原料未做充分干燥）
3. 模具磨损（可能性低，证据：模具使用次数接近维护周期但未超限）

第四步：验证建议生成。针对每条根因，Agent给出具体的验证步骤。比如"检查液压油状态，若浑浊或粘度异常则更换""查看原料干燥记录，确认干燥温度和时间是否达标"。

第五步：人工确认与反馈。建议推送给设备工程师和工艺工程师。他们确认或否定后，结果回写到案例库，Agent下次推理会更准。

整个流程从触发到推送，研华的目标是控制在5分钟内。实际落地中，如果数据链路顺畅，3分钟左右可以完成。

3.4 关键参数与配置

如果你要复现类似的方案，下面这些参数值得参考：

注意：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 常见问题速查表

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 扩展路径

验证有效后，按这个顺序扩展：

1. 增加数据源：从一台设备扩展到一条线，从时序数据扩展到MES、ERP。
2. 增加工具：接入诊断算法、仿真模型、报表生成。
3. 增加Agent：从质量分析扩展到设备诊断、能耗优化、排产辅助。
4. 引入MCP：当工具数量超过5个，考虑用MCP统一管理。
5. 边缘部署：对实时性要求高的场景，把部分推理下沉到边缘。

我个人在实际操作中的体会是：不要追求一步到位。工业场景的复杂性决定了，任何大而全的方案都会在细节上翻车。小步快跑，每个阶段都拿到实际价值，才是可持续的路径。

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的推理漏洞。等信任建立起来之后，再逐步简化输出。

这个领域变化很快，我上面写的很多内容，可能半年后就需要更新。但有些东西是不变的：对现场的理解、对数据的敬畏、对人的尊重。技术会迭代，这三点不会。