企业官网建设流程全解析

大型制造企业部署AI智能体，平台应该怎么选？

这几年“AI智能体”在制造业圈子里热度一直居高不下，但真正落地过的人都知道，这玩意的难点不在算法，也不在模型，而在“平台选型”这一步。我在制造企业信息化部门摸爬滚打了十几年，见过太多项目从立项时信心满满，到选型时反复纠结，再到上线后各种折腾的完整过程。很多企业一上来就问“哪个平台最强”，但我通常在回答这个问题之前，会先反问一句：你们到底想让智能体在工厂里干什么？

这个反问不是敷衍，是真的绕不开。大型制造企业的应用场景和互联网公司做AI客服完全是两回事：车间里环境复杂、网络条件参差不齐、数据敏感程度高、业务流程链路长、对稳定性和响应速度的要求又极其苛刻。你不可能拿一套面向互联网场景的开源框架直接搬进工厂，也不可能把核心工艺数据丢给公网上的SaaS平台。平台选型一旦出错，后面所有上层应用全部白做，AI智能体项目大概率会烂尾。

这篇文章我就完整梳理一下我这些年做的选型评估和经验总结，分平台定位、评估维度、模型接入、场景适配、实施推进这几个层面往下聊，尽量把选型这件事讲透。不管你是企业IT负责人、智能制造项目牵头人，还是刚接触AI智能体的一线工程师，这里面提到的思路和评估框架，基本上可以直接拿去做选型参考。

1. 先搞清楚一件事：制造企业的AI智能体到底要干哪些活

1.1 智能体的核心能力框架

在开始选平台之前，先把AI智能体的能力模型摆一摆。不管哪个平台，智能体的底层逻辑都是类似的：感知输入、规划任务、调用工具、记忆上下文、生成输出。这五个环节说起来简单，但在制造业环境里，每一个环节都有它特殊的坑。

举个例子，“感知输入”这一环，在办公场景可能就是接收一段文字或一张图片，但在工厂里可能是设备PLC传来的Modbus TCP报文、是MES系统推送过来的工单数据、是质检工位摄像头拍摄的实时光学图像、是老师傅语音描述的设备异响。一个合格的制造型智能体平台，必须对这些异构输入有成熟的接入方案，而不是只能靠API传一段JSON进去。

“记忆”这一环同样特殊。互联网场景下的智能体记忆，聊聊天记住用户的偏好就够了。制造业的智能体需要记住什么？某个型号的工艺参数范围、设备上次保养时间、该工位标准作业程序里的关键控制点、质检历史缺陷的图像特征。这些信息分散在PLM、MES、EAM、QMS等不同系统里，还有大量沉淀在老师傅脑子里的经验知识。平台是否支持把企业知识库做成结构化的、可检索的、权限隔离的形态，直接决定智能体能不能真的“懂业务”。

“规划”和“工具调用”更不用说。制造业的业务流程往往是多重条件分支、多个系统联动、多角色审批。比如设备故障报修，智能体要能判断故障等级、查备件库存、预约维修工单、通知相关责任人、生成维修工单。这个过程中它至少要调用EAM系统、库存系统、消息系统三套工具的接口。平台对工具调用的编排能力、容错能力、审计能力，在这个场景下会被放到显微镜下审视。

1.2 制造业典型智能体场景盘点

把能力框架落到具体场景上，制造业企业最常见的智能体应用大概可以分成这么几类，每类的技术诉求差异很大：

• 设备运维助手：设备故障诊断、保养计划提醒、维修知识检索、备件更换建议。这类智能体依赖IoT数据接入能力和知识库检索质量。
• 质量分析助手：质检异常归因、缺陷图像分析、SOP智能推荐。对视觉类模型集成能力有要求，同时要能拉通QMS历史数据。
• 工艺参数优化助手：根据历史生产数据和当前工况推荐最优工艺参数。这类智能体需要强大的数据分析能力和与SCADA系统的深度集成。
• 供应链风险预警助手：物料缺料预警、供应商交期预测、异常波动归因。主要挑战在数据整合和外部数据源的合规接入。
• 员工知识问答助手：制度查询、操作导航、跨系统数据查询。这个最容易起步，但也最容易做得没价值，关键在知识库建设的深度。

我建议企业做选型之前，一定要先把自己的场景清单列出来，按照“当前数据条件成熟度”“技术可行性”“业务价值”三个维度打分排序。很多时候选型选半天，最后发现不是平台不行，是自己根本没想清楚第一仗打哪个场景。先锁定一到两个高价值、低门槛的场景做试点，再根据试点结果反推平台能力缺口，这个节奏比一次性规划十几个智能体场景靠谱得多。

2. 平台选型的六大核心评估维度

2.1 开发方式：低代码优先还是代码优先

现在市面上的AI智能体平台大概分两个流派：一类是低代码/无代码平台，另一类是代码优先的开发框架。制造企业该怎么选？我的建议是看你的开发团队构成和场景复杂度。

如果你的核心问题是IT团队人手紧缺、业务部门又急需快速看到效果，低代码平台的优势非常明显。业务人员经过简单培训就能上手搭建基础问答型智能体，IT部门只需要负责平台运维和数据接入。这种模式见效快，适合场景探索阶段。

但如果你的智能体要深入集成多个核心业务系统，要做复杂的条件分支和长链路任务编排，低代码平台那套拖拽式的节点设计器往往会成为瓶颈。复杂逻辑怎么调试、版本怎么管理、异常分支怎么处理，都会让你用起来很难受。这个阶段就需要代码优先的框架，让开发工程师可以自由编写业务逻辑、自定义插件、做深度系统集成。

我个人比较推荐“低代码起步、代码能力兜底”的混合路线：选平台时优先看那些既提供可视化编排，又提供Python/API级二次开发接口的方案。用低代码方式搭建80%的标准场景，剩下20%的复杂场景用代码方式补齐。这个路线对制造企业最友好，既能快速见效，又不至于被平台的能力天花板卡死。

2.2 知识库与检索增强生成（RAG）架构

制造业企业做智能体，大概率绕不开企业知识库的构建。平台对知识库的支持能力，要看四个层面的设计：

• 存储层：知识库是不是基于向量数据库做强语义检索，还是只能做关键词匹配？很多制造企业问“AI智能体的企业知识库是存放在向量数据库中的吗”，答案是：成熟的平台都会采用向量数据库作为核心存储，因为只有把文本、图片等非结构化内容向量化，才能支撑语义级别的知识检索。但要注意，向量数据库只是RAG架构的一部分，还需要配合传统的关系型数据库做结构化数据的精确查询，以及倒排索引做关键词匹配。纯向量库不是万能的，混合检索架构才是工业场景下的正解。
• 处理链：知识内容的切分策略、清洗流程、索引优化，这些运维层面的能力平台是否友好。工业文档的问题在于格式混乱、术语密集、表格多、图片多。PDF转换质量差、章节目录识别错误、表格被切碎，这些都是常见问题，平台如果连基本的文档解析支持都做不好，知识库的质量一定堪忧。
• 更新机制：工业文档和标准规范经常更新换版，旧版本的知识如果不及时清理，智能体就会引用过期内容，这在制造业是要出安全事故的。平台对知识库版本管理、更新审核、生效时间控制的机制，需要重点考察。
• 权限隔离：不同车间、不同部门的知识和权限要隔离开，比如研发部门的配方数据绝对不能出现在车间操作人员的智能体问答结果里。平台是否支持细粒度的知识库级、文档级甚至块级权限控制，是制造企业选型时的硬性指标。

RAG这块我多说一句：不要迷信“大模型自己会推理”这件事。在工业场景下，知识检索的准确性直接决定智能体的价值。一个参数检索错了，后面推理再聪明也是错的，而且错的后果可能很严重。所以平台的知识库建设能力，怎么强调都不过分。

2.3 工具调用与系统集成广度

有个术语叫“模型上下文协议”（Model Context Protocol，简称MCP），近两年在智能体领域热度非常高，你可以把它理解成一个标准化的“万用插座”：只要平台和工具都支持这个协议，就能快速对接，不需要每个系统都写一遍定制接口。选型时一定要确认平台对MCP的支持程度，因为这意味着你的智能体未来能多快速接入新系统、新工具。

除了MCP，还要看平台本身内置的集成连接器有多少。SAP、用友、金蝶、西门子、罗克韦尔、施耐德，这些制造业常见系统是否有现成的连接器？工控协议MQTT、Modbus、OPC UA能不能直接接入？还是都要从零开发？这个清单越完整，你的实施周期就越短。

工具调用还有一个容易被忽略的点：接口调用的稳定性。制造企业的业务系统很多是老系统，接口响应慢、偶尔不稳定是常态。平台是否能做超时重试、降级处理和兜底回复，对用户体验影响很大。很多智能体上线后被人吐槽“智商不在线”，其实不是模型能力不行，是工具链路不稳定导致错误信息传给了模型。

2.4 部署形态与数据安全边界

这个维度对制造企业来说几乎是一票否决项。我的经验是，95%以上规模以上的制造企业，最终都会选择私有化部署，或者至少混合部署。原因很简单：工艺参数、设备数据、质量数据、供应链数据，这些是制造企业的核心商业机密，不太可能放到公网上的第三方平台。而且很多企业还有等保合规、数据出境合规等硬性要求。

所以考察平台时，关于部署架构需要问清楚这么几个问题：

• 平台是否支持全栈私有化部署？还是说所谓“私有化”只是把应用层部署在本地，底层模型调用还是要走云端API？
• 推理算力这一层是怎么设计的？是用企业现有的GPU集群，还是需要额外采购？
• 数据链路是否可审计？谁在什么时候访问了哪些数据，有没有操作日志？
• 如果后续需要扩充算力或者接入新的数据源，平台是否支持平滑扩展？

有些云端SaaS平台确实功能丰富、生态完善，但碰到制造企业的数据安全红线，往往是第一步就被筛掉了。如果你的企业允许纯SaaS模式，那选择面会宽很多，但要做好数据合规评估同外部平台签订好数据保护协议。

2.5 模型接入灵活性与多模型管理

多数企业初期会直接使用平台内置的大模型，比如某些头部平台内置了多个大模型API（深度求索、通义千问、混元、文心一言等）。但大型制造企业往往会不一样，因为涉及私有化部署，很多企业会选择部署开源模型（比如Qwen系列、DeepSeek系列），甚至微调出自己企业的专属模型。

平台对模型接入的灵活性，需要从三个维度评估：

• 模型切换成本：如果今天用的A模型效果不好，换到B模型，平台的切换成本有多高？是一个配置文件就能搞定，还是要改大量应用代码？
• 多模型路由：复杂任务用大模型保证质量，简单任务用小模型降低成本，平台是否支持这种按需路由的策略？
• 微调模型上线：自己训练的微调模型，能否快速导入平台替代基础模型？

关于“大模型、小模型、智能体应该从哪里开始学”这个话题，网络上讨论很多。我个人的建议是：不用太纠结模型本身，先从场景出发用成熟平台把智能体跑起来，慢慢体会不同模型能力的差异，再迭代模型选型。对制造企业来说，把业务跑通比追模型参数更重要。

2.6 平台开放性与生态扩展能力

最后一个维度容易被忽视，但长期来看非常关键。有些平台做得封闭，数据进去容易出来难，应用和应用之间、场景和场景之间是割裂的。等你用了两年想扩展新场景，发现平台不支持，数据还迁移不出去，那就非常被动。

好的平台应该有完整的API和Webhook机制，支持自定义插件开发和第三方应用嵌入，甚至允许你导出智能体的配置和知识库数据。这也是为什么现在开源智能体开发平台越来越受制造业欢迎的原因——生态开放，不会被绑定。Dify、扣子（Coze）、字节的AI Agent平台，各有擅长，但共性都是支持一定程度的开放性。选型时把“拔插自由度”作为一项重要指标，未来会有你感谢自己做这个决定的时候。

3. 大模型接入与数据处理的安全红线

3.1 私有化部署的算力规划

如果确定要走私有化部署路线，第一个问题就是算力。很多制造企业对GPU计算这块没有概念，这里给一个大致的参考估算方法。

以现在主流的70B参数级别开源模型为例，如果采用FP16精度推理，需要显存大约是参数量乘以2个字节，也就是约140GB显存。单张A100/昇腾910B级别的卡是80GB，意味着单卡跑70B模型会超出显存，通常需要两张卡做张量并行。如果是32B模型，每张卡大约是64GB，两张80GB的卡跑起来就比较从容。如果是7B到14B的小模型，单张消费级显卡甚至都能扛下来，当然工业环境不建议用消费级卡，稳定性是问题。

这里有个经验公式可以分享：显存需求（GB）约等于模型参数量（B）乘以2字节，再考虑KV Cache和推理开销上浮50%到100%。70B模型就是大约需要140GB乘以1.5到2之间，也就是210GB到280GB的集群规模，更加稳妥。这个估算方法虽然不是绝对精确，但用来做前期预算规划是够用的。

模型规模怎么选？我建议从场景倒推：如果是简单的知识问答和文档检索，7B到14B的小模型配上RAG，效果已经很好了；如果要处理复杂的逻辑推理和长流程任务编排，再考虑32B到70B这个档位；超大模型除非是集团级中央知识中心这种超级场景，否则对制造企业来说成本和收益比不太划算。

3.2 数据不出厂与安全审计机制

制造业企业对数据安全的顾虑，很多时候是刻在骨子里的。选型时要重点确认平台在数据链路每个环节的安全设计：

• 接入环节：IoT数据、系统API数据接入时是否走内网专用通道？是否支持国密算法的加密传输？
• 存储环节：知识库数据是明文存储还是加密存储？存储介质是谁来管？
• 处理环节：数据在模型推理过程中是否会被缓存？推理日志中是否可能泄露敏感信息？
• 输出环节：智能体的回复内容是否有脱敏机制？比如涉及员工个人信息、客户信息时是否自动打码？

另外一个细节是审计。制造企业应对内外部审计是常态。平台的用户操作日志、数据访问记录、模型调用记录是否完整可追溯，直接关系到大企业IT部门能不能过内部合规这一关。有些平台连最基本的操作审计都没有，这种项目上线后埋下的雷，爆的时候会非常痛。

3.3 终端与平台的连接安全

大型制造企业还有一个很实际的场景：一线员工怎么使用智能体？是用车间里的工位一体机、手持PDA，还是手机小程序？这个看似简单的终端选择问题，其实和安全架构强相关。

如果走手机端，企业一般会选择企业微信或专属APP集成，这就要看平台是否支持SDK集成到已有的移动应用里。如果走工位一体机，可能更多是Web端应用，需要确认平台的Web体验是否足够好。

我见过不少人搜索“无法通过微信进入打开平台的员工”，其实背后就是这个终端接入方案没有提前想清楚。选型时不要只盯平台功能，把“使用终端环境”这个约束条件一并纳入评估，否则后面用户推广阶段，你会被终端适配的琐碎问题折磨到怀疑人生。

4. 主流平台类型对比与选型建议

4.1 几种典型平台路线

当前的AI智能体平台市场，大致可以分成四个路线，每条路线的优劣势非常鲜明：

• 开源低代码平台，如Dify：当前制造企业私有化部署选型中讨论度最高的一类。Dify的优势是开源开放、可以完全私有化部署、支持自选模型、社区生态成熟，功能上覆盖了工作流编排、RAG、Agent等核心能力。缺点是复杂的生产级部署运维还是需要一定技术能力，代码质量和版本迭代的稳定性偶尔也让人头疼。
• 云端Agent平台，如扣子（Coze）：上手极快，内置大量插件和模型选择，适合快速构建原型和验证场景。但企业级私有化支持相对薄弱，数据出厂的顾虑天然存在。部分企业内部试点场景可以用，核心生产场景要慎重。
• 自研Agent框架：适合有较强AI研发团队的集团企业。优势是绝对的灵活性和定制深度，但研发周期长、维护成本高、对团队能力要求极其苛刻。一般制造企业如果没有30人以上的AI研发团队，不建议走这条路。
• 大厂垂直解决方案：如华为、浪潮等提供的软硬一体AI平台。优势是预集成度高、开箱即用、可装配性强，劣势是定制灵活性受限、价格偏高、容易形成绑定。

4.2 按场景匹配平台的策略

不同的应用场景，对平台的诉求是完全不一样的，这里给一个按场景匹配的参考方向：

这个表格不是一个严格的选型结论，更多是提供一个思考方向。具体怎么选，最终还是回到场景清单、数据边界、团队能力这三个约束条件来综合判断。

4.3 避免选型常见误判

这几年的选型评审里，我观察到几个高频误判，分享出来供参考：

第一个误判是把“功能多”等同于“适合自己”。有些平台Demo展示做得非常漂亮，流程编排一气呵成，但实际在工业环境里跑起来，性能和稳定性根本扛不住。选型时一定要坚持拿自己的真实业务数据做概念验证，不要被供应商的演示环境迷惑。

第二个误判是低估了知识库建设的成本。很多团队认为平台选好了，把文档扔进去就能用。实际情况是，一份制造业工艺文档可能要经过格式转换、章节识别、数据清洗、人工标注、验证评估等多道工序才能达到可用状态。平台只是工具，知识库建设才是大头工作。

第三个误判是忽视了运营与维护。智能体不是部署完就一劳永逸的软件。模型效果会衰减、知识库需要持续更新、业务场景在变化，这些都要求有专门的运营人员持续跟踪维护。选平台时如果没把运维团队建设和运营经费预算留出来，项目上线半年后大概率会沦为摆设。

5. 落地推进的路径与槽点实录

5.1 建议的实施路线图

结合我参与过的项目经验，制造企业落地AI智能体平台，我建议按“三步走”来推进：

第一步，场景探索与平台验证（约6至8周）。锁定1到2个高价值低门槛场景，用开源低代码平台在一周内搭出原型，再用三到四周接入真实数据做概念验证，重点验证检索效果、响应速度、工具调用稳定性三个技术指标。这个阶段的目标是让业务部门看到智能体到底能带来什么价值，帮项目争取更大范围的支持。

第二步，平台正式引入与核心场景落地（约3至6个月）。根据验证结果正式确定平台选型，完成生产环境部署、安全合规评审、与核心系统的正式集成，同步建设企业知识库平台和智能体运营团队。把第一步验证过的场景做成生产级应用，形成完整运营闭环。

第三步，规模化扩展与生态建设（6个月以上）。在试点场景稳定运行的基础上，把智能体平台推广到更多部门和业务场景，建立平台级别的治理机制，包括智能体发布审核、效果评估、访问权限管理和版本迭代规范。再好用的平台没有治理机制，多个智能体同时上线后一定会乱。

5.2 我踩过的坑与排雷技巧

最后分享几个我在实际项目里踩过的坑，都是真金白银换来的经验。

第一个坑是格式敏感的模型在工业文档识别上的翻车。最开始我们直接拿大模型去识别扫描版的工艺卡片，结果相当惨烈，字段错位、数字识别错误。后来我们调整为扫描件先走专门的OCR管线，结构化数据再进RAG检索，准确率才有质的提升。这里有个血泪教训：大模型不是万能的文档解析工具，该上专用识别引擎的地方，一个都不能省。

第二个坑是向量数据库与传统关系型数据库的配合问题。刚开始我们想用一个向量数据库解决所有数据存储和检索的问题，结果发现搞不定。原因是工业场景下很多数据是高度结构化的，比如设备台账、保养记录、质量标准参数表，这些数据用关系型数据库存储和查询的准确率、效率远高于向量检索。后面我们形成了“关系型数据库做事实数据查询，向量数据库做语义内容检索，两者融合进RAG链路”的混合架构方案，效果才稳定。架构上多一层，逻辑更清晰了，问题定位也容易了。

第三个坑是知识库更新机制的设计。我们最初的知识库更新很随意，结果出现过智能体给车间员工推荐了已经作废的旧版本操作规范，幸好被经验丰富的班组长发现问题了。后来我们给知识库增加了严格的版本审核、上线、过期下发的完整生命周期管理机制，确保智能体永远只能在有效版本范围内检索。这件事做安全了再谈智能体价值。

第四个坑是终端适配的验证不充分。有一段时间我们内部用企业微信集成了智能体，但一线车间工人反馈说扫码进不去。排查后发现是网络权限问题——车间工位所在网段不允许直接访问企业微信的某个域名。后来我们把智能体入口改成集成在统一工位门户里，问题解决了。这类终端环境细节，概念验证阶段就要充分考虑，不然后续推广时会被一线用户直接“用脚投票”。

6. 长期运营视角与扩展设想

6.1 智能体平台不是一次交付型项目

最后想重点强调一个观念：AI智能体平台不是一次交付型的项目，而是需要长期运营的平台型系统。

我见过太多制造企业把智能体当成一个“项目”来做，认为平台部署上线、场景开发完毕就是大功告成。过三个月再看，知识库没更新、模型版本没升级、问答质量越来越差，业务部门开始抱怨，项目慢慢就冷藏了。真正的智能体平台运营，从上线那一刻才算正式开始。

建议大型制造企业从第一天起就明确智能体平台的年度运营预算，包括模型推理算力成本、知识库维护人力、场景迭代开发投入、效果评估工具等。同时建立智能体运营日报或周报机制，记录各个智能体的调用量、用户反馈、知识命中率、业务成效数据。用数据说话，才能让业务部门和决策层持续看到平台价值，也才能让智能体平台从一个尝试性的项目变成一个长期的基础设施。

6.2 后续扩展的几条可行路径

随着智能体平台逐渐成熟，后续扩展的方向其实挺多。一个方向是把智能体能力嵌入到制造执行的核心流程中，比如和设备异常联动做自动报修，和生产排产联动做异常干扰预警，这需要平台和核心制造系统的集成进一步加深。

另一个方向是跨工厂复制。集团型企业往往有多个生产基地，一个基地验证成功的智能体场景和知识资产，可以通过平台的管理功能快速复制到其他基地，形成规模化效应。这就要求选型时就考虑平台对多租户、多工厂组织架构的支持。

还有一个方向是让智能体从被动响应走向主动出击。比如让智能体定期巡视设备数据，发现异常趋势就主动通知相应负责人。这个方向对平台的事件触发机制和业务流程集成能力要求更高，但是价值也更明显。制造业的利润增长点，往往就藏在这些主动发现问题和消除异常的缝隙里。

我对这个方向的具体感触是：选型不必追求一步到位，但路径方向要想清楚。先选一个站得住脚的平台，把基础打牢，再沿着这些方向平滑扩展，比一开始就追求大而全的平台方案要稳妥得多。毕竟在制造业，稳定可靠比什么都重要，AI智能体这件事也是一样。