制造业AI智能体怎么落地？数商云开发案例分享

一、案例背景：制造业头部集团的智能化拐点

（一）业务特征：链条长、协同密、经验重

本次案例客户是一家制造业头部集团，应客户要求全程匿名处理。集团业务覆盖多条产品线，生产基地与仓储节点分布在不同区域，上游连接数量众多的原材料与零部件供应商，下游面对渠道商与终端客户，内部按研发、工艺、计划、生产、质量、设备、仓储、物流、售后等职能划分组织。

这种结构的典型特征是流程长、系统多、数据散、经验重。一张订单从询价、评审、排产到交付，往往要在多个系统之间往返；一台关键设备的异常处置，既依赖设备台账与运行数据，也依赖老师傅的判断。集团在过往信息化建设中沉淀了大量数据，但这些资产长期停留在"记录"层面，没有充分转化为一线可用的"能力"。

（二）瓶颈：数据"存得下"，却"用不上"

推进智能化之前，集团已经察觉到几类共性问题。知识检索效率低：工艺文件、作业指导书、历史异常记录、供应商资料分散在不同系统中，一线人员需要层层询问才能找到答案，找到的还未必是最新版本。系统操作负担重：同一业务动作要在多套系统里重复录入与查询，跨系统协同靠人工搬运。经验传承困难：资深工程师的判断逻辑停留在个人头脑中，难以沉淀为组织可复用的规则。响应速度受限：面对客户咨询、异常工单、紧急插单，业务人员难以在短时间内完成信息汇总与初步判断。

（三）为什么选择AI智能体，而不是单纯的大模型问答

该集团早期尝试过通用大模型的问答能力，很快发现几个现实问题：通用模型不了解企业内部的术语、编码规则与业务流程，回答容易似是而非；而制造业的真实诉求大多不是"问一句、答一句"，而是"给个目标、办成一件事"。

智能体与大模型问答的本质区别正在于此：智能体具备目标理解、任务拆解、工具调用、状态记忆与结果校验的能力，可以在受约束的范围内自主推进任务，并把关键节点交回给人确认。对制造企业而言，可被约束、可被审计、可被集成的智能体，才具备进入生产与管理主流程的资格。

二、需求拆解：把"想用AI"翻译成"可交付的智能体"

（一）业务侧的真实诉求

数商云团队与客户各业务条线进行了多轮访谈与现场跟岗，把模糊的"想用AI"拆解成可交付的任务清单。

1. 生产与设备侧：在设备出现异常征兆时，自动关联设备档案、维修历史、工艺参数与作业规范，给出处置建议并生成工单草稿，压缩停机窗口内的决策时间。
2. 质量与工艺侧：把分散的质量标准、检验记录与异常案例整合成可对话的知识入口，让新员工也能获得接近资深工程师的判断参考，并支持异常批次的追溯分析。
3. 供应链与计划侧：在供应商资料、交期表现、物料替代关系之间建立可查询的关联，辅助采购与计划人员完成初步筛选与风险提示。
4. 知识与培训侧：把老师傅的经验、历史案例与标准文档转化为可交互的学习助手，缩短新人上手周期。

这些诉求的共同点在于：都不是开放域闲聊，而是有明确业务边界、有权威数据来源、有判断标准、有责任归属的专业任务。这正是智能体适合切入的场景特征。

（二）技术侧的硬约束

客户在技术评审阶段提出了几条不能让步的约束，它们直接决定了后续的架构选型。

1. 数据不出域。核心工艺参数、客户订单、供应商信息属于高敏感数据，模型推理与知识检索必须部署在企业可控的环境中。
2. 回答必须有据可依。任何面向一线的输出都要能回溯到具体文档、记录或系统字段，不能出现"看似合理、查无实据"的表述。
3. 权限必须隔离。不同工厂、部门、岗位能访问的数据范围不同，智能体的能力边界要与原有权限体系一致，不能成为绕过权限的后门。
4. 结果稳定可控。同一问题在相同上下文下应给出一致性较高的答案；涉及审批、派工、变更等动作时，必须保留人工确认环节。
5. 不推翻既有系统。集团已有大量系统承载着稳定业务，智能体的定位是协同层与交互层，而不是替换层。

（三）优先级排序：先摘低垂的果实，也要留出纵深

数商云建议客户按业务频次、标准化程度、错误代价、数据可得性几个维度对候选场景打分。高频、规则相对清晰、错误可被人工兜底、数据已经数字化的场景排在最前；涉及安全、财务、重大工艺变更的场景排在其后，先做辅助建议，再逐步放开执行权限。这个排序方法让项目在较短时间内产出可被一线感知的效果，也为更深度的场景积累信任与经验。

三、搭建过程：数商云的智能体落地路径

（一）场景诊断与能力地图

项目启动后，数商云团队最先做的不是写代码，而是绘制能力地图：把候选场景拆成需要什么知识、需要调用什么系统、需要哪些权限、由谁最终确认等几张清单。它的价值在于让业务团队与技术团队在同一张纸上讨论问题，避免把业务问题误判为模型问题。

（二）知识底座：让企业知识可检索、可引用、可更新

智能体的上限取决于它能触达的知识质量，数商云在这一阶段投入了大量精力。

1. 文档治理。对工艺文件、作业指导书、质量标准、维修手册等文档做结构化处理，统一版本标识，清理过期与冲突内容，建立文档与产品、工序、设备、物料等业务实体的关联。没有治理的知识库，只会把过去的混乱以更快的速度放大。
2. 结构化数据语义化。把系统里的字段、编码、单据类型翻译成模型能够理解的语义描述，让设备编号、工序代码、批次号这些概念在对话中被正确识别。
3. 混合检索策略。单纯依赖向量检索容易出现"语义相近但业务无关"的结果，因此采用关键词检索、向量检索与结构化过滤相结合的方式，并引入重排环节，优先保证业务相关性，而不是表面的语义相似。
4. 知识更新机制。建立文档变更触发知识同步的流程，把知识是否过期纳入运营巡检，避免智能体引用旧版本造成误导。

（三）智能体架构：大脑、手脚、记忆与护栏

1. 大脑——模型路由。不同任务对模型能力的要求不同，有的需要强推理，有的只需意图识别与信息抽取。通过路由把任务分派给合适的模型，在效果与成本之间取得平衡，同时保留替换模型的能力，避免被单一模型绑定。
2. 手脚——工具调用。把业务系统接口封装成智能体可调用的工具，例如查询设备档案、检索历史工单、读取库存、创建待办、发起审批。智能体能"干"到什么程度，本质上取决于它被授权调用的工具集合。
3. 记忆——上下文与业务记忆。会话级记忆维持多轮对话的连贯性；业务级记忆记住用户所属组织、常办事项与历史偏好，使交互从"每次都要交代背景"逐步变为"越用越顺手"。
4. 规划——任务拆解与工作流编排。多步骤任务先输出执行计划再逐步执行；确定性高的流程则直接固化为工作流，由智能体负责理解意图、填充参数、串联节点。自由度与确定性需要按场景配比，而不是一味追求自主。
5. 护栏——权限、校验与人在回路。所有工具调用都经过权限校验，敏感动作由人确认后执行；对输出设置格式校验与事实校验，不满足条件时返回澄清问题或转人工，而不是强行作答。

（四）与业务系统的集成方式

客户最担心的不是模型效果，而是又多一个孤岛系统。数商云的集成思路是以现有系统为主干，智能体以服务化方式接入：通过标准接口与消息机制对接业务系统，不复制业务数据、不绕开业务规则，只在需要时读取与写入，并保留完整调用日志。这既保护了既有投资，也让智能体的行为处于可追溯范围之内。

（五）评测、灰度与迭代

上线之前，项目组建立了评测机制：为每个场景构建贴近真实业务的测试集，覆盖常见问题、边界问题与易混淆问题，人工标注期望结果，形成可重复执行的回归测试。没有评测集的智能体项目，等于用感觉代替验收。

上线策略采用先小范围试点、再逐步放量的方式，先由少量业务骨干使用并反馈，修正问题后再扩面，避免缺陷在大范围暴露。

（六）运营机制：智能体不是"交付即结束"

项目交付后，数商云与客户共同建立运营机制：定期分析真实会话中的答不上来、答错与转人工情况，反哺知识库与工具集；把高频交互沉淀为更稳定的工作流；把新增场景纳入统一的开发规范。智能体的效果是一条持续爬升的曲线，而不是交付时的一次性快照。

四、应用价值：从效率改善到组织能力沉淀

（一）一线作业：从"找信息"回到"做判断"

试点场景中，一线人员最直接的感受是信息获取路径被大幅压缩。过去需要跨系统查询、电话确认、翻找文档才能拼凑出的信息，现在可以通过对话一次性获得，并且能看到来源依据。设备异常处置、质量异常初判、供应信息查询等场景的响应速度明显改善，员工把时间更多花在判断与处置上，而不是检索与搬运上。

（二）管理决策：口径统一与过程可见

智能体的输出建立在同一套知识与数据之上，不同岗位看到的口径趋于一致，减少了因信息不对称导致的反复沟通。调用日志、转人工记录与高频问题分布，也为管理者提供了新的观察窗口，帮助识别流程堵点与知识盲区。

（三）知识资产：从个人经验到组织能力

文档治理与知识库建设的过程本身，就是一次知识资产化运动。过去依赖口口相传的经验被显性化、结构化，成为可检索、可复用、可评价的组织资产。新人培训从"跟着师傅慢慢悟"转向"带着问题随时问"，上手周期明显改善；资深工程师则从重复答疑中解放出来，投入到工艺优化等更有价值的工作中。

（四）平台化复用：从"做一个"到"能持续做"

随着首批场景跑通，客户与数商云共同沉淀了智能体开发的规范流程、组件化工具与评测方法，新的业务场景不再需要从零开始，而是在既有底座上组装。这种可复用性，是制造业智能体从"项目"走向"能力"的关键分水岭。

五、落地过程中的几条经验

（一）不要把智能体当成"更聪明的搜索框"

如果只把它当作问答工具，价值天花板会很低。真正的价值释放点，在于让智能体进入业务流程，承担一部分信息收集、初步判断与流程发起的动作。

（二）数据治理的投入无法绕开

模型能力可以外购，企业的知识质量与数据质量只能自己建设。智能体放大了数据的价值，也同样放大了数据的缺陷。

（三）评测体系要先行于大规模推广

先想清楚什么叫做得对，再谈做得快。缺少评测的推广，往往在规模扩大后暴露出难以收敛的问题。

（四）组织配套决定落地深度

项目需要业务负责人、数据负责人与技术负责人共同在场：业务方定义什么是有价值的场景，数据方保障知识是否可信，技术方解决如何稳定实现。三方缺一，智能体就容易停留在演示阶段。

六、制造业AI智能体的演进方向

（一）从单点助手走向流程协同

早期智能体多以单点助手形态出现，解决某一段的具体问题。随着工具调用与编排能力成熟，智能体将更多以流程协同者的角色出现，串联跨系统、跨部门、跨角色的任务链条。

（二）从辅助建议走向受控执行

在权限、审计与人在回路机制足够可靠的前提下，智能体的执行权限会逐步放开。这个过程不会是突进的，而是随信任积累分阶段推进：先建议，再代人起草，最后在明确边界内自动执行并留痕。

（三）从项目交付走向能力平台

企业最终需要的不是若干个孤立的智能体，而是一套能够持续生产、评测、治理智能体的底座能力，包括知识管理、工具注册、权限治理、效果评测与运营分析。制造业的智能化竞争，最终会落在组织能否持续、低门槛地生产可用智能体这件事上。

（四）模型能力与工程能力的双轮驱动

模型进化会不断抬高能力上限，但真正决定落地效果的，仍是工程侧的细节：知识是否准确、工具是否可用、权限是否清晰、异常是否可兜底。把工程做扎实的企业，才能在下一次模型跃迁时获得更大增益。

数商云在这个案例中的角色，正是把这套从场景诊断、知识治理、智能体搭建到运营迭代的方法，变成制造企业可以落地的路径。对仍在观望的制造企业而言，更现实的问题或许不是智能体能不能做，而是从哪一个场景开始，才能既看到效果，又不承担不必要的风险。