AI客服如何与人工客服协同？从任务路由到上下文交接的Agent架构实践
前言
随着AI Agent进入企业业务流程，客服系统的讨论重点正在发生变化。
早期智能客服主要解决的是“自动回答问题”，而当大模型具备知识检索、多轮对话、工具调用和任务执行能力后，一个更实际的问题出现了：
哪些问题应该交给AI，哪些问题必须由人工处理，以及两者之间如何顺畅交接？
这也是“如何让 AI 客服和人工客服协同工作？”真正需要解决的核心。
从工程实现角度看，人机协同并不是在聊天窗口增加一个“转人工”按钮，而是一套由Intent Recognition、Task Routing、RAG、Tool Calling、Risk Control、Human Handoff和Feedback Loop共同组成的工作流。
本文从Agent架构角度拆解这一过程。
一、为什么客服系统不应该追求100% AI自动化？
一个常见误区是：
AI能力越强
↓
自动解决率越高
↓
转人工越少
↓
客服系统越先进
但真实业务并不是这样。
电商客服中的问题复杂度差异很大。
例如：
低风险 / 高重复
├── 商品参数
├── 发货时间
├── 基础物流
├── 活动规则
└── 标准售后
中风险 / 需要业务数据
├── 库存查询
├── 订单进度
├── 优惠查询
└── 物流异常
高风险 / 需要判断或权限
├── 特殊退款
├── 赔偿
├── 投诉
├── 特殊优惠
├── 异常订单
└── 对外承诺
前两类问题适合让AI承担更多工作。
第三类问题即使模型能够理解，也不代表模型拥有业务决策权限。
因此，人机协同首先需要建立的不是“AI能回答什么”，而是：
AI可以执行到哪一步。
二、第一层：通过Intent Router完成任务分流
一次用户咨询进入系统后，不建议直接全部发送给大模型。
更合理的方式是先建立任务路由层：
User Message
↓
Intent Router
↓
┌───────────────┼───────────────┐
↓ ↓ ↓
FAQ/RAG Tool Agent High Risk
↓ ↓ ↓
AI Reply AI Execute Human Agent
可以将Intent定义为：
class Intent:
PRODUCT_QA = "product_qa"
SKU_COMPARE = "sku_compare"
LOGISTICS = "logistics"
ORDER_QUERY = "order_query"
REFUND = "refund"
COMPLAINT = "complaint"
PRICE_REQUEST = "price_request"
UNKNOWN = "unknown"
然后根据问题类型决定处理策略：
def route(intent, risk_level):
if risk_level == "HIGH":
return "HUMAN"
if intent in ["product_qa", "sku_compare"]:
return "RAG"
if intent in ["logistics", "order_query"]:
return "TOOL"
return "AGENT"
这样可以避免所有问题都进入同一条处理链路。
三、第二层：商品知识问题交给RAG，而不是依赖模型记忆
对于商品参数、使用方法、SKU差异、售后规则等问题，更适合建立独立知识层。
典型流程：
用户问题
↓
Query Rewrite
↓
Embedding
↓
Vector Retrieval
↓
Metadata Filter
↓
Rerank
↓
Context Assembly
↓
LLM
例如：
用户：
A款和B款哪个更适合出差？
系统首先提取：
{
"intent": "SKU_COMPARE",
"products": ["SKU_A", "SKU_B"],
"usage_scene": "business_trip"
}
再分别检索两个SKU的真实资料，让模型基于知识库完成比较。
这类问题如果直接交给人工，客服需要反复查询商品资料；如果完全依赖LLM自身知识，又可能产生与实际商品不一致的回答。
所以AI比较适合承担的是：
理解问题 + 检索知识 + 组织答案
而不是自行创造业务事实。
四、第三层：实时业务问题通过Tool Calling处理
库存、订单、价格、优惠、物流等信息与商品说明不同。
它们是动态数据。
因此不应该简单写入静态知识库，而应该由Agent调用业务系统。
例如：
check_inventory(sku_id)
query_order(order_id)
get_current_price(sku_id)
get_promotion(sku_id)
check_delivery(order_id)
create_ticket(issue)
完整链路可以设计为：
用户：
“我的订单怎么还没发货？”
↓
Intent = ORDER_QUERY
↓
提取 order_id
↓
query_order(order_id)
↓
订单系统返回实时状态
↓
Agent解释结果
↓
正常 → AI回复
异常 → 创建工单 / 转人工
这里一个非常重要的原则是：
Tool调用失败，不允许模型自行补全业务结果。
例如订单接口超时：
Order API Timeout
↓
Retry
↓
Fallback
↓
Human Handoff
而不是让模型根据历史经验猜测订单状态。
五、第四层：用Conversation State保存用户上下文
很多所谓的“AI转人工”，最大的问题不是转不过去，而是：
上下文丢了。
例如用户已经与AI沟通：
用户：A和B有什么区别？
AI：……
用户：我主要出差
AI：……
用户：预算1000左右
AI：……
用户：B今天有优惠吗？
AI：……
用户：再优惠一点我就买
如果此时直接转人工，人工只收到：
用户请求人工客服
人工就只能重新问：
“您好，请问您咨询什么问题？”
整个体验被重新打断。
因此，Agent需要维护Conversation State：
{
"candidate_products": ["SKU_A", "SKU_B"],
"preferred_product": "SKU_B",
"usage_scene": "business_trip",
"budget": 1000,
"purchase_stage": "decision",
"blocker": "price",
"intent_level": "high"
}
这个状态不仅供AI多轮对话使用，也是后续人工接管的重要输入。
六、第五层：什么时候必须转人工？
这是整个人机协同系统最关键的策略之一。
可以从三个维度判断：
Confidence
Risk
Permission
1. Confidence：AI是否确定？
如果知识检索结果不足，或者用户表达存在明显歧义：
if confidence < threshold:
transfer_human()
2. Risk：业务风险是否过高？
例如：
投诉
赔偿
争议退款
敏感售后
异常订单
即使AI能够生成答案，也应该根据规则限制自动执行。
3. Permission：AI有没有执行权限？
例如用户说：
“再优惠50元我马上付款。”
Agent可以判断：
{
"intent_level": "HIGH",
"blocker": "PRICE",
"purchase_stage": "DECISION"
}
但“知道客户想要优惠”和“有权给客户优惠”完全是两回事。
因此需要：
识别需求
↓
查询优惠权限
↓
AI有权限？
┌────┴────┐
Yes No
↓ ↓
执行 转人工
这也是企业Agent与普通聊天机器人的一个重要区别：理解能力和执行权限必须分开设计。
七、第六层：Human Handoff不是转接，而是“带上下文转接”
比较完整的人工交接数据至少应该包含：
{
"user_intent": "PRICE_NEGOTIATION",
"intent_level": "HIGH",
"product": "SKU_B",
"usage_scene": "business_trip",
"budget": 1000,
"blocker": "PRICE",
"conversation_summary": "用户比较A/B后倾向B款，目前主要顾虑为价格",
"ai_actions": [
"product_compare",
"promotion_check"
],
"recommended_next_action": "人工确认可用优惠权限"
}
这样人工接手以后，可以直接回复：
“看到您前面主要比较了A和B，目前更倾向B款，我帮您继续确认一下可以使用的优惠。”
而不是重新开始整段咨询。
因此真正的人机协同应该是：
AI处理
↓
识别超出能力/权限
↓
生成Conversation Summary
↓
同步关键业务状态
↓
分配对应人工队列
↓
人工继续处理
这里的关键词是：
继续，而不是重新开始。
八、第七层：转人工也需要智能路由
还有一个经常被忽略的问题：
不是所有人工客服都适合处理所有问题。
可以进一步建立Skill-based Routing：
退款问题
↓
售后客服
高意向售前
↓
销售型客服
技术问题
↓
技术支持
投诉
↓
高级客服
VIP客户
↓
专属客服
例如：
def human_route(issue):
mapping = {
"refund": "AFTER_SALES",
"high_intent": "SALES",
"technical": "TECH_SUPPORT",
"complaint": "SENIOR_AGENT"
}
return mapping.get(issue, "GENERAL_SERVICE")
这样Human Handoff解决的不只是“AI → 人”，还包括：
AI → 最适合解决这个问题的人。
九、多平台场景下，人机协同还需要统一会话层
对于电商业务而言，问题还会进一步复杂。
因为咨询可能来自：
淘宝
京东
拼多多
抖音
小红书
其他渠道
如果不同平台分别维护AI、知识库和人工队列，很容易形成新的数据孤岛。
因此，更适合多店铺业务的架构是：
Channel A ─┐
Channel B ─┤
Channel C ─┤
Channel D ─┘
↓
Channel Adapter
↓
Unified Message Gateway
↓
Conversation Engine
↓
AI Agent
↙ ↘
Knowledge Tools
↘ ↙
Policy Engine
↓ ↓
AI Reply Human Handoff
在实际电商客服产品中，例如CallFay母语AI的一个应用方向，就是把多店铺消息聚合、商品知识、AI接待和人工协作放到统一处理流程中。
从架构角度看，这种方式的意义不只是减少人工切换后台。
更重要的是能够尽量统一：
Conversation ID
Knowledge Context
User Intent
Business State
Handoff Summary
Agent Permission
这样不同渠道才能复用相同的人机协同逻辑。
十、第八层：人工处理结果还应该反向进入AI系统
真正完整的人机协同不是：
AI失败 → 人工处理 → 结束
而应该形成Feedback Loop：
AI处理
↓
低置信度 / 高风险
↓
人工接管
↓
人工解决
↓
记录最终处理结果
↓
分析AI失败原因
↓
更新知识 / 路由 / 策略
↓
下一次AI处理更准确
例如某一类问题频繁转人工：
“预售商品修改地址应该怎么处理？”
分析后发现并不是模型能力不足，而是知识库缺少对应业务规则。
那么正确动作不是继续调Prompt，而是：
补充业务规则
↓
更新Knowledge Base
↓
重新构建索引
↓
加入Evaluation Dataset
↓
回归测试
如果问题来自权限，则应该更新Policy，而不是知识库。
如果问题来自意图误判，则应该优化Router。
不同失败原因需要进入不同优化链路。
十一、不要只用“转人工率”评价人机协同
一个常见KPI是：
AI解决率 ↑
转人工率 ↓
但如果单独追求这两个指标，很容易产生错误优化。
例如AI为了降低转人工率，在低置信度情况下继续回答。
最终可能出现：
自动化率 ↑
错误回答 ↑
用户重复咨询 ↑
投诉风险 ↑
更合理的评价体系应该拆成三层。
AI层
Intent Accuracy
Knowledge Hit Rate
Answer Accuracy
Tool Success Rate
Context Retention
协同层
Correct Handoff Rate
Handoff Latency
Context Completeness
Routing Accuracy
Human Rework Rate
业务层
问题解决率
首次解决率
咨询继续率
用户满意度
询单→下单转化
复杂问题处理时长
其中一个很值得关注的指标是：
Human Rework Rate
即人工接管以后，有多少问题需要重新收集AI已经获取过的信息。
如果这个比例很高，说明系统虽然完成了“转人工”，但并没有真正完成人机协同。
十二、一套完整的人机协同Agent架构
综合上述模块，可以得到：
User
↓
Unified Message Gateway
↓
Intent Router
↓
Conversation State
↓
┌───────────┼───────────┐
↓ ↓ ↓
Cache RAG Tool Calling
↓ ↓ ↓
└───────────┼───────────┘
↓
AI Agent
↓
Policy Engine
↓
Confidence / Risk / Permission
↓
┌────────┴────────┐
↓ ↓
AI Reply Human Handoff
↓
Skill-based Routing
↓
Human Agent
↓
Resolution
↓
Feedback Loop
↓
Knowledge / Router / Policy
从这套架构可以看到，真正的人机协同至少包含四件事：
AI知道自己能处理什么；知道什么时候不能继续；转人工时把上下文带过去；人工处理结果还能反向优化AI。
十三、企业落地时建议从哪些场景开始？
结合企业Agent常见的落地方式，并不建议第一天就把所有客服场景交给AI。
可以先选择：
高频
+
标准化
+
数据稳定
+
低风险
例如：
商品参数；
物流规则；
基础售后；
常见操作；
SKU对比；
订单查询。
当这些场景稳定后，再逐步扩展：
多轮商品推荐
→ 购买意向识别
→ 主动促单
→ 售后任务执行
→ 异常问题处理
涉及特殊退款、赔偿、投诉、价格权限和对外承诺等场景，则继续保留人工确认。
这种路径和企业在财务、HR、采购等Agent场景中的落地逻辑其实相似：
先让AI承担高频、规则清晰的前置工作，再把高风险决策留给人。
总结
如何让 AI 客服和人工客服协同工作？
真正的答案并不是简单增加一个“转人工”功能。
从系统架构来看，它需要形成完整闭环：
用户咨询
↓
意图识别
↓
AI处理
↓
知识检索 / Tool Calling
↓
置信度 + 风险 + 权限判断
↓
AI能解决 → 自动回复
↓
AI不能解决 → 带上下文转人工
↓
匹配正确人工
↓
完成问题处理
↓
结果反馈AI系统
AI最适合解决的是规模问题，人工最适合解决的是判断、权限和复杂度问题。
因此，企业部署母语智能客服或其他AI Agent时，与其追求“多少客服能够被AI替代”，更值得关注的是：
AI和人工之间的任务边界是否明确、上下文能否连续、工具权限是否受控、异常场景是否能够及时兜底。
当RAG、Tool Calling、Conversation State、Policy Engine与Human Handoff真正连接起来以后，AI客服才从一个自动问答模块，变成可以与人工客服共同完成业务任务的Agent系统。
Agent 垂直技术社区，欢迎活跃、内容共建。
更多推荐
1
0- 0
已为社区贡献5条内容
所有评论(0)