“我想订明天的……上午那一班。”如果系统在省略号处开始回答，识别出的文字再准确，体验也会很别扭。语音 Agent 需要判断的不是只有“有没有声音”，还包括“现在轮到谁说话”。
VAD 提供语音活动信息，轮次结束检测判断用户是否说完，打断检测判断系统是否该让出话语权。 这几种信号有关联，但不能直接互相替代。
VAD、VAP、EOT 与 INT 各是什么意思？
| 名称 | 主要问题 | 一个容易混淆的边界 |
|---|---|---|
| VAD：语音活动检测 | 这段音频中是否存在语音活动？ | 安静不一定意味着说完了 |
| VAP：语音活动预测 | 根据已观察的对话，后续活动可能怎样变化？ | 预测不是读取未来音频 |
| EOT：轮次结束判断 | 当前说话者是否准备交出话语权？ | 句中换气可能仍属于同一轮 |
| INT：打断判断 | 对方是否正在接管当前话轮？ | 简短附和不一定是要求停下 |
应用可以组合声学证据、对话内容与历史状态来判断时机。具体模型使用哪些信息，应以实现和评测协议为准，不能从缩写推断。
为什么固定静音时长容易出问题？
假设系统听到一段安静就开始回应，较短阈值可能频繁截断用户；较长阈值又会增加每次等待。用户语速、口音、环境噪声和表达习惯也会影响同一阈值的表现。
这并不意味着固定阈值完全不能用。对于约束明确、表达短而稳定的场景，它可以作为基线。关键是拿真实的停顿和更正样本比较收益，而不是只在几条理想录音上观察“反应很快”。
打断之后，应用还要做什么？
检测器给出一个时机信号，应用还要决定是否暂停播放、取消旧输出、等待用户继续，以及保留或修改原任务。这里可以用三个不同层面检查：
- 声音层：旧语音实际什么时候停止？
- 对话层：用户的新内容有没有被完整听取？
- 任务层：旧目标与工具结果有没有被正确处理？
例如，用户在播报天气时说“我问的是上海”，系统暂停后还应改对城市。只统计“是否停声”，会漏掉任务是否真的纠正成功。全双工交互中的状态处理
如何评价轮次检测模型？
检出更多事件可能同时带来更多误触发，因此至少要同时报告召回率、误触发率和检测延迟。更完整的应用测试还应记录错误抢话次数、无谓暂停、恢复成功率和用户实际等待时间。
同样叫“延迟”，起点和终点也可能不同：使用标注事件时间到预测事件时间，还是从用户发声到设备停止播放？是否包含推理计算和网络？对比前先固定口径。
Simplex MicroCF 的公开记录能说明什么？
MicroCF 的公开文章介绍了当前语音活动与后续活动预测相结合的时机判断方法，并分别报告打断与轮次结束任务。以下是文章保存的 TurnBench 测试记录，不代表所有部署条件下的表现，也不是今天实时榜单的排名声明。
| 任务 | 召回率 | 误触发率 FPR | 中位检测延迟 |
|---|---|---|---|
| 打断检测 INT | 98.4% | 7.3% | 747 ms |
| 轮次结束 EOT | 90.6% | 7.9% | 678 ms |
公开页注明榜单核对日期为 2026-09-23，测试集为 116 段对话。这些是检测指标，不是完整语音应用的端到端响应速度。开发集复评另有时间戳口径，不能直接混入这张测试表。MicroCF 公开说明与原始来源链接
这类记录可以帮助理解检测任务及取舍，不等同于公开 API 已经可用。Simplex 的交互模型尚未公开上线，接入能力和开放状态应以产品页面的实际说明为准。
做一个更接近现实的语音测试集
准备以下几组情景，标记用户意图、真实交接时刻和预期应用行为：句中长停顿、完整句后的短停顿、用户明确更正、简短附和、旁人说话，以及系统播放时的回声。录音必须来自可合法用于测试的材料。
每个情景同时检查时机和任务结果。用户更正了城市，正确行为应包含新城市进入任务状态；用户只是“嗯”了一声，是否要中断应由具体对话意图决定。记录判定规则，避免测试人员每次凭感觉给分。
常见问题
轮次结束检测是不是语音识别的一部分？
它可以与语音识别集成，但问题不同。识别文字回答“说了什么”，轮次判断回答“是否该接话”。一个系统可能识别正确，却在错误时机回应。
打断越快越好吗？
还要看误触发和恢复是否正确。如果背景声音会频繁让播报停止，仅优化停声速度并不能改善整体体验。
这些判断和机器人有关吗？
有关。机器人和数字人同样需要决定何时回应、何时继续听，但还会叠加视觉关注对象与动作状态等问题。见 机器人交互模型指南。