零售AI Agent Harness：库存与营销协同的治理框架

1. 这个项目到底在解决什么问题做零售的人应该都经历过这种场面市场部为了冲业绩激动地说要把前300个热销品全部打7折仓库的同事当场翻出库存表——其中有87个SKU只够卖三天活动还没结束就会断货。财务在旁边冷着脸说上季度周转天数又涨到80多天了。这类冲突几乎每天都在发生因为库存和营销根本就是两套逻辑在跑而负责协调的人往往只能靠Excel和开会拍板。我最近做完的一个项目就是围绕这个问题来的。项目代号是零售AI Agent Harness核心目标是把库存管控与营销流程放进同一个可编排的Agent体系里用大模型Agent去做跨域判断再通过工具层和规则引擎约束住这些判断让AI真正能干活又不至于乱来。简单说Harness不是某个单独的AI助手而是一整套Agent治理框架——给Agent配上工具、限定权限、套上校验、留下审计最后才敢让它们自动操作库存系统和营销系统。这篇内容我会从方案设计、关键参数、落地实操、踩过的坑这几个层面完整复盘一遍。如果你正在做零售数字化转型或者你们团队有自研系统但还在用规则脚本处理库存和营销协同那这篇文章应该能给你不少参考。1.1 零售链路里最扎心的两个数字先回到业务本身。我之前帮一家快消零售企业做过一段调研他们的SKU有8000多个分布在中心仓、门店仓、电商前置仓三类节点。每个月末库存周转天数和缺货率是最扎心的两个数字周转天数高说明积压严重资金全压在仓库里缺货率高说明销售机会在白白流失。这两件事其实是对立的库存备多了积压备少了缺货而营销活动恰好是打破平衡的最大变量。现实中大多数公司的处理方式是什么市场部看销量做促销方案仓库凭经验和历史数据说这个不能卖、那个要清仓最后靠一个采购经理或运营总监来平衡。这个模式在SKU少、渠道单一的时候还勉强能用但一旦到了几千个SKU、全渠道、实时促销的复杂度人就根本盯不过来。信息滞后加上部门目标不一致结果就是促销打得正猛热门款断货了没人管的冷门款库存一年都没动过。1.2 为什么是Agent而不是传统脚本有人会问这类问题不是用规则引擎也能解决吗比如写成库存低于安全值就自动补货毛利低于多少就不让打折。没错纯规则脚本能解决一部分问题但它最大的软肋是不会理解上下文。零售场景里大量决策信号是非结构化的客服那边有人在问某款商品最近会不会补货运营日报里写着某平台流量即将上涨竞品海报里透露出下周要搞一次大的价格调整。传统规则引擎接不住这些信息也做不到把这些信息跟实时库存、销售数据放在一起综合判断。而大模型Agent可以它能读文本、能提取信号、能看数据然后做出一个更接近人类运营管理者的决策。但Agent也有致命问题——幻觉和不稳定。它可能上一秒还正常下一秒就把补货数量填错或者根据训练期里的过时知识猜测一个价格。所以这个项目真正的难点不在于用Agent而在于怎么安全地让Agent干活。这也是Harness这个词的含义它像马具一样给Agent能力同时也给它套上缰绳把它的自由度限制在可控边界之内。1.3 这个方案的适用边界我先把话放在前面不是所有零售团队都需要上这套东西。如果你只有几十个SKU、两三个渠道Excel加一个有经验的运营完全够用上Agent反而是给自己找麻烦。这套方案真正适合的是已经有中台或数据基础、SKU过千、多仓多渠道、库存和营销决策频率高且已经频繁掉链子的团队。另外还要有个心理准备搭建这个Harness至少需要三块能力——数据管道把库存和销售数据洗干净、工具层能安全地调用业务系统接口、以及一点LLM工程经验。别指望一个后端工程师一周能全干完。我们当时是数据组、运营组和算法组各出人花了两个月才跑通第一个完整的决策链路。这个投入产出比对于业务规模上的团队是完全值得的。2. 核心架构与设计思路先讲架构。Agent Harness听起来高大上拆开其实就是四层感知层、决策层、执行层、校验层。感知层负责把各个系统的数据同步进来决策层跑大模型Agent执行层通过工具函数操作业务系统校验层在每一步动作生效前做硬性检查。这四层缺一不可尤其是校验层它才是Harness的关键。2.1 整体结构感知、决策、执行、校验感知层我们接了三类数据源ERP库存表、OMS在途单、第三方电商平台的实时库存。同步频率按业务重要性分开核心SKU的库存15分钟拉一次长尾SKU一小时拉一次营销活动期的数据直接走实时接口。决策层放了三个子Agent库存调度Agent、营销策略Agent、跨域协同Agent。它们之间不是互相聊天的关系而是各出方案、再由协同Agent合并成一个动作序列。这样做的原因很实际如果每个Agent都直接调用系统冲突根本避免不了先各自出方案再统一裁决至少能保证同一个SKU不会被两个Agent同时操作。执行层就是一组工具函数也就是Agent能动手的边界。工具越少越安全我们一共只注册了十来个函数覆盖查库存、创建采购单、改促销折扣、调整投放预算、查询预测等。校验层则是一套硬编码规则引擎任何Agent动作都必须先过一遍不过直接打回。模块职责关键输出感知层同步库存、销售、在途、活动计划数据标准化商品维表和库存快照决策层库存Agent、营销Agent分别产出建议结构化动作提案协同层合并冲突决策、排定动作顺序最终动作序列执行层调用业务系统API实际执行结果校验层拦截不合理动作触发人工审批通过/打回/转人工2.2 库存域Agent怎么管补货与周转库存调度Agent的日常是回答三个问题要不要补货、补多少、按什么优先级补。它的输入不是简单一个当前库存而是一组信号实时库存、最近30天日均销量和标准差、采购提前期、在途订单、供应商历史交期波动。这些信号汇总后Agent会判断某款商品是稳定补货、紧急补货还是滞销需要触发清仓建议。为什么这一步让Agent来做比规则引擎更合适举个例子某天下午客服系统里有几条对话都在问XX型号的保温杯还会不会补货同时运营日报提到某短视频平台突然带火了这个品类。这些是非结构化信息规则引擎根本没法读但Agent可以。它会判断短期需求大概率会上冲进而把补货优先级调高。这类靠嗅觉的决策正是大模型Agent的价值所在。不过要注意库存Agent给出的是补货建议不是直接下单。采购单无论金额大小都要经过校验层和采购模块负责人确认只是确认时间从原来的一天缩短到现在的几分钟。这个控制权让渡的度很关键千万不要一上来就全自动。2.3 营销域Agent怎么控促销与投放营销策略Agent负责的事包括从几千个SKU里筛选适合参加活动的商品、给出折扣档位、分配各渠道投放预算、对比竞品价格调整空间。光说筛选其实已经很难了规则很难定义什么叫适合做活动。我们给Agent的约束是商品毛利率必须高于30%近7天转化率不能是下滑的库存覆盖率至少要撑得起一场活动的预估销量。只有同时满足这三个条件才有资格进商品池。另外还定了一条铁律任何折后价不得低于成本价这条不是靠Agent自觉而是校验层里写死的规则。预算投放也一样。Agent可以提出某个渠道的日预算上调20%但上调超过50%或者导致当日总预算超限时必须转人工审批。大促期间还会额外加一个熔断器日预算消耗到80%自动暂停投放防止Agent看到数据好就越花越多最后预算被烧穿。2.4 跨域协同库存和营销为什么不能各自为战我前面说库存Agent和营销Agent各自出方案那它们打架了怎么办这就是协同Agent存在的意义。举一个实战中真出现过的场景某款轻羽绒服近7天销量翻了3倍营销Agent判断机会来了建议把广告预算上调20%同时小幅度提价2%库存Agent那边看到的却是实时库存只剩300件供应商补货需要5天于是建议停止投放并且立刻加急补货。两个方案单看都合理一起执行就是事故一边拉流量一边没货顾客点进来只看到缺货。协同Agent拿到两份提案后做的事是先看库存再排动作。它给出的最终序列是锁定库存保留量100件保证已有订单可发生成一张加急采购单同时把广告预算的上调幅度从20%压到5%并且不允许提价。这个例子很好地说明了管控二字不是让每个Agent追求局部最优而是对整个销售漏斗负责。3. 关键实现细节与参数选择架构想明白了真要落地全是细节。这一章我挑几个最容易影响成败的参数和实现点讲包括工具注册方式、安全库存计算、营销触发条件、LLM推理策略。这些细节看起来小但每个都决定了系统到底靠不靠谱。3.1 工具注册与权限边界Agent能调什么工具这是一切安全的基础。我们的做法是给每个工具写清楚名称、描述、参数约束和风险级别然后以JSON Schema的形式塞进模型。比如创建采购单这个工具描述里明确写着仅在库存低于安全阈值时使用参数里规定quantity必须是正整数urgency只能是normal或urgent。TOOLS [ { type: function, function: { name: create_purchase_order, description: 创建采购单仅在库存低于安全阈值时使用。quantity为整数单位是件。, parameters: { type: object, properties: { sku_id: {type: string}, quantity: {type: integer, minimum: 1}, urgency: {type: string, enum: [normal, urgent]} }, required: [sku_id, quantity] } } } ]关键设计是工具层本身就要做权限控制不能只靠prompt约束。比如create_purchase_order这个函数urgency为urgent时直接要求职位是采购经理的人审批update_promotion一旦把折扣调到低于成本价函数内部直接抛异常。也就是说Agent就算异想天开实际动作也很难越界。3.2 安全库存与订货点的计算逻辑库存阈值的计算看起来是个基础数学题其实参数非常讲究。我们用的是零售里最常见的公式安全库存SS Z × σ_d × √L其中Z是目标服务水平对应的标准正态分位σ_d是日需求量标准差L是采购提前期天数。算完之后订货点ROP 日均销量 × 提前期 安全库存。拿一个实际SKU举例日均销量100件日销量标准差15采购提前期7天目标服务水平95%查表得Z1.65。套公式得到SS 1.65 × 15 × √7 ≈ 65.46向上取整为66件ROP 100 × 7 66 766件。也就是说当这个SKU的实时库存降到766件以下时就该考虑补货了。Agent在这里的价值是动态修正公式里的参数。比如供应商近期交期从7天变成了9天或者某新渠道上线导致日均销量预测上调20%这些变化往往藏在邮件、会议记录或者运营日报里。Agent能感知到并调整输入而不是让公式一成不变。但公式本身一定要固化在校验层绝对不允许Agent直接输出一个我觉得补500件就行的数必须让它先报出参数交给规则引擎核算。3.3 营销触发条件与熔断器营销Agent不能想促销就促销。我们设置了三个前置条件和一个熔断机制全部写在校验层条件阈值目的库存覆盖率当前库存 / 日均销量 ≥ 50天防止活动打爆库存近7天转化率趋势环比上升 ≥ 10%只在商品上升期推活动商品毛利率折后毛利 ≥ 30%避免亏本促销预算熔断日预算消耗 ≥ 80%防止预算超支这套规则看起来硬但它非常必要。因为LLM Agent在判断这个商品适不适合做活动的时候会倾向于给出有机会就上的激进建议如果没有这些硬约束长期跑下来毛利和预算都会出问题。3.4 LLM推理策略温度、few-shot与结构化输出大模型Agent在不同任务上参数策略完全不同。库存和营销决策涉及真金白银我们一律把温度设成0保证相同输入下输出尽量稳定可复现。竞品情报摘要这类偏分析的任务温度放到0.2允许模型措辞有一些变化。还有一点很多人会忽略函数调用模式下不建议让Agent自由发挥写文本。我们在prompt里放了两到三个few-shot示例每个示例都展示了从输入数据到输出动作的结构化映射并且明确写了一条禁令你只能基于本次调用提供的实时数据做决策不得依据训练时期记忆中的历史价格或市场情况猜测。训练记忆里的价格信息常常是过时的让模型少猜幻觉率会明显下降。4. 实操过程从0到1搭建一个零售Agent Harness理论讲完了说说实际搭建过程。我按我们当时的项目进程来写分四步统一数据、注册工具、编排决策链路、灰度上线。每一步都有可以抄作业的细节。4.1 数据接入与统一商品主数据所有Agent的第一步都是读数据。如果数据是脏的后面所有决策都是垃圾。我们首先把ERP库存表、OMS在途单、第三方电商平台库存、CRM活动约束四类数据接入到统一的消息管道里按SKU为主键做对齐。这里有个大坑同样一件商品ERP里叫A001电商后台叫SKU-10086线下门店系统又叫GS-9801。主数据不统一Agent读到的就完全是错位数据。我们花了一个多星期专门做商品字典服务把各系统的商品编码全部映射到统一SKU_ID上库存Agent和营销Agent读取任何数据之前都必须先经过这个映射。这条规则写死在感知层不允许Agent自行跨编码猜测。上线后因为ID映射问题导致的错乱几乎为零。4.2 注册库存与营销工具数据通了就可以注册工具。我们陆续实现了十来个函数核心就四个查询库存、创建采购单、调整促销折扣、调整投放预算。实现上有几个原则每个函数直接封装内部服务接口不向Agent暴露原始数据库或ERP连接所有写操作都留审批钩子。def create_purchase_order(sku_id: str, quantity: int, urgency: str normal): if quantity 1: raise ValueError(quantity必须为正整数) if urgency urgent: require_approval(rolepurchase_manager, reason紧急补货) return purchase_service.create_order(sku_idsku_id, quantityquantity, urgencyurgency)这里我想强调一个经验安全校验一定要放在函数实现里不要指望Agent凭自觉。我们在函数里做了参数类型校验、数量上限校验、审批钩子这套防线比任何精心设计的prompt都可靠。4.3 编排Agent工作流一个完整的决策链路核心链路长这样感知层推送数据变化 → 协同Agent判断是否需要响应 → 根据情况唤起库存Agent和营销Agent → 两个Agent产提案 → 协同Agent合并排序 → 校验层逐条检查 → 工具层执行。说一个实战场景我们灰度期真实跑过的链路。某SKU平时每天卖30件周五午后突然卖到80件后台客服对话里也有人提到某平台主播当晚要带这个品。协同Agent收到销量异常告警后先让库存Agent查实时库存发现只剩180件让营销Agent评估当前投放策略它建议加预算20%冲一波库存Agent给出的建议是紧急补货500件同时把销量分布异常标记出来。协同Agent最终输出的动作序列是{ request_id: agent-20250113-001, sku_id: SKU-10086, actions: [ {tool: create_purchase_order, params: {sku_id: SKU-10086, quantity: 500, urgency: urgent}, status: approved}, {tool: update_ad_budget, params: {sku_id: SKU-10086, budget_delta: 0.2}, status: approved_with_limit}, {tool: set_reserved_stock, params: {sku_id: SKU-10086, reserved_qty: 100}, status: approved} ] }校验层在放行前做的事补货数量500是否在采购上限内当前可用库存180件是否足够做100件保留预算上调20%后是否还在当日预算内全部通过动作才依次执行。整个过程从感知到执行完成约90秒而人工模式下至少要半天。4.4 灰度上线与监控这系统不能一把梭直接全自动我们分了三步走。第一步只读模式所有Agent只输出建议不执行任何动作运营团队每周在例会上review建议清单判断哪些对、哪些错积累评估数据。第二步影子模式Agent建议和人工决策并行跑系统记录双方的差异这个阶段能看出Agent到底比人强在哪、弱在哪。第三步半自动模式低风险动作自动执行比如普通补货单、投放预算微调任何涉及毛利、超预算、紧急采购的动作一律转人工。监控指标我们挂了一块大屏重点看自动化执行率、人工干预率、决策平均耗时、幻觉拦截数、补货及时率、库存周转天数。我建议至少跑一个月再谈优化数据样本太少时看到的全是噪音。5. 上线后踩过的坑与排查实录再好的设计落地一定会有问题。下面几条都是我们灰度期真实踩过的坑每条都花了不少时间排查。拿出来分享主要是希望你别再走一遍。5.1 幻觉参数与工具层校验第一次出事故是Agent调用create_purchase_order时quantity把500件整个字符串传了进来。原因是我们在工具描述里写了quantity为整数单位是件模型自作主张把单位一起带进了参数。当时函数没有严格的类型校验调用接口直接报错差一点把采购流程打断。后来我们做了两层改动第一函数内部加类型和范围校验非整数直接抛异常第二提示词里明确要求所有参数只输出纯数值不要带单位。靠这两条再没出现过参数污染问题。这个教训很重要LLM输出再结构化也要在工具层做最后一公里拦截。5.2 多Agent并发下的库存竞争第二个坑是数据竞争。有个大促活动里营销Agent执行了锁定库存给秒杀池库存Agent同时读到的是锁定前的旧库存快照于是补货数量少算了一轮。这个场景特别典型多Agent只要在并发就一定会碰到读写冲突。解决办法是给每个SKU加分布式锁。锁粒度是sku_id加动作类型同一个SKU同一时刻只允许一个写动作在途后到的动作排队等待。我们还额外做了动作队列把针对同一SKU的动作串行化。加锁之后并发问题基本绝迹。5.3 大促高峰期的延迟与排队大促流量一来Agent推理延迟从几百毫秒飙到三四秒再加上几十个决策任务排队库存数据在等待期间已经过期。最要命的是有些动作基于过期数据做出执行时已经是错的了。我们的调整思路是高峰期启用快速模式普通case直接走规则引擎只有异常case才唤起LLM Agent同时把决策触发频率从每15分钟一次降为每60分钟一次减少放大触发。说到底LLM不应该处理所有case规则引擎负责过滤掉95%的平凡场景剩下5%真正需要语义理解和跨域判断的场景再交给Agent。这也是我做完这个项目之后最大的心得。5.4 决策审计日志与回放第四个坑其实不算坑是方法论问题。系统刚上线时每次Agent抽风我们都很被动因为不知道它当时看到了什么、为什么做出这个决定。后来我们把每个决策都记成一条完整trace字段包括request_id、输入上下文快照、中间推理摘要、最终action、校验结果、实际执行结果、延迟。字段说明示例request_id决策链路唯一IDagent-20250113-001input_snapshot当时的库存、销量、活动数据快照stock180, daily_sales80reasoningAgent给出的决策理由摘要需求上涨建议补货action实际调用动作与参数create_purchase_order(500)validation校验层结果passed / blockedlatency总耗时90s排查问题时我的顺序永远是先看数据管道是否正常再看工具执行是否正常然后才怀疑模型和提示词。实际情况里九成以上的AI犯傻其实是上游数据没更新或者字段错位。先把数据链查干净能省掉大量无谓的调试时间。6. 一些真实心得与可扩展方向项目做完、跑了几个月之后有些体会确实只有亲手做过才能写出来。先讲最核心的Agent Harness的价值不在于把决策权全部交给AI而在于给AI一个能安全施展能力的边界。模型幻觉不可能完全消失但通过工具层拦截、校验层把关、审计层留痕这三道防线可以把失控概率压到业务可以接受的范围。还有一个经验是系统的自由度要一点一点放别一开始就给太大。我们灰度期Agent的动作自由度设得很高结果运营团队一天要审批几十条可疑操作信任度直接崩了。后来把权限收紧、让Agent更多提建议而非直接执行自动化执行率反而升上去了——因为业务方开始信任系统了愿意放权。Prompt编写上我觉得最管用的技巧是写明不要做什么。比如Agent的提示词里写了不要在库存不足时建议增加投放预算、不要在毛利率低于30%时推荐折扣活动这类否定式的约束比单纯鼓励它要理性决策有效得多。模型对具体禁令的理解能力比抽象准则强很多。至于后续扩展我脑子里已经排了几个方向一是把天气数据接进来让库存Agent能预判冷热变化对销量的影响二是接入竞品动态监控营销Agent可以基于竞品价格调整自动给出应对方案三是更进一步的Agent协同让库存Agent和营销Agent在冲突时通过一轮对话自行协商而不是每次都由协同Agent硬性裁决。第一个方向我们已经在摸底了后面有结果再单独写一篇。灰度期还有一个便宜又好用的小技巧把所有Agent的建议和最终业务结果都记录下来跑上一个月你就拥有了一份带标注的高质量决策样本集。后面无论是调prompt、做评测还是微调小型模型做成本优化都靠这份数据。这是我们这套系统后续能持续迭代的最大底气。