最近被问得最多的问题，就是供应链行业里的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 GPU，24GB显存，跑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在库存优化和智能补货场景里的实际效果，到时候再跟大家细聊。
