项目交付｜数商云完成某企业私有化AI Agent智能体搭建工作

发布时间： 2026-09-28 文章分类：行业案例

阅读量： 0

AI智能体开发服务

数商云AI智能体开发服务，集成AI、大数据、云计算技术，提供全生命周期管理，涵盖需求分析至运维。支持智能客服、推荐等应用，助力企业高效构建智能体，提升业务效率，降低成本，实现智能化转型。

智能化转型走到深水区，制造企业先要回答“从哪开始”

过去一段时间，企业对大模型的态度变了几次。最早是好奇，拿几个问题去试通用助手；接着是失望，觉得它答得热闹却办不了事；现在更多人开始追问具体问题——这套能力能不能进到业务里，能不能在我们自己的机房里跑，能不能让一线的人少跑几趟腿。真正动手之后，难点往往不在算法，而在场景太散、数据不敢出内网、业务与技术说不清彼此的需求，以及项目上线之后没人接着运营。

高端装备制造行业的处境尤其典型。产品结构复杂、交付周期长、上下游协同密集，大量经验沉淀在资深工程师的脑子里，靠人与人传递，效率有限。数商云近期完成的一个私有化AI Agent搭建项目，客户就是这样一家装备制造行业的头部集团。他们要的不是一个会聊天的工具，而是一套能在内网长期运行、业务部门自己也能维护的企业级AI应用底座。

客户画像：多基地协同、系统林立的装备制造集团

该集团在装备制造领域经营多年，业务覆盖研发设计、生产制造、销售与售后服务等完整链条，在国内多个区域设有生产基地与服务中心，并承接海外项目。产品以按单定制为主，项目制交付特征明显，同一型号在不同客户现场往往有不同配置，这对知识复用的要求很高。

组织上，集团采用事业群加职能中心的架构，各事业群拥有一定自主权，信息化建设起步较早。ERP、MES、PLM、CRM、OA等系统陆续上线，核心业务基本实现了在线化，也沉淀了可观的数据资产。系统越多，边界越清晰，跨系统的信息流动反倒成了麻烦：工艺文件在PLM里，售后工单在CRM里，备件信息在ERP里，一线人员要回答客户一个问题，常常需要打开若干界面，或者干脆打电话找老师傅。

该集团信息中心负责人的说法是，他们不缺系统，缺的是把系统里的内容真正用起来的那一层。近年来集团在数字化转型上的投入持续加大，人工智能被列为重点方向，但管理层对“先做一个漂亮演示、再无声无息”的路径保持警惕，反复强调要看到业务侧的真实使用。

核心需求与挑战：既要好用，也要可控

项目启动前的调研阶段，数商云团队与集团信息中心、事业群业务骨干以及一线服务人员做了多轮沟通，需求逐渐收敛成几个方面。

① 知识获取效率是最急的痛点。售后服务工程师在现场排查故障时，需要翻阅设备手册、历史工单和工艺变更记录。这些资料分散在不同系统里，检索靠关键词，命中与否高度依赖个人经验。新人上手慢，老工程师被反复打扰。工艺与质量部门的情况类似，标准文件的版本管理很严，但“找到正确的那一版并读懂它”仍然要花不少时间。
② 数据不能出内网是底线。集团涉及大量图纸、工艺参数和客户合同信息，安全与合规要求明确，公有云推理不能作为主路径。这决定了项目必须走私有化部署，模型、知识库、运行日志全部留在集团自己的环境里。
③ 场景多而分散，缺少统一承接的平台。调研中收集到的想法覆盖研发、工艺、质量、供应链、售后和IT服务等多个方向。如果每个场景单独开发一套系统，很快会形成新的烟囱，运维和迭代都难以为继。
④ 业务与技术之间翻译成本高。业务人员能清楚描述痛点，却说不清模型需要什么输入、输出该怎么约束；IT团队排期紧张，也不具备大模型应用的工程经验。需求评审会上，双方常常各说各话。
⑤ 智能体要能办事，而不只是聊天。集团明确表示，如果智能体只把答案念出来，价值有限。他们更希望它能查询订单状态、调取库存信息、生成工单草稿、发起审批，也就是真正嵌进业务流程。
⑥ 上线只是开始，效果需要持续运营。谁来判断回答质量，谁来更新知识，模型迭代之后怎么验证，这些机制如果不在设计阶段想清楚，系统上线后很快就会失真。

数商云的AI Agent解决方案：先立平台，再做场景

面对这些诉求，数商云没有直接扎进某个单点场景，而是把项目拆成两步：先把私有化的AI Agent开发平台搭起来，将模型、知识、工具、权限、评测这些公共能力沉淀下来；再在平台上按优先级搭建场景智能体。整体思路可以概括为底盘稳、场景快、可运营。

私有化底盘：模型与数据都留在集团内网

架构底层是模型层。数商云为集团部署了适配中文语境与工业文本的开源大模型，运行在集团自有的算力资源池上，同时预留多模型接入与路由能力：不同任务调用不同规模的模型，结构化的简单任务走小模型控制成本，复杂推理再交给大模型。模型层之上是统一的数据接入与访问控制网关，推理请求全部在内网完成，敏感字段在进入推理环节前按规则过滤，调用链路全程留痕，可审计、可回溯。

平台层：用一套AI Agent开发平台承接多个场景

平台层是项目的重心。数商云基于自研的AI Agent开发平台，为集团提供了可视化编排、知识库管理、工具接入、权限控制、效果评测和运行监控等能力。

可视化编排把智能体的角色设定、任务流程、工具调用和输出格式做成可配置的模块，业务人员经过培训后也能参与调整，不必每次都提需求给IT。
知识库管理支持多种格式文档的解析、切分与向量检索，并能按事业群、角色设定访问范围，避免越权获取。
工具与插件机制把业务系统的能力封装成智能体可调用的动作，例如查询订单、读取库存、创建工单草稿。
权限与审计与集团统一身份认证打通，谁在什么时间调用了哪个智能体、获取了哪些数据，都有记录。
评测与监控提供回答质量打分、调用链路追踪和失败原因归类，为后续迭代提供依据。

这一层的意义在于，集团后续新增场景时不需要从零开始，而是在同一平台上配置、复用、扩展。这一点正是企业数字化转型中经常被忽略的部分：工具要能被组织自己接管，才算真正落地。

知识底座：把散落的经验变成可检索的资产

平台之上，数商云与集团各业务部门一起梳理知识资产。工艺文件、设备手册、故障案例、历史工单、质量报告、合同模板被分批整理入库，同时明确了知识的分级与更新责任。对于资深工程师脑子里的隐性经验，项目组采用访谈加场景问答的方式做结构化整理，把它变成可被检索的条目。

知识库不是一次性搬运。数商云为集团设计了版本联动机制，源文件更新后知识条目同步刷新，避免出现“答案很流畅、依据已作废”的情况。这是制造企业推进大模型落地时最容易踩的坑之一。

智能体搭建：从“能问答”走向“能办事”

有了平台和知识底座，场景智能体的搭建速度明显加快。项目组按业务价值与实现难度排序，先落地了几个高频场景。

① 售后服务智能体面向现场工程师。输入故障现象，它给出可能原因、排查顺序、相关图纸位置和历史处理记录，并能把过程整理成服务记录草稿。
② 工艺问答智能体面向生产与质量人员，回答参数要求、工序要点一类的问题，每条答案附出处与文件版本。
③ 供应链辅助智能体帮助采购人员汇总历史成交情况、供应商资质与交期信息，把原本需要跨系统比对的工作压缩成一次问答。
④ IT服务台智能体承接账号、权限、常见故障的自助处理，把重复性咨询从人工那里分走。
⑤ 合同与报价辅助智能体按集团模板比对条款差异，提示需要人工复核的位置。

这些智能体的共同点是都要调用业务系统的接口。数商云与集团IT团队共同梳理了接口清单，采用统一网关的方式做集成，既保证权限校验，也避免每个智能体各自直连后台。对业务人员来说，它就是一个入口；对IT团队来说，调用关系和风险都是可控的。

实施过程：从场景盘点到上线陪跑

项目由集团信息中心牵头，各事业群业务骨干参与，数商云派出方案、算法、前后端与测试人员组成交付团队，驻场与远程结合推进。整个过程大致分为几个阶段。

① 场景盘点与排序。团队走遍主要事业群，把收集到的想法按使用频率、业务价值和实现难度排成清单，与业务方逐条确认，砍掉了一批“听上去很美、实际没人用”的设想。
② 原型共创。针对排在前面的场景，数商云先做出可交互的原型，让一线人员直接上手试用。服务部门的区域经理在试用后提出，排查步骤的呈现顺序应该贴合现场作业习惯，而不是按文件章节排列。团队据此调整了输出结构。
③ 开发与联调。原型确认后进入正式开发，接口对接、权限校验、压力测试同步进行。集团IT团队负责网络与账号体系的配合，数商云负责平台与智能体侧的工程实现。
④ 试点上线与陪跑。选择使用意愿最强的部门先行试用，交付团队在初期保持高频响应，收集真实问题反哺知识库和编排配置。同时为集团培训了一批内部智能体管理员，把配置、更新和评测的方法一并移交。

项目负责人提到，这个项目里数商云团队花时间最多的不是写代码，而是和业务人员一起把问题问清楚。需求写得越具体，后面的返工就越少。