兆企供应链管理AI应用白皮书二WorkMate的部署与人机协同身边不少做供应链的朋友这段时间都在聊同一个东西AI Agent到底能不能在真实的采购、库存、物流协同场景里落地而不是停留在“演示很惊艳用起来鸡肋”的阶段。我自己的答案很明确能但前提是选对工具并且把部署和人机协同机制想清楚。这次要拆的WorkMate就是我在兆企供应链AI应用实践里踩完坑之后觉得值得拿出来聊透的一个方案。先交代背景兆企供应链的业务链条覆盖采购协同、仓储调度、运输跟踪、供应商考核等好几个大块过去靠传统Excel加邮件加微信群的方式信息延迟严重跟单员一天大半时间都耗在“问一遍、查一遍、再手工更新一遍”上。我们引入WorkMate目标不是做一个聊天机器人摆在角落而是让它成为跟单、计划、仓管这些角色真正能“交办任务”的数字同事。这套东西解决的核心问题是把过去散落在各处的单据核验、异常提醒、跨部门跟进动作变成可编排、可追踪、可干预的人机协同流程。我自己跑完整个部署闭环后的感受是WorkMate的定位更像一个“会调用工具、懂业务上下文、能被人随时接管”的工作代理而不是一个单纯的问答模型。所以你在部署它之前最该想清楚的不是模型参数有多大而是你要让它代替人做哪几类判断哪些动作必须留给人来拍板。这个想清楚了后面的架构选型、权限设计、流程编排都有了解题主线。1. 为什么供应链场景先聊“部署”而不是“算法”很多团队一上来就盯着模型效果总想找个“更聪明”的大模型来解决所有问题。但供应链业务跟写文案、聊天不太一样它讲究确定性、时效性和责任边界。供应商没按时发货、仓库库存账实不符、物流在途异常这些场景里你要的不是模型“发挥创意”而是按规则识别、按流程通知、按权限处理。所以在兆企的实际落地里我们把大部分精力放在了三件事上模型怎么稳定跑起来、外部系统怎么接进来、异常发生时人怎么快速接管。1.1 WorkMate定位人机协同里的“执行层”如果说大模型是负责思考的“大脑”那WorkMate更像长在大脑外面的“手和脚”。它负责把大模型给出的意图转化成实际动作比如查库存、生成采购建议、发预警通知、更新订单状态。这套分工在供应链场景里特别重要因为业务系统不会直接暴露给普通人操作更不能让模型随意写库。WorkMate充当了一个带权限、带审计、可回滚的代理层所有动作都在它的框架内执行。我见过不少团队盲目把模型接入企业微信就开始让人对话结果模型一本正经地给出了一个错误的库存数字或者直接“帮”用户把订单状态改掉了非常危险。WorkMate的思路是模型只负责理解需求并生成结构化意图真正的查询、写入、通知动作都要通过可配置的工具节点完成。这样从根上避免了模型幻觉直接污染业务数据。从使用角色看WorkMate适合四类人跟单员日常催单、异常上报、计划员补货建议、交期确认、仓管员库存查询、盘点差异跟进、运营管理者看板汇总、审批监控。部署时如果只让IT一个人玩后面很容易变成玩具让业务骨干参与定义“哪些任务可以交给机器、哪些必须人确认”部署完才是真正能用的起点。1.2 部署前的架构选型本地模型还是云端API我们在兆企内部评估过两条技术路线直接调用公有云大模型API或者本地化部署开源模型。公有云API胜在效果稳定、上线快但供应链数据涉及供应商价格、客户信息、库存细节直接出公网多少有些心理负担而且断网或者限流时业务会卡壳。本地化部署则把数据留在内网问题反馈闭环更可控但需要准备GPU或高配CPU节点还要有人维护推理服务。WorkMate的设计本身并没有把这两条路堵死它既支持对接本地Ollama、vLLM这类推理框架也支持走OpenAI兼容接口。我们最终选择的是本地化部署开源模型作为主链路然后把公有云API作为备胎。这样做的好处是日常大部分查询、汇总、提醒类任务用本地模型已经够用遇到知识密集型任务时再临时走云端接口成本和响应速度之间取得了平衡。另外部署形态上我们用Docker Compose做了一键编排包含WorkMate主服务、PostgreSQL数据库、Redis缓存、向量库、推理服务几个容器。为什么不用裸二进制直接跑因为供应链环境经常要测试新版本容器化之后升级、回滚、迁移都会轻松很多。这个选择在实际运维中帮了大忙后面遇到模型更新、配置调整时基本不用折腾宿主机环境。2. WorkMate部署实操从零到能干活2.1 环境准备清单先说硬件。我们是先在一台物理服务器上跑的配置大致是32核CPU、128GB内存、一张RTX 409024GB显存操作系统Ubuntu 22.04磁盘单独挂了一块2TB SSD。如果团队预算紧张没有独立显卡也可以先用CPU跑量化后的小模型试试但响应速度会比较慢我这里建议至少16核64GB内存起步否则人机协同的“实时感”会大打折扣。软件层面需要提前装好这些东西Docker和Docker Compose插件我用的是Docker 24.0Python 3.10以上部分工具脚本需要Git拉取WorkMate仓库和模型文件建议在干净的宿主机上操作不要在Windows上直接跑生产环境。我们内部也有人用WSL2做过测试能跑通但涉及GPU透传和端口映射时比较折腾生产还是建议Linux。2.2 模型底座部署Ollama还是vLLMWorkMate本身不携带模型它需要对接一个推理服务。我们在测试阶段最早用的是Ollama因为安装简单、命令友好适合快速验证。比如下载一个Qwen2.5-7B的量化版在Ollama里一条命令就能跑起来ollama pull qwen2.5:7b ollama run qwen2.5:7b不过跑了一阵子发现Ollama在处理并发请求时排队比较明显。供应链这类场景经常是早上一上班多个用户同时提问单个请求回答十几秒还可以接受但排队导致每个人都等半分钟就太影响体验了。后来我们把主力推理切到了vLLM。vLLM的优势在于连续批处理和高吞吐官方文档里说能用PagedAttention优化显存占用我们实测同一个7B模型并发从两三个提升到十几个每token延迟反而更稳定。vLLM部署也不复杂拉镜像起服务就行我用的是OpenAI兼容模式这样WorkMate侧配置base_url指向vLLM地址就行。核心命令大致如下docker run --runtime nvidia --gpus all \ -v /models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/qwen2.5-7b-instruct \ --served-model-name workmate-base \ --port 8000这里需要注意如果你是NVIDIA GPU环境记得提前装好NVIDIA Container Toolkit否则Docker容器里识别不到显卡。另外模型文件路径要挂载进容器vLLM才能读到权重。切到vLLM之后单请求延迟反而比Ollama略高一点点但整体吞吐好很多多人同时用不“打架”。2.3 WorkMate服务安装与配置拿到WorkMate的部署包后核心操作其实是改配置。我们先打开docker-compose.yml文件里面会定义一个个服务。你需要重点改这几项模型接口地址指向刚才的vLLM或Ollama数据库连接串Redis连接串向量库路径管理员账号初始密码我个人习惯先把所有配置项从代码里拆出来放到独立的.env文件里这样后面调整不用翻源码。比如LLM_BASE_URLhttp://vllm:8000/v1 LLM_API_KEYdummy-key DB_HOSTpostgres DB_PORT5432 DB_NAMEworkmate DB_USERworkmate DB_PASSWORDchange-me REDIS_HOSTredis REDIS_PORT6379 VECTOR_STORE_PATH/data/vectors ADMIN_PASSWORDchange-me-strong然后执行docker compose up -d第一次启动要做的事情比较多包括初始化数据库表、建向量索引、拉取默认技能包Skill Pack。建议先看日志确认没有报错再进后台初始化管理员账号。这里有个容易踩的坑如果你改了.env里的端口映射记得确认宿主机防火墙和云安全组放行了对应该端口否则外部浏览器始终打不开后台。2.4 连接业务系统与验证服务跑起来只是第一步。WorkMate要真正干活还必须把业务系统的数据接进来。兆企这边我们接了三个源企业内部的ERP只读视图通过一个只读账号、仓储WMS的API、还有订单追踪Excel后面改成了数据库同步。实际用的方式是提供一个统一的数据接入层WorkMate通过工具节点调用这些接口。验证阶段我会建议先做“冒烟测试”不要直接全量接业务。先给WorkMate配一个“库存查询”工具然后在对话框里问“SKU 10086当前库存多少”如果它能通过工具返回准确的数字和更新时间说明数据链路通了。接着再测“异常预警”工具模拟一个库存低于安全值的场景看WorkMate能否生成预警消息并推送给指定角色。这一步是整个部署过程里最容易出问题的地方。很多团队前面都顺利一到数据接入就开始“上火”因为源系统的字段命名不规范、接口超时、权限校验严格。我们当时花了整整两天梳理ERP的字段映射才让WorkMate能正确理解“可用库存”和“在途库存”的区别。所以这里想提醒一句工具节点的测试必须覆盖边界数据比如空值、超长字符串、重复记录不要让模型在真实数据上临场猜。3. 人机协同机制任务怎么分配、人怎么介入WorkMate部署完成只是技术上的里程碑真正的价值释放要靠“人机协同流程”的设计。兆企内部我把这套机制总结成三句话机器能做的自动做机器不确定的请示做人做决定后机器跟进做。3.1 角色定义与权限分层用人机协同的第一步是给WorkMate定义它在组织里的“岗位”。它不是你不是某个人的替身而是一个虚拟执行助理。我们建了四类角色跟单助理、计划助理、仓库助理、监控助理。不同助理拥有不同的工具权限。跟单助理可以读订单、发催单通知但不能改价格计划助理可以算补货建议但只有“建议权”最终采购单必须由计划经理确认仓库助理能查库存流水和差异单但盘点结果必须由仓管员二次确认。这个权限分层在WorkMate里主要体现为“角色-工具-流程”三重绑定。角色决定它能调用哪些工具工具决定它能碰哪些数据流程决定它在什么条件下把控制权交还给人。设计时我们参考了供应链里的“四眼原则”关键业务动作不能由一个人或一个Agent完全闭环至少要经过一次人工确认。这样即使模型判断有误也有一个兜底闸门。3.2 审批流与预警确认机制供应链场景里大量工作是“按例外管理”。WorkMate的价值不在于天天处理常规订单而在于它能第一时间发现异常然后把需要决策的问题以结构化方式提给对应的人。比如某个供应商连续三次延期WorkMate会自动生成异常记录计算延期率并给跟单主管推送一条审批请求“是否将A供应商列入重点观察名单”主管点同意WorkMate去更新供应商档案点驳回WorkMate记录驳回原因调整后续触发阈值。这个机制落地时我们要想清楚哪些审批是真正必要的。如果每个库存预警都让主管点一下不仅人疲劳而且容易“审批麻木”。所以兆企的做法是分级处理低风险异常只记录并汇总成日报中风险异常自动通知跟单员响应高风险异常才升级到主管审批。这样人机协同才真正高效否则就是把原来的手工流程线上化并没有减少人的负担。3.3 人机协同的反馈闭环WorkMate不是静态工具部署之后需要持续“调教”。我们内部建立了一个反馈闭环每一次人工纠偏都会成为模型调优的输入。比如WorkMate建议补货500件但计划员实际改成300件系统会记录差异如果连续多次出现类似偏向说明模型的预测逻辑可能给你了一个正偏差需要调整提示词模板或调低建议置信度。另外反馈不只是“模型错了才反馈”还包括“模型对了但方式不友好”。比如有用户反馈WorkMate回答太长我们就在提示词里加了“先给结论再给依据”的约束有用户反馈预警太频繁我们就调整了聚合窗口和触发阈值。这些都是部署之后必须做的长期运维工作也是人机协同能否越跑越顺的关键。4. 常见问题与排查技巧实录4.1 部署与运行期的典型故障速查表这部分都是我们实际踩过的坑整理成一张速查表方便大家对照排查现象可能原因快速解决方法Docker容器启动后立即退出环境变量缺失或数据库连接失败先看docker compose logs确认数据库是否健康检查.env里的DB_HOST是否指向容器名而非localhostWorkMate能对话但查不到数据工具节点配置错误或数据源权限不足在后台测试工具节点确认返回结果检查源系统账号是否只读了视图且字段名匹配回答速度越来越慢向量库索引膨胀或Redis缓存失效清理旧会话重建向量索引观察vLLM的GPU显存占用必要时重启推理容器预警消息没有推送到钉钉/企微Webhook URL配置错误或网络策略拦截检查webhook地址可访问性测试发送一枚测试消息确认消息频率限制是否触发模型对库存单位理解错误工具返回的数据元信息不足在工具返回结果中补充单位、时间戳、数据来源字段让模型有上下文可循用户误操作改掉了线上数据权限配置过宽工具暴露了写操作严格遵循最小权限原则默认只读需要写入的工具必须单独配置且带二次确认4.2 几个特别想提醒的避坑经验第一个特别提醒是不要把知识库一股脑灌进去。我们一开始图省事把供应商合同、操作手册、历史邮件全导入了向量库结果检索时经常命中不相关内容模型回答时也容易“跑偏”。后来我们按业务域拆分知识库目录并对每份文档写了简短的业务标签检索准确率才明显上去。这个道理跟整理自己的办公桌一样分类清晰才是高效检索的前提。第二个特别提醒是日志和审计一定不能省。人机协同一旦跑起来每天会有大量自动动作。如果哪天业务方来问“这个订单是谁改的”你查不到审计记录那就非常尴尬。WorkMate本身的动作日志要留存我们的做法是把所有AI触发的关键动作同步转发到独立的审计存储里并且禁止普通管理员删除。这既是为了安全也是为了后面做效果复盘时能还原现场。第三个特别提醒大版本升级前做好回滚快照。我们曾在一次升级中引入了新的技能包结果发现某个旧流程的输入输出格式变了生产任务被中断。还好提前给数据库和配置文件打了快照十分钟内就回滚了。CI/CD在AI部署里同样重要不能因为它是“AI应用”就觉得不需要版本管理。4.3 性能优化心得WorkMate部署中后期性能优化的重点慢慢从模型响应转向了整体链路。最明显的瓶颈往往是外呼系统的接口响应时间。比如查询某个供应商的实时物流轨迹上游接口要3秒才返回即使模型生成答案只要0.5秒整体体感还是慢。我们的优化手段是加了一层缓存高频查询同一车辆近一小时内轨迹直接命中Redis只有新查询才走上游接口。另外还可以把跨多个工具的调用串行改成并行WorkMate如果支持并行工具调用尽量让“查库存”和“查在途”同时进行省时间观感会很明显。5. 部署之后WorkMate还能怎么扩展5.1 从单任务到多Agent协作WorkMate初期只是完成一个个单点任务比如查库存、写预警、算建议。跑稳定之后我发现更值得玩的是让多个WorkMate实例或者多个角色协同作业。举个例子一个“计划助理”发现某物料库存告急它可以自动创建一个“协同任务”把“补货建议”推给“采购助理”采购助理生成采购草单后再流转给“跟单助理”去跟踪交期。整个过程每个节点都有明确负责人而人只需要在每个审批点把关。这就是人机协同从“1对1”走向“1对多”的阶段组织效率的放大效应非常明显。5.2 知识库的持续运营WorkMate在供应链场景用好很大程度取决于知识库有没有持续喂养。我们把每周的周会纪要、异常复盘、供应商评估结果都沉淀进知识库再过一段时间再让WorkMate回答“A供应商最近表现怎么样”它给出的答案就会更贴合实际。不过知识库不是堆越多越好每季度必须做一次档案清理过期文档要标记归档避免陈旧信息干扰模型判断。5.3 与BI和报表体系融合最后一个是可选的延伸方向把WorkMate生成的数据洞察接入现有的BI体系。我们后来把WorkMate的预警记录、审批通过率、Agent自动处理率都做成了看板管理层每周看一眼就能掌握这套人机协同机制的健康度。数据也很直观在补货建议场景里WorkMate的初稿建议被计划员直接采纳的比例大概在六成以上剩下四成经过微调后采纳这个过程中明显节约了计划员从零开始做计算的时间。这个指标比单纯的“对话次数”更能反映AI的真实价值。我自己的体会是WorkMate这类工具部署起来不难难的是把它嵌进业务肌理。你让它跑起来只花了半天但让它跟团队磨合出默契可能需要挺长一段时间。好在我们从一开始就把“人的审批权”和“机器的执行权”分得清清楚楚业务方才会慢慢建立起对它的信任这个信任一旦建立起来效率提升就是水到渠成的事。