最近被问得最多的问题就是供应链行业里的AI到底怎么落地。PPT上讲的“智能决策”“数字员工”听了一百遍真正敢把系统部署进生产环境、让一线员工天天用的少之又少。我们团队从去年下半年开始围绕“兆企供应链管理AI应用”做了一整套自研的AI工作台代号WorkMate。前一阵发布了白皮书的第一部分讲整体规划和技术选型这一篇正好接上专门聊聊WorkMate的部署全过程以及最核心的一环——人机协同机制是怎么设计和跑起来的。先说清楚这篇内容适合谁看。如果你所在的企业正在计划引入大模型但还没想清楚是买API还是本地部署如果你的系统已经接上了AI但业务部门反馈“就是个玩具、没什么用”或者你只是对供应链场景下的AI应用开发感兴趣想看看一个真实项目是怎么从环境搭建走到上线运营的——这篇文章都值得你花十几分钟读完。里面没有空话都是我们踩过的坑、验证过的做法和可以直接抄走的设计思路。1. 部署前先把协同模式想清楚1.1 我们为什么在供应链场景里做AI落地供应链管理这个领域很多人第一反应是“不就是管仓库、管运输、管订单吗”但实际上它是一个高度依赖数据协同和经验判断的复杂系统。订单、库存、采购、物流、财务任何一个环节的数据错位都可能引发连锁反应。传统信息化系统解决的是“流程线上化”但流程走完还是得靠人看报表、做判断、打电话催、发邮件协调。我们做WorkMate的初衷就是把这些“靠人看、靠人催、靠人协调”的环节逐步交给AI来处理。它不是给你生成一份报告就完了而是要能看懂一张订单有没有异常要能从历史数据里发现某个SKU的补货建议要能在供应商交期延误时自动触发预警并且把整个处理过程同步给对应的人。所以WorkMate从一开始就不是一个“会聊天的机器人”而是一个嵌入到业务执行链路里的AI处理引擎。这个定位决定了后面所有的部署决策。因为要处理真实业务数据就不能只靠云端API调一调因为要跟现有ERP、WMS、OMS系统对接就必须考虑内网环境、数据隔离和权限控制因为要给一线员工用就不能设计成技术人员的命令行工具必须有人机协同的任务流转界面。这些约束条件基本决定了我们要走一条“混合部署 以人为本的协同流程”的路线。1.2 混合部署的选型逻辑关于大模型的部署方式市面上无非三种全云端API、全本地私有化、混合部署。供应链企业普遍对数据敏感尤其是订单信息、客户资料、成本数据这些不可能随便发到外部API。但全本地私有化也有代价GPU资源投入大、运维复杂、模型更新慢。我们最后选择的是混合部署核心逻辑是“数据分级 算力分级”。简单说涉及客户隐私和生产核心数据的推理全部走本地模型数据不出内网涉及行业通用知识问答、日常办公辅助、非敏感文本处理可以走云端大模型API省下本地算力。这个策略在架构上不难实现难的是要有一个统一的模型网关把不同的请求自动路由到不同后端。WorkMate的系统里这个网关层承担了模型路由、密钥管理、调用日志、限流降级所有职责是整个系统里最重要的基础设施之一。为什么强调这一点因为很多团队一开始图省事全用云端API等业务部门要求接内部数据时发现链路根本通不了又回过头改造。我们有个经验哪怕你初期算力不足架构上也一定预留本地推理的接口不然数据合规这一关就过不去。这个决策越早做后期返工越少。1.3 系统整体架构WorkMate的整体架构可以分成四层。最底层是数据层接的是企业内部ERP、WMS、TMS、财务系统通过定时同步和消息队列把业务数据汇总到统一的数据仓库。这一层不直接面向模型而是为上面提供干净、可查询、带权限标记的数据。第二层是模型层包含本地部署的基础大模型、向量化模型和Embedding模型以及可选的云端模型接入。本地模型负责业务推理和敏感数据处理向量模型负责把文档、知识库、历史工单转成向量供检索使用。第三层是应用层这是WorkMate真正干活的层。它里面跑着若干个智能体比如订单异常识别智能体、库存优化智能体、供应商协同智能体每个智能体通过工作流引擎编排任务调模型、查数据、生成结论并把结果推送到人机协同界面。第四层是交互层包括Web端的工作台、企业微信/钉钉的消息推送、移动端审批界面。这个设计的好处是业务人员不需要懂任何技术他们看到的就是“有一次异常需要确认”“有一条补货建议待审批”。部署WorkMate不是把模型文件拉下来跑起来就完事的真正的功夫在数据打通、协同流程配置和权限体系设计上。这也是这篇白皮书第二部分要先讲部署、再讲人机协同的原因——没有一套稳的底座协同流程再漂亮也是空中楼阁。2. WorkMate的部署实操全记录2.1 基础环境与硬件配置先交代一下我们实际的部署环境。我们用的是内网机房加私有云混合的形态核心业务系统全部在内网WorkMate的应用服务和模型推理服务也部署在内网的Kubernetes集群上。Kubernetes的好处是方便横向扩容模型推理服务压力大了可以加节点业务应用可以滚动更新而不中断。硬件方面模型推理服务使用了两张NVIDIA A10 GPU24GB显存跑7B到14B参数量级的模型刚刚够用。如果你们计划部署70B以上的大模型建议直接上A100或者H800级别的卡。内存方面每个推理节点配了128GB主要是给向量检索和模型缓存用。存储用的SSD建议至少1TB起步因为模型文件、向量数据库、日志加起来非常占空间。操作系统和容器环境我们统一用的Ubuntu 22.04 Docker Kubernetes。如果你公司规模不大不想一上来就上K8s用Docker Compose先顶一两个月也完全可以WorkMate的应用层组件都做了容器化迁移到K8s只是配置文件的事。2.2 底层大模型的本地化部署本地模型部署这一步网上教程很多但真正要用在生产环境有几个细节一定要处理好。模型选择上我们最终用的是Qwen2.5-14B-Instruct的量化版本4bit量化后显存占用大约10GB留了充分余量给并发推理和上下文窗口。有人问为什么不用更大的模型我们实测下来在供应链这个垂直领域业务效果差距没有想象中大但推理速度和显存开销差距是实实在在的。配合一套好的提示词和知识库检索14B模型完全能Hold住业务。部署工具用的vLLM这个框架服务的吞吐量比原生transformers高很多支持continuous batching高并发下不会一个个排队等死。启动命令大致如下vllm serve Qwen/Qwen2.5-14B-Instruct-AWQ \ --host 0.0.0.0 \ --port 8001 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --served-model-name workmate-base注意几个参数max-model-len设成8192是因为供应链业务里要处理长订单、历史记录拼接太短的上下文装不下gpu-memory-utilization设0.9是给推理过程留出KV cache的空间设太满会触发显存溢出。模型启动后一定要压测。用vllm/benchmarks/benchmark_serving.py脚本发几轮请求测一下并发32时的TPOT单token生成时间和TTFT首token延迟这两个数值直接决定用户体感。我们的经验是TTFT控制在2秒以内、TPOT控制在80毫秒以内业务方基本不会再抱怨“卡”。如果公司没有GPU只有纯CPU服务器也不是完全不能跑但要接受推理速度慢一个数量级的事实。个人建议直接上云端API别在CPU上死磕这个账怎么算都不划算。2.3 应用层部署与配置模型层跑起来之后接着部署WorkMate应用层。这部分是一个标准的微服务集群我用Docker Compose演示一下核心服务组成方便你对照自己的环境调整services: gateway: image: workmate/gateway:2.1.0 ports: [8080:8080] environment: MODEL_ROUTE_JSON: /etc/workmate/model_route.json agent-orchestrator: image: workmate/agent-orchestrator:2.1.0 depends_on: [gateway, vector-db, redis] vector-db: image: milvusdb/milvus:2.4.1 redis: image: redis:7-alpine web-console: image: workmate/web-console:2.1.0 ports: [3000:3000]网关的模型路由配置是整个部署里最核心的配置项决定哪些请求走本地、哪些走云端。我们实际用的是一个JSON文件长这样{ routes: [ { name: internal-data-inference, description: 涉及内部业务数据的推理, backend: http://vllm-server:8001/v1, match_rules: [order, inventory, supplier] }, { name: cloud-general, backend: https://api.example-cloud.com/v1, api_key_env: CLOUD_API_KEY, match_rules: [general, summary, knowledge] } ] }实际匹配逻辑不只看关键词还叠加了用户权限和数据等级判断但原理就是这个。应用层部署完成后先用测试集跑一遍端到端的流程确认一个订单从进来到AI分析完成推送到界面整个链路是通的再做数据接入。2.4 数据接入与权限体系构建数据接入是部署阶段最耗时、也最容易翻车的一个环节。供应链业务系统五花八门接口协议不统一历史数据质量参差不齐这些问题不会因为部署了AI就自动消失。我们的做法是先用ETL工具从各个业务系统同步原始数据到数据仓库然后对数据做清洗和标准化比如统一SKU编码、修正缺失的供应商信息、规范时间格式等。完成之后按业务域生成数据集订单数据集、库存数据集、物流数据集、供应商数据集这些数据集对应不同的权限标签。权限体系是很多人会忽略的部分。WorkMate设计了一个“数据权限双向过滤”机制一方面用户在界面上只能看到自己权限范围内的数据另一方面用户问题发送到模型之前系统会根据用户的角色和权限自动剪裁上下文把无权访问的数据片段剔除掉。这个机制保证了即使模型有很强的推理能力也无法“看到”它不应该看到的内容。为什么这个设计重要因为供应链数据里藏着非常敏感的商业信息比如核心客户价格、渠道政策、未公开的促销计划等。如果权限只卡在界面展示层模型内部依然能用这些数据做推理一旦模型输出被截图外传就是合规事故。双向过滤机制把这一层风险兜住了。3. 人机协同机制从“AI助手”到“数字员工”3.1 协同模式设计的三个原则WorkMate部署完成只是第一步真正让它产生业务价值的是人机协同机制。我们设计协同机制的时候定了三个原则。第一个原则是“AI负责建议人负责决策”。AI可以把订单异常识别出来、把补货建议算出来、把风险等级标出来但所有涉及资金、承诺、对外沟通的环节必须有人最终确认。这既是对业务负责也是一种风险控制。AI的推理再强也无法为结果承担法律责任。第二个原则是“所有AI动作可回溯”。AI每一次识别的依据、使用的数据、给出的建议置信度都必须记录在案。这样业务人员处理AI推送的任务时点开详情就能看到“为什么AI认为这是一个异常”而不是面对一个结果搞不清来龙去脉。第三个原则是“异常必有人处理绝不能静默”。AI发现问题后推给人人如果没处理系统要自动升级提醒直到有人接手为止。这跟工业界的“故障闭环管理”是一个逻辑AI可以把问题发现效率提高但问题的最终关闭必须由人来完成。3.2 一个订单异常识别的完整协同流程拿最常见的场景举例订单异常识别与处理。客户下单后WorkMate的订单智能体会自动检查这张订单的多个维度客户历史下单频率是否正常、商品组合是否符合常规、收货地址是不是首次出现的新地址、折扣率有没有超出授权范围、当前库存是否足够满足交期。任何一个维度异常智能体会打一个风险标签综合风险超过阈值就会生成一条“订单异常待确认”任务推送到负责该客户的业务员工作台。业务员打开任务后能看到AI的分析结论和依据比如“该客户历史平均单笔金额8万元本次订单金额35万元超出3倍标准差客户首次下单时区为凌晨4点且要求发货到非主营区域地址”。AI会给出建议“建议联系客户核实需求真实性已自动触发二次验证流程”。业务员如果觉得没问题点“确认”任务关闭AI把这个反馈记入学习样本如果觉得可疑点“拒绝”订单被拦截转入人工审核通道。这个流程跑通之后业务员的日常工作发生了明显变化以前每天花两三个小时翻订单、对账、查异常、打电话现在变成了花半小时处理AI推送过来的十几二十条异常任务而且每一条都有分析背景不用再从零查起。异常订单的发现率反而比纯人工更高因为有AI实时盯着不再依赖人眼疲劳扫单。3.3 任务分级与自动升级机制不是所有任务都需要立即处理所以WorkMate设计了一套任务分级机制。按影响程度和紧急程度任务分成三个等级普通、重要、紧急。普通任务比如某个SKU的库存低于安全线但到货时间在计划内AI生成补货建议推送到工作台业务员当天处理即可。重要任务比如核心供应商延期交付且影响客户订单交期系统不仅要推送任务还会自动发企业微信消息给对应采购负责人和计划员。紧急任务比如一张大额订单同时触发多个风险规则AI会直接打电话提醒通过语音通知网关确保短时间内有人响应。如果任务推送之后2小时没人认领系统自动在协同群里提醒4小时还没处理升级到部门主管8小时仍未闭环生成异常报告抄送运营总监。这个升级机制一开始业务方觉得“太激进了”但实际跑下来发现真正会升级到主管的任务非常少反而是因为有了这套机制大家的处理响应速度明显提升。这里有一个设计细节值得每个做AI应用的人借鉴给AI推送的每一条任务加上“处理时效”和“升级路径”让AI从被动的“推送者”变成一个主动的“协同推进者”。很多AI应用demo做得很炫但用户用完就忘了就是因为没有给任务施加“必须闭环”的压力。3.4 反馈学习闭环让AI越用越准人机协同不光是“人干活、AI帮忙”更重要的一个维度是AI从人的决策中持续学习。WorkMate设计了两个学习回路。第一个是显式反馈回路业务员在处理AI建议时可以选择“采纳”“驳回”“修改”。所有反馈数据会回到样本池定期用来微调或优化提示词。比如有段时间AI对“新客户首次大额订单”的风险判断经常误报业务员驳回率特别高。我们分析反馈数据后发现是因为模型对“新客户”的定义理解有偏差——它把最近6个月没有订单的休眠客户也算作新客户。修正样本数据后误报率明显下降。第二个是隐式反馈回路系统会通过埋点记录业务员处理任务时的操作路径。比如业务员处理库存预警任务时总是先打开供应商交期页面、再打开安全库存报表系统就能学习到这个“处理习惯”在后续推送的任务详情页里自动把这两个信息放到最前面减少操作步骤。这个机制我们内部叫“工作记忆”它让每个业务员用到的WorkMate界面都是个性化的。当然这里有一个底线必须守住无论怎么学习优化都不能让AI自动执行资金支付、承诺交期、修改价格这类不可逆操作。人类必须始终保留最终控制权。4. 部署和协同中的常见问题实录4.1 模型部署好了但输出内容总是“答非所问”这是很多人第一次部署本地模型时遇到最多的问题。检查下来原因通常是三个。一是系统提示词没写好模型不知道自己的角色和任务边界。二是RAG检索出来的上下文噪声太大模型被无关信息带偏了。三是用户问题本身表述模糊。我们的解法是把系统提示词当成一个严谨的“岗位说明书”来写明确告诉模型“你是供应链订单分析助手你的任务是识别订单异常输出必须附带数据依据不确定时明确说不确定”。同时优化RAG的检索策略加入rerank环节让最相关的文档片段排到最前面。这一步解决了大部分“答非所问”的问题。另外一个技巧是给模型提供少量示例few-shot examples从历史数据里挑几个典型的订单异常案例写进提示词里。这个做法的提升效果立竿见影但要注意别把提示词撑得太长不然模型容易“忘记”后面的内容。4.2 并发一上来推理速度就断崖式下跌用vLLM部署的模型并发16时响应还很快一到并发32以上延迟就爆炸。这个问题排查下来大部分原因是显存不够导致KV cache频繁换入换出或者max-model-len设置的上下文太长实际请求可能只有几百token但系统预留了8192 token的缓存空间。解决方案有两个方向一个是加显存或换更大显存的卡另一个更经济是把max-model-len按业务实际需求降下来比如我们的订单分析任务里上下文很少超过4096那就直接改小。还可以配合vLLM的--max-num-seqs参数限制一个batch最大并发序列数避免短时高并发打爆显存。还有一次我们发现应用层和推理服务的连接用的是HTTP同步请求推理服务一忙应用层线程池就耗尽导致新的任务进不来。后来改成异步调用加队列缓冲压力瞬间小了很多。这类问题如果不用压测工具提前测生产环境是要吃苦头的。4.3 知识库检索出来的内容带着不该有的权限信息我们在测试阶段就发现一个业务员提问时RAG检索出来的知识库里包含了其他部门的敏感文档片段。虽然界面没有直接展示但模型推理时已经用了这些片段存在信息泄露风险。解决方案就是前面提到的“数据权限双向过滤”。只让检索器返回用户权限范围内的内容还不够还要在送入模型之前再做一次清洗把不含权限标记的字段也统一检查一遍。我们开发了一个轻量级的脱敏服务所有送进模型的文本都会经过这个服务自动识别和脱敏手机号、邮箱、身份证、内部价格等敏感信息。这一步做完合规风险基本可控。4.4 业务员就是不用说“不如我自己看”这个问题比技术问题更难解决。一开始我们花了很多精力优化模型效果但业务员反馈还是“不好用”。后来我们做了几轮用户访谈才明白问题不在AI分析能力而在交互方式。业务员习惯了原来的系统界面觉得“多开一个WorkMate很麻烦”。为此我们把WorkMate的入口直接做进了原有的业务系统里点击订单详情页旁边就有AI分析面板不用来回切换。另外我们把AI推送的任务跟业务流程绑定不在工作台里“另起炉灶”而是直接嵌入到原有的订单审核流、采购审批流里。这个改动上线之后使用率立刻翻了一倍多。这件事给我最大的教训是AI应用能不能落地关键在于它能不能融入用户现有的工作流而不是让用户去适应一个新的“AI系统”。人机协同的最高境界是“AI在后台默默工作人在前台只看到更顺畅的业务流”。最后分享一个我的体会WorkMate从部署到平稳运行中间踩过的坑远比这篇文章写的多。如果你问我什么最重要我的答案不是模型选型不是GPU配置也不是RAG调优而是“人机协同流程的设计”。技术层的部署再复杂都有成熟的方法论和工具可以学。难的是如何让AI输出与人的经验判断形成互补如何让业务人员真正信任AI的建议。我个人在项目里体会最深的一句话是AI应用的边界从来不是模型能力决定的而是协同流程设计决定的。你在流程里给AI多大的决策权、给人多大的控制权设计清楚并落地应用才算真正“部署”成功。后面我们还会继续更新白皮书的后续部分讲讲WorkMate在库存优化和智能补货场景里的实际效果到时候再跟大家细聊。