“兆企供应链管理AI应用白皮书二”这个系列走到第二篇其实就是一个分水岭。第一篇我们把问题定义得很清楚供应链管理场景下哪些环节适合上AI哪些环节上了也是白上。到了第二篇核心就两个字——落地。WorkMate的部署和人机协同听起来像是IT部门的事但真正跑过一遍的人会告诉你这中间有一大半功夫花在业务侧怎么让计划员敢把订单跟催交给AI怎么让采购经理愿意在异常升级时按下那个“人工接管”的按钮。这篇文章整理的就是我们自己在兆企供应链项目里部署WorkMate、设计人机协同机制的全过程。里面既有环境规划、组件选型、模型部署这类硬核操作也有让业务团队从“看热闹”到“真用起来”的软性设计。适合正在做工业AI应用落地、准备把大模型部署到企业内部、或者被“人机协同”这个口号搞得一头雾水的朋友参考。1. 项目整体设计与部署前的问题拆解1.1 WorkMate到底解决供应链里的什么问题WorkMate这个名字我们内部叫了很久的“数字同事”。它不是一个挂在网页上的聊天机器人而是一个嵌在供应链日常作业流里的AI应用。兆企是典型的多品种、小批量机械装备制造企业供应链部门每天要处理的事情非常杂需求计划滚动评审、采购订单交期确认、来料异常处理、库存水位调整、供应商绩效跟踪。过去这些事靠什么靠有经验的计划员和采购员在Excel、邮件、ERP、微信之间来回切换。我们部署WorkMate的第一个目标不是让AI替代哪个岗位而是把那些“低认知密度、高重复频率”的作业节点接过去。比如采购订单发出后第二天系统自动去供应商协同平台抓确认回传情况超过48小时没确认的订单AI自动生成催办函并推送到对应采购员的工作台而不是等采购员自己想起来去查。这个动作过去是每天下午四点半的例行人工巡检现在变成了AI的定时任务。第二个目标才是辅助决策。需求计划评审会上计划员最头疼的就是“上个月预测偏差大不大、风险物料有哪些、替代料能不能顶上”。WorkMate通过检索企业内部的知识库和历史订单数据会先给出一份“计划评审前摘要”把物料的库存周转天数、安全库存余量、供应商历史准交率摆出来。这不算什么黑科技但胜在稳定、不遗漏、随时可以查。1.2 为什么选私有化部署而不是直接调云端API这个问题我们在项目论证阶段反复讨论过。兆企供应链数据涉及产品BOM、采购价格、客户订单属于制造企业核心经营数据。直接调用公有云大模型API即便签了保密协议业务部门心里的那道坎始终过不去合规部门更是明确表示数据出域需要走完整审批流程周期不可控。所以方向从一开始就锁定了私有化部署。另一个原因是WorkMate要深度对接企业内部多个系统。我们不是要做成一个独立应用让用户来“问”它而是要让它能主动读取WMS的库存表、调用ERP的采购订单接口、把处理结果写回协同平台。如果模型和应用都跑在云端这一层网络交互的延迟和稳定性就是不可控因素。把模型、知识库、应用编排全部放在企业内部网络至少在网络层面是干净的出了问题排查链路也短。部署的代价也直观得准备GPU服务器得有人维护推理服务模型版本要自己管理知识库的更新要自己处理。但对比数据安全和企业内部系统打通的便利性这个成本是值得的。实际算下来一套支持20-30人日常使用的私有化部署硬件投入在一个项目预算里占比并不高真正贵的是后面的人机协同流程设计。1.3 部署实施前必须完成的四件事第一件事梳理业务场景的“系统接触面”。WorkMate不是凭空生成的AI它需要数据支撑。每个场景对应哪些系统、哪些数据表、哪些字段必须提前列清楚。我们当时建了一张大的矩阵表左边是场景清单右边是该场景需要读取的系统和字段、输出动作、涉及的岗位角色。这张表后来成为知识库构建和Agent工具配置的直接依据。第二件事明确权限边界。WorkMate能看哪些数据、不能看哪些数据、能以谁的身份写操作记录这必须在部署前设计好。我们的原则是AI默认只有只读权限加“创建待办”权限凡是涉及修改价格、确认订单、释放工单这类写操作一律只能生成建议卡片由人类操作员一键执行。第三件事准备好知识库的初始语料。WorkMate要回答准确不能只靠大模型本身的通识能力必须灌入兆企自己的业务知识。我们把采购管理办法、供应商准入流程、安全库存策略文件、异常处理SOP等几十份文档做了清洗、切分、入库。这一步看着不起眼但直接决定了后面输出的质量。第四件事设定评估基线。部署完不能只演示“哇它能写周报了”要提前定义几个关键指标知识问答准确率、订单跟催覆盖率、异常识别召回率、人工接管率。有了基线后面调优才有方向不然就是公说公有理。2. WorkMate部署架构解析与核心组件选型2.1 一套完整部署架构包含哪几层WorkMate的部署架构参考了我们之前做工业AI应用的标准分层但针对供应链场景做了一些调整。整体分四层从下往上依次是模型推理层、AI应用编排层、知识库与数据服务层、业务接入层。模型推理层是整个系统最底层的算力基座负责运行大模型的推理服务。我们基于开源模型做了领域微调和部署具体来说用的是通义千问系列的中尺寸模型。选择这个模型没有太纠结主要是考虑到中文场景下供应链术语的理解能力以及MIT协议对商用部署足够友好社区资料也是中文为主团队排查问题会顺手很多。AI应用编排层是WorkMate的大脑中枢。它负责把用户的自然语言指令解析成内部任务决定调用哪个知识库、触发哪个工具接口。这一层我们选择了成熟的Agent编排框架理由很简单供应链场景的流程并不简单一个“催货”动作背后可能是查订单、发消息、更新看板、通知采购员四个连贯步骤用编排框架可以定义出稳定的DAG流程而不是指望大模型每次现场发挥。要是每次让模型自由发挥工人师傅反馈的可能是“昨天还能催货今天它开始给我写诗了”。知识库与数据服务层解决的事实一致性问题。供应链管理容不得模型自由发挥——安全库存多少天、供应商准入条件是什么这些都是标准答案。我们在这层采用了RAG架构把公司知识文档向量化再结合读取出来的实时数据表组装成上下文让模型生成回答。这一举动在采购场景里尤其重要我后面会展开讲。业务接入层则承担了将WorkMate的回复变成可执行动作的任务。钉钉工作通知、ERP的待办中心、Web工作台、自动邮件都通过这层接入。最核心的设计是“动作沙箱”——AI能触达的系统操作都通过统一网关这个网关会做三件事权限校验、数据脱敏、操作留痕。2.2 推理服务与模型部署的不同路径模型部署环节我们面临一个选择是走推理引擎路线还是直接上Ollama这类极简方案。说实话刚开始做PoC测试时我们用Ollama跑得非常爽一条命令模型就起来了API调用也简单。但等到真正要考虑多用户并发、需要动态加载LoRA适配不同供应链子任务时Ollama的调度和吞吐就不太够了。最终我们选用了vLLM作为推理引擎。原因只有两个一是它对高并发推理有优化通过PagedAttention机制减少显存浪费实测可以支撑的并发度比朴素方案翻了几倍二是它支持OpenAI兼容的API接口我们所有的Agent编排层代码可以直接复用不用做适配修改。部署形态上我们采用了Docker Compose编排把模型推理服务、向量数据库、Agent后端、前端工作台这四组服务用YAML文件定义好。有人可能会问为什么不用Kubernetes坦白说兆企这个体量的项目用K8s多少有点杀鸡用牛刀。Docker Compose足够把服务编排得清清楚楚运维人员学习成本也低。真要哪一天并发量上来了服务本身支持水平扩容再迁移到容器云也不迟。推理服务的显存规划一定要提前算好。我们部署了一个14B参数量级的模型开启BF16精度后权重占用约28GB加上KV Cache和输入输出序列单张A100 80GB的显卡可以稳定跑起来。如果项目预算有限团队内部测试环境其实也可以用两张24GB的消费级显卡做张量并行但单卡推理并发能力确实受限。这个账要算清楚是追求更低的部署门槛还是要为生产环境留出余量。2.3 知识库构建与技术选型中的核心判断知识库说白了就是一个把企业文档变成模型可检索信息的流水线。WorkMate在供应链场景里的回答质量一半取决于模型能力另一半就是这个知识库的精细程度。文档接入上我们建立了完整的信息处理流水线首先对PDF、Word源文档做解析保留表格层级信息。这一步有个容易踩的坑很多PDF里的表格区域如果按照普通文本切成向量片段后面的语义检索基本抓不到要点。机械行业物料编码规则、供应商等级评定标准这些机制性文本尤其依赖表格结构。我们的做法是先把表格区域单独提取出来转成Markdown格式后再切分。文本切分策略也对效果影响很大如果固定按512字切那么一段讲“ABC分类管理”的长文会被切成两段导致检索时只命中其中一半答案就残缺了。我们修改为按章节和段落语义边界进行切分最长不超过800词同时保留章节元信息这样向量检索的召回更准确。向量数据库方面初期对比了Milvus和更轻量的方案。对我们这个数据量级几十万份文档以内轻量方案完全够用运维也方便。我把社区的部署经验和团队自己的资源一结合最后选定了能支持私有化本地服务模式的实现既杜绝了数据外流又不给运维添负担。2.4 部署硬件的配置建议直接给出一套经过验证的配置参考。我们为一个30人规模使用的供应链管理团队配置了两台服务器一台作为模型推理节点一台作为应用和数据库节点。主力推理节点配置GPU采用A100 80GB或同级别产品目的是保留未来更换更大体积模型的余地CPU选用64核以上内存在256GB以上。实际跑起来会发现如果显存够大但CPU内存偏小遇到长文档语料上下文全部载入时内存会先顶不住。应用节点配置就亲民得多32核CPU搭配128GB内存运行Docker Compose服务及企业级固态硬盘存储。整套系统的网络环境要求简单千兆内网就能流畅跑前端请求到模型推理的RTT大约几十毫秒不会影响使用体验。但显卡驱动和CUDA版本必须一开始就固定下来否则后面部署推理框架时各种编译报错会让人崩溃。3. WorkMate实操部署全流程记录3.1 工欲善其事环境和基础依赖准备服务器系统我们选用了平稳的Ubuntu Server LTS版本。首先是基础依赖安装环节包括显卡驱动、CUDA、Docker和Docker Compose插件。每一步都有版本要求显卡驱动和CUDA版本强相关装错了就得推倒重来。我建议拿到服务器第一件事就是核对驱动和CUDA兼容矩阵不要想当然地下载最新版。库的层面我们通过Python虚拟环境管理创建独立环境安装vLLM及其依赖。整个安装过程大约20分钟如果服务器网络不佳建议先配好镜像源不然下载模型权重和依赖包会等到人发疯。3.2 Docker Compose服务编排与启动用Docker Compose编排服务的一大好处是每次重新部署可以保证整套环境一致性。我们的compose文件里定义了四个服务每个服务都设置了健康检查这样服务启动顺序就有保证了向量数据库最先启动其次模型推理服务等推理服务显示ready之后Agent编排后端才启动。实操中印象比较深的一个环节是GPU资源分配。Docker里使用GPU需要额外配置参数同时必须确认Docker的版本够新。启动时建议先不加载全部服务而是先把模型推理服务单独撑起来确认模型权重下载完整再用几条测试Prompt验证推理正常最后才启动其他服务。这样可以快速切分问题如果问答没反应大概率是模型层的问题如果回复正常但无法触发动作问题就在编排层。3.3 模型服务配置与Prompt适配模型正常启动后第一件事不是调Prompt而是把模型的基础参数固定下来。我们配置服务时设置较低的温度这个数字在供应链场景里非常关键——温度越低采样越确定输出也就越稳定适用于标准作业类任务。计划评审辅助可以调到0.2给一点生成多样性但订单跟催、库存预警这类任务就固定在0.1以下保证同样的问题每次回复基本一致。这一点务必提前想清楚如果一家公司所有场景都是一套默认参数一定会出现风格忽冷忽热的现象。Prompt适配是另一个需要精心打磨的工作。我们的做法是给每个场景设计独立的System Prompt把角色定位、输出格式、引用要求、禁止事项都说清楚。举个例子在“物料齐套分析”场景里的提示是你是供应链计划助理只能基于提供的物料清单和库存数据输出分析结论必须注明数据来源的时间点不得推测未来到货时间。如果一个AI应用给业务人员的建议里掺杂了模型自己的幻觉那离被弃用就不远了。3.4 供应链Agent的建立与工具调用WorkMate的核心不在问答本身而是它能以Agent方式调用工具、执行动作。供应链场景下我们把Agent能力拆成了三组查询类工具、推送类工具、生成类工具。查询类工具包括库存查询、订单状态查询、供应商档案查询。推送类工具就是把AI处理结果推送到钉钉群、推送待办到工作台。生成类工具则会根据数据模板生成催办函、缺料预警单等。这三组工具分别以API服务的方式封装注册到Agent编排框架里。以“订单交期风险分析”为例整个链路是业务员在WorkMate工作台上提问或系统定时触发WorkMate收到任务后先根据意图理解调用订单查询工具拿到PO清单和各自确认的交期再与生产计划需要的物料到货时间做比对把差异超过三天的标红最后生成一张风险清单推送到采购员工作台。整个过程涉及三次工具调用和一次结果生成如果工具调用不规范任何一个环节出错都可能把错误结论一路带到推送环节。3.5 知识库初始灌入与效果验收WorkMate的部署完成后我们安排了两次知识库灌入第一次是基础制度类包括采购管理流程、供应商考核评分规则、物料主数据管理规范第二次是业务模板类包括标准采购订单格式、异常反馈模板、周报月报格式要求。灌完知识库必须做一轮效果验收。我们基于真实业务场景编写了四十多组测试问答。问法上故意做了多样化处理有的直白如“安全库存低于多少会触发预警”有的绕弯如“我们采购的轴承座最近老是缺料帮我看看一般会用到哪些材料”。测试结果可以直观看到RAG对准确性的提升。不过也得说句公道话如果你问的问题在企业文档里根本没有答案RAG再强也救不了你该建的知识体系还是得老老实实建起来。4. 人机协同机制的设计与落地方法4.1 协同模式划分从辅助到自动化的三个层级我们把人机协同划分成了三个层级越往后的层级自动化程度越高风险控制要求也就越严格。第一层级是AI辅助Assisted。AI提供信息摘要、数据可视化和文本草稿但最终判断完全由人来做。用得最多的场景是需求计划评审前的数据准备——过去计划员要花一小时把库存、在途、预测偏差整理出来现在WorkMate自动生成摘要计划员只需要校对信息是否完整。第二层级是AI代理加人工确认In-Context。AI独立完成信息检索、方案生成但执行动作前必须要有一位有权限的人点击确认。物料齐套预警后的采购建议、库存周转异常后的调拨建议都归在这一类。所谓人机协同其实要的是在这一层真正形成持续的、高频率的互动。第三层级是AI告警加人工响应。AI像一个不知疲倦的哨兵负责持续监测大量的数据流只有出现异常才把人的注意力拉过来。到货异常、供应商协同平台长时间未回传确认、库存低于安全水位这类事件由AI主动触发告警。4.2 管理层设计的核心原则机器做判断题人做决策题很多项目做人机协同容易犯一个错误把AI当成了能做决策的机器。实际上当前的大模型更适合做复杂判断题而不是未经受控的价值决策题。比如“这张订单的交期承诺是否合理”是一道判断题决策题是“是否要为了这张订单调整生产线排程”。我们在流程设计上严格挂接了判断与决策。WorkMate的权限边界在物理上就被限制住只能识别异常不能改变BOM结构只能建议调整采购数量不能直接在ERP中改订单。这套设计不仅是为了避免风险也是为了让业务人员逐步建立对AI的信任——他们知道自己始终保留了最终的决定权所以更愿意试探性地用起来。4.3 上下游流程中的具体协同场景举例举个例子某条产品线因为客户需求波动某种控制器芯片的库存不足以支撑未来两周计划。WorkMate监测到库存低于安全水位后会自动做三件事第一查询该芯片的采购在途订单看看有没有快到货的批次第二依照供应商历史准交率判断这批次到货的可靠性第三整理出“现状描述、风险等级、建议动作”为格式的预警卡片推送到负责该物料的采购员工作台。采购员看到预警卡后如果信息足够齐全可以直接按“生成催办消息”按钮WorkMate会自动把催办文本发到供应商协同平台。如果采购员判断这个物料确实紧张需要联系备选供应商他可以点击“转人工处理”WorkMate随即把这一次转接的原因和上下文记录打包给采购经理。这个流程里AI提供了基础的监控和信息服务但关键动作的决策权和执行权都在人类控制下。4.4 让业务人员从抗拒到主动用起来的运营方法技术部署只是第一步长期的成功要看业务人员的接受度。在这个项目中我们意识到有几个软性动作至关重要。全面上线前先找了几位资深计划员做“种子用户”一起打磨界面提示语和报告格式。通过访谈确定了业务人员的独特习惯比如他们总习惯先看一眼图片类汇总再去看明细数据于是让WorkMate生成表格统计的同时配上一份可视化摘要。如果直接从技术团队视角设计界面通常是相反的顺次——先列明细然后再给汇总业务上的体验就会不好。冷启动阶段不要追求高自动化率。第一个月我们把目标定为“AI必须给出依据人决定是否采纳”每个采纳动作都被记录在系统日志里。月底复盘时发现订单跟催场景的人工采纳率从最初两天的不到三成提升到了两周后的七成。能在一个月内实现这个水平靠的是每次答疑都给出了详实的知识库依据和数据来源业务人员能核实才敢放心采纳。4.5 信息透明和置信度机制的设计教训做协同机制设计时最容易被忽略的是置信度表达。人类面对一个AI建议时的第一反应往往是“它凭什么这么说”。为此WorkMate输出的每条建议都附带两个信息一是知识库依据来源标明这句话是根据哪份文档的哪个条款得到的二是数据证据链列出影响这个结论的关键数据记录。如果输入信息不足以支撑一个结论WorkMate会直接告知“缺少XX数据无法判断建议人工核查”不会硬生成一个看似通顺的答案。把“不知道”和“不确定”交给人类决策者这是人机协同最宝贵的机制之一。大量AI系统承诺过多导致“狼来了”效应最后业务人员连AI给出的有效判断都不信任了。宁可让AI承认自己判断不了也要确保它说出的每条结论经得起人工核查。5. 常见问题与排查技巧实录5.1 部署类问题推理服务崩溃与显存不足被问到最多的问题大概率是系统跑了一阵子后推理服务突然崩了日志显示CUDA out of memory。检查后发现往往是并发请求处理时KV Cache的预留空间不够多路问答同时涌入就直接打爆了显存。这个问题分三个层次解决。第一层在推理服务启动参数里主动设置max-model-len限制单次对话处理的上下文长度不能放任模型无限吃显存。第二层在接入层做并发控制配置最大并发数和排队策略。第三层升级到支持continuous batching的推理框架优化版本让服务端动态调度请求取代过去“来一个请求就占一整块显存”的做法。5.2 模型输出质量问题供应链数据的幻觉与不精准大模型在供应链专用术语上的知识是有局限性的如果没有企业知识库支撑很容易生成一本正经的废话。比如当问“XXX物料当前库存可用几天”时如果模型只是靠通用知识硬编一个算法就等于什么都没说。答案必须基于真实的库存表字段和计划数据计算而不是看起来正确的数据。我们为此专门设计了强制字段校验机制在处理库存类问题时答案中涉及库存数量、可用天数的必须在生成后由后端来校验数据源是否存在且格式正确。如果缺少上下文就需要发起二次工具查询并重新生成回答。这一轮轮的校验拦截是保证AI从“能说”迈入“能用”的关键门槛。5.3 人机协同中的“AI提出了正确建议但被忽略”问题系统上线中期实际出现过这样的案例WorkMate连续一周提示某物料供应商交期异常率偏高建议提前寻找替代供应商。但负责的采购员没有及时响应因为在他们的工作习惯里系统提醒等同于过去的“邮件通知”默认可以等等再处理。这个问题不能靠技术来解决要靠协同机制完善。我们增加了“三日未响应自动升级”的机制预警在某个人待办里停留超过48小时未处理系统会自动升级给采购经理如果再超过48小时就自动升级给供应链总监。压力报警机制启用后预警响应的时效从平均两天缩短到几十秒到数小时的范围。业务人员意识到系统提醒是有时限要求、不可忽略的任务态度就完全不同了。5.4 知识库更新与模型效果退化问题部署完成后知识库并不是一成不变的。当企业调整安全库存策略如果知识库没有同步更新WorkMate的依据就会和现实脱节。我们建立了双周更新机制由供应链部门指定专人收集最近两周新增或调整的管理制度、SOP文档提交给系统管理员做增量更新。增量更新过程中只需要重新对变化部分切片嵌入。一个特别容易踩坑的地方是文档中间某句话做了改动如果不做版本管理向量库里新旧内容混在一起那么召回时既可能命中旧版本也可能命中新版本回答自然混乱。所以要在文档入库前增加版本号校验将新版本文档标记为有效而旧版本标记为归档保证知识库内同一主题仅保留一个权威内容。6. 人机协同的运维机制与持续迭代经验6.1 建立持续的人机协作反馈闭环系统上线稳定后我们建立了“每周人机协作回顾会”业务方、IT、算法团队都会参加复盘本周的典型协同事件。会上只看三类数据所有被人工修正过的AI建议、人工拒绝采纳的原因分布、长期未被处理的预警和待办。这个复盘机制其实质量很高每一条被修正的建议都是模型效果的活体反馈样本比任何评测集合都真实。以前面的采购催办为例曾经有一段时间WorkMate生成催办消息的语气过于机械业务员要花不少时间修订语气后来干脆在知识库里加入了优秀催办话术模板引导模型模仿更柔和、更有礼貌的表达——毕竟供应链上大家是合作关系偶尔也要讲讲情面。这种细颗粒度的调优只有在一线使用者和算法团队之间建立了高效反馈通道后才能迅速推动。6.2 数据打标与定期评测用例集反馈闭环跑起来后我们建立了一套“人机协同事件库”每个月把人工修正过的AI回答分场景、分原因地打标入库。经过两个季度的积累形成了超过七百条典型修正样本。这批样本有两个作用一是用于后续模型的微调和Prompt优化二是会用之前积累的评测用例集来回归测试每次调整Prompt后都会先跑一遍五十多个核心场景的测试集确认旧能力没有被牺牲掉。关于任务回滚调整不总是成功的我们保留每个版本的Prompt和模型权重配置信息如果某些特定场景的回答反而变差了可以快速回滚。这套流程虽然朴素但在企业级AI应用里比所谓“上线就完了”的说法可靠得多。6.3 企业级AI应用后续迭代的可能性WorkMate在这个项目中取得了阶段性成果但距离完善的数字同事还有很长的路要走。展望后续的几个方向一是把模型从单点能力扩展为覆盖计划、采购、物流到供应商协同的全链路编排二是引入多模态能力来处理供应商送货单、质检单这类图片和信息混合的来源三是持续做领域微调让模型对企业专有名词的把握更精准。这个项目让人体会最深的是企业级AI应用的部署其实是一个“技术占三成、业务设计占七成”的工程。技术层面按部就班即可完成真正决定节点成败的还是协同流程是否让一线员工感到被赋能而非被取代。如果你也在做类似的企业内部AI应用部署项目我个人建议是不要急着追求“全自动”先花大力气把“AI给建议、人做决定、系统自动记录结果”的闭环跑顺。跑顺之后再谈逐步提升自动化率也不迟。这套朴素的路径在兆企的项目里被反复验证过大概率在你的场景下也适用。