摘要在电话呼入场景下大模型语音机器人转人工坐席时经常出现静音、重复播报、会话上下文丢失、状态错乱等问题。很多人把问题归结为 ASR 识别不准或者大模型回答质量差实际上大部分异常来自会话状态流转设计缺陷。本文从工程落地角度拆解呼入机器人会话状态机的设计思路分析人机切换的各类边界异常场景给出状态流转、上下文透传、超时兜底的实现方案。前言呼入语音机器人主要用于承接用户进线咨询、业务查询、简单单据受理当遇到复杂诉求、用户主动要求人工、模型置信度不足时需要平滑转接人工坐席。在实际项目落地中人机切换环节是故障高发点机器人已经停止播报但坐席侧听不到用户声音出现单向静音转接后机器人继续播放话术和坐席声音重叠转接成功后坐席看不到前面对话历史需要用户重复描述问题用户多次反复切换机器人 / 人工造成会话状态混乱网络抖动、信令延迟导致转接请求丢包会话卡在中间态。单纯依靠 SIP 信令完成呼叫转接只能解决通话线路的切换会话业务状态的管理必须依靠独立的状态机来管控。本文重点讨论业务层会话状态机而非底层 SIP 呼叫状态。1 呼入会话的基础状态定义我们把一次完整呼入会话拆解为 6 个核心业务状态状态之间单向流转不允许无规则跳转INIT通话建立完成机器人准备就绪等待用户发言BOT_ACTIVE机器人正在交互ASR 持续监听用户语音大模型负责应答TRANSFERRING触发人工转接进入转接流程中间临时状态不可长期停留AGENT_WAIT转接指令下发成功等待坐席摘机接听AGENT_ACTIVE坐席接入成功人工与用户通话机器人暂停输出SESSION_END通话挂断会话归档状态终结关键设计原则任何时刻会话只能处于单一状态避免多状态并行。比如进入TRANSFERRING后必须立刻停止机器人的 TTS 播报不能一边转人工一边继续播放语音。很多项目踩坑就是没有做状态互斥转接指令发出后TTS 队列里还有未播放的文本音频继续推送造成人机声音重叠。2 触发人机切换的条件触发从BOT_ACTIVE进入TRANSFERRING状态一般分为三类触发源用户主动触发用户说出 “转人工”“客服”“我要找人工” 等意图模型自动判定大模型返回置信度低于阈值识别到业务超出知识库范围规则触发识别到投诉、高危关键词直接强制转人工。触发转接时状态机需要同步执行三件事暂停当前 TTS 播放清空待播放语音队列冻结当前对话上下文生成会话快照向呼叫平台下发转接指令同时把会话快照随事件透传给坐席侧。这里需要注意触发转接 ≠ 转接成功。下发转接指令只是发起动作坐席是否空闲、能否及时摘机都存在不确定性所以需要单独设置TRANSFERRING与AGENT_WAIT两个中间状态不能一步直接跳到AGENT_ACTIVE。3 核心难点中间状态的超时与兜底逻辑TRANSFERRING和AGENT_WAIT是最容易出问题的两个临时状态。 场景举例用户要求转人工但当前所有坐席全部占线排队等待超时。如果状态机没有超时兜底会话会永久卡在AGENT_WAIT既没有人工接入机器人也已经停止工作用户只能听到静音最终挂断。兜底策略设计设置AGENT_WAIT超时阈值例如 30s超时未匹配到空闲坐席状态机回退到BOT_ACTIVE机器人告知用户 “当前坐席繁忙可以继续和我咨询或者稍后再试”保留之前全部对话上下文不会清空会话历史。另外还有异常场景转接指令下发后网络抖动导致转接事件丢失。状态机需要增加事件回执机制等待呼叫平台返回转接结果回执收到回执再变更状态超时没有回执则判定转接失败执行回退逻辑。重点状态变更必须以呼叫平台回执为准不能本地状态机直接预判转接成功。4 会话上下文透传设计无感转接的核心体验是坐席接入之后可以直接看到前面全部对话记录不需要用户重复描述问题。 上下文快照需要包含完整对话文本用户问句 机器人回复ASR 识别分段记录、识别置信度已提取的用户业务参数手机号、订单号、诉求类型触发转接的原因用户主动要求 / 模型置信度不足 / 高危词触发快照生成时机进入TRANSFERRING状态瞬间生成快照只读后续机器人不再写入新内容。 数据推送方式随 WebHook 事件推送到坐席工作台坐席端加载会话快照。这里有一个工程坑不要实时流式推送对话。如果边转接边持续写入对话会出现快照数据不一致。进入转接状态后会话上下文冻结不再新增内容。5 状态机事件幂等处理呼叫中心的 WebHook 回调、SIP 事件经常重复推送。同一事件多次到达状态机如果不做幂等校验会造成多次触发转接、状态反复切换。解决方案每一通通话分配全局唯一call_id作为会话主键状态机每次状态变更持久化存储最新状态写入数据库收到事件时先校验当前存储状态判断本次事件是否合法重复事件直接丢弃不执行状态流转。举个例子已经成功转接人工状态为AGENT_ACTIVE再次收到 “转人工” 事件状态机直接忽略不会重复发起转接。6 状态流转图文字版INIT → BOT_ACTIVE BOT_ACTIVE →【触发转接】→ TRANSFERRING TRANSFERRING →【收到平台回执坐席排队】→ AGENT_WAIT AGENT_WAIT →【坐席摘机】→ AGENT_ACTIVE AGENT_WAIT →【排队超时】→ BOT_ACTIVE上下文保留 AGENT_ACTIVE →【用户挂断/坐席挂断】→ SESSION_END 任意状态检测到挂断事件 → SESSION_END7 落地过程中的常见踩坑总结缺少中间临时状态直接从 BOT_ACTIVE 跳到 AGENT_ACTIVE忽略排队过程坐席忙时直接静音未清空 TTS 队列转接触发后缓存的语音继续播放人机声音重叠上下文没有冻结转接过程中还在持续写入对话坐席拿到的会话记录不完整无事件幂等信令重复推送多次触发转接超时兜底缺失坐席全忙会话卡在等待状态长时间静音状态只存在内存不持久化服务重启会话状态丢失通话异常。8 总结呼入语音机器人的人机无感切换底层通信线路依赖 SIP 中继而业务体验好坏由会话状态机决定。状态机的核心不是复杂逻辑而是精细化拆分中间状态、严格状态互斥、增加超时兜底、会话快照冻结、事件幂等校验。在项目开发中很多团队优先打磨大模型问答效果忽略状态流转边界场景导致上线后转接体验不稳定。只有把各类异常场景坐席全忙、网络丢包、用户反复切换、服务重启全部纳入状态机的设计范围才能实现真正平滑的人机切换提升呼入机器人整体可用性。