最近经常有人问我零售导购 Agent 到底是什么很多人第一反应是给大模型接个客服话术模板但真正在电商业务里跑过一个导购项目就会明白最难的不是让模型会聊天而是让它在一个对话框里同时搞清楚三件事——店里到底有哪些商品、这些商品现在有没有货、到手价是多少。这三个问题分别对应商品库、库存服务和促销规则它们在技术上完全是三种不同性质的数据。这篇博文就围绕连接这个过程来讲。我会先拆解导购 Agent 的完整决策链路然后分别讲清楚商品库、库存、促销规则各自怎么接入最后讲三套系统如何被 Agent 统一编排。适合正在做零售行业大模型应用、Agent 开发的工程师和架构师也适合想搞清楚 Agent 落地边界的产品经理。内容偏实战代码和配置以伪代码/示例为主因为各家业务系统差异很大思路比 API 名更重要。1. 导购 Agent 到底在连接什么先拆清三条数据链1.1 一个真实问题的背后链路用户可能问帮我找一双适合夜跑的鞋42 码五百以内今天下单明天能到吗这句话听起来只是一次普通咨询但 Agent 要给出合格答案必须按顺序完成至少四步从商品库检索适合夜跑的鞋过滤出 42 码、价格五百以内对上屏的每个 SKU 查可售库存排除断码和缺货的根据用户会员等级和无门槛优惠券计算到手价确认是否真的五百以内结合售后/配送信息回答明天能否到货。任何一步出错用户的信任感就会崩塌。用户不会理解库存系统还没同步或优惠券规则太复杂他只会觉得你推荐的商品买不了或者报价是骗人的。这也是导购 Agent 和普通搜索框最本质的区别搜索框只负责给选项Agent 要为结果负责。1.2 商品库、库存、促销规则的三种不同特性这是我在项目里反复跟团队强调的一个判断三条数据链的本质不同决定了接入方式完全不同。数据源典型更新频率数据性质犯错代价商品库小时级/天级偏静态的主数据推荐错商品可容忍库存秒级/分钟级实时状态数据推荐无货商品体验差促销规则活动周期级强逻辑的条件数据报价错误可能引发投诉/资损商品库本质上是主数据新品上架、描述修改、类目调整频率低但字段复杂库存是状态数据随时在变几乎不可能靠人工维护促销规则是逻辑数据它不是一个值而是一组条件和行为组合。把三种数据用一种方式去接是大部分失败项目的通病。1.3 整体架构的最小分层我建议的最小分层是三段式不强求微服务LLM 应用层负责理解用户意图、决定调用什么工具、组织最终回复。这一层只跟业务中间层打交道不直接连数据库。业务中间层Agent Gateway/Service把商品检索、库存查询、促销计算封装成 Agent 可调用的工具Tool。这是整个架构的核心负责把非结构化的用户问题翻译成结构化参数再把结构化结果转回自然语言。数据源层商品库MySQL/ES、库存中台Redis/DB、促销中心规则引擎/营销系统。这样分层的好处是模型可以换、Prompt 可以调但业务动作查库存、锁库存、算价始终走稳定接口不会因为模型升级而崩掉。我见过不少团队把 SQL 权限直接交给 Agent结果模型一句话没说对就把线上商品表锁了这种坑没必要踩。2. 商品库接入从全文本搜索到结构化决策2.1 让 Agent 好用的商品建模不是把表结构扔给它很多团队第一步就是把商品表全字段塞给 Agent让模型直接写 SQL 或查 ES。结果往往是模型面对几十个字段根本不知道该过滤什么最后推荐一堆看着像但完全不符合条件的商品。给 Agent 用的商品模型要按决策维度来裁剪字段。我总结过一组常用的最小字段集标识类spuId、skuId、商品名、主品牌、类目路径决策类可售状态、销售价、划线价、规格属性如尺码/颜色/容量推荐类商品标签夜跑、透气、防滑、详情摘要、主图 URL、销量/评分时效类上架时间、下架时间其中决策类字段最重要。比如42 码模型需要知道 SKU 级才有尺码概念SPU 级没有如果建模只到 SPUAgent 永远无法正确回答有没有 42 码。这也是很多导购项目上线后被吐槽答非所问的根源之一。2.2 双路召回ES 结构化查询 向量语义检索先讲一个比较容易踩的认知坑大模型本身并不适合直接做从十万商品里找出符合条件的这件事模型是决策者不是数据库。所以商品检索需要走独立的召回链路。我常用的组合是 Elasticsearch 向量检索双路召回结构化查询品牌、类目、价格区间、规格属性、上下架状态这些条件完全适合用 ES 的 term/range 查询来过滤准确率高。语义检索适合夜跑的鞋这种描述性需求用 embedding 模型把商品标题/卖点/标签向量化query 也转成向量用向量检索召回 TopK。双路的结果合并后再交给 Agent 做精选——Agent 根据对话上下文把 TopK 排序、解释为什么推荐这款而不是自己天马行空从零生成商品。这个方案还有个好处商品库只有几千个 SKU 的团队向量检索完全可以用开源模型部署在本地不必上昂贵的商业化服务。商品量再大一些也可以靠分片和索引调优扛住真正的瓶颈通常不在向量库本身而在商品文本质量。2.3 商品工具返回什么格式直接影响 Agent 的决策质量工具返回的内容不是能看就行它是模型下一轮推理的输入。返回字段越杂模型越容易乱返回得太少模型信息不足。我的做法是分两档列表检索返回精简卡片字段skuId、商品名、品牌、类目、售价、库存状态有货/无货、主图、核心标签。每款商品不超过 10 个字段。点击/追问详情时返回完整字段规格表、详细参数、售后政策、促销摘要等。这样既控制了 token 成本又避免模型在列表阶段就被复杂字段干扰。同样的接口也可以根据用户是模糊浏览还是精准比价来调节返回详略。注意商品名里经常掺着营销话术爆款限时福利这些词会污染向量召回效果。入库前做一轮清洗把营销词和真实卖点分开存储有利于后续语义检索。3. 库存接入实时性、锁定与缺货兜底3.1 库存数据怎么同步才跟得上导购场景库存是三条链里实时性要求最高的。导购场景里用户问有没有货如果返回的信息滞后几分钟就会出现明明没货还硬推的尴尬。核心思路是分层订单系统产生的真实库存变化通过 Binlog/Canal 订阅 MQ 异步同步到导购中台导购中台维护一份可售库存缓存给 Agent 查询用。链路一般是这样订单中心写入 MySQL 库存表扣减/回补Canal 监听 Binlog发送库存变更事件到 RocketMQ/Kafka消费服务更新 Redis 库存键同时同步到 ES 中的库存状态字段供商品检索过滤这套链路并不复杂但一定要做好顺序性和幂等。库存变更消息如果乱序Redis 里的数字会飞掉所以消费端最好按 skuId 做分区并携带版本号或者用数据库扣减结果反向校正。3.2 Redis 缓存和可售库存口径给 Agent 查询的库存不要直接用物理库存而是定义一个可售库存口径可售库存 物理库存 - 已锁定库存 - 营销活动占用 - 次品/异常占用这个口径需要和库存中台约定清楚否则 Agent 报了有货用户下单时才发现实际不可售体验断崖式下降。Redis 键设计一般用stock:{skuId}存可售数量TTL 不要设置得太短比如 10~30 秒否则大促时流量直接打穿到数据库。查询接口加一层本地缓存Caffeine/GoCache本地缓存失效后再去 RedisRedis miss 才回源数据库。这里有个很实在的经验导购场景对库存精度的要求不是最终一致性而是别错得太离谱。允许几秒差异但不允许把它当成短期秒杀的高频扣减通道。真要精确锁定走下面的锁定机制而不是反复查。3.3 锁定库存从查到占导购 Agent 比普通搜索强的地方在于能成事。用户说帮我把这双鞋加到购物车我确认一下这时候只查库存就不够了最好做一次临时锁定避免用户看完优惠再回来发现被别人抢走了。我做过的简单实现是用 Redis Lua 脚本做原子锁查可售量是否大于等于需求量满足则扣可售量并记一条锁定记录设置过期时间如 10 分钟。-- KEYS[1] stock:{skuId} -- ARGV[1] 需要锁定的数量 -- ARGV[2] 锁定记录键 -- ARGV[3] 过期秒数 local available tonumber(redis.call(GET, KEYS[1]) or 0) if available tonumber(ARGV[1]) then return -1 end redis.call(DECRBY, KEYS[1], ARGV[1]) redis.call(SET, ARGV[2], ARGV[1], EX, ARGV[3]) return 1锁定过期后的释放可以做成异步任务扫描也可以用最终下单时的重新校验可售库存来做兜底。总之导购 Agent 的锁定只是一种善意预占真正扣减仍以订单系统为准两边通过订单号/锁定号关联。3.4 缺货时的替代推荐策略Agent 和普通搜索的另一个差异是缺货时不能只说抱歉没货而是要给用户提供选项。合理的替代推荐顺序是同款不同尺码/颜色比如 42 码没了推荐 42.5 或同款黑色同品牌同品类相近价位同品类相近属性比如透气夜跑标签一致、价格不超过目标价 15%这里可以复用商品库的向量检索把缺货 SKU 的标题属性标签作为 query 向量在同类目候选池里找相似款。替代推荐的引入会让整体转化率明显提升但也别过度如果用户明确说只要这件 42 码就不要自作主张推替代品尊重用户刚性约束。4. 促销规则接入让 Agent 会算账但不替系统做决定4.1 促销规则的类型化建模促销规则是导购 Agent 里最容易出资损事故的地方。因为规则天然具有组合性、时效性和用户维度。常见规则类型可以归纳成几类类型示例关键参数单品直降秒杀价/闪购价生效时间、限购数量、会员等级满减满折满 300 减 50、满 2 件 8 折门槛金额/数量、优惠上限优惠券店铺券、品类券、无门槛券领取条件、使用门槛、互斥关系会员价黄金会员 95 折会员等级、商品范围赠品/积分买一赠一、下单返积分赠送条件、库存建模时每一条规则都要能回答几个问题适用哪些商品SPU/SKU 维度、适用哪些用户用户群/等级维度、何时生效时间窗口、和哪些规则互斥/叠加、由哪个系统执行。这些问题不搞清楚后面 Agent 一解释促销就大概率出错。4.2 规则引擎/营销中台Agent 应该调用谁这个问题要先想清楚再写代码。我的结论是不要让 Agent 直接解释规则代码或自己计算价格必须调用营销中台的统一报价服务。原因很直接营销规则是业务方频繁改动的对象今天叠加一个满减明天撤掉一个优惠券。如果 Agent 在 Prompt 里知道规则它就一定会出现规则过期或幻觉式发挥。正确做法是Agent 只负责把用户问题翻译成报价请求参数userId、skuId、数量、优惠券列表、收货城市等报价服务返回原价、优惠明细、到手价、是否可售Agent 负责把结果解释给用户并标注价格以下单页为准这样做还有个好处是安全和合规Agent 永远不知道也不可能向用户承诺一个系统算不出来的价格。如果团队没有现成营销中台最小实现也可以做一个轻量级规则引擎。规则用 JSON 配置化存储条件表达式用简单 DSL如price 300 category 鞋靴由规则引擎匹配返回结果而不是写死在代码里或者塞进 Prompt。4.3 报价链路的设计先查商品再算促销最后报到手价我给导购 Agent 定的报价顺序是固定的不能反过来先调商品库工具确认商品存在、上下架状态正常、有可售规格再调库存工具确认所选 SKU 有可售库存最后调报价工具传用户属性商品数量优惠券获得到手价。为什么必须先库存后报价因为很多促销规则对无货商品不生效或者算出来一个用户根本买不了的价格。最典型的就是秒杀无货时显示已抢光这时候谈优惠没有意义。报价结果一定要携带优惠明细而非只有最终价。因为用户会追问怎么减的券用上没有Agent 需要明细来解释才不会编造理由。4.4 权限可控Agent 能解释规则不能绕过规则零售 Agent 上线后要特别注意一类安全边界Agent 可以被用户套话套出内部规则或者被恶意用户引导去承诺系统不存在的优惠。我建议对 Agent 的促销相关能力做三层隔离读权限可以查询并解释当前活动规则回答现在有什么优惠写权限不直接发券、不改价、不创建订单只调用预置接口做加购/领券提示人工接管用户要求特殊折扣、客服维权等场景直接转人工Agent 不承诺任何特批结果。这层设计能避免很多资损和投诉。Agent 的本质是导购不是店长权限边界要想清楚。5. 三个数据源怎么被 Agent 编排起来5.1 Tool Use 的边界设计在导购场景里Function Calling或 Tool Use是连接 LLM 与业务系统的关键。工具不是越多越好每多一个工具模型选错工具的概率就高一分。我把导购 Agent 的工具集收敛成 8 个以内按功能分组商品域search_products双路召回、get_product_detail库存域get_stock、lock_stock可选促销域get_promotions、calc_price订单/服务域add_to_cart、query_logistics工具 description 写得越具体模型调度越准。比如{ name: calc_price, description: 返回指定用户购买指定SKU的到手价包含会员价、满减和可用优惠券。注意只在用户询问价格、优惠、到手价时调用。, parameters: { type: object, properties: { userId: { type: string }, skuId: { type: string }, quantity: { type: integer, minimum: 1 }, couponIds: { type: array, items: { type: string } } }, required: [userId, skuId, quantity] } }核心原则是工具名的动词要清晰description 里要给足触发条件参数尽量收敛成必填少、类型简单的 JSON。5.2 意图路由与多轮记忆Agent 面对的问题并不总是单一意图常常是复合的这个有没有货、能用券吗、和那个比哪个划算这时候需要一套轻量级的意图路由逻辑。我倾向于在系统提示词里给模型一个固定的思考顺序表提取用户明确约束商品、规格、价格区间、时间判断意图找商品查库存算价格比价还是下单按意图顺序依次调用工具不跳步每次工具返回后先检查是否满足用户约束再组织回复信息不足时主动提问不猜多轮记忆方面不需要把所有历史消息都塞进去。建议维护一个会话结构化状态拿一个 JSON 存当前候选商品列表、用户已选 SKU、当前选中的优惠券、上次报价结果。每次模型回复后更新这个状态而不是让模型从纯文本历史里重新推理。这个做法既省 token又能显著减少多轮场景下的状态混乱。如果你做过多轮导购测试大概率遇到过模型第二轮就忘了第一款商品的情况结构化记忆比靠对话历史硬抗要稳妥得多。5.3 报价不一致的兜底与人工接管再完善的链路也会遇到边界情况用户从商品页看到的价格和 Agent 报的不一样促销刚下线缓存没刷新用户领券未到账等。这时候 Agent 不能嘴硬要有一套兜底话术和动作承认可能存在时差提示价格和优惠以下单页为准主动重查立即重新调用 calc_price 刷新报价给出动作引导用户点开商品链接、进入结算页或转人工客服。我见过不少项目在兜底话术上做得不到位导致用户把 Agent 当出气筒。记住在零售场景用户要的是能买到不是你能说。价格有争议时最快解决路径永远比解释自己为什么没错更重要。5.4 单 Agent 还是多 Agent这个争论在群里经常看到。以我目前的落地经验零售导购场景优先做单 Agent 清晰工具集而不是一上来就拆多个子 Agent。原因很简单导购任务的状态耦合度很高选一个商品 - 查库存 - 算价格 - 加购是一条连贯链路拆成多个 Agent 后状态传递、上下文共享、工具重复调用都会变成新的复杂度来源。单 Agent 配合结构化记忆在大多数零售场景下已经足够。如果业务确实复杂比如客服和导购分开、售后单独处理可以拆成两个 Agent但中间用明确的移交触发条件不要让两个 Agent 共享一份混乱的会话上下文。6. 真实落地中的坑与性能优化6.1 缓存不一致、库存超卖这些老问题先说我实际踩过的一个坑库存缓存 TTL 设置成了 5 分钟大促当天某爆款 SKU 被疯狂推荐但真实库存其实早已归零。导购 Agent 高高兴兴把所有流量导到商品详情页结果用户全部加购失败第二天投诉量直接翻了一倍。后来我们把设计改成三个尽量库存查询尽量走 RedisRedis miss 才回源主库Redis 键尽量覆盖可售库存而不是物理库存大促期间尽量缩短缓存 TTL并给锁定操作独立计费路径避免锁和查共用一个键导致互相干扰。还有一次很隐蔽的 bug两条库存变更消息因为 MQ 重试乱序把一个 SKU 的库存从 100 扣成了 99 又加回 100刚好让用户看到了有货下单时却失败。最后给库存变更加了版本号判断旧版本消息直接丢弃问题才彻底消失。6.2 线上性能与成本导购 Agent 的每一轮回复背后往往是多次 LLM 调用和多次工具调用。如果设计不当成本会非常恐怖。我分享几个比较实用的成本控制手段列表页不调报价只有用户明确问多少钱到手价时才调 calc_price避免每个推荐商品都算一遍价格合并工具调用如果模型需要查库存又查促销尽量用一个聚合接口get_stock_and_promotion一次返回而不是两次调用缓存用户会话状态多轮对话中商品列表和优惠券列表不要反复查询控制上下文长度给模型的历史消息做截断或摘要不要让十几轮对话的原始文本全部进上下文。端到端延迟方面我的经验值是常规导购问答控制在 2~3 秒内比较合理。超过 5 秒用户明显不耐烦。延迟大头通常在 LLM 推理和工具串行调用上可以把不依赖上一步结果的工具调用并行化或者用流式输出先给用户我在查库存的反馈再逐步补全结果。6.3 测试与评估从对话样本到回归保障Agent 项目最容易被诟病的就是好像能用上线就翻车。我现在的做法是把 Agent 测试拆成三层单工具测试每个工具接口独立验证参数边界、库存为 0、优惠券不可用等都要覆盖对话场景测试整理 100~300 条真实/模拟对话样本分为找商品、查库存、问促销、比价、加购、投诉六类每轮记录 Agent 是否正确调用工具、最终答复是否准确回归评估每次改 Prompt、换模型后跑一遍场景集统计关键指标。关键指标可以参考下面这个表指标含义达标线建议工具调用准确率该调的工具是否正确调用≥ 95%报价准确率到手价与营销中台结果一致100%硬指标商品命中率推荐结果是否满足用户显性约束≥ 90%无货推荐率推荐商品中可售库存为 0 的比例≤ 2%端到端延迟用户提问到完整回复的时间≤ 3s报价准确率我坚持要求 100%这项不达标不应上线。最近也有研究把强化学习用进购物 Agent 的训练比如 shopping GRPO agent 这类方向通过环境反馈来优化 Agent 的决策策略。实践中我还没在线上大规模用但如果你们团队在探索 Agent 自学习这个方向值得关注至少说明行业已经在从调 Prompt走向让 Agent 在环境反馈里变强。6.4 实测中的几个反直觉结论最后分享几个我真实经历过、和直觉相反的现象模型不是越强越好。在某轮测试中小参数量模型因为不够聪明反而老老实实按工具返回结果组织话术大模型偶尔会自作聪明地在报价后面加一句这个价格应该还能再低您可以找客服要隐藏优惠直接把我们吓出一身冷汗。大模型的发散性在导购场景里是需要压制而不是鼓励的。不要给 Agent 太多历史商品字段。有段时间我们把商品详情全字段传给模型做精细推荐结果它开始关注一些无关属性比如包装清单推荐逻辑反而变差了。字段裁剪不是偷懒是帮模型聚焦决策要素。促销规则读得懂和算得对是两码事。模型能从规则文本里总结出满 300 减 50但它不会知道用户当前有没有可用的 300 减 50 券。所以规则归规则用户资产归用户资产两者都必须通过查询接口拿到最新数据不能靠模型记忆。回到开头那个问题零售导购 Agent 到底连接了什么它不是简单连了三张表而是把用户想要什么翻译成系统能提供什么的完整桥梁。商品库负责让它懂货库存负责让它懂现实促销规则负责让它懂划算而最终把这些串起来的是清晰工具边界、严格权限控制和完整的兜底机制。我个人在项目里的体会是导购 Agent 的瓶颈往往不在模型能力而在工程化能力。模型选得再大如果商品检索是乱的、库存是假的、报价是幻觉的用户一次体验就会流失。反过来把三条数据链梳理清楚即使模型不是最前沿的产品的可用性也会远超同行。如果你正在自己搭导购 Agent建议从最小闭环开始先接商品库和库存跑通推荐有货商品再加促销报价每一步都评估好指标再往上堆功能。这样踩坑的代价最小也最容易让业务方看到实际价值。 零售导购Agent连接商品库、库存与促销规则的工程实践
最近经常有人问我零售导购 Agent 到底是什么很多人第一反应是给大模型接个客服话术模板但真正在电商业务里跑过一个导购项目就会明白最难的不是让模型会聊天而是让它在一个对话框里同时搞清楚三件事——店里到底有哪些商品、这些商品现在有没有货、到手价是多少。这三个问题分别对应商品库、库存服务和促销规则它们在技术上完全是三种不同性质的数据。这篇博文就围绕连接这个过程来讲。我会先拆解导购 Agent 的完整决策链路然后分别讲清楚商品库、库存、促销规则各自怎么接入最后讲三套系统如何被 Agent 统一编排。适合正在做零售行业大模型应用、Agent 开发的工程师和架构师也适合想搞清楚 Agent 落地边界的产品经理。内容偏实战代码和配置以伪代码/示例为主因为各家业务系统差异很大思路比 API 名更重要。1. 导购 Agent 到底在连接什么先拆清三条数据链1.1 一个真实问题的背后链路用户可能问帮我找一双适合夜跑的鞋42 码五百以内今天下单明天能到吗这句话听起来只是一次普通咨询但 Agent 要给出合格答案必须按顺序完成至少四步从商品库检索适合夜跑的鞋过滤出 42 码、价格五百以内对上屏的每个 SKU 查可售库存排除断码和缺货的根据用户会员等级和无门槛优惠券计算到手价确认是否真的五百以内结合售后/配送信息回答明天能否到货。任何一步出错用户的信任感就会崩塌。用户不会理解库存系统还没同步或优惠券规则太复杂他只会觉得你推荐的商品买不了或者报价是骗人的。这也是导购 Agent 和普通搜索框最本质的区别搜索框只负责给选项Agent 要为结果负责。1.2 商品库、库存、促销规则的三种不同特性这是我在项目里反复跟团队强调的一个判断三条数据链的本质不同决定了接入方式完全不同。数据源典型更新频率数据性质犯错代价商品库小时级/天级偏静态的主数据推荐错商品可容忍库存秒级/分钟级实时状态数据推荐无货商品体验差促销规则活动周期级强逻辑的条件数据报价错误可能引发投诉/资损商品库本质上是主数据新品上架、描述修改、类目调整频率低但字段复杂库存是状态数据随时在变几乎不可能靠人工维护促销规则是逻辑数据它不是一个值而是一组条件和行为组合。把三种数据用一种方式去接是大部分失败项目的通病。1.3 整体架构的最小分层我建议的最小分层是三段式不强求微服务LLM 应用层负责理解用户意图、决定调用什么工具、组织最终回复。这一层只跟业务中间层打交道不直接连数据库。业务中间层Agent Gateway/Service把商品检索、库存查询、促销计算封装成 Agent 可调用的工具Tool。这是整个架构的核心负责把非结构化的用户问题翻译成结构化参数再把结构化结果转回自然语言。数据源层商品库MySQL/ES、库存中台Redis/DB、促销中心规则引擎/营销系统。这样分层的好处是模型可以换、Prompt 可以调但业务动作查库存、锁库存、算价始终走稳定接口不会因为模型升级而崩掉。我见过不少团队把 SQL 权限直接交给 Agent结果模型一句话没说对就把线上商品表锁了这种坑没必要踩。2. 商品库接入从全文本搜索到结构化决策2.1 让 Agent 好用的商品建模不是把表结构扔给它很多团队第一步就是把商品表全字段塞给 Agent让模型直接写 SQL 或查 ES。结果往往是模型面对几十个字段根本不知道该过滤什么最后推荐一堆看着像但完全不符合条件的商品。给 Agent 用的商品模型要按决策维度来裁剪字段。我总结过一组常用的最小字段集标识类spuId、skuId、商品名、主品牌、类目路径决策类可售状态、销售价、划线价、规格属性如尺码/颜色/容量推荐类商品标签夜跑、透气、防滑、详情摘要、主图 URL、销量/评分时效类上架时间、下架时间其中决策类字段最重要。比如42 码模型需要知道 SKU 级才有尺码概念SPU 级没有如果建模只到 SPUAgent 永远无法正确回答有没有 42 码。这也是很多导购项目上线后被吐槽答非所问的根源之一。2.2 双路召回ES 结构化查询 向量语义检索先讲一个比较容易踩的认知坑大模型本身并不适合直接做从十万商品里找出符合条件的这件事模型是决策者不是数据库。所以商品检索需要走独立的召回链路。我常用的组合是 Elasticsearch 向量检索双路召回结构化查询品牌、类目、价格区间、规格属性、上下架状态这些条件完全适合用 ES 的 term/range 查询来过滤准确率高。语义检索适合夜跑的鞋这种描述性需求用 embedding 模型把商品标题/卖点/标签向量化query 也转成向量用向量检索召回 TopK。双路的结果合并后再交给 Agent 做精选——Agent 根据对话上下文把 TopK 排序、解释为什么推荐这款而不是自己天马行空从零生成商品。这个方案还有个好处商品库只有几千个 SKU 的团队向量检索完全可以用开源模型部署在本地不必上昂贵的商业化服务。商品量再大一些也可以靠分片和索引调优扛住真正的瓶颈通常不在向量库本身而在商品文本质量。2.3 商品工具返回什么格式直接影响 Agent 的决策质量工具返回的内容不是能看就行它是模型下一轮推理的输入。返回字段越杂模型越容易乱返回得太少模型信息不足。我的做法是分两档列表检索返回精简卡片字段skuId、商品名、品牌、类目、售价、库存状态有货/无货、主图、核心标签。每款商品不超过 10 个字段。点击/追问详情时返回完整字段规格表、详细参数、售后政策、促销摘要等。这样既控制了 token 成本又避免模型在列表阶段就被复杂字段干扰。同样的接口也可以根据用户是模糊浏览还是精准比价来调节返回详略。注意商品名里经常掺着营销话术爆款限时福利这些词会污染向量召回效果。入库前做一轮清洗把营销词和真实卖点分开存储有利于后续语义检索。3. 库存接入实时性、锁定与缺货兜底3.1 库存数据怎么同步才跟得上导购场景库存是三条链里实时性要求最高的。导购场景里用户问有没有货如果返回的信息滞后几分钟就会出现明明没货还硬推的尴尬。核心思路是分层订单系统产生的真实库存变化通过 Binlog/Canal 订阅 MQ 异步同步到导购中台导购中台维护一份可售库存缓存给 Agent 查询用。链路一般是这样订单中心写入 MySQL 库存表扣减/回补Canal 监听 Binlog发送库存变更事件到 RocketMQ/Kafka消费服务更新 Redis 库存键同时同步到 ES 中的库存状态字段供商品检索过滤这套链路并不复杂但一定要做好顺序性和幂等。库存变更消息如果乱序Redis 里的数字会飞掉所以消费端最好按 skuId 做分区并携带版本号或者用数据库扣减结果反向校正。3.2 Redis 缓存和可售库存口径给 Agent 查询的库存不要直接用物理库存而是定义一个可售库存口径可售库存 物理库存 - 已锁定库存 - 营销活动占用 - 次品/异常占用这个口径需要和库存中台约定清楚否则 Agent 报了有货用户下单时才发现实际不可售体验断崖式下降。Redis 键设计一般用stock:{skuId}存可售数量TTL 不要设置得太短比如 10~30 秒否则大促时流量直接打穿到数据库。查询接口加一层本地缓存Caffeine/GoCache本地缓存失效后再去 RedisRedis miss 才回源数据库。这里有个很实在的经验导购场景对库存精度的要求不是最终一致性而是别错得太离谱。允许几秒差异但不允许把它当成短期秒杀的高频扣减通道。真要精确锁定走下面的锁定机制而不是反复查。3.3 锁定库存从查到占导购 Agent 比普通搜索强的地方在于能成事。用户说帮我把这双鞋加到购物车我确认一下这时候只查库存就不够了最好做一次临时锁定避免用户看完优惠再回来发现被别人抢走了。我做过的简单实现是用 Redis Lua 脚本做原子锁查可售量是否大于等于需求量满足则扣可售量并记一条锁定记录设置过期时间如 10 分钟。-- KEYS[1] stock:{skuId} -- ARGV[1] 需要锁定的数量 -- ARGV[2] 锁定记录键 -- ARGV[3] 过期秒数 local available tonumber(redis.call(GET, KEYS[1]) or 0) if available tonumber(ARGV[1]) then return -1 end redis.call(DECRBY, KEYS[1], ARGV[1]) redis.call(SET, ARGV[2], ARGV[1], EX, ARGV[3]) return 1锁定过期后的释放可以做成异步任务扫描也可以用最终下单时的重新校验可售库存来做兜底。总之导购 Agent 的锁定只是一种善意预占真正扣减仍以订单系统为准两边通过订单号/锁定号关联。3.4 缺货时的替代推荐策略Agent 和普通搜索的另一个差异是缺货时不能只说抱歉没货而是要给用户提供选项。合理的替代推荐顺序是同款不同尺码/颜色比如 42 码没了推荐 42.5 或同款黑色同品牌同品类相近价位同品类相近属性比如透气夜跑标签一致、价格不超过目标价 15%这里可以复用商品库的向量检索把缺货 SKU 的标题属性标签作为 query 向量在同类目候选池里找相似款。替代推荐的引入会让整体转化率明显提升但也别过度如果用户明确说只要这件 42 码就不要自作主张推替代品尊重用户刚性约束。4. 促销规则接入让 Agent 会算账但不替系统做决定4.1 促销规则的类型化建模促销规则是导购 Agent 里最容易出资损事故的地方。因为规则天然具有组合性、时效性和用户维度。常见规则类型可以归纳成几类类型示例关键参数单品直降秒杀价/闪购价生效时间、限购数量、会员等级满减满折满 300 减 50、满 2 件 8 折门槛金额/数量、优惠上限优惠券店铺券、品类券、无门槛券领取条件、使用门槛、互斥关系会员价黄金会员 95 折会员等级、商品范围赠品/积分买一赠一、下单返积分赠送条件、库存建模时每一条规则都要能回答几个问题适用哪些商品SPU/SKU 维度、适用哪些用户用户群/等级维度、何时生效时间窗口、和哪些规则互斥/叠加、由哪个系统执行。这些问题不搞清楚后面 Agent 一解释促销就大概率出错。4.2 规则引擎/营销中台Agent 应该调用谁这个问题要先想清楚再写代码。我的结论是不要让 Agent 直接解释规则代码或自己计算价格必须调用营销中台的统一报价服务。原因很直接营销规则是业务方频繁改动的对象今天叠加一个满减明天撤掉一个优惠券。如果 Agent 在 Prompt 里知道规则它就一定会出现规则过期或幻觉式发挥。正确做法是Agent 只负责把用户问题翻译成报价请求参数userId、skuId、数量、优惠券列表、收货城市等报价服务返回原价、优惠明细、到手价、是否可售Agent 负责把结果解释给用户并标注价格以下单页为准这样做还有个好处是安全和合规Agent 永远不知道也不可能向用户承诺一个系统算不出来的价格。如果团队没有现成营销中台最小实现也可以做一个轻量级规则引擎。规则用 JSON 配置化存储条件表达式用简单 DSL如price 300 category 鞋靴由规则引擎匹配返回结果而不是写死在代码里或者塞进 Prompt。4.3 报价链路的设计先查商品再算促销最后报到手价我给导购 Agent 定的报价顺序是固定的不能反过来先调商品库工具确认商品存在、上下架状态正常、有可售规格再调库存工具确认所选 SKU 有可售库存最后调报价工具传用户属性商品数量优惠券获得到手价。为什么必须先库存后报价因为很多促销规则对无货商品不生效或者算出来一个用户根本买不了的价格。最典型的就是秒杀无货时显示已抢光这时候谈优惠没有意义。报价结果一定要携带优惠明细而非只有最终价。因为用户会追问怎么减的券用上没有Agent 需要明细来解释才不会编造理由。4.4 权限可控Agent 能解释规则不能绕过规则零售 Agent 上线后要特别注意一类安全边界Agent 可以被用户套话套出内部规则或者被恶意用户引导去承诺系统不存在的优惠。我建议对 Agent 的促销相关能力做三层隔离读权限可以查询并解释当前活动规则回答现在有什么优惠写权限不直接发券、不改价、不创建订单只调用预置接口做加购/领券提示人工接管用户要求特殊折扣、客服维权等场景直接转人工Agent 不承诺任何特批结果。这层设计能避免很多资损和投诉。Agent 的本质是导购不是店长权限边界要想清楚。5. 三个数据源怎么被 Agent 编排起来5.1 Tool Use 的边界设计在导购场景里Function Calling或 Tool Use是连接 LLM 与业务系统的关键。工具不是越多越好每多一个工具模型选错工具的概率就高一分。我把导购 Agent 的工具集收敛成 8 个以内按功能分组商品域search_products双路召回、get_product_detail库存域get_stock、lock_stock可选促销域get_promotions、calc_price订单/服务域add_to_cart、query_logistics工具 description 写得越具体模型调度越准。比如{ name: calc_price, description: 返回指定用户购买指定SKU的到手价包含会员价、满减和可用优惠券。注意只在用户询问价格、优惠、到手价时调用。, parameters: { type: object, properties: { userId: { type: string }, skuId: { type: string }, quantity: { type: integer, minimum: 1 }, couponIds: { type: array, items: { type: string } } }, required: [userId, skuId, quantity] } }核心原则是工具名的动词要清晰description 里要给足触发条件参数尽量收敛成必填少、类型简单的 JSON。5.2 意图路由与多轮记忆Agent 面对的问题并不总是单一意图常常是复合的这个有没有货、能用券吗、和那个比哪个划算这时候需要一套轻量级的意图路由逻辑。我倾向于在系统提示词里给模型一个固定的思考顺序表提取用户明确约束商品、规格、价格区间、时间判断意图找商品查库存算价格比价还是下单按意图顺序依次调用工具不跳步每次工具返回后先检查是否满足用户约束再组织回复信息不足时主动提问不猜多轮记忆方面不需要把所有历史消息都塞进去。建议维护一个会话结构化状态拿一个 JSON 存当前候选商品列表、用户已选 SKU、当前选中的优惠券、上次报价结果。每次模型回复后更新这个状态而不是让模型从纯文本历史里重新推理。这个做法既省 token又能显著减少多轮场景下的状态混乱。如果你做过多轮导购测试大概率遇到过模型第二轮就忘了第一款商品的情况结构化记忆比靠对话历史硬抗要稳妥得多。5.3 报价不一致的兜底与人工接管再完善的链路也会遇到边界情况用户从商品页看到的价格和 Agent 报的不一样促销刚下线缓存没刷新用户领券未到账等。这时候 Agent 不能嘴硬要有一套兜底话术和动作承认可能存在时差提示价格和优惠以下单页为准主动重查立即重新调用 calc_price 刷新报价给出动作引导用户点开商品链接、进入结算页或转人工客服。我见过不少项目在兜底话术上做得不到位导致用户把 Agent 当出气筒。记住在零售场景用户要的是能买到不是你能说。价格有争议时最快解决路径永远比解释自己为什么没错更重要。5.4 单 Agent 还是多 Agent这个争论在群里经常看到。以我目前的落地经验零售导购场景优先做单 Agent 清晰工具集而不是一上来就拆多个子 Agent。原因很简单导购任务的状态耦合度很高选一个商品 - 查库存 - 算价格 - 加购是一条连贯链路拆成多个 Agent 后状态传递、上下文共享、工具重复调用都会变成新的复杂度来源。单 Agent 配合结构化记忆在大多数零售场景下已经足够。如果业务确实复杂比如客服和导购分开、售后单独处理可以拆成两个 Agent但中间用明确的移交触发条件不要让两个 Agent 共享一份混乱的会话上下文。6. 真实落地中的坑与性能优化6.1 缓存不一致、库存超卖这些老问题先说我实际踩过的一个坑库存缓存 TTL 设置成了 5 分钟大促当天某爆款 SKU 被疯狂推荐但真实库存其实早已归零。导购 Agent 高高兴兴把所有流量导到商品详情页结果用户全部加购失败第二天投诉量直接翻了一倍。后来我们把设计改成三个尽量库存查询尽量走 RedisRedis miss 才回源主库Redis 键尽量覆盖可售库存而不是物理库存大促期间尽量缩短缓存 TTL并给锁定操作独立计费路径避免锁和查共用一个键导致互相干扰。还有一次很隐蔽的 bug两条库存变更消息因为 MQ 重试乱序把一个 SKU 的库存从 100 扣成了 99 又加回 100刚好让用户看到了有货下单时却失败。最后给库存变更加了版本号判断旧版本消息直接丢弃问题才彻底消失。6.2 线上性能与成本导购 Agent 的每一轮回复背后往往是多次 LLM 调用和多次工具调用。如果设计不当成本会非常恐怖。我分享几个比较实用的成本控制手段列表页不调报价只有用户明确问多少钱到手价时才调 calc_price避免每个推荐商品都算一遍价格合并工具调用如果模型需要查库存又查促销尽量用一个聚合接口get_stock_and_promotion一次返回而不是两次调用缓存用户会话状态多轮对话中商品列表和优惠券列表不要反复查询控制上下文长度给模型的历史消息做截断或摘要不要让十几轮对话的原始文本全部进上下文。端到端延迟方面我的经验值是常规导购问答控制在 2~3 秒内比较合理。超过 5 秒用户明显不耐烦。延迟大头通常在 LLM 推理和工具串行调用上可以把不依赖上一步结果的工具调用并行化或者用流式输出先给用户我在查库存的反馈再逐步补全结果。6.3 测试与评估从对话样本到回归保障Agent 项目最容易被诟病的就是好像能用上线就翻车。我现在的做法是把 Agent 测试拆成三层单工具测试每个工具接口独立验证参数边界、库存为 0、优惠券不可用等都要覆盖对话场景测试整理 100~300 条真实/模拟对话样本分为找商品、查库存、问促销、比价、加购、投诉六类每轮记录 Agent 是否正确调用工具、最终答复是否准确回归评估每次改 Prompt、换模型后跑一遍场景集统计关键指标。关键指标可以参考下面这个表指标含义达标线建议工具调用准确率该调的工具是否正确调用≥ 95%报价准确率到手价与营销中台结果一致100%硬指标商品命中率推荐结果是否满足用户显性约束≥ 90%无货推荐率推荐商品中可售库存为 0 的比例≤ 2%端到端延迟用户提问到完整回复的时间≤ 3s报价准确率我坚持要求 100%这项不达标不应上线。最近也有研究把强化学习用进购物 Agent 的训练比如 shopping GRPO agent 这类方向通过环境反馈来优化 Agent 的决策策略。实践中我还没在线上大规模用但如果你们团队在探索 Agent 自学习这个方向值得关注至少说明行业已经在从调 Prompt走向让 Agent 在环境反馈里变强。6.4 实测中的几个反直觉结论最后分享几个我真实经历过、和直觉相反的现象模型不是越强越好。在某轮测试中小参数量模型因为不够聪明反而老老实实按工具返回结果组织话术大模型偶尔会自作聪明地在报价后面加一句这个价格应该还能再低您可以找客服要隐藏优惠直接把我们吓出一身冷汗。大模型的发散性在导购场景里是需要压制而不是鼓励的。不要给 Agent 太多历史商品字段。有段时间我们把商品详情全字段传给模型做精细推荐结果它开始关注一些无关属性比如包装清单推荐逻辑反而变差了。字段裁剪不是偷懒是帮模型聚焦决策要素。促销规则读得懂和算得对是两码事。模型能从规则文本里总结出满 300 减 50但它不会知道用户当前有没有可用的 300 减 50 券。所以规则归规则用户资产归用户资产两者都必须通过查询接口拿到最新数据不能靠模型记忆。回到开头那个问题零售导购 Agent 到底连接了什么它不是简单连了三张表而是把用户想要什么翻译成系统能提供什么的完整桥梁。商品库负责让它懂货库存负责让它懂现实促销规则负责让它懂划算而最终把这些串起来的是清晰工具边界、严格权限控制和完整的兜底机制。我个人在项目里的体会是导购 Agent 的瓶颈往往不在模型能力而在工程化能力。模型选得再大如果商品检索是乱的、库存是假的、报价是幻觉的用户一次体验就会流失。反过来把三条数据链梳理清楚即使模型不是最前沿的产品的可用性也会远超同行。如果你正在自己搭导购 Agent建议从最小闭环开始先接商品库和库存跑通推荐有货商品再加促销报价每一步都评估好指标再往上堆功能。这样踩坑的代价最小也最容易让业务方看到实际价值。