腾讯混元全模态交互智能体Gander：边听边看边干活，提前抢话率仅8%

龙哥导读

Gander不是把语音助手和后台智能体简单粘在一起，而是让一个“前端小脑”持续听、看、接话、被打断，再把耗时任务交给“后端大脑”。它在100个工具场景里的提前抢话率仅8.0%，但端到端任务成功率只有0.400。最值得看的，正是自然交互与可靠执行之间这条还没填平的缝。下面三段均为官方系统演示。

演示1｜用户用语音发起网页俄罗斯方块任务，后台执行期间继续追加功能要求，并结合共享画面提出界面修改。画面展示的是官方系统界面和实际任务流；它能证明任务可被持续补充，不能单独证明复杂软件工程的成功率。

演示2｜用户共享一份技术报告，请系统调研并整理总结；前端根据画面和语音建立后台任务。官方原视频部分过程以5倍速播放，因此这段画面不能用于推断真实端到端耗时。

演示3｜系统在说话时继续接收用户语音：短促附和不会抢走话轮，明确停止请求会让它暂停。这里展示的是全双工交互行为，不能替代第三方噪声、口音和长时间稳定性测试。

一个真正像同事的智能体，应该怎样工作？你让它做网页小游戏，它在后台写代码；你继续说“加个重开按钮”，它不用停掉原任务；你把结果画面共享给它，再说“暂停按钮换个颜色”，它能看着屏幕继续改。更难的是，你在它说话时“嗯”一声，它应该继续；你说“等等”，它又必须马上停。

Gander瞄准的不是“回答得像人”，而是“协作的节奏像人”。三段演示展示的是浏览器中的模型交互与后台任务过程，不是能力概念动画；但演示只能说明系统怎样工作，可靠性仍要看后面的基准、消融和失败边界。

一、轮次式助手的问题，不只是“等得久”

传统助手通常把交流切成整齐的轮次：用户说完，系统识别语音，模型生成答案，语音合成再把答案读出来。这个流程适合“问一句、答一句”，但真实协作往往是连续的。用户会补充条件，会临时改主意，会指着屏幕里的某个区域说“就改这里”，还会在后台任务没结束时追问进度。

如果系统只靠语音活动检测判断“人是不是说完了”，它很容易把停顿当成结束。比如“我想订一张……下周三去上海的票”，中间那口气不代表用户交出了话轮。相反，用户说“可以，就这样”以后，系统也不能因为过分谨慎而一直沉默。交互的核心不是同时收音和放音，而是理解此刻应该听、应该说、应该停，还是应该把任务交给工具。

第二个矛盾更现实：实时聊天要求小步快跑，长程任务却需要深思、检索、文件操作、权限处理和失败恢复。让一个大模型既保持低延迟，又持续跑几十分钟的复杂工作，计算节奏天然冲突。模型越大、思考越长，接话越慢；模型越追求即时回应，处理长任务时越容易浅尝辄止。

Gander的回答是“分工而不分家”。前端小脑维护正在发生的对话和视听环境，后端大脑异步完成复杂任务，中间由一个有状态的编排运行时连接。用户看到的仍是一条连续对话，但系统内部已经把毫秒到秒级的互动，与分钟级甚至更长的执行拆开。

图1｜官方能力总览。左侧是屏幕理解、多人对话与抗干扰，中间是聊天过程中维持异步任务，右侧是附和、打断与视觉事件提醒。图中的场景用于说明系统目标，不等同于每项能力都完成了大规模独立验证。

二、小脑—运行时—大脑：真正的新意在接口

前端小脑是一个约90亿参数的流式全模态模型。它直接处理原始语音和连续视频，负责理解日常问题、维持对话节奏、生成语音，并决定是否发起任务。它不需要每次都找后端大脑：简单问答和普通聊天留在前端完成，只有检索、代码、文件处理等长程工作才升级。

后端大脑则是可替换的通用任务智能体。论文实验与开源运行时给出的默认实现使用Codex工作进程，但协议并不把系统锁死在单一后端。理论上，只要新的任务智能体遵守工作提供者接口，就可以替换，而无需重新训练前端小脑。这个设计把“更自然地交流”和“更聪明地干活”变成两条可独立迭代的产品路线。

中间的编排运行时不是一个转发器。它维护项目、任务、运行、工作事件和结果投递五类实体，处理并发、工作区隔离、权限、停止、恢复和最终结果。更关键的是，它把小脑生成的任务动作绑定到传输层确认过的真实用户话轮，避免模型凭空编造一个工具参数就被当成用户授权。

图2｜根据论文第3节和官方运行时重绘。task_start创建后台任务；task_send可补条件、查进度或发起不改变主任务的只读分叉；task_resolve负责取消与授权。图中字号按公众号移动端显示检查。

这三个动作比“会调用工具”更接近真实协作。很多智能体只会在一轮里选一个函数，然后等函数返回。Gander允许任务已经运行后再修改目标，还用“执行代际”隔离旧结果：用户改变要求以后，旧执行即使晚到，也不能覆盖新目标成为最终答案。这个细节很工程，却比一个花哨的演示更重要。

运行时还提供两种控制模式。精简模式直接执行小脑判断，路径短、延迟低、失败点少，但任务策略大多在部署时固定；协调模式增加一个独立控制平面，为不同任务安排推理强度、提问、授权和结果通知，灵活性更强，代价是额外调用、算力、延迟和不确定性。论文没有把两者包装成谁全面更好，而是承认它们服务不同风险等级。

龙哥觉得这里最有产品价值的，是“前端保持人在场，后端保持任务在跑，运行时保持状态不丢”。如果没有状态层，所谓边聊边干活很容易退化成两套机器人互相转述；一旦转述失败、用户改口或权限被拒，系统就不知道应该恢复哪条执行链。

三、一秒一个时间块：把“是否开口”也交给模型学

前端小脑建立在“思考器—说话器”结构上。思考器负责理解音视频、生成文字和交互动作；说话器根据文字和隐藏状态生成离散语音单元，再由流式解码器逐步合成波形。两者解耦后，系统可以继续听和看，不必等整段语音全部生成完才重新感知外界。

论文把连续交互切成一秒一个时间块。每个时间块先装入这一秒的新音频、新视频和必要的任务上下文，模型再预测控制标记：继续听、开始说、停止正在说的话，或者产生结构化任务动作。只有决定“说”时，后面才生成一小段文字；每个说话块最多八个文字标记，并与五十个语音标记对齐。

这个顺序非常关键。普通生成模型往往一开始吐字，就顺着内容继续往下写；Gander先问“此刻应不应该行动”，再问“行动时说什么”。于是交互时机和回答内容共享同一份正在变化的语义表示，不再由外部语音端点模块单独拍板。

视觉侧把不同分辨率的帧切成若干块，经视觉编码器后压缩成少量标记，论文称相对原始图像块网格约压缩十六倍。音频侧先得到每秒约五十帧的特征，再通过轻量投影降到每秒约十个音频标记。两路信息沿同一时间轴进入语言骨干，避免某一种模态把上下文预算全部吃掉。

上下文最多保留最近128个时间块，也就是约两分钟的滑动窗口。旧块出去，新块进来，计算量因此受到控制。运行时还可以把当前任务摘要放进上下文，让小脑知道后台任务是否在运行、需要回答什么问题、有没有新结果。不过，两分钟只适合维持近期互动，不足以独自承担长会议或长项目记忆，论文也把外部长记忆列为开放问题。

每收到一秒新的音频和视频：
  压缩为时间对齐的感知标记
  加入最近128个时间块和当前任务摘要
  先预测：继续听 / 开始说 / 停止 / 调用任务
  如果开始说：生成短文字片段并流式合成语音
  如果调用任务：生成task_start、task_send或task_resolve
  运行时校验状态、权限和可信用户话轮
  后端大脑异步执行，进度与结果回到当前对话

看起来只是多了几个控制词，实际上训练难点很大。模型必须同时学内容、时机、重叠语音、无关噪声、视觉事件、后台状态和工具参数。任何一项数据分布偏了，都可能出现怪现象：该沉默时插话、该追问时乱猜、任务没完成却抢着总结，或者一直用“好的，我正在处理”占住话轮。

四、270万条训练样本，训练的是“协作过程”

Gander的训练混合约270万条样本。语音交互约101万条，音视频交互约110万条，智能体交互约35.96万条，抗干扰和负样本约22.97万条。规模本身不是最特别的地方，特别的是标签不只描述“正确答案是什么”，还描述“什么时候应该回应、任务现在处于什么状态、用户的新话要改主线还是开旁路”。

其中约26.08万段交互语音对话专门标记打断与附和。用户语句被合成为语音，助手回复保留文字，并在时间线上安排起点、持续时间和重叠区间。这样模型能看到同一句“嗯”在不同上下文里可能是鼓励继续，也可能是准备抢回话轮，而不是把所有重叠声音都当成打断。

音视频部分来自流式视频问答、连续解说和主动视觉回应等数据，先筛质量、修时间对齐，再把回答长度调整到平均每秒约八个标记。它教模型在画面不断变化时决定什么时候说，而不是看完整段视频后写总结。项目页里“看到企鹅时提醒我”的演示，正属于这种先记住条件、后等待视觉事件的交互。

智能体部分更像一套任务生命周期教材。语音智能体数据约32.02万条，全模态智能体数据约3.6万条，另有约0.34万条工具辅助推理样本。轨迹覆盖发起、补充要求、更新约束、澄清、查进度、取消、授权和交付。全模态轨迹还来自真实交互记录、已有界面操作数据和代码智能体生成的操作过程，再转成带时间戳的环境与任务状态描述。

这类数据的意义，是让模型见过“任务正在进行时又发生了一件事”。如果训练样本总是从完整指令直接跳到完整答案，模型就很难学会等待、追问、转向和恢复。持续协作需要监督整个过程，而不只是监督最后一句回复。

抗干扰数据则教模型“别什么都接”。无关网络视频与不相关指令配成负样本，没有用户命令的环境输入要求保持安静；噪声、重叠语音和多人对话来自高质量生产数据。对于永远在线的助手，沉默不是缺失能力，而是一种必须学会的安全动作。

不过，这套数据工程也带来一条必须正视的边界：不少语音由合成系统生成，全模态智能体轨迹中也有大模型合成和评审。它们擅长覆盖组合情况，却不等于真实用户会按同样方式说话、改口和授权。数据规模能教会基本协议，长期使用中的含糊表达、情绪、口音和组织流程，还需要真实部署验证。

五、实验最诚实的结论：会接话，不等于会办事

论文把实验拆成三组，因为三组测的是不同东西。全双工工具测试让语音进入前端、后台工具执行、语音输出再被识别，覆盖整套系统；语音问答只测前端小脑；音视频理解则让前端直接输出文字，不经过语音合成和后端任务。把这些分开，能避免拿一个局部高分替整套系统背书。

最吸睛的是全双工工具基准第三版的100个场景。Gander适时接话率为100.0%，与级联方案并列最高；提前抢话率只有8.0%，优于表中六个商业与开源基线，OpenAI实时语音模型为13.5%。这说明“先预测交互动作，再生成内容”的训练确实改善了开口时机。

但任务正确性换了一张脸。Gander的工具选择得分为0.759，参数准确率0.503，严格Pass@1只有0.400；OpenAI实时语音模型为0.600。把用户转写文本直接交给同一个后端大脑，绕过前端和语音链路以后，工具选择升到0.934，Pass@1升到0.520。问题主要不是后端不会做，而是前端何时委派、传了什么，以及语音输入输出链路损失了多少信息。

图3｜论文表3关键结果重绘。“提前抢话率”指用户尚未说完时模型就开始回应，不是响应用户打断所需的时间。只输入文本给后端大脑的结果没有音频时间线，不能与全双工交互指标直接比较。

还有一个不太好看的数字：在91个没有抢话且能完成延迟分析的场景里，51.6%使用了填充语。论文解释，后台任务运行时系统不能一直沉默，先说一句类似“好的，我处理一下”是合理的占位行为。这个解释有道理，但从产品体验看，占位太频繁也会让系统显得紧张、啰嗦，甚至掩盖它其实还没得到可靠结果。

语音问答共2052条样本。Gander在两个知识问答子集上得到75.60和59.30，在全双工流式模型组里最高；在开放式指令和带口音语音问答上分别为3.96分和46.84%，排在组内第二。与Moshi相比，知识问答优势明显；与完整听完再回答的轮次式模型相比，则不能忽略实时流式模型还承担了“现在能不能开口”的额外判断。

音视频理解更能看出训练取舍。世界感知基准为49.62%，日常全模态基准为78.53%，都低于初始化模型的55.70%和80.20%。尤其前者下降6.08个百分点，说明强调连续交互、忽略无关画面的后训练，没有覆盖好静态画面里的精细计数和定位。

另一方面，音频与视频联合输入明显胜过任何单一模态。世界感知基准相对最佳单模态提高5.01个百分点，日常全模态基准提高19.13个百分点。也就是说，它不是把两路特征摆在一起做装饰，确实学到了声音与画面之间的时间对应；只是融合能力增长，并不自动抵消基础细粒度视觉能力的回退。

图4｜论文表5与表6关键数字重绘。融合收益等于音视频联合准确率减去更强的单模态准确率；“基座”是训练前的小参数全模态基础模型（MiniCPM-o）4.5版。融合收益和基础回退描述不同问题，不能只选一个讲。

六、放到相似工作里看，Gander补的是哪一环

Moshi把语音与文字放进实时生成框架，重点解决边听边说和自然口语节奏，是全双工语音模型的重要起点。但它的主战场是语音对话，不负责持续视觉理解，也没有Gander这套任务编排运行时。Gander继承了“交互本身要由模型学习”的方向，再把屏幕和后台工作接进来。

Qwen2.5-Omni以及后续全模态模型更强调统一处理文字、图像、音频和视频，并流式生成语音。它们提供了强大的通用多模态底座。Gander与它们的差别，不是“模态更多”，而是把任务发起、追加要求、权限、取消、进度与结果投递定义成长期运行的协议。

Streamo专门研究流式视频理解，把沉默、待命和回应的时机预测放进模型，训练数据覆盖实时解说、事件描述、时间定位和问答。它解决的是“边看边决定何时输出”；Gander在此基础上加入语音全双工、用户打断和异步任务，所以问题从视频助手扩展成持续协作。

双脑实时语音推理与流式双脑记忆等研究，都说明“快反应模块加慢思考模块”正在形成一条路线。Gander进一步把这条路线工程化为可替换后端、持久任务实体、只读分叉、权限围栏和结果交付。它补上的不是又一个模型头，而是实时交互模型与通用任务智能体之间的运行协议。

因此，不要把Gander概括成“语音版智能体”或“会看屏幕的聊天机器人”。更准确的说法是：它尝试建立一种持续会话外壳，让用户在长任务里始终保留参与权。任务可以跑，但人没有被踢出流程；模型可以说，但人随时能打断、改目标或撤销授权。

七、开源到什么程度，复现门槛有多高

官方仓库已经公开前端微调代码、推理配置、编排运行时、浏览器服务、训练与推理脚本，以及一批随仓库发布的音频和图像样例。代码树里能看到任务网关、在线双工桥、媒体时间线、权限与工作工具路由等模块，不是只有一页说明文档。仓库当前使用Apache-2.0许可；模型权重已经给出入口，完整训练数据在仓库说明中仍标记为发布流程进行中。

本地静态检查使用官方主分支提交19e9598154eb3fce17922dd2f270bcb4aa1fab6f。82个Python文件通过编译检查，四份主要配置可以正常解析，四个入口脚本通过Shell语法检查。仓库中还包含22个音频样例和36个图像样例，可以确认发布包确实覆盖语音、全双工和界面任务的数据路径。

但这不等于“一台普通电脑点一下就能跑”。官方完整浏览器方案需要Linux和并行计算系统（CUDA）12.4对应环境，默认把思考器、说话器和自动语音识别分配到三张物理显卡，还要下载基础模型、Gander思考器与说话器权重、较大的语音识别模型，并准备可认证的后端任务智能体。没有这些条件，无法把静态检查写成端到端实测成功。

这个门槛说明，Gander当前更像研究与工程团队的参考实现，而不是面向个人开发者的轻量组件。它给出了完整架构和可阅读代码，复现路径也比只放演示透明；但显存、模型下载、语音链路和后端授权会让首次部署成本很高。团队若想采用，最现实的办法是先复用运行时协议，再选择更小的前端模型和已有后端。

八、五个局限，决定它还不是“全天候同事”

第一，交互时机领先，任务准确率落后。端到端Pass@1只有0.400，意味着严格要求工具和参数全部正确时，十个场景里平均只有四个一次完成。对日程、文件、代码和权限操作来说，“聊得自然”不能抵消“做错了”。产品必须把确认、预览、撤销和结果验证放在模型能力之外。

第二，前后端传递仍然偏窄。当前主要把自动语音识别（ASR）得到的文本和少量相关视频帧交给后端大脑。语气、重音、说话人身份、长视频细节和连续画面变化可能在转写与抽帧中丢失。论文也明确把更丰富的双向通信列为未来工作。

第三，长记忆尚未闭环。小脑只有约两分钟滑窗，运行时虽然能保存任务状态并提供外部记忆接口，但如何在数小时交互中检索真正相关的语音、画面、工具事件和用户决定，仍没有统一答案。记得太少会断片，记得太多又会增加延迟、成本和隐私风险。

第四，长程场景的稳定后训练还不充分。论文承认尚未广泛使用在线策略蒸馏和强化学习来优化全模态长任务。这里的奖励很难设计：只奖励任务完成，模型可能变得粗鲁、爱抢话；只奖励对话自然，它又可能不断安慰用户却不推进任务。局部交互质量和全局任务目标必须一起算账。

第五，缺少统一基准。现有测试分别测语音问答、音视频理解、接话时机和工具执行，却很少测“小脑与大脑协作是否正确”。真正需要的新测试应包含长时间任务、用户多次改口、权限拒绝、旁路查询、失败恢复和最终交付，而且要同时评价自然度、准确率、延迟、成本与安全。

图5｜论文公开局限汇总。卡片中的“约两分钟”来自128个一秒时间块；端到端0.400与填充语51.6%来自全双工工具基准第三版。它们描述当前研究版本，不代表未来工业模型的最终能力。

九、它最可能先改变哪些产品

第一类是共享屏幕协作。用户不必把屏幕内容完整转述成文字，可以一边展示文档、代码或设计稿，一边补充要求。前端负责理解“这里”“刚才那一页”等指代，后端负责真正修改文件。对编程、数据分析、设计审阅和办公自动化，这种持续参与比一次性上传文件更自然。

第二类是无障碍与陪伴式工具，但这里要格外谨慎。视觉提醒、持续解说和语音打断对视障、行动不便或需要免手操作的人很有价值；同时，错误提醒、误听授权和过度占位的代价也更高。产品不能只追求“像人”，还要让用户随时知道系统正在听什么、做什么、记住了什么。

第三类是客服与现场支持。后台查订单、检索知识库或生成方案时，前台仍能回应用户、询问缺失信息并报告进度。传统机器人常在调用工具后沉默，用户不知道它是卡住还是在工作；Gander式架构可以把任务里程碑作为独立事件送回对话，减少无意义等待。

第四类是复杂个人助理。旅行规划、材料整理、会议跟进和多应用操作都需要长任务，用户又会不断改变要求。真正有用的不是一次把计划写得很漂亮，而是任务运行中能接受新约束，保留主线，必要时开一个只读旁路回答临时问题，然后回到原任务继续执行。

不过，短期落地不会从“完全自主”开始。更可信的路线是：前端负责自然交流和澄清，后端在受限工作区执行，运行时提供权限围栏，高风险动作必须预览确认，结果要有可追溯证据。Gander最值得借鉴的不是让模型获得更多自由，而是给持续协作加上更清楚的状态和边界。

十、龙哥点评：这是一篇架构论文，也是一份产品问题清单

龙哥最认可的一点，是论文没有用“全模态”三个字遮住失败。它把100%适时接话、8.0%提前抢话率写出来，也把0.400的端到端Pass@1、51.6%的填充语、世界感知基准回退和两分钟窗口写出来。读者因此能看清：系统已经跨过“能不能自然互动”的门槛，却还没跨过“能不能可靠完成复杂工作”的门槛。

从研究角度看，小脑—大脑并非第一次出现，流式语音、流式视频和任务智能体也都有前作。Gander的贡献在于把三条线接成一套端到端系统，并公开了相当完整的运行时。创新不只来自一个新损失函数，也可以来自接口、状态、任务生命周期和训练数据怎样共同定义新问题。

从工程角度看，它提醒团队不要把所有智能都塞进一个巨型模型。用户能感知的低延迟与后台任务所需的高能力，可以用不同模型和不同节奏实现。这样做还带来一个现实好处：后端大脑升级时，不必重训前端交互模型；前端变得更轻时，也不必牺牲后台工具能力。

从产品角度看，下一步真正决定成败的不是演示更炫，而是委派更准、信息传递更完整、权限更可控、任务恢复更稳定。用户打断一句，系统究竟应该停止说话、停止工具、取消整个任务，还是只修改当前参数？这些不是语音识别问题，而是产品语义和状态机问题。

所以龙哥给这篇工作的判断是：方向很对，系统很完整，开源很有价值；但现阶段更适合当作下一代交互智能体的“参考架构”，还不能当作可靠性已经解决的成品。如果团队只看8.0%就准备全自动接管用户电脑，会过度乐观；如果因为0.400就否定这条路线，又会错过持续协作接口真正的价值。

十一、龙迷三问

第一，为什么不直接让最大模型一直在线？因为实时接话和长程推理的计算节奏不同。大模型持续处理每秒音视频成本高、响应慢，也会让简单对话被复杂推理拖累。小脑守住实时交互，大脑按需出现，更容易控制延迟和成本。

第二，8.0%的提前抢话率是不是等于打断响应只需很短时间？不是。这个指标统计模型在用户说完之前就开始回应的比例，越低越好；它不等于用户说“停”以后模型多久闭嘴。官方演示展示了停止行为，但论文表3没有给出统一的打断响应毫秒数。

第三，开源代码是否意味着普通开发者能立即复现完整效果？也不是。仓库结构、训练与运行代码确实公开，模型入口也已给出；完整服务默认需要三张显卡、多个大模型、语音识别和经过认证的后端任务智能体。能阅读、能改造，与低成本完整复现，是两件事。

十二、总结：智能体正在从“接单”走向“共事”

过去的助手像一个窗口：你提交请求，等它返回。Gander想把窗口变成共同工作的房间。语音、视频、文字、任务状态和工具结果持续进入同一段协作，用户可以随时补条件、看进度、纠正方向和停止行动。

它已经证明了三件事：交互时机可以由模型内生学习；实时前端和长程后端可以在一条对话里协作；任务生命周期值得成为模型训练的一部分。它也暴露了三件同样重要的事：自然对话不等于任务可靠，多模态融合不等于基础能力不回退，开源完整架构不等于部署成本已经足够低。

真正的下一代智能体，未必是一个无所不能的单体模型，更可能是一套分层系统：有负责感知和节奏的快脑，有负责推理和行动的慢脑，有负责状态、权限和证据的运行时。谁能把这三者之间的信息损失降下来，把错误操作关进可撤销、可验证的边界里，谁才更接近“可以一起工作”的人工智能。