WorkMate部署与人机协同：供应链AI应用实战解析

兆企供应链管理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 4090（24GB显存），操作系统Ubuntu 22.04，磁盘单独挂了一块2TB SSD。如果团队预算紧张，没有独立显卡，也可以先用CPU跑量化后的小模型试试，但响应速度会比较慢，我这里建议至少16核64GB内存起步，否则人机协同的“实时感”会大打折扣。

软件层面需要提前装好这些东西：

• Docker和Docker Compose插件（我用的是Docker 24.0+）
• Python 3.10以上（部分工具脚本需要）
• Git（拉取WorkMate仓库和模型文件）

建议在干净的宿主机上操作，不要在Windows上直接跑生产环境。我们内部也有人用WSL2做过测试，能跑通，但涉及GPU透传和端口映射时比较折腾，生产还是建议Linux。

2.2 模型底座部署：Ollama还是vLLM

WorkMate本身不携带模型，它需要对接一个推理服务。我们在测试阶段最早用的是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_URL=http://vllm:8000/v1 LLM_API_KEY=dummy-key DB_HOST=postgres DB_PORT=5432 DB_NAME=workmate DB_USER=workmate DB_PASSWORD=change-me REDIS_HOST=redis REDIS_PORT=6379 VECTOR_STORE_PATH=/data/vectors ADMIN_PASSWORD=change-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 部署与运行期的典型故障速查表

这部分都是我们实际踩过的坑，整理成一张速查表方便大家对照排查：

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这类工具部署起来不难，难的是把它嵌进业务肌理。你让它跑起来，只花了半天；但让它跟团队磨合出默契，可能需要挺长一段时间。好在我们从一开始就把“人的审批权”和“机器的执行权”分得清清楚楚，业务方才会慢慢建立起对它的信任，这个信任一旦建立起来，效率提升就是水到渠成的事。