如何设计一个 AI 客服系统

AI 客服系统 不是“套一个大模型聊天框”。真正难的地方在于：它要能理解用户问题，查到可靠知识，调用业务系统，知道什么时候不能回答，还要能把复杂问题顺滑地交给人工客服。

对 AI Agent 开发者来说，AI 客服是一个很典型的落地场景：它同时考验 RAG、工具调用、权限控制、状态管理、人工协同和线上评估。做得好，它是服务自动化；做不好，它就是一个会一本正经胡说的聊天窗口。

本文脉络：

• 一、先明确边界：AI 客服不是普通聊天机器人
• 二、核心需求与非功能指标
• 三、容量估算：客服系统的压力在哪里
• 四、整体架构：入口分流、AI 编排、人机协同
• 五、会话主流程：从用户提问到回复或转人工
• 六、知识库与 RAG：客服回答必须有来源
• 七、工具调用：让 AI 能查订单、退款和物流
• 八、人机协同：什么时候必须转人工
• 九、数据模型与存储设计
• 十、评估、观测与持续优化
• 十一、安全、成本与降级策略
• 十二、常见问题

一、先明确边界：AI 客服不是普通聊天机器人

很多人一听“AI 客服”，第一反应是：

用户发消息 → 大模型生成回答 → 返回给用户。

这只能做一个 Demo，做不了客服系统。

客服系统和普通聊天机器人的区别在于：客服有明确的业务后果。用户问“我的订单为什么没到”，AI 不能随便猜；用户说“我要退款”，AI 可能需要查询订单、判断售后规则、创建工单；用户投诉、威胁、涉及金额纠纷时，系统必须能识别风险并转人工。

所以在动手设计之前，边界要先讲清楚：

问题	为什么要问
面向什么业务？	电商、SaaS、银行、航旅的知识和风险完全不同
只做问答，还是允许执行操作？	是否能退款、改地址、发优惠券，会决定权限和审计设计
是否要求多轮对话？	多轮意味着会话状态、上下文压缩和问题追踪
是否接人工客服？	人机协同是客服系统的核心，不是附加功能
是否有现成知识库和工单系统？	决定 RAG、同步、迁移和数据治理复杂度

本文按“电商 / 互联网业务通用 AI 客服”来设计：支持 FAQ 问答、订单查询、物流查询、退款指引、简单工单创建和人工转接；不展开语音呼叫中心、复杂财务赔付和强监管行业合规。

一句话概括：AI 客服的目标不是让模型一直说话，而是用最低成本、最快速度，把用户问题可靠地解决掉。

二、核心需求与非功能指标

功能需求

一个完整 AI 客服系统至少要支持这些能力：

功能	说明
多渠道接入	App、Web、微信、邮件、工单入口统一接入
意图识别	判断用户是在问政策、查订单、投诉、退款还是闲聊
知识问答	基于 FAQ、帮助文档、政策文档回答问题
业务查询	查询订单、物流、退款、优惠券、账户状态
工具调用	在权限允许下创建工单、发起退款申请、修改服务单
多轮对话	记住当前问题、已确认信息、用户上下文
人工转接	低置信度、高风险、强情绪、复杂问题转人工
质量反馈	收集用户满意度、客服纠错、答案引用和失败原因

非功能需求

指标	建议目标
可用性	客服入口 99.99%，AI 能力故障时可降级人工或 FAQ
延迟	普通问答 P95 < 3s；业务查询 P95 < 5s；复杂多步任务可异步
准确性	高风险业务不能靠模型猜，必须基于知识库或业务系统事实
安全性	敏感信息脱敏，工具调用有权限、审计和二次确认
可观测	每轮对话能追踪模型、Prompt、知识引用、工具调用和结果
成本可控	高频简单问题走缓存、小模型或规则，不要全量打大模型

这里要特别强调一点：AI 客服的核心指标不是“模型回答得像不像人”，而是：

• 自助解决率：多少问题不用人工就解决了；
• 转人工率：多少问题需要人工接管；
• 一次解决率：用户是否不用反复追问；
• 错误回答率：AI 是否胡说、误导、越权；
• 平均处理成本：每次会话花了多少模型和人工成本。

客服系统最终看的还是服务效率和服务质量，不是模型表演。

三、容量估算：客服系统的压力在哪里

假设一个中大型电商平台：

指标	假设值
DAU	2000 万
日订单量	300 万
日客服会话量	50 万
高峰小时占比	20% 会话发生在 1 小时内
峰值会话 QPS	约 28 QPS，活动期间放大 10 倍约 280 QPS
平均每个会话轮次	6 轮
峰值消息 QPS	普通约 170 QPS，活动约 1700 QPS

客服系统的 QPS 未必比商品详情、搜索、下单高，但它有几个麻烦点：

• 每条消息都可能触发模型调用，延迟和成本都高；
• 一次回答可能需要向量检索、重排、订单查询、物流查询；
• 用户会连续追问，系统必须维护上下文；
• 高峰期通常伴随业务异常，比如物流延迟、支付失败、活动规则争议；
• 错误回答会直接制造投诉和赔付风险。

因此容量设计要关注三类资源：

资源	压力来源	设计重点
会话与消息写入	用户消息、AI 消息、客服消息持续写入	分库分表、冷热分层、按 conversation_id 查询
检索与模型调用	RAG、Embedding、LLM、重排模型	缓存、模型路由、批处理、限流
业务系统查询	订单、物流、退款、账户等工具调用	超时、熔断、只读优先、结果快照

做 AI 客服时，不要只盯着 QPS。真正容易把系统拖垮的，往往是这些问题：模型慢怎么办、成本爆怎么办、知识库错怎么办、AI 胡说怎么办。

四、整体架构：入口分流、AI 编排、人机协同

整体架构可以拆成七层：

层级	职责
渠道接入层	接入 App、Web、微信、邮件、工单等渠道，统一用户身份和会话 ID
分流与风控层	做限流、黑名单、意图识别、风险识别和人工优先级判断
AI 编排层	决定走 FAQ、RAG、工具调用、澄清追问、转人工还是拒答
知识与检索层	管理 FAQ、帮助文档、政策文档、历史工单和向量索引
业务工具层	封装订单、退款、物流、优惠券、账户等系统能力
会话与工单层	保存会话状态、消息记录、工单流转和人工接管信息
质量观测层	记录 Prompt、模型、知识引用、工具调用、反馈和评估结果

这里最关键的是 AI 编排层。它不是简单把用户问题丢给模型，而是像一个客服主管一样做决策：

1. 这个问题是不是可以直接 FAQ 回答？
2. 是否需要检索知识库？
3. 是否需要查询用户订单或业务状态？
4. 当前用户有没有权限查询这个信息？
5. 模型回答置信度够不够？
6. 是否涉及投诉、赔付、法律、隐私等高风险场景？
7. 要不要转人工，并把上下文整理给人工客服？

这也是 AI 客服和普通 RAG 问答系统的区别：RAG 解决“怎么回答”，客服系统还要解决“该不该回答、能不能操作、什么时候升级”。

五、会话主流程：从用户提问到回复或转人工

一次用户消息的处理流程可以拆成 9 步：

步骤	动作	关键点
1	接收用户消息	绑定用户、渠道、conversation_id
2	加载上下文	拉取最近消息、用户画像、订单摘要
3	意图识别	判断是 FAQ、订单查询、退款、投诉还是闲聊
4	风险判断	识别敏感信息、赔付、辱骂、威胁、法律风险
5	检索知识	从 FAQ、政策、文档、历史工单中找证据
6	调用工具	查询订单、物流、退款状态等业务事实
7	生成候选回答	基于证据和业务结果生成回复
8	答案校验	检查事实来源、权限、敏感信息和置信度
9	回复或转人工	通过则回复；不通过则澄清、拒答或转人工

这里有一个工程上很实用的原则：

用户看到的是一句自然语言回复，系统内部应该是一条可追踪的决策链。

比如用户问：

我的订单怎么还没到？

系统不能直接让模型猜。合理流程是：

1. 从会话或用户上下文里找到订单 ID；找不到就追问用户选择订单。
2. 调用订单服务查询订单状态。
3. 调用物流服务查询轨迹和预计送达时间。
4. 检索物流延迟政策和赔付规则。
5. 生成回答，并引用“订单状态 + 物流轨迹 + 政策规则”。
6. 如果物流异常超过阈值，主动创建工单或转人工。

这样回答才有事实依据。

六、知识库与 RAG：客服回答必须有来源

AI 客服回答业务问题时，不能只依赖模型参数里的“常识”。客服知识每天都在变：活动规则、退款政策、配送范围、会员权益、故障公告，任何一项过期都会导致错误回答。

所以知识库设计是 AI 客服的第一块地基。

知识来源

来源	示例	处理方式
FAQ	常见问题、售后规则、活动说明	结构化问答，优先命中
帮助文档	产品文档、用户指南、政策说明	分块、向量化、版本管理
历史工单	人工客服处理过的问题	脱敏后沉淀为案例或 FAQ
业务公告	物流异常、系统故障、活动变更	高优先级、短有效期
运营配置	退货时效、赔付规则、禁用话术	强规则，不建议只放向量库

RAG 检索链路

一个比较稳的客服 RAG 流程通常是：

1. Query Rewrite：把用户口语化问题改写成适合检索的问题。
2. 意图过滤：根据意图选择知识集合，例如物流、退款、活动、账户。
3. 多路召回：关键词检索 + 向量检索 + FAQ 精确匹配。
4. Rerank：用重排模型挑出最相关的知识片段。
5. 版本过滤：过滤过期文档、无效政策、低权限内容。
6. 答案生成：要求模型只基于检索结果回答。
7. 引用记录：保存回答引用了哪些文档、版本和片段。

在客服场景里，我更建议把 FAQ 精确匹配放在 RAG 之前。高频简单问题，比如“怎么修改手机号”“退货多久到账”，不一定要走完整大模型链路。FAQ 命中率足够高时，直接返回标准答案更快、更便宜，也更稳定。

知识库更新

知识库不是一次性导入就完事。至少要支持：

能力	说明
版本管理	每条知识有版本、生效时间、失效时间
灰度发布	新政策先小流量验证，避免全量错误
审核流程	运营修改知识后需要审核，重要规则不能随手改
回滚能力	发现错误知识后能快速回滚到旧版本
反馈闭环	人工客服纠错后能进入待审核知识池

这里有个常见坑：只更新了原文档，没有同步更新向量索引。结果用户看到的是旧答案。生产环境要把文档、分块、Embedding、索引版本绑在一起，索引失败不能悄悄吞掉。

七、工具调用：让 AI 能查订单、退款和物流

只会回答 FAQ 的 AI 客服价值有限。真正能省人工的，是它能处理一部分业务查询和轻量操作。

但工具调用一定要谨慎。客服工具不是给模型“自由发挥”的玩具，而是一组有权限、有输入校验、有审计的业务 API。

工具分级

工具类型	示例	风险	策略
只读查询	查订单、查物流、查退款状态	低	可由 AI 自动调用，但要鉴权和脱敏
低风险写操作	创建咨询工单、发送说明短信	中	可自动执行，但要记录审计
高风险写操作	发放优惠券、发起退款、修改地址	高	需要用户确认或人工审批
禁止操作	修改支付金额、绕过售后规则	极高	不暴露给 AI

一个工具定义至少要包含：

字段	说明
name	工具名称，例如 get_order_status
description	什么时候可以调用
input_schema	参数结构、类型和必填字段
permission	需要的用户权限、客服权限或系统权限
timeout	超时时间
retry_policy	是否可重试，重试几次
audit_level	是否记录完整参数、结果和操作者

示例工具定义可以长这样：

{
  "name": "get_order_status",
  "description": "查询当前登录用户的订单状态、支付状态和发货状态",
  "input_schema": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string",
        "description": "订单 ID，只能查询当前用户自己的订单"
      }
    },
    "required": ["order_id"]
  },
  "permission": "user_own_order_read",
  "timeout_ms": 800,
  "audit_level": "standard"
}

工具调用还有两个容易被忽略的点。

第一，工具结果要结构化。不要让业务系统返回一大段自然语言给模型，否则后续校验很难做。订单状态、金额、时间、物流节点都应该是结构化字段。

第二，写操作要有二次确认。比如用户说“帮我退款”，AI 可以先判断是否满足退款条件，然后回复：

这笔订单符合退款申请条件，预计 1～3 个工作日原路退回。是否确认提交退款申请？

用户确认后再调用退款申请工具。这个确认动作要落库，不能只存在模型上下文里。

八、人机协同：什么时候必须转人工

AI 客服做得好，不是把人工客服彻底干掉，而是把人工客服从重复问题里解放出来，把复杂问题交给更合适的人。

必须转人工的场景包括：

场景	原因
低置信度	检索不到可靠知识，或模型判断不确定
高金额纠纷	涉及赔付、退款、扣费争议
强情绪投诉	用户愤怒、威胁曝光、要求主管介入
法律与合规	发票、合同、隐私、监管投诉
多次未解决	同一会话连续多轮没有解决
工具调用失败	订单、物流、退款系统异常，AI 无法确认事实

转人工不是简单丢一句“请稍等”。系统要把上下文整理好：

信息	给人工客服的价值
用户问题摘要	客服不用重新读完整聊天记录
已识别意图	快速判断问题类型
订单/物流/退款查询结果	避免重复查询
AI 已回答内容	知道用户已经听过什么
风险标签	投诉、高金额、VIP、超 SLA 等
推荐处理动作	给人工客服一个初始建议

好的转人工体验应该是：用户不用重复描述问题，人工客服接手时也不用从零开始查。

九、数据模型与存储设计

核心数据模型可以围绕 conversation_id 展开。

会话表 conversations

字段	说明
conversation_id	会话 ID
user_id	用户 ID
channel	来源渠道
status	OPEN、AI_HANDLING、HUMAN_HANDLING、RESOLVED、CLOSED
intent	当前识别意图
risk_level	风险等级
assigned_agent_id	接管人工客服
created_at / updated_at	创建和更新时间

消息表 messages

字段	说明
message_id	消息 ID
conversation_id	所属会话
role	user、assistant、human_agent、system
content	消息内容
model_id	如果是 AI 回复，记录模型版本
prompt_version	Prompt 版本
latency_ms	生成耗时
created_at	创建时间

工具调用日志 tool_call_logs

字段	说明
call_id	调用 ID
conversation_id	所属会话
message_id	触发调用的消息
tool_name	工具名称
params_hash	参数摘要，敏感参数不要明文存
status	SUCCESS、FAILED、TIMEOUT、DENIED
result_snapshot	脱敏后的结果快照
created_at	调用时间

知识引用表 knowledge_refs

字段	说明
ref_id	引用 ID
message_id	哪条 AI 回复引用了这段知识
doc_id	文档 ID
chunk_id	分块 ID
doc_version	文档版本
score	检索或重排分数
citation_text	引用摘要

为什么要单独记录知识引用？因为客服场景出了错，要能回答两个问题：

1. AI 为什么这么说？
2. 当时它看到的是哪个版本的知识？

没有这两个信息，排查线上问题会非常痛苦。

分库分表与冷热分层

会话和消息表增长很快，可以这样设计：

数据	存储策略
最近 30 天会话	在线数据库，支持客服工作台快速查询
历史消息	冷存储或归档库，按合规要求保留
向量索引	独立向量库或搜索引擎向量能力
工具调用日志	在线保留摘要，详细日志进审计存储
评估样本	单独数据集，供离线评测和回归测试

查询路径通常是按 conversation_id 拉消息，所以消息表可以按时间 + 会话 ID 分片。不要设计成每次都按 user_id 扫全量历史消息，那会把客服工作台拖慢。

十、评估、观测与持续优化

AI 客服上线后，不能只看“能不能回复”。要把它当成一个持续迭代的生产系统。

在线指标

指标	含义
AI 自助解决率	不转人工且用户问题解决的比例
转人工率	AI 无法处理或主动升级的比例
用户满意度	点赞、点踩、评分、投诉
首响时间	用户发起后多久收到第一次有效响应
平均处理时长	从会话开始到解决的时间
工具调用成功率	业务工具是否稳定
RAG 命中率	检索是否能找到有效知识
幻觉率	回答没有事实依据或与知识冲突的比例
单会话成本	模型、检索、人工综合成本

离线评估

离线评估至少要有一套回归集：

样本类型	作用
高频 FAQ	确保常见问题不会退化
历史投诉	检查高风险转人工策略
政策边界问题	测试退款、赔付、售后规则
工具调用问题	检查参数抽取和权限判断
恶意输入	测试提示注入、越权查询、敏感信息泄露

每次改 Prompt、换模型、更新知识库、调整检索策略，都应该跑离线回归。别在线上靠用户帮你测试。

失败样本闭环

AI 客服最有价值的数据来自失败：

1. 用户点踩。
2. 人工客服改写了 AI 的回答。
3. AI 多轮没解决后转人工。
4. 用户重复问同一个问题。
5. 工具调用失败或超时。

这些样本应该进入“待分析池”，由运营、客服质检和算法/工程团队共同处理：

• 是知识缺失，就补知识；
• 是知识过期，就修版本；
• 是检索失败，就调召回和重排；
• 是 Prompt 问题，就改策略；
• 是业务工具缺能力，就补 API；
• 是本来就高风险，就完善转人工规则。

十一、安全、成本与降级策略

安全边界

AI 客服最怕三类事故：

风险	例子	防护
胡说业务规则	编造退款政策、赔付承诺	只基于知识库和工具结果回答，答案校验
越权查询	查询别人的订单、手机号、地址	工具层强鉴权，不信任模型判断
越权操作	自动退款、乱发优惠券	写操作二次确认，高风险人工审批

权限判断一定要放在工具服务端，而不是只写在 Prompt 里。Prompt 可以提醒模型“不要越权”，但真正的安全边界必须由代码控制。

成本控制

模型成本要从第一天就设计进去：

手段	说明
FAQ 精确命中	高频标准问题不走大模型
语义缓存	相似问题复用答案，但要绑定知识版本
模型路由	简单分类用小模型，复杂推理用大模型
上下文压缩	长会话只保留摘要和关键事实
检索裁剪	控制 Top-K 和上下文长度
流式输出	改善体感延迟，但不要掩盖后端慢问题

这里有个判断：如果一个问题可以用规则、FAQ、数据库查询稳定解决，就不要强行交给大模型。大模型应该用在“语言理解、复杂归纳、自然表达”上，而不是替代所有确定性逻辑。

降级策略

生产系统必须假设模型、向量库、业务工具都会失败。

故障	降级方式
LLM 超时	返回标准话术，转人工或让用户稍后查看
向量库不可用	退回 FAQ / 关键词搜索
订单服务超时	告知暂时无法查询，创建工单或稍后重试
工具调用失败	不编造结果，明确说明无法确认
人工坐席爆满	排队、预约回拨、按风险优先级分配

降级话术也要设计好。不要让 AI 说“系统异常，请稍后再试”就结束。客服场景里更好的处理是：

我现在暂时查不到这笔订单的最新物流信息。已经帮你记录这个问题，你也可以稍后在订单详情页刷新查看；如果 10 分钟后仍然没有更新，我会建议转人工继续处理。

这比冷冰冰的错误码更像客服。

十二、常见问题

问题	回答要点
AI 客服和普通 RAG 问答有什么区别？	RAG 主要解决知识问答；AI 客服还要处理用户身份、业务工具、人工转接、工单、权限、审计和服务质量指标。
为什么不能直接让大模型回答客服问题？	客服答案有业务后果。退款、物流、赔付、账户问题必须基于知识库和业务系统事实，不能靠模型猜。
如何降低幻觉？	限定回答来源、记录知识引用、做答案校验、低置信度转人工，高风险场景禁止自由生成。
什么时候转人工？	低置信度、高金额纠纷、强情绪投诉、法律合规、多轮未解决、工具失败或系统判断风险高时。
工具调用怎么保证安全？	工具服务端强鉴权，参数校验，敏感信息脱敏，写操作二次确认，高风险操作人工审批，全链路审计。
如何控制模型成本？	FAQ 优先、缓存、小模型分类、模型路由、上下文压缩、限制检索片段数量，把确定性逻辑留给规则和业务系统。
如何评估 AI 客服效果？	看自助解决率、转人工率、满意度、首响时间、平均处理时长、幻觉率、工具成功率和单会话成本。
如果知识库过期怎么办？	知识要有版本、生效时间、审核和回滚；回答记录引用版本；索引更新失败要报警，不能静默使用旧知识。

最后可以用一句话概括这套设计：

AI 客服的本质不是“让模型替客服聊天”，而是把知识、工具、权限、人工和评估串成一条可靠的服务链路。模型只是其中一个环节，不是整个系统。