这两年制造业的IT圈子里问得最多的问题已经从“AI能干嘛”变成了“AI智能体到底怎么落地”。工厂里MES、ERP、SCADA、PLM系统一大堆数据不缺业务痛点也足够明确但真到要部署AI智能体的时候很多团队反而卡在了最前面的环节——平台怎么选。选云平台怕数据出问题选开源怕没人运维选商业方案又怕被厂商绑定。这篇文章把我带项目时踩过的坑、做过的调研、和供应商“过招”的经验整理成一套可复用的选型方法重点解决三件事该用什么标准看平台、怎么在真实场景里做验证、哪些坑最容易在选型阶段被忽略。希望正在做技术调研或者准备立项的朋友能直接拿走参考。1. 先别急着看平台把需求的底细摸清楚1.1 制造企业的AI智能体本质上分三种“工种”很多团队选型选不下去不是因为平台不好而是根本说不清楚自己要的“智能体”到底解决什么问题。我习惯把制造业的智能体需求拆成三类每一类对平台的能力要求完全不同。第一类是问答顾问型。员工通过自然语言向智能体提问智能体基于企业知识库回答问题比如“这台注塑机的常见故障有哪些”“这个工件的SOP第几步有特殊要求”。这类需求最典型落地也最快核心考察的是平台的知识库管理能力、RAG检索增强生成效果以及文档解析能力。第二类是流程执行型。智能体接到指令后调用业务系统API完成实际操作比如“帮我创建一个设备维修工单”“把这批物料的状态改为待检”。这类需求对平台的Agent编排能力、系统集成能力要求极高知识库反而不是重点。第三类是数据分析型。智能体按自然语言问题去查询数据库、生成报表、做归因分析比如“这个月A线OEE下降了5%帮我分析可能原因”。这类需求要求平台具备可靠的数据源接入和多步推理能力。我说的这三类不是互斥的一个完整的智能体平台往往要同时支持三种能力但不同场景的权重不一样。前面做需求拆解的时候要先把业务部门真正的“痛点场景”定位到某一类或者某两类上再去评估平台——否则就会陷入“每个平台看起来都差不多”的迷茫。1.2 三条技术路线先判断自己是哪一种确定场景之后第二个要决策的是技术路线。市面上所有方案基本上可以归成三类纯自研、开源低代码平台、商业平台。纯自研也就是基于LangChain、LlamaIndex这类框架从头搭Agent编排层再自己写知识库、自己接模型、自己做前端。这条路适合算法和工程团队都比较强、且业务定制极其深刻的头部企业。优点是自由度最高缺点也很实在开发周期至少一个季度起步而且后期维护基础设施、监控、权限、知识更新这些“脏活”都要自己扛。我见过一家汽车零部件企业一开始雄心勃勃做了半年自研最后发现最耗时间的不是Agent框架而是数据清洗、接口联调、知识标注团队直接被拖垮。开源低代码平台典型代表是Dify、RAGFlow这类项目。它们提供可视化的工作流编排、知识库接入、模型管理、API发布对制造企业来说性价比比较高尤其是IT团队有一定开发能力但不想从零造轮子的情况。你可以跑在私有服务器上数据不出厂逻辑也看得见改得动。代价是需要自己运维这套平台模型接入也基本靠自己搞定。商业平台包括国内大厂的智能体开发平台、垂直厂商的私有化交付方案等等。优点很明显上手快、功能全、企业级支持完善甚至有些厂商能把大模型、算力、智能体平台、实施服务打包成一体机交付。缺点就是要花钱而且存在平台绑定风险后面我会专门讲。判断路线并没有绝对的对错我一般用两个问题快速筛选你的团队能接受多少开发和运维成本你的数据安全要求允许上云吗这两个问题答案出来了路线基本就能定一半。1.3 预算、团队、业务话语权同样会左右选型方向这里插一个容易忽略的软性因素项目是由谁推动的。制造业的数字化项目很多时候推动力不一样选型结果就完全不一样。如果是业务部门比如生产部、设备部主导他们往往更在意上线速度和最终效果对技术底座是不是完全可控没那么敏感。这时候选商业低代码平台或者云托管平台更容易快速拿到业务反馈形成正循环。如果是IT部门主导推进往往要考虑系统长期演进、数据安全、可维护性倾向于私有化部署或开源方案。还有一种常见情况是“领导拍板要上AI”这时候建议做一套完整的技术选型文档把不同路线的优劣势、成本、风险全部列出来既是给决策层看的也是给自己留的“保护伞”。预算方面同样不要只看软件授权费。私有化部署要考虑服务器和GPU成本开源方案要算人力维护成本商业平台要算按量计费或者年费模式下的远期费用。很多制造企业一开始雄心勃勃要全流程私有化结果被算力成本劝退最后选择了“敏感数据走私有化小模型、通用场景走云端大模型”的混合路线。这个折中方式我觉得在未来很长一段时间里都会是主流。2. 平台选型的核心逻辑开放性比功能清单更重要2.1 三种平台形态云端SaaS、开源私有化、商业私有化把技术路线和业务需求对齐之后再看平台的具体形态。目前市场上的AI智能体平台从部署方式上可以分成三大类每一类的优劣势非常鲜明。我直接做了一张对比表方便大家做快速判断。对比维度云端SaaS平台开源私有化平台商业私有化/一体机部署方式公有云托管自有服务器/私有云客户机房/专有云上手速度最快注册即用需要一定开发能力视实施复杂度而定初始成本订阅费/按量计费软件免费运维成本高授权费服务费较高数据安全数据出企业边界需严格评估数据本地化完全可控数据本地化但依赖供应商扩展性弹性扩展很方便要靠自己扩由供应商方案决定维护难度低高中等典型适用对象需求验证、中小工厂IT能力强、追求自主可控的团队对合规有强要求的大中型制造企业这里要提醒一句一个平台是“云端”还是“私有化”不等于它的能力是“强”还是“弱”。有些商用私有化版本功能会比公有云落后一个版本有些开源平台通过生态弥补了功能不足。所以形态只能作为筛选维度不能作为最终判断标准。2.2 可移植性制造业最容易忽视的隐藏风险选型的时候大多数团队都在比功能、比价格很少有人会问一个特别关键的问题如果未来我不想用你们平台了我的智能体、知识库、工作流能顺利迁走吗制造业的数据资产体量非常大知识库里的SOP文档、设备维修记录、工艺参数可能积累了好几年。如果平台把Agent定义、知识库格式、插件生态都绑定在自己的一套封闭格式里一旦迁移基本等于全部重做。这个成本在选型阶段很难被感知但项目上线一年之后想换平台的代价会变得极其高昂。我建议在选型阶段就做一次“退出演练”。直接向供应商或者开源社区抛出这三个问题智能体的定义文件用什么格式存储知识库内容能否批量导出数据源连接配置能不能在平台外部复用如果对方回答含糊或者需要“专业服务团队支持”那你就要警惕了。相反如果平台支持标准化的API接口、Agent定义可以导出为JSON/YAML这类通用格式知识库能一键打包下载那大概率可移植性不会太差。2.3 部署与安全边界数据不出厂是很多制造业的底线这一点对大型制造企业尤其重要。很多工厂的工艺数据、BOM表、质检数据涉及其核心竞争力集团合规部门对数据出厂的审批非常严格。所以在选型时要优先确认平台是否支持纯私有化部署至少在数据链路层面要保证业务数据不会离开企业边界。这里建议问供应商一句话“大模型可以调用云端基础模型但我的业务数据是不是只用在内网侧做检索和上下文处理不会上传到你们服务器”很多商用平台为了兼顾效果和部署成本会采用“混合架构”——模型在云端业务数据在本地中间做一层脱敏。这种方案本身没问题但必须要在合同和SLA里写清楚。其次要看权限模型。制造企业里不同车间、不同岗位能接触的知识范围差别很大产线班长能看的设备维保手册未必允许研发工程师回写一线操作工不应该通过智能体调取实验阶段的工艺参数。如果平台的权限体系只能做到“全员可见”那它就不适合直接投产。3. 数据接入和知识库这关直接决定智能体“聪明不聪明”3.1 先说结论企业知识库并不是只放在向量数据库里很多人在百度“AI智能体的企业知识库是存放在向量数据库中的吗”这个问题本身的出发点就有偏差。向量数据库解决的是“非结构化文本的相似度检索”问题比如把PDF文档切块后转成向量再根据用户问题找到语义上最相关的片段。但制造企业的数据形态远比这个复杂MES里的生产工单是结构化数据设备传感器产生的是时序数据PLM里可能有三维图纸和物料清单老师傅的经验则散落在聊天记录和纸质表格里。把这些数据全部硬塞进向量库不仅效果差还会造成资源浪费。做得比较稳的智能体平台通常是“混合检索”思路结构化数据走SQL查询或者API调用非结构化文本走向量检索关键词精确匹配走ESElasticsearch那套全文检索。有些场景甚至要接知识图谱比如设备故障诊断故障码、部件关系、维修记录之间有明确的逻辑关联图谱比向量检索要可靠得多。所以选平台的时候别只看它宣称的“知识库功能很强”要问清楚它怎么处理结构化数据。比较好的平台会提供“数据库查询节点”或“API调用插件”让智能体在对话过程中先去查系统拿到实时数据再组织回答而不是只靠知识库里的静态文档“瞎编”。3.2 数据源接入和文档解析能力很容易被低估制造业的数据散落在各种老系统和五花八门的文件里ERP有新有旧MES是五年前供应商定制的SCADA用的协议千奇百怪内部文档既有标准PDF也有扫描件、照片、甚至手写表单。智能体平台如果只有一两个标准连接器那落地的时候会非常痛苦。我建议从两个维度做评估。第一是内置连接器数量看它是否支持你企业正在用的那几个核心系统比如SAP、用友、金蝶、主流MES厂商的API。如果平台有成熟的连接器或者插件市场那对接成本会低很多如果全靠自己写API其实相当于把集成工作全部承接回来了。第二是文档解析能力尤其是OCR、表格抽取、版式还原。制造业里大量SOP是扫描的PDF很多工艺参数藏在图纸里这些文件如果不经过高质量解析直接进向量库检索效果堪忧。可以拿10份自己公司“最难处理”的文档去测各个平台这是最能看出差距的环节。3.3 知识更新和权限管控智能体“过期”和“越权”都是大问题知识库不是建好就完事的。制造企业的工艺文件、SOP、设备手册经常更新如果智能体的知识库不能跟业务系统做实时或准实时同步那用户很快就会遇到“智能体给的是旧版本流程”这种尴尬情况。所以选型时要考察平台的知识库生命周期管理能力是否支持定时增量更新文档版本更新后能不能自动替换旧内容有没有知识版本回滚机制这些细节在POC阶段就要问清楚等项目上线后再补就麻烦了。权限管控方面这里多提醒一句权限要能细化到“知识库级别”和“Agent级别”。有些平台能做到文档级甚至切片级权限控制那是最好的如果只能按“工作空间”切那至少要把不同敏感级别的知识放在不同的Agent里再通过路由把用户引导到特定Agent避免一个入口问遍所有数据。4. 用一张评分表把候选平台拉到同一维度上打分4.1 八维评分表及权重建议在拿多个平台对比的时候凭感觉做判断很容易被供应商的演示带偏。我习惯先拉一张评分表把维度、权重定下来再让项目组每位核心成员分别打分最后取平均值。这里给出一个适合制造业场景的参考表。评分维度建议权重关键考察问题Agent编排能力15%是否支持多Agent协作、复杂工作流、条件分支能否处理“感知-决策-执行”闭环知识库/RAG能力15%文档解析、混合检索、知识更新、权限控制是否完善模型接入灵活性10%能否接入私有化小模型和云端大模型是否支持多模型切换系统集成能力15%内置连接器、API接口、Webhook能否和MES/ERP/IM等系统快速打通安全与权限15%部署边界、数据加密、细粒度权限、审计日志可观测性与调试10%能否查看Agent的完整推理轨迹、调试工作流、定位失败节点部署与运维10%私有化难度、版本升级机制、监控告警是否完善生态与文档10%社区活跃度、官方文档质量、第三方插件丰富度权重不是固定的。如果你们最看重数据安全安全与权限这个维度的权重就可以调到20%以上如果业务方催得紧、要快速上线Agent编排和开箱即用的能力权重可以提高。评分表的作用是帮助团队把模糊的感觉变成可以被讨论的差距而不是追求一个绝对“正确”的总分。4.2 重点说模型接入灵活性和推理成本两个维度值得单独拉出来讲因为它们影响长期使用体验。模型接入灵活性核心问题是平台是否被单一模型厂商绑定。制造业的真实场景常常是“既要又要”涉及工艺参数、内部成本等敏感信息的问题希望走私有化部署的7B/13B小模型而面向员工的通用问答、文本摘要可以用能力更强的云端大模型。如果平台的模型接入层封闭只允许调用自家模型那你就失去了这个弹性。好在主流的开源平台和不少商业平台都已经支持自定义接入OpenAI兼容接口、多家国产模型以及私有化模型服务这个要仔细确认。推理成本这里要给制造业朋友提个醒别只看大模型的token单价。一个Agent任务的成本 多次模型调用的叠加。比如用户问“帮我分析A线效率下降原因”智能体内部可能要执行意图识别一次、工具调用规划一次、查数据库一次、生成分析报告一次、润色输出一次加起来可能调用模型5到10次。即使单次token价格不高一个完整Agent任务的总成本也要按量放大。所以评估成本时应该拿一条真实业务链路去测“单任务成本”而不是拿一次简单对话去算账。4.3 解读评分结果得分最高不代表最适合评分表的最大作用是避免“一票决定”但它本身也有陷阱。最典型的情况是某个云端SaaS平台总分很高但它的私有化版本功能明显落后甚至很多新特性只有公有云用户才能用。如果你所在的制造企业恰好只能私有化部署那这个高分就失真了。所以在解读评分结果时要先把“部署形态”作为一票否决项把所有不满足数据安全底线或者部署要求的平台排除掉再去看剩余平台之间的分数差距。另外每一项评分背后都要有证据支撑最好是在POC实测中获得的体验而不是完全依赖供应商的宣讲。一般来说最终候选平台留在23家就好不要贪多。5. 进场实测一套快速POC方法避免选型靠“感觉”5.1 POC场景怎么选业务价值高、数据易得、结果可判定再详细的评分表也替代不了亲手试一遍。有些团队把POC做成了“供应商演示会”下载平台后随便传两个文档聊了几句就下结论这样基本测不出真实水平。更合理的做法是选一个能充分暴露平台能力差距的典型业务场景。我给制造业朋友推荐三个很适合做POC的场景第一个是设备维修知识问答让智能体基于一批维修手册和故障记录回答问题验证知识库解析和RAG效果第二个是异常工单自动生成从产线报障信息中提取设备号、故障现象、紧急程度通过API调用工单系统创建维修单验证Agent的工具调用和工作流编排能力第三个是质量报告摘要生成输入一份PDF质检报告按照模板生成摘要和初步判定结论验证文档解析和多步推理。三个场景分别对应了我之前说的三类智能体覆盖了制造企业最普遍的落地诉求。选一个最贴近公司痛点的去做就够了不用一次做完。POC之前一定要自己准备数据拿二三十份真实的脱敏文档或一个测试版的业务系统API这样才能看出平台在“脏数据”场景下的真实表现。5.2 两小时快速验证清单这里给一份可以直接照抄的轻量级验证方法不需要等到POC完整结束在每个候选平台上花两个多小时就能快速分辨高低。第一步上传5到10份典型的文档比如SOP、设备手册、检验规范观察文档解析的质量表格有没有乱章节标题有没有识别出来中文排版有没有问题。第二步建一个知识库连续提5个关联性问题和一个跨文档问题看回答是否准确、有没有引用来源、能不能拒绝回答超出知识范围的问题。第三步配置一个最简单的带记忆的多轮Agent连续追问几轮验证上下文理解能力。第四步接一个真实的API做一个“查数生成”的小流程比如根据物料编码查询库存并生成缺料提醒。第五步测试权限隔离设置两个不同权限的用户看低权限用户能否绕过限制访问高权限知识库。这五步走下来平台的底线能力基本就清楚了。如果哪一步卡壳严重后面正式实施时只会更麻烦。5.3 POC环境与实际量产环境的三个落差POC做得顺利也不代表量产一定会顺利。我总结过三个最容易出现落差的环节在选型阶段就要有心理预期。第一个是数据量落差。POC时只有几十份文档召回率自然高量产时面对几千份甚至上万份文档知识库需要分库、分片检索策略要做优化回答质量可能会下降。解决办法是提前问清楚平台有没有测试过百万级文档以上的规模。第二个是系统延迟与API限流。POC时你调的API可能只有几个用户在用量产时MES接口扛不扛得住智能体的高频调用完全是另一回事。要在技术方案里提前设计缓存层和异步任务机制。第三个是网络边界。很多制造企业的MES系统在内网AI平台在DMZ区或者专有云中间还隔着防火墙和工业网闸。如果网络策略没有提前打通POC时演示得很流畅的API调用到了生产环境根本连不上。这个一定要尽早拉上网络和安全团队一起评审。6. 常见问题与选型避坑实录6.1 数据的“出境”和“能力出境”合同里要写清楚数据出境问题不少团队会关注到但“能力出境”很容易被忽略。有些平台虽然做了私有化部署但控制面也就是平台的管理后台、License校验、模型调用鉴权依赖供应商的云端服务。如果你们工厂的内网环境完全隔离甚至没有访问外网的权限那这类平台根本跑不起来或者断网之后平台直接瘫痪。所以在合同阶段要逐条确认业务数据是否只存本地模型调用是否存在数据回传平台License校验是否依赖外网控制面在断网情况下是否可用这些条款能落到纸面上的一定要落到纸面上不要听销售口头承诺。6.2 智能体平台和RPA、低代码平台是什么关系做技术选型的时候经常有企业把AI智能体平台和上一轮的RPA、低代码平台搞混。这里帮大家做一个简单的区分RPA适合规则明确、流程固定、重复性强的任务比如定时抓取网页数据、批量登录系统做信息录入低代码平台则更多地用来搭管理类应用比如审批表单、数据看板核心是“以表单驱动流程”而AI智能体平台的核心是用大模型来完成“理解、决策、生成”这类需要认知能力的任务。制造业里比较务实的做法不是用智能体平台去替代RPA和ESB而是在它们之上做一层“大脑”。智能体负责理解用户意图、拆解任务、选择工具然后把具体的操作交给RPA去执行或者通过ESB调用业务系统接口。如果一个智能体平台能提供灵活的API或者自定义插件能力能和你们现有的RPA系统顺利集成那会是加分项。6.3 供应商的交付和服务能力比想象中更重要最后说一个很多人吃过亏的点平台本身再强如果没有懂制造业场景的实施团队落地照样很难。不少制造企业买了平台之后供应商只做基础培训剩下的全靠自己的IT团队摸索最后项目越做越慢业务部门失去耐心整个项目被叫停。在选型时一定要问清供应商三个问题你们在制造业做过多少家客户的智能体落地实施团队是在本地还是远程支持团队里有没有懂生产业务的人还是只会讲技术概念同时验收标准也要提前定。比如知识库问答准确率怎么测、Agent任务的完成率怎么评估、系统故障的响应SLA怎么约定这些都应该在项目启动会之前写清楚。我在实际操盘项目时最大的体会是选平台这件事本身并不难难的是在选型之前把需求、团队、预算、安全边界全部想清楚。别指望有一个平台能一次性解决所有问题也别追求一步到位的大而全方案。先选定一个高频、痛点明确、数据条件成熟的场景把一个智能体真正跑通让业务部门看到效果再逐步横向复制到更多场景这才是制造业里比较稳的落地路径。另外平台选完之后不是终点知识库的持续更新、Agent的持续调优、使用反馈的回收这些机制如果不建立起来再好的平台也会越用越笨。选型只是第一步真正的功夫在后面的持续运营上。
制造业AI智能体平台选型指南：从需求拆解到POC验证的关键方法
这两年制造业的IT圈子里问得最多的问题已经从“AI能干嘛”变成了“AI智能体到底怎么落地”。工厂里MES、ERP、SCADA、PLM系统一大堆数据不缺业务痛点也足够明确但真到要部署AI智能体的时候很多团队反而卡在了最前面的环节——平台怎么选。选云平台怕数据出问题选开源怕没人运维选商业方案又怕被厂商绑定。这篇文章把我带项目时踩过的坑、做过的调研、和供应商“过招”的经验整理成一套可复用的选型方法重点解决三件事该用什么标准看平台、怎么在真实场景里做验证、哪些坑最容易在选型阶段被忽略。希望正在做技术调研或者准备立项的朋友能直接拿走参考。1. 先别急着看平台把需求的底细摸清楚1.1 制造企业的AI智能体本质上分三种“工种”很多团队选型选不下去不是因为平台不好而是根本说不清楚自己要的“智能体”到底解决什么问题。我习惯把制造业的智能体需求拆成三类每一类对平台的能力要求完全不同。第一类是问答顾问型。员工通过自然语言向智能体提问智能体基于企业知识库回答问题比如“这台注塑机的常见故障有哪些”“这个工件的SOP第几步有特殊要求”。这类需求最典型落地也最快核心考察的是平台的知识库管理能力、RAG检索增强生成效果以及文档解析能力。第二类是流程执行型。智能体接到指令后调用业务系统API完成实际操作比如“帮我创建一个设备维修工单”“把这批物料的状态改为待检”。这类需求对平台的Agent编排能力、系统集成能力要求极高知识库反而不是重点。第三类是数据分析型。智能体按自然语言问题去查询数据库、生成报表、做归因分析比如“这个月A线OEE下降了5%帮我分析可能原因”。这类需求要求平台具备可靠的数据源接入和多步推理能力。我说的这三类不是互斥的一个完整的智能体平台往往要同时支持三种能力但不同场景的权重不一样。前面做需求拆解的时候要先把业务部门真正的“痛点场景”定位到某一类或者某两类上再去评估平台——否则就会陷入“每个平台看起来都差不多”的迷茫。1.2 三条技术路线先判断自己是哪一种确定场景之后第二个要决策的是技术路线。市面上所有方案基本上可以归成三类纯自研、开源低代码平台、商业平台。纯自研也就是基于LangChain、LlamaIndex这类框架从头搭Agent编排层再自己写知识库、自己接模型、自己做前端。这条路适合算法和工程团队都比较强、且业务定制极其深刻的头部企业。优点是自由度最高缺点也很实在开发周期至少一个季度起步而且后期维护基础设施、监控、权限、知识更新这些“脏活”都要自己扛。我见过一家汽车零部件企业一开始雄心勃勃做了半年自研最后发现最耗时间的不是Agent框架而是数据清洗、接口联调、知识标注团队直接被拖垮。开源低代码平台典型代表是Dify、RAGFlow这类项目。它们提供可视化的工作流编排、知识库接入、模型管理、API发布对制造企业来说性价比比较高尤其是IT团队有一定开发能力但不想从零造轮子的情况。你可以跑在私有服务器上数据不出厂逻辑也看得见改得动。代价是需要自己运维这套平台模型接入也基本靠自己搞定。商业平台包括国内大厂的智能体开发平台、垂直厂商的私有化交付方案等等。优点很明显上手快、功能全、企业级支持完善甚至有些厂商能把大模型、算力、智能体平台、实施服务打包成一体机交付。缺点就是要花钱而且存在平台绑定风险后面我会专门讲。判断路线并没有绝对的对错我一般用两个问题快速筛选你的团队能接受多少开发和运维成本你的数据安全要求允许上云吗这两个问题答案出来了路线基本就能定一半。1.3 预算、团队、业务话语权同样会左右选型方向这里插一个容易忽略的软性因素项目是由谁推动的。制造业的数字化项目很多时候推动力不一样选型结果就完全不一样。如果是业务部门比如生产部、设备部主导他们往往更在意上线速度和最终效果对技术底座是不是完全可控没那么敏感。这时候选商业低代码平台或者云托管平台更容易快速拿到业务反馈形成正循环。如果是IT部门主导推进往往要考虑系统长期演进、数据安全、可维护性倾向于私有化部署或开源方案。还有一种常见情况是“领导拍板要上AI”这时候建议做一套完整的技术选型文档把不同路线的优劣势、成本、风险全部列出来既是给决策层看的也是给自己留的“保护伞”。预算方面同样不要只看软件授权费。私有化部署要考虑服务器和GPU成本开源方案要算人力维护成本商业平台要算按量计费或者年费模式下的远期费用。很多制造企业一开始雄心勃勃要全流程私有化结果被算力成本劝退最后选择了“敏感数据走私有化小模型、通用场景走云端大模型”的混合路线。这个折中方式我觉得在未来很长一段时间里都会是主流。2. 平台选型的核心逻辑开放性比功能清单更重要2.1 三种平台形态云端SaaS、开源私有化、商业私有化把技术路线和业务需求对齐之后再看平台的具体形态。目前市场上的AI智能体平台从部署方式上可以分成三大类每一类的优劣势非常鲜明。我直接做了一张对比表方便大家做快速判断。对比维度云端SaaS平台开源私有化平台商业私有化/一体机部署方式公有云托管自有服务器/私有云客户机房/专有云上手速度最快注册即用需要一定开发能力视实施复杂度而定初始成本订阅费/按量计费软件免费运维成本高授权费服务费较高数据安全数据出企业边界需严格评估数据本地化完全可控数据本地化但依赖供应商扩展性弹性扩展很方便要靠自己扩由供应商方案决定维护难度低高中等典型适用对象需求验证、中小工厂IT能力强、追求自主可控的团队对合规有强要求的大中型制造企业这里要提醒一句一个平台是“云端”还是“私有化”不等于它的能力是“强”还是“弱”。有些商用私有化版本功能会比公有云落后一个版本有些开源平台通过生态弥补了功能不足。所以形态只能作为筛选维度不能作为最终判断标准。2.2 可移植性制造业最容易忽视的隐藏风险选型的时候大多数团队都在比功能、比价格很少有人会问一个特别关键的问题如果未来我不想用你们平台了我的智能体、知识库、工作流能顺利迁走吗制造业的数据资产体量非常大知识库里的SOP文档、设备维修记录、工艺参数可能积累了好几年。如果平台把Agent定义、知识库格式、插件生态都绑定在自己的一套封闭格式里一旦迁移基本等于全部重做。这个成本在选型阶段很难被感知但项目上线一年之后想换平台的代价会变得极其高昂。我建议在选型阶段就做一次“退出演练”。直接向供应商或者开源社区抛出这三个问题智能体的定义文件用什么格式存储知识库内容能否批量导出数据源连接配置能不能在平台外部复用如果对方回答含糊或者需要“专业服务团队支持”那你就要警惕了。相反如果平台支持标准化的API接口、Agent定义可以导出为JSON/YAML这类通用格式知识库能一键打包下载那大概率可移植性不会太差。2.3 部署与安全边界数据不出厂是很多制造业的底线这一点对大型制造企业尤其重要。很多工厂的工艺数据、BOM表、质检数据涉及其核心竞争力集团合规部门对数据出厂的审批非常严格。所以在选型时要优先确认平台是否支持纯私有化部署至少在数据链路层面要保证业务数据不会离开企业边界。这里建议问供应商一句话“大模型可以调用云端基础模型但我的业务数据是不是只用在内网侧做检索和上下文处理不会上传到你们服务器”很多商用平台为了兼顾效果和部署成本会采用“混合架构”——模型在云端业务数据在本地中间做一层脱敏。这种方案本身没问题但必须要在合同和SLA里写清楚。其次要看权限模型。制造企业里不同车间、不同岗位能接触的知识范围差别很大产线班长能看的设备维保手册未必允许研发工程师回写一线操作工不应该通过智能体调取实验阶段的工艺参数。如果平台的权限体系只能做到“全员可见”那它就不适合直接投产。3. 数据接入和知识库这关直接决定智能体“聪明不聪明”3.1 先说结论企业知识库并不是只放在向量数据库里很多人在百度“AI智能体的企业知识库是存放在向量数据库中的吗”这个问题本身的出发点就有偏差。向量数据库解决的是“非结构化文本的相似度检索”问题比如把PDF文档切块后转成向量再根据用户问题找到语义上最相关的片段。但制造企业的数据形态远比这个复杂MES里的生产工单是结构化数据设备传感器产生的是时序数据PLM里可能有三维图纸和物料清单老师傅的经验则散落在聊天记录和纸质表格里。把这些数据全部硬塞进向量库不仅效果差还会造成资源浪费。做得比较稳的智能体平台通常是“混合检索”思路结构化数据走SQL查询或者API调用非结构化文本走向量检索关键词精确匹配走ESElasticsearch那套全文检索。有些场景甚至要接知识图谱比如设备故障诊断故障码、部件关系、维修记录之间有明确的逻辑关联图谱比向量检索要可靠得多。所以选平台的时候别只看它宣称的“知识库功能很强”要问清楚它怎么处理结构化数据。比较好的平台会提供“数据库查询节点”或“API调用插件”让智能体在对话过程中先去查系统拿到实时数据再组织回答而不是只靠知识库里的静态文档“瞎编”。3.2 数据源接入和文档解析能力很容易被低估制造业的数据散落在各种老系统和五花八门的文件里ERP有新有旧MES是五年前供应商定制的SCADA用的协议千奇百怪内部文档既有标准PDF也有扫描件、照片、甚至手写表单。智能体平台如果只有一两个标准连接器那落地的时候会非常痛苦。我建议从两个维度做评估。第一是内置连接器数量看它是否支持你企业正在用的那几个核心系统比如SAP、用友、金蝶、主流MES厂商的API。如果平台有成熟的连接器或者插件市场那对接成本会低很多如果全靠自己写API其实相当于把集成工作全部承接回来了。第二是文档解析能力尤其是OCR、表格抽取、版式还原。制造业里大量SOP是扫描的PDF很多工艺参数藏在图纸里这些文件如果不经过高质量解析直接进向量库检索效果堪忧。可以拿10份自己公司“最难处理”的文档去测各个平台这是最能看出差距的环节。3.3 知识更新和权限管控智能体“过期”和“越权”都是大问题知识库不是建好就完事的。制造企业的工艺文件、SOP、设备手册经常更新如果智能体的知识库不能跟业务系统做实时或准实时同步那用户很快就会遇到“智能体给的是旧版本流程”这种尴尬情况。所以选型时要考察平台的知识库生命周期管理能力是否支持定时增量更新文档版本更新后能不能自动替换旧内容有没有知识版本回滚机制这些细节在POC阶段就要问清楚等项目上线后再补就麻烦了。权限管控方面这里多提醒一句权限要能细化到“知识库级别”和“Agent级别”。有些平台能做到文档级甚至切片级权限控制那是最好的如果只能按“工作空间”切那至少要把不同敏感级别的知识放在不同的Agent里再通过路由把用户引导到特定Agent避免一个入口问遍所有数据。4. 用一张评分表把候选平台拉到同一维度上打分4.1 八维评分表及权重建议在拿多个平台对比的时候凭感觉做判断很容易被供应商的演示带偏。我习惯先拉一张评分表把维度、权重定下来再让项目组每位核心成员分别打分最后取平均值。这里给出一个适合制造业场景的参考表。评分维度建议权重关键考察问题Agent编排能力15%是否支持多Agent协作、复杂工作流、条件分支能否处理“感知-决策-执行”闭环知识库/RAG能力15%文档解析、混合检索、知识更新、权限控制是否完善模型接入灵活性10%能否接入私有化小模型和云端大模型是否支持多模型切换系统集成能力15%内置连接器、API接口、Webhook能否和MES/ERP/IM等系统快速打通安全与权限15%部署边界、数据加密、细粒度权限、审计日志可观测性与调试10%能否查看Agent的完整推理轨迹、调试工作流、定位失败节点部署与运维10%私有化难度、版本升级机制、监控告警是否完善生态与文档10%社区活跃度、官方文档质量、第三方插件丰富度权重不是固定的。如果你们最看重数据安全安全与权限这个维度的权重就可以调到20%以上如果业务方催得紧、要快速上线Agent编排和开箱即用的能力权重可以提高。评分表的作用是帮助团队把模糊的感觉变成可以被讨论的差距而不是追求一个绝对“正确”的总分。4.2 重点说模型接入灵活性和推理成本两个维度值得单独拉出来讲因为它们影响长期使用体验。模型接入灵活性核心问题是平台是否被单一模型厂商绑定。制造业的真实场景常常是“既要又要”涉及工艺参数、内部成本等敏感信息的问题希望走私有化部署的7B/13B小模型而面向员工的通用问答、文本摘要可以用能力更强的云端大模型。如果平台的模型接入层封闭只允许调用自家模型那你就失去了这个弹性。好在主流的开源平台和不少商业平台都已经支持自定义接入OpenAI兼容接口、多家国产模型以及私有化模型服务这个要仔细确认。推理成本这里要给制造业朋友提个醒别只看大模型的token单价。一个Agent任务的成本 多次模型调用的叠加。比如用户问“帮我分析A线效率下降原因”智能体内部可能要执行意图识别一次、工具调用规划一次、查数据库一次、生成分析报告一次、润色输出一次加起来可能调用模型5到10次。即使单次token价格不高一个完整Agent任务的总成本也要按量放大。所以评估成本时应该拿一条真实业务链路去测“单任务成本”而不是拿一次简单对话去算账。4.3 解读评分结果得分最高不代表最适合评分表的最大作用是避免“一票决定”但它本身也有陷阱。最典型的情况是某个云端SaaS平台总分很高但它的私有化版本功能明显落后甚至很多新特性只有公有云用户才能用。如果你所在的制造企业恰好只能私有化部署那这个高分就失真了。所以在解读评分结果时要先把“部署形态”作为一票否决项把所有不满足数据安全底线或者部署要求的平台排除掉再去看剩余平台之间的分数差距。另外每一项评分背后都要有证据支撑最好是在POC实测中获得的体验而不是完全依赖供应商的宣讲。一般来说最终候选平台留在23家就好不要贪多。5. 进场实测一套快速POC方法避免选型靠“感觉”5.1 POC场景怎么选业务价值高、数据易得、结果可判定再详细的评分表也替代不了亲手试一遍。有些团队把POC做成了“供应商演示会”下载平台后随便传两个文档聊了几句就下结论这样基本测不出真实水平。更合理的做法是选一个能充分暴露平台能力差距的典型业务场景。我给制造业朋友推荐三个很适合做POC的场景第一个是设备维修知识问答让智能体基于一批维修手册和故障记录回答问题验证知识库解析和RAG效果第二个是异常工单自动生成从产线报障信息中提取设备号、故障现象、紧急程度通过API调用工单系统创建维修单验证Agent的工具调用和工作流编排能力第三个是质量报告摘要生成输入一份PDF质检报告按照模板生成摘要和初步判定结论验证文档解析和多步推理。三个场景分别对应了我之前说的三类智能体覆盖了制造企业最普遍的落地诉求。选一个最贴近公司痛点的去做就够了不用一次做完。POC之前一定要自己准备数据拿二三十份真实的脱敏文档或一个测试版的业务系统API这样才能看出平台在“脏数据”场景下的真实表现。5.2 两小时快速验证清单这里给一份可以直接照抄的轻量级验证方法不需要等到POC完整结束在每个候选平台上花两个多小时就能快速分辨高低。第一步上传5到10份典型的文档比如SOP、设备手册、检验规范观察文档解析的质量表格有没有乱章节标题有没有识别出来中文排版有没有问题。第二步建一个知识库连续提5个关联性问题和一个跨文档问题看回答是否准确、有没有引用来源、能不能拒绝回答超出知识范围的问题。第三步配置一个最简单的带记忆的多轮Agent连续追问几轮验证上下文理解能力。第四步接一个真实的API做一个“查数生成”的小流程比如根据物料编码查询库存并生成缺料提醒。第五步测试权限隔离设置两个不同权限的用户看低权限用户能否绕过限制访问高权限知识库。这五步走下来平台的底线能力基本就清楚了。如果哪一步卡壳严重后面正式实施时只会更麻烦。5.3 POC环境与实际量产环境的三个落差POC做得顺利也不代表量产一定会顺利。我总结过三个最容易出现落差的环节在选型阶段就要有心理预期。第一个是数据量落差。POC时只有几十份文档召回率自然高量产时面对几千份甚至上万份文档知识库需要分库、分片检索策略要做优化回答质量可能会下降。解决办法是提前问清楚平台有没有测试过百万级文档以上的规模。第二个是系统延迟与API限流。POC时你调的API可能只有几个用户在用量产时MES接口扛不扛得住智能体的高频调用完全是另一回事。要在技术方案里提前设计缓存层和异步任务机制。第三个是网络边界。很多制造企业的MES系统在内网AI平台在DMZ区或者专有云中间还隔着防火墙和工业网闸。如果网络策略没有提前打通POC时演示得很流畅的API调用到了生产环境根本连不上。这个一定要尽早拉上网络和安全团队一起评审。6. 常见问题与选型避坑实录6.1 数据的“出境”和“能力出境”合同里要写清楚数据出境问题不少团队会关注到但“能力出境”很容易被忽略。有些平台虽然做了私有化部署但控制面也就是平台的管理后台、License校验、模型调用鉴权依赖供应商的云端服务。如果你们工厂的内网环境完全隔离甚至没有访问外网的权限那这类平台根本跑不起来或者断网之后平台直接瘫痪。所以在合同阶段要逐条确认业务数据是否只存本地模型调用是否存在数据回传平台License校验是否依赖外网控制面在断网情况下是否可用这些条款能落到纸面上的一定要落到纸面上不要听销售口头承诺。6.2 智能体平台和RPA、低代码平台是什么关系做技术选型的时候经常有企业把AI智能体平台和上一轮的RPA、低代码平台搞混。这里帮大家做一个简单的区分RPA适合规则明确、流程固定、重复性强的任务比如定时抓取网页数据、批量登录系统做信息录入低代码平台则更多地用来搭管理类应用比如审批表单、数据看板核心是“以表单驱动流程”而AI智能体平台的核心是用大模型来完成“理解、决策、生成”这类需要认知能力的任务。制造业里比较务实的做法不是用智能体平台去替代RPA和ESB而是在它们之上做一层“大脑”。智能体负责理解用户意图、拆解任务、选择工具然后把具体的操作交给RPA去执行或者通过ESB调用业务系统接口。如果一个智能体平台能提供灵活的API或者自定义插件能力能和你们现有的RPA系统顺利集成那会是加分项。6.3 供应商的交付和服务能力比想象中更重要最后说一个很多人吃过亏的点平台本身再强如果没有懂制造业场景的实施团队落地照样很难。不少制造企业买了平台之后供应商只做基础培训剩下的全靠自己的IT团队摸索最后项目越做越慢业务部门失去耐心整个项目被叫停。在选型时一定要问清供应商三个问题你们在制造业做过多少家客户的智能体落地实施团队是在本地还是远程支持团队里有没有懂生产业务的人还是只会讲技术概念同时验收标准也要提前定。比如知识库问答准确率怎么测、Agent任务的完成率怎么评估、系统故障的响应SLA怎么约定这些都应该在项目启动会之前写清楚。我在实际操盘项目时最大的体会是选平台这件事本身并不难难的是在选型之前把需求、团队、预算、安全边界全部想清楚。别指望有一个平台能一次性解决所有问题也别追求一步到位的大而全方案。先选定一个高频、痛点明确、数据条件成熟的场景把一个智能体真正跑通让业务部门看到效果再逐步横向复制到更多场景这才是制造业里比较稳的落地路径。另外平台选完之后不是终点知识库的持续更新、Agent的持续调优、使用反馈的回收这些机制如果不建立起来再好的平台也会越用越笨。选型只是第一步真正的功夫在后面的持续运营上。