26年电商AI客服如何实现人机协同？从任务路由到人工接管的架构设计

原创

CallFay云起未来

发布于 2026-09-15 18:12:08

770

摘要

AI客服从FAQ机器人向Agent演进后，系统设计的重点已经不只是“模型能回答多少问题”，而是如何在AI与人工之间建立稳定的任务边界。

在真实电商业务中，商品参数、物流规则等标准问题适合AI处理；订单查询需要调用实时业务接口；投诉、特殊退款、赔偿、价格权限等场景则需要人工介入。因此，“如何让 AI 客服和人工客服协同工作？”本质上是一个任务路由、知识检索、权限控制、上下文管理与Human Handoff共同组成的系统工程。

腾讯云开发者社区近期的Agent实践也将RAG、工具调用、工作流和治理视为Agent从Demo进入生产环境的重要组成部分。(腾讯云)

一、人机协同首先要解决任务边界

客服系统不适合把所有请求都交给同一个LLM处理。

可以先按照问题类型划分：

用户咨询
   ↓
Intent Router
   ├── 商品参数 / FAQ → RAG
   ├── SKU对比 → RAG + LLM
   ├── 库存 / 订单 → Tool Calling
   ├── 物流查询 → Business API
   ├── 标准售后 → Workflow
   └── 投诉 / 特殊退款 / 高风险问题 → Human

这里的核心不是判断“AI会不会回答”，而是判断三个条件：

Knowledge：是否有可靠知识依据
Risk：当前操作风险是否可控
Permission：AI是否拥有执行权限

即使模型能够理解特殊退款需求，也不意味着系统应该自动批准退款。

二、标准问题通过RAG处理

商品参数、SKU规格、发货规则、活动政策、基础售后等信息相对稳定，适合进入企业知识库。

基本链路为：

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

RAG的作用并不是让模型“知道更多”，而是尽量让回答建立在企业自己的知识数据之上。腾讯云开发者社区的客服RAG实践同样强调向量检索、知识上下文与生成链路的组合。(腾讯云开发者社区)

生产环境还需要增加知识置信度判断：

if knowledge_score >= threshold:
    return generate_answer(context)

return human_handoff(reason="LOW_KNOWLEDGE_CONFIDENCE")

如果没有足够知识依据，与其让模型补全答案，不如进入澄清或人工流程。

三、实时业务数据通过Tool Calling获取

RAG适合知识，但不适合保存所有实时业务状态。

例如：

库存
当前价格
实时优惠
订单状态
退款进度
物流状态

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

因此更适合采用：

用户：
“这个SKU现在还有库存吗？”
          ↓
Intent Recognition
          ↓
Tool Selection
          ↓
check_inventory(sku_id)
          ↓
Business System
          ↓
返回实时结果
          ↓
LLM组织回复

可定义一组受控工具：

check_inventory(sku_id)
query_order(order_id)
query_logistics(order_id)
get_promotion(sku_id)
create_ticket(issue)

Agent负责理解用户意图和选择工具，真实业务系统负责提供事实。

当接口Timeout、500或者返回异常结果时，不应让LLM根据历史上下文猜测业务状态，而应该进入Retry、Fallback或Human Handoff。

工具调用与外部系统执行能力，也是Agent区别于单纯对话模型的重要部分。(腾讯云开发者社区)

四、通过Conversation State保持多轮上下文

人机协同的另一个基础是会话状态。

例如：

用户：A和B有什么区别？
AI：……
用户：我主要出差使用
AI：……
用户：预算1000左右
AI：……
用户：再优惠一点我就下单

最后一句无法脱离前文单独理解。

因此可以维护结构化状态：

{
  "candidate_products": ["SKU_A", "SKU_B"],
  "preferred_product": "SKU_B",
  "usage_scene": "business_trip",
  "budget": 1000,
  "purchase_stage": "decision",
  "blocker": "price",
  "intent_level": "high"
}

Conversation State不仅用于下一轮AI回复，也应该成为人工接管时的输入。

否则系统虽然拥有多轮对话能力，但一旦进入人工环节，上下文仍然会断开。

五、什么时候触发Human Handoff？

人机协同的关键模块之一，是Handoff Policy。

可以建立多因子决策：

Handoff Score =
Confidence
+ Risk
+ Permission
+ Emotion
+ Failure Count
+ Business Priority

例如：

def should_handoff(ctx):
    if ctx.user_request_human:
        return True

    if ctx.confidence < 0.60:
        return True

    if ctx.risk_level == "HIGH":
        return True

    if ctx.permission_required:
        return True

    if ctx.failure_count >= 2:
        return True

    return False

腾讯云开发者社区已有客服Agent实践采用置信度、情绪、复杂度、失败次数以及业务优先级等因素判断是否需要转人工。(腾讯云开发者社区)

实际阈值不应直接照搬示例，而应基于企业自己的历史会话进行校准。

六、人工接管必须携带完整上下文

很多系统实现了“转人工”，却没有真正实现Human Handoff。

错误方式：

AI无法处理
   ↓
转人工
   ↓
人工：
“您好，请问有什么可以帮您？”

这意味着消费者必须重新描述问题。

更合理的方式是在转接前生成结构化Handoff Context：

{
  "intent": "PRICE_NEGOTIATION",
  "product": "SKU_B",
  "purchase_stage": "decision",
  "blocker": "price",
  "conversation_summary": "用户比较A/B后倾向B款，预算1000元，目前希望确认可用优惠",
  "reason": "PERMISSION_REQUIRED",
  "recommended_action": "人工确认优惠权限"
}

流程变成：

AI识别无法继续处理
        ↓
生成Conversation Summary
        ↓
保存Business State
        ↓
确定Handoff Reason
        ↓
匹配人工队列
        ↓
人工直接继续处理

所以，人机协同中的“转人工”并不是简单改变消息接收者，而是完成业务状态的交接。

七、人工客服也需要任务路由

Human Handoff之后，还需要解决“转给谁”。

例如：

复杂售前 → Sales Agent
异常订单 → Order Support
退款问题 → After-sales
投诉问题 → Senior Agent
技术问题 → Technical Support

可以建立Skill-based Routing：

ROUTING = {
    "HIGH_INTENT": "SALES",
    "REFUND": "AFTER_SALES",
    "ORDER_EXCEPTION": "ORDER_SUPPORT",
    "COMPLAINT": "SENIOR_AGENT",
    "TECHNICAL": "TECH_SUPPORT"
}

这样整个系统完成的就不是：

AI → 任意人工

而是：

AI → 判断问题 → 匹配对应技能组 → 人工继续处理

对于多店铺场景，还需要在路由过程中携带平台、店铺、商品、用户和历史会话等信息。

实际应用中，例如CallFay母语AI这类电商客服系统，可以把多渠道接入、AI接待与人工协作放在同一处理链路中；从架构角度看，重点仍然是统一会话状态、知识调用和转人工逻辑，而不是单纯聚合聊天窗口。

八、人工处理结果需要进入Feedback Loop

Human Handoff不是整个流程的终点。

假设某个问题一个月内大量触发人工：

“预售商品发货之前能不能修改地址？”

如果最终人工处理规则高度一致，需要进一步判断AI失败的原因。

可能是：

Knowledge Missing
→ 补充知识库

Intent Error
→ 优化Intent Router

Tool Missing
→ 增加业务Tool

Permission Required
→ 保留人工审批

Policy Error
→ 修改路由策略

因此完整链路应该是：

AI处理
   ↓
Human Handoff
   ↓
人工解决
   ↓
记录Resolution
   ↓
Failure Analysis
   ↓
Knowledge / Router / Tool / Policy更新
   ↓
Evaluation
   ↓
重新上线

这一步决定了系统能否随着真实业务持续迭代，而不是长期依赖固定Prompt。

九、不要单独追求低转人工率

生产环境中容易出现一个指标误区：

AI解决率越高越好
转人工率越低越好

如果模型为了降低转人工率，在知识不足或高风险情况下继续回答，可能导致：

Automation Rate ↑
       ↓
Wrong Answer ↑
       ↓
Repeated Query ↑
       ↓
Complaint Risk ↑

因此，更适合同时监控三类指标：

AI层
Intent Accuracy
Knowledge Hit Rate
Tool Success Rate
Answer Accuracy

协同层
Correct Handoff Rate
Handoff Latency
Context Completeness
Routing Accuracy
Human Rework Rate

业务层
First Contact Resolution
Average Handling Time
Customer Satisfaction
Inquiry Conversion
Complaint Rate

其中Human Rework Rate值得单独关注。

如果人工接管以后仍然需要重新询问商品、需求和问题背景，说明转人工虽然成功，但上下文交接并没有完成。

十、完整的人机协同架构

最终可以形成如下结构：

                     User
                      ↓
             Channel Gateway
                      ↓
                Intent Router
                      ↓
             Conversation State
                      ↓
        ┌─────────────┼─────────────┐
        ↓             ↓             ↓
      Cache          RAG       Tool Calling
        ↓             ↓             ↓
        └─────────────┼─────────────┘
                      ↓
                   AI Agent
                      ↓
                  Guardrail
                      ↓
       Confidence / Risk / Permission
                      ↓
            ┌─────────┴─────────┐
            ↓                   ↓
         AI Reply          Human Handoff
                                ↓
                        Skill-based Routing
                                ↓
                           Human Agent
                                ↓
                            Resolution
                                ↓
                         Feedback Loop
                                ↓
                Knowledge / Tool / Policy

这套架构的重点不是某一个模型，而是各模块之间是否形成稳定闭环。

企业Agent从Demo进入生产环境，也需要进一步处理权限、工具治理、异常恢复和可观测性等问题，而不能只验证模型能否完成一次成功调用。(腾讯云)

总结

AI客服和人工客服协同，本质上是一个任务编排问题。

可以归纳为：

标准问题 → AI
知识问题 → RAG + AI
实时业务问题 → Tool Calling
低置信度问题 → 人工
高风险问题 → 人工
权限型操作 → 人工确认
AI失败 → 携带上下文转人工
人工处理结果 → Feedback Loop

真正需要优化的并不是“AI替代了多少人工”，而是每一种问题是否进入了正确的处理路径。

对于生产级客服Agent来说，RAG解决知识依据，Tool Calling连接实时业务系统，Conversation State维持上下文，Policy Engine控制风险和权限，Human Handoff负责复杂场景兜底。

只有这些模块形成完整闭环，AI与人工才不是两个独立客服入口，而是一套能够共同完成业务任务的人机协同系统。

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

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

媒体AI

java-6

人工智能