当数字人走进业务现场，卡住的往往不是模型
企业上马数字人项目，开场往往很相似。展厅里立一块大屏，屏幕上站一位形象得体的虚拟员工，能打招呼、能介绍公司、能念一段欢迎词。参观的人觉得新鲜，过一阵子再去看，屏幕已经暗着。
也有企业反过来，拿通用大模型搭一个问答机器人。上线时热闹，真正用起来，业务人员问几句就放下了——问产品配置，答得含糊；问内部流程，答的是网上那套通用说法；问某个订单现在到哪一步，它只能礼貌地说自己不清楚。
问题很少出在模型本身。真正难的是中间那段工程：企业的知识散在文档、图纸、工单和老员工的判断里，业务系统各管一摊，权限边界、数据合规、责任归属没人能简单说清。数字人形象再逼真，背后如果没有一个能调用工具、能查数据、能被业务人员自己维护的AI智能体，它就只是个演示品。
这也是企业级AI应用当下最典型的困局：开发成本高、场景分散、周期拉长，最后不了了之。近年来，某高端装备制造行业头部集团推进数字人AI Agent建设时，遇到的正是这些问题。差别在于，他们后来换了一种做法。
客户背景：一家知识密集、渠道分散的装备制造集团
该集团是国内高端装备制造领域的头部企业，产品线覆盖多个细分市场，从核心设备到成套系统都有布局。与不少制造企业相比，它的业务链条格外长：前端要做技术方案和选型，中间要排产、交付、安装调试，后端还要长期提供备件与运维服务。
组织形态上，该集团由多个事业部构成，下设分布在不同区域的生产基地，销售与服务网络覆盖全国，并在海外设有营销和服务网点。渠道体系里既有直销团队，也有数量可观的经销商、代理商和集成商，他们直接面对终端客户，却不一定熟悉产品的每个细节。
企业数字化转型的基础并不薄弱。多年来，该集团陆续上线了ERP、MES、PLM、CRM、OA以及企业知识库等系统，沉淀下来的数据和技术资料体量可观。问题在于，这些系统大多按部门、按项目建起来，口径不完全一致，跨系统取数门槛高。大量真正有价值的经验，还停留在文档、手册、图纸、邮件和老工程师的脑子里。
"我们不缺系统，缺的是把这些系统里的东西，用自然的方式交到需要的人手上。"该集团信息中心负责人的这句话，后来成了项目立项时反复被提起的共识。
需求与挑战：数字人AI Agent要接住哪些真实问题
项目启动前，数商云团队和该集团做过走访。走访对象不是IT部门，而是业务现场。梳理下来，诉求集中在几个很具体的地方。
- 销售和渠道在客户现场答不上问题。装备类产品的配置组合复杂，同一个系列下面还有多种选型，交付周期、备件供应、认证要求各不相同。经销商在客户会议室里被问到一个技术细节，通常只能打电话回总部，接电话的人还常常在开会。等答复的时间，往往就是客户耐心流失的时间。
- 售后服务被重复问题反复消耗。服务工程师分布在全国各地，遇到不熟悉的机型或故障现象，习惯先找总部的技术专家。专家一天里相当一部分精力花在回答相似问题上，真正需要深度判断的疑难问题反而被挤压。而这些问答过程本身，也很少被沉淀下来。
- 职能部门的服务台被基础咨询占满。制度怎么规定、流程怎么走、报销需要哪些材料、入职手续办到哪一步，这类问题占了行政和IT服务台的大量时间。员工找不到人，就打热线；热线答过，下次还是同样的问题。
- 培训跟不上产品迭代。新产品、新版本的资料更新快，线下培训的排期和课件制作常常滞后。新员工入职后主要靠师徒带，上手周期长，学到的内容也因人而异。
- 吃过通用大模型的亏。该集团此前做过小范围尝试，用通用模型回答产品相关问题，出现过言之凿凿却给出错误参数的情况。涉及技术参数和合同条款，答错的代价很高。同时，技术资料属于企业核心资产，不能随意出企业边界，不同岗位能看的内容也必须有区分。
- 组织和责任上的顾虑。知识由谁维护？各事业部的资料口径不一致，谁来拍板？业务部门对"又一个IT项目"普遍持观望态度，不太愿意往里投人力。这些问题不解决，系统建起来也会很快荒废。
- 成本和节奏的要求很明确。该集团不想再做那种周期漫长、投入巨大、上线才知道好不好用的项目，希望先在一个场景里跑出可用的结果，验证之后再谈推广。
这几点叠在一起，指向的其实是同一个判断：企业要的不是一个会说话的数字人，而是一个能准确回答问题、能连上业务系统、能持续更新的AI智能体。
数商云数字人智能体解决方案：让AI Agent成为业务入口
形象是外壳，AI智能体才是内核
数商云团队在方案沟通的早期就提出一个判断：数字人的价值不在形象，而在它背后能不能干活。形象解决的是"愿不愿意跟它说话"，智能体解决的是"说完话有没有用"。前者是设计问题，后者是工程问题。项目从形象开始做，很容易做成展厅项目；从场景和知识开始做，才有可能长成业务的基础设施。
基于这个判断，双方把项目落点定为：以数字人为统一交互入口，以AI智能体为能力内核，先把该集团最痛的几个场景做扎实，再横向铺开。
平台选型与架构设计
该集团没有选择从零自研，也没有直接采购某个封闭的成品应用。数商云提供的是以AI Agent开发平台为底座的建设路径——平台负责模型接入、智能体编排、知识检索、工具调用和权限治理，业务场景在平台上配置和迭代。这条路线的另一个好处是，大模型落地过程中最容易被低估的模型替换、效果评测、版本管理，都被收进了平台层统一处理。
架构大致分成几个层次。
交互层承载数字人形象、语音识别与合成、多终端发布。员工可以在PC端、移动端、企业微信或钉钉里使用，展厅大屏和车间终端也能接入同一个智能体，只是呈现形式不同。
智能体编排层是整个方案的枢纽，负责识别意图、拆解任务、判断这次回答是走知识检索还是调用业务系统接口，必要时还会追问澄清。针对该集团的情况，数商云没有做一个"什么都能问"的巨型机器人，而是按角色拆分出多个专职Agent，再由调度层根据问题类型路由过去。这样每个Agent的知识范围和工具权限都能收紧，回答准确率明显更可控。
知识与数据层存放经过整理的企业私域知识，同时承担与业务系统的接口调用。检索采用向量召回与关键词召回结合的方式，并保留原文出处，让使用者能看到答案来自哪份文件、哪一版资料。
模型层以私有化部署的大模型为主，保证技术资料和会话内容留在企业内网。对于部分需要通用知识的场景，通过统一网关接入外部模型能力，并对出入内容做管控。
治理层贯穿所有层次，包括权限继承、内容审计、会话留痕、敏感信息过滤和效果评估。这一层不出彩，但它决定了这套系统能不能长期留在企业的生产环境里。
数字人Agent的角色划分与搭建路径
结合走访结果，数商云与集团共同划定了首批数字人Agent角色。
面向销售与渠道的方案助手，能按客户工况和需求做初步选型，调取参数对比、典型应用案例、常见竞品差异，并把结果整理成可供继续编辑的说明草稿。它不只是回答，还替销售完成了一部分案头工作。
面向服务工程师的技术支援助手，按"现象—可能原因—排查步骤"的结构引导排查，检索维修手册、图纸和相似历史工单。遇到超出范围的疑难问题，它会整理好已有信息再转人工，避免专家从头问起。
面向全体员工的员工服务助手，回答制度、流程、报销、人事政策类问题，答案直接指向对应的制度条款和办理入口。
面向来访客户的展厅讲解数字人，承担产品与解决方案的讲解，并能接住参观者临时提出的追问。它和方案助手共用同一套知识底座，讲解内容与销售口径保持一致。
搭建路径上没有追求一次做全。数商云的做法是，先选一个知识相对完整、风险相对可控、使用人群明确的场景做出样板，把知识梳理、接口对接、权限配置、效果评估的流程跑通，形成可复用的方法，再复制到下一个角色。这样做的好处是，后面的智能体搭建更像是配置和调优，而不是重新开发。
与业务系统的集成方式
数字人能不能干活，很大程度上取决于它能不能连上业务系统。该集团原有的ERP、CRM、PLM等系统继续承担记录和流程职责，数商云通过接口把它们的能力开放给智能体。
集成的原则有几条。查询类操作走只读接口，比如订单进度、库存状态、备件编码，由智能体调用后如实呈现，不让模型去"推测"。涉及写操作的动作，比如提交工单、发起申请，由智能体完成信息填写后交给用户确认，再走原有流程。权限体系与集团账号打通，员工能看到什么，数字人助手才能返回什么，避免越权访问。所有调用都留痕，便于事后追溯。
知识治理：决定项目能走多远的一环
很多数字人项目上线即巅峰，原因多数不在技术，而在知识没人管。数商云在该项目里把知识治理单独作为一个工作流来做。
先是知识盘点。把散落在各系统、各文档库里的资料梳理一遍，按业务域归类，同时标记密级和适用范围。接着是知识加工。原始文档不能直接丢给模型，需要切分、标注、补充上下文，把老师傅口头的判断经验转写成结构化的问答与决策规则。
更关键的是责任人机制。每一类知识都指定业务侧的维护人，资料更新时同步更新知识库，通过数商云提供的管理后台完成，不需要走IT排期。集团还从各业务部门挑选人员，培养成智能体管理员，负责本领域知识的日常维护和效果反馈。这些工作做完，系统才算真正交到了业务手里。
实施过程与关键动作：从场景筛选到规模化推广
项目从规划到上线，节奏被刻意压紧。数商云派驻实施与算法团队，与该集团信息中心、销售管理部门、售后服务部门、行政共享中心的人员组成联合项目组，按固定周期对齐进展，问题当天进清单，下次碰头先看未结项。
- 场景筛选与收敛。双方用"使用频次高不高、业务价值大不大、知识是否可得、答错风险是否可控"几个维度，把最初列出的场景清单收敛到一个范围。销售方案支持和服务技术支持被排在前面，原因是使用人群明确、痛点直接、资料基础相对好。
- 知识梳理工作坊。数商云的交付人员做引导，把业务专家请到一起，一个问题一个问题地对：客户通常会怎么问？我们内部实际怎么判断？依据是哪份资料？哪些话可以说，哪些不能承诺？工作坊产出的不只是知识条目，还有内部第一次相对统一的口径。
- 原型验证。数商云先搭出可交互的原型，交给业务人员试用，不追求功能完整，只求快速暴露问题。测试期间收集到的答错案例被逐条复盘，区分是知识缺失、检索不到，还是模型理解偏差，分别处理。
- 灰度上线与推广。样板Agent先在小范围用户中开放，同时保留原有的人工支持通道，用户不放心时可以随时转人工。运行稳定后，再逐步扩大使用范围，并同步启动其余角色的搭建。
"最难的不是把模型跑起来，是让业务部门相信这件事跟他们有关。"该集团项目负责人在复盘时说，"工作坊那几天，几位老师傅把压箱底的判断逻辑讲出来了，后面的事情才顺。"
应用成效与价值：变化发生在具体的工作环节里
成效最直观的地方在销售现场。以前，经销商在客户那里遇到技术问题，要打电话、等人回、再复述一遍。现在打开移动端的方案助手，参数、配置差异、典型工况案例当场就能调出来，还能顺手生成初步说明。带回去整理的时间大幅缩短，现场能往下谈的内容明显变多。有销售负责人反馈，过去一些因为答复不及时而搁置的机会，如今有机会接住了。
售后服务的变化体现在专家资源的分配上。服务工程师遇到不熟悉的机型，先按技术支援助手给出的排查逻辑梳理，多数常见问题当场有了方向，确实棘手的再升级给总部专家，且带着已经收集好的现象描述和历史工单信息。重复问答减少后，专家能腾出更多时间处理真正需要经验判断的问题。同时，每一次问答都在往知识库里沉淀，用得越久，可查的内容越厚。
职能服务台的感受也很明显。员工先问员工服务助手，问不到再转人工，服务台处理的问题更集中，也更有价值。新员工入职后不再完全依赖师徒带，随身的资料助手能回答相当一部分基础问题，上手周期缩短，学到的口径也更统一。
对管理层来说，价值以另一种方式显现。高频问题的分布、答不上来的问题集中在哪些环节，都成了可观察的信号。哪些产品资料版本陈旧、哪些培训内容缺失、哪些流程说明容易让人误解，这些过去藏在热线记录里的信息，现在能反过来推动业务改进，决策从凭印象转向看证据。
更深一层的变化发生在组织能力上。原来只存在个别人脑子里的判断经验，被整理成可检索、可复用、可更新的知识资产。业务人员通过管理后台自行维护知识，不必再排IT的队。数字人AI Agent由此从"一个IT交付的项目"，变成了业务部门自己在用的工具。
结语：这套方法能复制到哪些行业
回看这个案例，真正起决定作用的，是几个看起来并不新奇的判断：场景要先收敛，不要一上来就做全能助手；知识治理要有责任人，不能全靠技术团队；智能体必须接进业务系统，只回答不办事的对话窗很难长期被使用；权限和边界要在设计阶段就考虑，而不是出了岔子再补。
这些判断跟行业关系不大。凡是知识密集、渠道分散、服务链条长、业务人员需要随时获取准确信息的行业，都会遇到类似的处境——能源与化工企业的现场运维、汽车零部件企业的渠道支持、医疗器械企业的临床与售后答疑、建筑材料企业的经销商服务，场景不同，底层需求是相通的：把企业自己的知识和大模型的能力接起来，让数字人真正参与业务。
数商云在这条路径上积累的，是AI Agent开发平台的能力，以及把平台落到具体业务场景里的方法。项目做成什么样，往往取决于前期场景选得准不准、知识理得清不清、业务部门愿不愿意一起干。
如果你所在的企业也在考虑数字人AI Agent的建设，欢迎联系数商云团队，获取专属的数字人AI Agent建设与落地咨询。
评论