2026年电商AI客服如何提升转化？从问答到决策型Agent的架构设计

原创

CallFay云起未来

发布于 2026-09-23 17:32:53

1270

摘要

传统AI客服的核心目标通常是降低重复咨询处理成本，技术链路主要围绕意图识别、知识检索和答案生成展开。但在电商售前场景中，仅仅“回答正确”并不意味着消费者会继续完成购买决策。

因此，“客服只会回答问题，怎么提高转化？”本质上不是一个话术优化问题，而是客服架构需要从 Question → Answer 向 Conversation → State → Decision → Action 演进。

从工程角度看，一套面向售前转化的客服Agent，可以拆成会话状态、购买阶段、决策阻力、RAG知识检索、业务工具调用、Next Best Action和Human Handoff等模块。腾讯云开发者社区近期的智能客服实践，也将上下文管理、RAG、业务API、任务路由和人工接管作为完整客服智能体的重要组成部分。

一、传统问答架构为什么难以继续推动转化？

传统客服架构通常可以抽象为：

User Query
    ↓
Intent Classification
    ↓
Knowledge Retrieval
    ↓
LLM
    ↓
Answer

例如：

用户：A款和B款有什么区别？
AI：返回A/B商品参数

用户：什么时候发货？
AI：返回物流规则

用户：支持退换吗？
AI：返回售后政策

这种架构解决的是：

用户问什么
    ↓
系统找到答案
    ↓
回复用户

但真实购买过程往往是连续的。

A和B有什么区别？
↓
我主要出差使用
↓
预算1000左右
↓
那B是不是更适合？
↓
但是续航怎么样？
↓
今天还有优惠吗？

这里已经不再是6个独立问题，而是一条逐渐明确的购买决策链。

因此，客服系统如果希望进一步参与售前转化，首先需要从单轮问答升级到多轮上下文管理。腾讯云开发者社区的客服实践也指出，类似“那第二个适合吗”“黑色还有吗”这样的表达依赖前文，需要通过上下文、意图识别、知识检索和业务规则共同处理。

二、第一层：建立Conversation State

销售型客服首先需要解决的问题是：

用户前面说了什么？

可以维护一个基础会话状态：

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

每轮对话执行：

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

这样系统处理的对象就从：

单条Message

变成：

完整Conversation

对于生产环境而言，上下文管理也是大模型客服区别于传统关键词机器人的重要环节

三、第二层：从Intent进一步识别Purchase Stage

知道用户“问什么”还不够，还需要知道用户“进行到哪一步”。

可以将售前状态抽象为：

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

例如：

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

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

“我主要出差，预算1000”
→ S3 需求明确

“B比较合适，但是有点贵”
→ S4 购买阻力

“今天还有优惠吗？”
→ S5 决策确认

这一步的意义在于防止系统把所有用户都当成“准备下单”。

刚开始了解商品时，可以补充信息；已经开始比较SKU时，可以帮助选择；进入决策阶段以后，再进一步解决价格、配送、库存等问题。

四、第三层：识别Decision Blocker

消费者没有继续下单，原因可能完全不同。

可以建立：

DecisionBlocker

├── SELECTION       不知道怎么选
├── PRODUCT_FIT     商品是否适配
├── PRICE           价格顾虑
├── INVENTORY       库存
├── DELIVERY        配送时效
├── TRUST           信任问题
├── AFTER_SALES     售后顾虑
├── PERMISSION      特殊权限
└── UNKNOWN         暂未识别

例如：

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

“我的设备可以用吗？”
→ PRODUCT_FIT

“感觉价格有点高”
→ PRICE

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

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

因此，提高转化不能简单实现成：

每回答一次
↓
增加一句促销话术

而应该是：

识别购买阶段
↓
判断Decision Blocker
↓
确定缺失信息
↓
执行对应动作

这也是客服从Answer Generator进一步向Decision Agent演进的关键。

五、第四层：RAG负责“回答依据”

当Agent需要比较SKU、解释商品参数或者根据使用场景推荐产品时，不能完全依赖模型自身知识。

生产环境更适合通过RAG接入企业商品资料：

User Query
    ↓
Query Rewrite
    ↓
Embedding
    ↓
Vector / Keyword Search
    ↓
Metadata Filter
    ↓
Rerank
    ↓
Product Context
    ↓
LLM

知识库可以包含：

knowledge_base/

├── product/
│   ├── 商品参数
│   ├── SKU规格
│   ├── 型号差异
│   └── 使用说明
│
├── scenario/
│   ├── 使用场景
│   └── 兼容信息
│
├── promotion/
│   └── 活动规则
│
└── after_sales/
    ├── 退换货规则
    └── 售后SOP

腾讯云开发者社区的RAG客服实践采用的也是类似链路：Query Rewrite → 检索 → Rerank → LLM，并强调商品、活动、售后等业务知识需要持续更新，而不是依赖模型自行补全

对于销售场景，这一点尤其重要：推荐错误的商品，可能比不推荐带来更大的业务风险。

六、第五层：动态业务数据通过Tool Calling获取

RAG解决的是“知识是什么”，但不能解决所有实时问题。

例如：

黑色M码现在有货吗？
今天优惠是多少？
现在下单什么时候到？
我的订单发货了吗？

这些信息具有明显的实时性。

因此可以拆成：

数据	处理方式
商品参数	RAG
SKU区别	RAG
使用说明	RAG
售后政策	RAG
实时库存	Tool/API
当前价格	Tool/API
实时活动	Tool/API
配送时效	Tool/API
订单状态	Tool/API

整体结构变成：

              Intent Router
                    ↓
       ┌────────────┼────────────┐
       ↓            ↓            ↓
     Cache         RAG       Tool Calling
       ↓            ↓            ↓
    高频答案      商品知识      业务系统
       └────────────┼────────────┘
                    ↓
                 AI Agent

腾讯云开发者社区公开的客服Agent架构同样将商品/FAQ交给RAG，订单交给业务系统/API，物流交给物流接口，高风险问题则进入人工流程

七、第六层：Next Best Action决定回答之后做什么

如果只做到RAG和Tool Calling，系统仍然可能只是一个更强的问答机器人。

真正决定转化链路的是：

回答之后做什么？

可以建立一组有限动作：

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 = permission

→ TRANSFER_HUMAN

此时系统才从：

Question → Answer

进一步进入：

Conversation → State → Decision → Action

八、不要把“提高转化”完全交给Prompt

一种常见实现方式是直接修改System Prompt：

你是一名优秀的电商销售客服，
回答客户问题以后主动引导客户下单。

但这可能导致：

用户：
这个商品有黑色吗？

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

如果每轮都进行类似引导，很容易造成过度营销。

因此，Prompt更适合解决：

怎么表达？

而Decision Layer应该解决：

什么时候表达？
应该表达什么？
当前是否适合继续推进？

更完整的逻辑应该是：

Conversation State
      ↓
Purchase Stage
      ↓
Decision Blocker
      ↓
Next Best Action
      ↓
Prompt
      ↓
Response

九、第七层：增加Policy Engine控制业务边界

AI越靠近交易环节，越需要明确权限。

例如：

商品参数解释
→ AI

SKU比较
→ AI

普通商品推荐
→ AI

库存查询
→ Tool Calling

公开活动解释
→ AI + Knowledge

特殊价格
→ Permission Check

特殊赔偿
→ Human

复杂投诉
→ Human

因此需要：

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

生产级智能客服本身也不是简单接入大模型API，而是渠道、知识、业务系统和人工服务共同组成的完整链路

十、第八层：Human Handoff必须携带购买上下文

例如当前状态为：

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

用户继续询问：

“如果还能再优惠一点，我就买。”

系统判断需要人工价格权限。

如果只是执行：

transfer_human()

人工接入后仍然需要重新理解全部对话。

更合理的是：

{
  "intent": "price_negotiation",
  "preferred_product": "SKU_B",
  "budget": 1000,
  "purchase_stage": "decision",
  "blocker": "price",
  "summary": "用户比较A/B后倾向B款，目前主要顾虑价格",
  "handoff_reason": "permission_required"
}

然后：

AI Agent
   ↓
Generate Summary
   ↓
Human Handoff
   ↓
Skill Routing
   ↓
Human Agent

人工直接从“价格顾虑”继续，而不是重新从“您想咨询什么”开始。

十一、多平台场景需要统一Conversation Layer

对于同时经营多个渠道的电商业务，还需要增加Channel Layer：

Platform A ─┐
Platform B ─┤
Platform C ─┼→ Channel Adapter
Platform D ─┤
Platform E ─┘
                 ↓
          Unified Gateway
                 ↓
        Conversation Layer
                 ↓
             AI Agent

腾讯云开发者社区的多渠道客服实践同样指出，不同渠道独立配置容易产生后台切换和重复配置，可以先通过统一消息层完成会话聚合，再进入AI处理流程

实际应用中，例如CallFay母语AI这类电商客服系统，可以把多渠道接入、商品知识、AI接待与人工协同放到同一处理链路中；真正需要验证的并不是“消息是否聚合到一个页面”，而是聚合以后会话状态和人工交接能否继续保持。

十二、指标体系也要从“回复量”转向“决策质量”

传统客服可能关注：

First Response Time
Response Count
Automation Rate

销售型Agent还需要增加：

Intent Accuracy
Context Retention
Purchase Stage Accuracy
Blocker Recognition Accuracy
Knowledge Hit Rate
SKU Accuracy
Tool Success Rate
Correct Handoff Rate
Context Completeness
Human Rework Rate

最终再结合业务侧观察：

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

这里需要注意，询单转化率受到商品竞争力、价格、活动、流量质量、库存和物流等多个因素共同影响，不能直接把变化全部归因于客服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
→ Conversation
→ State
→ Purchase Stage
→ Decision Blocker
→ RAG / Tool Calling
→ Next Best Action
→ Policy Engine
→ AI Action / Human Handoff

RAG负责回答“商品事实是什么”，Conversation State负责保存“前面聊了什么”，Purchase Stage判断“客户进行到哪一步”，Decision Blocker识别“为什么还没有继续购买”，Tool Calling获取库存、活动、物流等动态数据，Next Best Action决定下一步动作，Human Handoff处理需要权限、判断和复杂沟通的问题。

对于电商客服而言，从“把问题回答完”到“帮助消费者完成下一步决策”，才是问答型客服向销售型Agent演进时真正需要解决的技术问题。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

人工智能

媒体AI