语音全双工交互近两月论文综述：从同时听说到理解插话、恢复现场与完成任务
语音助手正在解释一个方案，你说了一句“对，就按第二种”。它应该停下来等你说完，继续原来的介绍，还是直接围绕第二种方案往下讲？如果它已经在内部生成了五条建议，扬声器却只播完两条，此时再问“刚才说到哪了”，它又该以哪份历史为准？
这两个小问题概括了近期语音全双工研究的变化：同时听说只是运行条件，真正困难的是在不断变化的对话中选择动作，并让动作对应用户实际经历的过程。
本文整理 2026 年 7 月 28 日至 9 月 28 日首次提交的 21 篇核心论文，并以 6 月的全双工综述搭建背景框架。沿着架构与交互定义、数据、模型与运行时、评测展开，比较方法怎样工作、实验究竟支持什么，以及怎样组成实际可用的验证流程。
要解决的问题
全双工语音交互至少包含四项彼此相关、却不能互相替代的能力：
| 能力 | 一个具体问题 | 只测声音质量会漏掉什么 |
|---|---|---|
| 持续感知 | 系统说话时，用户的新输入是否仍被理解？ | 播报期间输入实际上被丢弃 |
| 发言权控制 | 当前应等待、接话、继续还是让出话轮？ | 把所有“嗯”都当成打断 |
| 在线修正 | 用户补充条件后，当前回答是否改变？ | 声音没停，但新条件没被采纳 |
| 状态连续 | 打断、播放与工具返回之后，历史是否仍然一致？ | 把尚未播放的内容当成已经讲过 |
这里的 backchannel 指听者的简短反馈，如“嗯”“对”，通常用于表示正在听；barge-in 指用户在系统发言中插入语音；turn-taking 指双方如何协调发言权。它们之间没有简单的一一对应关系：同一句话在不同上下文中，可能承担不同作用。
架构上也不能只按“级联”或“端到端”判断能力。外部轮次控制器可以支持连续监听，原生双流模型也可能学到不合适的停说策略。下面先展开这个区别，再阅读近期论文。
背景综述：Speaking While Listening 提供的三把尺子
补充阅读线索来自读者提到的语音之家综述及其知乎链接，读者进一步提供了 MM-Speech/DuplexSurvey 官方仓库。知乎正文未能直接读取，以下技术概括依据官方仓库和论文，不转述未核实的公众号措辞。
仓库使用题名 Speaking While Listening: A Survey and Empirical Audit of Full-Duplex Spoken Dialogue Systems；arXiv v1 题名为 A Survey of Full-Duplex Spoken Dialogue Systems: Architectural Hierarchy, Interaction Ontology, and Decision State Machine，首次提交于 2026 年 6 月 17 日。仓库记录了 8 月 EMNLP 2026 主会接收信息。这是同一项工作的题名与发布阶段差异，不应重复计数，也不计入本文近两个月的 21 篇。(论文记录)
1. L0–L3：决策发生在哪里
| 层级 | 决策位置 | 综述中的代表或定位 |
|---|---|---|
| L0 | 外部模块或控制器 | FireRedChat、FlexDuo |
| L1 | 读取模型隐藏状态的预测器 | MinMo、Freeze-Omni |
| L2 | token 流中的同步与生成 | Moshi、OmniFlatten、SyncLLM |
| L3 | 共享潜在表示中的双工建模 | 尚未实现的研究设想 |
这个分类不是性能等级。它定位“谁决定听、说、等”，不能仅凭 L2 标签断言系统优于 L0，也不能把已有流式系统直接归为 L3。(官方仓库：架构分层)
2. T × I × R：声音重叠只是现象
T 表示时间关系，I 表示用户意图，R 表示系统应答动作。例如，同为重叠语音，短反馈要求继续，争取发言权要求停说，旁人声音可能要求忽略。综述选出六类关键检验：常规接话、近零间隔接话、插话打断、说话中的短反馈、第三方声音、带长停顿的犹豫。(论文 §5)
3. 状态机：动作如何随时间展开
五个状态是 Idle、Listen、Speak、Wait、Dual。它们区分无人发言、倾听、发言、等待和双方同时发声并持续处理输入；论文用十一条转换描述行为。两个最有用的轨迹是：真正打断时 Speak → Dual → Listen，支持性短反馈时 Speak → Dual → Speak。这是一种观察和比较行为的框架，不要求每个模型实现同一套控制代码。(论文 §6)
用这套框架重新看近两个月的进展
下面是本文基于各篇论文作出的对应分析，并非原综述对后来论文的评价。
| 背景框架提出的问题 | 近期工作怎样推进 | 仍不能省掉的检查 |
|---|---|---|
| 决策放在哪一层？ | X2-Turn 联合输出转写与状态；AdaptDuplex 显式输出动作并调整更新窗口 | 更新频率、决策耗时与实际停声是否一致 |
| 相同重叠对应什么意图？ | ECHO 让同一句插话随上下文翻转动作；Duplex Cue 检查继续时是否吸收信息 | 动作正确以后，内容是否也正确 |
| 数据是否覆盖目标行为？ | 两篇 DuplexGen 与 Synthesis Harness 分别从偏好、时序、事件标签构造监督 | 合成样本的行为收益能否迁移到真人 |
| 到达某状态是否等于真正会用？ | SteerDuplex 用后训练调整互动；TurnBench 按场景暴露检测误差 | 训练来源重叠、风格迁移与奖励投机 |
| 状态机还缺哪些现场信息？ | Self-Listening 引入已播放前缀；工具架构引入后台任务与返回事件 | 用户改口后，旧输出和旧任务怎样失效 |
我的理解是，这篇综述的最大价值在于把架构能力、行为覆盖和实际表现分开。近期论文继续追问：同样能进入“双方同时发声”的状态，究竟能否理解对方、更新当前内容并保持任务连续？因此，本文既保留它的分类，也额外检查播放进度和工具状态；仅看听、说状态仍不足以解释这两类失败。
检索范围与证据口径
检索截至 2026-09-28，组合使用 full-duplex、spoken dialogue、turn-taking、backchannel、interruption、speech agent、streaming ASR 等关键词，并沿论文引用和作者项目页补查。主要核验入口为 arXiv、ACL Anthology 与作者公开项目；博客和聚合页用于发现线索与参考表达结构，论文结论回到一手来源核对。
纳入直接研究语音并发交互、轮次控制、相关训练数据和交互评测的工作。以 arXiv 首次提交日期判定是否进入主表，避免把会议收录、模型发布或论文更新日期混在一起。窗口包含 7 月 28 日当天；ECHO 和 DuplexDrama 的讨论采用 9 月 24 日的 v2。
这是一份有明确范围的研究整理，不能保证检索穷尽。主表中的测量均为作者报告，本次没有重新训练模型或复跑榜单。方法与局限能从正文核对的部分在文中展开；仅完成摘要级核验的工作保留为简短条目。论文公开、代码公开、权重公开和数据可下载是不同状态，本文不把论文出现等同于完整可复现。
论文地图：21 篇工作分别补哪块能力
以下日期均为 2026 年。表内使用简称，链接指向对应版本的论文；两篇 DuplexGen 是不同团队的独立工作。
一、数据：如何保留对话里的时间与意图
| 首次提交 | 论文 | 主要贡献 | 阅读时要保留的边界 |
|---|---|---|---|
| 07-28 | DuplexGen：Adaptive Synthesis | 用少量人工偏好校准不同场景下的轮次行为合成 | 六类合作、竞争任务的偏好不能直接代表所有应用 |
| 08-17 | DuplexGen：Decoupling Content, Timing, and Acoustics | 分离脚本内容、双模型互动时序与声学重渲染 | 时序分布接近真人，不等于下游任务自然提升 |
| 09-08 | ConversationalVoice | 从真实对话分离声道，再重建和扩展内容 | 评测针对数据属性，下游训练收益仍待验证 |
| 09-11 | DuplexDrama | 合成覆盖场景、人设、双工行为、情绪和声音事件的对话 | 论文描述内部训练验证；计划发布子集不等于已全部开放 |
| 09-23 | A Harness for Synthesizing Diverse Naturalistic Full-Duplex Conversations | 从带意图和相对关系的事件列表生成双声道语音及动作标签 | 合成监督的训练收益仍需用独立真人交互检验 |
二、模型与运行时：怎样持续决策而不丢失状态
| 首次提交 | 论文 | 主要贡献 | 阅读时要保留的边界 |
|---|---|---|---|
| 08-11 | X2-Turn | 在共享流式表征上并行预测 ASR token 与帧级轮次状态 | 中英 Easy-Turn 上的控制能力，不能替代完整对话评测 |
| 09-04 | What Did I Just Say? Self-Listening | 把已播放的自身语音送回模型，定位打断时的实际进度 | 锚定进度与常规轮次控制仍有取舍 |
| 09-08 | TASTE2 | 将文本对齐语音表征扩展为增量对话和流式合成系统 | 能流式运行不代表首段音频延迟已经足够低 |
| 09-11 | SteerDuplex | 基于 Moshi 改善语音指令控制，并用强化学习优化互动 | 时序奖励可能诱导不完整回答 |
| 09-12 | Realtime-Venus | 前台持续交互，后台异步推理与工具执行，共享因果时间线 | 音频、音视频模型及不同评测项需要分开看 |
| 09-16 | A frontend-backend architecture for tool calls | 双工前台发出委派信号，由文本后台调用工具，再注入结果 | 工具召回、参数正确与任务成功是不同指标 |
| 09-18 | NemotronLabs VoiceChat | 统一流式架构包含语音、转写与结构化工具调用通道 | 工具选择较好，参数与端到端执行仍是短板 |
| 09-24 | AdaptDuplex | 显式决策 token、动态时间窗、分层认知与外部推理 | 时间窗仍是离散选择，并发控制与取消仍有误差 |
三、评测：怎样识别“看起来会聊天”的捷径
| 首次提交 | 论文 / 评测集 | 它增加的检验维度 | 不能直接推出的结论 |
|---|---|---|---|
| 08-11 | DuplexWorld | 六类任务世界中的任务、对话与语音质量 | 自然度分数不能代替任务成功率 |
| 08-25 | TurnBench | 跨六种互动风格的结束与打断检测 | 某一种对话风格的阈值不一定通用 |
| 09-03 | DuplexSpeechBench-IFEval | 从角色隐含要求推断行为，区分内容与发言权遵循 | 人设口吻正确不等于主动行为正确 |
| 09-11 | Continue, Adapt, or Yield / Duplex Cue | 把“继续并吸收新信息”作为单独行为 | 单模型英语案例不构成通用排名 |
| 09-11 | MP-Bench | 多人场景的接话意识、回应适当性与理解 | 双人交互成绩不能外推到多人会议 |
| 09-15 | Same Words, Different Actions / ECHO | 同一插话文本在不同上下文中应作相反动作 | 固定轨迹诊断不等于闭环真人交互 |
| 09-17 | Full-Duplex Speech Models Take the Floor When Asked, Not When Needed | 区分“有机会说话”和“有理由主动介入” | 被点名后能回答，不代表会自主判断介入时机 |
| 09-23 | Neither Silence nor Overlap Is Failure / TACT | 根据意图和人类时序分布评价响应时机 | 分数依赖意图标注和参考分布，不能与二元准确率直接换算 |
主线判断
将这些工作放在一起，我的判断是：全双工研究正在把原先隐藏在“自然对话”里的三个问题拆开。
第一，合适的交互策略从哪里来。同样的停顿，在教学、闲聊和竞赛中可能有不同含义，因此训练数据需要记录场景、意图以及行为发生的位置。
第二，模型依据哪一份现场作决定。生成文本、实际播出的语音和后台任务并不同步，恢复对话必须知道用户听到什么、任务执行到哪里。
第三，怎样确认策略确实理解了上下文。一个遇到声音就停的系统，可能在打断测试中很好看；一个永远不停的系统，也可能在继续说话测试中占便宜。评测需要让这两种固定策略都暴露出来。
这是对上述论文的综合解释。各篇论文研究的对象、语言、模型版本和分数定义不同，本文不把它们拼成一张“谁最强”的总榜。
数据路线：真实感、可控性与训练价值要分开验证
先把数据流水线拆成三个问题：谁决定对话内容，谁决定事件时序，最后怎样得到监督标签。这比按总小时数排序更有解释力。
| 路线 | 内容与时序怎样产生 | 监督来自哪里 | 最需要做的对照 |
|---|---|---|---|
| 7 月 DuplexGen | 场景化生成，再用人工偏好校准互动 | 人对不同场景中行为的偏好 | 同一场景校准前后；换场景后是否仍成立 |
| 8 月 DuplexGen | 脚本约束内容，双模型演绎时序，再重渲染声音 | 演绎出的双声道互动轨迹 | 固定声音换时序；固定时序换声音 |
| ConversationalVoice | 真实对话经分离、重建与扩展 | 原始互动结构与重建结果 | 原录音与重建录音的事件一致性 |
| DuplexDrama | 场景、人设与声音事件驱动合成 | 合成过程中描述的对话行为 | 稀有事件覆盖、标签正确率、下游训练收益 |
| Synthesis Harness | 先写事件关系，再合成、强制对齐到共同时间轴 | 事件意图转换成帧级动作 | 事件标签是否可学；模型自己生成时是否仍受益 |
表中最后一列是本文建议的验证设计。各路线的技术依据见下文对应论文。一个有用的数据清单应同时记录小时数、独立对话数、事件数和来源去重情况：重复采样一个长对话能增加训练步数，却没有增加同等数量的交互情境。
人类偏好告诉我们“什么场合该怎样说”
7 月的 DuplexGen 用人工标注校准场景中的轮次偏好，关注交互规范是否随任务改变。它提示了一个数据设计问题：训练集即使包含很多自然对话，也不一定明确告诉模型，当前扮演什么角色、允许怎样插话。该工作的对照包含未经校准的提示生成与通用人际对话数据。(论文与项目)
对数据工程而言，值得保留的单位是“场景—候选动作—偏好”，而不仅是两个人分别说了什么。这是本文的实践推论；具体应用中的偏好仍需要自己的用户验证。
两个 DuplexGen 的“自然”指向不同问题
8 月的同名工作把脚本交给两个相互监听的模型演绎，再进行 TTS 重渲染。正文中，重叠按相对位置迁移，静默间隔直接保留，不能把摘要中的“保留时序”理解为所有绝对时间戳完全不变。
更值得读的是它的控制实验：当重渲染方式固定时，互动时序与拼接时序之间的 ASR 错误差异有限；改变重叠的渲染强度却明显改变识别难度。这说明“对话时序更像真人”和“识别任务更难”可以来自不同因素。(方法 II-D、实验 IV-D)
从真实重建与从事件合成，是两种不同起点
ConversationalVoice 从真实双人录音出发，保留声道、说话人和互动关系，再重建、扩展。论文明确只验证数据属性；声音质量或自动自然度评价变好，还不能作为模型训练有效的证明。(ConversationalVoice)
DuplexDrama 则从丰富的场景、角色和表达设置出发。作者报告已生成超过 2,000 小时语音，其中带至少一种双工行为的轮次占 3.8%；计划发布 800 小时精选子集。这里最值得关注的是行为覆盖和有效样本比例，而非只看总时长；公开可复现的训练增益也需另行核验。(DuplexDrama v2)
9 月的 synthesis harness 让 LLM 描述事件之间的关系，再根据合成音频对齐到共同时间轴，覆盖中英两种语言。作者给出了 Moshi 微调后的轮次控制收益，因而比只报告音频自然度更接近训练闭环；但仍需测试收益能否迁移到独立真人录音和实际设备。(Synthesis Harness)
由此可以设计三层验收：先检查内容和事件标签是否正确，再检查渲染后是否保留事件，最后验证训练后的动作质量。三层都通过，才有依据扩大合成规模。
事件图如何变成“现在该停”的监督
Synthesis Harness 的关键中间表示是事件关系。例如，先规定用户在系统说到某个词之后插话，再对每条语音独立合成和强制对齐，用实际词边界求插入时刻；成功打断还会裁去系统被打断后的尾部。它不要求文本模型提前猜中 TTS 的绝对时间。
随后，同一段声音可以按意图映射为占据、取得、释放、不占据发言权等标签。短反馈虽然包含用户声音，却不自动对应“系统释放发言权”。作者在模型自行生成的评测中报告，占据发言权的帧级 precision 从 0.46 提升到 0.88；使用标准对话历史时报告的是另一项 floor F1。两组结果不能混成一个分数。(方法 II–III、实验 IV-C)
这也暴露了合成数据的一个风险：如果“打断”总在固定词位出现，或者所有短反馈都很短，模型可能学会位置或时长捷径。可以固定同一句插话，交换前文、说话对象和插入位置，再检查行为是否随真正的意图变化。这个对照也把数据设计与后面的 ECHO 评测连起来。
模型路线：决策时钟、播放进度与后台任务
帧级状态预测与动态时间窗解决不同成本
X2-Turn 在 Voxtral Realtime 的共享流式表征上增加并行轮次状态头，让转写与状态判断在帧级对齐。它为已有系统提供了一条增量改进思路：先提高持续决策能力，再观察完整交互的收益。(X2-Turn)
具体来说，X2-Turn 每 80 毫秒更新一次，共享隐藏状态同时送入 ASR 头和状态头；训练目标是两项交叉熵的加权和。词级轮次标签被投射到 ASR token 的帧位置。推理时只有 ASR 输出回到自回归输入，状态预测不反馈给 ASR 解码环路。
它区分静默、刚开始说但语义尚不足、语义未完成、语义完成、短反馈五类状态。其中 noidle 指刚开始的语音，不能误读成背景噪声。80 毫秒是更新步长，目标延迟还由独立参数控制，因此不能把它写成端到端响应延迟。(X2-Turn §2)
AdaptDuplex 把行为决策显式放入 token 协议，并在多个时间窗之间动态选择。窗口缩短有助于更快更新，窗口变长则改变计算成本与互动取舍。论文支持推理时调整决策偏置，但这只是移动策略的工作点：更积极响应可能同时损害 backchannel 或旁人语音场景。
它在 HumDial-FDBench 报告综合分 72.9；表中的跨系统延迟没有硬件匹配，不能据此宣布某种架构普遍更快。其外部推理动作还包含使用标准历史前缀的评测，不能全部视为自由运行中的任务成功率。(AdaptDuplex §3)
阅读 AdaptDuplex 时，比总分更有解释力的是同一模型内部的时间窗消融：
| 同一检查点的窗口设置 | 打断行为分 | 短反馈行为分 | 打断后停声延迟（秒） | 平均回应延迟（秒） |
|---|---|---|---|---|
| 固定 0.48 秒 | 0.82 | 0.52 | 1.19 | 0.32 |
| 固定 0.96 秒 | 0.76 | 0.56 | 2.61 | 0.66 |
| 动态选择 | 0.79 | 0.55 | 1.32 | 0.37 |
这组实验支持的是速度与行为之间的取舍：动态窗口接近短窗口的速度，但并非每一项都最好。行为分使用 FDB-v1.5 的场景映射，回应延迟按四类场景等权平均。它还有一个独立的协议消融：相同语义记录改用紧凑序列，解码 P50 从 789.4 降到 418.5 毫秒；这是序列化成本，不能当成完整语音链路延迟。(AdaptDuplex 表 3–4)
TASTE2 提供了另一种提醒：保留文本模型能力与降低部署延迟需要分别衡量。其部署在两张 RTX A6000、经过 TensorRT 加速后，平均首段音频时间仍为 2.701 秒。这个数值只适用于论文配置，却足以说明“支持流式”本身不是低延迟的证据。(TASTE2)
打断恢复要以实际播出进度为准
Self-Listening 将已播放的自身语音作为输入，使模型能以用户实际听到的前缀恢复交互。在 AnchorSpeech 上，匹配对照的锚定准确率从 7.8% 提高到 73.0%；同时，论文也报告了锚定与常规轮次管理之间的取舍。它支持“播放历史有用”这一结论，尚不能推出所有对话能力都会一起改善。(Self-Listening §1–3)
下面是一个原创示意例子，时间与内容均不代表论文测量：
| 同一时刻 | 系统内部可能保留的内容 | 用户实际经历 |
|---|---|---|
| 文本生成 | 第一至第五条已生成 | 尚不知道第五条存在 |
| 音频合成 | 第一至第三条已合成 | 第三条还在队列 |
| 扬声器播放 | 第二条刚播放完 | 用户只完整听到两条 |
| 用户打断 | “重复刚才那一条” | 指向第二条 |
据此，工程实现至少要区分已生成、已合成、已播放三个进度。取消输出时，也需要核对音频队列是否真正停止；服务器侧停止生成之后，客户端缓存仍可能继续播出。这是播放一致性的实现要求，不应由模型的最终文本来代替。
工具调用必须进入同一条对话时间线
Realtime-Venus 用前台维持连续交互，后台处理推理与工具，并以因果时间线连接输入、输出和委派事件。其 FDB v1.5 结果分别报告真正打断与几类非打断重叠，说明系统评测需要观察相反方向的行为。(Realtime-Venus)
NVIDIA 的 frontend-backend 论文让前台发出委派 token，将流式转写交给文本后台，并把结果注入前台。它报告单轮工具调用召回率为 92%–97%，但召回不意味着参数正确或整个任务完成。(Frontend-backend architecture)
它的执行顺序值得单独写清楚：前台预测 <tc_bos>，说一小段等待提示，再输出 <tc_eos>；随后将转写交给后台执行。后台结果先作为上下文预填充，再由前台复述为语音。训练时预填充区域不计算损失，后面的复述区域参与训练。论文明确说明，工具执行期间前台保持静默。因此这套方法证明了模块化委派和结果回注的可行性，不能据此宣称已经解决等待期间持续交互。(架构与训练 §3–4)
NemotronLabs VoiceChat 的系统论文则展示了并行文本与结构化工具输出、增量转写和流式语音生成的统一设计。其 FDB 3.0 工具选择 F1 为 82.5%，作者同时指出参数准确率与端到端执行仍需改善。(VoiceChat)
本文的工程推论是：后台结果返回时，应先检查它对应的请求是否仍有效。例如用户已经将“周五”改为“周六”，旧查询结果可以留作记录，却不应直接当成新请求的答案播报。停止语音、取消查询和撤销已完成操作也需要不同的执行语义。
将四种运行时改动放到同一张图里看
下面是本文用于比较机制的逻辑图，各论文不必采用全部组件：
1 | 用户音频 → 流式编码 → 当前语义与轮次状态 → 动作决定 |
X2-Turn 主要改变“当前语义与轮次状态”的生成方式；AdaptDuplex 改变决策协议和更新时机；Self-Listening 为历史补入播放证据；前后台工具系统补入委派与返回路径。按这个图定位以后，就能解释为什么它们可能互补，也能避免把一个局部改进描述成完整解决方案。
例如，同样是“及时打断”，可能在四处失败：用户声音没有进入模型；模型误判为短反馈；已决定停说但音频队列没清空；停说成功但恢复时依据了未播出的文本。四种失败需要不同实验，单一平均延迟无法区分。
评测路线：从停不停，走向为什么停、如何继续
ECHO 检查上下文依赖，Duplex Cue 检查内容吸收
ECHO 固定插话文本，改写前置对话，使配对样本分别需要 Keep 与 Yield，并用两边都正确的配对成功率压制固定动作策略。它针对中文、固定轨迹中的动作诊断；两边独立合成的音频并非完全匹配，结果不能被解释成只改变上下文的纯声学控制实验。(ECHO v2 §1–2)
Duplex Cue 增加第三种行为：继续说话，同时吸收听者贡献。在 66 对可评估的合作性提示上，人类与 PersonaPlex 的适应比例分别为 68.2% 和 34.8%。这是有条件的案例结果：单个模型、英语录音、筛选后的样本；意图标注还看到了后续回应，存在标签与结果相互影响的风险。(Duplex Cue §5–6)
二者可以组成互补测试：先问同一句插话在不同情境中能否触发正确动作，再问继续时有没有真正采纳内容。对于明确要求停止的用户，应尊重停止意图；“继续并调整”并不适用于所有插话。
场景与意图决定“快”是否合适
TurnBench 用 30 小时人工标注双人对话覆盖六种互动风格，对比 14 类系统。其关键发现是打断误报与对话类型关系明显，尤其容易出现在简短反馈密集的场景。(TurnBench)
TACT 进一步按意图条件评价响应时序分布，包含 9,728 个片段、73.2 小时数据。它试图避免固定时间窗把合理等待或提前接话一律判错；实际采用时仍要检查意图标注、参考分布和目标用户是否匹配。(TACT)
因此，延迟报告最好同时给出事件类型、起止点和分位数。用户开始插话到系统停声，与用户说完到回复首音，是两种不同的时间；只写“响应 300 毫秒”无法说明体验。
指令、主动性与任务完成需要另设考题
SteerDuplex 提供 SteerBench 来评价语气、人设、风格、语速和长度等控制。其强化学习实验也暴露了奖励投机：回答不完整可能换来更好的时序表现。(SteerDuplex)
其训练分工是：SFT 学会按指令控制表达，第一阶段 RL 增加回答连续性约束，第二阶段特别采样用户短反馈并奖励继续表达。策略损失作用于文本通道，也包括承载等待时间的 padding 动作；音频码本动作没有直接的策略损失。这个细节说明，改进声音中的时序行为，不一定要直接对全部声学 token 做 RL。
SteerBench 又区分单项 rubric 通过率与整例通过率。假设一条回答满足四项要求中的三项，前者可记为 75%，后者仍为失败。正文还披露部分 FDB 样本来源与训练对话重叠，因此应优先看作者排除来源重叠的测试结果。(SteerDuplex §3–5)
DSB-IFEval 则通过 1,038 个样例、八类角色比较显式行为指令与角色隐含要求，并将发言权遵循和内容人设遵循分开计分。(DSB-IFEval)
关于主动发言，Take the Floor 的实验发现，被直接点名和遇到静默，比发现错误事实或危险更容易触发受测模型说话；这提示需要分别测试“是否启动发言”和“开口后是否说对”。(Take the Floor)
MP-Bench 把对象扩展到多人对话，在 12 个语音 Agent 上观察接话意识与回应适当性；DuplexWorld 则用六类任务世界中的 156 个场景联合考察任务、对话和语音自然度。它们说明，单个插话测试只是完整应用评测的一部分。(MP-Bench、DuplexWorld)
先对齐协议，再比较数字
| 评测对象 | 实际问的是什么 | 容易误读的地方 |
|---|---|---|
| TurnBench 的事件检测 | 对人工标注的结束或打断事件，何时发出检测信号？ | 检测信号正确，不等于后续回答正确 |
| ECHO 的配对动作 | 同一句插话换上下文后，两种相反动作是否都选对？ | 单项平均正确率会掩盖固定策略 |
| Duplex Cue 的适应行为 | 系统继续说时，有没有吸收协作性贡献？ | “有回应”不等于采纳信息，更不等于采纳正确 |
| TACT 的条件时序 | 对当前意图和说话人，何时回应或保持沉默更合适？ | 合理时间是一种分布，不能直接换算成二元正确率 |
| DSB-IFEval 的指令遵循 | 角色和行为要求是否影响了发言决策？ | 内容人设得分不能替代行为遵循得分 |
| DuplexWorld 的任务 | 互动最终有没有推进并完成任务？ | 自然度、轮次质量和任务成功应分开报告 |
这些差异来自前述各论文的评测定义。用于项目验收时，可以保留三个分母：全部测试案例、成功触发动作的案例、成功完成任务的案例。否则，把失败触发的样本排除以后，剩余回答的质量和延迟都可能显得很好。
举一个原创计分例子：100 对上下文翻转样本共 200 条，模型始终选择“停”。如果每对恰好一条应停、一条应继续，单条准确率就是 50%，但两条同时正确的配对成功率为 0%。这说明配对指标在检验对上下文变化的敏感性，而不是多加一个形式相近的分数。
时间指标也要拆开报告：音频更新步长、动作决策耗时、插话到停声、用户结束到回复首音、工具请求到可用结果分别处在不同环节。更短的模型更新步长，不保证客户端更快停止播放；工具很快返回，也不保证回答采纳了用户最后一次改口。
最小抽象
如果要把这些工作接到同一个实验系统中，可以将每个决策时刻描述为四部分：
| 部分 | 记录内容 | 用来回答什么问题 |
|---|---|---|
| 可见历史 | 截至当前时刻的用户音频、对话上下文、已播内容 | 当时系统究竟知道什么？ |
| 交互解释 | 说话对象、可能意图、当前发言权 | 为什么选择这个动作？ |
| 实际动作 | 等待、开始、继续、调整内容、让出话轮 | 策略是否落实到输出？ |
| 外部进度 | 播放位置、后台请求状态、已接受的结果 | 恢复和续接是否依据真实现场？ |
这是本文用于组织实验的抽象，并非所有论文共享的协议。它的价值是让一次失败能被定位：是输入没听到、意图解释错了、动作没执行，还是历史与播放进度不同步。
工程闭环
建议先建立一个小而有对照的回放集，再做真人闭环评测。下面是一组可以直接用于制定实验计划的场景，均为本文建议。
| 测试切片 | 对照方式 | 至少同时记录的指标 |
|---|---|---|
| 自然停顿 | 句内停顿与真正结束，尽量匹配停顿长度 | 抢答率、漏接率、首音延迟 |
| 短反馈与打断 | “对”作为赞同，与“对了，我要改一下”作为新请求 | 错误停播、漏打断、停声延迟 |
| 上下文翻转 | 固定插话文本，改变前文；再做音频匹配对照 | 单项与配对动作成功率 |
| 协作补充 | 用户补词、纠正数字、补充约束 | 动作分布、内容采纳、答案正确性 |
| 播放锚定 | 固定生成内容，改变实际播放到的位置 | 已播进度判断、跳项与重复 |
| 异步任务 | 工具返回前改口、取消或开始新话题 | 参数正确、旧结果误用、任务成功 |
| 多人或背景语音 | 保持语句内容，改变说话对象和来源 | 误响应、错误让出话轮、对象识别 |
| 角色与主动性 | 显式要求、角色暗示、需要提醒但未被点名 | 行为遵循、介入适当性、回应完整性 |
实施时有三个关键控制。
首先，回放必须保持因果性。决策只能使用当时已到达的输入，不能把整句转写或未来音频提前提供给模型。后台结果也应在实际返回时才可见。
其次，把失败样本留在分母中。没有输出、超时、无法转写、未进入可评分状态，都应报告数量和原因；若某个分析必须筛选可评分子集，应同时展示筛选前后的覆盖率。
最后，离线回放通过后再做真人交互。录音中的对方不会因为模型抢话而停下来，也不会因迟答而重复提问。真实用户的适应行为会改变后续输入，所以固定轨迹只能诊断部分能力。
小样本推演
以下均为原创测试情境，帮助把论文问题转成可观察行为。
情境一：用户说“嗯，对”。 系统正在说明流程，用户只表示理解。理想行为可以是继续讲解；如果它每次都停下，打断响应可能看起来很敏捷，整体对话却会被切碎。
情境二：用户说“第二个，选第二个”。 如果上一句正在征求选择，系统应更新当前方案；如果它正在复述用户已选的第二项，这句话也可能只是确认。测试时需要让前文真正改变目标动作，并人工复核歧义。
情境三：用户问“刚才最后那条再讲一遍”。 文本已生成五条，音频只完整播出两条。正确续接应锚定第二条，同时报告部分播放、播放确认缺失等边界情况，不能简单从文本末尾取一条。
情境四：查周五的行程时，用户改成周六。 旧工具结果先返回，系统应识别它属于旧请求；新的结果尚未到达时，可以说明仍在查询，而不是把旧结果当成新答案。
四个例子分别对应保持发言权、上下文理解、播放一致性与后台状态一致性。它们都需要语音输入，却无法只靠一个 ASR 错误率或首音延迟解释。
还缺什么证据
最值得补的证据是跨条件迁移：在合成数据和已知模型上改善的行为，换到真人、自发对话、不同语言、设备回声和网络抖动后是否保留。其次是长期交互：短片段中正确让出一次话轮，不等于多次改口之后仍能维护任务状态。
评测集之间也需要明确边界。相同名称的“打断成功”可能使用不同触发点、时间窗和内容评分；同样写着 latency，也可能测决策、停声或首音。任何跨论文比较都应先核对这些定义。
窗口内还检索到 Real-TurnTurk、多人对话中的注视与轮次预测 和 Rethinking Binary Evaluation of Turn-Taking under Inherent Ambiguity。它们分别补充语言覆盖、多模态社会信号和概率评价，本篇将其列作相关研究，不计入核心 21 篇。无线通信里的 full-duplex，以及只做离线识别或单句合成的论文，不在本文范围内。
直接结论
近两个月最有价值的进展，是研究开始为“自然互动”提供可检查的组成部分：场景化数据教模型何时行动，连续状态和播放反馈帮助它恢复现场，异步架构让复杂任务与即时交互共存，更细的评测则检查它是否理解了插话。
对实际项目，优先级可以很明确：先建立包含短反馈、真正打断和上下文翻转的测试集；再检查内容采纳、实际播放进度及工具返回的一致性；最后用真人闭环验证这些改进是否能提高任务完成率。选模型时，比较它在哪类情境中做对了什么，比单看“全双工”标签更有用。
下一步阅读：
阅读与写作参考
上方三张论文表构成本文的一手文献索引。组织方式参考了 Puneet Mathur 的全双工架构讲解 中从术语到机制的展开顺序，以及 Fullduplex 将研究信号关联到原始来源的呈现方式；站内则沿用问题、机制、验证与结论相衔接的结构。正文观点、示例和实验建议为独立整理，技术判断以所链接论文为依据。