前言
随着 AI 大模型能力快速落地，越来越多的企业开始把"智能客服"从关键词匹配升级为真正的意图理解。然而在微信生态中部署 AI 客服并非只是接一个大模型 API 那么简单——如何准确识别用户意图、何时触发转人工、转接后如何保持上下文不断档，这些工程细节往往才是项目成败的关键。
本文从意图识别的技术选型出发，结合微信消息接入的实际链路，给出一套完整的智能客服意图分层方案，并详细讲解转人工的触发逻辑和会话移交实现。
一、意图识别的核心问题
1.1 意图识别与关键词匹配的本质区别
传统客服机器人多依赖关键词触发，"退款"触发退款流程，"投诉"触发投诉流程。这种方式在词汇覆盖不全时会大量漏识，而同一个词在不同语境下意图完全不同（"我不想退款"与"我要退款"触发的应该相反）。
意图识别（Intent Recognition）的目标是理解用户想做什么，而不是用户说了什么词。它通常包含三个维度：
| 维度 | 含义 | 示例 |
|---|---|---|
| 意图类别（Intent） | 用户行为目标 | 查订单、申请退款、咨询价格 |
| 实体（Entity） | 意图中的关键槽位 | 订单号、商品名称、日期 |
| 情绪（Sentiment） | 用户当前情绪倾向 | 正向、负向、中性 |
三者结合才能判断"用户要干什么，情绪如何，涉及哪个具体对象"。
注意事项：意图识别依赖上下文，单轮识别准确率远不如多轮。在工程实现时，建议将最近 3 轮对话历史一并传入大模型，而不是只看当前这条消息。这样对"然后呢""就是这个"之类的指代性表达，模型能结合前文正确理解。
1.2 意图分层模型
工程实践中建议把意图按置信度分三层处理，而非简单二分"能回答/不能回答"：
用户输入
│
▼
┌─────────────────────────────────────┐
│ Layer 1：意图明确 + 置信度 ≥ 0.85 │ → 直接自动回复
└─────────────────────────────────────┘
│ 不满足
▼
┌─────────────────────────────────────┐
│ Layer 2：意图模糊 + 0.50 ≤ 置信度 │ → 追问澄清
│ < 0.85 │
└─────────────────────────────────────┘
│ 不满足
▼
┌─────────────────────────────────────┐
│ Layer 3：无法识别 / 情绪激烈 │ → 转人工
└─────────────────────────────────────┘这个分层模型有两个好处：一是避免机器在低置信区间瞎猜导致用户更不满；二是给人工坐席提供明确的接入时机。
置信度阈值（0.85 和 0.50）可以根据业务场景调整。对于客单价较高、投诉成本大的业务，可以把高层阈值调高到 0.90，宁可多追问、多转人工，也要减少误回复。
二、技术选型与架构设计
2.1 意图识别方案对比
目前主流的意图识别技术路线有三条，各有适用场景：
| 方案 | 原理 | 适用场景 | 缺点 |
|---|---|---|---|
| 规则 + 关键词 | 字符串匹配 / 正则 | 意图简单、高频场景 | 泛化差、维护成本高 |
| 传统 NLU 模型（BERT 微调） | 有监督分类 | 意图类别固定、有标注数据 | 需要标注、冷启动慢 |
| 大模型（LLM）Zero-shot | Prompt 引导推理 | 意图多样、快速上线 | 延迟较高、成本需控制 |
中小型微信客服项目推荐大模型 Zero-shot + 规则兜底的混合方案：用大模型处理自然语言理解，用规则捕捉高频确定性场景（比如用户直接输入"转人工"）。
实际落地时，这三条路线并不互斥。常见的做法是先用规则拦截最高频的 5～10 种场景，剩余流量交给大模型处理。随着业务积累，再逐步引入微调模型替换大模型，在成本和效果之间找到平衡点。
2.2 整体架构
微信用户
│ 发消息
▼
┌──────────────────────────────────────────────────────────────┐
│ 消息接入层（Webhook） │
│ 微信账号 → REST API → 回调服务（setCallback） │
└──────────────────┬───────────────────────────────────────────┘
│ 标准化 Message 对象
▼
┌──────────────────────────────────────────────────────────────┐
│ 意图识别引擎 │
│ 规则预处理 → LLM Prompt → 意图+置信度+情绪 │
└──────────────────┬───────────────────────────────────────────┘
│
┌─────────┴─────────┐
│ │
意图明确 意图模糊 / 负面情绪
│ │
自动回复 澄清追问 / 转人工
│ │
▼ ┌──────────▼──────────┐
发送消息 │ 人工坐席系统 │
（postText） │ + 历史上下文移交 │
└─────────────────────┘三、意图识别引擎实现
3.1 消息接收
微信账号的消息通过回调机制推送到业务服务器，接收到的报文结构示例如下（字段以官方文档为准）：
python# 示例：Flask 回调接收
from flask import Flask, request, jsonify
app = Flask(__name__)
@app.route("/wechat/callback", methods=["POST"])
def callback():
data = request.json
# data 结构示例（字段以官方文档为准）：
# {
# "appId": "xxx",
# "fromWxid": "wxid_xxx",
# "toWxid": "xxx",
# "type": 1, # 1=文本消息
# "content": "我要退款",
# "msgId": "xxxxx",
# "createTime": 1718000000
# }
if data.get("type") == 1: # 仅处理文本消息
handle_text_message(data)
return jsonify({"code": 200})
代码为示例，具体接口字段以官方文档为准。
实操细节：回调服务必须在 5 秒内响应，否则微信侧会判定超时并重试。因此处理逻辑应全部异步化——收到回调立即返回 200，将消息推入消息队列（如 Redis List 或 RabbitMQ），由后台 Worker 异步拉取并执行意图识别和回复。直接在回调函数里同步调用大模型 API 是常见的踩坑点。
3.2 大模型意图识别 Prompt 设计
意图识别 Prompt 的关键是返回结构化 JSON，便于后续逻辑判断：
pythonimport json
INTENT_PROMPT_TEMPLATE = """
你是一个客服意图分析助手。请分析以下用户消息，输出 JSON 格式结果。
用户消息：{user_input}
历史对话（最近3轮）：
{history}
请输出：
{{
"intent": "意图类别（查订单/申请退款/咨询价格/投诉/闲聊/其他）",
"confidence": 0.0到1.0的浮点数,
"entities": {{"订单号": "", "商品": ""}},
"sentiment": "正向/负向/中性",
"need_human": true或false,
"reason": "简要说明"
}}
只输出 JSON，不要其它内容。
"""
def recognize_intent(user_input: str, history: list) -> dict:
history_text = "\n".join(
[f"用户：{h['user']}\n客服：{h['bot']}" for h in history[-3:]]
)
prompt = INTENT_PROMPT_TEMPLATE.format(
user_input=user_input,
history=history_text
)
# 调用大模型 API（此处以伪代码示意，替换为实际 SDK 调用）
raw = call_llm(prompt)
try:
return json.loads(raw)
except json.JSONDecodeError:
return {"intent": "其他", "confidence": 0.0, "need_human": True}
3.3 规则预处理（关键词快速路由）
在调用大模型之前先做规则预处理，命中则直接跳过 LLM，降低延迟和成本：
pythonRULE_PATTERNS = {
"转人工": {"intent": "转人工", "confidence": 1.0, "need_human": True},
"人工客服": {"intent": "转人工", "confidence": 1.0, "need_human": True},
"投诉": {"intent": "投诉", "confidence": 0.9, "need_human": True},
"骗子": {"intent": "投诉", "confidence": 1.0, "need_human": True},
}
def rule_preprocess(text: str) -> dict | None:
for keyword, result in RULE_PATTERNS.items():
if keyword in text:
return result
return None
注意事项：规则关键词要定期维护。实际运营中会出现用户输入"快递被人骗走了"被误判为投诉的情况，此时需要细化规则或将该场景挪交大模型处理。建议为每条规则保留命中日志，定期统计误命中率，超过阈值时人工复审。
四、转人工触发逻辑
4.1 触发条件矩阵
转人工不是简单的"AI 答不了就转"，需要综合多个信号判断：
| 触发条件 | 判断方式 | 优先级 |
|---|---|---|
| 用户主动请求 | 规则匹配"转人工/人工客服" | 最高 |
| 情绪负向且内容敏感 | 情绪=负向 + 意图=投诉/退款 | 高 |
| 意图置信度过低 | confidence < 0.50 | 中 |
| 连续追问无效 | 澄清追问超过2次仍无法识别 | 中 |
| 问题超出知识库 | LLM 返回 need_human=true | 低 |
| 等待时间过长 | 用户在同一问题等待超过90秒 | 低 |
4.2 转人工决策函数
pythondef should_transfer_human(intent_result: dict, session: dict) -> bool:
"""
返回 True 表示需要转人工
session 示例字段：
clarify_count: 追问次数
wait_seconds: 本轮等待秒数
"""
# 用户主动请求
if intent_result.get("intent") == "转人工":
return True
# LLM 直接判断需人工
if intent_result.get("need_human"):
return True
# 置信度过低
if intent_result.get("confidence", 1.0) < 0.50:
return True
# 情绪负向 + 投诉/退款
if (intent_result.get("sentiment") == "负向"
and intent_result.get("intent") in ("投诉", "申请退款")):
return True
# 连续追问超限
if session.get("clarify_count", 0) >= 2:
return True
return False
4.3 上下文移交
转人工时最关键的是把对话历史完整传给坐席，避免用户重复描述：
pythondef build_handover_context(session: dict) -> str:
"""
构建移交给人工坐席的上下文摘要
"""
lines = ["=== AI 客服会话摘要 ==="]
lines.append(f"用户 wxid：{session['from_wxid']}")
lines.append(f"最终识别意图：{session.get('last_intent', '未知')}")
lines.append(f"用户情绪：{session.get('last_sentiment', '未知')}")
lines.append("\n近期对话记录：")
for h in session.get("history", [])[-5:]:
lines.append(f" 用户：{h['user']}")
lines.append(f" 客服：{h['bot']}")
lines.append("======================")
return "\n".join(lines)
实操细节：上下文移交不只是文字记录，还应包含当前识别到的意图类别和情绪状态，帮助坐席在接手的第一句话就能定位问题，而不是重新问"您好，请问有什么可以帮您？"。如果坐席系统支持，可以将这段摘要作为"内部备注"展示在坐席界面，对用户不可见，只供坐席参考。
五、消息发送与会话管理
5.1 自动回复实现
意图识别完成后，自动回复通过 REST API 的发消息接口发出。WechatApi 提供扫码登录、消息收发、好友与群管理等 REST 接口，HTTP 调用即可。
以下为发送文本消息的示例：
pythonimport requests
BASE = "https://你的接口域名" # 注册后在官方文档获取
TOKEN = "你的Token"
APPID = "你的appId"
HEADERS = {"token": TOKEN} # 鉴权字段名以官方文档为准
def send_text(to_wxid: str, content: str) -> bool:
url = f"{BASE}/message/postText"
payload = {
"appId": APPID,
"toWxid": to_wxid,
"content": content
}
resp = requests.post(url, json=payload, headers=HEADERS, timeout=10)
result = resp.json()
return result.get("ret") == 200
代码为示例，具体接口与字段以官方文档为准。
5.2 会话状态管理
AI 客服需要维护每个用户的会话状态，建议用 Redis 存储：
pythonimport redis
import json
r = redis.Redis(host="127.0.0.1", port=6379, decode_responses=True)
SESSION_TTL = 1800 # 30分钟无消息则会话过期
def get_session(wxid: str) -> dict:
raw = r.get(f"session:{wxid}")
if raw:
return json.loads(raw)
return {
"from_wxid": wxid,
"history": [],
"clarify_count": 0,
"is_human": False,
"last_intent": None,
"last_sentiment": None
}
def save_session(wxid: str, session: dict):
r.setex(f"session:{wxid}", SESSION_TTL, json.dumps(session, ensure_ascii=False))
def add_history(session: dict, user_msg: str, bot_msg: str):
session["history"].append({"user": user_msg, "bot": bot_msg})
# 只保留最近20轮，防止 context 过长
if len(session["history"]) > 20:
session["history"] = session["history"][-20:]
注意事项：SESSION_TTL 要结合业务场景设定。电商类客服用户可能今天咨询、明天再来，设置过短会导致历史丢失；设置过长则会话数据占用 Redis 内存增大。建议配合"会话主动关闭"逻辑：用户收到最终答复后，若 30 分钟内无新消息，自动清除会话状态，下次消息重新开始。
5.3 人工坐席接管后的消息路由
一旦转人工，后续该用户的消息应路由到坐席系统而非 AI 引擎。实现方式是在会话状态中标记 is_human=True，回调处理函数据此分流：
pythondef handle_text_message(data: dict):
wxid = data["fromWxid"]
content = data["content"]
session = get_session(wxid)
# 人工接管中：转发给坐席系统
if session.get("is_human"):
forward_to_human_agent(wxid, content, session)
return
# AI 处理流程
rule_result = rule_preprocess(content)
intent = rule_result if rule_result else recognize_intent(content, session["history"])
session["last_intent"] = intent.get("intent")
session["last_sentiment"] = intent.get("sentiment")
if should_transfer_human(intent, session):
context_summary = build_handover_context(session)
notify_human_agent(wxid, context_summary)
send_text(wxid, "正在为您转接人工客服，请稍候……")
session["is_human"] = True
elif intent.get("confidence", 0) < 0.85:
clarify_msg = generate_clarify_question(intent)
send_text(wxid, clarify_msg)
session["clarify_count"] = session.get("clarify_count", 0) + 1
add_history(session, content, clarify_msg)
else:
reply = generate_auto_reply(intent)
send_text(wxid, reply)
session["clarify_count"] = 0
add_history(session, content, reply)
save_session(wxid, session)
六、工程优化建议
6.1 意图识别延迟优化
大模型调用延迟通常在 1-3 秒，对实时客服体验有影响，常见优化手段：
- 规则前置：命中高频规则直接返回，跳过 LLM 调用，覆盖 60%~70% 的常见请求。
- 流式回复：若大模型支持 Streaming，可边生成边发送文字，减少用户感知延迟。
- 意图缓存：对完全相同的文本（如"你好""多少钱"）缓存意图结果，TTL 设 1 小时。
- 异步处理：回调收到消息后立即返回 200，意图识别和回复异步处理，避免回调超时。
延迟优化应有监控数据支撑，而不是凭感觉优化。建议在每次调用大模型时记录耗时，并按 P50/P95/P99 分位数统计，P95 超过 3 秒时再考虑引入额外优化手段。
6.2 误触发转人工的处理
转人工成本较高（需要坐席在线），应避免误触发：
- 负向情绪 + 置信度双重门槛：单独情绪负向不触发，需同时满足意图敏感。
- 白名单意图：部分负向表述实为正常询问（"这个价格不便宜啊"），应训练模型区分。
- 坐席忙时预案：坐席全忙时给出预计等待时间，并提供"稍后联系"选项，而非让用户无限等待。
另外需要注意的是，在坐席结束接待后，应将 is_human 状态重置为 False，并清除 clarify_count，让用户重新进入 AI 处理流程。否则下次该用户发消息仍会走人工路由，导致坐席资源浪费。
6.3 效果监控指标
上线后需持续监控以下指标，定期优化 Prompt 和规则：
| 指标 | 目标值 | 说明 |
|---|---|---|
| 意图识别准确率 | ≥ 90% | 抽样人工评估 |
| 自动解决率 | ≥ 70% | 未触发转人工的会话占比 |
| 误转人工率 | ≤ 5% | 本可自动处理却转人工的占比 |
| 平均响应时延 | ≤ 2s | 从消息入队到回复发出 |
| 用户负向情绪占比 | 监控趋势 | 持续上升说明自动回复质量下滑 |
建议每两周对近期所有转人工的会话做一次抽样复盘，重点看哪类意图被误判最多、哪些规则命中率在下降，据此调整 Prompt 中的意图类别定义或补充规则关键词。持续迭代是 AI 客服长期稳定运行的核心保障。
总结
意图识别是微信 AI 客服的核心能力，分层置信度模型结合大模型 Zero-shot 推理能在无需大量标注数据的情况下快速上线；转人工的触发逻辑应综合用户主动意愿、情绪信号、置信度和追问次数多维判断，而非单一阈值；会话上下文的完整移交则是保障用户体验不断档的最后一道关键工序。以上方案在实际项目中可按业务复杂度酌情裁剪，逐步迭代。