一、需求分析
业务背景
电商的客服量，长期被当成「售后成本」来管：退货、物流、尺码、发票。但真实数据讲的是另一件事——某电商 AI 智能体服务商在其 2,500+ 客户品牌的混合对话数据中披露：89% 的对话发生在购买之前，而其中约 三分之二 落在商家团队的非营业时间。
这两个数字合起来说明一件事：购买决策发生在没人值班的时刻，而商家最贵的资源（人）恰好不在。
| 痛点 | 现状描述 | 量化影响 |
|---|---|---|
| 售前无人值守 | 团队在线时段与消费者咨询高峰错位 | 约 2/3 的对话发生在非营业时间 |
| 渠道割裂 | 站内聊天、商品页问答、WhatsApp、社媒私信、邮件各用一套工具与人 | 同一客户在不同渠道重复描述，一换渠道就从头开始 |
| 只答不做 | 客服能解释退货政策，但不能开退货单 | 客户拿到解释仍要自己走完流程，流失在最后一步 |
| 知识碎片 | 政策文档、商品目录、库存分散在几个系统里 | 答案口径不一致，全靠人记 |
需求的两个层次
问商家「你要什么」，得到的通常是第一层：
「客户问什么，你帮我答什么，快一点就行。」
复盘流失路径，真正的痛点在第二层：购买前那段犹豫，没有被当成一个可经营的漏斗。「这件有没有 M 码」「明天能到吗」「和我手上的旧款兼容吗」——每一个问题都是一次可能成交的机会，却被打包成了工单。
这两层的区别直接决定系统形态：第一层做出来是问答机器人（RAG + FAQ）；第二层做出来是销售智能体——它得知道客户是谁、能查真实库存与履约、能在商家系统里把动作做完。
为什么不是「把 FAQ 塞进 RAG」
因为电商的绝大多数售前问题不是语义相似度问题，而是约束满足问题：
把商品描述向量化，模型能「聊得像」，但答不了这三类问题。语义检索解决「像不像」，电商要的是「是或不是」。
二、技术方案
前置判断：三类能力必须分开
动工前先把「Agent 要会的东西」拆成三类，因为它们的实现路径不同、失败代价更不同：
| 能力 | 技术路径 | 失败代价 |
|---|---|---|
| 知道（政策、成分、尺码建议） | 检索 + 生成 | 说错话，客户换一家 |
| 记得（这个客户是谁、聊到哪了） | 统一客户档案 + 会话状态 | 客户重复描述，体验崩 |
| 动手（查库存、开退货单、发券、改地址） | 工具调用（系统 API） | 做错事，要赔钱 |
**能说的和能做的，不能用同一套约束管。** 说错话可以道歉，做错事要赔钱——所以「知道」可以放开让模型生成，「动手」必须走权限分层与幂等。
系统架构
渠道接入层
├─ 站内搜索栏 / 商品页问答 / 站内聊天
├─ WhatsApp / 社媒私信 / 邮件 / 工单台
└─ 统一接入网关（渠道适配器 + 身份归并）
│
会话与身份层
├─ Identity Resolution：渠道 ID → 统一 customer_id
├─ 会话状态（当前意图 / 已收集信息 / 待兑现动作）
└─ 客户档案（历史订单 / 偏好 / 语言 / 历史对话摘要）
│
智能体编排层
├─ 意图路由：售前咨询 / 履约查询 / 售后动作 / 转人工
├─ 检索（政策与知识）
├─ 结构化查询（商品 / 库存 / 订单 / 物流）—— 工具调用 + 权限分层
└─ 生成（答案 + 依据引用 + 下一步动作）
│
执行与合规层
├─ 动作白名单 / 阈值（退款、改价、折扣）
├─ 幂等键（订单 + 动作类型 + 会话）
├─ 审计日志（谁触发 / 模型给的依据 / 系统返回）
└─ 转人工（无依据、超阈值、连续失败）
│
商家系统（Shopify / Magento / SFCC / BigCommerce / 自研 Admin API）技术栈
推理 多模型路由（按任务复杂度与成本分配，商业模型与自托管混合）
检索 政策向量库 + 商品目录结构化查询（两套并行，不通胀成一套）
接入 Shopify / Shopify Plus 原生；Magento / Adobe Commerce /
Salesforce Commerce Cloud / BigCommerce / 自研 Admin API + 前端一段 snippet
渠道 WhatsApp Business API / 邮件 / 社媒 DM / 工单台 webhook
数据 PostgreSQL（客户档案 / 会话状态 / 审计日志）
前端 嵌入式组件（搜索栏、商品页问答、聊天窗与 checkout 同页）三、实现细节
1. 训练一次、全渠道复用：把「渠道会话」和「客户实体」解耦
全渠道最常见的失败形态，是每个渠道各训一份知识、各存一份上下文——于是客户在 WhatsApp 里报过订单号，回到网站还得再说一遍。解法是把渠道降级成接入层，主键换成客户实体：
def resolve_identity(channel_id, channel, hints) -> str:
"""
渠道 ID → 统一 customer_id
hints: 邮箱 / 手机号 / 订单号 / 登录会话
"""
# 1) 强标识：登录会话或订单号 → 直接命中
if hints.get("customer_id"):
return hints["customer_id"]
# 2) 弱标识：邮箱 / 手机号（跨渠道常见，需去重与冲突处理）
for key in ("email", "phone"):
if hints.get(key):
cid = lookup_customer(key, hints[key])
if cid:
link_channel(channel_id, channel, cid) # 记住这条映射
return cid
# 3) 无法归并 → 匿名会话（只保留会话级上下文）
return create_anonymous_session(channel_id, channel)会话状态挂 customer_id，不挂渠道：
会话上下文（示例）
customer_id : C-88213
channel : whatsapp → web（已切换）
当前意图 : 售前 / 尺码
已收集 : 肤色=暖调；关注成分=酸类
待兑现动作 : 无
→ 客户换渠道后上下文继续，不需要重述要点：知识只训一次（政策 + 目录），上下文只存一份（客户级）。扩渠道 = 加一个适配器，不是重训一遍。
2. 让 Agent「动手」：权限分层 + 幂等
Agent 的价值一半在「能动手」，风险也全在这里。参考实现按三层分级：
| 层级 | 动作示例 | 处置 |
|---|---|---|
| L1 只读 | 查订单、查库存、查物流、查政策 | 自动执行，不走审批 |
| L2 可逆写 | 改收货地址、开退货单、发预付标签、发优惠券 | 自动执行 + 审计日志 + 通知客户 |
| L3 涉钱 / 不可逆 | 退款、改价、超阈值折扣、取消已发货订单 | 阈值内自动 + 幂等；超阈值挂起等人工 |
幂等在这里是硬要求，因为模型会重试、渠道会重投：
def execute_action(action_type, order_id, session_id, payload):
idem_key = f"{action_type}:{order_id}:{session_id}"
if seen(idem_key): # 同一动作在同一会话内只执行一次
return cached_result(idem_key)
result = dispatch(action_type, payload) # 真正调用商家系统 API
record(idem_key, result) # 落审计：谁触发 / 依据 / 返回
return result一段被压缩到 2 分钟的退货对话（格式示意）：
客户：鞋码不对，想退了。
Agent：查到订单 #8421（周五送达）。退货已开，预付标签已发到你的邮箱，
货到即原路退款。
[Return 8421 opened] [Prepaid label emailed] [Refund set on arrival]这条链上做了三件「事」：开单、发标签、设退款。这是回答和执行的差别，也是「智能体」和「聊天机器人」的差别。
3. 商品知识不是文档，是结构化目录
把商品全量向量化，很容易在「有货吗」这类问题上给出自信的错误答案。参考实现把商品侧拆成两套：
模型在中间负责的是决定查什么，而不是编答案：
输入：这件有 M 码吗？我明天要飞到里斯本。
① 意图 → 售前 / 库存
② 结构化查询 → catalog.sku("SILK-FDN-2W") → {stock: true, size: "M"}
→ shipping.eta(postcode="1000-001", asof=now) → 2 个工作日
③ 生成 → 「M 码有货；按里斯本的时效，标准配送要 2 个工作日，赶不上你明天出发。
可以走次日达（下单截止 18:00）。」（以上数值为格式示意。）
判据：答案里出现的每个「是/否/数字」，都必须能指回一条结构化返回值或一条政策原文——指不回去，就转人工。
4. 非营业时段占三分之二：无人值守时的三条兜底
约 2/3 的对话发生在没人值班的时刻，这决定了系统不能只在「一切正常」时工作：
1. 不许编：任何无法指回依据的回答，改成「这个我需要确认，已为你转人工，明早 9 点前回复」+ 记下待办。宁可少答，不可错答。
2. 高风险动作挂起：L3 动作在无人时段进审批队列，而不是自动放行——留一分钟的人工，比赔一笔退款便宜。
3. 降级要可感知：工具调用失败（库存接口超时等）时明确告知「暂时查不到库存」，而不是用一句听起来很确定的猜测糊过去。
四、项目成果
业务指标
| 指标 | 数据 | 口径 |
|---|---|---|
| 覆盖品牌数 | 2,500+ 电商品牌（DTC 到企业级零售） | 服务商官网（2026-09） |
| 售前对话占比 | 89% | 跨 2,500+ 品牌混合口径 |
| 非营业时间处理 | 约 2/3 的对话 | 同上 |
| 月处理对话量 | 约 70 万次 | 受访方自述 |
| 收入体量 | 月收入约 16.7 万美元，接近 200 万美元 ARR | 受访方自述 |
| 增长 | 周环比约 10% | 受访方自述 |
| 上线周期 | 自助客户当天；企业客户 1–4 周 | 服务商官网（2026-09） |
（上表混合服务商官网口径与受访方自述口径，逐行已标注，未做二次核验。）
一个结构性变化：从成本中心到成交侧
这个项目最值得对照的不是模型选型，而是它把 AI 客服的落点从「省人力」搬到了「抢成交」。一旦售前对话被算成收入，一切指标都换了：
| 维度 | 成本视角的客服 | 收入视角的销售智能体 |
|---|---|---|
| 核心指标 | 人均接待量、人工介入率 | 售前转化率、单次对话带单金额 |
| 考核时段 | 工作时间 | 24 小时（约 2/3 在非营业时段） |
| 动作边界 | 只答，不动系统 | 开单、发券、改地址、设退款 |
| 归因 | 会话数 | 订单归因到产生它的那次对话 |
最后一条是分水岭：当系统能把订单归因到对话，它就从「成本项」变成了「有 ROI 的渠道」——预算的审批逻辑随之完全不同。
获客侧：没有魔法，只有组合
案例方公开的增长动作，没有一项是增长黑客：
| 渠道 | 做法 |
|---|---|
| 应用市场 | ASO 优化 + 引导好评（平台内搜索本身就是主要流量入口） |
| SEO / GEO | 面向搜索引擎与大语言模型引用的双优化 |
| 内容与个人品牌 | 创始人全员在 X / LinkedIn 持续输出；YouTube 只做对电商人有真实价值的内容 |
| 冷邮件 | 规模化触达，数据源来自公开的店铺情报（Store Leads / Similarweb） |
| 生态嵌入 | 把「技能」嵌进其他商家应用，借别人的流量 |
| 付费测试 | AppSumo / Facebook / Google 广告，能跑就测，不 work 就换 |
「没有任何增长黑客，就是慢慢磨，不停磨。唯一不变的是：永远不要停止发布和售卖。」
五、可复用的经验
1. 先问「谁在什么时刻替客户做决定」，再谈模型。 89% 的对话发生在购买前、约 2/3 在非营业时间——这两个数字决定了系统必须无人值守可用，也决定了它的价值锚点是成交而不是工单。
2. 渠道是接入层，客户是主键。 全渠道做不好的根因，几乎都是把上下文挂在了渠道上。训练一次、复用多次的前提是身份归并，不是知识库的数量。
3. 说的和做的分开管。 语义生成可以放开，系统动作必须走权限分级 + 幂等 + 审计。三样缺一，事故迟早发生。
4. 能用结构化查询的地方，不要用生成。 库存、价格、时效这类问题，「查出来」永远比「说得好」可靠。
5. 无人值守的系统，价值在兜底而不在聪明。 不许编、高风险挂起、降级可感知——这三条比多答对 5% 的问题更能决定它能不能上线。
写在最后
把客服当成成本，你会得到一个更省人的应答器；把售前当成漏斗，你才会得到一个能动手的销售智能体。
探索智能，酷在前沿
本案例素材来自该服务商官网公开信息（2026-09 抓取）与一篇公开发布的项目报道（2026-09）；商务数据引自受访方自述与官网披露口径，技术方案与实现细节为 coolseek 依据该场景归纳的参考实现。