eess.AS · 2605.20755 · 20 May 2026（v2: 11 Jun 2026）

DuplexSLA: A Full-Duplex Spoken Language Model with Synchronized Speech, Language, and Action

Haoyang Zhang, Jun Chen, Donghang Wu, Yuxin Li, Yuxin Zhang, Xiangyu Tony Zhang, Che Liu, Qingjian Lin, Yizhou Peng, Hexin Liu, Eng Siong Chng, Chao Yan, Boyong Wu, Yechang Huang, Xuerui Yang, Fei Tian

📄 摘要 📑 PDF 🌐 HTML 💻 GitHub

Full-Duplex Speech-Language-Action Turn-Taking In-Conversation Tool Use Voice-Agent Benchmark

⚠️ 补充调研：本文 arXiv 主分类为 eess.AS（Audio and Speech Processing），不在日报流水线常规扫描的 cs.AI/cs.LG/cs.MA/cs.RO/cs.CL/cs.SE/cs.CV 类别范围内，因此结构性地未被每日候选池收录——非某天筛选疏漏，是分类扫描范围的盲区。已按用户反馈单独补精读。

一句话：DuplexSLA 是一个原生全双工 语音-语言-动作基础模型，在共享的 160ms chunk 时间轴上，用单一 backbone 联合解码用户音频（连续输入）、助手音频（离散输出）、结构化动作文本（限速率输出）三条通道，让"听、说、规划、调用工具"发生在同一个时钟上。核心贡献两点：(1) 语义驱动的打断/停顿/背景应答（backchannel）控制内建在 backbone 内部，不依赖外部语义 VAD；(2) 会话中规划与工具调用不打断语音输出，多动作、backchannel 触发的工具调用可与持续语音交织进行。配套提出 DuplexSLA-Bench 评测打断/停顿/背景应答 + 三种会话中工具调用风格。与用户核心参考论文 DuplexOmni（480ms 时间片、双层异步架构）形成有趣对照：DuplexSLA 走的是单一 backbone 单时钟联合解码路线，而非 DuplexOmni 的双层解耦异步路线——两者代表 duplex agent 架构设计空间的两极。

核心问题：duplex backbone 缺少原生 agentic 通道

口语对话模型近年从 turn-based 转向 full-duplex 设计——模型持续监听用户输入的同时生成响应。但作者指出一个被忽视的缺口：现有的 duplex backbone 缺少一条用于"会话中规划与工具调用"的原生通道。结果是实时 agentic 行为要么被绑死在 turn 边界上（必须等一轮结束才能规划/调用工具），要么被甩给一个外部的级联系统（ASR → LLM planner → TTS），后者天然引入延迟并破坏全双工的实时性。

DuplexSLA 试图用一个统一的 backbone 同时解决"全双工语音交互"和"会话中 agentic 行为"两个问题，而不是像多数系统那样把二者拆成两个独立子系统再拼接。

三通道联合解码架构

Dual-Stream 三通道公式化

模型在一个共享的 160ms chunk 时间轴上同时解码三条通道，全部由单一 backbone 联合建模：

用户音频通道（连续、持续输入）——模型始终在"听"
助手音频通道（离散、输出）——模型的语音响应
文本动作通道（限速率输出）——规划文本与结构化工具调用

三条通道不是三个独立模块拼接，而是同一个 backbone 在同一时钟节拍下的联合解码结果，这是与"ASR+LLM+TTS 级联"或"外挂 planner"路线的根本区别。

160ms 的 chunk 粒度明显细于 DuplexOmni Interaction Layer 的 480ms 时间片——三倍的时间分辨率，意味着更细粒度的打断/背景应答响应窗口，但也对应更高的解码调用频率，这是一个值得关注的延迟/算力权衡点（论文摘要未给出具体推理延迟数字，需读正文/代码验证）。

语义驱动的打断/停顿/背景应答控制

能力一：Turn-Taking 内建于 backbone

打断（interruption）、停顿（pause）、背景应答（backchannel，如"嗯""对"这类不打断说话者的短应答）全部在同一个 backbone 内部处理，不依赖外部语义 VAD（Voice Activity Detection）模块。这与多数级联式全双工系统形成对比——那些系统通常需要一个独立的 VAD/端点检测组件来决定"何时该我说话"，而 DuplexSLA 把这个决策直接融入语言建模本身，理论上能利用更丰富的语义上下文做打断判断（而不仅是声学能量/静音检测）。

这一点与 DuplexOmni 的"控制 Token 体系"（[CUT]/[WAIT] 等六个显式控制信号）形成设计对照：DuplexOmni 用显式 token 在两层之间传递打断/等待信号，DuplexSLA 则把打断决策隐式融入单一 backbone 的联合解码过程。两种路线孰优孰劣（显式可解释信号 vs 隐式端到端建模）是一个值得跟踪的开放问题。

会话中规划与工具调用

能力二：In-Conversation Planning & Tool Calling

规划文本与结构化工具调用在动作通道上输出，不打断助手音频的持续生成——即模型可以一边说话一边在后台完成规划/发起工具调用。摘要特别强调支持 multi-action（一次交互中触发多个动作）与 backchannel-triggered tool use（背景应答期间触发的工具调用）与正在进行的语音交织。这直接对应 duplex agent 的一个实践痛点：传统"先想清楚再说话"的串行模式在实时语音场景下会造成明显的响应延迟或尴尬的静默。

这一能力与用户当前 projects/duplex-sandbox/ 关注的"交互/推理解耦"维度高度相关——DuplexSLA 提供了另一种解耦方式：不是像 DuplexOmni 那样用两个独立层（S1 实时 / S2 深度推理）物理分离，而是把规划/动作作为**第三条通道**塞进同一个时钟节拍里，靠通道隔离而非层级隔离来实现"说话不阻塞思考、思考不阻塞说话"。

DuplexSLA-Bench 基准

配套评测集：DuplexSLA-Bench

覆盖两大类能力的联合评测：

Turn-taking：pause（停顿处理）、interrupt（打断处理）、backchannel（背景应答）
会话中工具调用：三种风格（摘要未展开具体分类，需读正文确认，可能对应"立即调用/延迟调用/背景应答触发调用"等模式）

项目主页、交互式 demo、评测套件均已公开：github.com/hyzhang24/DuplexSLA。这是目前少见的把"turn-taking 质量"和"会话中 agentic 能力"放进同一个基准联合评测的尝试，值得和 DuplexOmni 论文中的 DuplexBench ToR 指标做交叉对比。

研究者视角：与 DuplexOmni 的架构对照

把 DuplexSLA 放进用户核心方向的坐标系里看，它和 DuplexOmni 恰好构成 duplex agent 架构设计空间的两个代表性极端：

两条路线的核心分歧在于："实时响应与深度推理的解耦，应该靠架构层级（两个模型/两层）还是靠通道/时钟设计（一个模型/多通道）？" DuplexOmni 的两层设计更容易插拔任意强度的外部 LLM（推理天花板可换），但需要显式协议（控制 token）协调两层；DuplexSLA 的单 backbone 设计天然一致性更强、延迟理论上更低，但深度推理能力被绑定在同一个 backbone 的容量里，扩展推理天花板可能需要重新训练整个模型而非替换一个可插拔组件。这对用户的 duplex-sandbox 项目是一个直接可借鉴的架构选型参考维度。

此外，DuplexSLA-Bench 与 DuplexOmni 论文中的 DuplexBench 是两个独立但主题高度重合的评测集，如果两者的 pause/interrupt/backchannel 测试协议可比，交叉跑分会是判断两条架构路线相对优劣的一个直接实验。

	DuplexOmni	DuplexSLA
解耦方式	两层物理分离（Interaction Layer / Thinking Layer）	单一 backbone，三通道共享时钟
时间粒度	480ms 时间片	160ms chunk
打断/等待控制	六个显式控制 token（[CUT]/[WAIT] 等）	语义驱动，隐式内建于 backbone
深度推理承载	可插拔外部 LLM（Thinking Layer）	同一 backbone 的动作通道（规划文本）
工具调用	未在摘要中特别强调为核心贡献	核心贡献之一，与 backchannel 联动