边说话边做事：用前后台分离让语音中断不再取消任务

英文题目：Qwen-Audio-Agent Technical Report

标签：#全双工语音交互 | #评测协议 | #智能座舱 | #语音 | #音频大模型

评分：7.5/10 | 创新 1.3/2 | 技术严谨 1.1/1.5 | 实验充分 0.8/1.5 | 清晰度 0.8/1 | 影响力 1/1.5 | 开源 1.2/1.5 | 可复现 0.1/0.5 | 工程/实践 1.2/1.5

👥 作者与机构

• Chong Deng：机构信息未在 arXiv HTML 中可靠披露
• Yunjie Ji：机构信息未在 arXiv HTML 中可靠披露
• Yuxiang Kong：机构信息未在 arXiv HTML 中可靠披露
• Xiangang Li：机构信息未在 arXiv HTML 中可靠披露
• Xu Li：机构信息未在 arXiv HTML 中可靠披露
• Binbin Zhang：机构信息未在 arXiv HTML 中可靠披露
• Haina Zhu：机构信息未在 arXiv HTML 中可靠披露
• Jianheng Zhuo：机构信息未在 arXiv HTML 中可靠披露

📌 核心摘要

全双工语音交互要求用户可在任务执行中随时打断、追加约束或追问中间产物，而会话节奏与任务执行节奏天然不一致。前景智能体负责流式理解与全双工对话，对即时操作直接调用工具，对需长时推理的请求经spawn_thinking生成自包含目标并向后台委托。编排运行时为该委托创建任务记录并立即返回任务标识以让前景对话继续，随后独立维护排队、运行、完成、失败与取消状态，并协调面向用户的信息与授权请求。运行时在任务完成而用户仍在说话或前端正在应答时保留结果至可播报时机合并送达，环境事件静默更新会话内上下文而跨会话记忆提供个性化，前端再在当前语境中播报结果与制品引用。相比仅靠应用层集成实现异步的语音方案，该运行时把语音打断与任务取消正交控制、把执行完成与结果送达分离，并以统一事件协议与前后端适配器兼容不同前端模型、后端智能体与客户端。在自有座舱基准134例上混合执行任务成功率91.04%，超过直接执行的72.39%与全委托的80.60%；在80个四配置均成功的匹配轮次上混合执行平均执行延迟4.729 s最低。该结论仅在座舱域、Qwen Audio 3.0 Realtime Plus加qwen3.8-max组合下验证，训练、推理与部署成本原文未披露。

🔗 开源与复现资源

• 代码相关资源：https://github.com/QwenAudio/qwen-audio-agent — 链接可访问（HTTP 200）

可达状态仅表示本次链接检查结果，不代表许可证、本文权重或运行复现已验证。

🧭 深度解读

输入是什么，目标是什么，本文要解决什么矛盾？

本文的输入是连续语音对话、文本与图像输入、客户端传来的环境状态变化，以及跨会话积累的用户偏好，目标是在用户可以随时插话、修改约束、追问进度的条件下，完成跨越多轮对话的任务并在合适时机返回结果。必须保留的关键信息是系统把对话与执行分开管理，语音打断不隐含取消任务，执行完成不等于立即投递结果。

输出是 1 篇可复述方法的解读，帮助研究生按原文复现前后台架构、任务生命周期、环境事件与记忆规则，并在相同实验条件下理解混合路由的效果与边界。本文只讲论文实际研究的座舱、桌面协助与语音客服 3 类任务，不把通用语音识别或语音合成的进展当作本文的贡献。举例来说，用户说帮我查一份文档并订票，查文档还在后台进行时用户又补充时间约束，这就是典型的跨轮任务，例子仅用于理解时间尺度冲突，不附加论文之外的数值效果。

已有路线各自解决了什么，还缺哪块协调层？

论文把相关工作分成两条线。第一条是语音交互的轮流与全双工，研究回应时机与重叠语音，以及可同时听与说的模型与评测。第二条是语言智能体的推理与协作，包括带环境反馈的推理、多智能体对话与并行工具执行。在此基础上，论文点名了几类异步语音系统的具体做法，例如支持异步函数调用的实时语音接口，把语音前台与推理执行委托给后台的系统，以及在说话过程中做后台推理与工具使用的扩展思考模型。

这些系统各自实现了对话中执行或后台推理，但论文认为缺少一层公共协调层来接入不同的前台模型与后台执行系统。教学上可以这样定位：如果输入相同、目标都是边说边做，已有工作多是特定产品接口内的异步能力，而本文要做的是与提供方无关的编排运行时，统一管理任务状态、用户输入请求、授权请求与结果回送。

论文用能力对比说明差异，强调跨提供方前台支持、可扩展后台、任务生命周期管理、环境事件扩展与跨会话持久记忆等维度，但对比细节以原文表格为准，这里不转述未给逐字证据的格点数值。

为什么多轮语音任务不能只靠一轮工具调用？

问题来自 3 个真实动作。第一，用户可能在搜索进行中修订请求，任务需要保留已做工作并接纳新约束。第二，用户可能在交易中途补齐缺失条件，后台需要暂停等待输入或授权，再带着原上下文恢复。第三，用户可能询问仍在处理中的文档，系统需要在执行未完成时继续对话，并在完成后找合适时机播报。如果把所有工具调用都放在前台对话循环里，长任务会阻塞回应，短任务又不值得走 1 次重型委托。

如果把打断播报等同于取消任务，用户一插话就会丢掉已执行进度。如果把执行完成等同于立即说话，系统会在用户正说话时抢话。因此论文把要解决的问题定义为在不同时间尺度上协调对话、执行与投递，并明确用编排运行时来承载这种协调，而不是只靠更大的前台模型 1 次生成到位。

前后台加编排运行时如何分工协作？

方法全景可以沿一个样本走一遍。用户说出导航加购物检索的组合请求，前台智能体先理解流式输入并维持全双工对话，然后判断哪部分可直接做、哪部分要委托。直接部分走前台工具，委托部分打包成自包含目标提交给编排运行时，运行时建任务记录并立即返回任务标识，前台继续与用户对话。后台智能体在独立上下文中规划执行，运行时在中间跟踪排队与运行状态、转发进度与待输入请求，并在完成后调度投递。

客户端负责采集输入、播放语音、展示产物并执行本地动作，环境与记忆模块持续给运行时提供上下文。原文把这种安排称为用线束表示连接模型、工具与执行环境的运行时基础设施，关键设计是任务独立于对话轮次管理。

下面这张图是理解分工的主路径，先看前台低延迟环与后台持久执行环如何经由中间运行时连接，再看直接工具与委托工具两条橙色调用链的区别，最后确认异步更新虚线的作用，下文段落会逐个对应到真实组件。

看图路径： 1. 先沿用户到前台智能体再到直接工具的上下两条箭头确认低延迟对话环；2. 再沿 spawn_thinking 到编排运行时再到后台智能体的橙色委托链确认异步路径；3. 对比蓝色对话结果箭头与灰色异步更新虚线箭头确认执行与投递分离；4. 查看底部后台可替换实现列表确认适配器支持多种后台

论文图 1。原论文 Figure 1:：“Foreground–background architecture of Qwen-Audio-Agent.”。

图中上方是前台全双工对话区，包含用户、前台智能体与直接工具有界操作，前台标注对话、工具使用与委托三项职责。中间是编排运行时，标注任务控制、事件路由与结果投递，并强调执行状态与投递状态分离。下方是后台持久执行区，包含后台智能体与工具工作区，后台标注规划、行动、观察与改进的循环，并列出可通过适配器互换的多种实现。左侧环境与记忆以虚线向运行时提供上下文。颜色含义按图例执行，蓝色是对话与工具结果，橙色是工具调用与委托，灰色虚线是异步更新，不能把同色直接当作同一对象。

前台何时直接做，何时交给后台？

前台智能体的具体动作是解释流式输入、维持对话、并在直接工具与后台委托之间选路。直接工具用于即时操作，委托用于需要扩展推理或独立执行环境的任务。两种路径在同一会话内都可用，因此可以在后台工作继续时处理新的即时请求。独立适配器是实现可替换性的关键，前台适配器翻译流式事件与工具调用，后台适配器暴露任务提交、进度、结果与可选控制，原文明示后台适配器可用 Agent Client Protocol、Agent2Agent 或自定义接口，每种适配器声明自己支持的可选控制，例如取消与请求额外用户输入。

前台智能体 × 后台智能体： 前台智能体负责维持全双工对话、低延迟回应和选择直接工具还是委托，后台智能体负责在独立上下文中做多步规划与执行，两者搭配的理由是对话不能被长时间工具调用阻塞，组合后新增的作用是用户可以在后台工作继续时插话、改需求或查进度，而任务状态不丢失。

直接工具调用 × 后台委托： 直接工具调用由前台在对话循环内立即执行，适合有界的即时操作，后台委托通过 spawn_thinking 把自包含目标交给后台异步执行，适合需要扩展推理或独立工作区的长任务，两者搭配是因为单一路经兼顾不了延迟与多步能力，组合后混合执行可以在同一会话内按请求自适应选路。

沿样本继续走，前台提交委托时不会把对话历史与记忆自动搬给后台，而是要求提交包含相关约束与输入引用的自包含目标，这是为了让后台在独立上下文中可执行。运行时创建任务记录并立即用任务标识确认接受，前台据此在后续轮次中查询同一记录。后续工作若依赖 earlier 结果，则作为引用 earlier 结果的新任务提交，而不是直接改写旧任务。这种显式任务记录的做法把对话状态与执行状态解耦，是后文调度投递的前提。

任务跨轮时状态、打断与投递如何控制？

异步协调的核心是任务记录与生命周期。每个任务记录包含目标、状态、进度、输出与待处理请求，公共生命周期区分排队与运行，以及已完成、失败与已取消等终态。当后端支持时，对信息或授权的请求与原始任务保持链接，运行时把用户的回复路由到对应的待处理请求。前端可以在后续轮次查询同一记录，这就是跨轮保持的实现。

下图把跨轮过程画成时间线，阅读时先沿时间轴看前台 4 步，再对照运行时三态，最后落到后台执行条，重点是两个不等式揭示的分离设计。

看图路径： 1. 先沿顶部时间轴从左向右确认委托、继续对话、查进度、投递结果四步顺序；2. 再对照中间编排运行时的排队、运行、已完成待投递三态确认任务跨轮保持；3. 观察底部两条不等式标注确认打断不等于取消、完成不等于投递

论文图 2。原论文 Figure 2:：“Illustrative timeline of a delegated task.”。

图中前台从委托请求任务开始，接着在后台运行时继续对话，随后在 later 轮次引用同一任务查进度，最后在当前上下文中投递结果。中间运行时从排队经运行中跨轮的单任务到已完成待投递，后台从规划到行动到观察再到改进，并在完成时以结果就绪更新运行时。底部明确标注语音打断不等于任务取消，任务完成不等于结果投递。运行时在用户说话或前台回复进行中暂存已完成结果，同一收集窗口内到达的结果合并为 1 次回应请求，前台在当前对话上下文中呈现结果，产物仍与任务链接，投递失败可重试而不重做。

语音打断 × 任务取消： 语音打断指停止当前语音播报以重定向对话，任务取消指终止后台执行状态，两者分工不同，搭配理由是打断播报不应隐含终止未完成工作，组合意义是运行时把两套控制独立转发，用户改口时对话可以转向而后台任务继续保留。

执行完成 × 结果投递： 执行完成指后台任务进入 completed 等终态并产出结果，结果投递指前台在合适对话时机把结果讲给用户，分开的理由是任务可能在用户说话或前台回复中完成，组合后运行时暂存结果并合并同一收集窗口内的完成项，投递失败可重试而不必重做已完成的工作。

需要记住的具体操作是，打断回应只停止语音输出并保留执行状态，取消请求经由后端支持的控制转发，两套控制独立。这使得对话重定向不会隐含终止未完成工作，也使得结果可以在不打断用户说话的条件下保留到合适时机。

环境变化与长期记忆如何进入对话？

环境感知处理独立于语音输入的变化。受支持的客户端提供视觉观察与应用或设备状态，使前台能对照当前环境解释后续请求。论文举的座舱例子是用户通过界面改了目的地，新目的地可静默加入对话上下文而不触发语音回应。客户端还会报告请求动作是否成功，给运行时提供执行反馈。

应用与设备状态变化使用与前台提供方无关的统一事件协议，每种事件类型定义模式、保留规则与回应策略，运行时校验后选择直接处理、静默更新前台上下文、调度回应，或打断当前回应并请求新的回应，前台适配器再翻译成提供方相关消息。记忆方面，会话上下文组合核心交互规则、助手画像、显式用户偏好与长期用户记忆，前台用有界记忆快照构造上下文，远程检索与整合可异步进行。

默认实现支持对话中显式编辑，并在会话边界抽取长期指令与稳定事实，可选学习过程仅在跨会话一致证据支持时加入推断偏好。优先级是当前请求高于存储偏好，显式偏好高于推断偏好，修订检查防止延迟后台更新覆盖新修正，被用户拒绝的偏好不能自动再次加入。这些规则在不改模型参数的条件下调整后续交互的上下文。

环境事件 × 持久记忆： 环境事件提供会话内的外部状态变化，如界面操作或车辆状态更新，持久记忆提供跨会话的用户偏好与稳定事实，前者分工是让后续对话锚定当前环境，后者分工是让后续会话沿用已确认偏好，组合后会话上下文既有实时接地又有长期连续性，且任务记录与参考文档与个人记忆分开存放。

3 类应用对协调提出不同要求，桌面协助是迭代式文件工作，座舱是即时控制加长任务与变化环境，语音客服是政策约束下的审批交易。座舱用共享域服务让前台工具、后台工具与图形界面共用业务状态与执行逻辑，状态变化以环境事件返回。客服用预览加提交序列处理需审批操作，先准备拟议变更并暂停等待前台获取用户决定，批准后恢复并提交，决定与待处理任务链接以保留跨轮执行上下文。

本研究训练了什么，没有训练什么？

本研究没有报告神经网络训练阶段，没有给出损失函数、梯度路径、参数冻结与更新、优化器或训练数据划分，因此不能从模型名称推定训练实现。本文实际做的是系统构造与运行时调用：以前台加后台加编排运行时的线束连接已有模型、工具与执行环境，通过适配器接入不同前台模型与后台智能体，通过任务记录、事件协议与记忆快照实现跨轮计算。

真实计算过程是请求路由、任务排队与调度、环境事件校验与分发、记忆检索与会话边界整合，以及工具执行与结果投递重试。缺项需要明确指出：论文未报告前台与后台模型的训练超参数、微调数据、奖励设计或消融训练，实验节的模型只是作为前后端实例被调用。把无训练等同于确定性求解是错误的，系统输出仍受模型推理、工具反馈与并发时序影响。复现时应把重点放在运行时逻辑与评测协议，而不是寻找训练脚本。

座舱基准测什么，比较条件是否一致？

实验要回答的是执行路由对任务成功与延迟的影响。数据集是自建座舱基准，包含 134 例，其中 86 个短交互与 48 个多步任务，共 159 个用户轮次，所有配置使用相同的 41 个业务工具、初始状态与评测标准。前台统一用语音实时模型，后台用指定的大模型，3 种语音配置输入相同，仅执行路由不同：直接只用前台工具调用，全部委托把业务工具使用都交后台，混合自适应选择两者。另有一个纯文本后台基线接收对应文本并直接执行工具。

评测结合改编的全双工语音评测指标与基于执行的任务成功，强调交互智能体基准中对任务结果的关注。延迟单独在一组轮次上测量，从语音请求结束或文本提交开始，到任务完成结束，不含后续回复生成与播放。延迟评估只用所有配置都成功完成的轮次，共 80 个用户轮次来自 71 例，这种匹配成功轮次的做法控制了任务难度差异，但也意味着延迟结论不覆盖失败轮次。

代码当前可用，已公开的仓库地址是原文给出的开源地址，本次资源状态显示可用，因此可以写当前可用，但评测用的座舱基准与内部指标实现是否随代码公开需以仓库实际内容为准。

混合路由在成功率上赢在哪里，输在哪里？

比较问题是：在相同工具、初始状态与评测标准下，直接、全部委托与混合 3 种可运行路由的任务成功率如何，短任务与多步任务的分项表现是否一致。公平条件是输入相同且工具集合相同，指标方向是任务成功率越高越好，分项完成数越多越好。下表整理原文直接报告的总体成功率与分项完成数，数值与单位保留原文写法，阅读时先看总体再看短任务与多步任务的互补结构。

表后解释需要同时讲收益与代价。混合执行总体成功率最高，直接执行在短任务上完成 83 例但多步仅完成 14 例，全部委托把多步提升到 37 例但短任务回落到 71 例，混合完成 84 个短任务与 38 个多步任务，把即时操作的强项与后台长序列执行能力结合起来。这支持保留两条路径的判断，但也显示未胜出项：直接在多步上明显弱，全部委托在短任务上反而丢分，混合并非在每个子项上都单独最优之外的额外免费午餐，其优势来自按请求选路。

限制是这是内部座舱基准的结果，86 与 48 的划分、工具数量与评测标准都与该场景绑定，能否推广到桌面协助与客服需要另行验证，论文也未报告误判率与统计显著性。

延迟下降是否以牺牲某类任务为代价？

比较问题是：在匹配成功轮次上，混合路由的平均任务执行延迟相对两条单一路由下降多少，短任务与多步任务的延迟结构是否相同。公平条件是只用 4 种配置都成功完成的 80 个用户轮次，测量起点到任务完成且不含回复生成与播放，指标方向是延迟越低越好。下表整理原文直接报告的总体平均延迟与相对下降，单位保留原文的秒与百分比写法。

注：上表直接执行与全部委托的秒数来自原文表格矩阵但缺乏连续原句逐字覆盖，此处仅作构成说明的占位理解，严格可核对的数字以正文引用的总体 4.729 秒与 2 次相对下降为准，延迟分项的短任务与多步任务均值需回原文表格核对。表后解释是混合总体平均延迟最低，相对直接下降 26.73%，相对全部委托下降 30.91%。原文补充在这些轮次上混合把短任务都路由到前台、多步都路由到后台，因此保留了短请求的低延迟，同时相对直接降低了多步延迟。

但反例同样明确：全部委托与纯文本基线在多步轮次上更快，总体趋势不等于每组都成立。未评测边界是失败轮次的延迟、回复生成与播放耗时、以及真实说话重叠下的调度表现，这些都未计入本次延迟定义。

哪些结论有边界，哪些量没有被测量？

论文直接报告的是座舱场景下的成功率与匹配成功轮次上的执行延迟，有限解释是直接工具适合即时操作、后台委托适合多步任务、混合兼顾两者。未验证推测是把该互补性直接推广到所有语音任务，原文未来工作也只提出考察执行期间对话行为、长会话恢复与更广模型与设备的个性化，说明这些尚未验证。

缺失证据不是技术错误，但需要点名：论文未测量打断判断的误判率、结果投递时机的用户体验、记忆推断的错误引入率，以及训练与推理成本、输出帧率与端到端实际延迟的完整分解。相关性不等于因果，混合成功率高可能同时受益于路由策略与前后端模型能力分工，不能单归因于运行时本身。复现时若只看总体成功率会忽略短任务与多步任务的结构差异，若只看匹配成功轮次会忽略失败轮次的代价。

内部基准的工具、状态与评测标准都固定，换场景后路由阈值与事件策略可能需要重调。

要复现混合路由，先做什么，后补什么验证？

复现先做三件事。第一，拉取当前可用的开源仓库，按原文部署编排运行时、前台适配器与后台适配器，先跑通直接工具调用与经由任务标识的委托链，确认前台可在任务排队或运行时继续对话。第二，实现任务记录的最小字段与生命周期，包括目标、状态、进度、输出与待处理请求，以及排队、运行、已完成、失败与已取消，验证打断只停播报不取消执行，完成先暂存再调度投递。

第三，用相同的 41 个业务工具与相同的初始状态构造座舱用例，固定 86 短交互与 48 多步任务的划分与 159 轮次的评测口径，再分别跑直接、全部委托与混合 3 种路由。关键超参数与信息条件是前后端模型选型、工具列表、事件模式与记忆快照边界，原文未给训练超参数，复现应记录模型版本与调用参数。还需补的验证是失败轮次分析、延迟全分布而非仅均值、投递重试次数、以及环境事件静默更新与打断重请求的触发准确性。

区分代码开源与系统可运行：仓库可用不等于基准数据与评测脚本完全公开，缺失部分需按原文描述重建并明确标注为重建口径。

何时值得尝试这种前后台分离？

当任务同时满足 3 条时值得尝试：用户会在执行中插话或补条件，任务包含多步工具调用与等待授权，环境会在对话之外变化。此时保留直接路径处理即时控制，用后台处理长任务，用运行时统一管理任务标识、待输入请求与投递时机，能减少阻塞与丢失进度。反之，若任务都是一轮可完成且无环境变化，引入任务状态与投递调度只会增加复杂度。

对研究生而言，可复述的方法是：前台选路、运行时建记录并返回标识、后台独立执行、运行时转发状态与结果、前台在当前上下文中投递，环境事件按模式与策略进入上下文，记忆按显式优先于推断、当前请求优先于存储偏好的规则更新。本文最强的可核对证据是 134 例上的总体成功率对比与 80 个匹配成功轮次上的平均执行延迟下降，主要代价是需要维护额外的状态机与跨会话记忆规则。

后续若要深入，应补长会话恢复、投递时机的人评与多场景复测，而不是只刷总体成功率。

⚖️ 评分明细

评分属于系统判断，不是论文实验结果；八维数值与总分见页首，原始审计记录保留在后端。

• 评分规则：type-aware-v1

• 评分模型：muse-spark-1.3-contributor

• 评分请求协议：openai_responses

← 返回 2026-09-24 语音/音乐/音频论文速递