制造业AI智能体搭建落地案例｜数商云行业项目复盘

一、从系统上线到业务智能：制造业AI智能体搭建的起点

制造业的数字化建设已经走过一个相对完整的周期：先把流程搬到线上，再把数据汇聚到看板，接着打通系统之间的接口。当这些工作陆续完成之后，一个更棘手的问题浮现出来——数据已经被“存起来”，却还没有被“用起来”。正是在这样的阶段，数商云与某制造行业头部集团启动了制造业AI智能体搭建项目。它不是一次单点工具采购，而是一套以业务闭环为目标的数字化解决方案。

这家客户具有典型的集团型制造企业特征：业务覆盖多品类生产、集中采购与多渠道分销，生产端与供应链端高度耦合，内部同时运行着 ERP、MES、WMS、SRM、CRM 等系统。从系统覆盖面看并不“缺”，缺的是把分散在系统、文档与人脑中的信息，转化为一线人员可以即时调用的能力。行业转型走到深水区，比拼的已经不是谁的系统多，而是谁能把系统里的数据与人的经验合成为可执行的判断。

（一）客户画像：复杂业务背后的协同压力

从组织形态看，该集团由多个事业部和生产基地构成，采购、计划、生产、质量、物流、销售分属不同条线，各自有相对独立的考核目标与作业习惯。一个看似简单的客户交期问询，往往需要销售向计划确认排产、计划向采购确认到料、采购向供应商确认发货，再由物流确认在途状态。信息并非不存在，而是散落在不同系统与不同角色手中。

从业务节奏看，制造端的波动性很强：订单结构变化、物料供应不稳、工艺参数调整、质量异常处理，都会在短时间内产生大量临时性沟通。这些沟通中沉淀下来的判断与处置方式，恰恰是极有价值却又最难被记录的知识。项目立项时的共识是：智能体要接住的不是“标准问答”，而是这些高频率、跨角色、带上下文协同的真实业务动作。

（二）传统数字化工具的边界在哪里

报表与看板解决的是“看得见”的问题，规则引擎与流程引擎解决的是“走得通”的问题。但当业务人员提出的是“这批物料为什么会延迟”“这份工艺文件与上一版差异在哪”“这个供应商的准入资料是否齐备”这类带语境、需要跨源取证的问题时，传统工具的响应方式通常是让人自己去翻、去问、去比对。

大模型与智能体技术带来的变化，在于它可以用自然语言承接模糊表达，再通过工具调用去访问确定的数据源，最后给出带出处的结构化结果。但这也意味着，企业需要的不是一个大模型接口，而是一套能把模型能力约束在数据边界、权限边界与业务规则之内的工程体系。这正是数商云在设计这套数字化解决方案时的核心出发点。

二、痛点拆解：智能体要解决的不是“问答”，而是业务闭环

（一）知识沉淀碎片化，经验难以复用

在该集团的日常运转中，知识以多种形态存在：工艺文件与作业指导书、设备手册与维修记录、检验标准与质量报告、变更通知与会议纪要、邮件与即时通讯中的处置结论。它们分别存放在文档系统、共享盘、业务系统附件乃至个人电脑中，检索依赖关键词与目录结构，命中效率高度依赖检索者本人的经验。

更现实的挑战来自人员流动。资深工程师与老师傅掌握着大量“没有写下来”的判断依据，例如某种异常声响通常对应哪类故障、某类物料在特定季节需要提前备货。这些隐性知识一旦随着岗位变动而流失，企业就很难在短时间内补回来。把隐性经验显性化、把显性文档结构化，是智能体能够被信任的前提。

（二）跨系统流程割裂，协同成本高

系统林立带来的是操作路径的拉长。业务人员为了完成一次完整的判断，往往需要在多个系统之间反复切换，还要自行完成口径对齐：同一个供应商在不同系统里的名称写法可能不同，同一个物料在不同报表里的统计维度也可能不一致。人成了系统之间的“手工中间件”。

这类协同成本的隐蔽性很强，它不会体现在任何一张报表上，却真实消耗着组织效率。智能体的价值在于把这些跨系统的取数与比对动作封装起来，让使用者用一次提问完成原本需要多次跳转的操作，并在结果中保留数据来源，便于复核。

（三）一线人员的数字化门槛依然存在

制造业的一线场景与办公场景差异明显：使用者可能站在设备旁、可能在仓库通道里、可能戴着防护装备，他们的注意力有限，操作时间被压缩。复杂的界面、繁多的字段、严格的操作顺序，都会成为实际使用的障碍。

自然语言交互恰好契合这类场景。使用者只需要描述现象与需求，由智能体去决定调用哪些系统、走哪条流程、需要补充哪些信息。这种“以人为中心”的交互方式转变，是制造业AI智能体搭建在体验层面最直接的价值。

三、数商云数字化解决方案的整体设计

（一）分层架构：把大模型能力装进企业治理框架

项目没有采用“模型直接连数据”的简单做法，而是按分层思路建设，确保能力可扩展、边界可控制、效果可评估：

• 模型层：对接可用的商用大模型服务，同时保留对私有化部署模型的适配能力，避免能力绑定在单一模型上，为后续模型迭代留出空间。
• 智能体编排层：承担意图识别、任务拆解、上下文管理、工具调用与多智能体协作，是整套体系的“调度中枢”。
• 知识与数据层：包括企业知识库、向量检索、元数据与权限标签，以及面向业务系统的受控数据接口，解决“答得准”的问题。
• 业务集成层：把 ERP、MES、WMS、SRM 等系统的查询与操作能力封装为标准工具，让智能体能够真正触达业务动作。
• 治理与安全层：涵盖身份认证、权限校验、内容安全、审计日志与效果评测，构成企业级应用的合规底座。

分层的意义在于职责清晰：模型能力更新时，业务集成层不需要重写；业务流程调整时，知识层不需要推倒重来。这种解耦设计让智能体从“一次性项目”变成“可持续演进的能力平台”。

（二）场景选择：以高频、高价值、可闭环作为筛选标尺

智能体可落地的场景很多，但并非都适合优先启动。项目组在场景筛选时坚持三个判断：业务发生频率是否足够高、问题是否真实影响交付或成本、动作是否能在现有系统内形成闭环。凡是只能“聊一聊”却无法落到业务动作上的场景，一律后置。

需要强调的是，场景之间并非彼此孤立，它们共享同一套知识底座与工具接口。当一个场景跑通后，新增场景的成本会显著下降，这也是选择平台化路线而非单点开发的原因。

四、AI智能体搭建的关键落地路径

（一）知识工程：把经验变成可检索、可引用的资产

知识工程占据了项目中相当大的投入比重。团队对存量文档进行了系统梳理，包括格式解析、内容切分、语义向量化、元数据标注与权限映射，并为每一条知识建立版本与生效状态。对于存在多版本并存的工艺文件与标准，系统按生效时间与适用范围进行区分，避免“旧版本被当成新答案”。

检索环节采用向量检索与关键词检索结合的方式，并强制要求生成结果附带引用出处。可溯源不只是为了让人放心，更是让使用者在几秒内完成自我校验，从而愿意长期使用。对于无法在知识库中找到依据的问题，系统选择明确说明信息不足，而不是给出看似合理的推测。

（二）编排与工具调用：让智能体从“能回答”走向“能办事”

如果智能体只能复述文档，它的价值上限就很低。项目通过工具调用机制，把业务系统中的能力封装为受控的原子操作，例如按条件查询订单状态、读取库存与在途信息、发起审批、创建工单、生成业务草稿。智能体据此完成任务拆解与多步执行，必要时调用多个工具并汇总结果。

在协作层面，项目预留了多智能体协同的编排方式：由主智能体负责理解意图与分配任务，专业智能体分别承担采购、计划、质量等领域的职责。这种设计的现实价值在于，每个专业智能体只需要专注于自己的知识与工具边界，整体行为的可控性明显高于一个“什么都干”的通用助手。

（三）权限与安全：把企业数据边界画清楚

制造企业的数据敏感度很高，价格、成本、配方、供应商信息都属于严格管控范畴。项目采用身份继承机制，使用者在智能体中的可见范围与其在原系统中的权限保持一致，敏感字段在检索与生成两个环节都做脱敏处理。所有工具调用与结果返回均记录审计日志，可回溯到具体操作人与时间。

内容安全方面，系统对输入与输出都设置了过滤与校验规则，防止不当信息外泄或不当内容生成。对制造业而言，智能体能否通过安全与合规评审，往往比它是否“聪明”更能决定项目能否继续推进。

（四）人机协同：把审批权留在该留的地方

项目对智能体的动作做了分级处理：只读类查询直接放行；涉及数据写入或对外发送的动作，由智能体生成待确认内容，交由人工审核后执行；涉及金额、合同条款、工艺变更等高风险动作，必须走原有审批流程，智能体只承担信息准备与材料汇总。

这种设计既守住了风险底线，也保留了效率收益。智能体负责把“准备动作”做到位，人负责做判断与担责任，两者的分工边界清晰，落地阻力自然更小。

（五）评测与运营：上线只是开始

项目建立了持续的评测机制：围绕真实业务问题构建评测集，定期对回答质量、工具调用正确性、引用准确性进行人工抽检；对发现的问题案例进行归因，判断是知识缺失、检索偏差、编排逻辑问题还是模型能力边界，再分别回流到对应的优化环节。

运营机制同样重要。知识库需要有人持续更新，工具接口需要随系统升级同步维护，使用数据需要定期分析以发现新的高频场景。把智能体当作需要长期运营的“业务能力”，而非交付即结束的软件项目，是这套方案能够持续产生价值的关键。

五、项目复盘：制造业AI智能体落地的关键判断

（一）业务主导、IT 支撑的组织方式

项目由业务部门提出场景与验收标准，IT 与数据团队负责系统对接、权限设计与技术实现。这种分工避免了两种常见偏差：一是纯 IT 主导导致场景脱离实际使用习惯；二是纯业务主导导致技术方案忽视数据安全与系统稳定性。业务定义“什么算有用”，技术定义“怎样算可靠”，两者缺一不可。

（二）先做“窄而深”，再做“宽而通”

项目初期并未追求大而全的智能体门户，而是选择少数几个高频场景做深做透，把知识质量、引用准确性、工具调用成功率打磨到业务方认可的水平，再向外扩展。这样做的另一个好处是，早期用户会自然成为传播者，后续推广的阻力明显降低。

（三）数据与知识质量决定智能体上限

复盘中最一致的结论是：智能体的表现差异，多数时候不来自模型本身，而来自知识是否准确、数据是否及时、权限是否清晰。知识库中长期存在过期文件、同名不同物、口径不统一等问题，如果不先解决，智能体只会把这些混乱放大。项目因此把知识治理列为优先事项，而不是等到效果不理想时再回头补课。

（四）期望管理：智能体不是万能员工

智能体擅长的是信息检索、汇总、比对、初步归因与流程触发，不擅长的是需要现场判断、需要承担责任、需要跨部门博弈的决策。项目在内部沟通中明确了能力边界，把智能体定位为“高效率的业务助手”，反而让使用者的满意度更稳定。

（五）使用习惯的培养需要具体抓手

新工具的推广不能只靠培训会。项目把智能体嵌入到既有工作路径中，例如在工单页面提供知识辅助入口、在采购申请环节提供历史比价参考，让使用者在完成任务的过程中自然接触到智能体。降低第一次使用的成本，比反复强调工具有多强大更有效。

六、实施价值：效率、体验与组织能力的同步改善

从项目运行情况看，价值并非体现在单一指标上，而是多个层面的同步改善：

• 知识获取方式改变：从“找人问、翻文档”转向“随时问、看依据”，一线人员获取信息的路径显著缩短。
• 跨系统协同效率提升：原本需要在多个系统间反复切换的核对工作，被整合为一次提问与一次结果确认。
• 经验沉淀形成正循环：每一次有效问答都在丰富知识库，新人上手对个人经验的依赖明显降低。
• 管理可视性增强：高频问题、知识盲区、流程堵点通过使用数据被识别出来，为流程优化提供依据。
• 风险控制更有抓手：权限体系与审计日志让智能体的每一次动作都可追溯，合规评审更有依据。

需要说明的是，这些改善是业务、数据、技术与管理协同作用的结果，而不是智能体单方面的功劳。智能体更像是放大器：流程清晰、数据规范的企业，收益会更明显；基础薄弱的企业，则需要先把治理补齐。

七、可复用的方法论：数商云行业项目的沉淀

通过这个项目，数商云在制造业AI智能体搭建方面形成了较为清晰的推进顺序：先绘制场景地图，明确哪些业务域值得优先投入；再建设知识与数据底座，把可用的信息资产整理到可检索、可引用、可授权的水准；随后进入智能体编排与工具对接，让能力从“回答问题”延伸到“完成任务”；同步建立治理体系，覆盖权限、安全、审计与评测；最后是长期运营机制，让知识更新与场景扩展成为常态动作。

这套顺序的价值在于，它把技术问题转化为可管理的工程问题。企业在规划自身的数字化解决方案时，可以据此判断当前处于哪个环节、短板在哪里，而不必被层出不穷的新概念牵着走。

八、面向行业转型的下一步演进

从当前进展看，制造业智能体的演进方向相对清晰：一是从单智能体走向多智能体协同，让采购、计划、质量、设备等专业智能体在统一编排下协作处理复杂任务；二是从旁路助手走向与业务系统的双向融合，智能体既能读取数据，也能在授权范围内触发业务动作；三是从通用能力走向场景专用能力，通过行业知识与工具沉淀形成差异；四是从被动响应走向主动提醒，在交期风险、供应异常、质量波动出现苗头时提前介入。

这些演进都建立在一个前提之上：企业愿意把知识治理、数据治理与流程治理当作长期工作来对待。智能体的能力边界，最终由企业的组织能力与数据资产决定。对于正在规划制造业AI智能体搭建的企业而言，先想清楚“要解决哪个具体业务问题、依据哪些数据、谁来为结果负责”，往往比先选哪一种模型更关键。