传统智能客服的主要矛盾已经不再是“能不能回答”,而是“能不能稳定解决问题”。听不懂用户意图时答非所问,遇到复杂任务时只会重复 FAQ,高峰期又无法有效分担人工压力。要从“机械应答”走向“服务伙伴”,关键并不是单纯换一个更大的模型,而是把客服 Agent 建设成一套边界清晰、过程可观测、结果可回退的工程系统。
大模型不能直接等于客服系统
一个可上线的客服 Agent,至少需要区分四类职责:
- 语言理解:识别用户到底想查询物流、申请退款,还是处理账号问题。
- 业务决策:根据订单状态、售后规则和风险等级决定下一步动作。
- 工具执行:通过受控接口查询订单、创建工单或提交退款申请。
- 服务兜底:模型不确定、接口失败或风险过高时,把完整上下文交给人工。
如果让模型直接读取用户输入并自由生成答案,系统很容易出现两种问题。一种是“听起来合理,但业务上错误”;另一种是模型擅自承诺退款、时效或补偿。高可控架构需要把模型限制在合适的位置:模型负责理解和组织语言,确定性代码负责权限、规则与状态变化。
可以把一次对话拆成下面这条处理链:
用户消息
-> 意图识别与信息抽取
-> 置信度/风险判断
-> 会话状态机
-> 白名单工具调用
-> 结果校验
-> 回复生成或人工接管
-> 全链路审计
这条链路的价值在于,每一步都可以单独评估。意图识别错误、工具参数错误和回复表达错误,不再混成一个难以定位的“模型效果不好”。
多轮问题需要状态,而不只是聊天记录
复杂客服任务通常缺少必要信息。例如用户只说“帮我退一下”,系统至少还需要知道订单、商品、退款原因以及当前履约状态。直接把所有历史消息塞进提示词,并不能可靠管理这些约束。
更稳妥的做法是维护结构化会话状态:
{
"session_id": "s-1024",
"intent": "refund",
"slots": {
"order_id": "OD20250308001",
"reason": null
},
"stage": "collecting_information",
"risk_level": "medium",
"tool_history": []
}
Agent 每轮只做有限决策:补充缺失字段、调用一个允许的工具、回答查询结果,或者转接人工。这样既能处理多轮任务,也能防止模型跳过必要步骤。
状态机还应表达业务上的不可逆边界。例如“查询退款资格”是只读操作,可以自动执行;“正式提交退款”会改变业务状态,通常需要二次确认、幂等键和权限校验。两者不应该共享同一个模糊的“退款工具”。
一个可运行的受控 Agent 骨架
下面是一个仅使用 Python 标准库的最小示例。它不代表来源中的具体实现,而是一种可以这样实践的工程骨架:用确定性路由模拟意图识别,用白名单注册工具,并在低置信度或高风险操作时转人工。
将代码保存为 agent.py,使用 Python 3.10 及以上版本运行。实际接入模型时,可以替换 classify_intent,但应保留工具白名单、参数校验和人工接管逻辑。
from dataclasses import dataclass, field
from typing import Any, Callable
import json
import re
@dataclass
class Session:
session_id: str
slots: dict[str, Any] = field(default_factory=dict)
events: list[dict[str, Any]] = field(default_factory=list)
def record(self, event: str, **data: Any) -> None:
self.events.append({"event": event, **data})
def query_order(order_id: str) -> dict[str, str]:
# 示例数据;生产环境应调用只读订单服务。
return {
"order_id": order_id,
"status": "shipped",
"message": "订单已发出,正在运输中"
}
TOOLS: dict[str, Callable[..., dict[str, str]]] = {
"query_order": query_order,
}
def classify_intent(text: str) -> tuple[str, float]:
if any(word in text for word in ("物流", "快递", "到哪", "订单状态")):
return "order_query", 0.92
if any(word in text for word in ("退款", "退货", "不要了")):
return "refund", 0.88
return "unknown", 0.35
def extract_order_id(text: str) -> str | None:
match = re.search(r"OD\d{8,}", text.upper())
return match.group(0) if match else None
def handoff(session: Session, reason: str) -> dict[str, Any]:
session.record("handoff", reason=reason)
return {
"action": "handoff",
"reply": "这个问题需要人工进一步处理,我已整理当前对话信息。",
"reason": reason,
}
def handle(session: Session, text: str) -> dict[str, Any]:
intent, confidence = classify_intent(text)
session.record("intent_detected", intent=intent, confidence=confidence)
if confidence < 0.70:
return handoff(session, "low_intent_confidence")
order_id = extract_order_id(text) or session.slots.get("order_id")
if order_id:
session.slots["order_id"] = order_id
if intent == "refund":
# 退款会改变业务状态,示例中不允许 Agent 直接执行。
return handoff(session, "state_changing_operation")
if intent == "order_query" and not order_id:
return {
"action": "ask_user",
"reply": "请提供以 OD 开头的订单号,我来查询物流状态。"
}
tool = TOOLS["query_order"]
result = tool(order_id=order_id)
session.record("tool_called", tool="query_order", result=result)
return {"action": "reply", "reply": result["message"], "data": result}
if __name__ == "__main__":
session = Session(session_id="demo-001")
for message in ("帮我看看物流,订单 OD20250308001", "我想退款"):
response = handle(session, message)
print(json.dumps(response, ensure_ascii=False, indent=2))
print(json.dumps(session.events, ensure_ascii=False, indent=2))
运行命令:
python agent.py
这个示例刻意没有让 Agent 自动提交退款。它体现了一条重要边界:自动化率并非越高越好,应该按照操作风险逐级开放能力。订单查询可以自动执行,退款申请可以先收集信息,实际资金操作则应经过确认或人工审核。
可控性要落实到接口和观测数据
只有提示词里写着“不要擅自操作”并不可靠。真正的控制需要落在模型之外:
- 工具采用白名单注册,模型不能构造任意 URL 或数据库语句。
- 每个参数使用 JSON Schema、类型模型或服务端逻辑重新校验。
- 写操作携带幂等键,避免模型重试导致重复退款或重复建单。
- 查询、决策、工具调用和最终回复都记录关联 ID,便于还原单次服务过程。
- 敏感字段在进入模型和日志前脱敏,并根据岗位限制人工坐席的可见范围。
- 超时、接口异常和模型低置信度必须进入明确的降级路径。
评估指标也不能只看回答是否流畅。更有业务意义的指标包括意图识别准确率、任务一次解决率、工具调用成功率、错误自动执行率、人工转接率、转接后的平均处理时间,以及用户重复描述问题的次数。
其中,“错误自动执行率”应被当作高优先级指标。一个系统即使拦截了较多请求,只要能避免错误修改订单和资金状态,也可能比高自动化但不可控的方案更适合早期上线。
上线时采用分级放权
客服 Agent 适合从只读、低风险、高频任务开始。实际推进时可以使用下面的检查清单:
- 先覆盖订单状态、物流进度和规则说明等只读场景。
- 为每个意图定义必填字段、允许工具和禁止动作。
- 建立离线测试集,纳入口语、省略表达、错别字和多意图输入。
- 通过影子模式观察 Agent 决策,不立即影响真实业务。
- 小流量开放写操作,并加入确认、幂等和审计机制。
- 定期分析人工接管原因,把高频缺口转化为新的流程或工具能力。
从“机械应答”到“服务伙伴”的分水岭,不是回复更像真人,而是系统能否理解目标、推进任务,并在不确定时克制地停下来。模型提供语言和推理能力,状态机、业务规则、工具权限与人工坐席共同提供可靠性。只有这几部分形成闭环,Agent 才能真正缓解排队压力,而不是制造一批新的售后问题。