一、项目背景：能聊天的数字员工，为什么干不了活
很多企业上线数字人之后都会碰到同一种尴尬：数字员工能聊、能答、能查知识库，可一旦遇到“这单货发到哪了”“把这条报修工单建起来”这类要真正动手的事，就立刻卡壳。问题通常不在于大模型不够聪明，而在于数字人智能体与业务系统之间还隔着一堵墙。本文要复盘的，就是数商云为某制造行业头部集团搭建数字人智能体的完整过程——从一个高频场景切入，把订单、库存、工单这些系统能力拆解成智能体可调用的动作，最终让数字员工真正具备业务执行能力。
（一）客户的业务场景：一个典型的多系统、多角色服务现场
这家集团在装备制造领域长期处于头部位置，销售端以大客户直销与经销商渠道并行，售后服务的体量一直维持在高位。日常咨询来自四面八方：客服中心在接电话，区域服务工程师在现场跑，经销商业务人员在催发货，大客户的设备管理员在问保修范围。
把这些咨询归拢一下，无非几类：订单走到哪一步了、发货与物流到哪了、某个备件还有没有货、价格怎么算、安装调试排到什么时候、保修政策覆盖哪些情况、故障报修后工单进展如何、发票开了没有、对账数据对不对。看起来都是普通问题，但它们有一个共同特征——答案不在某一个系统里，而是散落在 ERP、订单管理、仓储与备件、CRM、服务工单、财务开票以及承运商物流接口之中。
（二）被反复放大的几处卡点
- 知识问答解决不了执行问题。过去上线的话术机器人能把政策讲清楚，却没法查一条真实订单的状态，用户听完还是要转人工。
- 跨系统查询靠人工搬运。客服要在一个系统里查订单、切到另一个系统看库存、再去工单系统看进度，来回切换既慢又容易看错。
- 服务口径依赖个人经验。同样的保修问题，不同坐席给出的解释可能不一致，返工和投诉就藏在这些差异里。
- 服务时段与人力弹性不匹配。客户和设备不会只在工作日白天出问题，而人工坐席的排班是有边界的。
（三）早期尝试留下的教训
在找到数商云之前，客户已经试过几轮。关键词匹配式的客服机器人，意图稍微换个说法就答非所问；单点 RPA 能模拟人工点界面，但缺乏语义理解，界面一调整脚本就失效；直接拿大模型做问答，又存在编造数据和越权查询的风险，风控部门很难放行。
这几轮尝试指向同一个结论：数字人不能只做“入口”，还得做“手脚”。只解决对话，不解决执行，价值始终停留在浅层。
二、破局思路：把“会聊天”和“能办事”拆开设计
（一）核心判断：智能体的价值在任务闭环
项目组在启动阶段就把数字人智能体的能力拆成了几个层面来看，而不是笼统地谈“智能”。
- 交互层：数字人形象、语音识别与合成、多轮对话、界面上的结构化呈现。
- 认知层：意图识别、知识检索、任务规划、上下文理解。
- 执行层：调用业务系统接口、编排跨系统流程、处理返回结果。
- 治理层：权限校验、操作留痕、异常兜底、人工接管。
真正拉开差距的是后两层。用户感受到的“能办事”，本质上是执行层和治理层做扎实了。
（二）数商云方案的落地思路
数商云为这个项目提供的数字人智能体开发平台，承担的是“调度中枢”的角色：统一做智能体编排，支持多种大模型的接入与路由；用知识库承接政策、手册、FAQ 这类非结构化内容；把业务系统的接口封装成智能体可以调用的工具与技能；通过工作流引擎把多个动作串成一条完整任务链；再叠加语音识别与合成、数字人形象驱动、会话数据分析，以及私有化部署与数据隔离能力。
这里有一个关键定位：它不是替换客户现有的业务系统，而是叠在它们之上，成为业务能力的统一调度入口。ERP 还是那个 ERP，工单系统还是那个工单系统，变化的是用户不必再自己去找它们。
（三）定下的设计原则
- 以任务为中心。不追求“什么问题都能答”，而是把有限场景做到任务能闭环。
- 以接口为边界。智能体能做什么，严格由后端接口和权限决定，不靠模型自由发挥。
- 以可回退为底线。任何办理类动作都要可确认、可追溯、可转人工。
三、搭建过程：从场景梳理到数字员工上岗
（一）场景筛选：优先挑“高频、规则清晰、系统有接口”的任务
项目组没有一上来就铺大摊子，而是和客服、售后、IT 一起把咨询记录做了归类，按几个标准筛场景：发生频次是否足够高、判断规则是否相对确定、后端是否已有可用接口、出错代价是否可控。
按这个标准，初期锁定的是：订单与发货进度查询、备件可用量与价格查询、服务工单创建与进度查询、保修与政策咨询、开票与对账信息查询。办理类动作则先只开放风险最低的几项，比如追加服务记录、更新联系人信息、预约上门时间。先把查询类做稳，再逐步放开写入类，这个顺序后来被证明非常关键。
（二）语义层建设：让智能体听懂行业里的“黑话”
制造业的沟通方式和通用场景差别很大。经销商习惯用简称叫型号，工程师会说备件的口语化别名，客户报故障时往往只描述现象不报编码，同一个词在不同语境下还可能指向不同的东西。
数商云团队和客户一起做了几件事：整理术语表与同义词，建立型号别称到标准编码的映射，把常见的上下文指代（“刚才那单”“这个设备的备件”）设计成可解析的规则，并对“客户、经销商、最终用户”之间的身份关系建模。这一步看起来不炫，但它决定了智能体是“听懂了”还是“猜对了”。
（三）工具化封装：把系统能力变成智能体可调用的动作
这是整个项目里工作量最实的一部分。每个动作都要写清楚：名称与用途、入参出参、可调用的角色、失败时返回什么、是否需要再次确认、重复调用怎么处理。
- 查询类动作：订单状态、物流轨迹、备件可用量、工单进度、应收与开票信息。
- 办理类动作：创建报修工单、追加服务记录、发起退换货申请、更新联系人信息、预约上门时间。
两类动作的放行尺度完全不同。查询类可以相对开放，办理类必须叠加权限校验、用户确认与操作留痕，涉及库存变动、金额调整的动作还要走审批或人工复核。同时，所有写操作都做了幂等与防重设计，避免因为网络重试造成重复建单。
（四）流程编排：多轮对话如何不断线
一条完整的任务链在平台里大致是这样跑的：识别意图，补齐缺失的关键信息，校验身份与权限，调用对应动作，核对返回结果，再用自然语言把结果讲清楚，最后落一条记录用于追溯。
难点在异常分支。接口超时怎么办？权限不够怎么解释？参数缺失怎么追问？返回为空是“真的没有”还是“查错了”？用户中途改口怎么接？情绪激动怎么转人工？项目组把这些情况逐条写进了编排逻辑，并确立了一条原则：不确定就澄清，查不到就说查不到，办不了就转人工，绝不允许模型编造业务数据。模型负责组织语言，业务事实一律以系统返回为准。
（五）数字人交互层：让“执行结果”看得见
交互层做了语音与文字双通道，数字人形象负责播报与情绪表达，语音识别针对行业口音和方言做了适配。更关键的是界面的配合：办理类任务在对话的同时会展示结构化卡片——订单号、当前节点、下一步动作——用户可以当场核对，而不是只听到一句口头结论。这一点对建立信任帮助很大，尤其是在涉及金额和责任边界的场景里。
（六）权限、安全与合规：能办事的前提是不越权
智能体的账号体系与业务系统做了身份映射，用户能看什么、能改什么，完全跟随其在原系统中的权限。数据遵循最小可见原则，敏感字段做遮罩处理，会话内容与操作行为全程留痕，方便审计与追溯。整个平台以私有化方式部署，业务数据不出企业边界，这也让风控和法务在评审时少了很多顾虑。
（七）灰度上线与持续运营
上线没有一步到位，而是分了几步走：先作为坐席助手在内部使用，辅助人工查数据；稳定后再面向客户和经销商开放查询类能力；办理类能力最后才逐步放开。
配套的评估看的是几件事：任务是否真的闭环、转人工的比例、用户追问的轮次、以及来自一线的反馈。每次复盘的产出都会回到知识库和工具清单里——新出现的问法变成知识条目，新冒出的需求变成新的工具动作。就这样，数字员工的能力是滚起来的，不是一次性交付完就固定了。
四、实施成效：数字员工的价值体现在哪
（一）业务侧：响应更快、口径更统一、闭环更完整
常见的订单、物流、库存、工单类问题，客户和经销商可以自助拿到结果，不必再排队等坐席。坐席人员从大量重复问答里被释放出来，专心处理复杂异常和需要判断的case。跨系统查询由智能体统一调度完成，过去那种“人工搬运数据”的环节明显减少。服务口径统一之后，因理解差异导致的返工和解释成本大幅下降。服务时段也从工作日延伸到全天候，客户在非工作时段遇到问题不再只能等。
（二）组织侧：能力沉淀，而不是依赖个人经验
老师傅脑子里的判断经验，被拆成了可复用的知识条目和标准流程。新人上手更快，因为问智能体就能拿到口径一致的答案。跨部门的协作也有了统一的任务入口，客服、售后、仓储之间的信息传递不再靠截图和口头转述。
（三）技术侧：沉淀出一套可复用的能力底座
项目沉淀下来的不只是数字人本身，还有工具化封装规范、语义资产、流程编排模板、评估埋点体系。这些东西可以迁移到其他场景——内部 IT 服务台、人力共享服务、供应链协同、渠道政策咨询，都能复用同一套方法。这也是数商云在这个项目里比较看重的长期价值：一次搭建，多处复用。
五、经验启示：让数字员工真正具备业务执行能力
（一）从任务出发，而不是从技术出发
客户一开始也讨论过“要不要上更先进的模型”，但最后决定先把场景选对。事实证明，决定数字员工好不好用的，是任务拆得够不够细、接口调得通不通，而不是模型参数有多大。技术选型应该服务于任务闭环。
（二）接口治理是绕不过去的前提
如果后端接口本身不规范、文档缺失、权限混乱，智能体落地就会非常吃力。这个项目在前期花了相当精力做接口梳理和标准化，看起来不显眼，却直接决定了后面能不能快速扩展新场景。智能体对接业务系统，本质上是一次企业内部能力的再梳理。
（三）边界与兜底，比能力上限更重要
一个敢说“这事我办不了，帮你转人工”的数字员工，比一个什么都说“没问题”的数字员工更值得信任。权限、确认、留痕、兜底这几件事做到位，业务部门才敢把真正的办理动作交出去。
（四）小步快跑，用业务反馈驱动迭代
先做查询、再做办理，先内部、再外部，先少数场景、再逐步铺开。每一步都拿到真实反馈，再决定下一步怎么走。这种节奏看起来慢，实际反而更快，因为避免了大规模返工。
（五）机制与组织要同步跟上
数字员工上岗之后，需要有明确的责任机制：业务部门负责出题和验收，技术团队负责能力和工具建设，风控法务负责边界审核，运营团队负责日常的问题收集与知识更新。没有这套机制，智能体很快就会停在“能用但没人管”的状态。
回到最开始那个问题：数字人到底能不能干活？答案取决于它身后的那套系统是否被真正打通。形象做得再逼真、对话再流畅，如果查不到一条真实订单、建不了一条真实工单，它就永远只是演示。当数字人智能体与业务系统完成对接，当每个动作都有权限、有留痕、有兜底，数字员工才真正从“会说”走到“会办”——这才是企业愿意为之买单的那一步。
评论