客服 Agent 完整架构设计

原创灵阙教研团队

S 精选提升架构设计 | 约 7 分钟阅读更新于 2026-02-27

AI 导读

客服 Agent 完整架构设计从意图识别到人工交接：构建三级客服智能体的工程实践一、架构总览客服 Agent 的核心挑战不是"能不能回答问题"，而是"知道什么时候该升级、该交接、该闭嘴"。本文设计一个三级分流架构：L1 全自动解决高频问题，L2 Agent 辅助人工处理复杂场景，L3 无缝交接至人工坐席。客服 Agent 三级架构...

客服 Agent 完整架构设计

从意图识别到人工交接：构建三级客服智能体的工程实践

一、架构总览

客服 Agent 的核心挑战不是"能不能回答问题"，而是"知道什么时候该升级、该交接、该闭嘴"。本文设计一个三级分流架构：L1 全自动解决高频问题，L2 Agent 辅助人工处理复杂场景，L3 无缝交接至人工坐席。

                     客服 Agent 三级架构
 ================================================================

 用户消息
   |
   v
 +---------------------------+
 |     意图分类器 (Router)    |    ← 基于 embedding + 规则双通道
 +---------------------------+
   |          |           |
   v          v           v
 +------+  +------+  +----------+
 |  L1  |  |  L2  |  |    L3    |
 | 自动  |  | 辅助  |  | 人工交接 |
 | 解决  |  | 处理  |  |         |
 +------+  +------+  +----------+
   |          |           |
   |     +----+----+      |
   |     | 知识库   |      |
   |     | (RAG)   |      |
   |     +---------+      |
   v          v           v
 +---------------------------+
 |    会话状态管理 (FSM)      |
 +---------------------------+
   |
   v
 +---------------------------+
 |    评估与反馈闭环          |
 +---------------------------+

二、意图分类器设计

意图分类是整个系统的"分诊台"。我们采用双通道策略：规则匹配处理确定性场景，向量检索处理模糊意图。

from dataclasses import dataclass
from enum import Enum
from typing import Optional
import numpy as np


class IntentLevel(Enum):
    L1_AUTO = "l1_auto"
    L2_ASSISTED = "l2_assisted"
    L3_HUMAN = "l3_human"


class IntentType(Enum):
    ORDER_QUERY = "order_query"
    REFUND_REQUEST = "refund_request"
    FAQ = "faq"
    COMPLAINT = "complaint"
    TECHNICAL_ISSUE = "technical_issue"
    ACCOUNT_SECURITY = "account_security"
    UNKNOWN = "unknown"


# 意图 -> 级别的路由映射
INTENT_ROUTING: dict[IntentType, IntentLevel] = {
    IntentType.ORDER_QUERY: IntentLevel.L1_AUTO,
    IntentType.FAQ: IntentLevel.L1_AUTO,
    IntentType.REFUND_REQUEST: IntentLevel.L2_ASSISTED,
    IntentType.TECHNICAL_ISSUE: IntentLevel.L2_ASSISTED,
    IntentType.COMPLAINT: IntentLevel.L3_HUMAN,
    IntentType.ACCOUNT_SECURITY: IntentLevel.L3_HUMAN,
    IntentType.UNKNOWN: IntentLevel.L2_ASSISTED,
}


@dataclass
class ClassificationResult:
    intent: IntentType
    level: IntentLevel
    confidence: float
    reasoning: str


def classify_intent(
    message: str,
    rule_patterns: dict[str, IntentType],
    embedding_model,
    intent_embeddings: dict[str, np.ndarray],
    confidence_threshold: float = 0.78,
) -> ClassificationResult:
    """双通道意图分类：规则优先，向量兜底。"""

    # 通道 1：规则匹配（确定性高、延迟低）
    normalized = message.lower().strip()
    for pattern, intent in rule_patterns.items():
        if pattern in normalized:
            return ClassificationResult(
                intent=intent,
                level=INTENT_ROUTING[intent],
                confidence=0.95,
                reasoning=f"rule_match: pattern='{pattern}'",
            )

    # 通道 2：向量检索（处理模糊表达）
    msg_embedding = embedding_model.encode(message)
    best_intent = IntentType.UNKNOWN
    best_score = 0.0

    for intent_name, intent_emb in intent_embeddings.items():
        score = float(np.dot(msg_embedding, intent_emb) / (
            np.linalg.norm(msg_embedding) * np.linalg.norm(intent_emb)
        ))
        if score > best_score:
            best_score = score
            best_intent = IntentType(intent_name)

    if best_score < confidence_threshold:
        best_intent = IntentType.UNKNOWN

    return ClassificationResult(
        intent=best_intent,
        level=INTENT_ROUTING[best_intent],
        confidence=best_score,
        reasoning=f"embedding_match: score={best_score:.3f}",
    )

三、会话状态机

客服对话不是无状态的问答，而是有明确生命周期的流程。用有限状态机管理会话，确保每个状态都有出路。

 会话状态流转图
 =============================================

 [idle] --用户发起--> [classifying]
                         |
            +------------+------------+
            |            |            |
            v            v            v
      [l1_resolving] [l2_assisting] [l3_queuing]
            |            |            |
            v            v            v
      [l1_resolved]  [l2_resolved] [l3_connected]
            |            |            |
            +------------+-----+------+
                               |
                               v
                        [feedback_pending]
                               |
                               v
                           [closed]

四、工具定义（Tool Schema）

Agent 的能力边界由工具决定。以下是三个核心工具的 JSON Schema 定义。

TOOLS = [
    {
        "name": "order_lookup",
        "description": "根据订单号或用户ID查询订单状态、物流信息、支付详情",
        "input_schema": {
            "type": "object",
            "properties": {
                "order_id": {
                    "type": "string",
                    "description": "订单编号，格式：ORD-YYYYMMDD-XXXXX",
                },
                "user_id": {
                    "type": "string",
                    "description": "用户ID，当无订单号时用于模糊查询",
                },
                "fields": {
                    "type": "array",
                    "items": {"type": "string"},
                    "description": "需要返回的字段：status/logistics/payment/items",
                },
            },
            "required": ["fields"],
        },
    },
    {
        "name": "process_refund",
        "description": "发起退款申请。金额超过500元或订单超过30天需人工审批",
        "input_schema": {
            "type": "object",
            "properties": {
                "order_id": {"type": "string"},
                "reason": {
                    "type": "string",
                    "enum": [
                        "quality_issue",
                        "wrong_item",
                        "not_received",
                        "changed_mind",
                        "other",
                    ],
                },
                "amount": {
                    "type": "number",
                    "description": "退款金额（元），不得超过订单实付金额",
                },
                "evidence_urls": {
                    "type": "array",
                    "items": {"type": "string"},
                    "description": "凭证图片URL列表",
                },
            },
            "required": ["order_id", "reason", "amount"],
        },
    },
    {
        "name": "faq_search",
        "description": "在知识库中检索FAQ，返回最相关的答案片段",
        "input_schema": {
            "type": "object",
            "properties": {
                "query": {"type": "string", "description": "用户问题"},
                "category": {
                    "type": "string",
                    "description": "限定搜索类目：shipping/payment/account/product",
                },
                "top_k": {
                    "type": "integer",
                    "default": 3,
                    "description": "返回结果数量",
                },
            },
            "required": ["query"],
        },
    },
]

五、System Prompt 模板

# 角色
你是「灵阙商城」的智能客服助手。你的职责是高效、准确、有温度地帮助用户解决问题。

# 核心原则
1. 先理解，再回答。确认用户意图后再调用工具，不要猜测。
2. 能解决就解决，不能解决就升级。禁止给用户"踢皮球"的感受。
3. 涉及资金操作（退款/赔偿）必须二次确认。
4. 不编造信息。知识库没有的答案，如实告知并升级。
5. 保持简洁。每次回复不超过3段，优先用列表呈现关键信息。

# 工具使用规则
- order_lookup: 用户提到订单/物流/发货时调用
- process_refund: 仅在用户明确表达退款意愿且确认后调用
- faq_search: 通用问题优先检索知识库

# 升级规则（触发任一条件立即升级至人工）
- 用户连续表达不满超过2轮
- 涉及账户安全（盗号/异常登录/资金异常）
- 退款金额 > 500元
- Agent 连续2次未能解决用户问题（用户重复提问）
- 用户主动要求人工服务

# 会话上下文
当前用户ID: {{user_id}}
会话ID: {{session_id}}
历史摘要: {{conversation_summary}}

六、RAG 知识库集成

 知识库检索流程
 =============================================

 用户问题
   |
   v
 +------------------+
 | Query Rewriting  |    ← 消歧义 + 关键词提取
 +------------------+
   |
   v
 +------------------+
 | Hybrid Search    |    ← BM25 + 向量检索
 | (Elasticsearch   |
 |  + pgvector)     |
 +------------------+
   |
   v
 +------------------+
 | Reranker         |    ← Cross-encoder 精排
 +------------------+
   |
   v
 +------------------+
 | Context Assembly |    ← Top-3 片段 + 元数据
 +------------------+
   |
   v
 +------------------+
 | LLM Generation   |    ← 基于检索结果生成回答
 +------------------+

知识库数据来源：产品手册、退换货政策、物流规则、历史工单（脱敏）、FAQ 文档。每周增量更新，每月全量重建索引。

七、评估指标体系

指标	定义	L1 目标	L2 目标	L3 基线
自动解决率	L1 独立解决 / 总会话	>= 65%	-	-
首次解决率 (FCR)	单次会话解决 / 总会话	>= 80%	>= 70%	>= 85%
平均处理时长 (AHT)	从开始到关闭的平均时间	< 90s	< 300s	< 600s
用户满意度 (CSAT)	结束后评分 4-5 星占比	>= 85%	>= 80%	>= 90%
升级准确率	应升级且升级 / 应升级总数	>= 95%	-	-
幻觉率	回答与知识库矛盾的比例	< 2%	< 1%	-

八、关键设计决策

为什么不用纯 LLM 做意图分类？ 规则通道处理确定性场景（订单号正则匹配）延迟 < 5ms，向量通道处理模糊表达延迟 ~50ms。混合策略比纯 LLM 分类（~500ms）快一个数量级，且规则部分 100% 可控。
为什么 L2 不是全自动？ 退款等资金操作的错误成本极高。L2 让 Agent 准备好方案、拉取数据、草拟回复，但最终操作由人工确认。这是成本与风险的最优平衡点。
为什么用状态机而不是自由对话？ 自由对话在客服场景容易失控（Agent 被用户带偏、忘记收集关键信息）。状态机确保每个阶段有明确目标和退出条件，同时保留 LLM 在每个状态内的灵活表达能力。
升级判定为什么用规则而不是情感分析？ 情感分析模型在短文本上准确率不稳定（约 75-80%）。而"连续不满2轮"的规则判定虽然粗糙，但误判成本低（最多多升级几次），远好过漏判导致用户流失。

Maurice | [email protected]

深度加工（NotebookLM 生成）

基于本文内容生成的 PPT 大纲、博客摘要、短视频脚本与 Deep Dive 播客，用于多场景复用

PPT 大纲（5-8 张幻灯片）点击展开

客服 Agent 完整架构设计 — ppt

这里是基于您上传的《客服 Agent 完整架构设计》文章生成的 7 张 PPT 大纲，已按照要求使用 Markdown 格式排版：

核心挑战与三级分流架构总览

系统的核心挑战：客服 Agent 的关键不仅在于能否回答问题，更在于“知道什么时候该升级、该交接、该闭嘴” [1]。
L1 全自动解决：负责独立处理高频、确定性的常见问题 [1]。
L2 辅助人工：由 Agent 拉取数据、草拟方案，辅助人工处理复杂场景，以平衡风险与成本 [1, 2]。
L3 人工交接：在系统无法解决或遇到高危情况时，无缝转交至人工坐席 [1]。

双通道意图分类器设计

“分诊台”定位：意图分类器是决定会话走向的起点，负责将问题路由至 L1、L2 或 L3 [1, 3]。
通道一（规则匹配）：优先处理确定性场景（如订单号正则匹配），响应延迟极低且 100% 可控 [1, 2]。
通道二（向量检索）：用于处理模糊表达，计算相似度分数，作为兜底策略 [1, 4]。
决策优势：混合策略比纯 LLM 分类快一个数量级，有效解决了单纯依赖大模型带来的高延迟问题 [2]。

基于有限状态机 (FSM) 的会话管理

摒弃无状态问答：客服对话具有明确的生命周期和流程，不能仅靠简单的自由对话 [4]。
确保会话可控：状态机设计可防止 Agent 被用户带偏或忘记收集关键信息，确保每个阶段都有明确目标和出路 [4, 5]。
状态流转机制：涵盖从分类识别（classifying）、各级处理（resolving/assisting）到完结或反馈闭环的完整链路 [4, 6]。
兼顾灵活性：在保证业务流程不偏离的前提下，依然保留了 LLM 在单个状态内的灵活表达能力 [5]。

Agent 工具能力边界与核心原则

工具定义能力：Agent 的能力边界由其配置的工具决定，核心工具包括订单查询、退款处理和 FAQ 检索 [6, 7]。
先理解再行动：必须先确认用户意图后才能调用相关工具，禁止胡乱猜测 [7]。
拒绝“踢皮球”：系统应秉持“能解决就解决，不能解决就升级”的原则，保障用户体验 [7]。
严控资金与幻觉：涉及资金操作必须二次确认，且禁止 Agent 编造知识库中不存在的信息 [7]。

触发人工升级的底线机制

用户体验兜底：当用户连续两轮表达不满，或 Agent 连续两次未能解决问题（用户重复提问）时，立即升级 [7]。
高风险场景熔断：涉及退款金额大于 500 元，或涉及账户安全（盗号/异常登录等）的事件直接转人工 [7]。
用户主动要求：在任何阶段，只要用户明确要求人工服务，系统无条件转交 [7]。
为何使用规则判定：相比准确率不稳定的情感分析模型，简单的“连续不满2轮”规则误判成本低，能更有效地防止用户流失 [5]。

RAG 知识库的集成与检索流程

数据基础：融合产品手册、物流规则、脱敏历史工单等，实施每周增量与每月全量更新 [2]。
查询预处理：首先对用户的 Query 进行消歧义与关键词提取（Query Rewriting） [2]。
混合检索策略：采用 BM25 与向量检索（Elasticsearch + pgvector）双重机制寻找相关内容 [2]。
精排与生成：通过 Cross-encoder 对检索结果进行精确排序，提取 Top-3 片段交由 LLM 生成最终回答 [2]。

评估指标体系与关键设计决策

核心业务指标：关注 L1 自动解决率（目标 >= 65%）、首次解决率（FCR）、平均处理时长（AHT）以及用户满意度（CSAT） [2]。
质量防线：严格要求升级准确率达到 95% 以上，并将 L1 和 L2 的幻觉率分别压降至 2% 和 1% 以下 [2]。
L2 不做全自动的原因：退款等资金操作错误成本极高，由 Agent 准备方案但由人工进行最终操作确认，是成本与风险的最优平衡点 [2, 5]。

博客摘要 + 核心看点点击展开

客服 Agent 完整架构设计 — summary

这是一份为您定制的 SEO 友好博客摘要及核心看点：

SEO 友好博客摘要（约 150 字）

本文深入解析了构建高效客服 Agent 的完整架构设计与工程实践。面对智能客服“何时升级或交接”的核心挑战，文章创新提出了 L1 自动解决、L2 辅助处理与 L3 人工交接的“三级分流架构”[1]。该方案采用规则与向量检索结合的双通道意图分类机制，实现低延迟与高可控[2, 3]；并引入有限状态机（FSM）精准管理会话生命周期，有效防止大模型对话失控[4, 5]。结合 RAG 知识库与完善的工具定义，本架构在开发成本与业务风险间取得了最优平衡，是企业落地智能客服的必读指南[3, 5, 6]。

3 条核心看点（每条 < 40 字）