Agent 零售电商：先把商品数据、促销规则和人工运营串起来，再谈智能卖货

很多人做零售 Agent 时，最先想到的是：

• •自动推荐商品
• •自动做加购和交叉销售
• •自动调价
• •自动回复所有购物问题

但真实零售系统里，真正决定体验和业务结果的，往往是这些事情：

• •商品信息是不是最新、完整、可解释
• •库存、促销和配送承诺是否真实
• •模型会不会为了转化瞎推荐或乱承诺
• •用户在犹豫、比价、退货时能不能被正确引导

所以零售 Agent 更适合被设计成“导购与运营协作者”，而不是一个只会追求 GMV 的自动销售黑盒。

如果第一版就想覆盖推荐、定价、补货、广告投放、售后客服和门店导购，项目通常会因为数据口径和系统边界太多而失控。

更现实的切入点通常是：

• •商品发现与比对助手
• •购物车和促销解释
• •活动商品运营辅助
• •缺货与替代品引导

以“导购与购物车助手”为例，一个可交付的第一版通常已经很有价值：

• •读取商品目录和促销规则
• •根据用户意图给出候选商品
• •解释差异、适配人群和限制条件
• •校验库存、配送和优惠可用性
• •遇到高风险承诺或异常订单时转人工

这比做一个“什么都能卖”的万能电商 Agent 更容易跑通。

1. 商品与规则层

这一层是 Agent 能不能靠谱工作的前提：

• •商品标题、属性、规格、图片
• •价格和促销规则
• •库存和配送范围
• •售后、退换货和门店政策

如果没有这一层，模型生成再流畅，也很容易把错误信息说得头头是道。

2. 意图与导购层

这一层更适合让模型发挥：

• •理解用户是想比价、送礼、补货还是解决具体需求
• •把模糊描述转成结构化筛选条件
• •对比不同商品的适用场景
• •生成更易理解的推荐理由

但推荐应该建立在真实商品数据之上，而不是模型想象之上。

3. 事务与执行层

零售 Agent 一旦进入订单和促销执行，边界就必须更明确。例如：

• •查询订单状态
• •校验优惠券或活动资格
• •解释缺货和替代方案
• •创建售后或客服工单

这些动作应该由受限工具和业务系统完成，而不是模型自己口头承诺。

4. 人工运营与客服层

遇到下面这些情况时，人工接管往往是必要的：

• •用户要求额外补偿、改价或特殊折扣
• •商品数据冲突或缺失
• •库存、配送时效和促销规则互相矛盾
• •涉及高单价、高投诉风险或品牌敏感问题

没有这一层，零售 Agent 很容易为了“继续卖”而做出不该做的承诺。

在零售场景里，一个更稳的职责拆分通常是：

更适合模型处理的部分

• •理解用户购物意图
• •组织商品比较与推荐理由
• •把复杂促销规则解释成人能看懂的话
• •生成给客服或运营看的摘要

更适合系统处理的部分

• •提供实时库存、价格和促销资格
• •查询订单与物流状态
• •校验地区限制、配送能力和活动规则
• •决定是否允许补偿、改价或人工审批

如果让模型自己同时负责“理解 + 推荐 + 承诺 + 执行”，最后最容易出问题的是履约边界。

相比直接让模型回复整段销售话术，我更建议先让它输出一个受限的购物计划。

from typing import Literal
from pydantic import BaseModel, Field


class RetailPlan(BaseModel):
    lane: Literal["discovery", "cart_support", "promo_check", "handoff"]
    shopper_goal: str
    candidate_skus: list[str] = Field(default_factory=list)
    needs_inventory_check: bool = True
    needs_human: bool = False
    blocked_reasons: list[str] = Field(default_factory=list)


def run_retail_workflow(plan: RetailPlan, tools):
    catalog = tools.fetch_catalog_context(plan.candidate_skus)
    draft = tools.generate_retail_reply(plan.lane, plan.shopper_goal, catalog)
    checks = tools.verify_inventory_and_promotions(plan.candidate_skus)

    if plan.needs_human or checks.has_conflicts:
        return tools.route_to_operator(draft=draft, checks=checks)

    return tools.prepare_customer_response(draft=draft, checks=checks)

这个模式的价值在于：

• •先区分当前是在导购、购物车支持还是促销校验
• •商品候选、库存检查和升级原因都可以显式记录
• •后续更容易评估推荐是否命中了真实商品与规则

很多零售 Agent 做到后面会陷入一个误区：只要推荐能让用户点进去，就算成功。

但更稳的推荐系统通常还需要回答：

• •推荐依据是价格、规格、场景还是历史偏好
• •当前是否真的有货
• •是否适用于用户所在地区
• •有哪些限制条件和替代方案

只要这些信息能被清楚表达，用户对推荐的信任通常会更高，也更不容易在售后环节反噬。

零售运营里一个常见冲动，是希望 Agent 自动做这些事情：

• •动态改价
• •发放补偿
• •决定特殊优惠
• •根据情绪给额外折扣

这些动作如果缺少规则和审批，很容易伤害利润和品牌口径。更稳的做法通常是：

• •模型只能提出候选方案
• •系统根据规则校验可用范围
• •超出权限的动作进入人工审批

这样 Agent 更像一个运营助理，而不是一个失控的价格开关。

零售 Agent 的评估，不应该只盯着点击率和转化率，还应该看：

• •商品推荐命中率
• •库存或促销错误承诺率
• •引导到人工时的摘要完整度
• •缺货场景下的替代方案接受率
• •由 Agent 引发的售后返工和投诉情况

这些指标更能反映系统是不是在帮业务，而不是把问题挪到售后环节。

1. 把 Agent 当成转化率最大化黑盒

如果系统只被优化成“多卖一点”，很容易忽略履约、售后和品牌一致性。

2. 没有实时库存和规则校验，就直接推荐和承诺

导购可以生成，但库存、价格和时效必须来自真实业务系统。

3. 把导购、客服、定价和运营混成一个 Agent

这些流程的数据来源、权限和责任人都不同，混在一起通常更难维护。

零售 Agent 真正可交付的价值，不是做一个“更会卖货”的聊天窗口，而是把商品知识、购物引导、规则校验和人工运营串成稳定流程：

• •推荐建立在真实商品数据上
• •关键承诺由系统校验
• •异常订单和高风险承诺及时转人工
• •评估同时覆盖转化、错误承诺和售后成本

只要把这些环节守住，Agent 才能成为零售团队的增长工具，而不是新的投诉来源。

• •OpenAI File Search
• •OpenAI Structured Outputs
• •OpenAI Conversation State
• •OpenAI Agent Evals
• •OpenAI Code Interpreter