Deep Research · 深度技术调研
Realtime-Venus：双循环实时多模态 Agent 系统调研
蚂蚁集团 Venus Team 与清华大学的开源全双工音视频 Agent 系统——架构、benchmark 真伪、部署现实，以及它到底能不能算「OpenAI Realtime API 的开源替代」。
调研时间 2026-10-17 / 18论文 arXiv:2609.13814（v3，2026-09-23 修订）标注 官方声称 论文 / 模型卡 / 官方仓库 · 第三方验证 独立分析与实验
总体判断
Realtime-Venus 是一套研究级、可下载、可魔改的原型系统，而不是生产可用的「OpenAI Realtime API 开源替代」 。它的 dual-loop 架构（前台 1 秒 chunk 全双工交互 + 后台 Harness 异步执行、结果经私有通道带回对话）是对「边聊边做」这一真实矛盾的完整建模，权重与代码以 Apache-2.0 完整开源。但截至 2026-10-18：全部 benchmark 数字均为作者自报、评测脚本未公开、无任何独立复现 ；唯一真实的第三方实验还给出了负面信号；无毫秒级延迟数据、无托管推理服务、无 API 与定价。适合做全双工 / 异步委托方向的预研原型，不适合直接作为智能眼镜、车载助手的量产基座。
2 × 9B
开源模型：Omni（音视频）+ Audio（纯语音），Apache-2.0
188 stars
GitHub 仓库（2026-09-16 创建，9 commits，13 forks）
0
托管推理服务 / 第三方部署——HF 官方注明无任何 Inference Provider 上线
0
独立复现——无第三方评测、无 leaderboard 条目
A100
官方在线 duplex demo 的最低硬件要求（单卡）
280 万+
后训练样本（9 类），只更新 Thinker、声学解码器冻结
目录
三组件架构与双循环机制 训练方法与数据 Benchmark 声明与限定条件 第三方验证：基本为零 代码与部署现实 与 OpenAI Realtime API 对照 智能眼镜 / 车载助手场景 风险与局限 无法确认 / 开放问题 综合判断与来源
01 三组件架构与双循环机制系统由两个 9B 前端模型和一个执行框架组成：Realtime-Venus-Omni 负责音视频持续感知，Realtime-Venus-Audio 是原生全双工语音模型，Realtime-Venus-Harness 把复杂推理、搜索和工具调用委派给后台异步执行。核心设计是把「实时交互」和「耗时任务」拆成两条并行运行的链路——前台对话永不因等待任务而中断。
用户
持续音视频输入 · 随时说话 / 打断
前台交互循环 · 延迟敏感
Realtime-Venus-Omni / Audio（9B）· 以 1 秒 chunk 持续感知与原生语音生成
<|listen|> 继续感知 · <|speak|> 说话 · <|turn_eos|> 结束话轮
说话与后台执行期间，感知保持活跃；未说出的内容可修订
后台能力循环 · Realtime-Venus-Harness
Capture 捕获 → Dispatch 路由 → 执行 → Return 回传
对隔离的会话快照执行；默认后端：Codex CLI / Gemini API
QUEUED → RUNNING → COMPLETED → DELIVERING → DELIVERED
媒体流
原生语音
<delegate> 请求
证据快照在开标签时刻固定
<backend> 私有通道
前端决定何时说出
Dual-loop 运行时：两条循环只交换两样东西——以请求因果上下文为界的 task package，和绑定到原会话的 prepared reply。内容与措辞归 Harness，时机与语音输出归前端。
REALTIME-VENUS-OMNI 音视频持续感知前端 官方声称
构成 ：改编自 MiniCPM-o 4.5 的 Omni-Flow 架构——SigLIP2 视觉编码器 + Whisper-Medium 音频编码器 + Qwen3-8B 主干；语音用离散 S3 token + streaming flow-matching 解码器（参考音频来自 system prompt）；上下文 40,960 tokens，BF16。流式组织 ：以 1 秒为单元，每单元交错当前帧视觉 token 与时间对齐的音频特征（约 10 个音频特征/秒）。每单元由 LLM 预测 <|listen|> 或 <|speak|>；<|chunk_eos|> 关闭语音 chunk，<|turn_eos|> 结束话轮。Omni-Proactive ：持续观看 + 聆听，无需唤醒词，事件值得回应时主动发起语音。免训练长视频记忆 ：外部记忆模块以运动补偿预测代价做视觉门控决定归档哪些帧，检索用 MaxSim 风格 token 级匹配 + MAD 加权 + MMR；HF 卡示例 model.use_memory(memory_minutes=40)，检索上限 96 历史帧 + 4 近帧。自报在 60–90 分钟 LVOmniBench 子集上 +5.88pp——但论文承认增益依赖 backbone（MiniCPM-o 4.5 在某些时长 bin 上记忆反而下降）。
REALTIME-VENUS-AUDIO 原生全双工语音 官方声称
同一流式主干上单独训练 的音频专用 checkpoint：去掉 ViT 视觉分支，只处理流式音频；输入音频 + 文本，输出文本 + 原生语音。
Thinker–Talker 架构 ：LLM（Thinker）联合预测交互控制 token、前台文本与 delegate 文本；语音解码器（Talker）从 LLM 隐状态生成 S3 token；训练中声学解码器冻结 ，只更新 Thinker。打断语义 ：按会话功能而非纯 VAD 区分重叠语音——停顿 / 背景噪声 → <|listen|>；backchannel（「嗯 / 对」）→ 保持 <|speak|> 继续说；真正的打断（纠正 / 重定向 / 新请求）→ <|turn_eos|> 终止过期回复：已播放音频不变，未说部分 stop / reject，并做 repair / update 或 redirect / follow-up。
REALTIME-VENUS-HARNESS 后台异步执行框架 官方声称 Harness 与两个前端共享，但不在模型权重里，在 GitHub 仓库中 。它是一个独立 Python 包（pip install -e ./harness，Python 3.11 / 3.12），核心是 DelegateHarness + DelegateBackend 协议（plan / execute / oralize / aclose）。
STAGE 1
Capture 捕获 协议门跨 chunk 组装 <delegate>…</delegate> span；证据快照 Xi 在开标签时刻固定 （时戳 + 序列 fence，media 裁剪到允许窗口，此后观测不能改写）——即「因果任务捕获」；一个请求至多生成一个 work item。
STAGE 2
Dispatch 路由 注册表 C = {γmm 多模态直接回答， γgen 通用多步任务} ∪ skills；router 基于 capability contract + 紧凑证据摘要做一次 模型决策选 capability 与参数（不看 raw media），schema 校验拒绝非法选择。
STAGE 3
Return 回传 adapter 把执行结果 polish 成口语 reply 文本、去掉保留控制 token，包成私有 <backend> 消息；经新鲜度检查 判断结果是否过期，再做 playback-aware 投递。
生命周期：QUEUED → RUNNING → COMPLETED → DELIVERING → DELIVERED ｜ FAILED ｜ CANCELLING → CANCELLED
关键事实：默认执行后端是闭源外部服务
Harness 的默认任务执行后端是
Codex CLI （
codex app-server，需 Codex 登录）或
Gemini API （自备 key）。也就是说，这个「开源」系统的关键执行环节依赖闭源外部服务——9B 前端本身不做复杂推理与工具执行。
「带回当前对话」是怎么实现的
官方声称 前台循环连续处理输入媒体、更新会话状态 sk ，决定 listen / speak / yield；形式化为 (sk+1 , Ok ) = Fm (sk , xk m , bk ; ηk )，输出 Ok 包含交互控制、前台文本、delegation 文本与语音 token，其中只有前台文本与语音面向用户。后台结果经私有 background channel 回到原会话，在 chunk 边界被接纳为 background input bk ，成为前端的私有上下文；前端再按已播放语音时长自适应调度每 chunk 的文本 token 数，决定何时把结果说出来。
第三方验证 报告中最有价值的一点
第三方分析 orcarouter 指出：后台任务对
隔离的会话快照 执行，对话继续推进不会污染长任务——这是多数「边聊边做」设计在实践中倒下的故障模式，也是这份报告最值得借鉴的设计。
来源：orcarouter.ai 分析 （verified live）
本节来源：论文 §3 / §4 / §5，arxiv.org/html/2609.13814v1 （verified live）；Harness 代码 github.com/inclusionAI/Realtime-Venus/tree/main/harness （verified live）。
02 训练方法与 9B 取舍官方声称 统一后训练语料 280 万+样本、9 类 。能力配比：离线理解约 56%，proactive duplex 约 37%，delegation 约 6%。覆盖中文、英文与 code-switch；duplex / delegation 数据天然含打断样本。
后训练语料构成（样本数）
论文 §4.5（verified live）。Video 类为 Omni 独占（约 70%），Audio 类两模型共享（约 30%）。
通用 AV 理解（Video） 936k
通用音频理解（Audio） 470k
Visual-proactive duplex（Video） 454k
Speech-in duplex（Video） 315k
口语问答（Audio） 205k
Omni-proactive duplex（Video） 201k
Speech-only duplex（Audio） 100k
Delegate（Video） 95k
Delegate（Audio） 90k
数据管线 （§6）：场景规划 → 副语言 / 声学实现（迟疑、笑声、呼吸、重叠、环境音）→ 时间对齐物化；duplex 目标（继续说 / 等待 / 让出话轮 / 停掉排队输出 / 修订回复）与 delegation 目标（保留 / 取消 / 修订 / 重试 / 回退在途工作）在同一时间轴上联合监督。训练配方 ：单次后训练 pass 混合三类数据；loss 只在 response span（排除 system / user / media 占位）；per-sample 归一化；长回答用 LM-head 分块 CE + recomputation；只更新 Thinker 。9B 取舍 ：沿用 MiniCPM-o 4.5 的 9B 量级，目标是单机可部署的实时流式推理（HF 卡示例为 .cuda() 单卡加载）；代价是复杂推理 / 工具执行必须外包给 Harness 后端。
第三方验证 「单机可部署」要打个问号
orcarouter 指出：9B BF16 ≈ 18GB 权重，实时 duplex 推理仍需 serious GPU，「够不着 MiniCPM-o 家族原本面向的笔记本部署」。论文未来工作也承认，需要验证该架构在百 B 量级是否保持优势。
03 Benchmark 声明与限定条件以下数字全部为作者自报 （论文表格，verified live），先看数字，再看论文自己写下的限定条件——后者决定这些数字能信几分。
Omni 视频流式理解 官方声称
Benchmark Realtime-Venus-Omni 备注
StreamingBench 70.2 online 模型第一；离线基线 Gemini-3.5-Flash 为 77.3 OVO-Bench 64.7 online 模型第一 Daily-Omni 81.3 online 模型第一；相对基座仅约 +1pp（见下方质疑） ProactiveVideoQA 46.2 输给自己的基座 MiniCPM-o 4.5（47.5） OmniPro 29.0 online 模型第一 WorldSense 54.0 输给自己的基座 MiniCPM-o 4.5（54.2） OmniVideoBench 39.2 online 模型第一 LVOmniBench 38.9 online 模型第一
出处：论文表 2。「8 个中 6 个第一」只统计 online 模型；离线基线 Gemini-3.5-Flash 在 8 项上全部远高，仅作参考单列。
Audio 音频理解与口语问答 官方声称
Benchmark Realtime-Venus-Audio 对照
MMAU 78.0 对比模型最高（论文表 4） MMAU-Pro 63.2 对比模型最高 MMAR 65.6 第二；Qwen3-Omni 66.4 第一 MMSU 66.8 Qwen3-Omni 69.0、Fun-Audio-Chat 67.8 更高 AlpacaEval（口语问答） 4.81 并列最高（论文表 5） Llama Questions 83.8 最高 Speech TriviaQA 75.7 第二；Qwen3-Omni 75.9 Speech CMMLU 67.8 最高——中文语音是其强项之一
全双工：续话率领先，打断响应并不领先 官方声称
FDB v1.5 续话率（越高越好）
用户发出 backchannel / 指向他人的语音 / 背景语音时，模型正确「不被带偏、继续说」的比例。论文表 6。
Backchannel（「嗯 / 对」类附和）
Venus-Audio 0.97
Gemini 3.1 Live 0.95
GPT-4o 0.70
Other-directed（对别人说话）
Venus-Audio 0.88
Gemini 3.1 Live 0.66
GPT-4o 0.02
Background（背景语音）
Venus-Audio 0.86
Gemini 3.1 Live 0.66
GPT-4o 0.04
必须同时看到的三个限定（论文自己写的）
打断响应率 0.75 并不领先 ：低于 Joy-Duplex（0.88）、GPT-4o（0.78）、Gemini 3.1 Live（0.77）——论文原文承认 "interruption-response rate is lower than those of Joy-Duplex, GPT-4o, and Gemini 3.1 Live"。Gemini 3.1 Live / GPT-4o 的 FDB v1.5 数字引自其他论文 （JoyAI-Talker 论文与 FDB 原论文），非作者实测。
自建 delegate benchmark 为内部基准 ：Omni 总体 75.93% vs Audio 68.89%；Audio 严重过度委托 （routine 请求 specificity 仅 39.44%），Omni 则漏委托 （external recall 68.33% vs Audio 92.22%）——路由偏差是系统性的，两个模型各偏一头。
工具调用：GPT-Realtime 全面领先 官方声称
FDB-v3 工具调用（%）
论文表 7。参数准确率与 Pass@1 是 Venus 与 GPT-Realtime 差距最大的地方。
Tool F1
Venus-Omni 86.0
Venus-Audio 85.0
GPT-Realtime 87.6
参数准确率
Venus-Omni 53.1
Venus-Audio 54.2
GPT-Realtime 68.0
Pass@1
Venus-Omni 43.0
Venus-Audio 48.0
GPT-Realtime 60.0
04 第三方验证：基本为零，一次负面信号
无独立复现 ：orcarouter（2026-09-18）确认「无第三方发表过评测、无 leaderboard 条目」；截至 2026-10-18 本调研仍未发现复现。评测脚本未公开 ：GitHub issue #3（2026-10-15）有人公开索要 "FDBench v1.5 Evaluation Scripts"，无下文。外部无法验证全双工数字。来源：github.com/inclusionAI/Realtime-Venus/issues （verified live） 提升幅度被质疑 ：orcarouter 指出 Daily-Omni 81.3 相对基座仅约 1pp 提升（其引 MiniCPM-o 4.5 为 80.2；论文表 2 基座为 79.4，口径或有 memory 差异），「post-training + runtime 的巨大投入换来约一个点的提升」。无毫秒级延迟数字 ：1 秒 chunk 是设计参数，不是实测 time-to-first-audio——而延迟正是这个品类「实际购买」的指标。其余第三方内容（aiweekly、dev.to、artrealmai）多为论文数字转载，无独立验证；artrealmai 的定性是 "research-grade…will not replace every cloud realtime API tomorrow"。
唯一真实的第三方实验：DuplexAgent-RSI 第三方验证
香港中文大学（深圳）+ Amphion 的 DuplexAgent-RSI 论文（arXiv:2610.11299，2026-10）是目前唯一实际运行 Realtime-Venus-Omni 的公开发表实验。结论对 Venus 不利：其纯自然语言 <delegate> 握手在精确工具调用 上显著退化。
自然语言 delegate 握手 vs 结构化基线（分数）
DuplexAgent-RSI 实验（verified live）。退化原因据作者分析：到达评分器的 transcript 常常是 delegate span 或回执，而不是答案本身。
BFCL（函数调用，平均）
基线 68.8
Venus 握手 46.5
BFCL parallel / parallel-multiple（子项）
parallel 基线 71.0
parallel 握手 35.0
p-multi 基线 53.0
p-multi 握手 22.0
口语问答 OBQA / 语音理解 MMSU
OBQA 基线 84.1
OBQA 握手 41.4
MMSU 基线 64.5
MMSU 握手 27.4
FDB-v3 Pass@1（该实验口径）
Venus 握手 1.0
解读需带 caveat
作者结论是：prose（自然语言）握手适合模糊任务，在需要精确函数名 + 参数的场景是系统性短板。
但该文是竞品论文 （推销自家 DuplexAgent harness），解读有立场——实验本身是真实的第三方运行信号，其结论方向与 Venus 论文表 7 中参数准确率偏低的现象相互印证，但具体幅度不宜直接当作定论。
来源：arxiv.org/html/2610.11299 （verified live）
05 代码与部署现实
项目 现状
HF 权重 inclusionAI/Realtime-Venus，Apache-2.0；双 checkpoint（sharded safetensors + 自定义 Transformers 代码）；含 requirements.txt、参考音色与 Token2wav assets、download_models.py；另有 ModelScope 镜像。HF 采用信号 "Downloads last month: -"（不追踪下载量 ）；"This model isn't deployed by any Inference Provider"（无任何托管推理 ）。 GitHub 仓库 2026-09-16 创建；9 commits；188 stars / 13 forks ；1 个 release（Android APK beta Realtime-Venus-0918.apk）；目录含 harness/、frontend/、demos/、tests/、install.sh / start.sh / config.json / LEGAL.md。 Issue 活跃度 仅 2 个 open（#3 索要 FDB 评测脚本；#1 请求接入 audio.cpp）；无讨论热度。 文档完整度 Harness README（含全部配置字段）、demo 配置指南、Omni / Audio cookbook 示例完整；评测脚本缺失 ；demo 要求 A100。 硬件要求 在线 duplex demo 至少 1× NVIDIA A100 （官方 README）。离线示例为标准 AutoModel.from_pretrained(...).cuda() 单卡加载。9B BF16 约 18GB，加上 KV cache / activation 与双编码器，属「严肃 GPU」级别。 推理框架 无 vLLM / SGLang 等第三方推理框架支持 该自定义 duplex 调度，只能用官方 model server 或自研。无消费级单卡（如 24GB）运行报告。Demo 形态 浏览器 demo 需自托管（Linux + CUDA，按 install.sh / start.sh 部署，SSH 隧道访问），单会话 ；serving 链路：模型服务（HTTP 8031）→ session host → 浏览器 UI（HTTP / WebSocket 8032）。Android 仅 beta APK，无下载 / 反馈数据。 采用信号总览 下载量不可见；188 stars / 13 forks（截至 2026-10-18）；2 个 issue；无公开应用案例、无社区部署报告 。
来源：huggingface.co/inclusionAI/Realtime-Venus 、github.com/inclusionAI/Realtime-Venus （均 verified live，2026-10-18）。
06 与 OpenAI Realtime API 的能力对照对照基准为 2026 年多家行业文档与实测（含 callsphere 约 280k 会话实测，详见来源）。结论先行：这不是 drop-in 替代 ——Venus 是「自托管研究级全双工前端 + 异步委托框架」，两者甚至不在同一个产品形态上。
维度 OpenAI Realtime API（2026 现状） Realtime-Venus
协议 / 接口 WebRTC（浏览器 / 移动端推荐）+ WebSocket + SIP （可直接终结 PSTN 来电）；GA（2025-08-28）；ephemeral key 鉴权；官方 SDK / 生态 无云端 API ；demo 为自托管 HTTP(8032) + WebSocket 浏览器应用，模型服务 HTTP(8031)；无 SIP / 电话接入、无生产鉴权 / 多租户工具调用 原生函数调用（含 MCP），可在响应中途触发；FDB-v3 87.6 / 68.0 / 60.0 全面领先 自然语言 <delegate> → Harness 路由到 capability / skill，非 JSON schema 函数调用 ；FDB-v3 落后（Omni 86.0 / 53.1 / 43.0）；第三方实验显示 prose 握手精确参数传递显著退化 延迟 首包约 300ms（WebRTC），glass-to-glass 中位数 <200ms（实测）；函数调用 +400–800ms 无毫秒级延迟数据 ；1 秒 chunk 为设计参数；time-to-first-audio 未公布中文语音 70+ 输入语言（Translate 模型），多语言语音到语音；9 个内置音色 训练含中文 + 英文 + code-switch；Speech CMMLU 67.8 第一；但无中文语音主观质量评测 （MOS 等）；仅单参考音色 打断 / 全双工 server_vad / semantic VAD，audio_interrupted 原生打断 FDB v1.5 续话率三项第一（0.97 / 0.88 / 0.86），但打断响应 0.75 低于 GPT-4o(0.78) / Gemini 3.1 Live(0.77) / Joy-Duplex(0.88)；数字未被独立复现 运维 / 生态 计费、prompt cache、Agents SDK、LiveKit / Twilio 集成、用量可观测 需自建 serving；Harness 默认后端依赖 Codex 登录或 Gemini API key；demo 单会话、无可观测性
第三方验证 两者的失败面正好相反
orcarouter 的对照结论：Grok / OpenAI 侧的问题是厂商锁定与营销数字不可验证，Venus 侧的问题是「没人真正跑过」。Venus 的真实优势在权重可下载、可魔改 Harness、数据不出域、Apache-2.0；差距在生产延迟 / 可靠性数据、工具调用精确度、协议与生态完整性、运维成熟度。
07 适用场景：智能眼镜、车载助手「持续感知 + 随时交流 + 后台执行任务」正是 dual-loop 建模要解决的问题，方向契合。但真实落地门槛有六道：
算力门槛 ：官方要求 A100 级 GPU 做在线 duplex demo；眼镜 / 车机端侧不可能承载，至少需要云端常驻推理，端云协同架构不可避免，而延迟预算未知（无实测数据）。延迟未知 ：1 秒 chunk cadence 下的端到端 time-to-first-audio、打断响应延迟均无公布数据；车载唤醒 / 打断体验无法做 SLA 承诺。工具执行要自研 ：Harness 默认后端是 Codex（代码任务）/ Gemini（通用），车载场景（导航、车控、POI 检索）需自己实现 GeneralAgentPort / 注册 skill，并补齐沙箱、超时、取消、重试——论文未来工作自己也点名「从延迟 / 失败工具调用中恢复」是开放问题。生产化缺件 ：demo 只支持单会话；无鉴权、多租户、计费、可观测；无 vLLM / SGLang 支持，serving 只能基于官方示例自研；Android 仅 beta APK。语音质量 ：中文语音有训练覆盖且 Speech CMMLU 第一，但无 MOS / 主观评测；单参考音色，车载多角色 / 品牌音色需自研。工程代价量级 ：以「算法原型 + 可魔改框架」计，需 1–2 名多模态推理工程师做 serving 与延迟优化，1 名后端工程师对接 Harness skill 生态；以「产品 SDK」计则差距甚远。
场景结论
适合作为
预研原型 验证「持续感知 + 后台委托」的产品形态，不适合直接作为量产方案的基座。
08 风险与局限
trust_remote_code=True 的供应链风险local_files_only=True，执行的仍是仓库自定义代码逻辑。Apache-2.0 的范围 ：代码与权重均为 Apache-2.0（GitHub 明确）。但 HF 卡明确加注需另行审查上游模型、第三方库与数据的许可与可接受使用条款 ——基座链 MiniCPM-o 4.5 → Qwen3-8B、Whisper、SigLIP2 各自许可需核查（Qwen 系列有自有许可），Apache-2.0 并不自动覆盖全链条。另 LEGAL.md 规定中文注释为准 。可复现性缺失 ：评测脚本未公开（issue #3），全双工核心数字外部无法验证；对比基线中 Gemini / GPT-4o 数字引自他文。已知能力短板 ：打断响应率非最优（0.75）；Audio 过度委托 / Omni 漏委托的系统性路由偏差；prose delegate 在精确工具调用上经第三方实验证实退化；论文承认 delegation 执行成功与结果整合「需要额外评估」。安全面 ：delegate 是自然语言——恶意音频 / 视频可做 prompt 注入，诱导前端发出恶意 delegate；Harness 执行任意 skill / tool，官方 demo 的 Codex workspace 无沙箱说明，生产接入必须自建隔离。项目活跃度风险 ：发布一个月仅 9 commits、2 个 issue、无官方路线图；蚂蚁官方渠道无任何发布声明，存在「论文配套仓库、后续不再维护」的可能。
09 无法确认 / 开放问题以下问题在本次调研中没有找到答案 ，如实列出，不做推测填充：
Q 全双工数字（75% / 97% / 88% / 86%）无独立复现；评测脚本未公开。Q 端到端延迟（time-to-first-audio、打断响应延迟）无任何数据。Q 消费级 GPU（24GB）能否跑通 duplex：无官方承诺、无社区报告。Q 中文语音主观质量：无 MOS / AB 测试。Q Harness 在生产流量下的稳定性、并发能力：demo 仅单会话。Q 蚂蚁是否有产品化 / API 化计划：官方零表态。
10 综合判断Realtime-Venus 是一个真实可用、许可宽松但成熟度处于研究原型阶段 的开源项目。它的 dual-loop 架构（前台 1 秒 chunk 全双工交互 + Harness 对快照化任务做异步执行、经私有通道带回对话）是对「边聊边做」这一真实矛盾的完整建模，权重、代码、demo 一应俱全，Apache-2.0 且可本地部署，这是它相对闭源 API 的真实价值。但三项硬伤决定了它的使用者画像：① 所有 benchmark 数字均为自报且评测脚本未公开，唯一第三方实验还给出了负面信号（自然语言委托在精确工具调用上显著退化）；② 无延迟数据、无托管服务、无生产级运维件；③ 默认任务后端依赖 Codex / Gemini 等外部闭源服务。
适合
研究者与原型团队 做全双工 / 异步委托方向的研究者；需要数据不出域的语音交互原型团队；想魔改 Harness 做自研 skill 的工程师。
不适合
找 drop-in 替代的团队 寻找 OpenAI Realtime API 开源替代、或要直接量产智能眼镜 / 车载助手语音方案的团队——至少要再投入 serving、延迟优化、工具生态三项工程，并先独立复现论文数字。
下一步
先复现，再决策 若考虑采用：先在 A100 上跑通官方 demo 并自测延迟与打断体验；审计 trust_remote_code 代码并 pin revision；核查基座链全链条许可。
来源清单
官方（论文 / 模型卡 / 代码，verified live 2026-10-18）
第三方（verified live / index，2026-09 / 10）
本报告基于 2026-10-17 / 18 的深度调研整理：结论标注分为（论文 / 官方模型卡 / 官方仓库）与（独立分析与实验）两类；所有 benchmark 数字均为论文自报，截至调研时无独立复现。开放问题一节列出的是调研中未能确认的事项，未做推测填充。