MOSS-Live 让语音 AI 边聊边办事，任务进行时还能补要求

11 月 7 日，OpenMOSS 团队介绍 MOSS-Live，把全双工语音对话与后台任务执行放进同一个实时交互系统。对开发语音助手、导览和会议工具的团队，它提供了一种让用户在查资料期间继续提问、修改要求的接入方式。本文沿着官方架构和 API，梳理怎样接住打断、更新任务，并把仍然有效的结果带回对话。团队介绍

原创 AI 概念插画，以两条相连路径表现实时对话与后台任务。

[配图建议：一条路径承载对话气泡，另一条承载地图和资料，两者通过小桥连接 + 暖沙色、珊瑚色与灰蓝的编辑插画。]

一、查资料时，前台还能继续听你说

设想你正在规划周末出行，让助手寻找住宿。查询尚未完成，你又补充“我们带着孩子，最好离海边近一点”，接着询问停车情况。一次自然对话，会同时出现持续中的任务、新的约束和临时追问。

MOSS-Live 的官方架构把这些节奏分开处理。前台交互模型负责持续感知、说话以及判断何时接话，后台模型处理复杂推理、工具调用和较长任务。协调层共享记忆、上下文和任务状态，帮助前台了解后台进展，并在合适时机引入结果。架构说明

前台对话可以持续，后台任务有自己的执行进度。这使“我正在查”之后的时间能够继续用于澄清需求。对交互设计而言，重要变化是让任务等待与用户表达形成并行流程。

官方提供在线体验和实时 API，当前场景指南列出的模型 ID 为 moss-live-1.0，连接使用 WebSocket。自定义工具可以独立接入，较复杂任务还可以交给开发者自己的后台执行环境。接入指南

团队公开演示覆盖会议、自驾规划和城市导览。它们展示了目标体验，产品验证仍应回到自己的麦克风、网络、工具和真实问法。本文采用出行查询作为分析场景，重点看需求在途中改变时，系统怎样衔接。

[配图建议：前台对话时间线与后台查询时间线并行，新增约束通过协调点进入任务 + 双时间线信息图。]

二、接住一次打断，播放器也要参与

全双工意味着系统在说话时继续接收用户声音。交互中还需要判断语义。轻声回应“嗯”可能表示继续听，明确的新问题则可能要求让出话轮。MOSS-Live 的产品说明把这类选择性回应作为核心能力之一。全双工能力说明

真正落到应用中，还存在音频队列。服务器已经生成的一段语音，可能仍在设备里等待播放。用户提出新要求后，应用需要正确处理旧回答的剩余音频，才能让对话顺畅切换。

官方指南要求客户端在播放时继续上传麦克风音频。收到 response.audio.stop 后，按对应的 run_id 和 turn_id 停止播放、清理队列，并报告播放停止。客户端还应根据实际播放进度发送完成确认。播放与打断流程

生成完毕、传输到达、用户听完，是三个不同的状态。开发者可以把它们分开记录。测试时听到旧句子仍在继续，就检查播放队列与停止事件；新输入未被接收，则继续检查音频采集和上传路径。

字幕也有自己的更新节奏。官方说明，转录更新事件中的文本是当前完整内容，界面应替换显示。用一个稳定的文本位置呈现修订，更容易让用户核对助手究竟听见了什么。转录事件说明

[配图建议：语音生成、音频排队与实际播放分别画成三个位置，停止事件指向对应的旧回答队列 + 清晰的播放器流程图。]

三、用户改了目的地，后台任务要带上版本

继续前面的例子。助手已在查询舟山住宿，用户改口“我们改去宁波，仍然想靠海”。此时，需要处理的对象包括新一轮语音回答，以及尚未结束的住宿查询。

MOSS-Live 的 API 为异步工具提供任务标识和修订机制。只读查询可以使用 async_query，带副作用的操作对应 async_effect。异步调用携带 task_id、revision 与独立的 call_id，应用可以据此关联任务、参数版本和具体执行。异步工具协议

需求改变时，未完成的异步任务可以修订参数。服务器以新的修订号和调用标识重新发出调用。修订请求需要提交当前观察到的版本，发生冲突时由应用处理。这给开发者提供了一组明确的对应关系。

需要停止旧调用时，协议会发出取消请求。应用承担停止实际执行、丢弃迟到结果的工作。对于已经完成的业务操作，还需要按自身业务处理后续状态。修订与取消约定

因此，可以给出行查询设计一项具体验收。先启动目的地甲的查询，再改成目的地乙，刻意让甲的结果晚到，观察最终播报是否仍对应乙。任务身份与当前参数版本，应贯穿执行、回传和播报。这一测试建议由本文提出，能帮助团队检查自己的工具适配。

更复杂的后台 Agent 使用客户端委派模式，通过委派标识关联进度和结果。API 还说明，当前回答等待结果超时后，后台任务可以继续运行，其执行超时由应用控制。界面可以据此分别显示“当前回答已结束”和“任务仍在进行”，再按实际结果更新。客户端委派说明

[配图建议：同一个查询任务从目的地甲修订到乙，旧结果晚到时进入停止处理，新结果沿当前版本回到对话 + 带版本标记的任务流示意图。]

四、先用一项只读任务，验证整条对话链

首次接入，可以先按场景指南打通普通语音对话，再增加一个容易核对的只读查询。准备好服务端认证与 WebSocket 转发，收到会话确认后启用输入，并记录每轮转录、播放状态与任务事件。

若要试后台 Agent，官方提供 Pi 配套示例，要求 Node.js 22.19.0 或更新版本，支持 macOS 和 Linux。配置后台模型的服务商、地址、模型 ID 和密钥后，可以运行示例。默认工具范围是 read / grep / find / ls，适合先从资料读取开始。后台接入示例

下面是一份本文整理的试用记录，便于把体验问题落到可观察的结果。

先把一个任务做完整，再扩大工具范围。可以记录发出请求、用户补充要求、工具返回、开始播报和实际播完的时刻。语音体验、工具耗时和人工返工分别留账，后续调整才容易找到原因。

阅读成绩时也要分项。团队公布的比较中，FDB v3 工具使用成功率为 51%，τ-Voice 多轮任务成功率为 57.93%。它们对应不同评测对象，应按厂商给出的测试范围理解，再补充自己场景的验收。官方完整评测表

手机或弱网络场景，还需核对音频编码和数据传输。官方指南提供低带宽媒体配置与兼容处理路径，接入团队可以在实际设备上比较转录确认、语音开始播放和连续播放表现。媒体传输说明

[配图建议：一次只读查询旁放置事件记录单，标出输入、修订、返回与播完时刻 + 简洁的开发验收笔记插画。]

今天先写一个“任务进行中改要求”的测试

正在开发实时语音产品、且已具备工具后端的团队，值得沿 MOSS-Live 的播放与异步任务协议做一次试点。只需要离线录音转文字的项目，可以继续围绕转写流程选型。

今天先定义一个只读任务，安排一次中途修改，再核对旧结果晚到时的表现。你的助手更容易卡在接话时机、后台任务更新，还是结果回到对话的那一步？这一条记录，能成为下一次迭代的具体起点。

[配图建议：一张测试卡写着初始任务、新要求和最终结果，两条路径在正确版本处汇合 + 与封面一致的珊瑚灰蓝插画。]

资料核查于北京时间 2026 年 11 月 10 日，本文深读团队于 11 月 7 日介绍的系统。依据官方介绍、文档与评测分析，本站未接入服务实测，出行场景和验收方法为作者编写，封面为原创 AI 概念图。