全双工语音模型精读⑤：Gander 论文精读——腾讯混元的全双工语音智能体，如何把"实时对话"和"长任务干活"缝进一个模型

全双工语音模型系列精读第 5 篇。本文逐节解读《Omni Interaction Agent Technical Report》（Gander，arXiv:2609.08977v2，2026 年 9 月 9 日）。该研究由**腾讯混元语音团队（Hunyuan Speech Team, Tencent）**完成，合作方包括浙江大学、上海交通大学、香港中文大学、南洋理工大学，模型、代码、数据全开源。文中所有数字、架构与评测均来自论文原文。配套总览见《全双工语音大模型全景调研》；系列前四篇为 Moshi、Freeze-Omni、GLM-4-Voice、Qwen3-Omni，后续第 6 篇讲阿里 Qwen3.5-Omni Realtime。

一、为什么这篇值得单独精读

前阵子我写过一篇《全双工语音大模型全景调研》，把 Gander 放进了"小脑-大脑"这一路线里。这篇技术报告发布 v2 后，信息密度远超当时能拿到的项目页——它不只是"又一个能打断的语音模型"，而是第一次把两件原本平行的事端到端缝进了同一个模型：

1. 全双工实时语音/视频对话——能边听边说、被随时打断、会用"嗯""对"附和、能在噪声和多人场景里分清"这话是不是对我说的"；
2. 智能体长任务执行——能调用工具、写代码、操作文件，在后台跑几分钟的任务时，你还能随时插话改需求、问进度。

更难得的是，这篇报告的实验态度：它没有只报喜不报忧，而是直接把自己最大的短板（任务精度垫底）摆出来，再用一个消融实验证明"短板不在架构、在可优化的链路"。这种写法比堆 SOTA 分数有参考价值得多。

二、两个根本问题：全文的钥匙

论文开篇把动机归成两问，后面所有设计都是在回答它们。

问题一：真正的交互能力，能靠拼装传统模块（VAD 语音检测 + ASR 语音识别）实现吗？

作者的答案是不能。传统语音助手靠外置 VAD 判断"用户说完没"，本质是一个声学开关。但真实对话里充满了犹豫、停顿、打断、重叠说话、背景噪声、多人交谈、附和（backchannel）。论文指出：这些行为无法靠一堆独立设计的模块可靠捕捉，更重要的是，交互性应该是模型内生的能力，这样它才能随底层智能一起 scale。

问题二：一个模型能同时做到"实时对话的低延迟"和"复杂任务的长程推理"吗？

作者的答案是不该用一个单体模型硬扛。闲聊要求即时响应、持续适配语境；复杂工作流要求长程推理、迭代规划、工具调用、持续执行。让一个模型同时满足，必然在"反应快"和"脑子好"之间产生内在权衡。所以要解耦。

Gander 就是对这两问的答卷：一个端到端模型，统一全模态感知（音/视/文）+ 实时全双工交互 + 智能体长任务。

三、总体架构：小脑 — 编排运行时 — 大脑

系统由三个组件构成（论文 Figure 2）。

3.1 前端小脑（Front Cerebellum）

• 一个实时全双工多模态模型，约 9B 参数，基座是 MiniCPM-o 4.5（论文 Table 5 明确写"MiniCPM-o 4.5 is Gander's base model"），采用 Thinker-Talker 架构；
• 持续接收流式语音、摄像头、屏幕输入，自回归决定每个时刻的动作：听、说、简短附和、被打断、调用工具；
• 日常闲聊、信息查询、简单搜索它自己就能处理；同时承担任务路由——判断当前请求能否本地解决，还是要委派给后端大脑。

3.2 后端大脑（Back Brain）

• 一个通用任务执行智能体，不需要任何任务专属训练（training-free）、即插即用；
• 论文实现默认用 Codex app server（评测时由 GPT-5.6 驱动），也可替换为 Claude Code 这类通用编码智能体；
• 负责长程任务：信息检索、代码/文件操作、文档处理等工具化工作流；
• 这是整个设计里最聪明的一步：大脑可替换且免训练，意味着以后换上更强的推理模型（更新的 GPT、Claude），整个系统的智能上限自动水涨船高，不用重训交互模型。这就是"实时交互"和"智能水平"能同时 scale 的关键路径。
• 大脑除了自带的文件、命令行、检索工具，还能调三个运行时专属接口：
  • context_fetch：按引用、角色、事件类型、时间范围拉取当前任务的实时上下文、事件和产物；
  • memory_search：检索跨会话的持久多模态记忆；
  • share：把验证过的重要发现、中间进度或纠正信息主动推回给前端小脑。

3.3 智能体编排运行时（Agent Orchestration Runtime）

夹在小脑和大脑之间的协调层，负责音视频流接入、增量推理调度、模型调用序列化、静态前缀缓存、按来源限流等。一个关键的安全设计：它会把小脑发出的工具调用绑定到传输层确认过的真实用户话轮上，确保任务目标始终来自"被认证的用户输入"，而不是小脑自己凭空生成的工具参数。

它有两种控制模式：

• lean（精简）模式：运行时直接执行小脑分类好的动作，用原始用户话轮作为给大脑的指令。控制路径短、额外延迟低、确定性强，适合小脑路由可靠的场景；缺点是任务配置在部署时就基本定死，难以按任务语义动态调整推理强度、监督策略。
• coordinator（协调器）模式：在小脑和网关之间插入一个独立的"控制面模型"，基于可信用户请求和受限系统状态，生成声明式执行指令（推理强度、提问策略、权限策略、结果投递策略）。代价是多一次模型调用、增加延迟和不确定性。coordinator 只出计划，不执行任务、不碰文件/shell/网络，其输出还要交给 Gateway（运行时核心控制组件）做结构化校验。当前实现里 coordinator 主要参与 task_start，task_send 和 task_resolve 由 Gateway 直接处理。

Gateway 围绕五个持久实体组织后端执行：Project（长任务容器）、Task（用户目标）、Run（一次具体执行）、WorkerEvent（worker 执行中发出的事件）、Delivery（结果投递机制与记录），并管理任务状态转移、worker 调度、工作区隔离、并发控制、权限处理。不同大脑通过统一的 Worker Provider 接口接入；默认大脑用 Codex，每条任务线对应一个持久 Codex 线程，用户追加指令可直接注入活动线程，只读旁支查询则在隔离 fork 里执行。

3.4 小脑如何调大脑：三个结构化工具调用

小脑通过特殊 token 包裹的结构化工具调用来表达任务级决策，接口定义了三个操作：

• task_start：初始化一个后台任务并关联当前用户话轮，任务描述/名称作为后续生命周期管理的标识；
• task_send：把用户后续输入路由给已有任务，支持增量补充和动态修改。两种路由模式：main（把新输入并入主任务的活动执行上下文）和 fork（实例化一个只读旁支查询，不改变主任务状态和执行轨迹）；
• task_resolve：对任务生命周期做确定性控制，四个动作——cancel（终止主任务）、allow_once（一次性授权当前操作）、allow_session（授权整个任务会话）、deny（拒绝并阻断）。

这就实现了论文主打的场景（Figure 3）：大脑在后台跑长任务的同时，用户可以继续和小脑闲聊，或者用 task_send 随时修改之前下达的任务，两条线互不干扰。

四、前端小脑内部：流式 Thinker-Talker 与分块展平

这是"交互内生"的技术核心（Figure 4）。

4.1 全模态感知：两路编码器并行

• 视觉通路：为了在实时约束下吃进任意宽高比/分辨率的画面又控制 token 预算，采用任意分辨率切分方案——每帧先切成若干 slice，每片独立过 SigLIP 视觉 Transformer，再用 query-based resampler 把 patch 特征压缩成每片固定少量视觉 token。相比原始 patch 网格约 16 倍压缩（比许多前代 omni 模型的 4 倍激进得多），实时分辨率上限 448×448，保证连续感知不掉帧。
• 听觉通路：流式分块语音编码器（Whisper 式）输出约 50 帧/秒的帧级特征，直接喂主干会撑爆序列长度；于是插一个轻量 MLP 投影器做 5 倍时间下采样，把有效音频 token 率降到约 10 token/秒，既保留音素和韵律线索，又与主干解码吞吐匹配。

两路都不等完整片段/话轮，而是在固定时长窗口上增量产出，让视觉和听觉观察在流式交互的每一步都持续刷新到主干。

4.2 Streaming Chunk Flattening：全文最巧妙的设计

为了让小脑在同一个自回归过程里既感知又回应，Gander 采用"展平交互"建模：

• 把连续交互切成固定 1 秒一个窗口，每个窗口 = 一个 chunk；
• 每个 chunk 是三段时间对齐内容的拼接：这 1 秒内观测到的音视频感知 token + 一个控制 token + 模型选择吐出的 N 个文本 token（N 由模型决定，可以为 0）；
• 连续 chunk 串成一条因果序列喂给标准语言主干。用户请求不再是"门控生成"的特殊对话角色，而是模型持续观测的世界状态的一部分——模型身处一个"永远在线"的环境里，每个 chunk 不仅要决定"产出什么"，还要决定"是否、何时产出"。

每个 chunk 开头先预测一个控制 token，三选一：

• listen：本窗口保持沉默、继续观察，输出段不带文本；
• speak：本窗口开口说话，后续 N 个文本 token 送去语音合成；
• interrupt：当语境变化（用户开始说话、或场景变化让当前回答过时）时，中止自己正在说的话。

先决定"说不说"、再决定"说什么"，把这两件事解耦，论文发现这样比把两者缠在一个预测步里能得到更稳定的全双工行为。感知段和生成段之间显式标注边界，也帮模型区分"观测到的输入"和"自己的输出"，稳定流式解码。

上下文管理用固定 128 个 chunk 的预算，对应约 2 分钟的滚动时间感受野。对话进行时窗口滑动推进，预算满了就淘汰最旧 chunk，使每步推理成本在任意长会话中保持稳定，防止展平序列无限增长。因为模型每个窗口都做一次决策，主动开口/打断自然涌现，完全不需要外部 VAD 来触发响应。

4.3 语音生成：主干不出声，交给两个轻量解码器

Gander 不让语言主干直接吐声学 token——语音帧率远高于文本，强行让主干自回归语音 token，既会让每秒解码步数爆炸，又会侵蚀模型的核心语言能力。因此把语义规划和声学实现解耦：

1. speech token decoder：取主干最后一层隐状态，经投影层整形、与文本 token 一起注入一个小型自回归解码器，产出离散语音 token（CosyVoice 式的监督语义 token，单码本、低码率，适合自回归预测）。韵律和风格决策实际上已预编码在主干隐状态里，语音解码器只需专注细粒度声学建模；
2. 流式 flow matching decoder：把离散语音 token 通过条件 flow matching 目标重建成 mel 频谱、再渲染成波形。这同时带来零样本音色控制——合成语音的音色和说话人身份由参考音决定，而非训练时固定。

解码器以 chunk-wise、因果方式运行，语音 token 一到就增量产出波形块，而不是等整句解码完，端到端延迟低、音频可连续播放——这正是全双工的前提。

五、数据：270 万条，专门为"交互"而造

传统 turn-based 语料天然没有打断和重叠，Gander 自建了四大类数据（论文 Table 2，总计约 2.7M）：

几个值得细看的数据工程细节：

• InteractionSpeech 用专用流水线"显式合成交互行为"，而不是从没有打断的对话语料里假装。先收集 11.2K 个场景/话题种子（覆盖教育、医疗、出行、金融、公共服务、客服等 45 个日常与任务场景），用 DeepSeek-V4-Pro 扩写成 8–18 轮、累计说话时长不超过 96 秒的多轮口语对话（控制在小脑流式上下文内，避免模型被超长独白主导）；
• 严格区分两类交互事件：
  • 竞争性打断（competitive interruption）：用户在助手说完前抢话，助手没说完的部分作为"hidden continuation"在时间轴上与用户语音重叠、但保留为文本却不合成音频——于是模型观测到的声学证据和真实听者完全一致，且后续用户话轮会被校验为"没有复用它本不该听到的信息"；
  • 支持性附和（supportive backchannel）：用户在助手说话时插一句简短确认，助手不让出话轮、继续说。附和有硬性判定门槛：必须嵌在对方话轮内、中文 ≤8 字 / 英文 ≤6 词、且命中词库或被显式标注；带疑问、请求、否定语气的候选会被降级为普通话轮，防止把"真抢话"误标成附和。附和从 266 个中文 + 170 个英文表达、11 个意图类别的双语词库中采样，避免小词库导致的重复"嗯嗯嗯"；
• 只渲染用户声道为音频（声音克隆 TTS），助手话轮以文本占位时间轴，每个话轮分配全局起点、时长、重叠区间，让打断/附和的时点成为显式监督；
• 质量控制分两道：规则门先剔除打断点语言上不合理、重叠段退化、泄露听不到的内容、交互未解决的样本；存活样本再由 LLM 裁判从自然度、助手连贯性、打断合理性、附和合理性四个维度打分，逐项过阈值才保留。最终 260.8K 条对话的打断起点广泛分布在被打断话轮的各处（而非集中在结尾），且多数抢话直接以内容开头而非话语标记，防止模型把打断和少数刻板词汇挂钩；
• 音视频数据取自 JoyAI-VL、LiveCC、Streamo，用 Qwen3.5-297B-A17B 做时间对齐精修，DeepSeek-V4-Pro 把响应长度归一化到平均 8 token/秒（平衡信息量与语音延迟），用户语音用 Qwen3-TTS 合成，产出约 1.1M 高质量对；
• omni 智能体数据的 GUI/视频轨迹来自三个来源：爬取的交互轨迹、现有 GUI 数据集、以及用 Codex 生成的 GUI 轨迹，共约 36K，再由 Qwen3.5 大模型转写成环境状态、任务进度、交互上下文的结构化描述；
• 抗干扰和多人场景的负样本直接取自混元工业级生产系统 Hy-Realtime 的真实数据，这是实验室之外很难拿到的资源。

六、实验：赢了时序，输了精度——再用一个消融定位原因

评测沿三个轴展开，作者特别强调三者评分协议和参与组件不同，分数不可横向比较，要分开读。所有结果来自同一个 Gander 检查点，系统提示词与训练时逐字节一致、无基准专属调优；后端大脑（如参与）由免训练的 Codex + GPT-5.6 实例化。

6.1 全双工交互（Full-Duplex-Bench v3，100 个带工具调用的服务场景）

† 该行绕过小脑和语音通道，直接用用户话轮转写驱动同一个 agent，没有音频时间轴，故三项交互指标不可测。

交互时序，Gander 完胜：100 个场景全部在恰当时候接话（仅与级联并列），抢话率仅 8.0%——对比 GPT-Realtime 的 13.5%、最弱基线 Ultravox 的 47.9%。论文反复强调这两个时序指标必须一起读：你可以靠"多等一会儿"把抢话压到极低，但代价是该接话时不接（Gemini Live 3.1 抢话 19.2% 却只有 78% 场景接了话）；反过来，级联系统买了 100% 接话率却付出 33% 抢话率——这正是"外部端点检测仅凭声学静音就判定话轮结束、而语义上用户其实还在想"的典型病症。Gander 两者都没犯，因为它的"要不要说"决策和"说什么"建立在同一个不断演化的表征上，可以等到话语语义上完整、而不仅是声学上安静再开口。它做到这一切只跑一个 9B 模型，正面赢了六个商业/开源系统。

但任务精度，Gander 垫底：Pass@1 只有 0.400，对 GPT-Realtime 的 0.600。

关键在最后那行消融：绕过小脑和语音通道、直接用用户文字转写驱动同一个后端大脑，结果 Pass@1 0.520（高于级联的 0.450）、RespQual 0.740、ToolSel 0.934（工具选择超过表里所有系统，包括 GPT-Realtime 的 0.876）。这说明：

• 后端执行层根本不是瓶颈——同一套 agent + 同一套工具，一旦去掉语音通道，工具选择全场第一；
• 端到端系统与这行之间隔着两个因素：① 复合系统要自己决定何时委派；② 评分是对合成语音做 ASR 转写后打分的（RespQual 从 0.740 掉到 0.490 与此一致，合成和识别错误都被算进了最终分数）。
• 作者的结论很直接：这两点都是训练配方和部署路径的属性，不是架构设计的缺陷，靠改配方就能解决。

唯一不占优的交互指标是 Filler（开口前垫"嗯/那个"）51.6%。作者的解释值得玩味：Filler 衡量的是"拿到话轮到给出答案之间"的间隔，和前两个"何时说"的指标性质不同——当任务被委派给后台大脑执行时，系统不能冷场沉默，占住话轮本身是合理行为，所以这个比率更多反映"有多少活被派给了大脑"，而非交互时序的缺陷。

6.2 口语对话（SpokenQA + VoiceBench，共 2052 条）

在全双机组内，Gander 在两个知识类口语 QA 子集上均第一：Llama Questions 75.60、Web Questions 59.30，领先 Audio-Interaction 8.29 / 4.96 分，领先 Moshi 超过 13 / 33 分；VoiceBench 两个子集组内第二。即便和不受流式约束的 turn-based 模型比，Gander 的 SpokenQA 仍能排到全场第二（Llama Q 仅落后 Baichuan-Omni-1.5 约 2.9 分）。

论文点出这张表的主旨：一个帧同步、边听边决策的模型，在口语事实问答上能追平"听完整句再答"的模型，说明流式分块建模本身并没有牺牲语言主干里保留的知识。 两个偏弱的列（AlpacaEval 开放式长答、SD-QA 口音语音）则暴露了交互训练不提供的东西——交互语料绝大多数是每次吐几个 token 的短对话轮，既不奖励长篇论述，也没拓宽口音覆盖；前者靠加长文响应监督、后者靠拓宽语音口音分布即可补。

一个很能说明设计意图的细节：这 2052 条样本里，后端大脑一次都没被调用，全是小脑独立应答。路由策略只把长程工具活升级给大脑，自包含问答不升级——正是这种"选择性"，让两级设计不至于沦为纯增延迟。

6.3 全模态理解（WorldSense 3172 题 + Daily-Omni 1197 题）

为交互做训练后，理解能力略有回退（WorldSense −6.08）。论文没有回避，还精确定位了原因：

• 视觉塔全程冻结、逐比特未改动，所以回退不可能来自视觉编码退化；
• 两个基准回退幅度差异很大：Daily-Omni（考音视频时间对齐推理）只掉了不到 2 分，WorldSense（考静态画面的计数、定位等细粒度属性）掉了 6 分多。交互语料奖励的是"对共同演化的音视频流做推理"（这能力几乎完整保留），而从不奖励"对静态片段做属性级检查"（代价就落在这里）。论文坦承这是当前的取舍，不做粉饰。

模态消融（Table 6）则证明模型是真融合而非偏科：

音视频同给比最强单模态高出 8.88 分，且视频单模和音频单模成绩彼此接近（WorldSense 差 1.3、Daily-Omni 差 1.6），说明联合条件不是简单抱某条模态的大腿；增益大小还随任务需求变化——考时间对齐、单模态不够用的 Daily-Omni 增益高达 19.13，单模态往往就够的 WorldSense 只增益 5.01。如果模型只是拼接特征，不会出现这种随任务对齐需求而变的增益。

七、局限与未来方向（论文自陈）

1. 数据与模型 scaling：智能体调用和对话行为对训练数据分布仍敏感，尤其复杂 omni 场景；后续会在混元工业级基座 Hy-Realtime 上做系统性放大；
2. 后训练还没上强度：当前 Gander 尚未对长程智能体场景做 on-policy 蒸馏（OPD）或强化学习（RL），奖励设计、信用分配、优化稳定性都是开放问题；小脑-大脑架构还引入了"局部交互质量"与"全局任务目标"如何协调的新课题；
3. 小脑↔大脑通信还很"薄"：目前两组件之间主要靠 ASR 转写的文本信号，未来要探索更丰富、更结构化的双向通信，包括大脑到小脑更好的信息传递、小脑到大脑更有效的反馈；
4. 记忆与长上下文管理：omni 智能体交互涉及长多模态历史、工具调用、不断演化的任务状态，需要能在超长交互中保留和检索任务相关信息的机制；
5. 缺乏统一评测基准：现有基准把 omni 理解、双工交互、智能体执行割裂评测，也几乎不考小脑-大脑协作（组件间通信与协调），面向 omni 交互智能体的统一评测框架仍然缺失。

八、我的几点判断

• 它的真正贡献不是"又一个全双工模型"，而是给出了一套可工程落地的分工范式：反应快、要不停听人说话的小模型（9B）管实时对话；脑子好、但可以慢一点的大模型（GPT-5.6 / Claude 这类，免训练可换）管长任务；中间用编排运行时把权限、状态、缓存、任务生命周期管起来。这套切分天然适配真实产品——你不可能为了每次系统提示词升级都重训一个语音模型。
• "训练-free 后端大脑"是神来之笔，而 6.1 那行 back-brain-only 消融（ToolSel 0.934 全场第一）就是给这个设计的背书：后端智能已经比所有竞品强，端到端分数低，低在"语音转写损耗 + 委派决策"这两件可迭代的事上。这比喊"全栈自研、全链路 SOTA"诚实，也更有说服力。
• chunk 级控制 token（listen/speak/interrupt）+ 128 chunk（约 2 分钟）滑窗，把"什么时候说话"变成和"说什么"同一套自回归过程，是它抢话率全场最低（8%）的根本原因，也正面回答了论文第一问"交互必须内生、不能靠外挂 VAD"。
• 需要清醒看待的：Pass@1 0.400 意味着在"带工具的复杂服务任务"上，它现在还不如 GPT-Realtime（0.600）好用；WorldSense 上静态细粒度感知也有回退。这是一个"交互范式验证成功、任务精度待补"的早期研究系统，不是开箱即用的成品。好在作者把短板都定位到了可优化项（OPD/RL 后训练、拓宽口音与长文监督、丰富双脑通信），方向清楚。
• 对行业的信号：语音交互的竞争正在从"谁的 ASR/TTS 更准"转向"谁能把实时对话和智能体干活无缝缝合"。Gander 选择全开源（模型+代码+数据），并背靠混元 Hy-Realtime 的工业级生产数据，既是学术探索，也像是腾讯在这条路线上的一次技术摊牌。

一手来源

• 论文：Omni Interaction Agent Technical Report（Gander），arXiv:2609.08977v2，2026-09-09 — https://arxiv.org/abs/2609.08977
• 项目主页：https://omni-interaction-gander.github.io/Omni-Interaction-Agent/
• 开源代码：https://github.com/Omni-Interaction-Gander/Omni-Interaction-Agent
• 配套阅读：本博客《全双工语音大模型全景调研（2026年9月）》中"小脑-大脑"路线章节