📄 通话不断线、后台接着干：DuplexAgent 如何协调实时语音与异步任务
英文题目：DuplexAgent-RSI: Recursive Harness Improvement for Full-Duplex Voice Agent Collaboration
标签：#全双工语音交互 | #语音代理规划与工具使用 | #工具增强与约束解码 | #评测协议
评分：7.0/10 | 创新 1.5/2 | 技术严谨 1.2/1.5 | 实验充分 1.2/1.5 | 清晰度 0.8/1 | 影响力 1/1.5 | 开源 0/1.5 | 可复现 0.3/0.5 | 工程/实践 1/1.5
👥 作者与机构
- Yingda Shen：机构信息未在 arXiv HTML 中可靠披露
- Yuxiang Wang：机构信息未在 arXiv HTML 中可靠披露
- Kunyu Feng：机构信息未在 arXiv HTML 中可靠披露
- Qinke Ni：机构信息未在 arXiv HTML 中可靠披露
- Jiaqi Li：机构信息未在 arXiv HTML 中可靠披露
- Minghao Hsu：机构信息未在 arXiv HTML 中可靠披露
- Junan Zhang：机构信息未在 arXiv HTML 中可靠披露
- Dekun Chen：机构信息未在 arXiv HTML 中可靠披露
- Yutong Bian：机构信息未在 arXiv HTML 中可靠披露
- Zhizheng Wu：机构信息未在 arXiv HTML 中可靠披露
📌 核心摘要
全双工语音智能体输入是流式语音波形与交叠的对话事件，输出是适时spoken回复或可执行工具调用，难点在于任务变更、过时结果到达与说话时机三者交织，系统须在保持通话连贯的同时更新目标并舍弃过时工作。DuplexAgent用全双工交互模型守住实时通道，用推理大语言模型与代码智能体组成的委派池做后台搜索、推理与编码，六模块协作harness在两者之间维护任务账本并决定路由、确认、移交与播报。Duplex-Harness-RSI重用服务用户的委派池做改进：考试规划器按归因失败与修复档案选择下一轮定时测试，Harness编辑器修改被诊断点名的模块，配对比较与保护集决定是否保留，使协调能力随证据迭代。与把请求写成一句话标题或自然语言重述的描述式移交不同，该系统传递正式函数模式与完整上下文，并只在当前任务的说话窗口内播报，避免描述替换可执行调用。在BFCL-v3可执行工具使用评测中，Qwen-Realtime附件上DuplexAgent†的BFCL-v3平均分从Qwen-Realtime的82.0%升至90.8%。在MMSU口语知识评测中，同一Qwen-Realtime附件上DuplexAgent†的MMSU准确率从Qwen-Realtime的64.8%升至82.7%。在FDB-v1双工计时评测中，同一附件上DuplexAgent†的打断TOR从Qwen-Realtime的0.89升至0.97。原文未披露训练、推理或部署成本。
🔗 开源与复现资源
本次未形成可展示的已核验资源记录，开放状态尚未核实。
可达状态仅表示本次链接检查结果，不代表许可证、本文权重或运行复现已验证。
🧭 深度解读
实时语音监督长任务时难在哪
这篇论文研究的输入是用户的实时语音流，里面有重叠、犹豫、插话、补充和反悔，目标是让用户一边说话一边监督后台的搜索、推理和代码任务，输出是及时又不打断人的语音回应，同时后台任务的身份、版本和投递时机都被管住。必须保留的信息包括用户当前到底要什么、哪个任务还算数、结果能不能说、什么时候说。
难点在于例子里说的那种情况：用户先要昨晚男足比分，搜索还没回来又改成要女足比分，还可能在旧结果回来瞬间又开口，系统要更新活动目标、作废旧结果、等到合适的说话窗口再说。固定写死的协调器容易另起一个独立搜索，或者把旧结果盖着用户声音说出来，或者取消错任务。读者需要先建立这个判断：连续对话和复杂执行通常是两类模型在做，前者守通话，后者跑长活，中间缺一个能把接受、进展、取消、替换和回送都讲清楚的协作层。
已有全双工与委派路线做了什么
论文把相关工作分成两条线。第一条是全双工语音本身，有端到端和模块化两条做法，解决流式听与说、轮流、插话和伴随性回应，文中提到 Moshi、Freeze-Omni 等模型研究，也提到可控组件与声音语义分离等模块化探索。第二条是把实时通道连到后台计算，例如给 Moshi 加异步检索、把后台工作委派出去、协调异步返回、连接长时执行。
DuplexAgent 沿着第二条路线走，但关注点不同：不是再做一个交接实例，而是把交接、确认和投递控制拆成可诊断、可修改的模块，让同一种失败能定位到委派、任务理解、后台执行还是投递。评测方面，VoiceBench、Full-Duplex-Bench、BFCL 等分别量知识、轮流重叠与结构化函数调用，论文的模拟器则补上显式的任务转换与模块归因，两类分数回答不同问题，需要分开报告，不能互相替代。
论文要解决的具体协作问题
具体问题是异步交接后的控制语义不清。当交互模型把活交给委派池，任务还在跑，用户可能细化需求、替换目标、取消、问进度、同时开新任务、打断正在说的话，后台结果也可能延迟、失败或在用户说话时回来。系统必须决定这一轮是直接答、交出去还是做任务控制，解析控制针对哪个活动任务，等待期间说什么，选哪个委派者并约定结果格式，结果何时说、说成功还是失败，以及对话与后台共享什么上下文。
如果这些决定耦合在各自系统的启发规则里，同一失败反复出现时，轨迹说不清该改哪一块，修补就难以隔离、评估和迁移。论文因此把协作流程写成 6 个可编辑模块，并配一个从交互轨迹出发的闭环，让每次修改都对应到被诊断点名的模块，并在同样的考试与保护集上验证。
系统整体如何分工与流转
部署的系统被写成三元组，交互模型守用户面通道，委派池异步做长活，协作框架管身份、时机与上下文，改进时只改框架、模型权重不动。委派池里做用户任务的推理与代码能力，也被复用为改进循环里的出题与修补角色，所以服务用户的那些能力同时也在改进协调本身。
1 次会话的大致流转是：用户语音进来，框架先判路由，需要后台做的就建任务台账、给确认、把当前目标与上下文交给选定的委派者，用户改主意就改台账并确认变化，后台晚到的过时返回只记录不转正，只有当前任务的结果才在安静窗口经交互模型说出。会话引擎维护任务的接受、运行、完成、投递、取消与替换状态，迟到返回不能让过时任务重新变回当前，适配器把框架决定搬到不同开放或托管实时模型的接口上而不改变含义。
全双工交互模型 × 委派池： 全双工交互模型指一直听和一直说、守在实时通话入口的语音模型，负责轮流、插话和简短回应；委派池指做搜索、推理和代码长任务的推理大语言模型与代码智能体的集合。两者搭配是因为前者响应快但算不动复杂任务，后者算得动但不能同时守电话，组合后由协作框架在两者之间传任务身份、上下文和结果时机。
\[S=(F,B,H),\]\[H=(\mathrm{Policy},\mathrm{Intake},\mathrm{Hold},\mathrm{Worker},\mathrm{Deliver},\mathrm{Memory}).\]下面这组连环画把 1 次替换讲得很直观，读图时先按时间看用户如何从 Snake 改到 Tetris，再看系统何时确认、何时丢弃、何时等待停顿，理解过时结果为何不能说、当前结果为何要等。
看图路径： 1. 按六格顺序跟踪 Snake 从运行到被划掉、Tetris 从运行到等待停顿再到播报；2. 注意 DISCARD 与 WAIT FOR PAUSE 两个标签对应的丢弃过时结果与等说话窗口；3. 观察前台蓝色小机器人与后台紫色机器人的分工位置
论文图 3。原论文 Figure 3:：“A full-duplex collaboration session. The user requests Snake, then cancels it and asks for Tetris while work is running.”。
图中第一格用户请做贪吃蛇游戏，系统说马上做；第二格后台开始跑贪吃蛇，前面保持陪伴回应；第三格用户打断说取消贪吃蛇改做俄罗斯方块，系统确认切换；第四格旧的贪吃蛇结果被标为过时并丢弃；第五格新的俄罗斯方块就绪但标注等待停顿。
第六格用户停下后系统才播报完成。这说明协作不是单步流水线，而是随时间合作的状态机，台账决定什么可投递，投递决定何时开口。
六个模块各自管什么决定
6 个模块每个都有明确的输入、决定和可观察效果，失败才能归到有界范围。下表是原文给出的分工与可改表面，第 1 次看到这些英文名时记住它们管的实际动作，后文都用同一称呼。Policy 管答、委派或任务控制的选择；Intake 管操作含义与针对哪个活动任务；Hold 管等待期间用户听到的确认与进度。
Worker 管选谁做、给什么上下文和结果契约；Deliver 管当前结果何时如何回来；Memory 管对话与后台共享上下文的组装、保留与压缩。
| Module | Collaboration decision | Editable surface |
|---|---|---|
| Policy | Answer, delegate, or task control | Instructions, delegation schema, routing examples |
| Intake | Operation expressed, and which live task | Parsing, control cues, task relations, resolution rules |
| Hold | What the user hears while a task is pending | Receipts, progress timing, control replies |
上表只说明 Policy、Intake、Hold 三行的协作决定与可编辑表面，Policy 改指令与路由示例，Intake 改解析与任务关系规则，Hold 改确认与进度时机。正文另述 Worker 改路由与结果模式，Deliver 改说话窗口与成功失败渲染，Memory 改轮次组装与保留。它的限制是只定义决定归属，不保证 1 次修补只动一个模块，耦合修补仍记为一个保留版本。
Policy × Intake × Worker： Policy 负责决定这一轮是直接回答、发起委派还是做任务控制；Intake 负责解析用户说了什么操作以及它针对当前哪个活动任务；Worker 负责选哪个委派模型去做、带什么上下文和约定什么格式的结果。三者分工是路由、理解任务关系、执行交接，组合起来让直接回答保留口语简洁，让需要工具的请求带着完整参数出去。
Hold × Deliver × Memory： Hold 负责任务等待期间用户听到什么，包括确认收到和进度提示；Deliver 负责结果何时、以何种方式说出，只放当前任务的结果并等用户安静的窗口；Memory 负责对话与后台共享的上下文，保证委派拿到的不是半句话。组合后对话不断、过时结果不出口、上下文不丢。
以 Snake 换 Tetris 为例，Policy 判该委派，Memory 留住目标，Intake 建任务，Hold 确认，Worker 把请求与上下文发给代码智能体；用户改目标后 Intake 对照台账做取消与替换，Memory 更新，Hold 确认变化；晚到的 Snake 只记录；Tetris 就绪后 Deliver 等窗口再经交互模型说出。任何一步错，轨迹里都能看到是任务没更新还是过时结果被投递了，光听 audible 错误不够。
失败如何归因到模块
模拟器跑完后，观察者记录语音活动、转写、委派信号、模块决定、委派返回、任务转换与投递事件，诊断器对照预期行为选一个终因，并按默认映射归到模块，再用中间决定与返回载荷修正。例如委派载荷对但说错了，归投递；没出结果但执行失败，归执行。一轮可能多个信号并存，但只选一个终因供后轮比较。下表是默认归因，感知失败在框架之外，因为交互模型没听清输入就轮不到框架行动。
| Failure family | Default attribution | Trace evidence |
|---|---|---|
| Perception | Outside harness | Requested turn not recovered well enough for the harness to act |
| Routing | Policy | Missed or extra delegation, or a reply to non-directed speech |
| Interpretation | Intake | Malformed request, or control applied to the wrong task |
| Continuity | Hold | Receipts conflict with speech, handoffs repeat, or pending work lacks progress |
上表只列出感知、路由、解释、连续性四行，路由归 Policy、解释归 Intake、连续性归 Hold，感知单独列为框架外。正文归纳执行归 Worker、投递归 Deliver、上下文归 Memory。它的价值是让修补假设可检验，限制是默认映射只是起点，仍需看轨迹修正，同一 audible 错误可能对应任务控制解析错或投递放行了过时结果。
没有训练模型时循环实际改什么
本研究不训练任何模型权重，交互模型与委派池权重全程固定，改的只是框架的指令、配置与可执行覆盖。实际计算过程是仿真与规则修补：出题者离线调考试分布，编辑者在隔离工作区改框架文件，评测器由文件补丁推导改动并拒绝未声明路径，不准改评分规则、不准把模拟器引入框架、不准写针对场景的答案。
6 条不变式也要守住：委派只能源自交互模型，框架不能静音或打断它的语音，接受先于完成，只有当前结果能投递且至多 1 次，结果经交互模型返回，参考答案不进其提示词。循环每轮做计划考试、用现任跑并诊断、提候选、在同考卷上配对比较、过开发门限再过保护集、写修复档案。拒绝就保留现任，多模块联修仍记为一个保留版本。
Exam Planner × Harness Editor × 修复档案： Exam Planner 是由委派池中推理模型担任的出题角色，根据已归因失败和修复档案调整下轮考试的请求类型与交互模式权重；Harness Editor 是由代码智能体担任的修补角色，只改声明过的模块表面；修复档案保存每轮考试计划、轨迹、候选改动与可见 verdict。搭配后考试越考越准，修补不重复踩坑，保留只看配对胜负与保护集。
出题者保留固定核心占比与代表性覆盖，限制新增用例数与采样权重移动幅度，给近期失败分配有限新变体但不永久入库，保护新修行为的用例留在计划里，屡修不好的目标要轮换走，不动评分与保护集。编辑者要定位产生失败的决定、按机制归组、查已试过的改动、给出可检验假设并在候选副本上改，参考可见的评测反馈再细化。经验就是带到下一轮的档案，避免重复失败的改法、累积已有效的修补。
模拟考试与外部基准如何搭建
模拟器把要什么与 handling 时发生什么分开。请求类型定能力与初始路由，交互模式定细化、取消、重叠、延迟等事件。语义预期固定后再加语言与声学变化，所以同一控制操作可跨能力测而不改变评判。题库按 19 种请求类型与 22 种交互模式组织，内容分会话、信息、推理、动作四组，但分组不等于一刀切的委派规则，熟悉事实可直答，闲聊也可能要检索。模式覆盖正常完成、任务控制、并发、全双工重叠、连续与恢复，只有兼容的请求与模式组合才组装。
流水线先生成请求与参考答案及控制轮，质检语义与去重，内容先切分开发、保护、密封集再做时间编排，固定核心每轮重复以便跨轮比较，确定性编排器放时间轴、定委派延迟失败、记必需任务转换与可说窗口，答案检查可用精确、包含、正则、选项字母或语义标准。语音渲染与增强最后把文本变成按实时钟流式播放的音频，说话人、风格、语言、 pace 可变，干净与增强版语义一致。实验用 DeepSeek-v4-flash 生成内容并担任出题者，Codex 担任编辑者，Qwen3-TTS 渲染，VoiceChat 与 Qwen-Realtime 分开做改进活动。
\[\varphi(\tau)=(\mathrm{cause},\mathrm{module},\mathrm{pattern}).\]\[Q=\text{percentage of successes, excluding perception failures}.\]外部评测另用自带输入。口语知识用 VoiceBench 的 OBQA 与 MMSU 口语选择题，解析选项字母；可执行工具用 BFCL-v3 5 个单轮子集与 FDB-v3 自然口吃语音工具评测，前者按函数名与参数打分并报未加权均值，后者看选择 F1、字符级精确参数准确率与全部精确才算过的 Pass@1；双工计时用 FDB-v1 暂停、轮流与打断，暂停 TOR 越低越好表示犹豫时少抢话，轮流与打断 TOR 越高越好。比较时同挂载固定交互模型，跨块还换交互模型。百分比差异按百分点表述。
| Component | Experimental setting |
|---|---|
| Content bank | Content split before temporal composition into development, protection, and sealed sets (60/20/20). |
| Exam Planner | DeepSeek-v4-flash; bounded weights over request types, interaction patterns, and input conditions, with request-coverage floors. |
| Adaptive exam | Fixed core share 40%; fresh-item budget of 30 per round, with weighted sampling of the remaining cases. |
上表是改进实验的配置，内容按 60/20/20 先切分再编排，出题者权重有界且有覆盖下限，自适应考试固定核心占 40% 且每轮新题预算 30。正文另述编辑者每轮三候选至多 2 次细化，开发门要求配对胜多于负加不变式与原因回归容限，保护门在独立保护集上至少胜负相当加不变式。它的限制是这些只是本篇实验设置，换题库规模或预算结论可能变。
协作分数 Q × 失败签名 × 感知失败排除： 失败签名记录一次失败的终因、归属模块和交互模式；协作分数 Q 是满足预期行为的对话占比，但把交互模型没听清输入的感知失败排除，因为那不属于框架修改范围；感知失败排除保证分数只反映协调对错。组合后分数说明修好多少，签名说明该修哪里。
可执行工具调用为何拉开差距
先看总体概览，蓝色 DuplexAgent 在智能、工具与双工 3 类面板上都高于灰色其他协作系统，且协作系统用同一委派大语言模型，说明差距不在换更强的后台，而在交接内容与时机。读图时注意 3 类指标方向都是越高越好，工具侧看 BFCL 并行多调用与 FDB-v3 Pass@1，智能侧看 MMSU，双工侧看 FDB-v1 打断响应。
看图路径： 1. 先看四个面板的指标名与右侧数值：MMSU 准确率、BFCL 并行多调用、FDB-v3 Pass@1、FDB-v1 打断响应；2. 再对比每行蓝色 DuplexAgent 条与灰色其他协作系统的长度差异；3. 注意右上角 Higher is better，确认方向都是越高越好
论文图 1。原论文 Figure 1:：“Benchmark results for DuplexAgent (blue), compared with other collaboration systems (gray).”。
图中左上 MMSU 面板 DuplexAgent 为 82.7，高于 Qwen-Audio-Agent 的 71.8 与 Gander 的 62.7；右上 BFCL 并行多调用面板 DuplexAgent 为 78.0，高于 58.0、22.0 与 0.0；左下 FDB-v3 Pass@1 面板 DuplexAgent 为 49.0，高于 30.0、1.0 与 0.0；右下打断面板 DuplexAgent 为 97.0，高于 92.0、83.0 等。可见口语答案与可执行调用可以分开走，描述式交接能抬前者却可能丢后者。
下面这张宽表回答可执行调用在同挂载下谁把基准函数名与参数真正传过去了，指标方向都是越高越好，比较条件是同一波形、同一模式与同一检查。
| 挂载 | 指标 | 独立交互模型 | DuplexAgent | 变化 |
|---|---|---|---|---|
| VoiceChat 挂载 | BFCL 平均分% | 53.5 | 75.8 | 上升 |
| VoiceChat 挂载 | FDB-v3 三数 F1/参数/Pass@1 | 60.2 / 26.2 / 16.0 | 97.4 / 57.0 / 47.0 | 上升 |
| Qwen-Realtime 挂载 | BFCL 平均分% | 82.0 | 90.8 | 上升 |
| Qwen-Realtime 挂载 | BFCL 并行多调用% | 66.0 | 78.0 | 上升 |
| Qwen-Realtime 挂载 | BFCL 无关项% | 85.0 | 100.0 | 上升 |
| Qwen-Realtime 挂载 | FDB-v3 三数 F1/参数/Pass@1 | 87.0 / 47.8 / 39.0 | 84.8 / 55.0 / 49.0 | F1 略降参数与通过率升 |
这张宽表对比的是同一语音输入下可执行调用的得失，数值上升说明交接保住了函数名与参数，个别回落则对应多找回带来的代价，结论只在这些语音输入、模式与检查下成立。独立交互模型若能绑定基准模式本就有可用分，Moshi 与 MiniCPM-o 无绑定则调用子集为 0.0、只靠空调用在无关项拿 100.0。加后台若只给描述就会替换掉已有的调用：Gander 给的是任务标题，Realtime-Venus 给的是尖括号里的 prose 句，Qwen-Audio-Agent 给的是自然语言重述，MoshiRAG 只检索文本，窄的函数名加参数要求就对不上。
DuplexAgent 把是否委派与交接装什么分开，Worker 拿官方模式与用户轮携带的参数，Memory 留住标题或短重述会丢的标识与约束，Deliver 只在窗口放当前结果，所以 VoiceChat 平均分从 53.5 到 75.8，Qwen-Realtime 从 82.0 到 90.8。代价在 VoiceChat 无关项从 95.0 到 90.0，找回必需调用也带入一些不必要调用；Qwen-Realtime 选择 F1 从 87.0 到 84.8 略降，但参数与通过率更精确。结论只在这些语音输入、模式与检查下成立。
口语知识涨了通话还跟得上吗
这张宽表回答同一交接能否同时抬起口语选择题分数并保住实时性，知识准确率越高越好，暂停 TOR 越低越好，轮流与打断 TOR 越高越好，同挂载比较才公平。
| 挂载 | 指标 | 独立交互模型 | DuplexAgent | 变化 |
|---|---|---|---|---|
| VoiceChat 挂载 | OBQA 准确率% | 54.2 | 80.6 | 上升 |
| VoiceChat 挂载 | MMSU 准确率% | 36.1 | 80.5 | 上升 |
| Qwen-Realtime 挂载 | OBQA 准确率% | 86.3 | 92.1 | 上升 |
| Qwen-Realtime 挂载 | MMSU 准确率% | 64.8 | 82.7 | 上升 |
| VoiceChat 挂载 | 暂停合成/自然与轮流/打断 TOR | 0.162 / 0.343 / 0.983 / 1.000 | 0.117 / 0.241 / 0.961 / 0.965 | 暂停改善轮流打断略降 |
| Qwen-Realtime 挂载 | 暂停合成/自然与轮流/打断 TOR | 0.074 / 0.278 / 0.898 / 0.890 | 0.147 / 0.231 / 0.966 / 0.970 | 合成暂停变差其余改善 |
表后解释另一半规律。描述式交接也能写出更好的口语答案，所以 MoshiRAG、Gander、Qwen-Audio-Agent 在 VoiceChat 上知识分涨而调用分不动或跌，知识与可执行分开走。反例是 Realtime-Venus-Omni，OBQA 从 84.1 掉到 41.4、MMSU 从 64.5 掉到 27.4，因为 transcript 到达评分器时常是委派片段或确认语，选项字母被挤掉，工具也跌，说明后台只有在框架选对路由、装对细节、送对时机才有用。DuplexAgent 直接问题留口语答，工具请求保留可执行调用与参数，OBQA 与 MMSU 在两个挂载都涨，弱交互模型涨更多是因为委派补了它没有的推理。
计时是独立约束，DuplexAgent 基本贴着所挂模型走：VoiceChat 暂停改善但轮流打断略降，Qwen-Realtime 轮流打断涨、自然暂停改善但合成暂停从 0.074 到 0.147 变差。任务变好与某一暂停条件变差可以并存，实时通道仍算灵敏，但不能说延迟全面优化。
诊断加档案比反复改多带来多少
消融在 VoiceChat 固定核心上比较 3 种用同样考试材料的改法，回答修补增益来自多看几遍题还是来自诊断与档案。单次修补把 10 轮材料 pooling 1 次改，顺序修补按原顺序改 10 次但去掉每轮诊断与档案，完整循环每轮做计划、诊断、编辑与两道门限并用档案，报告第 10 轮检查点。左图看协作分数 Q 越高越好，右图看各类诊断失败率越低越好。
看图路径： 1. 左图看协作分数 Q 从 54.6 到 85.3 的阶梯，右图看漏委派从 30.3% 降到 1.3%；2. 对比单次修补 57.4 与顺序修补 61.9，确认诊断加档案带来的额外增益；3. 注意额外委派从 3.9% 升到 6.6%，这是恢复委派的代价
论文图 6。原论文 Figure 6:：“VoiceChat harness ablation on the fixed core.”。
图中左面板 Qwen-Audio-Agent 与初始框架 g0 都是 54.6，单次改到 57.4，顺序改到 61.9，完整循环到 85.3，比 g0 高 30.7 个百分点，比顺序改高 23.4 个百分点；右面板漏委派从 g0 的 30.3% 降到 1.3%，额外委派从 3.9% 升到 6.6%，忽略控制 stays 5.3%，未说出项归零。主要收益是找回漏掉的委派，代价是多一些不必要调用与未解决控制。反复看同样的考卷确实有用，但加上诊断与档案增益大得多，未胜出项是顺序改仍远低于完整循环，说明不是轮数本身。适用条件是固定核心可比、开发与保护门限不变，换题分布结论需重测。
保留版本如何一步步累积
另一条证据在 Qwen-Realtime 上看版本 lineage，回答修补是否在第二个交互模型上同样累积。记号上 g 下标计保留版本数，r 下标计完成轮次数，一轮可不产生新 g。虚线是每轮后固定核心分，含未保留提案所以可跌；实线是已保留最优，只在通过开发与保护门时上台阶，不通过就走平，后期平台是多轮提案未过门。
看图路径： 1. 看横轴 r01 到 r18 轮次与纵轴协作分数 Q，区分虚线本轮评测与实线已保留最优；2. 数 g0 到 g8 八次保留版本对应的台阶位置；3. 注意后期平台期表示多轮未通过门限则保持当前版本不变
论文图 7。原论文 Figure 7:：“Duplex-Harness-RSI on Qwen-Realtime. Retained versions raise the collaboration score on the fixed core from the initial harness g_0 to g_8.”。
图中从 g0 的 47.1 经 8 次保留到 g8 的 84.8，共涨 37.7 个百分点，r01 到 r18 横轴上 g1、g2 等台阶位置清晰，r05、r12 等处虚线回落而实线不动。这与 VoiceChat 消融合起来说明同一机制在两个挂载都累积，且保留只看配对比较支持。限制是每个挂载有各自初始框架与考试序列，不能把 Qwen 的 g8 直接搬到 VoiceChat 用。
下面这张表是每次保留修补背后的规则变化，比较问题是哪个模块的哪条规则改了、本地考试上目标失败降多少，注意这些百分比是测该修补的本地考试，不是固定核心总分。
| Module | Rule before repair | Rule after repair | Recorded local evidence |
|---|---|---|---|
| Policy† | Conversational and familiar-fact turns are routed too broadly. | State the direct-answer categories explicitly, while still delegating requests that need additional capability. | Extra calls reduced by 50%. |
| Intake∗ | A late cancellation can be treated as work that has already completed. | Resolve the cancellation against live task state, and apply the same control handling to replacement preambles. | Ignored cancellations reduced by 81%. Replacements reduced by 65%, then by 83.3%. |
| Hold† | Pending work does not receive a timely progress update. | Report progress earlier, and keep receipts brief and compatible with the adapter. | Missing progress updates reduced by 75%. |
| Worker∗ | Conversions skip the required calculation, or reformulate output that was already verified. | Preserve the requested units and precision, calculate when the request requires it, and retain verified result content. | Wrong answers reduced by 66.7%. |
上表只显示 Policy 把直接回答类别写明后额外调用降 50%，Intake 对照活动任务状态处理晚取消与替换前导后忽略取消降 81%、替换失败先后降 65% 与 83.3%，Hold 提前报进度后缺进度降 75%，Worker 保单位精度与已验证内容后答错降 66.7%。正文另述 Deliver 等用户安静再说并区分执行失败后重叠与掩盖失败都降 100%，Memory 组装完整轮并保留上下文后缺上下文降 60%。它的限制是本地证据，固定核心总分是门限保留后的组合效果。被拒的例子也重要：过宽的投递超时会引入其他语音冲突，过宽的直接回答会漏掉必需委派，开发门因此只留假设窄且配对比较支持的修补。
框架修补到哪里就停住了
论文明确增益止于框架。改的是模块指令与可执行规则，交互模型权重不动，所以修补可以要求安静再说、委派前组装完整问题，但模型对重叠语音的感知与自己判断轮次结束的能力还是原样。门限接受或拒绝候选时，这部分残差仍在轨迹里：观察者已对齐语音、委派与投递，诊断器已命名原因、模块与模式，出题者已把签名变成下轮定时对话。记录因此能说清哪些失败可被模块编辑吸收，哪些留在交互模型自身的感知与时机。
作者提出后续用智能体强化学习把更新从框架延伸到实时时间线上的交互模型，模拟器继续供考试、轨迹与签名。这不是已验证的效果，而是待验证的方向，不能当成现有提升。另一限制是外部比较测的是委派加框架的合效果，框架本身的隔离效果只在模拟器固定核心与保护集上看，两类分数不要混读。
复现第一步与关键条件
值得尝试的时机是已有能听会说的实时模型，但长推理与工具执行跟不上，且用户会在任务运行时改主意、插话或并行开任务，需要把过时结果拦住并等窗口再说。复现第一步不是训模型，而是把会话引擎、适配器与六模块框架搭起来，接一个推理模型与一个代码智能体做委派池，再跑模拟器生成定时对话：先定请求类型与交互模式的兼容组合与预期行为，再做内容生成与确定性时间编排，最后做口语变化、语音渲染与声学增强，按实时钟流式评测。
关键超参数与信息条件按原文保留：内容先切开发、保护、密封再编排，固定核心占比 40% 且每轮重复，每轮新变体预算 30，出题者权重有界，编辑者每轮三候选至多 2 次细化，开发门要配对胜多于负加不变式，保护门在独立集上至少胜负相当，参考答案不进交互模型提示词。来源方面，本次未发现完成 HTTPS 验证的作者资源，不得声称代码模型数据已公开，代码开源、权重可下载、系统可运行要分开确认。
常见误解是把模拟器协作分涨当成外部基准必然涨，或把百分点差读成相对百分比，或把自动指标当人工评价，这些在原文都是分开报告的。
结论在什么条件下才成立
综合看，论文直接报告的是：在 VoiceChat 与 Qwen-Realtime 两个挂载上，保留后的框架让口语知识、可执行工具与固定核心协作分一起涨，同时模型权重保持 campaign 开始时的样子，计时基本贴着所挂模型但个别暂停条件变差，消融显示诊断加档案远超单次与顺序改。证据支持的解释是路由、任务控制、上下文与投递时机的精确化带来了这些涨幅，推测部分是更弱的交互模型更依赖委派补推理。
尚未评测的范围包括密封集之外的开放对话、其他语言与信道、真实用户重叠习惯，以及训练与部署成本、延迟与误判率的系统测量，没有测就不能承诺改善。下一步需补的验证是把同一框架接到更多实时模型与委派组合上重跑外部基准与固定核心，并公开可运行的模拟器与评测脚本以便独立复算。总之，这是一套让协调可定位、可修补、可验证的做法，修的是协作层，不是语音模型本身。
📎 论文与评分元数据
排名：前50% | 文档类型：系统技术报告 | arXiv 原文
⚖️ 评分明细
评分属于系统判断，不是论文实验结果；八维数值与总分见页首，原始审计记录保留在后端。
评分规则：type-aware-v1
评分模型：muse-spark-1.3-contributor
评分请求协议：openai_responses