兆企供应链管理AI建设推进到“WorkMate部署”这一步时我遇到最多的提问是这到底是不是又一个内部聊天机器人每次我都要解释很久。WorkMate确实带着对话界面但它背后连的是主数据、订单流、仓配事件和审批链路它要做的不是“回答提问”而是把“现场发生了什么、建议下一步做什么、需要谁拍板”串成一个可执行的事件流。而这件事能否真正落地关键其实不在大模型参数有多强而在部署策略是否清楚、人机协同的规则是否把责任边界划得明白。这篇白皮书二不再铺开讲AI应用图谱那部分在第一篇里已经梳理过。这里集中写我们实际部署WorkMate时的判断过程、技术选型、推进方法以及从上线到现在遇到并解决掉的几类典型问题。内容主要面向正在做供应链数字化或准备引入AI数字员工的项目负责人、实施工程师和运营管理者我会尽量把不少不会再写进正式方案里的判断依据也一并讲透。1. 先明确WorkMate的真实定位它不是聊天窗是供应链事件处理器1.1 供应链场景里“能对话”和“能干活”之间隔着很远的距离我见过太多团队把大模型接上企业微信就宣布“AI助手已上线”。但供应链人员试用一周后基本都会放弃原因是它只会“说”不会“做”。业务人员真正需要的并不是一个能解释什么是安全库存的百科而是当一张采购订单出现交期异常时系统能自动把相关邮件、TMS轨迹、供应商反馈汇总到同一个页面并给出“催货、改期、换供应商、触发缺料预警”这几个选项的利弊分析。WorkMate的设计初衷就是朝这个方向走把AI嵌入到供应链业务的“事件处理闭环”中。所谓事件包括订单逾期未确认、到货数量短装、报关资料缺失、库存低于安全水位、运输温度异常、应付账款票货不一致等等。WorkMate要做的是感知事件、汇聚信息、生成处置建议并在获得授权后执行低风险动作。所以部署WorkMate前必须做一次认知对齐它不是要替代SRM或者ERP它更像是站在这些系统之上的“操作助手”。你需要让它可以读系统的数据但不能让它绕过权限乱写数据你需要让它能起草回复客户的邮件但邮件是否发出必须可追溯。这个定位一旦模糊后面做的所有技术工作都会变形。1.2 人与AI的分工原则AI做“卷宗整理员”人做“审判员”在供应链管理场景里完全自动化是一件风险很高的事。供应商关系、客户承诺、折让条款、紧急插单这些场景里隐藏着大量无法结构化表达的隐性知识。同一个供应商延迟三天如果对应的是战略物料计划员可能会启动紧急空运如果对应的是通用包材也许只要调整到货顺序即可。这种判断无法简单靠模型完成至少现阶段不行。因此我们在部署WorkMate时没有追求“AI独立完成全流程”而是把人机协同作为默认工作模式。WorkMate负责扫描数据、定位异常、整理证据链、起草多个可选方案并给出它自己的推荐计划员、采购员或客服负责人负责做最终判断。这种“AI整理卷宗、人来做审判”的模式既避免了大模型在复杂决策中“一本正经胡说八道”的隐患也让业务人员感觉到自己不是被AI替代而是多了一个能提前把功课做完的助手。这个原则直接影响系统的架构设计WorkMate的每个动作都必须生成“依据片段”比如对应哪张订单、哪份邮件、哪个运输节点。没有依据的建议系统不允许直接推送给业务负责人只能放在低优先级待办里供人自助查看。2. 部署前必须确认的边界场景、数据、系统权限和底线动作很多团队在部署AI应用时习惯先选模型、再搭环境、最后找场景。我们的经验恰恰相反先把业务边界和数据条件想清楚再谈技术实现。否则大概率会把一个能跑通Demo的模型变成一个没人愿意用的“昂贵玩具”。2.1 起步场景的筛选矩阵别一上来就碰最难啃的骨头供应链涉及的环节太多不可能一次性让WorkMate覆盖所有岗位。我们最初列了一批候选场景然后拿四个维度做筛选业务发生频率、数据线上化程度、流程标准化程度、误操作可回退性。从实践看第一波最适合部署的场景往往具备三个特征发生频次高、所需数据在现有系统里已经比较完整、即使AI建议出错也不会直接造成资金或法律风险。比如“供应商发货通知与预到货时间比对”“订单确认超时提醒”“客供物料库存预警”都属于这种类型。而“合同条款自动谈判”“供应商赔付金额裁定”这类场景我们放到第二甚至第三阶段再做。先做一些低风险但高频的场景还有一个好处业务部门能很快感受到变化。当采购员发现自己每天要花一两个小时整理的催货清单WorkMate早上九点前就推送到工作台时他们对AI的怀疑会明显降低。2.2 数据条件如果线下台账比系统还准先别谈部署我在项目启动会上反复强调一句话AI能处理“混乱”但处理不了“系统里根本没有的数据”。如果企业的主数据质量很差比如同一个供应商在ERP里叫“深圳市华星电子有限公司”在Excel台账里叫“华星电子”在邮件往来里叫“SZ-HX”那么无论模型多强都无法稳定完成跨系统信息整合。所以在部署前我们专门花了两周做数据体检。检查内容包括三类一是主数据唯一性重点看供应商编码、物料编码、客户编码是否在核心系统里统一二是事件数据完整性比如物流轨迹能不能回传、订单状态变更有没有时间戳三是非结构化数据的可读取性比如邮件、PDF版合同、质检报告能否被稳定解析。体检结果决定WorkMate先做什么、后做什么。如果一个物料主数据连编码规则都还没统一那就先不让WorkMate做该物料的库存预测否则它学到的规律本身是扭曲的。2.3 系统集成与写入权限的边界清单WorkMate必须能被“投喂”数据也需要在执行动作时写回业务系统。这里涉及大量权限设计问题。我们做了一个相对保守的权限分层只读连接ERP中的采购订单、库存、物料主数据TMS中的在途轨迹WMS中的收发货记录。受控写入向SRM系统提交“催货提醒任务”、向OA发起“异常审批单”、给客户或供应商发送通知邮件草稿。禁止触碰财务记账凭证、已审批的价格主数据、合同电子签章流程。所有写入动作必须有幂等标识。同一异常事件即使WorkMate被重复触发也不允许生成两份催货单或重复扣减库存。这个细节在联调时最容易出问题尤其是消息队列发生重试时PowerShell脚本式的重复提交会直接造成业务脏数据。2.4 明确“必须由人按下按钮”的底线动作我们和运营、法务、财务一起列了一份黑名单里面是WorkMate在任何情况下都不能自动执行的动作。比如对供应商正式发出索赔函、修改采购单价、承诺新的交货日期给客户、释放超过阈值的付款指令。对这些动作系统只能把完整材料包准备好推送给对应负责人等待人工确认。这份黑名单带来的价值不只是风控。它让业务部门感受到项目组对AI边界有清醒认识这是后续推进时获得支持的关键。3. WorkMate技术部署流水账模型服务、知识库与Agent编排的落地过程进入技术实现阶段后我们把架构拆成三层模型服务层、知识增强层、Agent任务编排层。每层要解决的问题不同部署逻辑也不同。3.1 模型服务层按任务复杂度拆成“重模型”和“轻模型”关于是否要本地部署大模型我们内部争议很大。最终选择的是“混合推理”方案而不是把所有请求全部发给云端大模型也没有把一切都压在本地私有化模型上。原因是供应链数据敏感度高合同、报价、库存、客户信息不能随意出域。但完全私有化部署一个高性能基座模型成本又太高且更新维护麻烦。所以WorkMate的技术底座使用了本地部署的开源模型加内部知识库处理合同审阅、Agent规划等复杂任务而像“提取一封邮件里的供应商名称和PO号”这类高并发、低复杂度的任务则交给一台轻量模型服务以降低单位成本。模型服务本身跑在容器平台上通过OpenAI兼容协议暴露给上层。我在部署时给团队定的原则是上层应用不直接绑定某个具体模型而是通过一个路由层做模型分发。路由规则大致是长文本摘要与复杂推理走最大参数的模型工具调用参数抽取走中等模型简单分类和实体识别走轻量模型。这样即使未来替换模型也不会动到上层业务代码。3.2 RAG知识库建设WorkMate“懂业务术语”靠的不是微调我们一开始考虑过用业务数据微调模型后来发现现阶段投入产出比不高。真正让WorkMate在供应链场景里“像内行人”的关键是RAG知识库的搭建质量。知识库的内容不只是产品手册它包含几类特殊材料公司供应链管理SOP文件、合同模板库、客户特殊要求清单、供应商服务协议要点、历史异常处理案例。我们把这些内容切成不同粒度的块SOP按条款切合同按章节切历史案例按事件链路切。切完后做向量化存入知识库同时保留原始文档编号这样模型引用时能回溯到具体出处。RAG检索有一个很实际的问题供应链文档里充满“提前期”“MOQ”“VMI”“JIT”这类中英混合术语简单的向量检索经常召回不准确。我们的补救措施是建了一个“业务同义词表”把同一概念的不同说法映射到标准词条比如“最小起订量”“MOQ”“Minimum Order Quantity”“起订量”都归到一个向量索引分组下。这个表数据量不需要很大但对检索精度的提升非常明显。3.3 Agent编排层从单个问答到多步骤供应链任务WorkMate能自动处理事件依赖的是Agent能力。这里的Agent不是单纯的“调用大模型聊天”而是一套任务编排引擎。拿“供应商延迟交货预警”这个场景举例。WorkMate收到ERP推送的“PO单交货日期已过但未收到发货通知”事件后会执行一串动作先去SRM查该供应商最近一段时间的准时交付率再去邮件系统搜索最近两周与该PO号相关的往来邮件再查TMS里是否有在途异常记录。所有信息汇集后模型生成一段结构化摘要内容包括延迟可能原因、当前库存可支撑天数、建议动作选项。随后系统按预设规则判断该事件归入自动处理还是人工确认。这套多步骤能力不能依靠模型自由发挥否则动作序列会漂移。我们的做法是把每种业务事件预先定义成“状态机”节点固定模型负责在每个节点上做信息抽取、判断和生成而不是决定整个流程怎么走。这既保证了业务可控性也大幅降低模型幻觉引发乱操作的概率。3.4 与业务系统对接的集成细节先影子模式再逐步放开WorkMate与SRM、ERP、OA之间通过消息队列和API连接。部署阶段最关键的策略是“影子模式”先行。所谓影子模式是指WorkMate在最初两周内只做只读分析它生成的每一封催货函、每一份异常报告都发送到一组测试邮箱而不是真实客户或供应商邮箱。项目组用这段期间比对AI建议与实际业务人员处理结果的差异不断调整提示词与判定阈值。影子模式结束后我们开放了低风险动作的自动执行权限比如向内部计划群推送预警、生成催货任务待办。再过两周才开放了“由业务负责人确认后发送给供应商”的半自动动作。这个过程不能省它既是对模型输出质量的反复验证也是给业务团队一个逐步建立信任的过程。顺带提醒一点在对接业务系统时API调用必须加“操作人”字段。即使是WorkMate自动发起的动作也要落到某个系统账号上方便审计时追踪。否则出了问题连找谁负责都说不清安全部门那一关就过不去。4. 人机协同机制把“自动执行”和“人工决策”用规则连接起来部署完成后业务团队经常问我WorkMate到底哪些事能自己做主哪些事必须问人我们后来把答案沉淀成一套人机协同规则这是整个项目中最核心、也最难复制的部分。4.1 置信度分级不要用单一阈值决定自动还是人工我们一开始采用过简单阈值判断比如置信度超过0.8就自动执行。很快发现这个做法在真实业务里行不通。因为有些场景哪怕置信度达到0.99也不能自动执行比如涉及金钱赔付有些场景置信度只有0.7反而可以自动执行比如把某张订单的到货异常转发到内部群。后来我们把判断逻辑改成“置信度加动作风险等级”的二维矩阵高置信度加低风险动作自动执行比如更新内部异常看板、创建催货待办、向计划组推送预警。高置信度加高风险动作生成完整建议与证据包推送负责人审批比如向供应商发正式催货函、调整系统预计交期。低置信度加低风险动作推送到人工待办区但不强提醒。低置信度加高风险动作只生成“分析草案”连推送都不推需要业务人员主动进入WorkMate工作台查看。这套矩阵解决了AI系统普遍存在的“过度自信”问题。模型的置信度数值本身不能全信但把它和动作风险结合后出错的后果就被限制在可控范围内。4.2 任务看板加对话入口让不同使用习惯的人都能上手WorkMate部署上线后我们观察到两类使用者存在明显差异。年轻的计划员习惯用自然语言和WorkMate对话“帮我查一下上周所有逾期的PO单”而工作年限较长的客服主管更习惯看清单、勾选、确认。如果只做聊天窗后者会抗拒如果只做看板前者的效率优势又发挥不出来。因此WorkMate工作台同时提供两种形态左侧是任务列表按紧急程度和所属流程分组每条任务点开后能看到WorkMate汇总的“事件摘要、证据材料、建议动作、风险提示”四块信息。右侧才是对话界面主要用于追问和数据探查。这个设计背后有一个经验人机协同的界面不能只考虑“怎么让AI回答问题”还要考虑“人如何快速完成确认动作”。在很多供应链岗位高频操作是“看一眼材料、点一下同意或修改”。把界面做成材料完整、按钮清晰的审批流比让业务人员自己组织语言问AI更符合实际场景。4.3 角色授权WorkMate的能力要跟着人的权限走在部署前安全评审时我们被问了一个尖锐问题如果计划员问WorkMate“这个供应商的采购单价是多少”而这个计划员本身没有查看价格的权限系统能给吗这提醒我们AI应用必须继承使用者的数据权限而不能拥有超越其主人的特权。技术上实现方式是让WorkMate在每次查询前先获取当前用户的权限上下文并在检索结果阶段做行级过滤。用户没有权限触达的数据在向量召回前就被过滤掉模型根本看不到。这比“先查出结果再判断能否返回”要安全得多因为后者无法防止模型通过推理反推出敏感信息片段。这个机制也意味着不同角色看到的WorkMate界面和回答范围是不同的。采购员能看到供应商交期和配合度评价但看不到财务付款条款财务专员能看到账款数据但看不到运输路线成本明细。把权限嵌进AI访问链路后业务部门对WorkMate的接受度明显提高因为大家不用担心自己的数据通过AI被其他岗位套出来。4.4 一次真实协同场景从异常发现到处置完成的完整链路为了让读者更直观理解人机协同的运转我描述一次真实事件。某天上午十点WorkMate扫描到一条异常供应商“KJ精密”的一张PO单已过交期两天但SRM系统里没有发货通知TMS也没有相应在途记录。它随即把该PO关联的物料、最近一次收货记录、历史准时交付率一起拉出来发现该物料库存只能支撑三天生产。WorkMate将该事件标记为“高风险”推送到采购员李工的任务列表并附上一封已生成的催货函草稿和一份替代供应商名单。李工点开任务两分钟内确认了催货函内容点击提交按钮。系统自动发送给供应商并抄送了计划部和仓库。同一天下午供应商回复说原材料到厂延迟预计推迟五天。这个回复经邮件系统被WorkMate捕获它更新了事件状态并给计划员推送了一条建议关注该物料对应产线的排产计划是否需调整。整个过程中WorkMate前后做了信息收集、催促、跟踪、通知四项工作但最终“是否发函、是否调整排产”这两个决策节点都是人在操作。业务部门对这个模式的评价是AI做掉了最耗时间的擦桌子工作把精力留给真正需要经验判断的环节。5. 上线半年后我处理过最典型的四类现场问题白皮书不只写怎么做成更该写哪些地方会出问题。WorkMate上线后的前半年我们实际上是在持续救火中迭代的。下面是四个最典型、最有代表性的问题。5.1 专业术语与同义词导致的检索失真第一类问题是供应商名称和业务术语的表述不统一。WorkMate在处理“东莞金田纸业有限公司”和“金田纸业东莞厂”时常把它们当作两个实体导致库存汇总、交期分析出现数据分裂。我们用统一术语词典加实体别名表解决但这件事没有终局——每次接入新的供应商或客户都要评审一遍别名表是否覆盖。后来我们形成了一条规范凡是进入WorkMate知识库的文档在切块前先过一遍“术语标准化”预处理把同义表达替换成企业标准词。这一步看起来不起眼但它决定了后续检索质量的上限。5.2 文档切块切断语义供应链场景里有大量表格型文档比如供应商对账单、物流报价单、质检报告。早期我们把PDF按固定长度切块结果经常出现把一个报价项目的起始行和金额行切到两个块里RAG检索时只召回前半段模型看到的数据不完整给出的分析自然不准。调整策略是“先结构解析再切分”。先识别PDF里的表格边界、页眉页脚、标题层级把一张完成的表格或一个完整的条款作为最小切块单位。块与块之间有交叉引用关系时保留“上一块/下一块”的元数据让模型在需要时可以循着关系找到完整上下文。这个调整之后合同审阅场景的回答完整度提升非常明显。5.3 知识库权限的穿透风险有段时间安全团队测试时发现一个低权限账号通过精心构造的追问有可能让模型拼接出知识库中某些未授权文档里的片段。问题出在RAG检索阶段没有做权限过滤导致敏感内容进入了模型上下文。我们修复方式是把权限过滤从“回答后过滤”改成“检索前过滤”。知识库每条数据都带有权限标签在向量检索时先按当前用户身份过滤可见范围再进行语义召回同时在提示词里明确要求如果信息不在给定资料内必须回答未知不能自行推断。上线半年后这类问题基本被堵住了但它提醒我AI应用的安全测试不能只测接口还要测检索链路和提示词组合的边界情况。5.4 业务人员对AI建议的信任重建初期有几名资深计划员非常抵触WorkMate原因是AI给过几次错误建议。比如把一张已经取消的订单当作正常订单来催货虽然我们很快修复了数据同步问题但信任损伤已经造成。后来我们调整了两个细节一是在WorkMate生成的每条建议后面都附带“数据更新时间与来源标签”让业务人员能自行核查二是对初筛置信度较低的判断WorkMate使用更谨慎的措辞例如“存在异常迹象建议人工复核”而不是“该订单已逾期”。语气上的调整看起来很虚但在重建信任方面效果显著。毕竟资深员工的抵触通常不是对技术本身而是对“AI用确定语气说出错误结论”的本能反感。6. 下一阶段重点把协同经验持续固化回WorkMateWorkMate走到今天已经不是一个单纯的“部署项目”它进入了一个持续运营状态。我在这个阶段最关注的是如何把业务人员在协同过程中产生的修正经验不断回灌到系统里形成正循环。具体做法是给WorkMate增加了一条“修正日志”链路。当业务人员修改了AI生成的内容——不管是改了措辞还是改了整个建议方向系统都会记录这次差异。项目组每周分析这些差异把它们分成两类一类是提示词或阈值问题直接调整规则另一类是知识库缺失问题比如业务人员补充了一个文档里没有的特殊条款我们就把它沉淀到知识库对应模块。这样做了一段时间后WorkMate输出的建议质量有了肉眼可见的提升。更重要的是业务团队开始把修正AI当成分内事而不是负担。他们意识到自己不是在帮技术部门“擦屁股”而是在把个人经验转化为组织能力。未来我们计划把WorkMate从单点事件处理向跨流程协同推进。供应链里的很多问题不是单一岗位造成的比如缺料可能是计划不准、采购不及时、物流延误三者叠加。要解决这类问题需要让WorkMate同时连接计划员、采购员和物流专员在多个角色之间传递信息并追踪闭环。多Agent之间的任务交接、冲突消解和权责认定会是比单点部署更复杂但也更有价值的下一道考题。回看WorkMate的部署之路我的核心体会可以浓缩成一句话AI在供应链里能不能产生价值不取决于模型能回答多难的问题而取决于你能不能讲清楚哪些事让机器直接做、哪些事只让机器准备好材料等人来做。部署是人机协同的开始而不是结束。