语音设备支持打断，需要同时处理新一轮输入、旧回答生成、设备播放队列和已经启动的业务任务。用户插话后扬声器停下，只完成了其中一环；系统还要识别旧结果、避免过期音频重新播放，并向用户说明任务是否已经执行。
2026年10月19日，ElevenLabs在变更日志中介绍Eleven Realtime，采用逐步向工作区开放的方式。10月20日，Mistral发布Voxtral Mini Transcribe Realtime 3公开预览，文档列出结束说话检测等能力。这些进展让语音模型与对话管理进一步结合，但终端的完整交互仍需由采集、网络、播放和业务系统共同完成。ElevenLabs变更日志；Mistral模型说明
先定义产品中的“打断”
在桌面陪伴终端中，用户说“换个话题”，可能只需要停止当前回答；在家庭设备中，用户说“等一下”，可能是在撤回一条尚未执行的指令。两句话都发生在设备说话时，处理方式却不能相同。
产品设计时应把语音会话和业务任务分开。语音会话回答谁正在说、该轮输入是否结束、当前播放到哪里；业务任务回答请求是否已接收、是否开始执行、是否还能取消。前者变化不应自动覆盖后者的真实状态。
先约定常见用户表达的含义。普通插话是否只影响播报，明确的停止词是否请求取消，设备执行到哪一步后只能报告结果而无法撤销。没有这份约定，不同模块可能把同一个事件理解成不同动作。
从用户发声到扬声器停止，中间发生什么？
设备正在播放自己的回答时，麦克风可能同时收到用户声音、扬声器回放和环境噪声。采集端要处理回声及音频输入，再判断是否出现需要响应的新输入。单纯看到麦克风音量变化，不能认定用户正在插话。
语音活动检测通常用于识别有无语音；判断用户是否已经说完，还需要结合停顿和对话规则。用户在一个数字或地址中间停顿，不一定代表轮次结束。把所有停顿都当作新请求，会让设备频繁抢话。
ElevenLabs的Conversation flow文档将静默等待、打断和轮次响应倾向分别配置。它们是对话策略，不能代替整机声学调试，也不等于固定的端到端响应时间。对话流程文档
可以先在同一套音频条件下比较不同策略：完整短句、中途停顿、旁人说话、电视背景声和设备自身播报。观察每次是否形成新轮次，以及有没有错误停止原回答。测试结果需要连同输入片段和配置保存，不能只记录“能打断”。
取消生成与清空播放队列要一起做
一轮回答可能经历文本生成、语音合成、分片传输、解码和排队播放。即使云端停止生成，设备内存或音频驱动中仍可能有尚未播放的数据。用户就会感觉“已经打断，设备却又接着说”。
可以为每轮回答维护独立标识，并让文本、音频分片和播放回执携带相同标识。新的有效轮次开始后，把旧轮次标记为失效；后到的旧音频不再进入播放队列。这样能区分网络延迟到达的数据与真正的新回答。
终端还需要明确播放队列的清理边界：应用队列清空后，解码器或驱动是否还有缓存；新的音频是否会与旧缓冲拼接；正在输出的片段怎样结束。具体实现取决于音频框架，不能只在上层设置一个布尔变量。
ElevenLabs Speech Engine文档介绍，用户在回复中途说话时，SDK会通过AbortSignal或任务取消停止进行中的LLM请求。这是特定SDK的生成取消机制，设备端缓存与外部业务状态仍须另行协调。Speech Engine说明
工程中还要处理取消与完成同时发生的情况。旧回答结束事件晚到时，不应把新一轮会话改成“已完成”；旧网络连接回调也不能关闭正在工作的播放通道。状态更新要核对轮次身份，再决定是否接受。
工具执行中被插话，先查状态再回应
假设用户让设备创建一个提醒，系统已经提交请求，用户随后说“不要了”。直接回答“已取消”可能不真实。正确处理要先判断请求是否还在本地等待、是否已提交，以及服务端是否支持撤销。
业务层可以明确待确认、已提交、执行中、已完成、取消中、已取消和结果未知等状态。状态名称可以按项目简化，但未知结果不能用一个“成功”或“失败”强行覆盖。请求超时不一定代表没有执行。
取消本身也应当有结果。能撤销的操作请求取消并核对回执；不能撤销的操作说明已经发生什么，并给出后续可行操作。不要把“停止解释”当作“撤回动作”，也不要因为用户换了话题就丢失原任务结果。
ElevenLabs为工具提供允许打断、仅执行期间抑制打断，以及整个工具轮次抑制打断等模式。这些选项控制对话行为，不授予业务系统撤销能力。工具打断设置
产品界面也要区分两类停止。停止播报可以让用户迅速恢复安静；停止任务则需要确认执行状态。二者可以在同一个入口中组织，但反馈应准确，避免用户以为声音停了，设备动作也一定停止。
把时延拆开记录，才知道该改哪里
体验卡顿时，直接更换模型不一定解决问题。用户发声、检测到插话、停止旧音频、新请求发出、首个结果返回和新音频开始播放，是不同时间点。
可以在设备与服务中记录这些阶段，使用同一事件标识串联。设备本地耗时和跨网络耗时分开计算；时钟未对齐的两台机器，不能把日志时间直接相减当作精确时延。先保证测量口径可靠，再比较版本。
除了平均值，还要保存慢请求、重连和异常样本。一次漂亮演示不能反映弱网或长回答的尾部情况。验收时应说明使用的硬件、音频设置、网络、模型配置和任务，避免把某次短句结果当成整机承诺。
打断测试还需要看回答连续性。新轮次是否理解用户刚才改了哪个条件，是否错误复用已经放弃的内容，是否把部分播放过的回答当作完整传达。没有必要把每条历史都重新朗读，但会影响执行的条件要重新确认。
板卡、云端与控制系统怎样分工？
终端侧优先承担确定的交互反馈和播放管理，例如明确显示接收、等待、暂停和错误。云端可以负责模型推理、语义理解和任务组织。业务控制层负责权限、任务身份、执行状态和结果核验。
分工不应只写“本地负责硬件，云端负责AI”。还要约定取消事件由谁发起，哪些组件需要确认，断线后保留哪些任务，以及重连时怎样查询原结果。接口中需要有足够信息让每一侧判断当前轮次和任务是否仍有效。
普众数智的板卡与智能体方案把硬件资源、指令接口和异常反馈放在同一协同设计范围中。准备项目材料时，可以把用户插话、任务取消和网络恢复作为交互需求，连同设备形态与外设条件一起讨论。板卡与智能体方案
做样机时也要考虑资源竞争。录音、解码、显示和网络重连可能同时占用处理器与内存。只测试一个功能分别正常，不能证明组合运行时仍能及时响应。应在最终计划使用的资源配置上重复检查。
重连之后，怎样避免旧回答突然出现？
连接恢复时，设备不能仅把缓存按到达顺序重新播放。应先确认当前会话、轮次与业务任务，再决定哪些结果仍需交付。用户已经放弃的解释可以丢弃，尚未看见的真实执行结果却可能需要保留。恢复规则应根据内容用途确定。
可以把会话恢复与音频续播分开：恢复连接后查询必要状态，重新确认用户需要，再生成简洁反馈。不要默认重播所有历史音频，也不要把一次连接失败变成静默删除任务。对跨设备接续，还应明确哪个终端拥有当前输出权。
测试时保留断线前后的事件记录。让网络分别在生成中、工具提交后和播放中断开，比较恢复行为。相同故障发生在不同阶段，用户应看到不同而准确的状态，不能始终使用同一句“网络异常”。
把这些状态组织进一份接口表，双方约定标识、顺序与重复事件处理方式。参数可以随产品调整，但任务的真实结果必须可追踪。资源有限的板卡尤其要限制缓存量，并为必要状态留出空间。
一组可执行的验收用例
正常回答中插话，检查旧播报是否停止、新问题是否接续；长回答期间插话，检查有没有残余音频；工具提交后取消，检查任务状态是否准确；断网后重连，检查是否重复执行原操作。
再加入无效触发：设备自身播报、旁人交谈和短促噪声。记录误打断与漏打断，分别查看触发条件。对需要完整传达的信息，应先约定用户能否暂停，以及恢复后从什么位置继续。
每个用例应保存输入条件、实际事件顺序、任务结果和用户侧反馈。问题记录不只写“偶尔卡住”，而要标出是没有识别插话、旧队列未清、服务未取消，还是结果状态没有返回。这样才方便不同供应方共同排查。
最终验收看完整体验：用户改变主意后，系统能否及时听见、停止过期输出、保持真实任务状态，并给出可理解的下一步。把这些条件写进设计，语音打断才从一个按钮选项变成可交付能力。