零售AI Agent Harness：打通库存与营销的智能编排实践

做零售数字化这几年见过太多“库存和营销打架”的场面市场部大促海报都出了仓库那边却告诉你爆款SKU只剩个位数这边刚把临期品做买一送一那边采购又补了一整批同款进来。说白了库存系统和营销系统各管各的是行业里最普遍也最顽固的问题。我最近把一个“零售AI Agent Harness”从设计到落地完整推了一遍核心就干一件事用一套Agent编排框架同时把库存流程和营销流程拉进同一个闭环管控里。这个项目适合正在做零售数字化、或者想在业务场景里落地AI Agent但不知道从哪下手的团队参考我尽量把架构思路、踩坑过程和关键实现都摊开来写。1. 项目背景零售AI Harness要解决什么问题1.1 零售行业“两套系统”的困局传统零售企业的数字化建设基本是两条线并行。库存侧有WMS、ERP里的库存模块营销侧有CRM、CDP、促销引擎两边数据库独立、口径不统一、流程割裂。结果就是营销活动的目标库存没人核对缺货商品还在投流库存报表靠次日凌晨跑批等到人工发现问题活动早打出去了。我们最开始想得比较简单觉得做几个API打通一下就行。但真上手才发现问题根本不在接口而在决策逻辑。库存侧关心的是“安全水位、补货时点、周转效率”营销侧关心的是“人群响应率、券核销率、GMV拉动”两边连优化目标都不一样单纯接数据不接流程依然是两条腿各走各的。1.2 Harness模式的核心思路“Harness”这个词直译是“线束、控制装置”放在Agent语境下更像一个编排底座把所有业务Agent、工具、事件、权限、审批统一挂在上面让它们共享一套状态和规则而不是各自放飞。我做的这个Retail AI Agent Harness核心是三个词统一接入、事件驱动、人机协同。它把库存Agent和营销Agent放在同一个运行时里库存变化直接产生事件营销Agent订阅这些事件来校准投放反过来营销活动开启前必须校验库存容量两者不再是“事后对齐”而是“事前协商、实时联动”。这套设计也决定了适配人群不是给你一套炫技的Demo而是适合手里真有零售业务、有库存和营销数据、想让Agent替人盯流程和做初步决策的团队。如果你们连基础的商品主数据和库存表都没有清洗干净那先别碰Agent先把数据底座补上。2. Harness整体架构与技术选型解析2.1 四层结构从Agent运行到底层依赖整个Harness我按四层切每一层职责单一避免Agent代码里塞太多业务逻辑。第一层是Agent运行时也是决策脑。库存Agent和营销Agent各跑一套状态机接收事件输入产出动作输出。第二层是工具层把库存查询、补货单创建、优惠券发放、人群圈选这些能力封装成Agent可调用的工具函数。第三层是共享记忆层所有Agent共享一套SKU画像、门店属性、历史销售特征向量避免每个Agent各存一份知识、口径飘了。第四层是事件总线库存变化、活动状态变更、审批结果都作为事件在总线上流转。为什么强调四层而不是直接把逻辑塞进一个Agent里因为零售业务流程天然跨域缺货会影响营销营销会反过来影响库存如果每个Agent各自处理两边对“缺货”的理解可能完全不同。共享记忆层保证它们是看同一份数据做决策工具层则保证动作是收敛的不会出现AI自己胡写一个库存数字的情况。2.2 技术选型的三个关键决策第一个决策Agent编排不用重型工作流引擎。一开始我考虑过主流的Low-Code流程编排平台发现它们更适合固定流程而零售库存和营销的联动规则变化太快比如大促临时改折扣策略、区域缺货切换替代商品硬编码在流程里维护成本很高。方案定为轻量状态机LLM决策内核规则面用可配置的Go/JSON策略文件控制模糊决策交给LLM。第二个决策事件总线用Redis Streams而不是消息队列。原因有三一是零售场景的事件量级其实是“高峰很高、平常很低”大促瞬间可能有几十万条库存事件Redis Streams扛得住且部署简单二是Harness是单体部署没必要引入独立MQ增加运维复杂度三是Redis Stream有消费者组和消息ACK正好满足Agent消费事件的可靠性要求。第三个决策LLM模型层面做分层。库存决策这种偏数值、要稳定的场景用规则引擎或函数计算主导LLM只做异常解释营销文案、人群圈选理由这种偏生成的场景才交给大模型自由发挥。分层使用让整条链路的成本可预估不会出现一次库存对话烧掉几万token。3. 库存Agent的核心实现与决策逻辑3.1 库存Agent的决策主循环库存Agent我把它做成一个事件驱动的循环不是一个被动问答的ChatBot。它订阅三类事件库存变动事件、补货到货事件、营销计划事件。收到事件后按四步走读取最新库存快照、判断水位与缺货风险、给出补货或调拨建议、输出结构化的建议事件给下游。为了让决策可控Agent的主循环把涉及事项收敛成清晰的状态变量。每个SKU对应一个状态机状态从常规、低库存、缺货、积压四态里选一个。状态迁移完全由量化规则触发比如库存天数低于阈值就进低库存等于零就进缺货高于某阈值就进积压。LLM只负责在状态确定之后补充解释性分析和异常排查方向不让模型直接拍阈值规避了幻觉。实现上我用一个Python异步服务跑了整个Agent生命周期。核心逻辑是维护每个SKU的最近库存事件窗口动态计算“未来7天预计消耗量”和现有库存一减就知道哪一天会触底。这个预测不搞复杂时序模型用需求均值加上季节系数预估零售场景里够用了稳定又容易解释。3.2 关键参数安全库存与补货量计算安全库存是所有库存决策的地基。我们不用拍脑袋的“备一个月”而是基于补货提前期和需求波动来算。某SKU平时代购需求日均20件供应商从下单到到货要5天安全库存标准公式取服务率95%对应的系数1.65再算上这5天里需求的标准差8件安全库存就是1.65乘8乘根号5约等于30件。补货量怎么定我们用的目标库存水位法目标库存等于日均需求乘以补货周期加安全库存。上面那个SKU日均20件补货周期5天加上安全库存30目标库存就是20乘以5再加30等于130件。现有库存如果只有50件这批建议补货量就是80件。这套公式写在策略文件里改系数不需要动代码排障时也一眼能看出数是哪来的。真正难的是动态修正。某新品上架后日均需求从5件爬升到15件按静态安全库存就会一路缺货。我们的解法是给SKU打上“趋势上升”标签系统自动把日均需求替换成最近14天加权移动均值让补货建议跟着爬坡走。这个修正逻辑是我踩过坑之后的补救第一版上线时新品缺货率一度干到18%后来就是靠加权均值拉回来的。3.3 库存事件输出的规范化库存Agent的输出不能是一句人话因为下游营销Agent还要消费。所有建议统一输出为事件消息包含SKU编码、门店编码、当前库存天数、风险等级、建议动作和时效窗口。比如消息的JSON结构基本长这样{ event_id: inv_20240618_1001, event_type: inventory_risk, sku_id: SKU_A001, store_id: STORE_BJ_03, current_days: 2.5, risk_level: high, suggested_action: urgent_replenish, suggest_qty: 80, trigger_ts: 2024-06-18T10:30:0008:00 }这套格式看起来简单实际价值在于“可机器消费”。营销Agent订阅到high风险的补货事件就会自动把该SKU从所有投放计划里摘掉而不是等人工通知。刚开始输出的字段太多太杂后面我们砍到只剩决策必需字段上下文输入成本直接降了三分之一。4. 营销Agent的核心实现与投放策略4.1 营销Agent的能力边界与触发场景营销Agent不是替代整个营销系统它聚焦在三件高频、规则清晰、又需要实时响应的事活动前的库存校验、投放人群的圈选调整、优惠券面额的动态生成。这三件事恰恰是传统营销系统处理得最僵硬的点——活动一旦创建很难修改人群包更是拍平了放在那边不动。场景一新品首销。营销Agent圈选首购人群同时订阅该新品的库存事件如果库存低于安全线自动把用户触达量调低20%而不是硬着头皮全量发券。场景二临期促销。库存Agent标记某批次商品进入“积压临期”状态营销Agent自动触发定向清仓活动给近期未购买但加购过同类目的用户推高阶优惠。场景三大促冲刺。营销Agent在促销开始前拉取所有参与SKU的库存快照跑一遍“库存余量除以预估销量”的覆盖率清单低于阈值的SKU直接标注风险并建议替换引流品。所以营销Agent的核心能力不是“写文案”而是做“决策闭环”我家促销动作是绑定库存状态的库存一变营销动作跟着变。这个设计逻辑一开始就要想清楚别把Agent做成ChatGPT套壳那样除了生成几句广告语对业务毫无推动。4.2 动态券面额一个可复用的计算模型优惠券面额过去靠经验拍我们改成了带约束的求解逻辑。基础公式很简单券面额等于客单价毛利的某个比例但要叠加两个系数库存周转系数和人群敏感度系数。拿一款毛利额30元的商品举例基础券值取毛利的40%是12元。如果它库存积压系数达到1.2面额上调10%变成13.2元如果目标人群的领券转化率偏低敏感度系数再打0.9最终面额就是11.9元。整套计算是确定性函数Agent把参数填进去输出多少就是多少。为什么不做成LLM自由发挥因为券面额直接记入财务成本不可控的Token输出等于让AI替财务拍板这在真实零售公司过不了审。我的做法是LLM负责判断“这个库存积压需要刺激”量化面额一律走函数计算。这样既保留了灵活性又保证每一笔优惠都能追溯计算过程财务审计的时候拿数据说话。另一个容易漏的细节是“券叠加控制”。营销Agent生成优惠券事件时必须携带幂等键通常是用户ID加活动ID加SKU编码的组合。不然后台一个重试同一个人被重复发券用户当然开心但财务会疯掉。这个点在测试环境完全暴露不出来必须压测加日志双重检查。4.3 营销内容生成与渠道投放的联动人群圈选完了、券面额定了还有一公里是内容生成和渠道投放。内容生成这块我们走了不少弯路。第一版让LLM自由写文案结果每一轮生成风格都不一样促销利益点的排序也乱用户根本抓不住重点。后来改成标准化模板加变量填充利益点统一首句强调券面额第二句讲适用品类第三句给到期提醒LLM只负责生成个性化前缀词和地域性口语表达这样测试下来点击率反而涨了12%。投放渠道联动靠事件订阅实现。库存Agent发出的“临期积压”事件会触发营销Agent匹配渠道策略高客单商品走私域和App push低客单快消品走短信加小程序弹窗。渠道的选择逻辑写在策略表里什么级别的风险事件配什么渠道组合全部可配置Agent只负责执行和反馈投放结果。我强烈建议营销Agent的每一次投放结果都回写成一个事件比如“campaign_feedback”包含了展示量、点击量、券领取量。这些事件会成为库存Agent后续判断“促销是否有效去化库存”的依据两边的数据就真正闭环起来了。5. 两个Agent的协同机制与安全护栏5.1 事件驱动的反向补偿机制库存和营销协同如果只做单向“营销看库存”就还停留在数据打通阶段。真正把Harness价值发挥出来的是反向补偿营销活动效果反过来影响库存策略。举一个真实跑通的场景。某门店的奶酪品类给高活跃用户推了满减券投放三天后核销率高达40%仓库那边在第四天感知到库存快速下滑库存Agent自动把补货提前期从7天压缩到3天并加量50件。这就是反向补偿营销带来的销量波动直接反哺到补货决策两边不再分前后端而是一个相互校准的回路。这个机制落地依赖事件总线的Topic设计。我们分成三条主Topicinventory_events、campaign_events、decision_events。库存Agent和营销Agent分别向自己的主Topic发消息同时订阅对方的通知Topic。有些同行做Agent协同让两个Agent直接对话我的建议是别这样Agent间的自由对话既难控制又难审计都要通过事件总线转一手谁发了什么、谁消费了什么一目了然。协同链路里最容易翻车的就是时序和重复消费。两个Agent都订阅了库存变化大促高峰期一条SKU的库存事件一小时内可能更新十几次如果每个事件都触发一次营销动作高维发券就成了灾难。我们的处理方式是在Harness层做“窗口去抖”同类事件在5分钟窗口内只取最新一条进入决策并给每条营销动作生成独立的activity_id做幂等控制。这个参数我建议按业务节奏调大促前改到1分钟日常跑量用5到10分钟即可。5.2 人审闸门与灰度放量的落地方式AI Agent再靠谱在零售这种直接涉钱、涉货的场景里也不能完全撒手。Harness里我做了三级动作分级绿灯动作Agent直接执行黄灯动作要带预设条件执行红灯动作必须等人审批。绿灯动作包括低风险提示、库存预警、常规补货建议黄灯动作包括折扣比例在10%以内的优惠券发放、投放人群的规模和渠道调整红灯动作包括超过20%的折扣、清仓价格修改、大范围停售。绿灯和黄灯的可执行条件全部是精确数字不允许LLM自己解释“差不多可以发”只能走策略判断。审批流拉了一条人工介入通道红灯动作产生时Harness会先把完整决策链路打包成审批请求推给值班人审批人只需要看三个字段触发条件、建议动作、预估影响。如果数值都正常一键通过如果不对可以退回修改数值。上线第一个月我们其实是让审批人把所有黄灯动作也过了一遍收集了大量Agent“太激进”的反馈然后逐条调策略参数。灰度放量我也提一下经验Agent全量上线之前拿两个同体量门店跑一版对比。同样营销预算、同样库存池一边开Agent自动决策一边沿用人工经验。跑两周看周转率和毛利变化数字说明问题别凭感觉说Agent有用还是没用。6. 落地过程中的问题排查与效果度量6.1 典型故障排查速查表这个Harness从开发到稳定Bulletin里记了不下二十个问题挑几个最典型的列在这里给后面做类似项目的留个参考。故障现象根因分析解决方案Agent重复发券事件重试导致同一活动多次消费增加幂等键用户ID活动IDSKU组合去重补货建议突然跳变某天销量为0导致均值计算为负日均需求改成加权均值并加下限保护库存数据延迟夜间同步导致Agent读到前一日旧数据事件总线切实时推送保留15分钟对账LLM回答不一模型对同一SKU给出歧义描述状态判断全部收敛为确定性规则LLM只做解释大促流量打崩高频事件全部进决策队列加窗口去抖高频重复事件只保留最新值活动审批积压夜间红灯动作没人审核加值班人轮转支持审批接口移动端处理排查的过程里我得到一个很深的体会Agent出问题八成不是模型不行而是数据口径和事件治理没做好。很多问题都是数据脏导致的比如负数库存、门店编码不一致模型再聪明也没办法从脏数据里推岀正确动作。6.2 效果度量指标与预算归因Harness整体的效果度量不能只看一个指标要拆成两层一层是流程效率另一层是业务结果。流程效率层面我们重点看三个数库存预警到补货动作的平均时长、营销活动从创建到投放的分钟数、需要人工介入的决策占比。Harness上线后库存预警到补货建议生成从原来的30分钟降到了秒级一个大促活动从配券到投放从半天缩到20分钟人工介入率稳定在15%以下。业务结果层面追踪的是库存周转天数和营销投资回报率。因为库存和营销的优惠面额绑定我们能做到单SKU级别的归因哪一次活动消耗了多少库存、带来了多少毛利直接关联起来看。一段时间跑完之后统一算出整体数值。做这类归因最忌讳的就是活动太多造成互相污染我们的处理方式是同一SKU在同一时间窗口避免并行活动实验设计上保持干净。预算分配上也给了Agent一个明确的边界思路每一档活动先锁死最大预算池Agent只能决定“池子里的钱怎么发”不能决定“池子要多大”。这样即使Agent决策翻车损失也是可控的不会出现一夜之间把整月营销预算打光的情况。最后分享一个个人体会。做这个Harness技术难度其实没有想象中那么大真正难的是一开始就要想清楚哪些决策交给Agent、哪些留给规则、哪些必须人审。我的经验是规则能做的绝对不给模型模型只做规则覆盖不到的判断和解释。别为了AI而AI零售业要的不是一个会说话的库存系统而是一个能替你盯着库存和营销流程、发现风险、给出合理动作的可靠助手。先把边界划好再让Agent进来这东西才真的能在门店端和运营端扎下根。