1. 项目背景与WorkMate的系统定位1.1 供应链管理正在发生什么变化在供应链管理这个行当里待得久了你会发现一个很现实的问题业务量越来越大数据越来越多但人的精力始终是有限的。以前我们靠Excel表格加电话邮件后来上了ERP、WMS、TMS系统越来越重但真正到了一线业务人员手里反而多了无数个需要登录、需要维护、需要导出导入的工具。订单异常了要查系统、对账要查系统、供应商评估也要查系统一天下来光是系统切换就能耗掉大半精力。这两年大模型技术火起来之后行业里很多人都在讨论AI能不能改变这种状态。想法是美好的但落地的时候很快就遇到了瓶颈通用聊天机器人不懂供应链业务私有数据不敢直接喂给外部接口好不容易找到一个开源模型能本地跑了又发现部署和运维又是个大工程。说实话我自己也经历过好几轮“从兴奋到失望再到冷静”的循环。直到我们把WorkMate这套体系搭建起来才算真正找到了一个能稳定运转、业务人员愿意用、管理层看得到效果的落地形态。WorkMate不是一个单纯的聊天工具也不是传统意义上的自动化机器人。它更像是一个位于业务系统和一线员工之间的智能工作伙伴能接数据、能查逻辑、能跑分析、能写报告还能把结果主动推给需要的人。而这一期的白皮书核心就是两个关键词——部署和人机协同。部署解决的是“AI怎么在企业内网里跑起来”的问题人机协同解决的是“AI跑起来之后人到底怎么跟它配合才最高效”的问题。这两个问题打通了供应链AI应用才算真正有了根。1.2 WorkMate到底是什么、解决什么问题先把WorkMate的定位说清楚不然后面的部署细节会让人困惑。WorkMate本质上是一个面向供应链业务场景的AI智能体AI Agent应用它跟普通的问答机器人最大的区别在于它能调用工具、查询数据、执行流程而不是仅仅“说”一段话给你听。举个例子业务人员问它“这个月华东仓的发货及时率怎么样”WorkMate不只是从知识库里找一段标准答案而是会实际连接WMS的数据库按时间范围统计发货单的准时签收情况计算及时率然后结合历史数据进行对比最后生成一段有数据、有分析、有结论的文字回复。如果你在系统里配置了定时任务它还能每天早上主动推送前一天的运营简报。这就是“Agent”跟“聊天机器人”的本质区别。那WorkMate解决的核心问题是什么我用一句话概括把供应链从业者从“找数据、做表、写报告”的低价值重复劳动中解放出来让人把精力聚焦在判断、决策和沟通上。这不是替代人的逻辑而是补位和增强的逻辑。系统不会替你做采购决策但它能帮你把历史价格、交期、质量数据全部拉齐让你做决策的时候心里有数。这套东西适合谁参考如果你是企业的信息化负责人、供应链运营主管、或者正在做AI应用落地的技术负责人这篇文章里涉及的部署路径、框架选型、权限设计、人机协同流程都是可以直接拿来落地的方法论。如果只是出于兴趣想了解一下企业级AI应用是怎么回事也能从中看到一个大模型从“技术玩具”变成“业务工具”的完整路径。2. 技术选型与整体架构设计2.1 为什么选Dify加Ollama加Docker这套组合WorkMate在技术选型上纠结过很长时间。最初我们考虑过直接调用云端大模型API方案简单、效果也好但很快就被数据安全这一关卡住了。供应链数据涉及供应商报价、客户订单、库存成本这些核心经营信息管理层的第一要求就是“数据不能出内网”。这个红线一划云端API方案基本就废了大半剩下能走的路就一条私有化部署大模型。私有化部署又面临一个选择题到底是从零开始训练一个行业模型还是在开源基座模型之上做应用封装答案很明确训练行业模型不是一般企业能耗得起的算力成本、数据清洗成本、迭代维护成本都极高。更合理的方式是选择成熟的开源基座模型通过RAG检索增强生成技术把企业内部知识库和业务数据接入进去再通过Agent框架让模型具备调用工具和执行业务流程的能力。这个思路下我们确定了三件套Dify做应用编排和Agent管理Ollama做模型本地化推理服务Docker做底层环境封装和部署管理。这套组合的优势在于分工清晰、上手成本低、生态成熟。Dify作为开源LLMOps平台内置了Agent工作流、知识库RAG、Prompt编排、API发布这些核心能力能省掉大量自研框架的重复劳动。Ollama则把模型加载、推理参数、显存管理这些复杂事情封装成了简单的命令行操作一条命令就能把一个开源大模型跑起来对运维团队非常友好。Docker则解决了环境一致性问题——不会出现“在测试环境好好的上生产就崩了”这种经典事故。2.2 整体架构与数据流向WorkMate的整体架构从上到下可以分成四层业务接入层、Agent编排层、模型推理层、数据底座层。业务接入层面向最终用户包含企业微信/钉钉的机器人入口、Web页面、以及定时任务推送。这一层的核心价值是“降低使用门槛”——业务人员不需要学习新的工具在聊天窗口里就能完成大部分操作。Agent编排层是WorkMate的中枢运行在Dify上。这里定义了一个个“技能”比如订单异常分析、供应商绩效评估、库存周转测算。每个技能对应一组Prompt模板、一个数据查询流程和一个输出格式约束。Dify内置的Agent节点支持调用外部API和数据库工具这就让WorkMate具备了“动手干活”的能力而不只是动嘴。模型推理层跑的是本地化部署的大语言模型。我们用Ollama加载了Qwen2.5-14B-Instruct作为主模型后来又根据场景需要增加了DeepSeek-R1-Distill-Qwen-14B用于复杂推理类任务。之所以不只用一个大模型是因为不同任务对模型能力的侧重不一样文本摘要和格式转换用Qwen系列性价比高复杂数据分析和多步推理用DeepSeek系列更稳。数据底座层放在最底下包含三类数据源关系型数据库MySQL/PostgreSQL存业务结构化数据向量数据库Milvus或Dify内置的向量索引存知识库文档切片对象存储存非结构化的合同、对账单、质检报告等文件。WorkMate在回答问题时会先从向量库检索相关知识动态拼入Prompt再结合数据库查询结果一起生成回答。这就是RAG的典型链路也是控制幻觉、提升回答准确率的关键机制。数据流向很好理解用户提问进到Agent编排层编排层判断意图后决定是直接交给模型回答还是先查数据库/调用API再回答。需要知识库支撑时先从向量库检索相关片段拼入上下文。最后统一送回模型推理层生成回复再通过接入层呈现给用户。3. WorkMate部署实操全流程3.1 环境准备与基础依赖安装说完了架构进入正题讲部署。WorkMate的部署过程我拆成五个阶段环境准备、模型部署、应用服务安装、知识库建设、业务配置。每一步都有不少坑我会把关键的地方都标出来。先说环境准备。WorkMate对服务器的要求不算特别苛刻但也不能太寒酸。我们的生产环境用了三台物理机搭集群两台跑模型推理与应用服务一台做数据存储。单台配置大致是双路Intel Xeon Gold处理器、256GB内存、一张NVIDIA A100 80GB显卡、2TB NVMe SSD。如果你的并发量不大单台配置可以降到两张RTX 4090显卡加128GB内存预算能省不少。操作系统方面推荐Ubuntu 22.04 LTS稳定且对深度学习生态支持好。装好系统后第一件事是更新内核驱动和CUDA环境。NVIDIA驱动版本建议535以上CUDA建议12.2以上这两个版本没对齐的话后面跑模型经常会遇到“CUDA error: invalid device function”之类的报错。基础依赖主要是Docker和Docker Compose。Docker的安装直接参考官方文档就行但有三点要注意一是Docker的存储驱动建议配置为overlay2性能最稳二是给Docker的根目录单独分个大分区默认放在/var/lib/docker下后续镜像和数据会膨胀得很快三是如果服务器上有防火墙要提前放行Dify所需的80/443端口和Ollama的11434端口。Docker装完之后验证一下环境docker info能看到服务器信息docker compose version能正常输出版本号基本就算OK了。3.2 本地大模型服务部署接下来是整套部署里的关键环节——模型推理服务。我们选的是Ollama原因之前说了简单、稳定、社区活跃。Ollama的安装非常简单官方提供了一键脚本curl -fsSL https://ollama.com/install.sh | sh就能装好。不过在生产环境我建议下载离线安装包避免部署时依赖外网。装完之后用ollama list能查到已安装的模型列表初次安装是空的。拉取模型用的是ollama pull命令。以Qwen2.5-14B-Instruct为例执行ollama pull qwen2.5:14b-instructOllama会自动匹配量化版本和适配层不用手动配置。如果要用DeepSeek-R1-Distill-Qwen-14B则执行ollama pull deepseek-r1:14b模型拉下来之后建议先跑一次简单对话测试确认推理服务正常ollama run qwen2.5:14b-instruct 请介绍一下你自己这里有个参数需要特别关心——上下文长度context length。Ollama的默认上下文是4096对于供应链分析这种需要塞大量业务数据的场景远远不够。要调大上下文可以在启动时设置环境变量OLLAMA_CONTEXT_LENGTH32768或者在Modelfile里指定参数。注意Context Length调大会显著增加显存占用。14B模型在4096上下文下大概需要12GB显存拉到32768之后显存占用会到20GB以上。所以不是越大越好而是在业务需求和硬件资源之间取平衡。为了让Ollama作为后台服务常驻运行还需要配置systemd服务。Ollama安装完之后默认会注册服务执行systemctl status ollama确认运行状态。如果需要局域网内其他机器访问要修改Ollama的环境变量OLLAMA_HOST0.0.0.0允许外部连接。3.3 Dify应用编排平台部署Dify是WorkMate的“大脑”所有Agent技能、知识库、工作流都在这里配置。Dify的部署走Docker Compose方式这是官方推荐也是维护成本最低的方式。首先用git把Dify的源码仓库拉到服务器上或者直接下载release包然后进入docker目录。Dify官方提供了一个docker-compose.yaml文件预先定义好了所有服务API服务、Worker服务、PostgreSQL、Redis、Weaviate向量数据库、Nginx等。执行cd dify/docker cp .env.example .env docker compose up -d第一次启动会自动拉取所有镜像耗时取决于网速。中途如果出现拉镜像超时可以配置Docker的镜像加速地址后重试。镜像拉完访问http://服务器IP/install按页面提示初始化管理员账号。Dify的初始化需要几步设置管理员邮箱和密码等待系统初始化数据库最后进入主界面。Dify部署好后需要把Ollama接入进来。路径“设置” - “模型供应商” - 找到Ollama填写API地址。如果在同一台服务器上地址就是http://host.docker.internal:11434如果在另一台机器上则填完整的IP地址。填完之后测试连通性能看到已拉取的模型列表就说明对接成功。提示Dify容器内部访问宿主机不能用localhost要用host.docker.internal。这是很多初次部署的人容易踩的坑。如果网络模式是host模式才可以直接用localhost。3.4 知识库建设与数据接入模型部署好了Dify也跑起来了这时候WorkMate还只是个空壳真正让它“懂业务”的是知识库建设和业务数据接入。知识库用在RAG链路中负责给模型提供供应链领域的专业背景。我们把知识库分了两大类一类是通用供应链知识包括仓储管理术语、交付条款解读、行业标准另一类是企业私有知识包括公司规章制度、SOP流程文档、历史项目复盘报告、客户交付要求汇总等。知识库的构建流程是准备文档 - 文档解析 - 切片 - 向量化 - 入库。Dify在“知识库”模块中提供了完整的操作界面支持上传PDF、Word、Markdown等格式。上传完成后Dify会自动做文档解析和分段默认分段长度是500个token重叠50个token。这个参数不一定适合所有场景我的经验是SOP类文档切片可以长一些保证语义完整问答对类文档切片短一些便于精准匹配。向量化这一环节需要调用Embedding模型。我们用了Dify内置的OpenAI兼容接口配合Ollama上的Embedding模型。在Ollama上拉取Embedding模型ollama pull nomic-embed-text然后在Dify的模型供应商里配置Ollama的Embedding模型即可。业务数据接入方面WorkMate通过Dify的“工具”能力对接了企业内部数据库。Dify内置了PostgreSQL和MySQL连接器可以在Agent工作流中直接执行SQL查询。我们在数据库里为WorkMate专门创建了一个只读账号权限严格限制在业务分析需要的表和视图上防止Agent被恶意提示词诱导做出危险操作。数据库接入配置路径“工具” - “内置工具” - 找到PostgreSQL/MySQL填入连接参数最后做连通性测试。建议先手动执行一条简单查询验证权限是否正确。3.5 Agent技能配置与发布当底层的模型、知识库、数据库连接都准备好之后最后一步就是配置Agent技能了。这一步相当于给WorkMate“装职业能力”。在Dify中Agent技能的核心是“应用”App。我们创建了多个应用供应链问答助手、运营日报生成器、异常订单分析员、供应商绩效评估师。以“供应商绩效评估师”为例它需要的核心能力是输入供应商名称查询该供应商在数据库中的交期、质量、价格数据结合知识库中的评分标准生成一份结构化的评估报告。这类任务的实现路径有两种。一种是在Dify的Prompt编排中把数据库查询写成Function Calling的工具函数让模型自行决定何时调用另一种是用工作流Workflow方式把流程固定成一个有向无环图开始节点 - 参数输入 - 工具调用查询API - 知识库检索 - LLM生成 - 结束节点。我的建议是数据查询链路稳定的场景用工作流固定流程、结果可控开放性问题多的场景用Agent模式给模型更多自主判断空间。WorkMate目前运行下来的经验两种模式共存效果最好。配置完成之后点击“发布”即可生成API访问地址。Dify支持多种渠道接入网页应用、ChatGPT插件、API调用对企业微信和钉钉的支持可以通过Dify的扩展机制实现。我们生产环境主要走API方式在企业微信机器人后端用Python将用户消息转发给Dify API再把结果推回企业微信群。整个链路非常轻盈业务人员在企业微信里就能完成所有操作。4. 人机协同的核心场景与运行机制4.1 人机协同不是“机器替代人”很多企业在做AI落地时会陷入一个认知误区AI上了线人就可以减少或者AI干完活直接给结果人就只负责看。但实际到供应链这种复杂业务场景中这种预期一定会落空。人机协同的本质是“能力互补”和“责任共担”。补给品需求预测、供应商谈判策略、紧急订单插单安排这些决策背后有大量说不清楚的“隐性知识”——客户关系深浅、供应商实际产能弹性、历史合作默契度、业务现场的特殊情况。这些信息不会完整记录在系统里也不可能被模型“学会”。所以WorkMate的定位一直是辅助者是增强人的感知力和计算力而不是替代人的判断力。具体到交互模式上我们把WorkMate设计成三层协同第一层是“我在现场查”业务人员主动向它提问快速获得数据和分析第二层是“它帮我盯”通过定时任务WorkMate主动监控业务指标并推送异常预警第三层是“我们一起定”针对重要决策WorkMate提供数据分析和多方案推演人在这个基础上拍板。这三层协同分别对应不同的使用深度也对应不同的人员能力要求。第一层人人可用第二层需要一点配置和调优能力第三层则更依赖业务人员自身的经验。但共同点是工具不会替你做决定而是让你的每一个决定都更有根据。4.2 典型场景一跨部门协作中的“翻译官”供应链管理天然是跨部门的采购、销售、仓储、财务、计划各有各的系统各有各的语言。一线管理者很多时间都耗在沟通和解释上采购问库存周转为什么这么慢销售问补货为什么还没到位财务问供应商账期为什么又延长了。WorkMate在这里扮演的角色是个“翻译官”。它把不同系统的数据拉通之后用一句话把关键信息解释清楚。举个例子仓储经理问“华东仓的空间占用什么时候会饱和”WorkMate不只是报一个“当前占用率80%”的数字它会结合未来四星期到货计划和出库预测给出一个趋势判断“按当前到货节奏第3周转运空间将达到阈值建议调整第3周的到货计划或提前启动部分出库。”这个分析过程看起来简单实际上背后做了大量工作查询WMS当前库存、读取采购订单的预计到货日期、结合历史出库数据做预测、把结果翻译成业务视角的建议。人看完这个结论后可以直接拿去跟计划部门沟通省掉了“找数据-做表格-自己想结论”的大半时间。这里要特别强调的是WorkMate的输出永远带着数据来源和置信度说明。如果模型不太确定某个推断它会明确说“这部分是根据历史趋势推测的准确度约80%”。这个设计很重要因为供应链决策错了是有真金白银损失的宁可让人保留怀疑也不能让AI显得全能。4.3 典型场景二异常预警与主动推送人机协同的另一个高频场景是异常预警。传统模式下业务异常往往靠人去发现——“这个订单怎么三天了还没出库”、“这个供应商最近怎么老延期”人发现问题的时候往往已经过去了一段时间损失已经发生。WorkMate的定时任务能力改变了这个模式。我们配置了一个“每日运营巡检”任务每天凌晨3点执行检查前一日的新增订单、未按期出库订单、库存低于安全线的情况、供应商交期延期比例生成一份巡检报告。早上八点业务负责人在企业微信里就能收到一份简报“昨日新增订单128单其中3单超过12小时未分配仓库华东仓有6个SKU库存低于安全线详情见列表XY供应商最近两周交期延期率上升到18%建议关注。”这套机制运行了两个月之后业务团队最大的感受是发现问题的速度变快了响应时间从以天计缩短到以小时计。有几次临时促销活动导致订单量激增WorkMate在当天中午就识别出仓库处理能力可能跟不上提醒计划部门提前协调了临时外包人员。这就是主动推送机制的价值——不等人发现问题让问题自己浮现出来。推动实现这个场景的技术细节也不算复杂Dify的“工作流”里有一个定时触发节点设定执行频率和调用参数即可。关键在预警阈值的设定不能太灵敏否则全是噪音也不能太迟钝否则失去预警意义。我的建议是先基于历史数据统计P90分位数作为初始阈值上线后根据实际误报率持续调参。4.4 典型场景三复杂决策前的“分析沙盘”第三层协同是让我自己最兴奋的场景也是WorkMate真正发挥大模型思考能力的场景——复杂决策前的多方案推演。举个例子公司计划在西南区域新设一个区域仓但建仓方式有自建、租赁、跟第三方物流合作三种选择。传统做法是让计划团队做一轮分析可能要花两周时间。WorkMate的做法是把要求的约束条件输入进去——目标区域、预计年处理量、投资上限、运营成本敏感度它会基于历史物流数据和行业基准生成三种模式的成本对比、时效对比、风险点分析并且支持追问“如果把年处理量提高30%三种模式的优劣势会怎么变化”这个场景复现出来的效果非常惊艳。业务团队可以在几十分钟内获得多维度、多假设的分析结果虽然最终决策还需要结合资金情况、战略方向综合判断但前期分析的时间成本被压缩了将近90%。这种场景的实现难点不在技术而在“知识储备”。WorkMate能够做推演是因为知识库里沉淀了大量行业分析框架、历史项目数据和标杆案例。如果知识库是空的模型只能泛泛而谈给出的建议没有参考价值。所以我的建议是在开放这类高复杂度场景之前先把知识库做扎实。5. 常见问题与排查技巧实录5.1 部署阶段的高频问题从零到一把WorkMate部署起来整个过程中我们踩了不少坑挑几个典型问题说说。问题一Ollama模型推理速度极慢一个简单问题要等几十秒。排查过程先看显存占用如果模型没有完全加载进显存大概率是KV Cache没有命中每次请求都重新加载部分权重再看并发请求多个用户同时问问题时Ollama默认的并发策略可能会导致排队。解决调大OLLAMA_NUM_PARALLEL环境变量把模型常驻显存避免swap到内存确保OLLAMA_KEEP_ALIVE设置较长的时间。问题二Dify工作流中调用数据库超时。排查过程先看是不是SQL写得太复杂、没有走索引再看连接池配置Dify默认的连接池比较小并发高时会出现连接等待。解决在数据库侧为大查询加索引或物化视图调大Dify配置里的连接池参数对于周期性大查询任务改为错峰执行。问题三知识库问答效果差检索到的文档片段完全不相关。排查过程先看切分策略是否合理原始的切片方式下SOP大段落被拆得七零八落再看Embedding模型效果通用Embedding对供应链专业术语的理解不够深。解决改用按标题分块策略保留章节结构在Dify的检索配置中把检索模式从“向量检索”改为“全文向量混合检索”召回效果提升非常明显。5.2 使用阶段的高频问题问题一AI回答的格式不稳定有时候给表格有时候给列表。解决在系统提示词中给出明确的输出格式模板并对结构化输出场景使用Dify的“输出格式”控制功能。如果还需要更严格的约束可以采用JSON Schema输出让模型以固定JSON结构返回数据再由前端渲染。问题二业务人员提问很口语化AI经常答非所问。解决给WorkMate配备一个“意图理解前置模块”把“这个月发货准不准啊”这类口语化问题归一化成标准查询参数。我们的做法是在Dify工作流中加了一个意图识别节点先让模型判断用户想查什么指标再生成对应的SQL查询效果比直接问数据库好很多。问题三权限控制不好做A供应商的业务人员能查到B供应商的数据。解决基于Dify的多租户能力改造每个供应商/客户对应一个独立知识库在应用入口处根据用户身份动态限定可访问的数据范围。数据库层面也通过视图隔离确保即便SQL被恶意构造也无法越权读取。5.3 项目复盘与运维经验总结WorkMate从部署到稳定运行整个项目走下来的经验可以总结成三条核心心得。第一条部署最大的难点不在技术而在业务梳理。大模型部署的技术栈已经很成熟了按文档操作基本能跑通但要把业务流程抽象成Agent技能需要业务方深度参与。我们的做法是前期花了两周时间把所有核心业务场景梳理成一张“场景-数据-决策”地图哪一步用什么数据、产出什么结果、由谁来验证全部搞清楚再动手开发。这个投入非常值得。第二条知识库的维护是长期工作不是上线就完了。业务文档在持续更新供应商信息在变流程制度也在变。我们设了一个“知识库运营”的轮值角色每周复核一次新增文档并更新向量库每个月复盘一次检索质量。不打理的知识库会越用越差检索准确率会肉眼可见地下降。第三条人机协同需要机制保障不能只靠工具。我们配套建立了“AI结果人工复核”制度对于影响金额较大的数据输出必须由人工确认数据来源和计算逻辑后再用于决策。这不是对AI不信任而是必要的风险管理机制。AI会有幻觉会有数据源变更导致的误判把人工复核嵌入流程是在效率和安全之间找了一个平衡点。最后再分享一个维护技巧。WorkMate用久了之后模型的表现会有轻微漂移尤其是知识库新增内容之后回答风格和引用逻辑可能发生变化。我们每个月会做一次“回归测试”准备好一组标准的测试问题集覆盖所有核心场景依次跑一遍对比回答质量和数据准确性是否达标。这个问题集平时都在维护和扩充每次模型升级、知识库更新后自动触发一轮回归能提前发现很多潜在问题。这套体系从部署到现在已经稳定运行了快半年。最让我欣慰的还不是技术侧的成功而是业务团队的态度转变——最开始很多人抱着试试看的心态现在是每天早上主动等着WorkMate的推报。这个变化说明它真的融进了业务流程里成了团队的一分子。AI在供应链里的价值说到底还是要看人愿不愿意用、用得顺不顺手。WorkMate这个项目的经验告诉我技术只是起点让人机协同真正运转起来、让每个业务人员都感受到AI带来的提效才是终局。 供应链AI智能体落地指南：WorkMate私有化部署与人机协同实践
1. 项目背景与WorkMate的系统定位1.1 供应链管理正在发生什么变化在供应链管理这个行当里待得久了你会发现一个很现实的问题业务量越来越大数据越来越多但人的精力始终是有限的。以前我们靠Excel表格加电话邮件后来上了ERP、WMS、TMS系统越来越重但真正到了一线业务人员手里反而多了无数个需要登录、需要维护、需要导出导入的工具。订单异常了要查系统、对账要查系统、供应商评估也要查系统一天下来光是系统切换就能耗掉大半精力。这两年大模型技术火起来之后行业里很多人都在讨论AI能不能改变这种状态。想法是美好的但落地的时候很快就遇到了瓶颈通用聊天机器人不懂供应链业务私有数据不敢直接喂给外部接口好不容易找到一个开源模型能本地跑了又发现部署和运维又是个大工程。说实话我自己也经历过好几轮“从兴奋到失望再到冷静”的循环。直到我们把WorkMate这套体系搭建起来才算真正找到了一个能稳定运转、业务人员愿意用、管理层看得到效果的落地形态。WorkMate不是一个单纯的聊天工具也不是传统意义上的自动化机器人。它更像是一个位于业务系统和一线员工之间的智能工作伙伴能接数据、能查逻辑、能跑分析、能写报告还能把结果主动推给需要的人。而这一期的白皮书核心就是两个关键词——部署和人机协同。部署解决的是“AI怎么在企业内网里跑起来”的问题人机协同解决的是“AI跑起来之后人到底怎么跟它配合才最高效”的问题。这两个问题打通了供应链AI应用才算真正有了根。1.2 WorkMate到底是什么、解决什么问题先把WorkMate的定位说清楚不然后面的部署细节会让人困惑。WorkMate本质上是一个面向供应链业务场景的AI智能体AI Agent应用它跟普通的问答机器人最大的区别在于它能调用工具、查询数据、执行流程而不是仅仅“说”一段话给你听。举个例子业务人员问它“这个月华东仓的发货及时率怎么样”WorkMate不只是从知识库里找一段标准答案而是会实际连接WMS的数据库按时间范围统计发货单的准时签收情况计算及时率然后结合历史数据进行对比最后生成一段有数据、有分析、有结论的文字回复。如果你在系统里配置了定时任务它还能每天早上主动推送前一天的运营简报。这就是“Agent”跟“聊天机器人”的本质区别。那WorkMate解决的核心问题是什么我用一句话概括把供应链从业者从“找数据、做表、写报告”的低价值重复劳动中解放出来让人把精力聚焦在判断、决策和沟通上。这不是替代人的逻辑而是补位和增强的逻辑。系统不会替你做采购决策但它能帮你把历史价格、交期、质量数据全部拉齐让你做决策的时候心里有数。这套东西适合谁参考如果你是企业的信息化负责人、供应链运营主管、或者正在做AI应用落地的技术负责人这篇文章里涉及的部署路径、框架选型、权限设计、人机协同流程都是可以直接拿来落地的方法论。如果只是出于兴趣想了解一下企业级AI应用是怎么回事也能从中看到一个大模型从“技术玩具”变成“业务工具”的完整路径。2. 技术选型与整体架构设计2.1 为什么选Dify加Ollama加Docker这套组合WorkMate在技术选型上纠结过很长时间。最初我们考虑过直接调用云端大模型API方案简单、效果也好但很快就被数据安全这一关卡住了。供应链数据涉及供应商报价、客户订单、库存成本这些核心经营信息管理层的第一要求就是“数据不能出内网”。这个红线一划云端API方案基本就废了大半剩下能走的路就一条私有化部署大模型。私有化部署又面临一个选择题到底是从零开始训练一个行业模型还是在开源基座模型之上做应用封装答案很明确训练行业模型不是一般企业能耗得起的算力成本、数据清洗成本、迭代维护成本都极高。更合理的方式是选择成熟的开源基座模型通过RAG检索增强生成技术把企业内部知识库和业务数据接入进去再通过Agent框架让模型具备调用工具和执行业务流程的能力。这个思路下我们确定了三件套Dify做应用编排和Agent管理Ollama做模型本地化推理服务Docker做底层环境封装和部署管理。这套组合的优势在于分工清晰、上手成本低、生态成熟。Dify作为开源LLMOps平台内置了Agent工作流、知识库RAG、Prompt编排、API发布这些核心能力能省掉大量自研框架的重复劳动。Ollama则把模型加载、推理参数、显存管理这些复杂事情封装成了简单的命令行操作一条命令就能把一个开源大模型跑起来对运维团队非常友好。Docker则解决了环境一致性问题——不会出现“在测试环境好好的上生产就崩了”这种经典事故。2.2 整体架构与数据流向WorkMate的整体架构从上到下可以分成四层业务接入层、Agent编排层、模型推理层、数据底座层。业务接入层面向最终用户包含企业微信/钉钉的机器人入口、Web页面、以及定时任务推送。这一层的核心价值是“降低使用门槛”——业务人员不需要学习新的工具在聊天窗口里就能完成大部分操作。Agent编排层是WorkMate的中枢运行在Dify上。这里定义了一个个“技能”比如订单异常分析、供应商绩效评估、库存周转测算。每个技能对应一组Prompt模板、一个数据查询流程和一个输出格式约束。Dify内置的Agent节点支持调用外部API和数据库工具这就让WorkMate具备了“动手干活”的能力而不只是动嘴。模型推理层跑的是本地化部署的大语言模型。我们用Ollama加载了Qwen2.5-14B-Instruct作为主模型后来又根据场景需要增加了DeepSeek-R1-Distill-Qwen-14B用于复杂推理类任务。之所以不只用一个大模型是因为不同任务对模型能力的侧重不一样文本摘要和格式转换用Qwen系列性价比高复杂数据分析和多步推理用DeepSeek系列更稳。数据底座层放在最底下包含三类数据源关系型数据库MySQL/PostgreSQL存业务结构化数据向量数据库Milvus或Dify内置的向量索引存知识库文档切片对象存储存非结构化的合同、对账单、质检报告等文件。WorkMate在回答问题时会先从向量库检索相关知识动态拼入Prompt再结合数据库查询结果一起生成回答。这就是RAG的典型链路也是控制幻觉、提升回答准确率的关键机制。数据流向很好理解用户提问进到Agent编排层编排层判断意图后决定是直接交给模型回答还是先查数据库/调用API再回答。需要知识库支撑时先从向量库检索相关片段拼入上下文。最后统一送回模型推理层生成回复再通过接入层呈现给用户。3. WorkMate部署实操全流程3.1 环境准备与基础依赖安装说完了架构进入正题讲部署。WorkMate的部署过程我拆成五个阶段环境准备、模型部署、应用服务安装、知识库建设、业务配置。每一步都有不少坑我会把关键的地方都标出来。先说环境准备。WorkMate对服务器的要求不算特别苛刻但也不能太寒酸。我们的生产环境用了三台物理机搭集群两台跑模型推理与应用服务一台做数据存储。单台配置大致是双路Intel Xeon Gold处理器、256GB内存、一张NVIDIA A100 80GB显卡、2TB NVMe SSD。如果你的并发量不大单台配置可以降到两张RTX 4090显卡加128GB内存预算能省不少。操作系统方面推荐Ubuntu 22.04 LTS稳定且对深度学习生态支持好。装好系统后第一件事是更新内核驱动和CUDA环境。NVIDIA驱动版本建议535以上CUDA建议12.2以上这两个版本没对齐的话后面跑模型经常会遇到“CUDA error: invalid device function”之类的报错。基础依赖主要是Docker和Docker Compose。Docker的安装直接参考官方文档就行但有三点要注意一是Docker的存储驱动建议配置为overlay2性能最稳二是给Docker的根目录单独分个大分区默认放在/var/lib/docker下后续镜像和数据会膨胀得很快三是如果服务器上有防火墙要提前放行Dify所需的80/443端口和Ollama的11434端口。Docker装完之后验证一下环境docker info能看到服务器信息docker compose version能正常输出版本号基本就算OK了。3.2 本地大模型服务部署接下来是整套部署里的关键环节——模型推理服务。我们选的是Ollama原因之前说了简单、稳定、社区活跃。Ollama的安装非常简单官方提供了一键脚本curl -fsSL https://ollama.com/install.sh | sh就能装好。不过在生产环境我建议下载离线安装包避免部署时依赖外网。装完之后用ollama list能查到已安装的模型列表初次安装是空的。拉取模型用的是ollama pull命令。以Qwen2.5-14B-Instruct为例执行ollama pull qwen2.5:14b-instructOllama会自动匹配量化版本和适配层不用手动配置。如果要用DeepSeek-R1-Distill-Qwen-14B则执行ollama pull deepseek-r1:14b模型拉下来之后建议先跑一次简单对话测试确认推理服务正常ollama run qwen2.5:14b-instruct 请介绍一下你自己这里有个参数需要特别关心——上下文长度context length。Ollama的默认上下文是4096对于供应链分析这种需要塞大量业务数据的场景远远不够。要调大上下文可以在启动时设置环境变量OLLAMA_CONTEXT_LENGTH32768或者在Modelfile里指定参数。注意Context Length调大会显著增加显存占用。14B模型在4096上下文下大概需要12GB显存拉到32768之后显存占用会到20GB以上。所以不是越大越好而是在业务需求和硬件资源之间取平衡。为了让Ollama作为后台服务常驻运行还需要配置systemd服务。Ollama安装完之后默认会注册服务执行systemctl status ollama确认运行状态。如果需要局域网内其他机器访问要修改Ollama的环境变量OLLAMA_HOST0.0.0.0允许外部连接。3.3 Dify应用编排平台部署Dify是WorkMate的“大脑”所有Agent技能、知识库、工作流都在这里配置。Dify的部署走Docker Compose方式这是官方推荐也是维护成本最低的方式。首先用git把Dify的源码仓库拉到服务器上或者直接下载release包然后进入docker目录。Dify官方提供了一个docker-compose.yaml文件预先定义好了所有服务API服务、Worker服务、PostgreSQL、Redis、Weaviate向量数据库、Nginx等。执行cd dify/docker cp .env.example .env docker compose up -d第一次启动会自动拉取所有镜像耗时取决于网速。中途如果出现拉镜像超时可以配置Docker的镜像加速地址后重试。镜像拉完访问http://服务器IP/install按页面提示初始化管理员账号。Dify的初始化需要几步设置管理员邮箱和密码等待系统初始化数据库最后进入主界面。Dify部署好后需要把Ollama接入进来。路径“设置” - “模型供应商” - 找到Ollama填写API地址。如果在同一台服务器上地址就是http://host.docker.internal:11434如果在另一台机器上则填完整的IP地址。填完之后测试连通性能看到已拉取的模型列表就说明对接成功。提示Dify容器内部访问宿主机不能用localhost要用host.docker.internal。这是很多初次部署的人容易踩的坑。如果网络模式是host模式才可以直接用localhost。3.4 知识库建设与数据接入模型部署好了Dify也跑起来了这时候WorkMate还只是个空壳真正让它“懂业务”的是知识库建设和业务数据接入。知识库用在RAG链路中负责给模型提供供应链领域的专业背景。我们把知识库分了两大类一类是通用供应链知识包括仓储管理术语、交付条款解读、行业标准另一类是企业私有知识包括公司规章制度、SOP流程文档、历史项目复盘报告、客户交付要求汇总等。知识库的构建流程是准备文档 - 文档解析 - 切片 - 向量化 - 入库。Dify在“知识库”模块中提供了完整的操作界面支持上传PDF、Word、Markdown等格式。上传完成后Dify会自动做文档解析和分段默认分段长度是500个token重叠50个token。这个参数不一定适合所有场景我的经验是SOP类文档切片可以长一些保证语义完整问答对类文档切片短一些便于精准匹配。向量化这一环节需要调用Embedding模型。我们用了Dify内置的OpenAI兼容接口配合Ollama上的Embedding模型。在Ollama上拉取Embedding模型ollama pull nomic-embed-text然后在Dify的模型供应商里配置Ollama的Embedding模型即可。业务数据接入方面WorkMate通过Dify的“工具”能力对接了企业内部数据库。Dify内置了PostgreSQL和MySQL连接器可以在Agent工作流中直接执行SQL查询。我们在数据库里为WorkMate专门创建了一个只读账号权限严格限制在业务分析需要的表和视图上防止Agent被恶意提示词诱导做出危险操作。数据库接入配置路径“工具” - “内置工具” - 找到PostgreSQL/MySQL填入连接参数最后做连通性测试。建议先手动执行一条简单查询验证权限是否正确。3.5 Agent技能配置与发布当底层的模型、知识库、数据库连接都准备好之后最后一步就是配置Agent技能了。这一步相当于给WorkMate“装职业能力”。在Dify中Agent技能的核心是“应用”App。我们创建了多个应用供应链问答助手、运营日报生成器、异常订单分析员、供应商绩效评估师。以“供应商绩效评估师”为例它需要的核心能力是输入供应商名称查询该供应商在数据库中的交期、质量、价格数据结合知识库中的评分标准生成一份结构化的评估报告。这类任务的实现路径有两种。一种是在Dify的Prompt编排中把数据库查询写成Function Calling的工具函数让模型自行决定何时调用另一种是用工作流Workflow方式把流程固定成一个有向无环图开始节点 - 参数输入 - 工具调用查询API - 知识库检索 - LLM生成 - 结束节点。我的建议是数据查询链路稳定的场景用工作流固定流程、结果可控开放性问题多的场景用Agent模式给模型更多自主判断空间。WorkMate目前运行下来的经验两种模式共存效果最好。配置完成之后点击“发布”即可生成API访问地址。Dify支持多种渠道接入网页应用、ChatGPT插件、API调用对企业微信和钉钉的支持可以通过Dify的扩展机制实现。我们生产环境主要走API方式在企业微信机器人后端用Python将用户消息转发给Dify API再把结果推回企业微信群。整个链路非常轻盈业务人员在企业微信里就能完成所有操作。4. 人机协同的核心场景与运行机制4.1 人机协同不是“机器替代人”很多企业在做AI落地时会陷入一个认知误区AI上了线人就可以减少或者AI干完活直接给结果人就只负责看。但实际到供应链这种复杂业务场景中这种预期一定会落空。人机协同的本质是“能力互补”和“责任共担”。补给品需求预测、供应商谈判策略、紧急订单插单安排这些决策背后有大量说不清楚的“隐性知识”——客户关系深浅、供应商实际产能弹性、历史合作默契度、业务现场的特殊情况。这些信息不会完整记录在系统里也不可能被模型“学会”。所以WorkMate的定位一直是辅助者是增强人的感知力和计算力而不是替代人的判断力。具体到交互模式上我们把WorkMate设计成三层协同第一层是“我在现场查”业务人员主动向它提问快速获得数据和分析第二层是“它帮我盯”通过定时任务WorkMate主动监控业务指标并推送异常预警第三层是“我们一起定”针对重要决策WorkMate提供数据分析和多方案推演人在这个基础上拍板。这三层协同分别对应不同的使用深度也对应不同的人员能力要求。第一层人人可用第二层需要一点配置和调优能力第三层则更依赖业务人员自身的经验。但共同点是工具不会替你做决定而是让你的每一个决定都更有根据。4.2 典型场景一跨部门协作中的“翻译官”供应链管理天然是跨部门的采购、销售、仓储、财务、计划各有各的系统各有各的语言。一线管理者很多时间都耗在沟通和解释上采购问库存周转为什么这么慢销售问补货为什么还没到位财务问供应商账期为什么又延长了。WorkMate在这里扮演的角色是个“翻译官”。它把不同系统的数据拉通之后用一句话把关键信息解释清楚。举个例子仓储经理问“华东仓的空间占用什么时候会饱和”WorkMate不只是报一个“当前占用率80%”的数字它会结合未来四星期到货计划和出库预测给出一个趋势判断“按当前到货节奏第3周转运空间将达到阈值建议调整第3周的到货计划或提前启动部分出库。”这个分析过程看起来简单实际上背后做了大量工作查询WMS当前库存、读取采购订单的预计到货日期、结合历史出库数据做预测、把结果翻译成业务视角的建议。人看完这个结论后可以直接拿去跟计划部门沟通省掉了“找数据-做表格-自己想结论”的大半时间。这里要特别强调的是WorkMate的输出永远带着数据来源和置信度说明。如果模型不太确定某个推断它会明确说“这部分是根据历史趋势推测的准确度约80%”。这个设计很重要因为供应链决策错了是有真金白银损失的宁可让人保留怀疑也不能让AI显得全能。4.3 典型场景二异常预警与主动推送人机协同的另一个高频场景是异常预警。传统模式下业务异常往往靠人去发现——“这个订单怎么三天了还没出库”、“这个供应商最近怎么老延期”人发现问题的时候往往已经过去了一段时间损失已经发生。WorkMate的定时任务能力改变了这个模式。我们配置了一个“每日运营巡检”任务每天凌晨3点执行检查前一日的新增订单、未按期出库订单、库存低于安全线的情况、供应商交期延期比例生成一份巡检报告。早上八点业务负责人在企业微信里就能收到一份简报“昨日新增订单128单其中3单超过12小时未分配仓库华东仓有6个SKU库存低于安全线详情见列表XY供应商最近两周交期延期率上升到18%建议关注。”这套机制运行了两个月之后业务团队最大的感受是发现问题的速度变快了响应时间从以天计缩短到以小时计。有几次临时促销活动导致订单量激增WorkMate在当天中午就识别出仓库处理能力可能跟不上提醒计划部门提前协调了临时外包人员。这就是主动推送机制的价值——不等人发现问题让问题自己浮现出来。推动实现这个场景的技术细节也不算复杂Dify的“工作流”里有一个定时触发节点设定执行频率和调用参数即可。关键在预警阈值的设定不能太灵敏否则全是噪音也不能太迟钝否则失去预警意义。我的建议是先基于历史数据统计P90分位数作为初始阈值上线后根据实际误报率持续调参。4.4 典型场景三复杂决策前的“分析沙盘”第三层协同是让我自己最兴奋的场景也是WorkMate真正发挥大模型思考能力的场景——复杂决策前的多方案推演。举个例子公司计划在西南区域新设一个区域仓但建仓方式有自建、租赁、跟第三方物流合作三种选择。传统做法是让计划团队做一轮分析可能要花两周时间。WorkMate的做法是把要求的约束条件输入进去——目标区域、预计年处理量、投资上限、运营成本敏感度它会基于历史物流数据和行业基准生成三种模式的成本对比、时效对比、风险点分析并且支持追问“如果把年处理量提高30%三种模式的优劣势会怎么变化”这个场景复现出来的效果非常惊艳。业务团队可以在几十分钟内获得多维度、多假设的分析结果虽然最终决策还需要结合资金情况、战略方向综合判断但前期分析的时间成本被压缩了将近90%。这种场景的实现难点不在技术而在“知识储备”。WorkMate能够做推演是因为知识库里沉淀了大量行业分析框架、历史项目数据和标杆案例。如果知识库是空的模型只能泛泛而谈给出的建议没有参考价值。所以我的建议是在开放这类高复杂度场景之前先把知识库做扎实。5. 常见问题与排查技巧实录5.1 部署阶段的高频问题从零到一把WorkMate部署起来整个过程中我们踩了不少坑挑几个典型问题说说。问题一Ollama模型推理速度极慢一个简单问题要等几十秒。排查过程先看显存占用如果模型没有完全加载进显存大概率是KV Cache没有命中每次请求都重新加载部分权重再看并发请求多个用户同时问问题时Ollama默认的并发策略可能会导致排队。解决调大OLLAMA_NUM_PARALLEL环境变量把模型常驻显存避免swap到内存确保OLLAMA_KEEP_ALIVE设置较长的时间。问题二Dify工作流中调用数据库超时。排查过程先看是不是SQL写得太复杂、没有走索引再看连接池配置Dify默认的连接池比较小并发高时会出现连接等待。解决在数据库侧为大查询加索引或物化视图调大Dify配置里的连接池参数对于周期性大查询任务改为错峰执行。问题三知识库问答效果差检索到的文档片段完全不相关。排查过程先看切分策略是否合理原始的切片方式下SOP大段落被拆得七零八落再看Embedding模型效果通用Embedding对供应链专业术语的理解不够深。解决改用按标题分块策略保留章节结构在Dify的检索配置中把检索模式从“向量检索”改为“全文向量混合检索”召回效果提升非常明显。5.2 使用阶段的高频问题问题一AI回答的格式不稳定有时候给表格有时候给列表。解决在系统提示词中给出明确的输出格式模板并对结构化输出场景使用Dify的“输出格式”控制功能。如果还需要更严格的约束可以采用JSON Schema输出让模型以固定JSON结构返回数据再由前端渲染。问题二业务人员提问很口语化AI经常答非所问。解决给WorkMate配备一个“意图理解前置模块”把“这个月发货准不准啊”这类口语化问题归一化成标准查询参数。我们的做法是在Dify工作流中加了一个意图识别节点先让模型判断用户想查什么指标再生成对应的SQL查询效果比直接问数据库好很多。问题三权限控制不好做A供应商的业务人员能查到B供应商的数据。解决基于Dify的多租户能力改造每个供应商/客户对应一个独立知识库在应用入口处根据用户身份动态限定可访问的数据范围。数据库层面也通过视图隔离确保即便SQL被恶意构造也无法越权读取。5.3 项目复盘与运维经验总结WorkMate从部署到稳定运行整个项目走下来的经验可以总结成三条核心心得。第一条部署最大的难点不在技术而在业务梳理。大模型部署的技术栈已经很成熟了按文档操作基本能跑通但要把业务流程抽象成Agent技能需要业务方深度参与。我们的做法是前期花了两周时间把所有核心业务场景梳理成一张“场景-数据-决策”地图哪一步用什么数据、产出什么结果、由谁来验证全部搞清楚再动手开发。这个投入非常值得。第二条知识库的维护是长期工作不是上线就完了。业务文档在持续更新供应商信息在变流程制度也在变。我们设了一个“知识库运营”的轮值角色每周复核一次新增文档并更新向量库每个月复盘一次检索质量。不打理的知识库会越用越差检索准确率会肉眼可见地下降。第三条人机协同需要机制保障不能只靠工具。我们配套建立了“AI结果人工复核”制度对于影响金额较大的数据输出必须由人工确认数据来源和计算逻辑后再用于决策。这不是对AI不信任而是必要的风险管理机制。AI会有幻觉会有数据源变更导致的误判把人工复核嵌入流程是在效率和安全之间找了一个平衡点。最后再分享一个维护技巧。WorkMate用久了之后模型的表现会有轻微漂移尤其是知识库新增内容之后回答风格和引用逻辑可能发生变化。我们每个月会做一次“回归测试”准备好一组标准的测试问题集覆盖所有核心场景依次跑一遍对比回答质量和数据准确性是否达标。这个问题集平时都在维护和扩充每次模型升级、知识库更新后自动触发一轮回归能提前发现很多潜在问题。这套体系从部署到现在已经稳定运行了快半年。最让我欣慰的还不是技术侧的成功而是业务团队的态度转变——最开始很多人抱着试试看的心态现在是每天早上主动等着WorkMate的推报。这个变化说明它真的融进了业务流程里成了团队的一分子。AI在供应链里的价值说到底还是要看人愿不愿意用、用得顺不顺手。WorkMate这个项目的经验告诉我技术只是起点让人机协同真正运转起来、让每个业务人员都感受到AI带来的提效才是终局。