识别用户意图打断的关键在于实时捕捉语义层面的意图覆盖与上下文重置信号，而非监听语音停顿或检测输入中断；需通过语义单元切分、并行意图分类、优先级比对实现精准打断识别，并配合三层清理与上下文锚点机制。
识别大模型流式交互中的用户意图打断，关键不在“监听语音停顿”或“检测输入中断”，而在于实时捕捉语义层面的意图覆盖与上下文重置信号。底层网络清理逻辑不是清空缓存或关闭连接，而是有选择地丢弃已生成但未确认的部分响应，并冻结当前对话状态机中正在执行的槽位填充或意图推理链。
打断的本质是意图覆盖，不是输入终止
用户在流式输出过程中插话（如模型刚说“正在为您查询订单…”时用户接一句“等等，我要查的是退款进度！”），系统要识别的不是“用户说话了”，而是新输入是否否定了前序意图、引入更高优先级意图、或要求中止当前流程。这需要：
- 将流式token序列按语义单元切分（如每完成一个主谓结构就做一次轻量意图再评估）
- 对新输入启动并行意图分类，不等待完整句子，用首3–5个词快速触发高置信度候选意图
- 比对新意图与当前活跃意图的业务优先级（例如“取消操作”永远高于“继续查询”）
网络层清理不是丢整个session，而是精准截断生成链
当确认发生有效打断后，系统需立即执行三层清理：
- 生成层：向LLM调用接口发送cancel请求，终止未返回的token流；对已发出但未渲染的片段（如前端尚未显示的补全句）标记为“discardable”
- 状态层：冻结当前DST（对话状态跟踪）中正在填充的槽位，保留原始值但设为“stale”；若新意图含冲突槽位（如原查“订单123”，新问“订单456”），则直接覆盖旧槽位
- 网络层：复用现有HTTP/2连接，仅重置当前stream ID，不重建TCP连接；避免TLS握手开销，保障毫秒级响应连续性
必须配合的上下文锚点机制
单纯靠文本匹配无法稳定识别打断，需在每次流式响应前注入轻量上下文锚点：
- 在生成每个语义块前，附带当前意图ID、关键槽位哈希、时间戳（精度到100ms）
- 用户新输入到达时，系统比对新输入时间戳与最近锚点时间戳差值，若＜800ms，视为强打断信号
- 对“等等”“不对”“换一个”等高频打断触发词，不依赖语义分类，直接激活硬规则拦截通道
业务侧要防的两个典型误判
真实场景中，两类情况最易被错判为打断，导致体验断裂：
- 自修正表达：用户说“我想查订—哦不，是查退款”，后半句是自我纠正，非意图切换，此时应合并为单一“查询退款”意图，不触发清理
- 补充说明：用户在模型输出中途插入“对，就是那个蓝色的”，这是槽位补全，不是打断，应暂停生成、提取新实体、再续流
