1. 开场这件事到底解决什么问题干了十年企业信息化我有一个很深的体会大部分供应链系统不是被技术难死的而是被“岗位墙”和“改造恐惧”拖死的。仓库不知道采购的到货计划采购看不到销售的真实波动财务拿着三份对不上的报表运营在群里一遍遍催人——这些场景每天在无数企业重演。AI在这中间能做什么不是搞一个炫酷的数字人也不是上一套跟现有业务毫无关系的“智能大屏”而是把分散在各岗位、各系统里的信息变成能被机器自动理解、自动流转、自动裁决的流程。这也是我想写“兆企供应链管理AI应用白皮书”系列的初衷。第三篇重点落在两件事上跨岗位协同与系统渐进改造。前者是AI真正产生业务价值的场景所在后者是让AI能在一个真实、复杂、充满历史包袱的IT环境里落地的唯一现实路径。简单说这篇内容适合三类人一是正在做供应链数字化转型的甲方信息化负责人二是给制造业、零售业、农产品流通企业做系统的乙方顾问和实施工程师三是刚入行想搞明白“AI Agent在企业里到底怎么用”的产品经理和研发。我会尽量讲人话不绕概念把我在实际项目中踩过的坑和相对有效的做法都摊开聊。2. 跨岗位协同为什么AI在这里更有价值2.1 供应链岗位协同的典型断点供应链从来不是一条单线条的流水线而是一张多角色交织的网。一个订单从客户下达到最终交付至少要经过销售、计划、采购、仓储、物流、财务六个岗位。每个岗位都有自己的系统——CRM、ERP、WMS、TMS这些系统之间往往只有薄弱的接口甚至完全靠人来搬运数据。我见过最典型的断点场景是销售在CRM里录入了一个大客户订单交期很紧。但这个信息要经过计划员二次录入到ERP里采购员看到的是昨天甚至上周的缺料报表仓库知道自己有库存但不知道这批货优先级最高物流排在最后等所有环节反应过来三天已经过去了。这里面的问题不是某个人不努力而是信息在不同岗位之间的传递存在结构性延迟。更麻烦的是流程断点。采购订单确认后没有自动通知仓库准备库位到货之后没有自动比对采购单和送货单质检结果没有实时回传给库存状态。每一个断点都意味着一次线下沟通一次微信一次“这个单子卡在哪了”的追问。AI在断点处的价值不是替代某个岗位的人而是充当一个“永不掉线的协同调度员”。它把各系统产生的数据汇总到一个语义统一的视图里在关键节点自动触发动作并让每个岗位只看到与自己相关的、经过推理的信息。这个定位听起来不复杂但真正实施起来第一个要解决的其实是共识问题——不是技术共识而是业务共识。2.2 业务共识比技术选型更难我在推进项目时反复遇到一个现象业务部门对“协同”的理解完全不一致。仓储认为协同就是把库存在系统里共享出去采购认为协同是让供应商能直接看到预测订单销售认为协同是让我随时知道这批货能不能按时交付。如果一开始就急着上AI Agent大概率会做成一个“什么都是但什么都不精”的大杂烩。正确做法是先画一张岗位触点矩阵。横轴是被协同的核心对象——订单、库存、交期、质量、成本纵轴是参与岗位和对应系统。把每个对象在“信息产生—信息流转—信息消费”三个环节中的状态列出来哪些地方连续哪些地方断裂一目了然。这意味着AI的应用边界要足够清晰不需要覆盖所有协同场景优先解决那些按规矩办事但效率极低、出错率极高的场景。这里面最容易“出成绩”的通常是三类订单交期承诺跨销售、计划、生产、仓储四个环节的滚动应答。采购到货异常处理涉及采购单、送货单、质检单三单匹配。库存预警与调拨建议涉及多仓库存水位、销售预测与在途数据。这三类场景有一个共同特点规则明确、数据结构化程度高、人工处理量大。AI在这里可以立刻产生可量化的收益也为后续更复杂的非结构化协同场景打下信任基础。2.3 AI能改变的四个协同层次根据我的实操经验AI参与跨岗位协同可以分成四个层次每个层次的实施难度和业务价值递增。第一层是信息聚合层。把散落在各系统中的数据拉通形成统一的业务视图AI做的事情主要是数据清洗、实体对齐和相关性分析。这个层次解决的是“看不见”的问题技术上是可行的因为它不改变任何既有流程只是让每个人看得更全。第二层是异常感知层。AI持续监控流程指标发现偏离常规的情况——比如订单交期风险、库存低于安全水位、到货数量差异、应付账款账龄异常——自动分类并按岗位推送。这层解决的是“顾不上”的问题本质上是把原来依赖老师傅经验才能发现的隐患变成系统性的即时信号。第三层是决策建议层。AI不仅告诉你“有问题”还告诉你“怎么办”。比如缺料时建议替代料方案产能冲突时建议调整排产优先级物流延误时建议切换运输方式。这一点上的关键是“建议”而非“决定”人在回路上仍然掌握最终审批权。第四层是流程执行层。AI Agent在权限范围内直接推进流程比如自动创建调拨单、自动触发补货申请、自动向供应商发送交期确认请求人在事后审核。这层的价值最大但信任门槛也最高通常需要在前面三层运行稳定后才逐步放开。多数项目死在跳跃式实施上——第一层还没做扎实就急着上第四层。我个人的原则是每一层至少稳定运行一个业务周期通常是3个月再谈下一层看起来慢但整体反而快。3. AI Agent到底怎么介入流程3.1 Agent不是聊天机器人现在一说AI Agent很多人的第一反应还是对话框。但在供应链协同场景里Agent的核心形态不是“对话窗口”而是一组运行在业务流程中的自主执行体。它感知事件、理解上下文、做决策、调工具、走流程最终把结果写回系统。举个例子采购到货异常处理。以前是仓库收到货发现数量比采购单少了5%于是拍照、记录、微信发给采购采购再判断是否接受短装、是否补发、是否调整订单整个过程可能耗时半天。现在引入Agent后流程变成这样仓库扫码入库WMS产生到货差异事件。差异事件进入Agent的消息管道Agent自动调取采购单、送货单、历史到货差异率。Agent根据预设策略推理短装比例在允许范围比如3%以内则自动通过并更新采购单状态超过3%则生成异常工单附带处理建议推送给采购员确认。采购员在消息卡片上点击“同意”或者“修改”Agent把结果回写WMS和ERP。这里Agent做的事情不是聊天而是把原来需要人工查阅多个系统、判断规则、发起流程的工作变成了一个自动化的推理-执行循环。3.2 一个可落地的Agent工作流配置我习惯用一个比较朴素的方式描述Agent工作流——把它拆成四段触发条件、上下文组装、策略决策、动作执行。每一段都需要业务人员和工程师一起定义清楚。以农产品销售系统中的“订单分配”为例。一个B端客户下单10吨苹果要求72小时内送到系统里有多个产地仓和协作供应商。传统做法是客服手工判断从哪个仓发货容易受个人经验影响忙的时候干脆按地域就近发不考虑库存和成本。配置Agent时触发条件是“新订单进入待分配状态”上下文组装是把客户地址、各仓实时库存、各仓到该地址的平均时效、当前运力情况、商品批次信息全部拉过来策略决策部分是一个综合排序模型优先级从高到低依次是满足时效要求、库存充足、物流成本最低、批次新鲜度最高动作执行则是调用ERP生成销售出库单通知对应仓库备货并把分配结果回传客服工作台。这里有个容易被忽略的工程细节Agent的决策过程一定要有痕迹。每一步为何选了A仓而不是B仓都要有日志记录客户问起来能解释。否则一旦出问题客服和业务都无法向客户交代。3.3 提示词与知识边界技术团队容易对提示词工程着迷但在这种企业级场景里提示词只是很小一部分。真正决定Agent效果的是两块一是决策所依赖的知识是否准确完整二是Agent的权限边界是否清晰。知识的问题尤其隐蔽。供应链领域有很多“隐性规则”不在任何文档里比如某家老客户虽然下单量不大但下半年会有大单所以即使当前批次库存紧张也优先保证又比如某个产地的苹果虽然价格便宜但客户上次投诉过糖度问题分配时要降权。这些规则写不进标准提示词但可以沉淀到知识库或者规则引擎里让Agent在决策时能够引用。权限边界则更多是治理问题。我在项目里坚持一个原则Agent只能建议不能擅自承诺。对外给客户发送交期确认、价格调整、赔付方案这类动作一律走人工审批通道。对内可以自动执行库存调拨、采购申请、单据更新但要有操作审计和回滚机制。企业用了AI不是要把责任推给AI而是让AI帮人把活干得更快更准责任人始终是岗位上的那个人。4. 渐进改造为什么不能推倒重来4.1 存量系统的三个现实在谈论“渐进改造”之前先接受三个现实。第一企业核心系统可能已经运行了十年以上。我见过一家制造企业的ERP还是十多年前基于旧平台定制的MES是另一个厂商做的WMS更离谱是IT自己用Excel加数据库拼出来的。这种环境下谈“全面上云”“全面替换”根本不现实成本高、周期长、风险大。第二业务不能停。供应链系统7×24小时在跑不可能为了上AI停线三天做数据切换。渐进改造的核心原则就是在不中断业务的前提下把AI能力逐步嵌入到既有流程中。第三组织和人员的适应需要时间。每个岗位对新系统的接受速度不同操作用户尤其是仓库、质检这些一线环节对界面变化非常敏感。一次性大变样会让培训成本激增、异常频发最终项目死在推广环节。这三个现实决定了务实路线只有一条在存量系统上做增量叠加让AI先以“辅助工具数据服务”的身份进入业务流程再逐步向“流程参与者”过渡。4.2 渐进改造的三个阶段按我的经验一个典型的渐进改造路径可以划分为三个阶段。第一阶段是工具嵌入期大约1-3个月。这个阶段AI不碰核心流程只在关键岗位旁边加一个“智能助手”。比如仓储主管的智能看板——把WMS数据拉出来用自然语言就能问“今天哪些SKU出库量最大”“哪些订单有超时风险”再比如采购助理的供应商画像查询——输入供应商名称自动汇总交货准时率、质检合格率、价格趋势。这些功能不改变任何岗位的操作习惯大家用不用、用得好不好都不影响正常业务运行。这个阶段的目的是建立信任、验证数据质量、积累真实使用反馈。第二阶段是流程辅助期大约3-6个月。AI参与到具体的流程环节但它做的是辅助判断和信息流转最终决策仍然由人完成。比如前文提到的到货差异工单建议、订单分配建议、库存调拨提醒。这个阶段要把AI的准确率、误报率、处理时效等指标纳入监控每周复盘。技术团队需要重点关注的不是模型本身而是数据管道是否稳定——只要有一个系统接口改动了整个Agent的上下文就可能缺一块。第三阶段是协同执行期大约6-12个月。在置信度足够高的场景里把部分确定性流程交给Agent自动执行人工转为审核角色。比如自动对账、自动补货、自动生成采购建议单并推送供应商。这个阶段才能真正释放人力让供应链团队从繁琐的事务性工作中腾出手来去处理真正需要经验和判断的例外情况。4.3 选型与架构叠加层思路渐进改造的架构选型我通常推荐叠加层思路。简单说就是在现有系统之上加一层“智能协同层”这层负责连接AI能力和业务系统但不替代任何存量系统。这个叠加层通常包含四个组件数据接入组件负责从ERP、WMS、MES、TMS、CRM等系统采集数据做清洗、标准化、实体对齐。这是整个架构里最脏最累也最容易被低估的模块。事件中枢负责在各系统之间传递业务事件。采购单创建、到货登记、库存变更、质检完成等事件在这里统一建模、统一路由。Agent运行引擎承载各种AI Agent的注册、触发、决策、执行、日志记录。这个引擎需要和事件中枢深度集成同时提供人工审批的回旋空间。统一知识库沉淀供应链的业务规则、异常处理经验、商品属性、供应商信息等让Agent在决策时有“常识”可以引用。四个组件尽量用成熟技术搭建不建议从零开发。事件中枢可以直接用消息队列产品Agent运行引擎可以基于开源框架二次开发知识库用向量数据库加传统关系库混合存储。我们要解决的是企业供应链里的具体问题不要在基础设施上重复造轮子。5. 改造过程中的数据与权限治理5.1 主数据不干净AI就是加速器“垃圾进垃圾出”这句话在AI场景里被放大得更厉害。因为传统报表系统遇到脏数据至少人眼能看出来异常AI Agent如果被喂了脏数据可能会一本正经地按照错误信息去触发采购、调整库存、通知客户后果严重得多。我参与过的项目里最常见的脏数据有三类物料编码不统一。同一个商品ERP里一个编码WMS里一个编码Excel台账里又是另一个叫法。不做实体对齐Agent一调库存就乱套。供应商信息重复。一个供应商在系统里有三四个名称变体历史合作记录被切碎画像完全失真。库位主数据缺失。不少企业的WMS里库位信息长期不维护仓管员靠记忆找货AI按系统数据发出库指令大概率会扑空。渐进改造的第一阶段之所以要从“工具嵌入”做起很大程度就是为了在不侵入流程的前提下先把这些基础数据问题暴露出来、清洗干净。等Agent真正接业务流程时注入的数据至少是可信的。5.2 灰度发布与回滚机制AI功能上线不能像传统系统一样“一次性切换”。我在实际操作中会做三层灰度第一层是场景灰度。新功能先在一个品类、一个仓库、一个供应商群体里试点验证效果后逐步扩展到全部业务范围。比如智能补货先跑苹果品类跑顺了再上梨、蔬菜这些品类因为不同品类的保鲜期、损耗率、销售节奏差异很大。第二层是角色灰度。同一功能对不同岗位开放不同权限。比如到货差异处理建议先对采购经理开放再逐步下放给采购专员先对资深仓管员开放再普及到所有值班员。让“先用起来的人”成为布道者而不是让没有决策经验的员工直面不确定的AI输出。第三层是流量灰度。技术上支持按比例放量——先让Agent处理10%的工单人工处理剩余90%对比准确率和效率之后再逐步调高到20%、50%直到达到目标水位。这一层需要技术架构一开始就设计好开关不能事后补。回滚机制同样关键。每一类Agent动作都要有“一键停用”能力——不是停系统而是把某个Agent的权限立刻收回到人工。再准备一份回滚操作手册明确定义谁有权触发、执行步骤、回滚后如何补偿数据。5.3 权限治理与审计跨岗位协同的天然矛盾是为了让AI能够端到端地处理流程它需要触达多个系统的数据但同时每个系统都有自己的权限模型AI不能“越权”。我的做法是为AI设置独立的服务账号而不是复用某个人的账号。这个服务账号的权限按最小必需原则配置能读的才读能写的才写而且写操作必须有独立审批流。所有Agent的动作记录要做到“四个W”——谁哪个Agent、何时、操作了什么数据、基于什么策略——全部入审计日志。财务和合规部门对这一点非常敏感项目前期提前跟他们对齐会省很多事。6. 常见问题与排查技巧实录6.1 问题速查表问题现象常见原因排查方向Agent给出的建议明显不合理上下文数据缺失或过期检查数据接入组件的同步时效确认关键字段是否完整同样的数据Agent的判断和老师傅不一致规则库里缺少隐性经验把老师傅的判断逻辑显式化沉淀到策略配置Agent触发动作后下游系统没反应接口权限或数据格式不匹配检查服务账号权限、接口字段映射、消息队列消费情况效率反而不如人工使用路径太长操作繁琐简化交互把Agent入口嵌入原有工作台而不是新增一个平台业务人员不敢用对AI输出缺乏解释强化决策痕迹展示完整推理过程让结果可解释可追溯新系统上线后旧流程又恢复回流培训不够缺少激励机制把AI使用纳入岗位考核阶段性地公示效率对比数据这份速查表是从十几个项目的复盘里提炼的每条背后都是真实踩坑的教训。其中“效率反而不如人工”这条我特别想强调很多AI项目失败不是因为技术不行而是产品交互设计得太“AI”了——非要人切到另外一个系统去看结果。正确做法是让AI“长”在用户已有的工作界面上无论是企微、钉钉还是ERP自带的门户。6.2 踩过的一些典型坑第一个坑是项目一开始就想做全流程打通。前期需求调研花了两三个月画了非常完整的流程图结果真正实施时发现光是把六个系统的接口打通就要排五个版本周期。后来改成“先跑通一个最小闭环”只做采购订单到仓库预约入库这一段两周上线业务看到了效果后面推进就顺畅了。第二个坑是忽略了异常处理路径的设计。开发团队把精力都放在主流程自动化上但业务实际上有大量“流程外”的情况供应商提前一天送货怎么办质检发现批次不合格但客户急等货怎么办这些没有预判到位一线用户遇到一次异常走不通就不再信任AI前面累计的信任度会瞬间清零。第三个坑是对提示词和模型能力期待过高。供应链场景里有大量数值计算和规则判断大模型本身并不擅长精确计算。所以我的方案里Agent看起来是“智能决策”实际上背后挂了很多规则引擎、约束求解器和计算公式大模型更多承担的是意图理解、语义匹配和文本生成。把模型放对位置效果会好得多。6.3 关于“人的问题”最后想说的技术层面的东西聊了很多但整个项目真正决定成败的往往是“人的问题”是否处理好。仓管员不愿意扫枪操作采购员担心AI抢饭碗计划员觉得新系统增加工作量——这些声音真实存在。我的经验是不要试图说服所有人先找到每个岗位里愿意尝鲜、有一定话语权的“种子用户”花时间陪他们把流程跑顺让他们成为内部推荐者。效果比开十场全员培训会都好。另外对一线操作人员AI系统能不能“少录入、多提醒”非常关键。能自动读取的坚决不让人填能消息推送的坚决不做成待办列表。任何新增的操作动作都要想清楚它带来了什么对冲价值否则就是给一线添堵。跨岗位协同最难的不是系统拉通而是让各岗位的人相信这套东西能让我少背锅、少加班、把活干得漂亮。想清楚这件事技术方案自然就有了方向。从一个更长的时间维度来看跨岗位协同与系统渐进改造是供应链智能化的基本盘。基本盘打得扎实后面再上更复杂的预测优化、多级库存协同、端到端控制塔都是顺势而为的事。AI在这个领域还远没到拼算法的阶段拼的还是谁能更务实地理解业务、更耐心地打磨每一个流程细节。