低延迟只是及格线：Qwen-Audio-3.1-Realtime 怎么教语音助手想清楚、动手做、知分寸

你开车时对语音助手说：「帮我规划去虹桥的路线。」它开始查。你接着说：「别走高架。」再说：「等我说完你再回我。」查询还没结束，你又改口：「算了，去浦东机场。」

这段几十秒的对话里，助手要做对四件事：理解目标（目的地换了），跟踪执行（上一次查询要作废还是复用），决定要不要开口（你让它等），以及只说有证据的话（路线还没查到，不能先说「好的已经规划好了」）。这四件事没有一件是「响应快」能解决的。

这正是 Qwen-Audio-3.1-Realtime 技术报告（阿里巴巴 Token Foundry，2026 年 9 月）开篇给出的场景。上一代 3.0 解决的是「实时地听和说」，3.1 追问的是：当口语交互变成推理和行动的场景，还缺什么？ 报告的答案是三层：

• Think：让模型在音频上也能推理、跟随多轮指令，智力来源是文本 LLM；
• Act：把口语意图变成可执行、可验证的决策，在真实的工具、数据库和业务规则约束下完成任务；
• Speak and Coordinate：管住「怎么说、何时说、该不该说」。

报告自己也说，Act 是方法论的重心。它花了整整一章讲怎么造训练环境、怎么给奖励排序、怎么在三种粒度上做 GRPO。本文顺着这个重心走，Think 和 Speak 讲清骨架，Act 讲透细节。评测数字放在第五节，第六节讲报告附带的持久语音 Agent 原型（Voice Harness），最后是报告自己划的边界。

先给两个提纲挈领的数字：在 τ-Voice 的半双工语音转文本改编版上，整体任务成功率从 78.4% 提到 82.0%；在 Full-Duplex-Bench v1.5 的「背景有人说话」场景，误响应率从 73.0% 降到 13.0%。前者是「会动手」，后者是「知分寸」。

一、全景：一个循环，三层技术

报告用一张循环图统摄全文：听（Listen）→ 想（Think）→ 做（Act）→ 说（Speak），执行反馈回流到 Think，对话继续回到 Listen。三个技术层分别支撑三个环节：

模型层面，3.1 沿用「Audio Encoder + LLM」的结构，但走两条并行的路：

• 全双工决策模型：预测系统此刻该继续听、开始说、停下还是恢复；
• Speech-to-Text 模型：生成回复内容的文本（报告称之为语义 token）；
• 上下文感知语音渲染器：拿到回复文本，结合对话历史、语音线索和声学上下文，产出流式语音；什么时候开始播、什么时候停，听全双工决策的。

这个「决策与内容分离」的设计值得留意：双工决策走的是一条独立的 Audio Encoder + LLM 路径，而不是塞进内容生成的 token 流里。如果你读过《不是「能被打断」就算全双工》，可以拿那篇综述的「决策在模型栈哪一层做」来对照。报告没有披露参数量、编码器结构、两条路径是否共享权重以及渲染器细节，本文也不猜。

二、Think：把文本模型的智力搬进耳朵里

基础训练的目标一句话：让 AudioLM 既有源文本 LLM 的推理和指令跟随能力，又有文本模型没有的「原生音频能力」（听出情绪、语气、场景）。报告把这个过程分成四个阶段：

2.1 Core-Cocktail SFT：先把语言参数「对齐回去」

起点是一个做过音频预训练的 AudioLM。音频预训练会让它的语言部分偏离原来的文本 LLM，所以第一步不是直接微调，而是以源文本 LLM 为「语言参数锚点」，先做参数调和（parameter reconciliation），把两者共享的语言参数对齐，再做受控 SFT。这是 DrVoice 提出、Fun-Audio-Chat 发展起来的 Core-Cocktail 策略，3.1 沿用。

这一阶段的数据规模是约一百万小时的音频文本配对数据，覆盖通用音频理解、口语指令跟随、多轮交互、面向工具的请求、情感与共情、语用意图、声学场景理解。产出是一个「可用」的音频策略：能听懂、能按指令回答，但推理和工具决策能力还远不如文本模型。

2.2 Multimodality OPD：三个分布，同一个前缀

这是本节的核心机制。OPD 是 on-policy distillation（在线策略蒸馏）：老师不预先写好答案让学生模仿，而是在学生自己采样出来的每一个 token 位置上给出「我会怎么写」的分布。如果你读过《看过答案的自己教没看过答案的自己》，这里的形式完全一样，区别只在老师是谁、看的是什么。

设学生策略为 π_θ，音频输入为 x_a，与之语义等价的文本为 x_t（只在「文本足以表达任务信息」的任务上存在）。学生根据音频采样一条轨迹：

y = (y₁, …, y_J) ~ π_θ(· | x_a)                                   (1)

在位置 j，三个分布同时对着同一个前缀 y<j 给出下一个 token 的预测：

学生      p_θ^(j)   = π_θ(· | x_a, y<j)        条件是音频，被更新的一方
文本老师  q_T^(j)   = q_T(· | x_t, y<j)        条件是等价文本                (2)
音频参考  q_ref^(j) = q_ref(· | x_a, y<j)      条件是音频，参数冻结          (3)

三个角色各管一摊：

• 文本老师 q_T 看的是文本版的题目，但接的是学生用音频写出来的前缀。它负责监督知识、推理、指令跟随和工具决策，也就是文本 LLM 擅长的那些。
• 音频参考 q_ref 是这一阶段开始时从学生复制出来的冻结副本，看的仍是音频。它提供一个「音频条件下的参考」，防止学生在追随文本老师的过程中把音频条件下的行为丢掉。
• 学生 p_θ 同时向两者学。报告的措辞是「两个互补的监督分布」。

报告强调的一点值得反复读：对齐目标是「沿着生成轨迹的行为」，而不是「输入特征的相似度」。传统跨模态对齐常常做的是把音频编码器的输出拉近文本嵌入；这里不动输入侧，只在输出侧要求「同一个前缀之后，你下一步的选择要像文本模型一样」。这和「学生自己采样」结合起来，就是 on-policy 的意义：老师纠正的是学生真会犯的错，而不是老师自己路径上的错。

报告没有给出损失的具体形式（散度种类、两路监督的权重、是否裁剪），下面这段伪代码只是把上面三个式子摆到一起，帮助建立直觉，不是官方实现：

# 示意：Multimodality OPD 的一步。散度 D 与两路权重 λ 报告未披露。
y = sample(student, audio=x_a)                       # 式 (1)：学生自采样
loss = 0
for j in range(len(y)):
    p_student = student(audio=x_a, prefix=y[:j])     # 式 (2) 左侧，带梯度
    q_text    = text_teacher(text=x_t, prefix=y[:j]) # 式 (2)，no_grad
    q_audio   = audio_ref(audio=x_a, prefix=y[:j])   # 式 (3)，no_grad，冻结副本
    loss += D(q_text, p_student) + λ * D(q_audio, p_student)
loss /= len(y)

这条路的适用范围也写得很清楚：只用于「相关任务信息可以用文本表达」的任务。情感、语用意图、声学场景这些「转写里没有的信息」，文本老师无从教起，得靠下一步。

2.3 领域专家与 Multi-Teacher OPD：先分头练，再合成一个

对于转写之外的信息，报告先用领域数据和 GRPO 训练一批音频领域专家：情感与共情、语用意图（说话人的真实意图）、声学场景（非语音事件）。报告明确说这三个只是例子，图里的省略号表示还有别的领域。专家训练本身不把行为合并进主模型。

合并靠第二条 OPD 路径。主 AudioLM 自己生成音频条件下的轨迹，对每个前缀，每一个相关的专家拿到同样的音频上下文，给出逐 token 的分布：

专家 k    q_k^(j) = q_k(· | x_a, y<j)                                   (4)
学生      p_θ^(j) = π_θ(· | x_a, y<j)     由与该领域相关的专家分布监督

和 2.2 的区别只在老师换了：那边是「文本老师 + 音频参考」，这边是「若干音频专家」。两者共享的骨架是「学生自采样 + 老师逐 token 打分」，所以报告把两条路合称 M²-OPD（Multimodality and Multi-Teacher OPD）。所有老师只在后训练阶段出场，推理时只有合并后的主模型。

为什么不直接把专家数据混进 SFT？报告没有做消融，但从设计上能看出取舍：专家是用 GRPO 训出来的，它们的行为是「奖励优化」的结果，而不是某份数据集的样子。要把这种行为搬进主模型，在主模型自己的轨迹上蒸馏，比再造一份 SFT 数据更直接。

三、Act：在可执行的环境里学会动手

这是报告最厚的一章。开宗明义：生成一个合法的函数调用只是第一步。模型还得从语音里认出参数、查记录、要确认、更新数据库、如实汇报。训练流程五步：建环境、验环境、跑模型、判结果、进化任务。

3.1 一个可执行领域由五样东西组成

一个领域（domain）打包五个部件：工具、一个共享数据库、业务策略、任务、验证器。所有工具都作用在同一个数据库上，所以执行效果可以事后核对。工具集里故意混入长得像但无关的工具，模型必须真的选对，而不是「看哪个最显眼就调哪个」。

一个任务只有三种合法的结局：

1. 一次符合策略的状态变更（一次「写」）；
2. 一次有理由的拒绝；
3. 一句说明：「这个请求不支持」。

只有第一种会改数据库。这三种结局的划分很要紧，后面奖励和评测都建立在它上面：拒绝和不支持不是失败，乱写才是。

环境由一个代码 Agent 根据工具定义、服务级的工具集合和任务需求自动构建。这意味着环境是批量生产出来的，随之而来的问题是：造出来的环境本身对不对？

3.2 三道门

每个任务过三道门：

• 静态门：从初始数据库出发，回放一份参考解，检查预期结果、允许的写操作、相关策略条款，以及「用户可见信息」和「内部状态」的边界。过了这道门，说明在当前验证器下这个任务至少存在一个合法解。
• rollout 门：评估模型的一条轨迹。先查数据库结果和所有写操作，再查行为要求（要不要确认、汇报是否属实）。只有当环境、工具轨迹和所有必需的评估器都跑完，才产生裁决。
• 难度门：把任务跑若干次，测量有效通过率，把任务标成「稳定通过」「稳定失败」或「在模型当前能力边界附近」。无效运行重采样，不影响这个标签。

3.3 任务跟着模型一起进化

难度标签决定下一步：

• 模型反复解出的任务：加策略依赖或状态约束，让它变难；
• 模型反复失败的任务：先查环境。环境坏了就修；环境没问题、确实暴露了模型弱点的任务，留作训练数据；
• 边界附近的任务：作为前沿案例保留。

每个新任务都要重新过三道门。反馈在两个层面起作用：任务层面，有用的难度模式被复用来造后续任务，覆盖目标追踪复杂度和交互长度；框架层面，反复出现的构建或验证失败会反过来修改环境模板和验证器。所以这套流水线既改进训练任务，也改进生产任务的系统。

3.4 奖励的固定顺序：流畅的回答不能掩盖错误的执行

这是我认为全报告最值得抄作业的一段。奖励按固定顺序检查：

1. 数据库到达要求的状态了吗？
2. 每一次写都走了允许的路径吗？
3. 行为断言：数据库状态表达不了的要求，比如「提交前先核实信息」「写之前先要确认」「如实汇报执行状态」。断言只记录违规；前提不满足的断言直接跳过。
4. 质量裁判：可以否决一条「完成了写操作但违反交互规则」的轨迹，但不能推翻前两步判定的失败。

工具错误和状态变化直接交给评估器，不从对话文本里推断。这个顺序防止的正是开头那种毛病：模型说得头头是道，数据库里什么都没变，或者变错了。

报告还区分了两种「没成功」：

• 无效 rollout：基础设施故障、轨迹格式畸形、缺少必需的裁决。这类样本重采样，而不是记零分，因为零分会把系统故障当成模型的错来惩罚。
• 有效失败：执行和评估都完成了，但模型违反了任务目标、写策略或行为断言。这类样本作为负例保留，也参与难度估计。

用伪代码把这个顺序写出来（同样是示意，报告没有给出实现）：

# 示意：一条 rollout 的奖励裁决
def judge(rollout, env, task):
    if rollout.infra_failed or rollout.trace_malformed or rollout.missing_verdict:
        return RESAMPLE                          # 无效 rollout：不计分，重采
    if env.db_state != task.required_state:
        return FAIL                              # ① 数据库没到位
    if any(w.path not in task.allowed_paths for w in rollout.writes):
        return FAIL                              # ② 走了不允许的写路径
    violations = [a for a in task.assertions
                  if a.precondition(rollout) and not a.holds(rollout)]
    if violations:
        return FAIL                              # ③ 行为断言：只记违规，前提不满足则跳过
    if quality_judge.rejects(rollout):
        return FAIL                              # ④ 裁判只能否决，不能翻案
    return PASS

3.5 三种粒度的 rollout

GRPO 需要对同一个起点采样一组轨迹、比较好坏（原理见《教会模型「哪个更好」》）。问题是「起点」取在哪。报告用三种粒度，它们共用同一套环境状态、任务规则和验证器，只在比较多少行为、反馈挂在哪一处上不同：

• 对话级：对同一个任务采样若干段完整对话，比较最终结局。它直接训练任务完成和策略合规，难度门用的通过率也来自这里。局限是一个最终奖励看不出是哪一步决策导致的。
• 里程碑级：一条参考工具链定义若干重要的中间状态（里程碑）。到达一个里程碑要求按顺序完成预期的成功调用、带对的参数，失败的调用不算数。rollout 到达某个里程碑时，流水线保存对话和数据库状态，从这个共享点采样多条续写，于是最终回报比较的是「下一步决策」。打分器对「部分轨迹」很谨慎：有些要求已经满足、有些违规已经不可逆、有些义务还挂着、有些条件已经无关，它把这些分开记；对挂着的动作，等到期限再判；对「我已经完成了」这种声明，在它成真之前绝不奖励。
• 轮级：在选定的决策点，模型提出一句话、一次工具调用或两者兼有。局部检查打分：工具选择、参数是否落到了语音里说的内容上、有没有未授权的写、回复质量。保存下来的前缀和数据库状态（包括早先失败的）可以复用来造这类样本，不必重放整段对话。难度靠干扰工具和额外的策略上下文调节。

一个容易忽略的细节：训练前，报告过滤了与评测数据重叠的工具名、对话片段和策略文本。评测那节的 τ-Voice 数字要放在这个前提下读。

3.6 语音条件下的工具调用与检索

前面的环境是文本对话也能跑的。语音带来的额外难点是：口语里的数字、发音相近的名字、否定词，都会影响选工具和填参数。流水线可以把用户的一轮合成为语音送给模型，让这些难点进入训练。报告也坦言合成语音只是匹配了部署时的模态，对真实录音的鲁棒性要另行评估。

检索训练拆成三个决策：要不要搜、发什么查询、怎么根据证据回答。需要搜索的请求会配上不该触发搜索的请求成对训练；时效性相关的加日期上下文；需要搜索时，模型学着发少量互补的查询，再基于真实搜索结果回答。奖励也照这三步拆：工具调用那一轮给「搜索决策 + 查询质量」打分，最后一轮给「忠实、有用、安全、口语表达」打分。查询数量是执行负载和冗余的指标，不直接衡量答案质量或延迟。这个界定和后面 WebSearch1K 的结果读法直接相关。

3.7 调工具之前先说一句，但不能先报喜

真人助理接到任务会先说「好，我查一下」。模型也可以，但不能在任务完成前声称成功。每个工具调用轮被标成三类：必须先说一句、不许说、可说可不说；更高层的规则（比如「只在第一次调用前说」）会被转换成这种轮级标签。评估器检查：这句话出现的位置对不对；如果出现了，长度、重复、语言是否一致、有没有泄露实现细节。它还单独识别第一句确认和第一句实质回答。过早的承诺、反复的填充词和不必要的内部细节都会被罚。

报告说这一小节是 Act 和 Speak 的接口：动作层决定做什么，交互层决定怎么汇报进度。

四、Speak and Coordinate：怎么说、何时说、该不该说

对话策略被拆成三个维度，每个维度有不同的训练方式和不同的证据来源。

4.1 怎么说：表达、人设与共情

约束项是长度、风格、角色一致性、情绪得体和口语自然度。训练用 SFT 和 GRPO 训出的专家模型当老师；会话级 rollout 给重复、模板化的追问、对话停滞、长程人设漂移打分；确定性过滤器兜住截断、极端长度、重复开头和异常字符。奖励是长度中性的，也不奖励「命中人设关键词」，这两条都是防止模型学会取巧。

共情这一块强调听音频才有的线索：犹豫、疲惫、哭腔。目标是「用得上这些线索」，而不是「机械地复述每一个听到的属性」（「我听出你有点累」说一次是共情，每句都说是骚扰）。

评测按场景切片：信息查询、技能控制、指令与风格控制、日常闲聊，因为它们对回复策略的要求不一样。

4.2 何时说：等待、让位与恢复

双工决策策略是一个条件在三样东西上的函数：

a_t = π( o≤t , h≤t , s_t )                                          (5)

o≤t  到时刻 t 为止的流式音频
h≤t  对话与交互事件历史（可含临时约定，如「等我说完再答」）
s_t  当前系统状态（是否正在播放、是否在执行工具）

动作空间四个：继续听、开始回答、停止播放、打断后恢复。

两条设计原则：

• 优先级：运行时的用户约定 > 静态场景策略 > 默认行为。「等我说完再答」这种临时约定进入历史 h，就能压过「用户停顿即回答」的默认。
• 不同的声音要不同的对待：附和（「嗯嗯」）、对旁人说话、真正的打断，各需要不同的响应。而且，「停止播放」和「要不要回答」是两个独立的决策：听到声音先停下，与停下之后是否接话，分开判。所以评测里把接管、打断响应与恢复、附和响应、「对别人说话时」的响应分别记成不同的策略错误。

4.3 该不该说：能力边界与权限

策略要在五个选项里选：直接回答、调工具、要求澄清或确认、拒绝、保持沉默。决定因素是工具触发条件、不确定性、验证需求和能力边界。能力边界评测检查的是「每条回复是否与一份固定的能力配置一致」，它不证明某项能力真的可用。

报告在这里放了一句我想原文引用的话：

A spoken promise is neither proof of execution nor an authorization token.

一句口头承诺既不是执行完成的证明，也不是授权凭证。模型学会的「遵守策略」，必须和工具与运行时强制执行的「权限」区分开。前者是训练出来的倾向，后者是系统保证。这句话也解释了为什么第六节的 Voice Harness 要把权限请求挂在任务记录上由运行时处理，而不是让模型「说了算」。

报告还给了一张「策略到证据」的映射：「怎么说」由人设、共情和 VoiceChat 评测支撑；「何时说」由停顿处理、轮次交接、打断、附和、旁人说话、多方交互和语义控制支撑；「该不该说」由工具决策、可靠性与安全测试、细粒度安全和一个 50 会话的人工红队研究支撑。它也承认：更大规模的人工研究和长程可执行口语任务评测还是未来工作。

五、评测：数字怎么读

报告用到的三十多个测试集各自测什么、题长什么样、分怎么算，我另写了一篇逐个拆解；这一节只讲怎么读数字。

5.1 先看协议

报告在评测前先写了一节「证据范围」，这几条读数字时要带着：

• S2T 与 S2S：S2T 是语音输入、文本输出；S2S 是语音进语音出。除非注明，评测用 S2T；Full-Duplex-Bench 系列和 EVA-A 用 S2S。
• τ-Voice 用的是半双工 S2T 改编版，不能和官方的全双工 S2S 协议直接比。
• GPT-Realtime-2 用 low-effort 设置。
• 加粗只表示「所示比较里最好」，不表示统计显著；发布级比较不能隔离单个训练组件；所有比较都是描述性的。

5.2 智力：通用、多语言、听写、长上下文

AMC（Audio MultiChallenge）用 GPT-4o-mini 当裁判，因为官方的 o4-mini 裁判不可用，所以这列数字不能和官方结果比。从 3.0 到 3.1，通用能力基本持平，多轮指令跟随（AMC、MultiChallenge）涨得明显。

多语言这一项报告做了件有意思的事：把 Big Bench Audio 翻译成 13 种语言，做成 14 语评测。3.1 的宏平均从 81.7 涨到 88.1，涨幅最大的是阿拉伯语（52.5 → 79.1）、泰语（51.5 → 79.0）和越南语（61.5 → 79.2）。

听写和音频理解：

FLEURS 是 14 种语言的宏平均词错率，从 9.01 降到 3.98，和上面的多语言推理涨幅是一致的。MMAU 略降（82.21 → 81.60），报告没有解释。

长上下文：LongBench v2 从 43.14 到 49.90，MiniLongBench 从 55.70 到 60.10，内部的 Long-AMC 从 44.44 到 52.48；长上下文版 VoiceChat-L 基本持平（4.61 与 4.58，1 到 5 分制）。

5.3 行动：工具调用与检索

τ-Voice 是零售、航空、电信三个领域的落地任务（再提醒一次：半双工 S2T 改编版）。航空领域涨了 10 个点，这类任务恰好是「策略多、要确认、要查记录」的典型，和第三节的训练目标对得上。EVA-A 的 Pass 涨了、Mean 降了，报告只列了数字，配置也和公开版略有不同（覆盖 213 个会话中的 200 个）。

检索触发这一项最能体现「奖励设计决定行为」：

WebSearch1K 是 1000 条单轮样本、其中 99 条真的需要搜索的内部评测，只看「要不要搜、搜什么」，不执行检索也不给最终答案打分。预设的工作区间是「调用率 10% 到 20%、F1 约 60%」。3.1 的平均查询数从 4.37 降到 1.05，降了 76%，F1 掉了 2.26 个点，调用率仍在区间内。回到 3.6 节的界定：查询数衡量的是执行负载，不是答案质量，所以这个结果是「用更少的查询保住了触发精度」，而不是「搜得更准了」。

5.4 交互：人设、共情、闲聊与全双工

人设与共情（1 到 5 分）：

人设类 SeedDuplex 领先三项，共情类 3.1 四项全领先。共情评测用的是统一的高共情人设，所以测的是「这个角色约束下的行为」，不是所有人设。

VoiceChat 是 218 段中文对话、2706 轮的内部评测，Qwen-Plus 当裁判。总分上 3.1 的 Spoken 4.100、Rubric 0.961 是所示系统里最高的。但报告特意指出一个要两列一起读的现象：日常闲聊切片的 Spoken 从 4.016 降到 3.965，Rubric 却从 0.955 升到 0.965；人设互动切片同样是 Spoken 降、Rubric 升。同时每轮平均字数从 58 降到 53 个汉字，技能控制从 45 降到 36。报告的态度是：回复长度只是描述性的，更短不代表更好。

全双工是这一版变化最大的地方。Full-Duplex-Bench v1.5 上两个场景的四个指标：

背景说话的误响应率从 0.73 降到 0.13，恢复率从 0.26 升到 0.87；对旁人说话的误响应率从 0.13 降到 0.03，恢复率从 0.82 升到 0.96。这两个场景考的正是 4.2 节说的「不同的声音要不同的对待」。

其他几项：

• 用户打断：响应率 0.845、恢复率 0.13（3.0 是 0.88 和 0.035），不确定和未知都是 0.005 和 0.02 级别。
• 用户附和：响应率 0.0306、恢复率 0.9694，不确定和未知都是 0，响应延迟 1.70 秒是所示系统里最低的。
• 停顿处理：合成集的接管率 0.0073 和 3.0 持平，Candor 真实对话集从 0.1100 降到 0.0509。
• FDB v3.0（带工具调用的全双工）：填充词率从 0.759 降到 0.296，接话准确率 0.99，打断错误率 0.111；但工具选择（0.937）和参数准确率（0.626）不如 SeedDuplex（0.976 和 0.726）。
• 内部 Qwen-Audio-FDB：多方交互的会话级通过率从 0.08 到 0.96，语义控制（用户指定的交互协议，如「等我说完再答」）从 0.07 到 0.68；点级通过率分别是 0.9943 和 0.8930。会话级要求会话里所有判定点都通过，所以比点级严得多。

5.5 可靠性与安全

多轮攻击成功率是内部的 200 会话集，中文从 80.5% 降到 26.0%，英文从 63.5% 降到 23.5%。十个风险类别的细粒度安全通过率里，3.1 有九个高于 GPT-Realtime-2，涨幅最大的是「拟人化与情感依赖」（高 14.93 个点）、「仇恨与辱骂」（14.19）、「虚假与误导信息」（11.77）和「心理健康危机」（10.94）；唯一低的一类是成人内容，低 0.90 个点。五位测试者、50 个多轮会话的人工红队里，3.1 的会话级安全通过率 92%，GPT-Realtime-2 是 96%。报告也强调：这些分数不衡量运行时强制执行的授权保证。

六、从实时模型到持久语音 Agent：Voice Harness

报告第七节讲的东西和前面不是一回事，先把定位说清楚：Voice Harness 是一个独立的系统原型，前台用的是 Qwen-Audio-3.0-Realtime，不是对 3.1 模型的评测。它的前后台分离设计来自开源的 Qwen-Audio-Agent，我之前在《让 Agent 一边说话，一边干活》里从源码层面拆过那个运行时，这里只讲报告新增的部分。

核心还是三段：前台负责解释流式输入、选工具、维持对话、表达结果；短动作直接做，长任务提交给编排运行时，得到一个「已接受」事件后继续聊；后台 Agent 用自己的工具和环境干多步的活，进度、追问、权限请求和最终结果都挂在原始任务上。划分标准是任务需要什么，不是工具调用的次数：查设备状态留前台，处理文档、跑代码、探索环境交后台。

几个被刻意区分开的语义：

• 接受事件只记录提交成功，不表示执行已开始或完成。任务经 queued、running 到 completed、failed 或 cancelled。
• 语音打断 ≠ 取消任务：打断只停当前的回复，取消需要显式的控制事件并由执行器确认。
• 任务完成 ≠ 结果送达：产出可以等一个合适的对话时机再播；播报被打断也不会让已完成的工作作废。

路由评测在内部的 134 个驾驶舱任务上做（86 个短任务或依赖上下文的交互，48 个带规划约束和环境反馈的多步任务）：

混合路由的任务成功率 91.04%，比「全在前台」高 18.66 个点，比「全部委托」高 10.45 个点，接近纯文本后台的 90.30%，同时保留了语音输入。延迟在一个 71 案例、80 个工具请求轮的共同成功子集上测：短任务 1.591 秒（前台直连是 1.488 秒），多步任务 43.430 秒（前台直连 67.705 秒）。报告的注脚要看：多步子集只有 6 轮，没有重复种子的显著性检验，回复裁判和后台执行器是同一模型家族，并且这个基准用合成语音、模拟业务工具和直接的委托接口，不衡量图中那套正式的异步生命周期。

记忆与画像分四层，冲突按固定顺序解决：核心交互规则 > 用户当前的显式请求 > 存储的偏好 > 助手画像。长期记忆只提供事实上下文，不参与这个指令序列；用户当前说的话覆盖旧记忆。这个结构是为了防止「人设或记忆里的内容」压过工具、权限和安全规则。偏好与记忆放在一个可替换的提供者后面，只暴露 read、append、replace 三个原子操作；写入经过运行时，做版本检查防止静默覆盖，拒绝存入类似凭证的内容；提示词路径只读本地快照，不等远程 I/O。画像学习在会话之后跑，只有多个会话都有证据的属性才会更新，且下个会话才生效。

七、报告自己划的边界

报告第八节的自我批评相当坦率，摘几条对读者最要紧的：

• 证据覆盖不均。「怎么说」「何时说」「该不该说」三个维度的评测密度不同；全双工评测混合了公开基准和受控的内部集，真实录音和部署条件下的覆盖还不够；τ-Voice 用了半双工改编版；EVA-A 只覆盖 200 个会话。
• 没有消融。无法把提升归因到 Core-Cocktail SFT、哪条 OPD 路径、环境进化或 rollout 粒度中的任何一个；也没有置信区间、重复种子测试和污染分析。
• 持久 Agent 的证据来自 3.0 前台的原型，端到端评测 3.1 模型和正式的异步生命周期还没做；运行时的记忆、权限和任务状态机制需要模型合规之外的验证。
• 未来工作：真实录音的全双工测试、长程可执行口语任务、更大规模的人工安全研究、端到端延迟与成本。

八、读完这份报告，我记住的三件事

第一，语音 Agent 的智力是搬来的，耳朵是自己长的。 M²-OPD 把两种监督放在同一条学生轨迹上：文本老师教推理和工具决策，音频专家教情绪和场景，而学生始终只看音频。对齐的是「同一前缀之后你会怎么选」，不是「你的表示像不像文本」。

第二，奖励有先后，裁判只能否决。 数据库状态先于写路径，写路径先于行为断言，质量裁判排最后而且不能翻案。无效 rollout 重采样而不给零分。这套顺序的目的只有一个：别让一段流畅的话掩盖一次错误的执行。「口头承诺既不是执行证明，也不是授权凭证」，这句话值得贴在每个做语音 Agent 的人的显示器上。

第三，「说」是三个决策，不是一个。 怎么说看人设与共情，何时说看双工策略和优先级（用户的临时约定压过默认行为），该不该说看能力边界和权限。三者各有各的证据，评测也要按维度分开读。3.1 在「何时说」上进步最大：背景说话的误响应从 73% 降到 13%；在「怎么说」上有取舍：闲聊更简洁了，主观分反而略降。

至于开头那段导航对话，报告没有给出它的端到端评测。它给出的是一套让这类对话可以被训练、可以被验证的方法，以及一份诚实的「还没做」清单。

参考

• Alibaba Token Foundry. Qwen-Audio-3.1-Realtime: Towards Reliable Agentic Voice Interaction. Technical Report, 2026. 本文所有数字与机制均出自此报告。
• Tongyi Fun Team et al. Fun-Audio-Chat Technical Report. 2025. Core-Cocktail 后训练策略的来源。
• Tan et al. DrVoice: Parallel Speech-Text Voice Conversation Model via Dual-Resolution Speech Representations. 2025.
• Kevin Lu. On-Policy Distillation. Thinking Machines Lab, 2025. 报告引用的 OPD 定义。
• Shao et al. DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models. 2024. GRPO 的出处。
• QwenAudio Team. Qwen-Audio-Agent. GitHub, 2026. Voice Harness 前后台分离设计的来源。
• Ray et al. τ-Voice: Benchmarking Full-Duplex Voice Agents on Real-World Domains. 2026.
• Lin et al. Full-Duplex-Bench（2025）与 Full-Duplex-Bench-v3（2026）。
• Bogavelli et al. EVA-Bench: A New End-to-End Framework for Evaluating Voice Agents. 2026.
• Gosai et al. Audio MultiChallenge. 2025.
• 本站相关文章：《不是「能被打断」就算全双工》、《看过答案的自己教没看过答案的自己：OPSD 在线自蒸馏》、《教会模型「哪个更好」：PPO、DPO、GRPO 与 GSPO》、《让 Agent 一边说话，一边干活：拆解 qwen-audio-agent》。