腾讯做了一只会打断你说话的AI鹅

你有没有遇到过这种情况：跟语音助手说话时，它非要等你说完整句话、停顿两秒钟，才慢悠悠开始回答。你想插一句"等等我改个要求"，它压根不理你，自顾自把话说完。你想在它讲话的时候"嗯嗯"一下表示我在听，它却突然停下来问"您说什么？"

这些让人抓狂的瞬间，恰恰是腾讯这次发布的Gander模型想要解决的问题。这个名字翻译过来是"鹅"，项目页面用了一只戴蓝色毛线帽的企鹅形象，看起来憨态可掬，但它背后要啃的骨头一点都不软。

**这篇论文要解决的，是让AI真正学会"边听边说边干活"这件事。**

这句话听起来简单，拆开看却是三个互相打架的需求。你需要AI能听懂你说的话、看懂你给它看的画面（这叫多模态理解）；你还需要它反应够快，不能让你等，甚至还要能被你随时打断（这叫实时交互）；你更需要它能真的帮你把活干了，比如写代码、查资料、处理文件（这叫智能体能力）。

多模态*：指模型能同时处理文字、语音、视频等多种类型的信息，而不是只会处理单一形式的输入。

问题是，这三件事对模型的要求是矛盾的。想反应快，就得让模型保持轻量，不能想太多；想干复杂活，就得让模型深度思考、反复试错，这必然要花时间。一个模型要是想同时满足这两头，很容易变成"哪头都不精"的四不像。

当AI还在"排队等你说完"的年代

在Gander出现之前，主流的语音交互模型基本都遵循一套老套路：先用一个叫VAD的模块判断你什么时候开始说话、什么时候说完了，等你说完了，再把这段完整的语音丢给AI去理解和回复。

VAD*：全称语音活动检测（Voice Activity Detection），是一种专门用来判断"现在有没有人在说话"的技术模块，通常独立于对话模型之外运行。

这套流程听起来挺合理，但它有个致命缺陷：判断"你说完了没有"这件事，完全靠声音本身的物理特征，比如有没有停顿、音量有没有降下来。它根本不理解你说的内容。你说"我想问一下……"然后停顿了半秒钟想措辞，VAD可能就误判你说完了，AI立刻插嘴回答，把你没说完的话强行"接话"了。反过来，如果你说得很快没有停顿，VAD又可能一直等，导致AI迟迟不回应。

这就好比你在餐厅点菜，服务员不是听你说了什么内容来判断你点完了没有，而是掐着秒表，你停顿超过两秒就默认你点完了。你说"我要一份宫保鸡丁，然后再来一份……"中间想了想菜单，服务员立刻打断说"好的宫保鸡丁一份，还需要别的吗"。如果服务员不是靠秒表判断，而是真正理解你话里的语义结构，就知道你这句话还没说完，该等一等。这正是老式VAD方案的代价：它省事，但代价是经常打断用户或者反应迟钝，因为它压根不懂你在说什么，只懂声音的物理形状。

这个问题在学术界已经有不少团队在尝试解决。比如BayLing-Duplex把"什么时候该说话、什么时候该闭嘴"直接做成模型自己预测的内容，不再依赖外部的VAD控制器；阿里的Qwen-Audio-3.0-Realtime把连续的语音流切成一个个小块，让模型能一边接收新内容一边组织回复，减少等待时间；字节跳动的Seeduplex则专门研究模型怎么在嘈杂环境里"专心听"，区分哪些声音是在跟自己说话，哪些是背景噪音或者别人的对话。

这些工作都在往一个方向努力：让AI自己学会判断交互的时机，而不是外包给一个死板的规则模块。但它们大多还停留在"听声音"的层面，对周围发生了什么画面变化不敏感。腾讯的Gander想往前再走一步，把视觉信息也纳入进来，同时还要解决一个更棘手的问题：既要反应快，又要能干复杂的活。

鹅的"小脑"和"大脑"：一个分工协作的架构

Gander最核心的设计思路，是把整个系统拆成两个部分，一个叫前小脑，一个叫后大脑。

**这个设计的灵感来自于人类神经系统的分工方式，小脑负责快速的、本能式的反应和协调，大脑负责深思熟虑的复杂决策。**

前小脑是一个实时的、全双工的多模态模型，负责跟你实时聊天、听你说话、看你的屏幕或摄像头画面，并且随时决定自己是该继续听、该开口说话、该给个简短反馈，还是该打断自己正在说的话。

全双工*：指系统可以同时进行"听"和"说"两个动作，而不是必须一方说完另一方才能开口，类似电话通话中双方可以随时插话的状态。

后大脑则是一个通用的任务执行智能体，负责处理那些需要长时间、多步骤才能完成的复杂工作，比如查资料、写代码、改文件。论文里提到，这个后大脑完全是"训练无关"的，也就是说它可以直接调用像Codex或者Claude Code这样现成的通用智能体，不需要专门为Gander重新训练一套。

这个设计带来一个很实际的好处：如果未来出现了更强的推理模型，你可以直接把后大脑换掉，不需要重新训练整个交互系统。这就好比你家里的智能音箱，喇叭和麦克风（前小脑）负责实时听你说话、跟你唠嗑，而真正需要动脑子解决的复杂问题，比如帮你规划一次跨省自驾游的详细路线，则被转发给云端一个更强大的计算中心（后大脑）处理。如果不这样拆分，而是让音箱本身承担所有计算，它要么反应变得很慢，因为要等复杂运算跑完才能开口，要么只能被迫削弱推理能力来保证反应速度。两头都要顾，硬凑在一个模型里，最后往往是两头都打折扣。

那前小脑和后大脑之间怎么协作呢？论文里给出了一个具体的机制，叫任务状态工具调用，包含三个操作：task_start（开始一个新任务）、task_send（往正在进行的任务里追加信息或修改要求）、task_resolve（对任务做出许可、取消等决定）。

举个论文里的例子：你跟Gander说"帮我找出这段代码报错的原因并修复它"，前小脑立刻调用task_start，把这个任务甩给后大脑去查。这时候后大脑就在后台默默干活了，可能要花几十秒甚至几分钟去翻代码、复现错误、定位问题。而这段时间里，你完全可以继续跟前小脑聊别的，比如问一句"报错的文件是哪个"，前小脑立刻回答"是config.py"。你甚至可以中途补充要求，比如说"记得保持Python 3.12的兼容性"，这时候前小脑会调用task_send，把这条新要求实时塞进后大脑正在执行的任务里，而不需要你重新描述一遍整个需求。等后大脑真正修好了代码、跑完了测试，它会把结果主动"汇报"给前小脑，前小脑再用自然的口语化方式讲给你听，比如"修好了，测试全部通过，Python 3.12也兼容了"。

这套机制解决的核心矛盾是：复杂任务需要时间，但用户不想干等着。传统语音助手一旦接了个复杂任务，往往就变成了一问一答式的"黑箱"，你问它进度它才告诉你，你没法在任务进行中随时插话调整方向。Gander把这层"用户可以随时介入正在跑的后台任务"的能力，做成了原生支持的架构特性，而不是事后打补丁加上去的。

这中间还有一层协调层，叫智能体编排运行时，它就像一个尽职的项目经理，负责管理音视频数据的实时传输、任务状态的记录追踪、权限的授权与拒绝、以及最终结果怎么送达用户。这个运行时支持两种工作模式，一种叫精简模式，直接执行前小脑的判断，路径短、延迟低，但灵活性差一些；另一种叫协调器模式，在中间加了一层独立的控制模型，能根据任务语义动态调整该用多强的推理力度、要不要多问用户几句、结果该怎么呈现，但代价是多了一次模型调用，会增加一点延迟和不确定性。

让AI学会"每一秒都要做决定"：流式思考者-说话者架构

前小脑内部具体是怎么实现"边听边看边说"的呢？这里用到了一个叫思考者-说话者的架构，Thinker负责理解和思考，Talker负责把想说的内容转换成语音。

这个架构本身不算新鲜，前面提到的MiniCPM-o系列、通义千问的Omni系列都用过类似设计。Gander的创新点在于它怎么把这个架构改造成能"持续感知、持续决策"的流式系统，论文里管这个叫流式分块展平机制。

具体是怎么运作的呢？系统把整个交互过程切成一个个一秒钟的小窗口，叫做chunk（分块）。每一个chunk里，模型会同时拿到这一秒钟内新观察到的视频画面和音频内容，然后必须做一个决定：这一秒钟我是继续听，还是开口说话，还是要打断自己刚才正在说的话。

分块*：指把连续不断的音视频流按固定时间长度（这里是一秒）切成一个个片段，模型逐块处理，而不是等到整段输入完成后才开始工作。

这里有一个细节很关键：模型是先预测这个"听/说/打断"的控制决定，然后才生成具体要说的内容。这两步是分开的，不是混在一起预测的。论文里解释说这样做能让全双工交互更稳定，因为"要不要说话"和"说什么"本来就是两个不同层次的问题，硬绑在一起反而容易出错。

这就好比你在开会发言前，脑子里其实经过了两道判断：第一道是"现在该我说了吗"，第二道才是"我具体要说什么"。如果这两个判断被强行捏在一起，变成"我一边想着该不该说话，一边同时组织语言"，很容易出现你话说到一半突然意识到"其实还不该轮到我"的尴尬场面。把这两步拆开，先笃定地判断时机，再从容地组织内容，是更稳的做法。如果不拆开会怎样，论文里提到的实验数据能说明问题：在Full-Duplex-Bench v3这个测试里，Gander在100个场景里做到了100%的时机判断准确率，同时打断错误率只有8%，是所有对比模型里最低的，而那些依赖简单规则判断说话时机的传统级联方案（先用Whisper识别、再用GPT-4o生成回复、最后用TTS合成语音），打断率高达33%，几乎是Gander的四倍。

为了让模型在很长的对话里也不至于卡顿变慢，Gander还设了一个128个分块的上下文窗口，大约对应两分钟的交互历史，超过这个长度就把最早的分块自动淘汰。这样无论对话进行多久，模型每一步的计算成本都保持稳定，不会随着聊天时间越长就越卡。

视觉和听觉这两路信息具体是怎么处理的呢？论文交代得挺细。视觉这边，每一帧画面先被切成若干小块，每块单独用一个叫SigLIP的视觉编码器处理，再用一个叫查询重采样器的模块把结果压缩成很少的几个视觉token，压缩比例大概是16倍，比很多同类模型的4倍压缩要激进得多。这样做的原因很直接：全双工交互对延迟极其敏感，画面一帧接一帧涌进来，如果每帧占用的计算资源太多，系统很快就会跟不上节奏。

听觉这边同理，原始语音编码器每秒会产生50帧特征，直接喂给主干模型的话序列长度会爆炸，所以中间加了一个轻量级的投影层做5倍时间下采样，把音频token的速率降到每秒10个左右，这个压缩比例既保留了理解语音所需的关键信息，又不会拖慢整个系统。

打断和沉默：藏在数据里的"社交礼仪"

模型架构定了，接下来更麻烦的问题是：从哪找到能教会模型"什么时候该打断、什么时候该闭嘴"的训练数据？

普通的对话数据集，本质上都是"你一句我一句"轮流说话的记录，根本没有真实世界里那些插话、抢话、重叠说话的现象。想让模型学会处理这些场景，得专门造数据。

论文里详细描述了一套叫InteractionSpeech的数据构建流程，专门用来合成带有打断和背景反馈的对话。整个流程分四步：先收集对话内容，再标注两类关键的交互事件，然后把结果渲染成带时间轴的音频，最后做质量把关。

对话内容来自两个渠道。一个是从11200个场景种子出发，用DeepSeek-V4-Pro扩展成8到18轮的口语化对话，覆盖教育、医疗、旅游、金融等45种日常和任务场景，并且严格限制总时长不超过96秒，避免生成那种不自然的长篇大论。另一个渠道是把已有的多轮对话改造成带打断功能的版本，但因为这些原始对话通常是"写"出来给人阅读的，充满markdown格式、代码、网址这些不适合口语表达的内容，所以要先经过一道过滤，把明显不适合说出口的内容筛掉，大部分候选对话都在这一步被淘汰了。

标注的两类交互事件很有意思，一类叫竞争性打断，一类叫支持性背景反馈。

竞争性打断*：指用户在助手还没说完话时就插进来说话，助手原本准备说的剩余内容会变成一段被隐藏的文本，虽然保留在数据里但从不真正合成为语音，这样模拟的是真实听众根本没听到那段话的情况。

支持性背景反馈：指用户在助手讲话过程中插入简短的"嗯嗯""对对"之类的回应，但助手不会因此停下来，而是继续把话说完，这类似人类对话里的"随声附和"。

判断一句话到底算打断还是背景反馈，论文设置了明确的规则：必须嵌在对方还没说完的话里、长度要短（中文不超过8个字，英文不超过6个词）、并且要能在词库里对应到11类意图之一。如果一句话带有疑问、请求或者否定的语气，即便很短，也不会被误判成背景反馈，因为这些往往是用户真正想抢过话头的信号。这套背景反馈的词库覆盖了266个中文表达和170个英文表达，避免了训练出来的模型永远只会说那几句干巴巴的"嗯嗯""好的"。

渲染成音频的时候，只有用户说的部分真正被转换成语音，助手的话保留成文字并占据相应的时间占位，这样打断和背景反馈发生的具体时间点，就成了可以拿来训练的精确监督信号，而不是拼接过程中的意外产物。

质量把控上，先用规则过滤掉那些打断时机不合理、内容有逻辑漏洞、助手说了用户不可能听到的话的样本，剩下的再交给一个大模型评委，从自然度、连贯性、打断合理性、背景反馈合理性四个维度打分，只有全部达标才留下。最终筛出来的26万条数据里，打断发生的位置分布得很均匀，不会集中在句子快说完的地方，而且大部分打断话语是直接切入内容的，不带那种"呃""那个"之类的口头禅开场，这一点很重要，因为如果打断总是伴随固定的口头禅，模型很容易学到一个偷懒的捷径，只认这几个词，而不是真正理解语义上的抢话时机。

除了语音交互数据，论文还专门造了一批音视频联动数据（占训练集的40%多，是最大的一块），让模型学会持续跟踪画面里发生的变化，比如屏幕上出现了什么新内容、视频里有什么新事件，并且能在恰当的时候主动开口提醒用户，比如"你要看的结果图表已经出现了"。

训练数据的四张牌：合起来才够用

整个训练语料一共270万条样本，分成四大类。

第一类是语音交互数据，占37%，负责打基础，包括常规对话、口语问答、前面提到的全双工打断数据，还有一部分同声传译数据。第二类是音视频交互数据，占40.66%，负责教会模型持续看画面。第三类是智能体交互数据，占约13%，专门训练前小脑和后大脑怎么配合完成长任务。第四类是鲁棒性和负样本数据，占约8%，专门教模型什么时候该"装作没听见"。

这最后一类特别有意思，值得多说几句。

现实场景里，AI经常会遇到跟自己无关的声音或画面，比如旁边有人在聊别的话题，或者屏幕上播放的视频跟当前对话毫无关系。如果AI对这些内容也一惊一乍地做出反应，用户体验会很糟糕。所以论文特意造了一批"无关视频""无指令环境""抗干扰""多人交互"数据，专门训练模型学会分辨这些声音画面是不是真的在跟自己说话，学会该沉默的时候就沉默。

这就好比你在咖啡馆专心工作，隔壁桌两个人聊得很热闹，你的耳朵能听见，但大脑会自动过滤掉这些信息，不会每听到一句话就抬头搭腔。如果一个AI做不到这种"选择性忽略"，那它在嘈杂的多人场景里会变得非常聒噪，别人随口一句话它就插进来接话，这种AI没人愿意用。反过来，如果为了避免误触发而设置得过于保守，又会导致真正该回应的时候它反而不吭声。论文里的多方交互数据，就是想在这两个极端之间找到平衡点，让模型学会追踪"谁在说话、说给谁听"这件事。

智能体交互数据这块也值得展开讲讲，因为这是Gander区别于纯聊天机器人的核心能力。这块数据又细分成音频智能体交互和全模态智能体交互两种，构建方式挺巧妙：先按任务类型、领域、具体分类这种层级结构采样出任务种子，再配合不同的交互模式（比如多轮请求、中途修改约束、询问进度、取消任务）和提问方式，用DeepSeek-V4-Pro合成出用户、前小脑、后大脑三方之间完整的交互轨迹。这些轨迹会记录下任务从开始到结束的完整生命周期：任务怎么发起的、中途用户提了什么新要求、进度怎么查询的、最后结果怎么交付的，全都有时间戳标注。

全模态智能体交互数据更复杂一些，因为涉及到视觉画面的持续跟踪，比如操作一个软件界面完成某项任务。这部分数据来自三个来源：真实爬取的操作轨迹、已有的图形界面数据集、以及用Codex直接生成的操作轨迹，一共约3.6万条。这些原始轨迹会先被转换成结构化的文字描述，说清楚每一步的环境状态、动作、时序变化，然后再合成出用户的语音请求和三方交互记录。

拿真实测试来说话：Gander到底行不行

光讲设计理念不够，得看实测数据。论文在三个维度上做了评估：全双工交互能力、纯语音对话能力、多模态理解能力。

先看全双工交互这块，用的是Full-Duplex-Bench v3，一个专门测试带工具调用的语音助手在真实服务场景（含自然的说话卡顿、犹豫等）下表现的基准。

|模型|工具选择准确率|参数正确率|回复质量|严格准确率|抢话时机|误打断率|填充词率|

|GPT-Realtime|0.876|**0.680**|**0.792**|**0.600**|96.0|13.5|16.9|

|Gemini Live 3.1|0.817|0.588|0.718|0.540|78.0|19.2|31.7|

|级联方案|0.803|0.562|0.600|0.450|100.0|33.0|26.9|

|Gander|0.759|0.503|0.490|0.400|**100.0**|**8.0**|51.6|

从这张表能看出一个很鲜明的对比：Gander在时机判断这个维度上是绝对的赢家，100个场景里全都在合适的时机接话，误打断率只有8%，比表现第二好的GPT-Realtime还低了将近6个百分点。但在纯粹的任务准确率上，Gander排在靠后的位置，跟表现最好的GPT-Realtime差了大约20个百分点。

论文对这个结果的解释挺坦诚，没有藏着掖着：Gander是个9B规模的模型，比起动辄更大参数量的商业闭源系统，本身在推理能力上就存在差距。论文还专门做了个对照实验，把后大脑单独拎出来，绕过前小脑和语音环节，直接用文字驱动，结果显示纯后大脑的工具选择准确率高达0.934，超过表中所有其他系统，说明执行任务这一层的能力其实并不弱，差距主要出在语音识别转写带来的误差、以及前小脑自己判断"这件事该不该转交给后大脑"的决策环节上。这提示了一个改进方向：与其重新设计整个架构，不如先把这两个具体环节打磨得更精细。

再看纯语音对话能力，测试用了SpokenQA和VoiceBench两套基准。

|模型规模|SpokenQA-Llama|SpokenQA-Web|AlpacaEval|SD-QA|

|Audio-Interaction(3B)|67.31|54.34|**4.28**|**52.14**|

|Moshi(7B)|62.20|26.30|2.01|15.01|

|Gander(9B)|**75.60**|**59.30**|3.96|46.84|

在同样属于全双工流式模型的对比组里，Gander在两个知识型问答测试上都是第一名，比第二名Audio-Interaction高出8个百分点以上。这说明流式架构本身并没有牺牲模型底层积累的知识储备，这是个挺重要的验证，因为按常理，一边要实时决策一边要回答问题，很容易两头顾不上。但在开放式生成质量和带口音语音识别这两项上，Gander排在了后面，论文分析原因是训练数据里大量是简短的对话轮次，没有专门加入长篇论述式的回复训练，也没有刻意扩充带口音语音的覆盖面。

多模态理解能力这块，测试用了WorldSense和Daily-Omni两套基准。

|模型|WorldSense|Daily-Omni|

|Gemini 2.5 Flash|52.60|79.30|

|Qwen3-Omni|54.00|70.70|

|MiniCPM-o 4.5(基座模型)|**55.70**|**80.20**|

|Gander|49.62|78.53|

Gander是在MiniCPM-o 4.5这个基座模型上做交互训练改造出来的，所以这里更适合把它当成一次"回归测试"：改造之后，模型的多模态理解能力掉了多少？结果显示在Daily-Omni上几乎没掉（差1.67分），但在WorldSense上掉了超过6分。

这个差异挺有意思，论文给出了一个合理的解释：Daily-Omni考察的是对音视频对齐的时序推理能力，恰恰是交互训练最强化的部分；而WorldSense考察的是更细粒度的感知能力，比如计数、定位这类静态属性判断，训练数据里并没有专门强化这块，视觉编码器本身也全程冻结没有更新。也就是说，交互训练精准地保住了它主要锻炼的那部分能力，代价则落在了它没有专门训练的部分。

论文还做了一个模态消融实验，测试同时给音频加视频、只给视频、只给音频三种情况下的表现差异。

|测试集|同时给音视频|只给视频|只给音频|融合带来的提升|

|WorldSense|49.62|44.61|43.32|+5.01|

|Daily-Omni|78.53|59.40|57.81|**+19.13**|

这个结果证明了一件事：模型是真的在融合两种信息，而不是偷懒只依赖其中一种更强的信号。尤其在Daily-Omni这个考察时序对齐的测试里，单独给任何一种模态都远远不够，只有两种信息合在一起才能大幅提升表现，提升幅度接近19个百分点，这几乎相当于把成绩从不及格拉到了良好水平。

这只鹅还没解决的事

论文在结尾坦率列出了几个还没搞定的开放问题，这种坦诚在技术报告里其实不算常见。

数据和模型规模还需要进一步扩大，尤其是复杂多模态场景下模型的稳定性还比较敏感，容易受训练数据分布影响。目前Gander还没有用上策略蒸馏或强化学习这类更精细的训练手段来优化长任务表现，怎么设计合适的奖励信号、怎么在小脑和大脑协作的场景下做好归因，这些都是尚待解决的难题。前小脑和后大脑之间目前主要靠语音识别转写出来的文字来通信，这个信息通道其实相当粗糙，未来如果能设计更丰富的双向沟通机制，比如后大脑能把中间过程的关键画面或数据结构直接传回前小脑，而不是简化成一段文字，交互质量应该还能再上一个台阶。另外，长时间、多模态的智能体交互会产生海量的历史记录和任务状态，怎么做好记忆管理也是个待解的问题。最后，目前业内其实并没有一套专门针对"全模态+实时交互+智能体"这种复合场景的评测标准，现有的基准要么只测多模态理解，要么只测语音交互，要么只测智能体执行，很少有能同时衡量这三者协同表现的统一框架。

Q&A

Q1：Gander是什么？

A：Gander是腾讯混元语音团队推出的一个端到端全模态交互智能体，它能同时处理语音、视频、文字输入，支持用户随时打断，并且能一边聊天一边执行复杂的后台任务，比如查资料或者修代码。

Q2：Gander的小脑大脑架构具体是怎么分工的？

A：前小脑是一个实时全双工多模态模型，负责持续感知和自然对话，能随时决定听、说或打断；后大脑是一个训练无关的通用任务执行智能体（比如Codex），负责长时间的复杂推理和任务执行，两者通过任务状态工具调用持续协作。

Q3：Gander在实测中表现怎么样？

A：在Full-Duplex-Bench v3测试中，Gander的抢话时机判断做到了100个场景全部准确，误打断率仅8%，是所有对比模型里最低的；但在任务执行准确率上因为模型规模较小（9B），落后于部分商业闭源系统。