企业官网建设流程全解析

1. 制造业AI智能体落地的真实困境

1.1 为什么制造业的AI智能体项目总是“雷声大雨点小”

我在制造业信息化这个圈子里摸爬滚打了十来年，见过太多AI智能体项目从立项时的雄心壮志，到验收时的草草收场。有个做汽车零部件的客户，2024年初高调宣布要上马“全流程AI智能体”，预算批了八位数，结果半年后我去回访，项目组已经解散，只留下几台边缘服务器在机房里吃灰。这不是个例，而是制造业AI智能体落地的普遍现状。

问题出在哪里？很多人第一反应是“技术不成熟”。但说实话，以现在大模型的能力，写个文案、做个知识问答、甚至生成一段PLC代码，都不是什么难事。真正的难点在于：制造业的AI智能体，不是做一个能聊天的机器人，而是要嵌入到生产流程里，跟设备、物料、工艺、人员发生真实的物理交互。这就好比你在办公室里用语音助手定个闹钟很容易，但要让这个助手去车间里拧螺丝、调参数、处理异常，那就是完全不同的难度级别。

我总结下来，制造业AI智能体落地难，核心卡在三个地方：数据不通、场景不清、责任不明。数据不通是指OT（运营技术）层和IT（信息技术）层之间存在着巨大的数据鸿沟，设备数据上不来，IT指令下不去；场景不清是指很多企业根本不知道自己到底要让AI智能体解决什么问题，只是觉得“别人都在搞，我也得搞”；责任不明是指一旦AI智能体做出了错误决策，导致产线停线或者批量报废，这个锅该谁来背？

1.2 OT与IT融合：制造业AI智能体的“任督二脉”

要理解制造业AI智能体的落地难点，必须先搞清楚OT和IT的区别。OT是Operational Technology，运营技术，指的是车间里的PLC、SCADA、DCS、CNC这些直接控制物理设备的系统；IT是Information Technology，信息技术，指的是ERP、MES、WMS这些管理信息系统。这两套系统从诞生之初就是两条平行线，OT追求的是实时性、确定性、可靠性，IT追求的是灵活性、扩展性、互联性。

我见过一个典型的场景：某电子制造厂的SMT产线，贴片机每秒产生上千条数据，这些数据在OT层是实时采集的，但传到IT层的MES系统时，往往已经延迟了几分钟甚至几小时。为什么？因为中间要经过网关协议转换、数据清洗、格式对齐，每一道工序都会引入延迟。而AI智能体要做实时决策，比如根据贴片质量动态调整炉温曲线，它需要的是毫秒级的数据响应，而不是几分钟前的历史数据。

这就是OT/IT融合的核心矛盾：OT层的数据是实时的、封闭的、碎片化的，IT层的数据是历史的、开放的、结构化的，AI智能体需要的是两者的结合，但现有的技术架构很难做到无缝衔接。很多解决方案商宣称自己能做OT/IT融合，但实际上只是做了一个数据采集网关，把OT数据单向传到IT层，这根本不叫融合，这叫“数据搬运”。

真正的OT/IT融合，需要做到三点：第一，双向通信，IT层的决策指令能够实时下发到OT层执行；第二，语义对齐，OT层的设备状态、工艺参数要和IT层的订单信息、物料信息建立统一的语义模型；第三，安全隔离，IT层的网络攻击不能影响到OT层的生产安全。这三点说起来简单，做起来每一点都是硬骨头。

1.3 多智能体协同：从“单兵作战”到“集团军作战”的跨越

制造业的生产流程天然就是多智能体协同的场景。一条产线上有负责上料的智能体、负责加工的智能体、负责质检的智能体、负责物流的智能体，它们需要协同工作才能完成一个生产任务。但现在的AI智能体产品，大多还是“单兵作战”的模式，一个智能体只能处理一个特定的任务，智能体之间的通信和协作机制非常原始。

我参与过一个家电工厂的智能体项目，他们最初的想法很简单：给每个工位配一个AI智能体，负责该工位的质量检测。听起来很合理对吧？但实际跑起来就发现问题了：当上游工位的智能体检测到来料有缺陷时，它不知道该怎么通知下游工位暂停加工；当下游工位的智能体发现成品不合格时，它也不知道该怎么追溯是哪个上游环节出了问题。每个智能体都是信息孤岛，协同效率极低。

多智能体协同的难点在于：任务分解与分配、通信协议与语义、冲突检测与消解、全局优化与局部优化的平衡。举个例子，当订单插单时，负责排产的智能体需要重新分配任务，但负责设备维护的智能体可能正在安排预防性维护，负责物料配送的智能体可能已经按原计划备好了料。这三个智能体如何协商出一个新的方案？这就需要一套完善的协同机制，包括协商协议、优先级规则、冲突解决策略等。

目前业界比较前沿的做法是采用“黑板模型”或者“合同网协议”来实现多智能体协同。黑板模型是指所有智能体共享一个公共的数据空间，每个智能体都可以读取和写入信息，通过数据的变化来触发其他智能体的行为；合同网协议是指当一个智能体需要帮助时，它会发布一个“招标书”，其他智能体根据自身能力“投标”，最终由招标方选择最合适的“中标方”来完成任务。这两种模式各有优劣，黑板模型适合数据驱动的场景，合同网协议适合任务驱动的场景。

2. 解决方案商的能力图谱与选型逻辑

2.1 制造业AI智能体解决方案商的四种类型

市面上做制造业AI智能体的解决方案商，我大致分为四类：自动化厂商系、软件厂商系、互联网大厂系、创业公司系。这四类玩家各有各的基因，也各有各的短板，选型的时候一定要看清楚。

自动化厂商系的代表是西门子、施耐德、罗克韦尔这些传统工业自动化巨头。他们的优势在于对OT层的理解非常深，PLC、SCADA、MES这些系统都是他们做的，数据采集和设备控制是他们的看家本领。但他们的短板也很明显：IT层的软件能力相对较弱，大模型、多智能体协同这些新技术积累不足。我见过西门子的工业AI方案，底层的数据采集和边缘计算做得非常扎实，但上层的智能体决策逻辑还是比较传统的规则引擎，离真正的AI智能体还有距离。

软件厂商系的代表是SAP、Oracle、用友、金蝶这些企业管理软件厂商。他们的优势在于对IT层的业务流程理解很深，ERP、MES、WMS这些系统的数据模型和业务逻辑都是他们定义的。但他们的短板在于OT层的连接能力较弱，设备数据采集往往需要依赖第三方网关。而且他们的AI能力大多是集成第三方的大模型，自己的核心算法积累不多。

互联网大厂系的代表是阿里云、华为云、腾讯云这些云服务商。他们的优势在于AI技术实力强，大模型、多智能体协同、边缘计算这些技术都有深厚的积累。但他们的短板在于对制造业的业务理解不够深，往往是把消费互联网的AI方案直接搬到工业场景，水土不服的情况很常见。我见过某大厂的工业AI方案，智能体的对话能力很强，但让它去解析一个Modbus协议的数据包，它就懵了。

创业公司系的代表是那些专注于工业AI的初创企业。他们的优势在于灵活、专注、创新，往往能在某个细分场景做出很深的东西。但他们的短板在于产品化能力弱、项目交付经验少、持续服务能力存疑。我见过不少创业公司的AI智能体产品，Demo演示很惊艳，但一到实际产线部署就各种问题，最后项目烂尾。

2.2 选型时必须问清楚的五个问题

基于我这些年的踩坑经验，选型制造业AI智能体解决方案商时，有五个问题必须问清楚，缺一个都可能埋雷。

第一个问题：你们的OT数据采集能力到底怎么样？不要听他们说什么“支持多种工业协议”，要具体问：支持哪些PLC品牌？支持哪些通信协议？采集频率最高能到多少？断线重连机制是怎样的？数据缓存策略是什么？我见过一个解决方案商，宣称支持“所有主流PLC”，结果到现场发现，他们只支持西门子和三菱，欧姆龙的PLC需要额外开发驱动，工期直接拖了两个月。

第二个问题：你们的AI智能体决策延迟是多少？制造业的很多场景对实时性要求极高，比如运动控制、视觉检测、异常处理，延迟超过100毫秒可能就会导致生产事故。要问清楚：智能体的推理是在云端还是在边缘端？边缘端的算力配置是什么？从数据采集到决策输出的端到端延迟是多少？有没有做过压力测试？我见过一个方案，智能体部署在云端，推理延迟平均500毫秒，遇到网络波动直接飙到2秒，这种方案在产线上根本没法用。

第三个问题：你们的多智能体协同机制是怎样的？不要满足于“支持多智能体”这种模糊表述，要具体问：智能体之间怎么通信？是消息队列还是共享内存？协同协议是什么？冲突怎么解决？有没有全局优化？我见过一个方案，多个智能体之间通过REST API通信，一个智能体要等另一个智能体的HTTP响应才能继续执行，这种同步阻塞的模式在产线上就是灾难。

第四个问题：你们的模型更新和迭代机制是怎样的？制造业的工艺参数、设备状态、产品质量标准都在不断变化，AI智能体的模型需要持续更新。要问清楚：模型更新的频率是多少？是自动更新还是手动更新？更新过程中会不会影响生产？有没有A/B测试机制？我见过一个方案，模型更新需要停机操作，每次更新要停线4小时，这种方案在实际生产中根本不可接受。

第五个问题：你们的责任边界和售后服务是怎样的？这个问题最敏感但也最重要。要问清楚：如果AI智能体决策错误导致生产事故，责任怎么划分？是解决方案商全责还是双方共担？售后服务的响应时间是多少？有没有现场支持？备件供应周期是多长？我见过一个项目，AI智能体误判导致批量报废，解决方案商和制造企业互相扯皮，最后闹到对簿公堂。

2.3 不同规模企业的选型策略差异

选型策略不能一刀切，不同规模的企业要有不同的打法。

大型制造企业，年产值几十亿以上的，我建议采用“平台+生态”的策略。选择一家有实力的平台厂商作为底座，比如华为云或者阿里云，然后在上面集成多家专业厂商的智能体应用。这样做的好处是平台层的能力有保障，应用层可以灵活选择最优方案。但缺点是集成复杂度高，需要企业自己有较强的技术团队来统筹。

中型制造企业，年产值几亿到几十亿的，我建议采用“整体解决方案”的策略。选择一家在行业内有过成功案例的解决方案商，让他们提供从OT数据采集到AI智能体应用的全套方案。这样做的好处是责任清晰、交付周期短、运维简单。但缺点是容易被厂商锁定，后续扩展和替换成本高。

小型制造企业，年产值几千万到几亿的，我建议采用“场景化切入”的策略。不要一上来就搞全流程AI智能体，而是选择一个最痛的点，比如质检环节或者设备预测性维护，用轻量级的AI智能体方案先跑起来。这样做的好处是投入小、见效快、风险可控。等这个场景跑通了，再逐步扩展到其他场景。

3. 从零到一搭建制造业AI智能体的实操路径

3.1 第一步：场景选择与价值评估

搭建制造业AI智能体，第一步不是选技术，而是选场景。我见过太多企业，技术选型做了一大堆，最后发现选错了场景，白忙一场。

场景选择的原则是：高频、刚需、可量化、容错率高。高频是指这个场景每天都会发生很多次，比如质检、排产、设备巡检；刚需是指这个场景的痛点足够痛，不解决不行，比如质量问题导致的客户投诉；可量化是指这个场景的投入产出比可以算清楚，比如减少多少不良品、节省多少人工；容错率高是指即使AI智能体偶尔出错，也不会造成严重后果，比如文档审核、报表生成。

我一般建议企业从“设备预测性维护”或者“视觉质检”这两个场景切入。设备预测性维护的容错率相对较高，即使预测错了，最多是提前换了不该换的零件，不会导致停线；视觉质检的容错率也可以通过人工复检来兜底，而且效果立竿见影，能直接看到不良品检出率的提升。

场景选定后，要做价值评估。我常用的评估框架是：人工成本节省+质量损失减少+产能提升收益-系统建设成本-运维成本。举个例子，某工厂的质检环节有10个工人，每人每年成本10万，AI智能体上线后可以减少到3个工人，每年节省70万；不良品率从2%降到0.5%，按年产值1亿算，每年减少质量损失150万；质检速度提升带来的产能提升收益每年50万；系统建设成本一次性投入200万，每年运维成本20万。那么第一年的净收益是70+150+50-200-20=50万，第二年开始每年净收益250万。这个账算清楚了，老板才会批预算。

3.2 第二步：数据采集与OT/IT融合架构设计

场景选定后，下一步是数据采集和OT/IT融合架构设计。这是整个项目中最脏最累的活，但也是最关键的活。

数据采集的第一步是盘点数据源。要搞清楚：需要采集哪些设备的数据？这些设备支持什么通信协议？数据采集的频率要求是多少？数据需要保存多久？我一般会做一个数据源清单表格，把每台设备的品牌、型号、协议、接口类型、数据点表都列清楚。

| 设备名称 | 品牌 | 型号 | 通信协议 | 接口类型 | 采集频率 | 数据点位数 | |---------|------|------|---------|---------|---------|-----------| | 贴片机1 | 西门子 | SIPLACE TX | PROFINET | RJ45 | 100ms | 256 | | 回流焊1 | 劲拓 | NS-800 | Modbus TCP | RJ45 | 1s | 64 | | AOI1 | 欧姆龙 | VT-S730 | EtherNet/IP | RJ45 | 500ms | 128 | | 注塑机1 | 海天 | MA1600 | OPC UA | RJ45 | 1s | 96 |

数据源盘点清楚后，要设计OT/IT融合架构。我推荐的架构是“边缘采集+边缘计算+云端训练+边缘推理”的四层架构。

边缘采集层负责从设备采集原始数据，常用的工具包括Kepware、Ignition、Node-RED等。这一层的关键是协议转换和数据缓存，要确保在网络中断时数据不丢失。

边缘计算层负责数据的预处理和实时推理，常用的硬件包括工控机、边缘服务器、AI加速卡等。这一层的关键是算力配置和实时性保障，要根据智能体的推理需求选择合适的硬件。

云端训练层负责模型的训练和优化，常用的平台包括华为云ModelArts、阿里云PAI等。这一层的关键是数据质量和标注效率，要建立完善的数据标注流程和质量控制机制。

边缘推理层负责将训练好的模型部署到边缘端执行推理，常用的框架包括TensorRT、OpenVINO、ONNX Runtime等。这一层的关键是模型压缩和加速，要在保证精度的前提下尽可能降低推理延迟。

3.3 第三步：智能体设计与多智能体协同实现

架构设计完成后，进入智能体设计阶段。智能体设计包括三个部分：能力定义、决策逻辑、协同机制。

能力定义是指这个智能体要具备哪些能力。比如一个质检智能体，它的能力包括：图像采集、缺陷检测、分类分级、结果输出、异常报警。每个能力都要定义清楚输入输出接口和性能指标。

决策逻辑是指智能体如何根据输入做出决策。我一般推荐采用“规则引擎+机器学习模型”的混合决策模式。规则引擎负责处理确定性的逻辑，比如“如果缺陷面积大于5平方毫米，则判定为不合格”；机器学习模型负责处理不确定性的逻辑，比如“根据历史数据预测设备何时需要维护”。这种混合模式的好处是既能保证决策的可靠性，又能发挥AI的灵活性。

协同机制是指多个智能体之间如何协作。我推荐采用“发布-订阅”模式，所有智能体都连接到一个消息总线，通过发布和订阅消息来协同。比如质检智能体检测到缺陷后，发布一条“缺陷告警”消息，排产智能体订阅了这条消息，收到后自动调整后续工单的优先级；设备维护智能体也订阅了这条消息，收到后自动检查相关设备的运行参数。

# 智能体协同的伪代码示例 class QualityAgent: def detect(self, image): defect = self.model.predict(image) if defect.severity > THRESHOLD: self.message_bus.publish("defect_alert", { "defect_type": defect.type, "severity": defect.severity, "timestamp": time.now(), "equipment_id": self.equipment_id }) return defect class SchedulingAgent: def on_defect_alert(self, message): # 收到缺陷告警后，调整后续工单优先级 self.adjust_priority(message["equipment_id"]) self.reschedule() class MaintenanceAgent: def on_defect_alert(self, message): # 收到缺陷告警后，检查相关设备参数 self.check_equipment(message["equipment_id"]) if self.need_maintenance(): self.schedule_maintenance()

3.4 第四步：部署上线与持续迭代

智能体设计完成后，进入部署上线阶段。这个阶段最容易出问题，我总结了几条实操经验。

第一条：一定要做灰度发布。不要一次性全量上线，先选一条产线或者一个班次做试点，跑通了再逐步推广。我见过一个项目，一次性全厂上线，结果智能体误判导致整条产线停线，损失惨重。

第二条：一定要有人工兜底机制。AI智能体再聪明，也有犯错的时候。在关键决策环节，一定要保留人工确认的步骤。比如质检智能体判定不合格时，要有人工复检的环节；排产智能体调整工单时，要有计划员确认的步骤。

第三条：一定要建立数据闭环。智能体上线后，要持续收集运行数据，包括决策结果、人工修正记录、异常情况等。这些数据是模型迭代的宝贵素材。我一般建议每周做一次数据复盘，每月做一次模型迭代。

第四条：一定要监控关键指标。智能体的运行状态要实时监控，包括推理延迟、准确率、召回率、异常率等。一旦指标偏离阈值，要立即告警并处理。

4. 常见问题与排查技巧实录

4.1 数据采集层面的典型问题

问题一：设备数据采不上来。这是最常见的问题，原因可能有很多：协议不匹配、IP地址冲突、防火墙拦截、网关配置错误、设备本身故障。排查思路是：先用ping命令测试网络连通性，再用协议测试工具（如Modbus Poll）测试协议通信，最后检查网关的配置和日志。

问题二：数据采集频率不稳定。表现为数据时快时慢，有时候几秒才来一条，有时候一秒来几百条。原因通常是网络带宽不足或者网关性能瓶颈。排查思路是：用网络监控工具（如Wireshark）抓包分析，看是否有丢包或者重传；检查网关的CPU和内存使用率，看是否过载。

问题三：数据质量差。表现为数据缺失、数据跳变、数据重复。原因可能是传感器故障、信号干扰、采集程序bug。排查思路是：先检查传感器的工作状态，再用信号分析仪检查信号质量，最后审查采集程序的逻辑。

4.2 智能体决策层面的典型问题

问题一：智能体决策延迟高。表现为从数据输入到决策输出超过预期时间。原因可能是模型太大、算力不足、通信延迟。排查思路是：先测量端到端的延迟，定位瓶颈在哪个环节；如果是模型太大，做模型压缩和量化；如果是算力不足，升级硬件或者优化推理框架；如果是通信延迟，优化网络架构或者改用边缘推理。

问题二：智能体决策准确率低。表现为误判、漏判频繁。原因可能是训练数据不足、数据分布偏移、模型过拟合。排查思路是：先分析误判和漏判的案例，看是否有规律；如果是训练数据不足，补充标注数据；如果是数据分布偏移，做在线学习或者增量训练；如果是模型过拟合，增加正则化或者简化模型。

问题三：多智能体协同冲突。表现为多个智能体做出相互矛盾的决策。原因可能是协同协议不完善、优先级规则不清晰、冲突检测机制缺失。排查思路是：先复现冲突场景，分析冲突的根本原因；然后完善协同协议，明确优先级规则；最后增加冲突检测和消解机制。

4.3 系统运维层面的典型问题

问题一：系统稳定性差。表现为频繁宕机、服务不可用。原因可能是硬件故障、软件bug、资源泄漏。排查思路是：先检查硬件状态，看是否有故障告警；再检查软件日志，看是否有异常报错；最后做压力测试，看系统在高负载下的表现。

问题二：数据安全问题。表现为数据泄露、数据篡改。原因可能是网络隔离不彻底、访问控制不严格、加密措施不到位。排查思路是：先做网络安全评估，看是否有漏洞；再审查访问控制策略，看是否有越权访问；最后检查数据加密措施，看是否符合安全标准。

问题三：运维成本高。表现为人力投入大、硬件成本高、云服务费用高。原因可能是架构设计不合理、资源利用率低、自动化程度低。排查思路是：先做成本分析，看成本主要花在哪里；再优化架构设计，提高资源利用率；最后引入自动化运维工具，降低人力投入。

4.4 常见问题速查表

4.5 独家避坑技巧

技巧一：一定要做POC验证。不要相信解决方案商的PPT和Demo，一定要在自己的产线上做POC验证。POC的时间不用太长，两周就够了，但一定要覆盖真实的场景和数据。我见过太多项目，POC阶段跑得好好的，一到正式部署就各种问题，就是因为POC的环境太理想化了。

技巧二：一定要留足数据缓冲期。AI智能体的效果很大程度上取决于训练数据的质量和数量。我一般建议至少积累3个月的历史数据再开始训练模型，而且数据要覆盖各种工况，包括正常工况、异常工况、边界工况。

技巧三：一定要建立反馈闭环。智能体上线后，要建立人工反馈的机制。操作工发现智能体决策错误时，要能方便地标记和反馈。这些反馈数据是模型迭代的宝贵素材。我见过一个项目，智能体上线后没有反馈机制，模型半年没更新，准确率从95%掉到了80%。

技巧四：一定要做压力测试。产线满负荷运行时的数据量和决策请求量，可能是正常情况下的几倍甚至几十倍。上线前一定要做压力测试，确保系统在高负载下不会崩溃。我见过一个项目，正常运行时没问题，一到月底赶工就宕机，就是因为没有做压力测试。

技巧五：一定要有回滚方案。智能体上线后如果出现严重问题，要能快速回滚到人工模式。回滚方案要提前准备好，包括数据备份、配置备份、切换流程等。我见过一个项目，智能体出问题后没有回滚方案，产线停了8小时才恢复，损失惨重。

5. 制造业AI智能体的未来演进与个人实践体会

5.1 从“单点智能”到“全局智能”的演进路径

制造业AI智能体的发展，我判断会经历三个阶段：单点智能、产线智能、工厂智能。

单点智能是当前大多数企业所处的阶段，就是在某个特定工位或者特定环节部署一个AI智能体，解决一个具体问题。比如质检智能体、预测性维护智能体、排产智能体。这个阶段的特点是场景单一、数据封闭、价值有限。

产线智能是未来2-3年会逐步成熟的阶段，就是整条产线的多个智能体协同工作，实现产线级别的优化。比如当质检智能体发现质量异常时，排产智能体自动调整工单，设备维护智能体自动检查设备，工艺优化智能体自动调整参数。这个阶段的特点是场景复杂、数据互通、价值显著。

工厂智能是更远期的目标，就是整个工厂的所有智能体协同工作，实现工厂级别的全局优化。这个阶段需要解决的核心问题是：如何在海量智能体之间实现高效的协同和全局优化。这可能需要全新的技术架构和算法，比如基于博弈论的协同机制、基于强化学习的全局优化等。

5.2 我在实际项目中的几点体会

做了这么多制造业AI智能体的项目，我有几点很深的体会。

第一，技术不是最重要的，业务理解才是。我见过太多技术很牛但业务理解很浅的团队，做出来的东西根本不能用。制造业的AI智能体，一定要深入理解生产工艺、设备特性、质量标准和人员习惯，否则做出来的东西就是空中楼阁。

第二，不要追求大而全，要追求小而美。很多企业一上来就想做一个“全能智能体”，什么都能干。结果是什么都干不好。我建议从一个具体的、小的场景切入，做深做透，然后再逐步扩展。就像搭积木一样，一块一块搭，最后才能搭出高楼。

第三，人的因素永远不能忽视。AI智能体再智能，也是辅助人的工具，而不是替代人的。在项目推进过程中，一定要做好人员的沟通和培训，让操作工理解智能体的工作原理和决策逻辑，建立信任感。我见过一个项目，智能体做得很好，但操作工不信任它，总是手动干预，最后项目效果大打折扣。

第四，数据是长期的护城河。AI智能体的算法和模型可以买，但数据买不来。企业在推进AI智能体的过程中，一定要注重数据的积累和治理。数据质量越高、数据量越大，智能体的效果就越好。这是一个正向循环，越早开始积累，优势越大。

第五，要有耐心，不要指望一夜之间见效。制造业AI智能体的落地是一个长期的过程，从场景选择到数据采集，从模型训练到部署上线，从运行监控到持续迭代，每一个环节都需要时间和精力。我见过太多企业，做了三个月没看到明显效果就放弃了，非常可惜。

5.3 给正在推进AI智能体项目的同行几点建议

如果你正在推进制造业AI智能体项目，我有几点建议。

建议一：先做减法，再做加法。不要一上来就想做很多场景，先选一个最痛的点，做深做透，做出效果，然后再扩展。这样既能快速见效，又能积累经验，还能建立信心。

建议二：重视数据治理。数据是AI智能体的燃料，没有高质量的数据，再好的算法也跑不出好结果。在项目初期就要建立数据治理的规范和流程，包括数据采集、数据清洗、数据标注、数据存储、数据安全等。

建议三：建立跨部门的项目团队。AI智能体项目不是IT部门一个部门的事，需要生产、工艺、质量、设备、IT等多个部门的协同。我建议成立一个跨部门的项目组，由高层领导挂帅，各部门派人参与，定期沟通协调。

建议四：选择合适的合作伙伴。不要只看价格，要看能力、看案例、看服务。我建议至少对比3家以上的解决方案商，做详细的POC验证，选择最适合自己的合作伙伴。

建议五：做好长期投入的准备。AI智能体不是一次性投入，而是持续投入。除了初期的建设成本，还有后续的运维成本、迭代成本、培训成本。企业要做好预算规划，确保项目能够持续运行。

最后再分享一个小技巧：在智能体上线初期，可以设置一个“影子模式”，就是智能体在后台运行，做出决策但不实际执行，只是把决策结果和人工决策结果做对比。这样既能验证智能体的效果，又不会影响正常生产。等智能体的准确率达到一定水平后，再切换到“执行模式”。这个技巧我在多个项目中用过，效果很好，推荐大家试试。