智能客服系统设计要点

业界智能客服系统的架构原则、安全模型、多系统对接与 BFF 设计提炼，适用于技术博客或个人笔记。

---

1. 系统定位与架构分层

核心概念

智能客服是嵌在现有客服体系中的 AI 入口，不是替代全部后台的单体应用。典型技术栈：LLM Agent + RAG + 业务系统集成 + 渠道 UI。

层次	职责
渠道层	登录、会话、多端接入、展示
Agent 层	意图理解、工具选择、多轮对话编排
BFF 集成层	聚合多系统、鉴权、降级、字段映射
业务系统层	订单、物流、支付、仓储、工单等真实数据源

两套状态必须分离：

• Agent 运行时状态：messages、推理步骤、checkpoint
• 业务实体状态：订单状态、工单状态、退款状态

不可将业务状态机建模为 Agent Graph 的边或节点替代方案。

实现原理/要点

标准调用链：

用户 → 渠道 → Agent → 语义化工具 → BFF → 各业务系统 Client → 数据源

Agent 编排层（LangGraph / ReAct 等）负责：

• 模型与工具的循环调用
• 条件路由、多 Agent 协作
• Checkpoint、断点续跑
• Human-in-the-loop（interrupt 人工审批节点）

不负责：

• 业务权限判定（RBAC/ABAC）
• 订单/工单状态机合法性
• 跨系统事务与幂等

业务规则必须在领域服务层以代码硬约束实现。

总结/注意事项

Agent 决定「调哪个工具」；BFF 与领域服务决定「能不能做、数据从哪来」。编排层与业务层职责分离是生产架构的基本纪律。

---

2. 安全模型：Prompt 不能承担写操作边界

核心概念

控制层	作用	性质
Prompt / System Message	流程引导、话术规范	软约束，可被 Prompt Injection 或模型失误绕过
代码硬约束	权限、状态机、角色隔离、审计	硬约束，生产必备

只靠 Prompt 控制状态流转或权限边界，在生产环境不可接受。

实现原理/要点

读操作最低要求：

• 身份绑定：网关注入 user_id，禁止由 LLM 自行指定操作主体
• 数据归属校验：订单、工单、账户信息仅返回当前用户有权访问的范围
• 敏感字段脱敏：手机号、地址、金额按角色脱敏

写操作标准防线（优先级从高到低）：

1. 不向用户侧 Agent 暴露高危写能力
2. RBAC / ABAC 角色权限校验
3. 业务状态机（合法状态跳转矩阵）
4. 语义化领域 API（cancel_order，而非裸 UPDATE status）
5. 审计日志 + 幂等键
6. 高危操作 Human-in-the-loop 审批
7. Prompt 流程引导（最末层）

典型风险模式：

风险	说明
无状态机	仅校验状态枚举，允许任意 A→B 跳转
读写工具混暴露	客服审核类 API 与用户查询 Agent 共用
流程仅存于 Prompt	「先核实再操作」无代码强制执行
缺审计	无法追溯谁、何时、改了什么
Prompt Injection	用户诱导模型调用越权工具

标准分层模型：

用户输入 → LLM（软约束）→ 工具入口 → 权限校验 → 状态机 → 领域服务 → 持久化

总结/注意事项

写操作安全公式：不提供能力 > 状态机 > 权限 > 审计 > Prompt。读操作可叠加 RAG grounding，但归属校验仍须在代码层完成。

---

3. 业务能力边界：Agent 做什么、不做什么

核心概念

生产环境中，智能客服标准定位为 「查询员 + 申请受理员」，不是 「订单/资金状态管理员」。

能力类型	生产常见度	说明
查订单 / 物流 / 商品 / 政策	非常高	只读，核心价值区
创建售后/退款/换货申请	常见	创建工单，非终审
查售后/退款进度	常见	只读
用户侧直接修改订单状态	几乎不做	由后端服务 + 状态机驱动
LLM 审批退款、承诺到账	不做	合规与资金风险

实现原理/要点

订单状态变更的标准触发源（事件驱动，非对话驱动）：

状态变化	触发源
待付款 → 已付款	支付网关回调
已付款 → 已发货	WMS 出库 / OMS 履约
已发货 → 已完成	物流签收 / 超时自动确认
→ 退款中	退款申请审批通过 + 支付系统发起退款
→ 已取消	未支付超时 / 规则允许取消 / 售后审核通过

用户「取消订单」的标准路径：

Agent 理解意图
  → 调用语义化 API（如 POST /orders/{id}/cancel 或 POST /refund-requests）
  → 领域服务校验当前状态是否可取消
  → 通过则更新状态并触发副作用（释库存、关支付单等）
  → 向用户返回受理结果（流程 + 单号），不承诺即时到账

用户侧 Agent 推荐工具边界：

✅ 订单/物流/商品查询
✅ 政策知识检索（RAG）
✅ 创建售后工单 / 退款申请
✅ 查询工单进度
✅ 转人工

❌ 直接修改订单/支付状态
❌ 客服审核/终审类操作
❌ 发起实际资金退款（属支付系统）

客服侧操作应通过独立后台、坐席工作台或高权限服务 API 完成，不与用户 Agent 共用工具集。

总结/注意事项

用户要的是「结果」，系统应先给「受理确认 + 单号 + 预计时效」。资金与状态终审永远在后端工作流，不在对话通道。

---

4. 落地场景与业务痛点

核心概念

落地形态是分场景嵌入现有客服体系，而非「单一万能 Agent 全量替代人工」。

场景	典型能力	风险等级
售前咨询	商品参数、活动规则、库存/发货说明	低
售中服务	查订单、查物流、催发货、改址申请	中
售后	受理退换货、查进度	高
政策合规	RAG + 法务审定知识库	中
坐席 Copilot	摘要、话术推荐、工单预填、质检辅助	低

实现原理/要点

十大业务痛点：

1. 成本与峰值 — 大促咨询量激增；KPI 通常为拦截率，行业经验约 80% 重复问题机器处理、20% 转人工
2. 重复劳动 — 查单、查物流、复制政策；最适合工具化
3. 多系统割裂 — 集成工作量常不低于模型与 Agent 开发
4. 答错代价 — 虚假退款承诺、越权泄露、政策误读引发批量纠纷
5. 多轮与跨渠道上下文 — 指代消解、会话恢复、身份统一
6. 情绪与对抗 — 愤怒用户需升级人工；Prompt Injection 攻击
7. 人机协作边界 — 转人工策略、会话交接、责任归属
8. 知识库运营 — 文档过期、版本不一致；运营成本常被低估
9. ROI 度量 — 拦截率、FCR、CSAT、答错率需联动评估
10. 组织协同 — 客服、交易、供应链、法务、技术多方协调

业界常见三阶段演进：

阶段 1：规则 / FAQ / 决策树机器人
  → 阶段 2：LLM + 只读工具（RAG + 订单/物流查询）
    → 阶段 3：工单受理 + 坐席 Copilot + 人工审核闭环

核心运营指标：

指标	含义	注意
拦截率 / 自助解决率	未转人工即结案比例	不宜为 KPI 牺牲满意度
转人工率	升级人工比例	过低可能强行死循环
FCR	首次接触解决率
AHT	人工平均处理时长	Copilot 常先体现价值
CSAT / NPS	用户满意度
答错率 / 人工纠错率	质检发现的机器错误	比模型 benchmark 更接近真实

总结/注意事项

业界普遍「先 Copilot、后对外机器人」。宁可明确转专员，也不幻觉式承诺。知识运营、转人工策略与 ROI 设计和模型选型同等重要。

---

5. 多系统对接

核心概念

多系统对接：智能客服通过 API、消息队列或同步读库等方式，连接企业内已存在的独立业务系统，获取实时、有权限、可审计的数据与受理能力。

标准原则：Agent 不直连各业务系统原始接口。

常见对接系统：

系统	客服用途	Agent 典型动作
OMS	订单状态、履约信息	只读查询
TMS / 快递 API	运单轨迹	只读查询
PIM / 商品中台	SKU 详情、规格	只读查询
WMS	出库、库存	按需只读
支付 / 退款	退款单状态	只读查询
工单 / ITSM	售后受理与进度	创建申请 + 查进度
知识库 / CMS	政策、FAQ	RAG 检索
CRM / 会员	等级、优惠券	只读查询
呼叫中心	人工坐席	转接 + 上下文移交

实现原理/要点

四种主流集成架构：

模式	说明	适用
客服 BFF	为客服场景定制的 API 聚合层	最常见
iPaaS / ESB	企业集成总线统一对接	系统多、历史包袱重
事件驱动 + 读模型	业务事件同步至客服读库/搜索索引	高 QPS 查询、可接受近实时
复用坐席后台 API	机器人与人工同源数据	避免人机信息不一致

分阶段接入路线图：

P0  知识库 + 统一身份认证
P1  OMS 只读（订单列表/详情）
P2  物流轨迹
P3  工单系统（创建 + 查询）
P4  商品 / 库存（售前场景）
P5  支付退款进度（只读，谨慎）

工程必备能力：

能力	要求
Client 规范	统一超时、重试、熔断、限流、trace_id
身份联邦	网关解析 token，向下游注入用户上下文
聚合编排	多系统串联在 BFF 代码中完成，不由 LLM 多步拼接
降级策略	依赖超时返回明确提示 + 转人工，禁止编造
CS View DTO	多系统状态码映射为统一「客服视图」
契约测试	上游字段变更可自动发现集成破坏

写操作标准跨系统工作流：

Agent 创建售后工单
  → 工单系统审批
  → 审批通过 → 支付系统发起退款
  → 支付回调
  → OMS 更新订单状态

总结/注意事项

智能客服项目约半数工作量在企业集成。LLM 负责理解意图，集成层负责取数、聚合、降级与权限。

---

6. 客服 BFF（Backend for Frontend）

核心概念

BFF 是专为客服场景（智能 Agent、坐席工作台）定制的后端服务层，对外提供少量语义化 API，对内聚合多个业务系统。

常见误解纠正：

误解	正解
BFF = 一个万能接口	BFF 是一层服务，通常包含 5～15 个按场景设计的端点
每次查询打满所有系统	按需调用；列表查询不必拉物流
暴露 OMS/WMS 原始 JSON	返回精简的「客服视图」结构或自然语言友好字段

实现原理/要点

两类端点并存：

类型	示例	适用场景
聚合读接口	GET /cs/orders/{id}/fulfillment（OMS + 物流 + 可选 WMS）	「发货了吗、到哪了」
单一职责接口	GET /cs/orders、POST /cs/knowledge/search、POST /cs/tickets	仅需单系统或明确写流程

标准结构：

Agent / 坐席前端
  ├─ GET  /cs/orders                     → OMS
  ├─ GET  /cs/orders/{id}/fulfillment    → OMS + TMS（聚合）
  ├─ POST /cs/knowledge/search           → 向量库 / CMS
  ├─ POST /cs/tickets                    → 工单系统
  └─ POST /cs/handoff                    → 呼叫中心

设计三原则：

1. 按用户问题设计，不按数据库表或上游微服务粒度设计
2. 高频组合在 BFF 聚合，减少 Agent 推理步数与失败面
3. 写接口窄、语义明确，与读接口分离；写操作不返回无关大块数据

BFF 层标准职责：

• 鉴权与数据归属过滤
• 多系统调用编排
• 字段映射与话术友好化
• 缓存（如物流轨迹 5～15 分钟）
• 熔断降级与错误码统一
• 审计日志

Agent 工具数量建议： 约 8～12 个，每个 tool 对应一个 BFF 语义端点，返回短文本或精简 JSON。

总结/注意事项

BFF 是「一层」不是「一个接口」。聚合发生在特定高频端点上；工具与端点宜一一对应，避免 Agent 面对庞大原始数据。

---

7. Agent 编排框架的定位（以 LangGraph 为例）

核心概念

LangGraph 及同类框架解决 Agent 执行编排，不替代业务领域层。

编排层擅长	业务层必须负责
ReAct 工具循环	状态机
条件分支 / 子图路由	RBAC / ABAC
Checkpoint / 持久化会话	审计、幂等、事务
Human-in-the-loop（interrupt）	防 Prompt Injection 硬边界
多 Agent 协作	资金与合规审批

实现原理/要点

三种主流 Agent 架构模式：

模式	特征	适用
ReAct + 薄工具直连数据源	工具即 SQL/HTTP，约束少	POC / 内部演示
ReAct + 领域服务	工具调用 OrderService.cancel() 等语义 API	生产主流
显式 StateGraph	自定义节点、边、interrupt 审批	金融、复杂售后、强合规

生产推荐模式 B 示意：

Agent Tool: cancel_order(order_id)
    → BFF: POST /cs/orders/{id}/cancel
        → OrderService.cancel(user_ctx, order_id)
            → 权限校验 → 状态机 → OMS / WMS / 支付联动

Human-in-the-loop 适用场景：

• 大额退款审批
• 特殊补偿 / 价保
• 投诉升级
• 身份存疑时的敏感查询

总结/注意事项

编排框架管「怎么跑 Agent」；BFF + 领域服务管「业务能不能做」。二者分层是业界共识，混用会导致安全与维护风险。

---

8. 转人工、知识库与 Copilot

核心概念

转人工、知识库运营、坐席 Copilot 是生产落地中与模型能力并列的三大支柱。

实现原理/要点

转人工标准触发条件：

类型	示例条件
情绪	愤怒、辱骂、连续负面反馈
能力边界	连续 N 次工具失败或无法理解意图
合规风险	起诉、监管投诉、媒体曝光等高风险词
业务规则	超过退款金额阈值、特殊人群、跨境订单
用户显式要求	「转人工」「找经理」

转人工交接标准内容：

• 用户身份与渠道
• 对话摘要（机器生成 + 可追溯）
• 已查订单号 / 工单号
• 机器已执行的工具与结果
• 推荐意图标签

知识库运营标准流程：

法务/运营审定文档 → 版本号 + 生效日期 → 入库（CMS/向量库）
  → 定期巡检过期文档 → 抽检答错率 → 迭代

• RAG 文档必须可追溯来源，禁止模型自由发挥政策内容
• 商品信息与 PIM 不一致时，需定义优先级规则

坐席 Copilot 标准能力（常优先于对外机器人落地）：

• 对话实时摘要
• 政策/商品知识推荐
• 工单字段预填
• 话术建议
• 质检与培训回放

人机同源数据（同一 BFF）可避免「机器查的与坐席后台不一致」。

总结/注意事项

转人工是能力边界的一部分，不是失败退路。Copilot 降本路径清晰、风险低于对外机器人，业界常作为第一阶段交付物。

---

9. 设计检查清单

核心概念

立项与架构评审时应优先明确的五个问题：

1. 哪些数据和操作绝不让 AI 触碰？
2. 转人工的触发条件与交接格式是什么？
3. 机器答错谁负责、如何兜底与追责？
4. 知识库谁维护、更新频率、版本如何管理？
5. ROI 如何衡量？（节省的人工班次 vs. 满意度与投诉变化）

实现原理/要点

架构评审检查项：

维度	检查项
安全	写操作是否隔离？状态机是否代码化？审计是否完备？
集成	是否有 BFF？Agent 工具数是否 ≤15？是否有人机同源？
可用性	依赖超时是否有降级？是否禁止幻觉式填数？
运营	知识库是否有版本与失效机制？质检指标是否定义？
组织	各业务系统接口人、SLA、联调与契约测试是否到位？

标准能力分层一览：

渠道层     ：多端接入、SSO、会话管理
Agent 层   ：意图识别、工具选择、多轮、转人工
BFF 层     ：聚合、鉴权、映射、降级
领域服务层 ：状态机、业务规则、副作用编排
业务系统层 ：OMS、支付、物流、工单、知识库

总结/注意事项

价值定位：扛重复查询、规范政策答复、受理售后流程；复杂纠纷与资金终审交人工与后端工作流。

真正难点：多系统对接、答错成本、知识运营、人机协作、组织协同。

安全底线：写操作不提供 > 状态机 > 权限 > 审计 > Prompt。

架构底线：Agent 薄、BFF 厚、领域服务厚、业务系统各司其职。