OpenMOSS 公开 MOSS-Live 项目资料，将全双工语音、实时视觉与后台推理和工具调用结合，让助手在持续交流时并行执行任务。官方评测显示其部分工具调用和多轮任务指标具有竞争力，但并非全面领先；实际业务仍需独立验证，并自行管理任务取消、授权与执行状态。
OpenMOSS 于2026年11月7日公开 MOSS-Live 项目介绍，提出把实时语音交流与后台任务分开处理：系统一边倾听、说话和理解画面，一边让后台模型继续推理、查询信息或调用工具，待结果准备好后再带回对话。
这次公开的重点，不只是让语音助手回答得更快，而是减少执行任务对交流的打断。不过，能够持续对话与能够可靠完成任务是两回事。官方仓库公布的评测显示，MOSS-Live 在特定工具调用和多轮任务测试中取得了有竞争力的成绩，但并非所有指标领先，相关结果也尚不能替代真实业务中的独立测试。
GitHub 公开事件记录显示，仓库在11月7日转为公开，当天创建 main 分支，并推送项目介绍。这里的日期指项目资料公开，并不等同于产品最早上线时间；API 文档中的日期化快照模型标识，也不能单独作为首次发布日期的依据。
不只是“边听边说”，还要判断什么时候不说
按照官方产品说明，MOSS-Live 采用全双工交互方式，即接收用户声音与输出自身语音可以同时进行。系统试图区分几种表面相似、含义不同的情况：用户说“嗯”可能只是表示听懂，短暂停顿可能是在思考，而新的问题或要求才意味着需要让出话语权。
同样重要的是判断声音是否在对它说话。多人讨论、旁人交谈和导航播报都可能出现在麦克风输入中。官方称，系统会结合上下文选择回应对象，并在用户修改要求、转移话题后保留相关信息，必要时接续此前被打断的解释。
这些能力决定的不是声音是否悦耳，而是交流能否连续。假如系统把每个附和都当成打断，解释就难以完成；若把用户的新要求当作背景音，后台任务又可能沿着错误方向继续。
视觉输入也被纳入同一对话。官方介绍支持摄像头和屏幕共享，让用户围绕眼前场景提问。但这应理解为其公开的能力描述，而不是对任意画面识别准确率的保证。
前台维持交流，后台负责长任务
MOSS-Live 的架构分为前台交互模型、后台模型与协同层。前台处理持续感知、语音表达和回应时机；后台承担复杂推理、工具调用及耗时任务；协同层共享记忆、上下文和任务状态。
官方用旅行规划说明这一分工：用户可以把舟山两日游从徒步改为海边休闲，继续追问轮渡和停车信息，同时让系统在后台查询酒店。另一个会议场景中，系统在讨论继续时查询上海、杭州的天气和活动信息，随后回到讨论中汇报。上述内容来自厂商演示说明，并非本文独立复现的结果。
对开发者而言，关键边界藏在接入指南中：复杂推理和长时间运行的任务可以委派给开发者自己的后端。换言之，前台对话模型并不自动等于一套已经接通所有业务系统的执行服务。
指南列出的稳定模型 ID 为 moss-live-1.0，通过 WebSocket 建立持续双向连接，接收音视频输入并返回语音和文本。官方同时提供 Pi 集成和自定义执行框架的接入路径；后端委派是可选配置，实时对话及自定义工具可以独立使用。公开文档说明了接入方式，但本文没有调用服务验证账户权限、地区可用性或实际运行效果。
评测显示优势，也暴露出取舍
官方仓库列出了 FDB v1、v1.5、v2、v3、Big-Bench Audio 和 τ-Voice 的比较结果。其中，MOSS-Live 在 FDB v3 的工具调用成功率为51.00%，与 Doubao SeedDuplex 并列该表最高；在 τ-Voice 的多轮任务成功率上为57.93%，低于 GPT-Live-1 的67.68%，在该表中位居第二。
这两组数字测量的对象不同，不能混为一个“综合成功率”，更不能解释成面对任意真实任务时的完成概率。它们首先是 OpenMOSS 发布的特定测试结果，而非本文进行的第三方复测。
表格也不支持“全面领先”的结论。例如，在 FDB v3 工具使用场景的响应延迟上，MOSS-Live 为2.36秒，GPT Realtime 2.1 为1.61秒；在 Big-Bench Audio 总体准确率上，MOSS-Live 为88.40%，Doubao SeedDuplex 为90.50%。这些差异提示，自然的轮流发言、语音理解、工具选择与最终完成任务，并不是同一项能力。
因此，官方强调的若干全双工交互优势，应放在对应指标和比较范围内理解。更有价值的问题是：在目标场景中，它是否既能减少错误插话，又能在用户确实需要时及时停下，并把正确结果交回来。
打断回答，不等于取消操作
API 参考文档揭示了另一项容易被忽略的区别：停止语音播放，不会自动撤销业务操作；前台等待超时，也不意味着后台任务已被取消。应用需要自行管理执行状态，并在取消任务时停止实际工作、处理旧结果。
这对旅行、客服或企业助手尤其重要。用户说“换一个方案”时，系统不仅要在声音上停止旧回答，还要判断哪些查询可以继续、哪些操作必须取消，以及已完成的动作是否需要另行处理。将模型接入有写入权限的工具前，开发者仍需设计授权、重复调用防护、审计和人工确认；自然对话本身不能替代这些控制。
这种前后台分工也并非 MOSS-Live 独有。OpenAI 在2026年9月10日的 GPT-Live-1 API 公告中，同样描述了让全双工语音层持续交流、把深入推理和工具调用交给后台文本模型的路线。AIFlux 此前关于GPT-Live-1 从对话走向任务执行的报道提供了这一架构方向的背景，但两者并不是同一次产品事件。
MOSS-Live 此次公开资料的意义，在于把持续交流、实时视觉与后台执行放进了同一套系统设计和开发接口。它是否适合具体业务，仍要由更完整的测试回答：不仅看是否会接话，还要看任务能否正确完成、需求变化能否同步，以及取消和失败是否得到可靠处理。公开项目仓库和接入文档，也不应被等同于模型权重已经开放，或所有部署条件都已得到验证。