零售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:00+08: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设计。我们分成三条主Topic：inventory_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出问题，八成不是模型不行，而是数据口径和事件治理没做好。很多问题都是数据脏导致的，比如负数库存、门店编码不一致，模型再聪明也没办法从脏数据里推岀正确动作。

6.2 效果度量指标与预算归因

Harness整体的效果度量，不能只看一个指标，要拆成两层：一层是流程效率，另一层是业务结果。

流程效率层面，我们重点看三个数：库存预警到补货动作的平均时长、营销活动从创建到投放的分钟数、需要人工介入的决策占比。Harness上线后，库存预警到补货建议生成从原来的30分钟降到了秒级，一个大促活动从配券到投放从半天缩到20分钟，人工介入率稳定在15%以下。

业务结果层面，追踪的是库存周转天数和营销投资回报率。因为库存和营销的优惠面额绑定，我们能做到单SKU级别的归因：哪一次活动消耗了多少库存、带来了多少毛利，直接关联起来看。一段时间跑完之后，统一算出整体数值。做这类归因最忌讳的就是活动太多造成互相污染，我们的处理方式是同一SKU在同一时间窗口避免并行活动，实验设计上保持干净。

预算分配上也给了Agent一个明确的边界思路：每一档活动先锁死最大预算池，Agent只能决定“池子里的钱怎么发”，不能决定“池子要多大”。这样即使Agent决策翻车，损失也是可控的，不会出现一夜之间把整月营销预算打光的情况。

最后分享一个个人体会。做这个Harness，技术难度其实没有想象中那么大，真正难的是一开始就要想清楚哪些决策交给Agent、哪些留给规则、哪些必须人审。我的经验是，规则能做的绝对不给模型，模型只做规则覆盖不到的判断和解释。别为了AI而AI，零售业要的不是一个会说话的库存系统，而是一个能替你盯着库存和营销流程、发现风险、给出合理动作的可靠助手。先把边界划好，再让Agent进来，这东西才真的能在门店端和运营端扎下根。