Gander 怎样让全模态智能体边说边执行任务

Gander 是一个面向持续音视频交互的智能体系统。它让一个 9B 流式模型每秒判断继续听、开始说或停止当前发言，再把需要检索、调用工具和长时间执行的任务交给后台智能体。全双工交互（full-duplex interaction）在这里指输入和输出可以同时持续流动，模型说话时仍能听见用户，也能根据新信息停下或改变任务。(Orantqing et al., 2026)

这项工作的核心问题很具体。语音助手若先等待用户说完，再依次运行语音识别、大模型和语音合成，就很难处理思考停顿、简短附和、中途打断和不断变化的屏幕画面。Gander 把“什么时候参与对话”纳入模型预测，同时把实时响应与长程执行分给不同部件。

先看一次持续协作

假设用户共享报错画面，并请智能体修复程序。Gander 的前端小脑接收麦克风和屏幕流，建立后台任务。执行期间，用户可以补充“保持 Python 3.12 兼容”，也可以询问进度或取消任务。运行时把补充要求送入当前任务，并阻止旧目标下产生的过期结果成为最终交付。

整个控制流可以压缩为下图。

麦克风、摄像头或屏幕
          ↓ 每秒形成一个时间块
流式前端小脑
  ├─ 继续听
  ├─ 开始说或停止当前发言
  └─ 发出结构化任务调用
          ↓
任务运行时
  ├─ 绑定真实用户话轮
  ├─ 管理任务、执行、权限和结果版本
  └─ 投递进度、问题和最终结果
          ↓
可替换的后台大脑
  └─ 推理、检索、工具调用和长程执行

官方实现默认使用 Codex 作为后台大脑，也提供可替换的 provider 接口。这里的“端到端”主要描述前端小脑对流式感知、交互控制和语音输出的统一建模。完整系统仍包含托管语音识别、任务运行时与外部执行智能体。

每秒先决定是否开口

前端小脑基于 MiniCPM-o 4.5 构建，采用 Thinker-Talker 结构。Thinker 负责感知、交互控制、文本和任务调用，Talker 把 Thinker 的隐状态与文本转换为流式语音。

Gander 将连续交互切成一秒一个 chunk。每个 chunk 依次放入这一秒的音频和视频 token、一个控制 token，以及模型选择生成的文本 token。(Orantqing et al., 2026)

[视频与音频 token] → [控制 token] → [0 到 N 个文本 token]

技术报告给出的控制 token 有三个取值。

控制值	当前一秒的行为
listen	保持沉默并继续接收新输入
speak	生成文本，并交给 Talker 合成语音
interrupt	停止已经不合时宜的当前发言

工具调用由后续的结构化输出表达，不是报告中第四种控制 token。模型先判断是否开口，再生成具体内容。这个顺序让接话决策使用与回答内容相同的最新语义表示，因此可以利用“用户是否表达完整”等信息，而不只依赖静音长度。

上下文最多保留 128 个 chunk，约覆盖最近两分钟。新 chunk 到来后，最旧的内容会被移出滑动窗口，使每一步的计算量保持有界。运行时另行保存任务和执行状态，因此短期模型上下文与长期任务记录是两套机制。

流式感知和说话怎样控制计算量

持续输入会迅速占满 token 预算。Gander 对视觉和音频分别压缩。

• 视频帧以最高 $448\times 448$ 的分辨率进入视觉通道，切片经过 SigLIP 编码和查询式重采样后，token 数压缩为原始 patch 网格的约 $1/16$。
• 音频编码器每秒产生约 50 帧特征，再通过 MLP 做 5 倍时间下采样，送入语言骨干的速率约为每秒 10 个音频 token。

Talker 没有让语言骨干逐个生成高帧率声学 token。它先用一个小型自回归解码器产生单码本语音 token，再由因果流匹配解码器增量生成波形。官方模型卡给出的发布配置在每个一秒单元中最多生成 8 个文本 token 和 50 个 S3 语音 token，并以约 0.5 秒为一个语音输出块。

这些设计都以降低流式计算负担为目标。论文和仓库尚未报告端到端响应延迟、实时系数或单次会话成本，因此目前不能用这些结构参数推导真实设备上的等待时间。

运行时为什么是系统的一部分

前端小脑通过三个任务操作连接后台大脑。

操作	作用
task_start	从当前用户话轮建立后台任务
task_send	补充约束，或发起不改变主任务的旁路查询
task_resolve	取消任务，或处理一次性和会话级权限

运行时把任务操作绑定到传输层确认过的用户话轮，避免模型自行生成的工具参数替代用户的真实指令。它还分别记录 Project、Task、Run、WorkerEvent 和 Delivery。用户修改目标时，系统可以让旧执行结果失效，同时保留任务的最新目标与事件历史。

当前实现传给后台大脑的内容主要是语音识别文本和相关视频的末尾帧。后台没有直接接收完整音视频流。作者把更丰富的双向通信、长期记忆和跨部件协作评测列为后续问题。(Orantqing et al., 2026)

交互时机来自怎样的训练数据

Gander 报告的训练混合包含约 270 万条样本。四类数据分别监督说话内容、交互时机、画面变化、任务生命周期和抗干扰行为。(Orantqing et al., 2026)

数据类别	规模	主要作用
语音交互	101 万	对话、问答、打断、附和与同声传译
音视频交互	110 万	流式视频问答、描述、时序定位与主动提醒
智能体交互	35.96 万	委派、追问、进度、权限、取消和工具推理
鲁棒性与负样本	22.97 万	无关画面、无人指令、噪声、重叠说话和多人场景

其中 26.08 万条 InteractionSpeech 对话显式标注竞争性打断和支持性附和。每一轮都有开始时间、持续时间与重叠区间。用户在助手说话时发出简短的“嗯”可以保留助手的话轮，真正提出问题或要求停止则需要让出话轮。数据构造把时间位置变成训练信号，这是 Gander 最容易迁移到其他实时语音系统的设计之一。

这批数据经过规则过滤和 LLM 评分。合成数据的自然度、覆盖范围与评分器偏差仍需要真实对话和独立评测检验。

抢话率 8% 究竟表示什么

Full-Duplex-Bench v3 包含 100 个带工具的语音服务场景。论文报告的 Interrupt 是模型在用户结束发言前开始回应的被测话轮比例。8.0% 不能改写为“任务准确率 92%”，也不能在缺少评分明细时直接断言为“恰好 8 个场景抢话”。

抢话率需要与 Take-turn 一起读。系统只要一直等待，就可能降低抢话率，却会错过应当接话的时机。Gander 在论文表格中同时得到 100.0% 的 Take-turn 和 8.0% 的 Interrupt。(Orantqing et al., 2026)

系统	Take-turn	Interrupt	严格 Pass@1
Gander	100.0%	8.0%	0.400
GPT-Realtime	96.0%	13.5%	0.600
Gemini Live 3.1	78.0%	19.2%	0.540
Whisper、GPT-4o 与 TTS 级联	100.0%	33.0%	0.450

这组结果支持一个有限结论。在 Full-Duplex-Bench v3 的 100 个场景中，Gander 在论文所列七个系统里取得最低抢话率，同时没有牺牲 Take-turn。测试规模较小，论文没有报告置信区间，公开页面也没有提供独立复现结果，因此 5.5 个百分点的领先幅度还不能视为稳定的总体差异。

任务执行指标呈现另一面。严格 Pass@1 要求工具集合及每个参数全部正确，Gander 的 0.400 低于表中六个对照系统。工具选择 F1 为 0.759，参数正确率为 0.503。绕过前端小脑和语音路径后，同一个后台大脑在文本输入条件下得到 0.934 的工具选择 F1 与 0.520 的 Pass@1。这个对照说明前端路由和语音处理路径带来了明显损失，但实验没有进一步分离委派判断、语音合成和再次识别各自的影响。

论文还报告 51.6% 的 Filler。该指标判断模型接过话轮后是否先说“我来看看”一类占位表达，分母是 91 个成功接话、没有抢话且得到延迟分析判定的场景。它反映接话后的表达方式，不能与抢话率当作同一个指标解释。

音视频融合有收益，也出现能力回退

Gander 在 Daily-Omni 上得到 78.53% 的准确率，接近起点模型 MiniCPM-o 4.5 的 80.20%。它在 WorldSense 上得到 49.62%，低于起点模型的 55.70%。这表明全双工与智能体后训练没有均匀保留原模型的所有感知能力。

消融实验中，音视频联合输入相对较强的单模态输入在 WorldSense 上高 5.01 个百分点，在 Daily-Omni 上高 19.13 个百分点。这些数字说明联合输入在两套题目上增加了可用信息。论文没有加入只做简单特征拼接的融合基线，因此还不足以把增益归因于某一种特定融合机制。(Orantqing et al., 2026)

目前适合怎样评价 Gander

Gander 提供了三个可复用的系统思想。

1. 交互时机可以作为显式监督目标，让模型持续预测听、说和停止。
2. 实时交互与长程执行可以使用不同计算层级，并通过结构化任务协议连接。
3. 任务目标、一次执行和结果投递应分别记录，用户修改要求后才能可靠隔离过期结果。

现有结果还不足以证明这套系统已经达到稳定生产可用。论文是 2026 年 9 月发布的 arXiv 预印本，评测由作者团队完成。官方发布配置把 Thinker、Talker 和语音识别分别放在三张物理 GPU 上，后台大脑还需要单独配置。论文尚未给出端到端延迟、成本、长时间会话成功率和真实用户协作效果。现有基准也分别测试交互时机、工具执行和音视频理解，没有直接测量前端小脑与后台大脑在长任务中的整体协作质量。

开源状态与参考资料

截至 2026 年 9 月 14 日，官方 GitHub 仓库 已提供 Apache 2.0 许可的代码，Hugging Face 模型页 已提供匹配的 Thinker 与 Talker 权重。官方仓库仍将数据集标记为 “Coming soon”，因此当前不能写成训练数据已经开放。

• Omni Interaction Agent Technical Report · Trackback 记录(Orantqing et al., 2026)
• Gander 官方技术页面
• Gander 官方代码仓库
• Gander 模型卡与权重
• Full-Duplex-Bench 官方仓库

本文依据技术报告 v2、官方项目页、代码仓库、模型卡和基准仓库整理，核验日期为 2026 年 9 月 14 日。文中的结构、训练规模和分数均为作者报告结果；本文未在本地运行模型、复现基准或开展独立用户研究。

Orantqing, Ji, S., Tong, J., Zuo, J., Fu, D., Cao, D., Li, Y., Wu, S., Franz, Evan, Theron Veyra, Pan, C., Lu, J., Yang, D., Xie, Z., Tan, Y., Shen, X., Yang, X., Wang, W., … Zhao, Z. (2026). Omni Interaction Agent Technical Report. https://doi.org/10.48550/arXiv.2609.08977