前言

很多电商客服系统已经能够解决“回答问题”这件事。

用户问发货时间，系统返回物流规则；用户问商品参数，系统查询知识库；用户问退换货，系统给出售后说明。

从技术上看，这套链路已经比较成熟：

User Query
    ↓
Intent Recognition
    ↓
FAQ / RAG
    ↓
LLM
    ↓
Answer

但在真实电商场景中，会出现一个比较典型的问题：

客服只会回答问题，怎么提高转化？

消费者的问题虽然被回答了，但对话也可能停在“回答完毕”。近期CSDN上的相关客服Agent实践也在讨论类似变化：客服系统正在从单纯响应问题，进一步向理解意图、推进对话和执行任务演进。(CSDN)

因此，如果目标从“降低客服工作量”进一步变成“辅助售前转化”，架构需要从 Question → Answer 升级到：

Conversation
    ↓
State
    ↓
Intent
    ↓
Decision
    ↓
Action

这也是销售型Agent与传统问答机器人的主要区别。

---

一、为什么“回答正确”不等于“促进成交”？

先看一个典型会话：

用户：A款和B款有什么区别？

客服：
A款重量1.2kg，B款重量0.9kg，
其他参数分别是……

答案可能完全正确。

但用户看完以后，没有继续提问，也没有下单。

问题出在哪里？

因为系统只完成了：

用户问题 → 商品信息

却没有进一步判断：

为什么比较A/B？
↓
用户真正需要什么？
↓
当前处于哪个购买阶段？
↓
还有什么问题阻碍决策？
↓
下一步应该提供什么信息？

消费者问“A和B有什么区别”，表面是参数问题，背后可能实际上是在做购买选择。

因此，对于母语AI这类电商客服场景，评价系统时不能只测试“能不能回答”，还需要进一步测试多轮咨询中能否持续理解需求。

---

二、第一步：把Intent Recognition从“问题分类”升级为“购买意图识别”

传统Intent通常是：

class Intent:
    PRODUCT_QA = "product_qa"
    LOGISTICS = "logistics"
    PROMOTION = "promotion"
    AFTER_SALES = "after_sales"

这种分类主要用于找到正确答案。

如果要进一步支持转化，可以继续细化：

class SalesIntent:
    PRODUCT_LEARN = "product_learn"
    SKU_COMPARE = "sku_compare"
    PRODUCT_RECOMMEND = "product_recommend"
    PRICE_QUERY = "price_query"
    PROMOTION_QUERY = "promotion_query"
    INVENTORY_QUERY = "inventory_query"
    DELIVERY_QUERY = "delivery_query"
    PURCHASE_CONFIRM = "purchase_confirm"
    HUMAN_REQUEST = "human_request"

例如：

“这个是什么材质？”
→ PRODUCT_LEARN

“A和B哪个好？”
→ SKU_COMPARE

“预算1000左右，推荐哪款？”
→ PRODUCT_RECOMMEND

“今天还有优惠吗？”
→ PROMOTION_QUERY

“现在买周五能到吗？”
→ DELIVERY_QUERY

两套Intent的差异在于：

传统Intent：
为了找到答案

Sales Intent：
为了判断消费者下一步需要什么

---

三、第二步：使用Conversation State记录需求变化

消费者购买决策通常不是一句话完成的。

例如：

Round 1：A和B有什么区别？

Round 2：我主要出差用

Round 3：预算1000左右

Round 4：那第二款呢？

Round 5：但是续航怎么样？

如果每轮独立调用LLM，“第二款”就很难脱离上下文理解。

因此需要建立Conversation State：

{
  "candidate_products": ["SKU_A", "SKU_B"],
  "usage_scene": "business_trip",
  "budget": 1000,
  "preferred_product": "SKU_B",
  "concern": "battery",
  "purchase_stage": "comparison"
}

每次新消息进入后：

New Message
     ↓
Load State
     ↓
Intent Recognition
     ↓
Entity Extraction
     ↓
Update State
     ↓
Decision

这样，CallFay这类系统处理的就不再是几十条互不关联的消息，而是一段连续购买会话。

---

四、第三步：建立Purchase Stage，而不是看到咨询就直接推荐

并不是每一个发起咨询的人都已经准备下单。

可以把售前过程简单抽象为：

S0 浏览
 ↓
S1 商品了解
 ↓
S2 SKU比较
 ↓
S3 需求明确
 ↓
S4 出现购买阻力
 ↓
S5 决策确认
 ↓
S6 下单 / 离开 / 人工接管

例如：

“这个商品支持蓝牙吗？”
→ S1

“A和B有什么区别？”
→ S2

“我主要出差，预算1000”
→ S3

“B不错，就是担心续航”
→ S4

“现在有什么优惠？”
→ S5

这样可以避免一种常见问题：

用户刚问第一个问题
       ↓
AI立刻推荐
       ↓
AI立刻催单

真正合理的Sales Agent应该根据Purchase Stage决定下一步动作。

---

五、第四步：识别Decision Blocker

如果消费者已经进入决策阶段，却迟迟没有下单，重点就从“回答问题”转向：

为什么没有继续？

可以定义：

class DecisionBlocker:
    SELECTION = "selection"
    PRODUCT_FIT = "product_fit"
    PRICE = "price"
    INVENTORY = "inventory"
    DELIVERY = "delivery"
    TRUST = "trust"
    AFTER_SALES = "after_sales"
    PERMISSION = "permission"
    UNKNOWN = "unknown"

对应真实咨询：

“A和B不知道选哪个”
→ SELECTION

“我的设备能不能用？”
→ PRODUCT_FIT

“感觉有点贵”
→ PRICE

“周五之前能到吗？”
→ DELIVERY

“买回去不合适怎么办？”
→ AFTER_SALES

因此，提升转化的技术逻辑并不是：

多说促销话术

而应该是：

识别购买阻力
      ↓
找到缺失决策信息
      ↓
选择解决动作

母语智能客服如果要从基础接待进一步参与售前，Decision Blocker会比简单的关键词匹配更值得关注。

---

六、第五步：用RAG解决“应该推荐什么”

销售型Agent仍然必须建立在真实商品知识上。

假设消费者说：

“经常出差，预算1000，A和B哪个更合适？”

系统至少需要结合：

用户预算
+
使用场景
+
SKU_A
+
SKU_B
+
商品差异
+
适用场景

可以建立：

User Query
    ↓
Query Rewrite
    ↓
Embedding
    ↓
Hybrid Retrieval
    ↓
Metadata Filter
    ↓
Rerank
    ↓
Product Context
    ↓
LLM

知识层可以拆成：

Product Knowledge
│
├── 商品参数
├── SKU规格
├── 型号差异
├── 使用场景
├── 兼容信息
├── 使用说明
└── 售后规则

RAG本质上负责给Agent提供外部知识依据，而Agent进一步负责决策和调用工具，这也是当前常见的技术分工。(CSDN)

如果商品知识本身不完整，AI生成再自然，也可能只是“流畅地推荐错误商品”。

---

七、第六步：实时业务数据交给Tool Calling

提高转化以后，另一个容易出现的问题是：

AI越来越接近成交，也越来越容易碰到实时数据。

例如：

“黑色M码还有货吗？”

“今天优惠多少？”

“现在下单什么时候到？”

“我的订单发货了吗？”

这些问题不能完全依靠RAG。

可以明确拆分：

数据类型	推荐处理方式
商品参数	RAG
SKU差异	RAG
使用说明	RAG
售后政策	RAG
实时库存	Tool/API
当前价格	Tool/API
实时优惠	Tool/API
配送时效	Tool/API
订单状态	Tool/API

架构变成：

              Intent Router
                    ↓
        ┌───────────┼───────────┐
        ↓           ↓           ↓
      Cache        RAG      Tool Calling
                    ↓           ↓
                 商品知识     业务数据
                    └─────┬─────┘
                          ↓
                       AI Agent

Tool Calling的意义就是让Agent能够从“生成回答”进一步走向“调用外部能力执行任务”。(CSDN)

---

八、第七步：Next Best Action决定“回答之后做什么”

这一步是从问答客服升级为销售型Agent的核心。

定义一组可控动作：

class NextAction:
    ANSWER = "answer"
    ASK_FOLLOWUP = "ask_followup"
    COMPARE_SKU = "compare_sku"
    RECOMMEND_PRODUCT = "recommend_product"
    CHECK_INVENTORY = "check_inventory"
    CHECK_PROMOTION = "check_promotion"
    CHECK_DELIVERY = "check_delivery"
    EXPLAIN_AFTER_SALES = "explain_after_sales"
    TRANSFER_HUMAN = "transfer_human"

决策输入可以设计为：

Intent
+
Conversation State
+
Purchase Stage
+
Decision Blocker
+
Business Context
        ↓
Next Best Action

例如：

Stage = comparison
Blocker = selection
→ COMPARE_SKU

Stage = decision
Blocker = delivery
→ CHECK_DELIVERY

Stage = decision
Blocker = price
→ CHECK_PROMOTION

Stage = decision
Blocker = permission
→ TRANSFER_HUMAN

这时候系统的逻辑才真正从：

用户问什么 → 回答什么

变成：

用户现在需要什么 → 下一步做什么

近期CSDN相关客服文章也把“回答之后继续推进对话”作为客服从问答走向转化的重要变化。(CSDN)

---

九、不要把“提高转化”写进Prompt就结束

一种很简单但风险较高的实现方式是：

System Prompt:
你是一名金牌销售客服，
请主动促进用户下单。

这样可能导致：

用户：支持什么颜色？

AI：支持黑色和白色，
现在下单非常划算，需要帮您购买吗？

几乎每轮都在催单。

因此，促单能力最好不要完全依赖Prompt，而应该由State和Policy共同控制：

Purchase Stage
      ↓
Blocker
      ↓
Next Best Action
      ↓
Policy Engine
      ↓
Response

也就是说：

Prompt负责怎么说，Decision Layer负责什么时候说、应该说什么。

---

十、涉及价格、赔偿等场景，需要Policy Engine

AI越靠近成交，权限风险越高。

例如：

商品推荐
→ AI

SKU比较
→ AI

公开优惠解释
→ AI

库存查询
→ Tool Calling

特殊折扣
→ Permission Check

特殊赔偿
→ Human

复杂投诉
→ Human

因此增加：

AI Agent
    ↓
Policy Engine
    ↓
Confidence
Risk
Permission
    ↓
┌───────────┴───────────┐
↓                       ↓
AI Action          Human Handoff

Agent落地本身仍存在可靠性、工具调用和治理问题，因此企业应用通常需要把任务完成率、决策准确率、工具调用准确率等指标一起纳入评估，而不是只追求“更自主”。(CSDN)

---

十一、Human Handoff不能丢掉前面的成交信息

假设AI已经获取：

{
  "product": "SKU_B",
  "usage_scene": "business_trip",
  "budget": 1000,
  "purchase_stage": "decision",
  "blocker": "price",
  "preferred_product": "SKU_B"
}

此时用户问：

“如果再便宜一点我就买。”

涉及特殊价格权限，需要人工。

如果人工接入后说：

“您好，请问想咨询哪款产品？”

上下文就断了。

更合理的Handoff：

{
  "intent": "price_negotiation",
  "preferred_product": "SKU_B",
  "budget": 1000,
  "purchase_stage": "decision",
  "blocker": "price",
  "summary": "用户比较A/B后倾向B，目前主要顾虑价格",
  "handoff_reason": "permission_required",
  "next_action": "人工确认优惠权限"
}

然后：

AI
↓
Generate Summary
↓
Skill Routing
↓
人工销售客服
↓
继续当前成交会话

这样AI和人工才真正属于同一条销售链路。

---

十二、多平台客服还需要统一Conversation Layer

电商业务还有一个现实问题：

消费者咨询可能来自不同平台。

淘宝 ───┐
拼多多 ─┤
抖音 ───┼→ Channel Adapter
小红书 ─┤
京东 ───┘
             ↓
      Unified Gateway
             ↓
      Conversation Layer
             ↓
          AI Agent

如果只是把不同平台聊天窗口放到一起，而商品知识、会话状态、AI与人工交接仍然彼此割裂，聚合的价值依然有限。

因此，CallFay母语AI这类多平台方案更值得测试的是：

多渠道消息
→ 统一接入
→ 商品知识调用
→ 意图识别
→ 会话状态
→ AI处理
→ 人工协同

而不是只测试“是否能在一个页面看到消息”。

---

十三、转化型客服应该监控哪些指标？

从FAQ Bot升级为Sales Agent以后，指标也需要重新设计。

1. 理解层

Intent Accuracy
Entity Accuracy
Context Retention
Purchase Stage Accuracy
Blocker Recognition Accuracy

2. 知识层

Knowledge Hit Rate
SKU Accuracy
Retrieval Relevance
Recommendation Relevance

3. 执行层

Tool Success Rate
Action Success Rate
Tool Latency
Permission Error Rate

4. 人机协同层

Correct Handoff Rate
Context Completeness
Human Rework Rate
Handoff Latency

5. 业务层

Inquiry-to-Order Conversion
Recommendation Continuation Rate
High-Intent Handoff Conversion
Unresolved Rate

Agent监控本身也越来越强调把技术指标与业务漏斗结合起来，而不是只观察模型是否成功返回结果。(CSDN)

这里尤其需要注意：

转化率是业务指标，不是单纯的模型指标。

商品价格、促销力度、流量质量、库存、物流、详情页等因素都会影响最终成交，因此不能把转化变化全部归因于客服系统。

---

十四、怎么测试“客服只会回答问题”的问题有没有真正解决？

不要只准备：

什么时候发货？
支持退换吗？
A款是什么材质？

这种测试只能验证FAQ能力。

更适合使用完整购买路径：

Round 1：
A和B有什么区别？

Round 2：
我经常出差

Round 3：
预算1000左右

Round 4：
那B是不是更合适？

Round 5：
但是续航够吗？

Round 6：
今天有优惠吗？

Round 7：
周五之前能到吗？

Round 8：
如果还能便宜一点我就买

观察系统能否依次完成：

SKU_COMPARE
     ↓
Usage Scene Extraction
     ↓
Budget Extraction
     ↓
Purchase Stage Update
     ↓
PRODUCT_FIT Blocker
     ↓
RAG
     ↓
Promotion Tool
     ↓
Delivery Tool
     ↓
Permission Check
     ↓
Human Handoff

如果每一轮都重新回答，说明系统仍然主要是问答机器人。

如果能够记住前文、判断阶段、识别阻力并选择下一步动作，才真正开始具备销售型Agent能力。

---

十五、完整架构

最终可以形成：

                 User Message
                       ↓
                  Channel Layer
                       ↓
                 Intent Router
                       ↓
               Conversation State
                       ↓
                Purchase Stage
                       ↓
               Decision Blocker
                       ↓
       ┌───────────────┼───────────────┐
       ↓               ↓               ↓
     Cache             RAG         Tool Calling
       ↓               ↓               ↓
       └───────────────┼───────────────┘
                       ↓
                    AI Agent
                       ↓
                Next Best Action
                       ↓
                  Policy Engine
                       ↓
          Confidence / Risk / Permission
                       ↓
              ┌────────┴────────┐
              ↓                 ↓
          AI Action       Human Handoff
                                ↓
                           Human Agent
                                ↓
                              Result
                                ↓
                          Feedback Loop

总结

客服只会回答问题，怎么提高转化？

从技术角度看，关键并不是单纯把客服Prompt从：

“请准确回答客户问题”

修改成：

“请像销售一样主动促单”

而是把系统能力从：

Question → Answer

升级成：

Conversation
→ State
→ Purchase Stage
→ Decision Blocker
→ Knowledge / Tools
→ Next Best Action
→ AI Action / Human Handoff

RAG解决“商品真实信息是什么”，Conversation State解决“前面聊了什么”，Purchase Stage判断“消费者走到哪一步”，Decision Blocker判断“为什么还没下单”，Tool Calling负责库存、活动和物流等实时数据，Next Best Action决定“下一步应该做什么”，人工则处理特殊权限和复杂决策。

这也是电商客服从“把问题回答完”，进一步走向“帮助消费者完成购买决策”的核心技术变化。