1. 选型之前先理清制造企业部署AI智能体的真实需求先说一个我这两年反复见到的场景某工厂CIO开会时说“我们要上AI智能体平台”但问及具体业务场景回答是“先搭个平台后面再说”。这个思路在制造业是行不通的。制造业不像互联网公司可以为了技术尝鲜去烧资源。制造企业的AI智能体从第一天起就得回答三个问题它接什么数据、它连什么系统、它解决谁的问题。制造企业里所谓“AI智能体”说白了就是一个能自主完成任务的软件系统。它跟传统自动化最大的区别在于传统自动化是“如果A发生就执行B”流程写死了智能体是“给我一个目标我自己拆解步骤调工具、查数据、做决策”更像一个数字员工。比如设备坏了传统系统只会发告警工单智能体可以自己去查历史维修记录、对比同型号设备的故障特征、调取备件库存、生成维修方案甚至自动预约维修工——这一串动作传统MES系统做不了。但正因为智能体的“自主性”强它对平台的依赖就非常大。平台决定了这个智能体能不能看到数据、能不能调用系统、能不能安全地执行动作、出了问题能不能追责。平台选得不好智能体就是个纸面方案演示的时候看着聪明一接真实产线就露馅。所以我给制造企业的第一个建议是不要先选平台先选场景和系统边界。你至少要梳理出三张表一张是数据清单现有ERP、MES、SCADA、PLC各有哪些数据接口一张是系统清单哪些系统允许智能体直接操作哪些只允许只读一张是流程痛点清单哪个环节人工成本最高、响应最慢、错误率最高。这三张表定下来平台选型才有判断依据。再说说制造业独有的几个约束条件。首先是OT系统像PLC可编程逻辑控制器、SCADA数据采集与监控系统、DCS集散控制系统这些工业控制系统的协议五花八门Modbus、OPC UA、Profibus、EtherNet/IP各有各的脾气平台如果连OPC UA都接不顺那在生产侧基本就是废的。其次是网络安全要求很多制造企业有等保要求数据不能出内网大模型推理甚至要部署在本地或私有云这直接卡死了很多纯SaaS平台。第三是组织协作制造业的数字化团队通常不大一个平台如果要求IT、OT、算法、业务四个团队各配专人维护那基本跑不起来。2. 平台选型的六个硬指标照着打分就不会翻车我梳理了制造业选智能体平台时最关键的六个维度。这六个维度我建议做成打分表按企业自身情况加权比凭感觉选靠谱得多。2.1 系统集成能力能不能接上你的老系统制造业最不缺的就是“遗产系统”。工厂里跑着用了十五年的ERP、改了一百遍的MES、各个车间各自为政的SCADA系统之间数据口径对不上是常态。AI智能体平台的第一个考验就是它能接多少种数据源和系统。这里要特别注意平台说的“支持”跟“好用”是两回事。有些平台号称支持OPC UA但实际做下来需要写大量自定义脚本才能连上有些平台对SAP、Oracle ERP有现成的连接器但对国产的用友、金蝶就支持得一般。我的建议是在选型清单里把你企业实际在用的系统全都列出来挨个问厂商支持的成熟度最好让厂商当场演示连通。演示不出来的一律按“不支持”处理别听“后续版本会支持”这种话。另外制造业场景里还有一个特别重要的连接对象数据库里的时序数据。设备振动、温度、电流这些数据都是时间序列存在InfluxDB、TDengine或工业时序数据库里。平台如果对时序数据有原生的查询和处理能力会方便很多。有些平台的数据源列表里全是关系型数据库和文档数据库对时序数据的支持是空白的这种在制造业场景就要打问号。2.2 大模型兼容与切换成本别被一家模型厂商绑死AI智能体的大脑是大模型但大模型这行现在卷得厉害。今天你用GPT-4效果好明天一个开源模型微调出来可能更好还更便宜今天某家云厂商的大模型推理贵得离谱明天就降价一半。平台如果只能绑定一家模型服务商你后续会被动。我建议选型的硬性标准是平台能同时对接多家大模型API支持模型灵活切换最好是模型层跟业务层解耦的架构。具体来说智能体的技能编排、Prompt管理、知识库切片这些逻辑不应该依赖某个特定模型。换模型的时候只要重新评估一轮效果就行不用重新开发。工业场景还有一个特殊性很多数据不能出内网但车间里又不能自己训练一个大模型。折中方案是通用能力用云上大模型API涉及工艺参数、客户数据等敏感内容的推理用小模型或本地部署的模型处理。平台最好能支持“混合路由”——根据任务类型自动决定请求发给哪个模型。2.3 数据安全与权限颗粒度制造业的红线制造业的数据保密要求比很多人想象的严。产品BOM物料清单、工艺配方、设备参数、客户订单这些数据泄露出去就是真金白银的损失。平台在数据安全层面的能力直接决定这个方案能不能过企业的信息安全评审。几个重点考核项局域网部署能力平台是否支持完全部署在企业内网推理在本地完成不需要调用外部API。精细的权限控制不是简单地按“管理员/普通用户”分权要能精确到某个智能体只能读某个数据库的某几张表、某几个字段。操作审计追踪智能体每次调用外部系统、执行写操作都要有完整日志。制造业安全事故追责可不是闹着玩的。脱敏处理知识库里的敏感信息在上传和处理过程中能否自动脱敏。数据隔离如果你用的是多租户SaaS平台不同租户之间的数据隔离机制是什么样的有没有等保和行业认证。我见过有个企业选了个开源框架自己搭搭完才发现日志体系一塌糊涂智能体误操作改了生产订单的优先级查日志查了半天都定位不到原因。所以安全审计能力一定要在选型阶段就验证到位。2.4 智能体编排能力复杂任务能不能拆解智能体跟普通聊天机器人的区别在于它要做“任务编排”。比如“分析这台设备过去一周的故障趋势并生成检修建议”这个任务要拆成查时序数据库→调用故障诊断规则→读取历史维修工单→生成结构化报告→推送给设备主管。每一步都可能调用不同工具、不同数据源。平台对这类多步骤任务的编排能力决定了智能体是“聪明”还是“呆板”。看编排能力时关注两个层面一是流程的可视化编排界面最好能拖拽式定义任务流程不需要写大量代码二是智能体自主规划能力即模型自己决定调用哪些工具而不是每条路径都人工写死。两者各有适用场景生产规程类的任务建议人工编排为主毕竟工艺流程不能乱来分析报告类的任务可以放开让智能体自主规划。还有个细节平台要支持“人机协同”模式。制造业里有个现实问题——智能体再聪明关键决策还是得人来拍板。比如智能体生成了一份设备检修方案它不能直接下单采购零部件得发给工程师审批。平台要能定义“审批节点”做到“该自动化的地方自动化该卡住的地方卡住”。2.5 知识库与场景沉淀能力能不能继承老师傅的经验制造业最值钱的资产除了设备和数据就是老师傅脑子里的经验。一个干了二十年的设备维修老师傅听声音就知道设备哪儿不对这种经验很难写成规则但可以沉淀成知识库。平台要在知识库管理上下够功夫支持文档、表格、图片、音视频等多种格式的知识入库能自动做知识切片和向量化支持知识的版本管理和权限控制。更进一步要支持从对话记录中自动沉淀新知识——智能体在跟工程师交互中发现了新的处理方案能通过人工确认后自动加入知识库。有了这个能力企业的知识资产才能越用越厚。这里多说一句知识库的质量直接决定智能体的回答质量跟模型聪明程度关系反而没那么大。两个人用同一个大模型搭智能体一个投喂了高质量的设备维修手册、故障案例、工艺标准一个随便丢了几篇PPT进去效果天差地别。所以选平台的时候重点看知识库的处理管线是否成熟、是否支持增量更新、是否便于多人协作维护。2.6 工程化配套模型监控、效果评估、灰度发布缺一不可很多平台Demo演示时效果很好一上线就拉胯。关键问题出在工程化配套不足。制造企业的智能体上线牵涉到产线稳定性一定要有完善的工程化保障。效果评估体系能不能给智能体的回答质量打分比如定义一个测试集平台定期用测试集跑智能体看准确率有没有下降。这叫回归测试没有这个能力你都不知道一次更新到底改坏了什么。灰度发布与版本回滚智能体的行为逻辑改了先在少量工单上跑几天没问题再全量放量。出了问题能不能一键回滚到上一个版本。可观测性智能体每次任务的完整执行链路由日志记录清楚。这个前面在数据安全里提过但工程化层面还要更细比如召回率、Token消耗、工具调用成功率、单次任务耗时等指标。3. 市面平台类型盘点开源DIY、商业平台、云服务、自研底座怎么选不同类型的平台各有各的坑。我给制造企业做个现实向的盘点别被厂商的PPT带跑了节奏。3.1 开源框架类Dify、LangFlow、Coze开源版这类平台以Dify为代表加上LangFlow、Flowise、扣子开源版等。优点是可以私有化部署代码开放、可定制性强国内社区活跃中文技术支持好。Dify在知识库、工作流编排、模型对接、Agent能力方面做得相对均衡而且支持本地部署对制造企业来说是个不错的选择起点。但开源框架的问题是工程能力需要自己补齐。Dify本身不提供高可用的集群方案不提供脏活累活的监控告警、权限体系也比较简单。你拿它做几个内部知识问答机器人没问题但要支撑几十个智能体同时跑在产线上IT团队得有较强的二次开发能力。另外开源版本迭代快版本升级可能带来兼容性问题需要有人长期跟进维护。适合谁有3人以上专业开发团队、愿意投入长期维护成本、对数据安全要求极高必须完全内网部署的企业。3.2 商业AI平台类面向企业的一站式解决方案这类产品很多包括一些大厂的企业级AI平台、低代码智能体平台以及聚焦制造业的垂直类平台。它们的优势是开箱即用功能完整度好——权限、审计、监控、知识库、模型管理全都有不用自己拼积木。售前和实施团队还能帮你梳理场景。劣势也明显贵。按用户数、按Token量、按功能模块收费一年下来少则几十万多则上百万。而且这类平台的外部生态连接器主要覆盖的是通用企业软件SAP、Salesforce、钉钉、飞书等对工业现场特殊协议的适配深度参差不齐。如果你们工厂的PLC协议比较冷门可能还是得定制开发。适合谁预算充足、希望快速上线、内部数字化团队规模不大的企业。前期做好POC验证别签完合同才发现连接器不够用。3.3 云厂商托管服务类模型、平台一体化的便利选择阿里云、腾讯云、华为云、AWS等云厂商都有智能体平台跟自家大模型深度绑定。这类平台的优势是技术栈统一、上手快模型推理、知识库存储、算力扩展都在一朵云上解决。华为云在工业场景耕耘比较深有些制造企业的案例可以参考。劣势在于一是有绑定风险用久了就被套在单一云厂商生态里模型切换成本高二是数据合规问题很多制造企业过不了“数据出内网”这一关。如果企业整体上云战略清晰、对数据出域没有硬性限制这确实是最省心的路。但如果你所在行业有严格的数据安全要求这选项基本可以直接划掉。3.4 基于开源框架自研底座这是最重的一条路适合集团型制造企业、数字化成熟度高、有几十人IT团队的公司。具体做法是基于Dify或LangGraph等框架做二次开发加上统一登录、权限中心、审计系统、模型网关做成企业内部的智能体中台。这条路投入巨大但长期价值也最大。一是能力完全内化不依赖任何厂商后续想改哪里都行二是可以沉淀企业独有的工业Know-how形成面向产线的模板和技能库三是跟内部的IT系统MES、ERP、OA深度集成数据链路完全自主可控。我见过一个汽车零部件集团就是这么干的前期花了半年做技术验证后续一年内陆续上线了十几个内部智能体覆盖设备报修、工艺文档生成、供应链询价等场景。预算上省了License费但人力成本并不低。这条路走不走取决于企业最高管理层愿不愿意把它当成数字化的战略投资。4. 选型实操的六步法从场景梳理到平台落地这部分的建议来自我参与过的多个制造业AI项目按这个顺序推进踩坑概率会小很多。就算不能照搬理清思路也很有帮助。4.1 第一步锁定一到两个高价值场景别贪多制造企业AI选型最常见的失败模式是“贪多嚼不烂”——想一次性把设备、质量、供应链、工艺全做成智能体结果每个都没做好。我的建议是在设备智能运维、质量智能检测、工艺参数优化、供应链协同、知识管理这几个方向里选出最痛的一到两个场景先做深。怎么判断是不是“最痛”三个标准频次高每天都要做的重复性工作、成本高专家工时消耗大、容错低出错了影响生产。比如工厂的能源管理每天要做几十份报表数据分析师天天加班这就是高价值场景再比如设备报修故障响应慢直接影响产量这也是典型场景。选场景的时候业务部门的负责人必须亲自参与不能IT部门自己拍板。4.2 第二步把目标场景拆成智能体任务清单选定场景后把它拆解成智能体需要执行的原子任务。这一步做细了后面选型就是自动匹配根本不需要纠结。拿“设备智能运维”举例可以拆成任务一定时读取SCADA系统里设备的运行参数判断是否偏离正常工作区间。任务二设备出现异常时检索历史故障库、同类设备维修记录、设备说明书生成初步诊断报告。任务三诊断报告通过企业微信/钉钉推送给设备工程师工程师在线确认或修正。任务四确认需要维修后自动创建工单检查备件库存、协调维修档期并生成维修任务书。任务五维修完成后根据实际处理情况自动更新知识库和故障案例库。把每个任务对应的数据源、系统接口、触发条件、输出结果都写清楚。这张清单就是选型评分表最好的输入项。4.3 第三步用演示环境做一轮盲测方案一白遮百丑我特别不建议只看厂商的Demo定结论。厂商Demo是精心准备过的拿你现场的复杂数据一跑效果可能完全不是那么回事。正确做法是要求厂商用你提供的脱敏数据在测试环境里跑你的真实任务做一轮“盲测”——你不知道它内部怎么配置的只看结果。盲测的评分维度包括任务完成率、准确率、执行耗时、需要人工干预的次数。建议把同一批测试任务发给至少三家候选平台跑结果并列放在一起比。制造业场景不要求100%准确率但90%以下基本不可用。这个环节比较费时间但也是最能拉开平台档次的一步值得认真做。4.4 第四步量化评分选型决策表权重按企业情况调整把候选平台按我们前面说的六维能力打分每项1-10分乘以权重加总后排序。下面这张是我经常用的选型评分表可以参考评分维度权重建议评分要点系统集成能力25%支持的数据源/系统数量、工业协议适配深度、连接器的成熟度大模型兼容与切换15%是否支持多家模型、切换成本、混合路由能力数据安全与权限20%私有化部署、权限颗粒度、审计日志、知识脱敏智能体编排能力15%可视化编排、人工审批节点、工具调用复杂度知识库管理15%知识切片质量、增量更新、版本管理、协作能力工程化配套10%效果评估、灰度发布、可观测性、告警能力请注意这个权重不是固定的。比如你们企业特别在意数据安全那安全这项权重可以拉到30%如果你们团队开发能力强、倾向开源自研那工程化配套的权重就得提上来。评分表的颗粒度可以更细比如把“系统集成”再拆成“IT系统连接能力”和“OT系统连接能力”分项打分。4.5 第五步商务谈判时把“概念验证”写进合同选型结束了合同阶段还有个关键动作把POC验证的范围和时间周期写清楚。我见过不少企业合同签了实施做了三个月才发现平台根本接不上自家的老旧MES最后双方扯皮项目烂尾。建议在合同里约定清楚验收标准是什么比如“能完成5个指定场景的智能体任务、准确率不低于90%”、实施周期多长、超期怎么处理。这样一来厂商在销售阶段就会认真评估技术可行性不敢乱承诺。真正有底气的厂商是会接受这种约束的。4.6 第六步实施遵循“先读后写、先低后高”原则平台实施上线的时候有个我反复强调的原则先做只读型任务再做写入型任务。先让智能体只读数据、生成报告跑顺了再让它去对接工单、启动流程这类写操作。同理先上低风险场景比如知识问答、报告生成再上高风险场景比如直接控制工艺参数。制造业的安全性高于一切宁可慢一点也不能把产线搞出事故。5. 典型制造场景下平台选型的差异点分析同样一个平台在不同场景下的适配标准很不一样。我把制造业里最常见的几类AI智能体场景分别展开说说帮大家建立体感。5.1 设备预测性维护智能体对OT集成和数据接入要求最高这类智能体的核心是“连接”。平台必须能稳定读取SCADA/DCS系统的数据而且往往是高频时序数据。选型重点看三块一是对OPC UA、Modbus TCP等工业协议的适配深度是不是有现成的连接器二是对时序数据库的查询优化能力几万点位的高频数据能不能高效处理三是对接工单系统的流畅度毕竟预测到故障只是一个开始更重要的是触发维修流程。一个容易被忽略的细节设备数据的实时性要求很高平台的数据管道在设计时是不是低延迟的。有些平台的“数据接入”其实就是每天做一次批量同步这用在设备预测维护场景里基本没用。你得问清楚数据从PLC采集到智能体看到数据延迟是秒级还是分钟级。5.2 工艺参数优化智能体对知识库和仿真能力要求高工艺参数优化比如注塑机的温度、压力、速度怎么设定需要综合大量历史数据、工艺文档和专家经验。这里的关键是知识库得“厚”还要有跟工艺仿真软件联动的能力。选型时我建议重点考察平台能不能把历年工艺记录、实验报告、行业标准做成高效的知识库能不能跟你们的工艺仿真软件很多是专用软件对接让智能体跑“假设”分析。还有一个容易忽视的研究这类智能体建议做成“建议型”而非“执行型”——它输出参数推荐值由工艺工程师确认后再落实到产线。平台对“人工确认环节”的原生支持程度反而比“自主执行能力”更重要。5.3 供应链协同智能体对系统集成和企业间数据交换要求高供应链类的智能体比如供应商询价、订单跟催、库存预警核心挑战在于要打通多个企业的数据边界。对于企业内部要能接ERP、SRM供应商关系管理系统对于企业外部可能要跟供应商的EDI电子数据交换系统或协同平台对接。选型关注点一是ERP连接器的成熟度特别是你们在用的ERP品牌二是对非结构化文档的处理能力比如供应商的报价单、质检报告很多是PDF和表格智能体要能自动解析对齐三是多租户与权限隔离能力如果你要给多个供应商开不同的门户数据隔离是硬底线。5.4 制造知识管理智能体对知识管线和检索质量要求高这是制造业最容易出成果的智能体方向。把散落在老师傅脑子里、硬盘里、纸版文件里的经验变成可查询、可问答的活知识。这个场景对平台的要求集中在知识库模块支持的文档格式广度、切片效果、语义检索的准确率、知识更新的及时性。测试的时候有一个简单方法把你的知识库文档导入平台准备30个真实问题看回答的准确率和引用来源是否可靠。制造业的知识管理如果回答错了还引用了一个错误的文档来源那比不回答更麻烦。所以平台要支持“带来源引用”的回答模式并且知识库要有版本审批机制让专家对入库内容把关。6. 基于实际部署经验的避坑清单这些坑我替你踩过最后分享几个项目里真实踩过的坑。这些经验在厂商文档里看不到碰上一次就是几周时间搭进去。6.1 数据源连通性验证放在了商务谈判之后结果是灾难这是最大的坑没有之一。有个项目选型时厂商SaaS平台演示得天花乱坠场景本身也不复杂合同一签才发现它连不上工厂里的老MES数据库版本太低、又没有开放API。最后花了两个多月做定制开发项目才勉强跑起来。所以数据源连通性验证一定要放在合同签订之前而且是拿着你们自己的真实环境和数据来测不能只在会议室里看PPT。6.2 低估了知识库建设的工作量以为导入文档就够了很多人觉得知识库嘛把Word、PDF导进去就行。实际上文档要清洗、要去重、要打标签、要划分访问权限、要定期更新——这些工作需要业务专家跟IT一起做。我建议在项目计划里单独列一块“知识工程”的工作预算占整体实施成本的20%-30%不算夸张。纯靠平台自动切片的文档做出来的知识问答效果一定很粗糙。6.3 大模型并不是越强越好还要看推理成本和响应速度制造企业的智能体很多是“高频、短请求”——比如操作工在产线上问一句“这个报警代码是什么意思”要求秒级响应。如果每次问答都走几百亿参数的大模型Token成本高、响应也慢。实际情况里很多场景用一个7B或13B的小模型就能解决。平台能不能按任务复杂度做模型分级路由直接影响你的运营成本和体验。我见过一个企业上线初期所有请求都走最强模型当月推理账单出来之后财务差点把项目叫停。后来改成“简单问答走小模型、复杂推理走大模型”的混合架构成本降了60%以上。这类经验在选型阶段就要跟平台方确认清楚。6.4 智能体平台跟现有IT治理体系的对接比想象中复杂制造企业通常有一套严格的IT治理体系统一身份认证AD/LDAP工单系统是某个品牌审批流是另一个系统。智能体平台要融入这套体系需要管理员花不少精力做配置。选型时记得问支持SAML/OAuth2单点登录吗工作流引擎能对接现有审批中心吗邮件/企业微信/钉钉通知渠道通不通这些看似不起眼的功能决定平台能不能真正走进日常工作流。我建议在POC阶段就把这些“非智能”的功能一并验证别只管AI效果。6.5 忽略了持续运营组织智能体上线三个月后开始退化智能体平台不是一次性项目是持续运营的产品。知识库要更新模型要调优智能体的行为要迭代。很多企业上线时热火朝天三个月后没人维护知识库过期了、模型版本落后了、准确率下降了最后被业务部门弃用。我建议在立项时就配好“产品运营”角色——哪怕是兼职也要有人对智能体的效果负责定期看数据、更新知识、发布新版本。7. 选型决策参考要点汇总如果你现在正处于选型的关键节点我整理了一份决策参考方便你把思路收拢到几个核心问题上先确认企业内部是否有完整的数字化基础数据有没有在线化、系统接口开放程度如何。如果这一步都没做选什么平台都白搭。用“实际任务盲测”替代“看演示”拿真实业务场景和数据把至少三家候选平台放在同一标准下比一比。平台能力之外认真评估厂商在制造业的行业积累——有没有同行业的成功案例、有没有懂业务的实施顾问这比技术参数本身更影响落地效果。权衡短期上线和长期成本不要刚起步就上重平台也不要因为省钱选一个扩展性差的开源方案最后推倒重来。无论选哪家把运营和迭代放进规划AI智能体的价值是在持续使用中滚出来的。制造企业的AI智能体平台选型本质上不是选工具而是选一条跟自身业务阶段匹配的演进路线。平台只是一个容器真正的核心是你能否借此把产线经验数据化、把隐性知识显性化、把人工操作智能化。想清楚现在处于哪个阶段、目标是什么再回来选平台决定会好做很多。 制造业AI智能体平台选型指南：六大硬指标与避坑实践
1. 选型之前先理清制造企业部署AI智能体的真实需求先说一个我这两年反复见到的场景某工厂CIO开会时说“我们要上AI智能体平台”但问及具体业务场景回答是“先搭个平台后面再说”。这个思路在制造业是行不通的。制造业不像互联网公司可以为了技术尝鲜去烧资源。制造企业的AI智能体从第一天起就得回答三个问题它接什么数据、它连什么系统、它解决谁的问题。制造企业里所谓“AI智能体”说白了就是一个能自主完成任务的软件系统。它跟传统自动化最大的区别在于传统自动化是“如果A发生就执行B”流程写死了智能体是“给我一个目标我自己拆解步骤调工具、查数据、做决策”更像一个数字员工。比如设备坏了传统系统只会发告警工单智能体可以自己去查历史维修记录、对比同型号设备的故障特征、调取备件库存、生成维修方案甚至自动预约维修工——这一串动作传统MES系统做不了。但正因为智能体的“自主性”强它对平台的依赖就非常大。平台决定了这个智能体能不能看到数据、能不能调用系统、能不能安全地执行动作、出了问题能不能追责。平台选得不好智能体就是个纸面方案演示的时候看着聪明一接真实产线就露馅。所以我给制造企业的第一个建议是不要先选平台先选场景和系统边界。你至少要梳理出三张表一张是数据清单现有ERP、MES、SCADA、PLC各有哪些数据接口一张是系统清单哪些系统允许智能体直接操作哪些只允许只读一张是流程痛点清单哪个环节人工成本最高、响应最慢、错误率最高。这三张表定下来平台选型才有判断依据。再说说制造业独有的几个约束条件。首先是OT系统像PLC可编程逻辑控制器、SCADA数据采集与监控系统、DCS集散控制系统这些工业控制系统的协议五花八门Modbus、OPC UA、Profibus、EtherNet/IP各有各的脾气平台如果连OPC UA都接不顺那在生产侧基本就是废的。其次是网络安全要求很多制造企业有等保要求数据不能出内网大模型推理甚至要部署在本地或私有云这直接卡死了很多纯SaaS平台。第三是组织协作制造业的数字化团队通常不大一个平台如果要求IT、OT、算法、业务四个团队各配专人维护那基本跑不起来。2. 平台选型的六个硬指标照着打分就不会翻车我梳理了制造业选智能体平台时最关键的六个维度。这六个维度我建议做成打分表按企业自身情况加权比凭感觉选靠谱得多。2.1 系统集成能力能不能接上你的老系统制造业最不缺的就是“遗产系统”。工厂里跑着用了十五年的ERP、改了一百遍的MES、各个车间各自为政的SCADA系统之间数据口径对不上是常态。AI智能体平台的第一个考验就是它能接多少种数据源和系统。这里要特别注意平台说的“支持”跟“好用”是两回事。有些平台号称支持OPC UA但实际做下来需要写大量自定义脚本才能连上有些平台对SAP、Oracle ERP有现成的连接器但对国产的用友、金蝶就支持得一般。我的建议是在选型清单里把你企业实际在用的系统全都列出来挨个问厂商支持的成熟度最好让厂商当场演示连通。演示不出来的一律按“不支持”处理别听“后续版本会支持”这种话。另外制造业场景里还有一个特别重要的连接对象数据库里的时序数据。设备振动、温度、电流这些数据都是时间序列存在InfluxDB、TDengine或工业时序数据库里。平台如果对时序数据有原生的查询和处理能力会方便很多。有些平台的数据源列表里全是关系型数据库和文档数据库对时序数据的支持是空白的这种在制造业场景就要打问号。2.2 大模型兼容与切换成本别被一家模型厂商绑死AI智能体的大脑是大模型但大模型这行现在卷得厉害。今天你用GPT-4效果好明天一个开源模型微调出来可能更好还更便宜今天某家云厂商的大模型推理贵得离谱明天就降价一半。平台如果只能绑定一家模型服务商你后续会被动。我建议选型的硬性标准是平台能同时对接多家大模型API支持模型灵活切换最好是模型层跟业务层解耦的架构。具体来说智能体的技能编排、Prompt管理、知识库切片这些逻辑不应该依赖某个特定模型。换模型的时候只要重新评估一轮效果就行不用重新开发。工业场景还有一个特殊性很多数据不能出内网但车间里又不能自己训练一个大模型。折中方案是通用能力用云上大模型API涉及工艺参数、客户数据等敏感内容的推理用小模型或本地部署的模型处理。平台最好能支持“混合路由”——根据任务类型自动决定请求发给哪个模型。2.3 数据安全与权限颗粒度制造业的红线制造业的数据保密要求比很多人想象的严。产品BOM物料清单、工艺配方、设备参数、客户订单这些数据泄露出去就是真金白银的损失。平台在数据安全层面的能力直接决定这个方案能不能过企业的信息安全评审。几个重点考核项局域网部署能力平台是否支持完全部署在企业内网推理在本地完成不需要调用外部API。精细的权限控制不是简单地按“管理员/普通用户”分权要能精确到某个智能体只能读某个数据库的某几张表、某几个字段。操作审计追踪智能体每次调用外部系统、执行写操作都要有完整日志。制造业安全事故追责可不是闹着玩的。脱敏处理知识库里的敏感信息在上传和处理过程中能否自动脱敏。数据隔离如果你用的是多租户SaaS平台不同租户之间的数据隔离机制是什么样的有没有等保和行业认证。我见过有个企业选了个开源框架自己搭搭完才发现日志体系一塌糊涂智能体误操作改了生产订单的优先级查日志查了半天都定位不到原因。所以安全审计能力一定要在选型阶段就验证到位。2.4 智能体编排能力复杂任务能不能拆解智能体跟普通聊天机器人的区别在于它要做“任务编排”。比如“分析这台设备过去一周的故障趋势并生成检修建议”这个任务要拆成查时序数据库→调用故障诊断规则→读取历史维修工单→生成结构化报告→推送给设备主管。每一步都可能调用不同工具、不同数据源。平台对这类多步骤任务的编排能力决定了智能体是“聪明”还是“呆板”。看编排能力时关注两个层面一是流程的可视化编排界面最好能拖拽式定义任务流程不需要写大量代码二是智能体自主规划能力即模型自己决定调用哪些工具而不是每条路径都人工写死。两者各有适用场景生产规程类的任务建议人工编排为主毕竟工艺流程不能乱来分析报告类的任务可以放开让智能体自主规划。还有个细节平台要支持“人机协同”模式。制造业里有个现实问题——智能体再聪明关键决策还是得人来拍板。比如智能体生成了一份设备检修方案它不能直接下单采购零部件得发给工程师审批。平台要能定义“审批节点”做到“该自动化的地方自动化该卡住的地方卡住”。2.5 知识库与场景沉淀能力能不能继承老师傅的经验制造业最值钱的资产除了设备和数据就是老师傅脑子里的经验。一个干了二十年的设备维修老师傅听声音就知道设备哪儿不对这种经验很难写成规则但可以沉淀成知识库。平台要在知识库管理上下够功夫支持文档、表格、图片、音视频等多种格式的知识入库能自动做知识切片和向量化支持知识的版本管理和权限控制。更进一步要支持从对话记录中自动沉淀新知识——智能体在跟工程师交互中发现了新的处理方案能通过人工确认后自动加入知识库。有了这个能力企业的知识资产才能越用越厚。这里多说一句知识库的质量直接决定智能体的回答质量跟模型聪明程度关系反而没那么大。两个人用同一个大模型搭智能体一个投喂了高质量的设备维修手册、故障案例、工艺标准一个随便丢了几篇PPT进去效果天差地别。所以选平台的时候重点看知识库的处理管线是否成熟、是否支持增量更新、是否便于多人协作维护。2.6 工程化配套模型监控、效果评估、灰度发布缺一不可很多平台Demo演示时效果很好一上线就拉胯。关键问题出在工程化配套不足。制造企业的智能体上线牵涉到产线稳定性一定要有完善的工程化保障。效果评估体系能不能给智能体的回答质量打分比如定义一个测试集平台定期用测试集跑智能体看准确率有没有下降。这叫回归测试没有这个能力你都不知道一次更新到底改坏了什么。灰度发布与版本回滚智能体的行为逻辑改了先在少量工单上跑几天没问题再全量放量。出了问题能不能一键回滚到上一个版本。可观测性智能体每次任务的完整执行链路由日志记录清楚。这个前面在数据安全里提过但工程化层面还要更细比如召回率、Token消耗、工具调用成功率、单次任务耗时等指标。3. 市面平台类型盘点开源DIY、商业平台、云服务、自研底座怎么选不同类型的平台各有各的坑。我给制造企业做个现实向的盘点别被厂商的PPT带跑了节奏。3.1 开源框架类Dify、LangFlow、Coze开源版这类平台以Dify为代表加上LangFlow、Flowise、扣子开源版等。优点是可以私有化部署代码开放、可定制性强国内社区活跃中文技术支持好。Dify在知识库、工作流编排、模型对接、Agent能力方面做得相对均衡而且支持本地部署对制造企业来说是个不错的选择起点。但开源框架的问题是工程能力需要自己补齐。Dify本身不提供高可用的集群方案不提供脏活累活的监控告警、权限体系也比较简单。你拿它做几个内部知识问答机器人没问题但要支撑几十个智能体同时跑在产线上IT团队得有较强的二次开发能力。另外开源版本迭代快版本升级可能带来兼容性问题需要有人长期跟进维护。适合谁有3人以上专业开发团队、愿意投入长期维护成本、对数据安全要求极高必须完全内网部署的企业。3.2 商业AI平台类面向企业的一站式解决方案这类产品很多包括一些大厂的企业级AI平台、低代码智能体平台以及聚焦制造业的垂直类平台。它们的优势是开箱即用功能完整度好——权限、审计、监控、知识库、模型管理全都有不用自己拼积木。售前和实施团队还能帮你梳理场景。劣势也明显贵。按用户数、按Token量、按功能模块收费一年下来少则几十万多则上百万。而且这类平台的外部生态连接器主要覆盖的是通用企业软件SAP、Salesforce、钉钉、飞书等对工业现场特殊协议的适配深度参差不齐。如果你们工厂的PLC协议比较冷门可能还是得定制开发。适合谁预算充足、希望快速上线、内部数字化团队规模不大的企业。前期做好POC验证别签完合同才发现连接器不够用。3.3 云厂商托管服务类模型、平台一体化的便利选择阿里云、腾讯云、华为云、AWS等云厂商都有智能体平台跟自家大模型深度绑定。这类平台的优势是技术栈统一、上手快模型推理、知识库存储、算力扩展都在一朵云上解决。华为云在工业场景耕耘比较深有些制造企业的案例可以参考。劣势在于一是有绑定风险用久了就被套在单一云厂商生态里模型切换成本高二是数据合规问题很多制造企业过不了“数据出内网”这一关。如果企业整体上云战略清晰、对数据出域没有硬性限制这确实是最省心的路。但如果你所在行业有严格的数据安全要求这选项基本可以直接划掉。3.4 基于开源框架自研底座这是最重的一条路适合集团型制造企业、数字化成熟度高、有几十人IT团队的公司。具体做法是基于Dify或LangGraph等框架做二次开发加上统一登录、权限中心、审计系统、模型网关做成企业内部的智能体中台。这条路投入巨大但长期价值也最大。一是能力完全内化不依赖任何厂商后续想改哪里都行二是可以沉淀企业独有的工业Know-how形成面向产线的模板和技能库三是跟内部的IT系统MES、ERP、OA深度集成数据链路完全自主可控。我见过一个汽车零部件集团就是这么干的前期花了半年做技术验证后续一年内陆续上线了十几个内部智能体覆盖设备报修、工艺文档生成、供应链询价等场景。预算上省了License费但人力成本并不低。这条路走不走取决于企业最高管理层愿不愿意把它当成数字化的战略投资。4. 选型实操的六步法从场景梳理到平台落地这部分的建议来自我参与过的多个制造业AI项目按这个顺序推进踩坑概率会小很多。就算不能照搬理清思路也很有帮助。4.1 第一步锁定一到两个高价值场景别贪多制造企业AI选型最常见的失败模式是“贪多嚼不烂”——想一次性把设备、质量、供应链、工艺全做成智能体结果每个都没做好。我的建议是在设备智能运维、质量智能检测、工艺参数优化、供应链协同、知识管理这几个方向里选出最痛的一到两个场景先做深。怎么判断是不是“最痛”三个标准频次高每天都要做的重复性工作、成本高专家工时消耗大、容错低出错了影响生产。比如工厂的能源管理每天要做几十份报表数据分析师天天加班这就是高价值场景再比如设备报修故障响应慢直接影响产量这也是典型场景。选场景的时候业务部门的负责人必须亲自参与不能IT部门自己拍板。4.2 第二步把目标场景拆成智能体任务清单选定场景后把它拆解成智能体需要执行的原子任务。这一步做细了后面选型就是自动匹配根本不需要纠结。拿“设备智能运维”举例可以拆成任务一定时读取SCADA系统里设备的运行参数判断是否偏离正常工作区间。任务二设备出现异常时检索历史故障库、同类设备维修记录、设备说明书生成初步诊断报告。任务三诊断报告通过企业微信/钉钉推送给设备工程师工程师在线确认或修正。任务四确认需要维修后自动创建工单检查备件库存、协调维修档期并生成维修任务书。任务五维修完成后根据实际处理情况自动更新知识库和故障案例库。把每个任务对应的数据源、系统接口、触发条件、输出结果都写清楚。这张清单就是选型评分表最好的输入项。4.3 第三步用演示环境做一轮盲测方案一白遮百丑我特别不建议只看厂商的Demo定结论。厂商Demo是精心准备过的拿你现场的复杂数据一跑效果可能完全不是那么回事。正确做法是要求厂商用你提供的脱敏数据在测试环境里跑你的真实任务做一轮“盲测”——你不知道它内部怎么配置的只看结果。盲测的评分维度包括任务完成率、准确率、执行耗时、需要人工干预的次数。建议把同一批测试任务发给至少三家候选平台跑结果并列放在一起比。制造业场景不要求100%准确率但90%以下基本不可用。这个环节比较费时间但也是最能拉开平台档次的一步值得认真做。4.4 第四步量化评分选型决策表权重按企业情况调整把候选平台按我们前面说的六维能力打分每项1-10分乘以权重加总后排序。下面这张是我经常用的选型评分表可以参考评分维度权重建议评分要点系统集成能力25%支持的数据源/系统数量、工业协议适配深度、连接器的成熟度大模型兼容与切换15%是否支持多家模型、切换成本、混合路由能力数据安全与权限20%私有化部署、权限颗粒度、审计日志、知识脱敏智能体编排能力15%可视化编排、人工审批节点、工具调用复杂度知识库管理15%知识切片质量、增量更新、版本管理、协作能力工程化配套10%效果评估、灰度发布、可观测性、告警能力请注意这个权重不是固定的。比如你们企业特别在意数据安全那安全这项权重可以拉到30%如果你们团队开发能力强、倾向开源自研那工程化配套的权重就得提上来。评分表的颗粒度可以更细比如把“系统集成”再拆成“IT系统连接能力”和“OT系统连接能力”分项打分。4.5 第五步商务谈判时把“概念验证”写进合同选型结束了合同阶段还有个关键动作把POC验证的范围和时间周期写清楚。我见过不少企业合同签了实施做了三个月才发现平台根本接不上自家的老旧MES最后双方扯皮项目烂尾。建议在合同里约定清楚验收标准是什么比如“能完成5个指定场景的智能体任务、准确率不低于90%”、实施周期多长、超期怎么处理。这样一来厂商在销售阶段就会认真评估技术可行性不敢乱承诺。真正有底气的厂商是会接受这种约束的。4.6 第六步实施遵循“先读后写、先低后高”原则平台实施上线的时候有个我反复强调的原则先做只读型任务再做写入型任务。先让智能体只读数据、生成报告跑顺了再让它去对接工单、启动流程这类写操作。同理先上低风险场景比如知识问答、报告生成再上高风险场景比如直接控制工艺参数。制造业的安全性高于一切宁可慢一点也不能把产线搞出事故。5. 典型制造场景下平台选型的差异点分析同样一个平台在不同场景下的适配标准很不一样。我把制造业里最常见的几类AI智能体场景分别展开说说帮大家建立体感。5.1 设备预测性维护智能体对OT集成和数据接入要求最高这类智能体的核心是“连接”。平台必须能稳定读取SCADA/DCS系统的数据而且往往是高频时序数据。选型重点看三块一是对OPC UA、Modbus TCP等工业协议的适配深度是不是有现成的连接器二是对时序数据库的查询优化能力几万点位的高频数据能不能高效处理三是对接工单系统的流畅度毕竟预测到故障只是一个开始更重要的是触发维修流程。一个容易被忽略的细节设备数据的实时性要求很高平台的数据管道在设计时是不是低延迟的。有些平台的“数据接入”其实就是每天做一次批量同步这用在设备预测维护场景里基本没用。你得问清楚数据从PLC采集到智能体看到数据延迟是秒级还是分钟级。5.2 工艺参数优化智能体对知识库和仿真能力要求高工艺参数优化比如注塑机的温度、压力、速度怎么设定需要综合大量历史数据、工艺文档和专家经验。这里的关键是知识库得“厚”还要有跟工艺仿真软件联动的能力。选型时我建议重点考察平台能不能把历年工艺记录、实验报告、行业标准做成高效的知识库能不能跟你们的工艺仿真软件很多是专用软件对接让智能体跑“假设”分析。还有一个容易忽视的研究这类智能体建议做成“建议型”而非“执行型”——它输出参数推荐值由工艺工程师确认后再落实到产线。平台对“人工确认环节”的原生支持程度反而比“自主执行能力”更重要。5.3 供应链协同智能体对系统集成和企业间数据交换要求高供应链类的智能体比如供应商询价、订单跟催、库存预警核心挑战在于要打通多个企业的数据边界。对于企业内部要能接ERP、SRM供应商关系管理系统对于企业外部可能要跟供应商的EDI电子数据交换系统或协同平台对接。选型关注点一是ERP连接器的成熟度特别是你们在用的ERP品牌二是对非结构化文档的处理能力比如供应商的报价单、质检报告很多是PDF和表格智能体要能自动解析对齐三是多租户与权限隔离能力如果你要给多个供应商开不同的门户数据隔离是硬底线。5.4 制造知识管理智能体对知识管线和检索质量要求高这是制造业最容易出成果的智能体方向。把散落在老师傅脑子里、硬盘里、纸版文件里的经验变成可查询、可问答的活知识。这个场景对平台的要求集中在知识库模块支持的文档格式广度、切片效果、语义检索的准确率、知识更新的及时性。测试的时候有一个简单方法把你的知识库文档导入平台准备30个真实问题看回答的准确率和引用来源是否可靠。制造业的知识管理如果回答错了还引用了一个错误的文档来源那比不回答更麻烦。所以平台要支持“带来源引用”的回答模式并且知识库要有版本审批机制让专家对入库内容把关。6. 基于实际部署经验的避坑清单这些坑我替你踩过最后分享几个项目里真实踩过的坑。这些经验在厂商文档里看不到碰上一次就是几周时间搭进去。6.1 数据源连通性验证放在了商务谈判之后结果是灾难这是最大的坑没有之一。有个项目选型时厂商SaaS平台演示得天花乱坠场景本身也不复杂合同一签才发现它连不上工厂里的老MES数据库版本太低、又没有开放API。最后花了两个多月做定制开发项目才勉强跑起来。所以数据源连通性验证一定要放在合同签订之前而且是拿着你们自己的真实环境和数据来测不能只在会议室里看PPT。6.2 低估了知识库建设的工作量以为导入文档就够了很多人觉得知识库嘛把Word、PDF导进去就行。实际上文档要清洗、要去重、要打标签、要划分访问权限、要定期更新——这些工作需要业务专家跟IT一起做。我建议在项目计划里单独列一块“知识工程”的工作预算占整体实施成本的20%-30%不算夸张。纯靠平台自动切片的文档做出来的知识问答效果一定很粗糙。6.3 大模型并不是越强越好还要看推理成本和响应速度制造企业的智能体很多是“高频、短请求”——比如操作工在产线上问一句“这个报警代码是什么意思”要求秒级响应。如果每次问答都走几百亿参数的大模型Token成本高、响应也慢。实际情况里很多场景用一个7B或13B的小模型就能解决。平台能不能按任务复杂度做模型分级路由直接影响你的运营成本和体验。我见过一个企业上线初期所有请求都走最强模型当月推理账单出来之后财务差点把项目叫停。后来改成“简单问答走小模型、复杂推理走大模型”的混合架构成本降了60%以上。这类经验在选型阶段就要跟平台方确认清楚。6.4 智能体平台跟现有IT治理体系的对接比想象中复杂制造企业通常有一套严格的IT治理体系统一身份认证AD/LDAP工单系统是某个品牌审批流是另一个系统。智能体平台要融入这套体系需要管理员花不少精力做配置。选型时记得问支持SAML/OAuth2单点登录吗工作流引擎能对接现有审批中心吗邮件/企业微信/钉钉通知渠道通不通这些看似不起眼的功能决定平台能不能真正走进日常工作流。我建议在POC阶段就把这些“非智能”的功能一并验证别只管AI效果。6.5 忽略了持续运营组织智能体上线三个月后开始退化智能体平台不是一次性项目是持续运营的产品。知识库要更新模型要调优智能体的行为要迭代。很多企业上线时热火朝天三个月后没人维护知识库过期了、模型版本落后了、准确率下降了最后被业务部门弃用。我建议在立项时就配好“产品运营”角色——哪怕是兼职也要有人对智能体的效果负责定期看数据、更新知识、发布新版本。7. 选型决策参考要点汇总如果你现在正处于选型的关键节点我整理了一份决策参考方便你把思路收拢到几个核心问题上先确认企业内部是否有完整的数字化基础数据有没有在线化、系统接口开放程度如何。如果这一步都没做选什么平台都白搭。用“实际任务盲测”替代“看演示”拿真实业务场景和数据把至少三家候选平台放在同一标准下比一比。平台能力之外认真评估厂商在制造业的行业积累——有没有同行业的成功案例、有没有懂业务的实施顾问这比技术参数本身更影响落地效果。权衡短期上线和长期成本不要刚起步就上重平台也不要因为省钱选一个扩展性差的开源方案最后推倒重来。无论选哪家把运营和迭代放进规划AI智能体的价值是在持续使用中滚出来的。制造企业的AI智能体平台选型本质上不是选工具而是选一条跟自身业务阶段匹配的演进路线。平台只是一个容器真正的核心是你能否借此把产线经验数据化、把隐性知识显性化、把人工操作智能化。想清楚现在处于哪个阶段、目标是什么再回来选平台决定会好做很多。