论文名称：Multimodal Duplex Interaction Agent
模型名称：Gander
研究方向：全双工语音交互、多模态大模型、智能体、工具调用
核心关键词：Full-Duplex、Cerebellum-Brain、Thinker-Talker、Streaming Interaction、Agent Orchestration
1. 前言：如果 AI 在工作时，你还能继续和它说话吗？
假设你正在让 AI 修复一段代码。
你对它说：
“帮我找出这个错误的原因并修复。”
传统 Agent 接到任务后，通常会进入一段相对封闭的执行过程：读取代码、分析报错、修改文件、运行测试。此时，你要么等待它执行结束，要么重新发送一条消息，打断原来的任务流程。
但现实中的协作不是这样。
当 AI 正在检查代码时，你可能突然想到：
“对了，还要兼容 Python 3.12。”
过了一会儿，你又问：
“现在查到哪一步了？”
AI 也可能需要主动告诉你：
“问题来自依赖版本冲突，我正在验证修复方案。”
真正自然的人机协作，不应只是“用户提交请求，AI 返回答案”，而应该允许双方持续沟通、互相打断、补充信息，并在交流过程中共同推进任务。
Gander 想解决的正是这个问题：
如何让 AI 在保持实时语音和多模态交互的同时，继续执行耗时较长的复杂任务？
它给出的答案不是训练一个无所不能的超大模型，而是让两个不同角色协同工作：
- 一个“小脑”负责实时听、看、说和维持交流；
- 一个“大脑”负责深度推理、工具调用和后台任务；
- 一个编排运行时负责连接二者并管理任务状态。
如果只用一句话概括 Gander：
Gander 把“实时交流”和“复杂任务执行”拆成两个协同层，使 AI 可以一边与用户持续对话，一边在后台完成长程工作。
2. 为什么现有语音助手和 Agent 还不够？
论文认为，自然的人机协作至少需要三类能力：
- 理解语音、视觉和文本；
- 进行低延迟、双向、连续的实时交流；
- 完成规划、工具调用和多步骤任务。
现有系统往往只能覆盖其中一部分。
2.1 传统语音助手：听到一句，回答一句
典型语音系统采用如下流程：
VAD 检测语音结束
↓
ASR 转写文本
↓
大模型生成回答
↓
TTS 合成语音
这类系统的问题是，“什么时候该回答”通常由外部模块决定。
例如，VAD 可以检测声音是否停止，却很难理解：
- 用户是在思考，还是已经说完；
- “嗯嗯”是在表示赞同，还是准备抢话；
- 用户的插话是补充条件，还是要求 AI 立刻停止；
- 背景中的说话声是否在呼叫 AI。
自然对话不是简单的声音开关，而是一个语义判断问题。
2.2 工具型 Agent：能干活，但交流不够自然
另一类系统擅长：
- 搜索资料；
- 操作文件；
- 编写代码；
- 调用 API；
- 执行多步骤工作流。
但它们通常围绕离散任务轮次运行。
用户提出任务
↓
Agent 长时间执行
↓
返回最终结果
一旦进入执行状态，用户很难像和同事协作一样：
- 临时追加约束；
- 询问进度；
- 纠正错误方向；
- 在不影响主任务的情况下提出旁支问题；
- 随时取消或批准高风险操作。
2.3 一个模型承担所有工作也不现实
实时交互和复杂推理对模型的要求并不相同。
实时对话要求：
- 延迟低；
- 持续接收音视频；
- 高频判断是否回应；
- 快速生成自然口语。
复杂任务则要求：
- 长时间推理；
- 多轮规划；
- 调用工具；
- 操作文件；
- 保存大量任务状态。
如果让一个模型同时完成这些工作，往往会陷入矛盾：
模型越大、推理越深
↓
任务能力越强
↓
实时响应越慢
Gander 因此选择将两种能力解耦。
3. 整体架构：小脑负责交流，大脑负责执行
Gander 由三个主要部分组成：
| 模块 | 主要职责 |
|---|---|
| Front Cerebellum | 实时感知、语音交互、打断判断、任务路由 |
| Agent Orchestration Runtime | 状态管理、权限控制、任务调度、结果投递 |
| Back Brain | 长程推理、工具调用、代码和文件操作 |
整体流程可以表示为：
用户语音、摄像头、屏幕
↓
Front Cerebellum
感知、回应、判断是否委托
↓
Agent Orchestration Runtime
创建任务、维护状态、控制权限
↓
Back Brain
推理、搜索、写代码、调用工具
↓
中间进展或最终结果
↓
Front Cerebellum
↓
转化成自然口语告诉用户
这套架构的重点不是简单地部署两个模型，而是明确划分职责。
前端小脑追求“快”，后端大脑追求“深”。二者通过结构化任务和事件持续协作。
4. Front Cerebellum：一个始终在线的交互模型
前端小脑基于 MiniCPM-o 4.5 初始化，是一个实时全双工多模态模型。
它持续接收：
- 用户语音；
- 摄像头视频；
- 屏幕画面；
- 最近的对话历史；
- 后端任务状态；
- 后端返回的中间结果。
它需要不断做出几类判断：
继续听？
开始说？
停止当前回答？
回应用户的附和？
忽略背景说话声？
自己回答？
还是把任务交给后端？
简单闲聊、短问题和一般信息查询由小脑直接完成。
遇到以下情况时，小脑会考虑调用后端大脑：
- 需要多步推理；
- 需要访问文件；
- 需要编写或修改代码；
- 需要调用外部工具；
- 任务执行时间较长；
- 需要持续追踪任务状态。
因此，小脑不仅是语音模型，也是整个系统的任务路由器。
5. 核心机制一：模型自己决定什么时候听、什么时候说
传统语音系统通常把交互时机交给 VAD 等外部模块。Gander 则把交互决策放进模型内部。
5.1 把连续交互切成一秒一个 Chunk
Gander 将音视频流划分为固定的一秒窗口。
每个 Chunk 包含：
当前一秒的视觉 Token
+
当前一秒的音频 Token
+
交互控制 Token
+
模型生成的文本 Token
这些 Chunk 按时间顺序连接成一个统一的自回归序列。
这意味着模型不是等用户说完整句话后才开始处理，而是每隔一秒都会重新观察环境并做出判断。
5.2 三种关键控制状态
每个 Chunk 中，模型会先预测一个控制 Token。
Listen
表示继续听，本窗口不输出内容。
适用于：
- 用户还没有说完；
- 用户只是停顿思考；
- 当前环境没有需要回应的事件；
- 背景声音并非在呼叫 AI。
Speak
表示开始或继续生成内容。
后续文本会进入语音生成模块，并以流式方式播放。
Interrupt
表示停止当前正在生成的回答。
适用于：
- 用户开始真正抢话；
- 用户提出新的约束；
- 当前画面发生变化，使原回答失效；
- 系统发现当前表达不应继续。
关键点在于：
Gander 先决定“要不要说”，再决定“具体说什么”。
这使交互控制和内容生成相对解耦，也让模型更容易学会稳定的全双工行为。
6. “打断”和“嗯嗯”不是一回事
全双工交互中，一个常被忽视的问题是：语音重叠不一定意味着用户在抢话。
例如，AI 正在解释一个方案，用户说：
“嗯嗯。”
这通常表示用户在认真听，AI 应该继续。
但如果用户说：
“等等，你理解错了。”
AI 就应该立即停止并让出话语权。
Gander 的训练数据显式区分了两类事件。
6.1 竞争式打断
用户在 AI 尚未说完时插入新的实质性内容。
系统应：
- 停止当前回答；
- 关注用户新输入；
- 判断原任务是否需要修改。
6.2 支持式附和
用户发出简短确认，但并不想获得话语权。
系统应：
- 理解用户正在跟随对话；
- 保持原来的表达节奏；
- 不把每一个“嗯”“对”“明白”都当作中断命令。
训练数据为中英文构建了专门的附和表达集合，并结合长度、语气、疑问特征和上下文判断它是否属于 backchannel。
这说明 Gander 学习的不只是“声音有没有重叠”，而是：
重叠的语音在当前对话中承担什么功能。
7. 多模态输入如何满足实时性？
持续处理音频和视频的成本很高。为了控制延迟，Gander 对两种输入进行了压缩。
7.1 视觉输入
视觉模块采用：
- 任意分辨率图像切片；
- SigLIP 视觉编码器；
- Query-based Resampler；
- 最高约 448×448 的紧凑输入分辨率。
经过压缩后，视觉 Token 数量约为原始 Patch 网格的 1/16。
这种压缩会牺牲部分细粒度视觉信息，但能降低持续视频输入的计算负担。
7.2 音频输入
音频编码器以流式方式输出特征，原始速率约为每秒 50 帧。
经过轻量 MLP 做五倍时间下采样后，输入主模型的音频表示降到约：
10 个音频 Token / 秒
这样既能保留语音、语调和韵律信息，又不至于让音频 Token 占满上下文。
7.3 两分钟滑动窗口
Gander 最多保留最近 128 个 Chunk。
由于每个 Chunk 对应一秒，因此实时上下文约为两分钟。
第 1 秒 → 第 2 秒 → ... → 第 128 秒
↓
新 Chunk 进入时，最旧 Chunk 移出
这种设计能让长时间运行的推理成本保持稳定，但也意味着更早的细节需要依靠外部记忆系统保存。
8. Thinker-Talker：主模型不直接生成音频
如果让语言模型直接生成高频率语音 Token，会带来两个问题：
- 每秒解码步数大幅增加；
- 语言和推理能力可能受到声学建模干扰。
Gander 因此采用 Thinker-Talker 架构。
Thinker
负责：
- 理解音视频；
- 语义推理；
- 生成文本；
- 预测听、说和打断状态。
Talker
读取文本 Token 和 Thinker 的隐藏状态，生成离散语音 Token。
隐藏状态中包含：
- 语义；
- 语气；
- 重音；
- 表达风格。
Flow-Matching Decoder
最后将语音 Token 流式转换为音频波形。
整个过程可以表示为：
音视频输入
↓
Thinker 生成文本与隐藏状态
↓
Talker 生成离散语音 Token
↓
Flow-Matching Decoder
↓
流式音频输出
由于音频按块生成，系统不必等整句话完成后才开始播放，从而降低首包语音延迟。
9. 核心机制二：用户可以在后台任务执行时继续干预
小脑通过三类结构化操作管理后端任务。
9.1 task_start：创建新任务
当用户提出复杂任务时，小脑创建一个后台任务。
例如：
“找出这个报错的原因并修复。”
运行时会创建任务对象和执行实例，并把真实用户请求传递给后端。
9.2 task_send：追加或修改任务
用户可以在任务执行期间补充信息。
例如：
“还要兼容 Python 3.12。”
task_send 支持两种模式：
main：将新信息加入主任务，改变后续执行；fork：创建只读旁支查询，不影响主任务。
因此，当用户问“现在进展如何”时，系统可以单独查询任务状态，而不必打断主执行流程。
9.3 task_resolve：处理取消和权限
系统支持：
cancel：取消任务；allow_once：仅允许本次操作；allow_session：当前任务会话内持续允许；deny：拒绝操作。
这让用户可以通过自然交流参与权限审批，而不是把所有操作权限一次性交给 Agent。
10. 编排运行时：真正把两个模型连接起来
小脑和大脑之间并不是简单传递几段文本。
Gander 的编排运行时维护五类持久化实体：
| 实体 | 作用 |
|---|---|
| Project | 长期项目或工作流容器 |
| Task | 用户希望完成的逻辑目标 |
| Run | 某一次具体执行 |
| WorkerEvent | 执行过程中产生的事件 |
| Delivery | 结果如何交付给用户 |
它还负责：
- 音视频流接入；
- 增量推理调度；
- 模型调用序列化；
- 工作区隔离；
- 并发控制；
- 权限校验；
- 任务恢复；
- 中间结果和最终结果投递。
一个很重要的安全设计是：
运行时会把小脑发出的任务操作绑定到经过确认的真实用户输入，而不是完全信任模型自行生成的工具参数。
这可以减少模型误生成任务目标或权限指令造成的风险。
11. 两种编排模式：低延迟还是强控制？
论文提供两种控制方式。
11.1 Lean 模式
运行时直接执行小脑分类后的任务动作。
优点：
- 路径短；
- 延迟低；
- 行为更确定；
- 额外模型调用少。
缺点：
- 推理强度和权限策略不够灵活；
- 难以针对不同任务动态调整通知方式。
11.2 Coordinator 模式
在小脑和任务网关之间增加一个独立协调模型。
协调器负责生成控制计划，例如：
- 使用何种推理强度；
- 是否需要向用户提问；
- 采用什么权限策略；
- 何时汇报中间进展；
- 如何交付最终结果。
协调器本身不执行任务，也不直接访问文件、终端或网络。它只输出声明式计划，计划还需要通过网关验证。
可以简单理解为：
Lean：
小脑判断 → 直接执行
Coordinator：
小脑判断 → 协调器制定策略 → 网关验证 → 执行
前者更快，后者更适合复杂、需要严格监督的任务。
12. 训练数据：270 万条样本如何教会模型自然互动？
Gander 的训练集约有 270 万条样本，分为四大类。
| 数据类型 | 数量或占比 | 主要目标 |
|---|---|---|
| 语音交互 | 约 37.49% | 对话、问答、打断、轮次控制 |
| 音视频交互 | 110 万，40.66% | 视频问答、事件理解、主动提醒 |
| 智能体交互 | 约 13.33% | 任务委托、进度沟通、约束更新 |
| 鲁棒性与负样本 | 约 8.52% | 抗噪声、多人环境、不该回应时保持沉默 |
12.1 语音交互数据
其中包括：
- 53.94 万条基础对话；
- 26.08 万条全双工互动数据；
- 16.51 万条语音问答；
- 基础数学、逻辑和指令任务；
- 同声翻译数据。
全双工数据显式标注：
- 打断发生在什么时间；
- 哪些内容发生重叠；
- 哪些是附和；
- 哪些内容用户实际上没有听到。
12.2 音视频交互数据
约 110 万条，包括：
- 流式视频问答；
- 流式视频描述；
- 主动视觉响应；
- 视觉事件定位；
- 音视频时间对齐。
这些数据训练模型根据“当前已经观察到的内容”回答，而不是偷看未来画面。
12.3 智能体交互数据
数据覆盖完整任务生命周期：
创建任务
→ 追加要求
→ 修改约束
→ 请求进度
→ 澄清问题
→ 批准或拒绝操作
→ 取消任务
→ 接收最终结果
这和传统单次工具调用数据有明显区别。模型学习的不是“调用一次工具”，而是如何在任务持续执行时与用户保持协作。
12.4 负样本为什么重要？
一个持续监听的模型，最危险的问题之一是“什么都想回应”。
因此训练集中专门加入了：
- 无关视频；
- 没有人向 AI 发出指令的环境；
- 背景噪声；
- 多人同时讲话；
- 旁人的对话；
- 重叠干扰。
这些数据不是教模型回答，而是教模型：
什么时候应该保持沉默。
13. 实验结果：Gander 最强的能力是什么？
论文从三个方面评估 Gander：
- 全双工工具任务；
- 语音问答；
- 多模态理解。
13.1 全双工交互：接话时机突出，任务准确率一般
在 Full-Duplex-Bench v3 的 100 个场景中，Gander 的关键结果如下：
| 指标 | Gander |
|---|---|
| 合适时机接话 | 100% |
| 过早打断 | 8.0% |
| 工具选择 | 0.759 |
| 参数正确率 | 0.503 |
| 回答质量 | 0.490 |
| Pass@1 | 0.400 |
| Filler | 51.6% |
Gander 的过早打断率为 8.0%，优于：
- GPT-Realtime：13.5%；
- Gemini Live 3.1：19.2%；
- Whisper→GPT-4o→TTS 级联系统：33.0%。
这说明它确实学会了根据语义判断用户是否说完，而不是只依赖声音停顿。
但在工具准确率方面，Gander 并不领先。
它的 Pass@1 只有 0.400，低于最强基线的 0.600。
因此，这组实验揭示了一个很清楚的特点：
Gander 更擅长判断“什么时候行动”，但还不够擅长保证“每次行动都正确”。
13.2 后端大脑很强，前后端衔接是瓶颈
当实验绕过小脑和语音链路，直接把用户文本交给后端大脑时：
| 指标 | 完整 Gander | 仅后端大脑 |
|---|---|---|
| 工具选择 | 0.759 | 0.934 |
| 回答质量 | 0.490 | 0.740 |
| Pass@1 | 0.400 | 0.520 |
这说明后端执行能力本身并不弱。
端到端性能下降可能来自：
- 小脑没有在正确时机委托任务；
- 用户语音转写存在误差；
- 小脑传递给大脑的信息不完整；
- 大脑结果被小脑口语化时发生信息损失；
- 语音合成后再经 ASR 评分带来额外误差。
换句话说，Gander 当前最大的工程问题之一，不是“大脑不够聪明”，而是：
小脑和大脑之间还没有形成足够可靠的信息通道。
13.3 占位语偏多
Gander 的 Filler 比例达到 51.6%。
这意味着模型经常先说：
- “好的，我看一下。”
- “明白，我正在处理。”
- “稍等，我来检查。”
这类表达能够维持交流连续性，但过多也会让用户觉得拖沓。
如何区分“有价值的进度反馈”和“没有信息量的占位语”，仍然值得进一步优化。
14. 语音问答：流式模型也能保留知识能力吗？
在全双工流式模型中，Gander 的 SpokenQA 表现最好：
| 模型 | Llama Questions | Web Questions |
|---|---|---|
| Moshi | 62.20 | 26.30 |
| Audio-Interaction | 67.31 | 54.34 |
| Gander | 75.60 | 59.30 |
这说明实时流式建模没有完全破坏模型的知识问答能力。
但在更强调开放回答质量和口音适应的 VoiceBench 中，Gander 弱于 Audio-Interaction。
论文认为可能有两个原因：
- 训练数据以短对话为主，不利于生成较长、结构完整的回答；
- 语音训练数据的口音覆盖不够广。
值得注意的是，这组测试中后端大脑一次都没有被调用。
这说明路由策略能够区分：
普通知识问答 → 小脑直接回答
复杂工具任务 → 委托后端大脑
如果所有问题都交给大脑，双层架构反而会失去低延迟优势。
15. 多模态理解：音频和视频一起输入真的有帮助吗？
Gander 在两个多模态测试集上的结果为：
| 模型 | WorldSense | Daily-Omni |
|---|---|---|
| MiniCPM-o 4.5 | 55.70 | 80.20 |
| Gander | 49.62 | 78.53 |
与基座模型相比：
- Daily-Omni 下降 1.67；
- WorldSense 下降 6.08。
这说明交互训练后，模型保留了大部分音视频理解能力，但细粒度视觉能力有所下降。
15.1 音视频融合消融实验
| 输入方式 | WorldSense | Daily-Omni |
|---|---|---|
| 音频+视频 | 49.62 | 78.53 |
| 仅视频 | 44.61 | 59.40 |
| 仅音频 | 43.32 | 57.81 |
音视频融合带来的增益为：
- WorldSense：+5.01；
- Daily-Omni：+19.13。
Daily-Omni 强调音频与视频之间的时间对应关系，因此联合输入的提升尤其明显。
这说明 Gander 并不是简单选择更强的单一模态，而是在利用：
当前听到了什么、看到了什么，以及两者在时间上如何对应。
16. 这篇论文真正值得关注的地方
Gander 的贡献不在于每个测试指标都达到最佳，而在于它提出了一套较完整的实时 Agent 范式。
16.1 把“什么时候说”变成模型能力
传统系统更多依赖外部规则判断轮次边界。
Gander 则让模型直接学习：
Listen / Speak / Interrupt
这使交互控制可以利用语义、视觉和上下文，而不只依赖声学停顿。
16.2 把“实时交流”和“复杂执行”分开扩展
双层架构允许：
- 小脑单独优化延迟和交互；
- 大脑单独升级推理和工具能力；
- 更换后端模型时不必重新训练小脑。
这对工程落地尤其重要。
16.3 后台任务不再是不可干预的黑盒
用户可以：
- 追加条件；
- 查询进度；
- 提出旁支问题；
- 批准操作；
- 拒绝操作；
- 取消任务。
这让 Agent 从“接收命令的工具”更接近“可以持续协作的同事”。
16.4 负样本与沉默能力同样重要
持续在线的 AI 不只是要学会回答，还要学会不回答。
在多人、噪声和开放环境中，“保持沉默”本身就是一种重要能力。
17. 局限性：Gander 离真正的实时 AI 同事还有多远？
17.1 缺少长期端到端协作评测
现有实验分别测试了：
- 接话时机；
- 工具调用；
- 语音问答；
- 多模态理解。
但最关键的问题还没有被充分回答：
用户连续几十分钟与系统交流，并多次修改任务后，任务最终能否可靠完成？
这才是 Cerebellum-Brain 架构真正想服务的场景。
17.2 小脑与大脑之间的信息传递仍然有限
当前主要传递：
- ASR 转写文本；
- 少量相关视觉帧；
- 结构化任务状态。
语调、完整视频过程、用户情绪和更细粒度环境变化，可能在传递中丢失。
17.3 两分钟窗口难以支撑长期协作
128 个一秒 Chunk 只能覆盖最近约两分钟。
更长时间的任务需要依赖外部记忆，但论文尚未充分验证：
- 哪些信息应该写入记忆；
- 何时检索；
- 如何避免错误记忆；
- 如何把长期任务状态重新注入实时交互。
17.4 工具任务端到端准确率仍不高
完整系统的工具选择、参数正确率和 Pass@1 都不占优势。
这表明“能自然交互”和“能可靠执行”仍未完全统一。
17.5 训练数据大量依赖合成
对话、智能体轨迹、GUI 描述和质量评价大量使用其他大模型生成或过滤。
这种方式扩展快，但也可能带来：
- 表达模式趋同；
- 真实用户行为覆盖不足；
- 自动评审偏差；
- 合成模型的行为模式被继承。
17.6 人工评价披露不够充分
论文提到内部人工评价认为 Gander 的语音自然且富有表现力，但没有像自动测试那样给出完整、清晰的量化结果。
因此，读者仍难以准确判断它在真实体验上的提升有多大。
18. 总结：从“回答问题”走向“持续协作”
过去的语音助手更像一个问答接口：
你说一句
AI 回一句
传统工具 Agent 更像一个任务执行器：
你交任务
AI 做完后返回结果
Gander 想把两者组合起来：
持续听、看、说
+
异步推理、规划、调用工具
+
用户随时追加、纠正和取消
它用前端小脑维持低延迟交互，用后端大脑承担复杂任务，再通过编排运行时管理任务、权限、状态和结果。
从实验来看，Gander 已经证明了几件事：
- 交互时机可以由模型原生学习；
- 全双工流式模型可以保留较强的语音问答能力；
- 音视频联合输入确实优于单一模态；
- 实时聊天与异步 Agent 任务可以出现在同一套系统中。
但它也暴露了下一阶段最关键的问题：
- 小脑与大脑如何更可靠地交换信息；
- 如何降低语音链路造成的任务准确率损失；
- 如何管理长时间、多模态记忆；
- 如何评价持续数十分钟的人机协作；
- 如何在自然反馈和冗余占位语之间取得平衡。
Gander 不是终点，但它提供了一个值得关注的方向：
下一代 AI 助手可能不再是等待提问的聊天框，而是一个持续感知环境、能够自然交流，并在后台不断推进任务的实时协作者。