26年AI客服能不能帮商家主动促单？从智能问答到销售型Agent的实现路径

摘要

传统电商AI客服主要解决“有没有人回复”的问题，而随着大模型、RAG、工具调用和Agent工作流逐渐进入客服系统，AI开始从被动回答向需求识别、商品推荐和业务执行延伸。华为云目前公开的Agent应用资料中，也已将电商售前咨询列为智能客服应用场景，并支持通过Prompt、知识库以及插件获取订单等业务信息

因此，“AI客服能不能帮商家主动促单？”这个问题不能简单理解成让模型自动发送营销话术。更值得研究的是：AI能否持续理解消费者需求，判断其购买阶段和当前阻力，再通过商品知识、实时业务数据以及人工协同完成下一步动作。

从技术架构看，可以将其抽象为：

用户咨询
   ↓
意图识别
   ↓
会话状态
   ↓
购买阶段判断
   ↓
成交阻力识别
   ↓
RAG / Tool Calling
   ↓
Next Best Action
   ↓
AI继续处理 / 人工接管

一、传统AI客服为什么很难直接参与成交？

早期客服机器人更接近一个问答系统：

Question
   ↓
Intent
   ↓
FAQ / Knowledge
   ↓
Answer

例如：

用户：A款续航多久？
AI：回答续航参数

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

这种模式解决的是Question → Answer。

但真实购买过程通常是连续的：

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

用户：我主要出差使用

用户：预算1000左右

用户：那B是不是更适合？

用户：但是我比较担心续航

如果系统把每句话都当成独立问题，就很难判断消费者已经从“了解商品”进入“商品比较”，又进一步进入“购买决策”。

所以销售型客服首先需要解决的不是“回答得更像销售”，而是把：

单轮问答

升级为：

多轮理解
+
状态记录
+
决策
+
业务动作

华为云公开的智能客服方案同样将多轮上下文、企业知识库和业务理解作为智能客服的重要组成部分

二、第一步：识别消费者当前咨询意图

主动促单之前，需要先知道消费者到底在解决什么问题。

可以将常见售前意图拆成：

PRODUCT_QA          商品咨询
SKU_COMPARE         商品比较
PRODUCT_RECOMMEND   商品推荐
PRICE_QUERY         价格咨询
PROMOTION_QUERY     活动咨询
INVENTORY_QUERY     库存查询
DELIVERY_QUERY      配送咨询
AFTER_SALES         售后咨询
HUMAN_REQUEST       人工请求

例如：

“A和B哪个好？”
→ SKU_COMPARE

“我经常出差，推荐哪个？”
→ PRODUCT_RECOMMEND

“黑色还有货吗？”
→ INVENTORY_QUERY

“今天买周五能到吗？”
→ DELIVERY_QUERY

只有Intent识别准确，后续才能决定调用知识库、查询业务系统，还是进入人工流程。

这也是母语AI这类电商客服从标准问答进一步走向售前辅助时，需要解决的第一层问题。

三、第二步：通过Conversation State保存购买上下文

单纯识别当前Intent仍然不够。

例如：

用户：A和B哪个好？
用户：我经常出差
用户：预算1000
用户：那第二款呢？

最后一句“第二款呢？”本身没有完整语义。

系统需要依赖此前对话才能知道：

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

因此，可以建立：

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

当前企业级智能助手的实践也已经将意图识别、RAG、业务工具与多轮对话记忆放在同一个Agent体系中。(华为云论坛)

对于CallFay这类面向电商业务的方案而言，如果要测试主动促单能力，多轮上下文是否连续，比单独测试一句话回复是否自然更有意义。

四、第三步：识别Purchase Stage

消费者从进入店铺到最终购买，通常会经历不同阶段。

可以抽象成：

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

例如：

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

“我经常出差”
→ S3 需求明确

“B挺合适，就是价格有点高”
→ S4 购买阻力

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

这样Agent关注的就不只是：

用户问了什么？

而是：

用户现在进行到哪一步？

这一步决定了后续动作应该是继续介绍商品、推荐SKU、查询库存，还是交给人工销售。

五、第四步：找到客户为什么没有下单

这一步可以称为Decision Blocker识别。

常见阻力可以拆成：

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

例如：

“两个型号不知道选哪个”
→ SELECTION

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

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

“再便宜一点我就买”
→ PRICE / PERMISSION

所以：

主动促单 ≠ 自动催付

更合理的逻辑应该是：

识别客户顾虑
      ↓
找到缺失决策信息
      ↓
选择下一步动作

这也是母语智能客服从“回答商品问题”进一步进入销售辅助环节时需要建立的核心能力。

六、第五步：使用RAG提供真实商品依据

主动推荐必须建立在可靠的商品知识之上。

例如消费者问：

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

Agent需要同时获取：

用户需求
+
预算
+
A款商品知识
+
B款商品知识
+
SKU差异
+
使用场景

因此可以使用RAG：

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

知识库可以包括：

商品参数
SKU规格
型号差异
使用说明
适配信息
使用场景
售后政策

华为云AgentArts的RAG文档也明确指出，RAG通过在模型推理前检索外部文档，并将结果作为上下文提交给大模型，从而补充企业私有知识和训练数据之外的信息。(华为云帮助中心)

因此，商品推荐是否准确，很大程度上取决于商品知识本身是否完整、结构是否清晰以及检索结果是否正确。

七、第六步：实时库存、优惠和物流交给Tool Calling

RAG并不能解决所有问题。

例如：

“黑色M码现在还有货吗？”

“今天还有什么优惠？”

“现在下单周五能到吗？”

这些数据随时可能发生变化。

因此需要明确区分：

相对稳定知识
→ RAG

实时业务状态
→ Tool Calling / API

例如：

商品参数
→ RAG

SKU区别
→ RAG

库存
→ Inventory API

优惠
→ Promotion API

配送
→ Logistics API

订单
→ Order API

可以形成：

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

华为云2026年公开的客服智能体参考架构也采用了“意图识别+RAG检索+工具调用业务系统”的组合方式，使Agent不仅能够查询知识，还能够连接CRM/BSS/OSS等系统执行实际业务。(华为云论坛)

对于电商场景，道理相同：商品知识可以检索，但库存、价格、物流等实时数据不能让模型猜。

八、第七步：通过Next Best Action决定下一步

当系统已经得到：

Intent
+
Conversation State
+
Purchase Stage
+
Decision Blocker

就可以进一步决定Next Best Action。

例如：

这时Agent完成的就不再只是：

Generate Answer

而是：

Understand
→ Decide
→ Act

华为云关于智能客服技术演进的资料同样将下一代客服的核心变化概括为从单纯问答进一步进入“理解—决策—执行”的业务闭环。(华为云论坛)

九、AI越接近成交，权限控制越重要

如果AI只回答：

“这个商品是什么材质？”

风险相对有限。

但如果开始涉及：

优惠
价格承诺
特殊折扣
赔偿
异常订单
特殊售后

就必须增加权限和风险判断。

可以设计：

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

例如：

普通商品推荐
→ AI

公开优惠说明
→ AI

实时库存
→ Tool Calling

特殊折扣
→ Human

特殊赔偿
→ Human

重大投诉
→ Human

因此，销售型Agent不是自动化程度越高越好。

越接近交易和权限环节，越需要明确哪些动作允许AI执行、哪些动作必须经过人工确认。

十、人机协同不能在转人工时“重新开始”

例如消费者已经完成：

A/B比较
 ↓
说明使用场景
 ↓
预算1000元
 ↓
倾向B款
 ↓
出现价格顾虑

因为涉及特殊优惠，需要人工介入。

如果人工接手以后重新问：

“您好，请问您需要咨询什么？”

前面的Agent判断基本被浪费。

更合理的是生成：

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

然后：

AI Agent
   ↓
Conversation Summary
   ↓
Human Handoff
   ↓
人工继续处理

华为云相关全渠道客服方案也支持坐席实时介入并查看历史对话，使人工能够基于此前上下文继续处理。(华为云)

这对于销售场景尤其重要，因为消费者的预算、商品偏好和当前顾虑本身就是成交上下文。

十一、完整销售型客服Agent架构

综合以上模块，可以形成：

                  User
                    ↓
              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

从技术层面看，这也是“自动回复型客服”和“销售型Agent”比较明显的区别。

前者核心是：

Question → Answer

后者更接近：

Conversation
→ State
→ Decision
→ Action

十二、落地时应该重点验证哪些指标？

如果目标是验证AI是否真正能够参与促单，不能只统计AI回复量。

可以从四个层面观察。

理解能力：

Intent Accuracy
Context Retention
Purchase Stage Accuracy
Blocker Recognition Accuracy

知识能力：

Knowledge Hit Rate
SKU Accuracy
Recommendation Relevance

业务执行能力：

Tool Success Rate
Inventory Query Accuracy
Promotion Query Accuracy
Action Success Rate

人机协同与业务结果：

Correct Handoff Rate
Context Completeness
Human Rework Rate
Inquiry-to-Order Conversion

其中，询单转化需要结合商家自己的历史数据、流量来源、商品价格、促销等因素分析，不能简单把变化全部归因于AI。

总结

所以，AI客服能不能帮商家主动促单？

从技术实现来看，可以把这一问题拆成：

客户说了什么？
→ Intent Recognition

前面聊了什么？
→ Conversation State

客户进行到哪一步？
→ Purchase Stage

为什么还没有买？
→ Decision Blocker

商品事实是什么？
→ RAG

库存、优惠、物流是什么状态？
→ Tool Calling

下一步应该做什么？
→ Next Best Action

AI有没有权限做？
→ Policy Engine

需要人工怎么办？
→ Human Handoff

华为云现有Agent和智能客服技术体系也已经覆盖知识库、RAG、多轮上下文、工作流编排以及业务工具调用等关键能力，为这类“理解—决策—执行”的智能客服架构提供了可参考的技术路径。(华为云论坛)

因此，真正值得关注的并不是AI会不会说“现在下单更划算”，而是：

当消费者已经产生购买意向但仍然犹豫时，系统能否准确判断他卡在选品、适配、价格、库存、配送还是售后，并调用正确的信息或人工资源解决这个阻力。

做到这一层，AI客服才真正从“自动回答”进一步走向“辅助成交”。