一、项目背景

XpShop 客服机器人最早是单轮问答形态：用户问一句、系统答一句，依托知识库检索能解决大量标准问题，例如物流时效、发票抬头、退换政策等。但随着 XpShop 新普MALL 私域会员体系与多终端订单量增长，我们发现单轮能答、多轮就乱——用户补一句"那我的退款到哪了"，机器人就丢了前文，只能让用户重新描述一遍；更复杂的退换货、改地址、发票重开问题，转人工又慢，高峰期排队严重，坐席疲于在多个系统间复制粘贴上下文。

这个项目里，我们决定把客服从"问答机"升级为"带状态的对话体"，并以工单流转承接复杂问题。我们依托自研 AI 网关的对话状态管理与统一接入能力，在不替换原有知识库的前提下做了增强，目标是让简单问题在对话内闭环、复杂问题平滑转人工并带齐上下文，不再让用户重复描述。

二、落地场景

落地后，客服对话由三部分协作，形成"识别—澄清—建单—流转"的连续链路：

• 多轮对话状态管理：维护用户意图、订单上下文、已澄清槽位（slot），并支持上下文压缩，避免历史消息撑爆窗口。
• 意图识别与澄清：对模糊问题主动追问缺失槽位，对高置信意图直接作答或建单，减少无效往返。
• 自动建单与流转：当问题超出自助范围，自动生成工单并路由到对应技能组，附带 SLA 计时与升级提醒。

简单问题在对话内闭环，复杂问题平滑转人工并带齐上下文，坐席接手即可处理，用户体验与坐席效率同步改善。

三、关键技术挑战与解决思路

对话状态与上下文压缩。 多轮对话最大的成本是上下文窗口被历史消息撑爆，导致后面的轮次"看不全"前面的信息，进而答非所问。我们没有盲目上更大模型，而是设计了一个轻量状态机：每轮对话后抽取关键槽位（订单号、问题类型、诉求、已承诺动作）写入状态，历史原文超过 N 轮就压缩为"摘要加槽位"再喂给模型。这样的好处是，无论对话多长，模型每轮拿到的都是精炼且完整的关键信息。我们的体会是：上下文压缩比模型大小更关键，中小模型配好状态机，往往比硬上大模型更省成本、更稳定。

案例片段（已脱敏）：对话状态结构片段—— {"session_id":"s_88231","intent":"refund_status","slots":{"order_no":"SO20260xxx","amount":199.0},"history_summary":"用户询问退款进度，已提供订单号","turn":4,"need_human":false}

意图识别与澄清。 用户常一句话含多个意图，或缺少关键槽位（只说"我要退款"却没给订单号）。我们用小模型先做意图分类与槽位抽取，置信度高于阈值时直接作答或建单；置信度低时按模板主动澄清（"请问您说的是哪笔订单？"）。澄清轮次设了上限，避免陷入无限追问的死循环，超过上限即引导转人工，把决定权交还给用户。

自动建单与 SLA。 当意图命中"需人工"或用户主动转人工，系统自动建单：把状态机里的槽位、摘要、原文摘要打包成工单字段，按问题类型路由到售后、物流、财务等技能组，并启动 SLA 计时。超时未处理触发升级提醒，确保复杂问题不会在队列里"沉底"。工单字段的结构化，是后续所有协同与统计的基础。

人机协同。 转人工不是甩锅，而是带着上下文转。坐席看到的不是空白聊天框，而是已填充的工单草稿与对话摘要，可一键接管。AI 在旁持续做建议回复，坐席采纳即发，显著降低平均处理时长。这个设计的核心，是让机器处理"记"和"整理"，让人专注"判断"和"共情"。我们在灰度阶段还做了一个小改进：当坐席连续三次采纳 AI 建议，系统会将该类问题的标准话术沉淀为知识条目，反哺单轮问答，形成"对话—工单—知识"的正向循环。

四、效果数据

下表为脱敏示意数据，统计口径为某区域客服队列上线前后一个月对比：

上述数值为内部脱敏示意值，用于说明趋势，不作为精确审计依据。

五、可复用经验总结

第一，上下文压缩比模型大小更重要。中小模型配合好的状态机，往往比硬上大模型更省成本、更稳定，这也是多轮对话能否规模化的隐性关键。第二，复杂问题要早转人工，不要让用户在机器人里反复打转，体验反而更差；澄清轮次上限是保护体验的护栏。第三，工单是机器人与人的最佳接口——把对话沉淀成结构化工单，人机协同才真正顺畅，坐席接手成本趋近于零。第四，意图识别用小模型前置分流，既降成本又提速。这套"状态机加澄清加自动建单"的组合，后来也被我们复用到智能核单等场景，验证了它在不同业务域下的通用性与可迁移价值。