当货架由 Agent 组织：把「电商 AI」拆成四层准入与可测指标

文谦南宁AI普工
6 阅读12分钟

说明：本期主题为电商与营销，本文只讲"怎么搭"和"怎么量"。

双 11 这一年，最值得技术人围观的不是哪家又发了购物 Agent，而是一个失败案例的复盘价值：OpenAI 的 Instant Checkout 上线 5 个月、跑通不到 30 家 Shopify 商户，2026 年 3 月 4 日关停；沃尔玛披露对话内直购转化率只有跳转购买的 1/3，而且"一次只能处理一件商品、没有购物车、没有会员积分"。

这不是模型能力问题。这是状态机设计、幂等性、责任边界三件事没做好。下面把它拆成一套可以落地的四层架构，每层给接口形状、评测口径和踩过的坑。

一、参考架构：四层准入

[商品源系统 PIM/ERP]
        │  (1) 结构化投影
        ▼
┌───────────────────────────────────────────┐
│ L1 可读层  Product Knowledge Layer        │
│   schema 校验 / 类目必需字段 / 多语言对齐   │
└───────────────────────────────────────────┘
        │  (2) 事实条目 + 出处
        ▼
┌───────────────────────────────────────────┐
│ L2 可引层  Citation & Provenance Layer    │
│   信源图谱 / 引用审计 / 一致性校验          │
└───────────────────────────────────────────┘
        │  (3) 会话与意图
        ▼
┌───────────────────────────────────────────┐
│ L3 可接层  Fulfillment Conversation Layer │
│   多 Agent 调度 / 工具边界 / 升级策略       │
└───────────────────────────────────────────┘
        │  (4) 委托支付令牌
        ▼
┌───────────────────────────────────────────┐
│ L4 可结层  Settlement Layer               │
│   checkout session / 幂等 / 责任归属        │
└───────────────────────────────────────────┘

判断：L1、L2 是工程活，能靠流程把效果做出来；L3 是产品活，成败在"什么时候闭嘴"；L4 是法务活，技术团队在里面只占三成权重。

二、L1：把商品投影成机器可读的实体，而不是一段文案

Channable 分析近一万家零售商产品数据，说超 75% 的 feed 缺 AI 平台所需关键属性（二手转述，原文未取到）。这个数字你可以不信，但用 JSON Schema 跑一遍自己的目录，十分钟就知道真假。

关键是：必填字段必须按类目分叉。服饰的"裙长/版型/弹性"和 3C 的"接口/功率/保修"完全不是一套字段，用一个通用 schema 必然漏。

# L1: 类目感知的投影校验
from dataclasses import dataclass, field
from typing import Literal

@dataclass
class ProductDossier:
    sku: str
    title: str
    category_path: list[str]
    # 可读：机器要能算，不能只给人看
    attributes: dict[str, str | float]      # 结构化属性
    size_table: dict[str, dict] | None      # 尺码表：{size: {chest, length, ...}}
    materials: list[dict]                   # [{"name": "棉", "pct": 95}]
    use_cases: list[str]                    # 适用场景，检索命中率主要靠它
    # 可引：每条事实都要有出处
    claims: list["Claim"]
    # 可结：价格/库存/履约/退换的标准字段
    price: dict          # {amount, currency, tax_included}
    stock: dict          # {available, reserved, restock_eta}  ← 语义必须写清
    fulfillment: dict    # {ships_from, lead_time_days, regions}
    return_policy: dict  # {window_days, conditions, who_pays}

@dataclass
class Claim:
    text: str
    source_url: str | None
    verified_at: str | None   # ISO date；None 表示未核验，L2 会拒收
    evidence_type: Literal["spec", "test_report", "third_party_review", "self_claim"]

REQUIRED_BY_CATEGORY = {
    "apparel": ["size_table", "materials", "use_cases"],
    "appliance": ["attributes.power", "attributes.warranty", "return_policy"],
    "food": ["materials", "attributes.shelf_life", "attributes.certification"],
}

def validate(d: ProductDossier) -> list[str]:
    missing = []
    for path in REQUIRED_BY_CATEGORY.get(d.category_path[0], []):
        obj = d
        for part in path.split("."):
            obj = getattr(obj, part, None) or (obj or {}).get(part) if isinstance(obj, dict) else getattr(obj, part, None)
            if obj is None:
                missing.append(path); break
    # 语义陷阱：stock.available 到底是"可售"还是"实物在库"？
    if d.stock.get("available") and d.stock.get("reserved") is None:
        missing.append("stock.reserved")   # 缺失会导致 Agent 承诺了发不出的货
    return missing

工程上的第一个真坑就在最后两行。available 语义不统一，是"可售库存"和"实物在库"两回事；Agent 拿到前者去承诺发货，超卖投诉会直接打到客服头上。你可以在自己的系统里含混，但一旦被 Agent 读取，含混就变成事故。

Mondelēz 的案例说明回报：不做投放、不写软文，只把 Oreo 公开产品描述改成机器可读结构，曲奇类 AI 查询引用率从 10% 到约 70%。这是本期最"便宜"的一次效果提升。

三、L2：引用是可以被审计的，别把它做成玄学

先立一个前提：85% 的 AI 品牌提及来自外部域名，不是品牌自有站点（AirOps，经 M+C 转述）。所以 L2 的核心资产不是你的官网，是你的"事实条目 + 谁在替你确认"。

审计管线可以很朴素：

# L2: 引用审计（按周跑）
QUERY_SET = load_queries("category_queries.yaml")   # 200~1000 条真实问法
PLATFORMS = ["deepseek", "doubao", "yuanbao", "quark", "chatgpt"]

def audit(queries, platforms):
    rows = []
    for q in queries:
        for p in platforms:
            r = call_platform(p, q, temperature=0, seed=42)   # 固定种子，否则周与周不可比
            cites = extract_citations(r.text, r.raw)          # 优先取结构化引用字段，退化到URL正则
            rows.append({
                "query": q, "platform": p,
                "brand_mentioned": contains_brand(r.text),
                "brand_rank": rank_of_brand(r.text),          # 首推=1，未出现=None
                "cited_domains": [domain_of(u) for u in cites],
                "self_domain_share": share(cites, OUR_DOMAINS),
            })
    return rows

def share_of_citation(rows, brand):
    hit = [r for r in rows if r["brand_mentioned"]]
    return len(hit) / len(rows), median([r["brand_rank"] for r in hit if r["brand_rank"]])

两个必须自己定义的指标，否则一定被服务商的话术带走：

  • SoC（Share of Citation，被引份额）：在固定 query set 上，你被引用的回答数 / 总回答数。分母是"回答条数"，不是"提及次数"。
  • 首推率（Top-1 Rate）：brand_rank == 1 的回答占比。

行业里说的"推荐率 20%→96%"，分母定义查不到统一标准——是回答条数占比、还是首推占比、还是提及次数占比，差三倍以上。签约前必须写进合同：query set 谁定、多少条、跑几次、temperature 与 seed 是否固定、失败重试怎么算。

同时记一条红线：三地监管已经罚过"造证据"。深圳 5 万（套取收录标准、批量编造虚假排名）、广州越秀 12 万（虚构 187 起案件、9.6 分满意度、92.5 分综合得分）、北京朝阳 5 万（虚构自身 99.6 分、市占 49%、续费率 99%）。技术上做一个"每条 claim 必须有 source_url 与 verified_at，两者缺一即拒发"的闸门，成本极低，能挡住 90% 的麻烦。

四、L3：承接层的本质是"工具边界 + 升级策略"

淘天给的定价是 0.2 元/通（标准版），人工 2 元/通。十倍价差意味着：每多一次不必要的转人工，就吃掉十次 AI 会话的毛利。所以 L3 的核心指标不是"AI 解决率"，而是"每千次会话的净收益"——转人工成本 + 退款成本 + 差评成本，全部计入。

工具调用必须带三道闸：

@dataclass
class ToolPolicy:
    name: str
    max_amount: float | None      # 退款/补偿上限
    requires_human_above: float   # 超过则强制转人工
    idempotency_key_required: bool
    reversible: bool              # 不可逆操作（改地址、拦截物流）单独审批

POLICIES = {
    "refund":        ToolPolicy("refund", 50, 50, True, False),
    "address_change":ToolPolicy("address_change", None, 0, True, True),  # 仅未发货可改
    "logistics_intercept": ToolPolicy("logistics_intercept", None, 0, True, True),
    "coupon_issue":  ToolPolicy("coupon_issue", 20, 100, True, False),
}

def guard(tool: str, args: dict, ctx: dict) -> Literal["exec", "escalate", "refuse"]:
    p = POLICIES[tool]
    if p.max_amount and args.get("amount", 0) > p.max_amount:
        return "escalate"
    if p.idempotency_key_required and not args.get("idem_key"):
        return "refuse"                       # 没有幂等键，一律不发
    if ctx["sentiment"] < -0.5 and not ctx["human_available"]:
        return "escalate"                     # 情绪已经崩了，别让 AI 继续解释
    if ctx["policy_risk"] == "high":          # 涉及功效宣称、医疗、绝对化用语
        return "escalate"
    return "exec"

三条经验，血换的：

  1. 幂等键不是可选。退款、赔付、发券这三个动作，重试一次就是真金白银。idem_key = hash(session_id + tool + args) 是底线。
  2. 不可逆操作必须单独授权。改地址、拦截物流这类，AI 一旦错，人工只能事后补救。REP AI 的案例里，34% 的会话内加购转化很亮眼，但他们真正的功课在"把对话完整交回人工"——89.68% 自助解决意味着剩下 10.32% 的交接质量决定口碑。
  3. 情绪分要单独建模，别塞进意图分类。同一个"我的货呢"，平静问是查询，第三次追问是投诉。

豆包"帮你选"把历史退货记录作为推荐特征，是本期最值得抄的一个工程设计：退货原因是天然的高质量标注（尺码不符/风格不符/色差），而且免费。把它接进推荐侧的特征，服饰类目 40% 的退货率才有得降。工程上注意：退货原因是用户自填 + 客服归类，噪声大，先做一轮归一化再用。

五、可测指标：北极星、过程指标、反指标

层北极星过程指标反指标（涨了就要停）
L1类目必需字段完整率schema 校验通过率、字段冲突数"属性齐全但语义错误"的工单数
L2SoC（被引份额）首推率、引用域名集中度、自有域名占比引用来源单一度（>60% 来自一处即危险）
L3每千次会话净收益AI 解决率、转人工率、会话内加购率重复退款率、同一会话轮次中位数
L4结算成功率会话完成率、支付失败归因分布支付争议率、超授权金额笔数

L2 的"引用来源单一度"是很多人漏掉的反指标。当你的品牌提及 80% 来自同一个站群，短期 SoC 会很好看，长期是模型一更新就整条消失——这也是监管最容易认定的形态。

六、工程易错点（8 条）

  1. 把"引用率"当"转化率"报给老板。两者相差两个数量级：AI 来源流量同比 +393%，但仍不到零售访问的 1%（Adobe + Flagship 口径）。
  2. 离线评测集被优化到过拟合。固定 200 条 query 跑到 96%，上线发现真实问法完全不长这样。做法：query set 分"训练池/盲测池"，盲测池每季度换一半。
  3. 不固定 seed/temperature 就做周对比。同一问题两次回答不同，你会把噪声当趋势。固定 seed，同时记录平台版本号。
  4. 多平台字段语义不统一：库存、含税价、发货时效、退换责任方，四组字段最容易各说各话。建议在 L1 就强制加 semantics_version。
  5. 把 AI 标识做成一闪而过的小字。2026 年 2 月 1 日《直播电商监督管理办法》第 37 条要求"依法标识并持续提示"，角落小字不符合"显著标识"。做前端组件时就把它做成不可关闭的角标 + 口播提示，别等法务来找。
  6. A/B 分流不均。淘天 2026 年 3 月那次测试是 1% 纯人工 / 99% 先 AI 接，这种极不均衡分流下，任何"转化率超过人工"的结论都要做分层校验，否则是辛普森悖论。
  7. 把 Agent 的推荐当竞品情报。平台 AI 只读关联平台的价格，跨平台比价做不到（多家媒体实测），你拿它的输出去定价格策略，会系统性偏高。
  8. 忽略"目录即接口"这件事。ACP/UCP 的接入本质是 feed 质量竞赛：商品 feed 不及时、不准确，你连被推荐的资格都没有。这不是运营活，是数据工程活。

七、六维（Top 3 全展开 + 简版）

Top 1｜跨平台经营 Agent 工作台（Accio / 千问办公电商版形态） 场景=替代"五个后台复制粘贴 + 手合并表格"；可行性=无模型难题，难在连接器与字段映射；用户=10 人内团队管几十家店的中小商家，千问办公电商付费用户占比超 20%、周均 38 个任务；前景=订阅+按店计费，杠杆来自"一人能管多少店"（全网投放盘点 2h→15min）；优势=跨平台，单平台工具必被收编；风险=接口政策一变即断供。

Top 2｜可核验信源层（合规 GEO） 场景=替代软文/买榜单式 SEO 外包；可行性=知识库+审核流+多平台监测，智火已做到 952 关键词×6 产品线×5 平台；用户=B2B 制造、本地连锁、母婴医疗等高信任门槛品类，决策链含法务；前景=项目+年框，护城河是留档能力；优势=证据链而非模型，监管正在清理造假型供给；风险="GEO"一词被 SPAM 污染，效果指标无统一定义。

Top 3｜承接层 Agent（客服/尺码/售后） 场景=AI 导购之后的最后一百米；可行性=成熟，多 Agent 调度+工单对接已跑通，难点在升级策略；用户=咨询量大/SKU 多/跨境；前景=单位经济最清楚（0.2 元 vs 2 元，鱼跃一季省 400 万），Cabana Life 30 天 647换647 换 4,713 销售；优势=接得住的流程（改地址、拦物流、直接退），不是模型；风险=平台自带产品挤压第三方，一次答错吃掉一个月节省。

简版四项：灵境 AIGC（素材工厂，优势在版本↔转化回流，风险在同质化）；擎舵 3.0（创意+投放双 Agent，15 万客户，风险是加速同质化）；Zocket×Bata（自建产线，年省约 100 万美元、成本降 80%，风险是辨识度几年后才显现）；商品「准入档案」（概念阶段，技术无难点、标准缺位，查不到成品）。

八、Top 3

  1. 跨平台经营 Agent 工作台——L1 的入口，卡在"交材料"第一道工序，付费已被验证。
  2. 可核验信源层（合规 GEO）——L2 需求刚性（85% 提及来自第三方），供给正在被监管清理。
  3. 承接层 Agent——L3 单位经济最干净，十倍价差不需要讲愿景。

不选 Higgsfield（年化 10 亿美元但站在产能侧，会被模型降价吃掉）与 Anthropic 开源购物 Agent（L4 基础设施，平台战场）。

九、本周可执行

# 1) 十分钟体检：跑一次类目必填字段校验
python -m dossier.validate --catalog ./exports/products.jsonl --report ./out/gap.csv

# 2) 建 200 条 query 的引用基线（固定 seed，跑两轮取交并集）
python -m citation.audit --queries ./queries.yaml --platforms deepseek,doubao,yuanbao --seed 42

# 3) 导出客服转人工原因 TOP10，排出承接层改造顺序
python -m cs.export --reason-field transfer_reason --top 10

第 1 步决定你能否被读到，第 2 步决定你能否被引用，第 3 步决定你能否接住。三步做完，再谈要不要买工具。

说明：本文数据均标注归属与口径，当事方自述数值未做横向加总；服务商案例无独立核验。涉及企业经营，不构成投资建议。

avatar
文章
阅读
粉丝