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万。那么第一年的净收益是7015050-200-2050万第二年开始每年净收益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 常见问题速查表问题类别典型表现可能原因排查方法解决方案数据采集数据采不上来协议不匹配、网络不通ping测试、协议测试更换网关、调整配置数据采集采集频率不稳定带宽不足、网关过载抓包分析、性能监控升级网络、优化网关数据采集数据质量差传感器故障、信号干扰传感器检查、信号分析更换传感器、增加滤波智能体决策决策延迟高模型太大、算力不足延迟测量、瓶颈定位模型压缩、硬件升级智能体决策准确率低数据不足、分布偏移案例分析、数据统计补充数据、增量训练智能体决策协同冲突协议不完善、优先级不清场景复现、根因分析完善协议、明确规则系统运维稳定性差硬件故障、软件bug硬件检查、日志分析硬件更换、bug修复系统运维数据安全网络隔离不彻底安全评估、访问审查加强隔离、严格管控系统运维运维成本高架构不合理、自动化低成本分析、资源监控优化架构、引入自动化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智能体不是一次性投入而是持续投入。除了初期的建设成本还有后续的运维成本、迭代成本、培训成本。企业要做好预算规划确保项目能够持续运行。最后再分享一个小技巧在智能体上线初期可以设置一个“影子模式”就是智能体在后台运行做出决策但不实际执行只是把决策结果和人工决策结果做对比。这样既能验证智能体的效果又不会影响正常生产。等智能体的准确率达到一定水平后再切换到“执行模式”。这个技巧我在多个项目中用过效果很好推荐大家试试。
