本文要点
- 实时语音前端从默认DashScope扩展为可按会话选择speech-to-speech。
- 桌面设置开始展示前端配置与运行状态，WebUI也统一播放确认逻辑。
- 任务结果回传脱离特定后台分支，进入共享响应上下文。
阅读辅助
先看数字、证据和来源，再读正文。
过去24小时的新增量是两个源码PR合入，不是v1.3.0正式发布。
2026-08-01T08:36:17Z · v1.2.0 GitHub Release发布；这是当前正式包版本，也是本篇的背景节点。
两小时内的两次合入，把 Qwen Audio Agent 的实时语音入口从单一默认路径扩成了可切换的前端层。北京时间 8 月 2 日 20:41:38，PR 50 先把 Hugging Face speech-to-speech 接成用户自管的实时前端；到 22:35:26，PR 58 又补上桌面设置、运行状态和跨界面的响应交付。
这条新闻的状态词比功能清单更重要。仓库 README 把新能力标为“测试中 · v1.3.0”，并明确写着“当前可从源码体验，正式 Release 将在完成测试后发布”。main 分支的 package.json 版本仍是 1.2.0，PR 58 也直接声明不会触发 v1.3.0 release。
因此，开发者今天获得的是一条可审阅、可从源码试跑的集成路径，不是一个已经推送到 npm 或桌面下载页的新正式版本。现有 v1.2.0 Release 发布于 2026-08-01T08:36:17Z，它负责提供当前稳定包的版本锚点，在本篇中只属于背景。
受影响最大的是希望自托管语音链路的 Agent 开发者。他们可以让 Qwen Audio Agent 连接本地或自管的 VAD、STT、LLM、TTS 组合，同时保留后台 Agent 执行长任务的架构；但跨平台全双工、回声消除、模型组合延迟和发布包升级路径，仍要等正式版给出更完整答案。
两次合入分别解决了什么
PR 50 新增了一层实时前端适配。其说明写明：用户自行安装、配置和运行 speech-to-speech，并选择 STT、LLM、TTS 与音色；Qwen Audio Agent 只连接它暴露的 OpenAI Realtime 兼容 WebSocket。默认 DashScope 路径保持不变，两者由 provider registry 选择。
这次改动覆盖 33 个文件，新增 1,895 行、删除 152 行。WebUI 可以按会话选择前端，而且只有被显式配置的前端才会显示为可用，避免把不存在的默认本地服务误报成可选项。公开 provider ID 是 speech-to-speech，较短的 s2s 只保留为兼容别名。
PR 58 随后把能力从 WebUI 和服务端推进到桌面运行时。它改动 20 个文件，新增 1,033 行、删除 149 行，加入 DashScope 与用户自管 speech-to-speech 的桌面设置和状态展示；同时整理播放确认与任务结果交付，让 Desktop 和 WebUI 复用同一套响应上下文，避免为不同后台 Agent 写特例。
| 节点 | 精确时间 | 已进入main的内容 | 没有发生的事 |
|---|---|---|---|
| PR 50 | 2026-08-02T12:41:38Z | speech-to-speech实时前端、provider registry、协议适配、会话级选择 | 没有发布新npm包，也没有替换默认DashScope路径 |
| PR 58 | 2026-08-02T14:35:26Z | 桌面设置与状态、播放确认、任务结果交付、双语预览文档 | 明确不触发v1.3.0 Release |
| v1.2.0 Release | 2026-08-01T08:36:17Z | 当前正式版本与既有桌面维护改动 | 早于本期两个PR，仅作背景，不能冒充当天新增量 |
| main分支版本 | 截至 2026-08-03 | package.json仍写 1.2.0 | v1.3.0仍是源码测试标签，不是正式包版本 |
可替换的是前台语音链路，不是整套Agent
speech-to-speech 上游把语音交互拆成 VAD、STT、LLM、TTS 四个模块，并通过 OpenAI Realtime 兼容接口向客户端提供服务。Qwen Audio Agent 本次只接入这个接口边界，上游各模型不进入它的发布包。语音识别、语言模型和语音合成因此可以分别替换，Qwen Audio Agent 继续承担前台会话与后台任务的衔接。
架构上的分工可以概括为三层：
- 上游 speech-to-speech 负责听、转写、生成和合成，可全部本地运行，也可把 LLM 指向兼容服务；
- Qwen Audio Agent Gateway 负责实时事件、会话、打断、前台回复与任务结果回传；
- OpenCode、OpenClaw、Codex、Claude Code 等后台 Agent 继续执行工具调用或长任务，完成后把结果送回当前语音会话。
这也解释了 PR 58 为什么花较多改动处理播放确认和任务结果交付。语音 Agent 不能只在“开始生成”时判断一轮结束：音频可能仍在客户端播放，用户可能中途打断，后台任务也可能晚于前台回答完成。若 Desktop 与 WebUI 对这些状态采用不同判断，任务结果就可能过早插入、重复播报或在旧会话中出现。
社区演示把这套关系概括成“前台 Agent 边听边答，后台 Agent 执行任务，完成后回到同一段对话”。这有助于理解产品意图，但不构成稳定性证据。实际可靠性仍取决于播放确认、打断终态、重连竞争和任务与对话轮次的关联能否在不同客户端中保持一致。
协议适配藏着最容易出错的部分
PR 50 没有把 speech-to-speech 当成与 DashScope 完全同构的后端。它新增 GA protocol adapter，用来翻译 output_modalities、response.output_text.* 事件和不同 item 类型的 ID 命名空间；能力标记还记录两项已知差异：上游接受 session.update 后不返回 session.updated，并且同一时间只接受一个活跃 response。
这些差异会直接影响超时、重试与打断。如果客户端假定每次更新都会有确认事件，就可能把正常状态判成超时；如果在上一条 response 未终止时又创建新 response，就会制造并发冲突。PR 50 依赖 conversation item receipt、打断终态和服务端轮次的 response.created 等真实协议事件，避免用固定等待时间补偿。
音频格式同样采取“少干预”策略。集成沿用上游 16 kHz PCM 默认值，不覆写音频格式、模型与音色。Gateway 因而只是协议客户端，具体使用哪套 STT、LLM、TTS 和 voice 仍由 speech-to-speech 侧决定。在该模式下不需要 DashScope API Key；SPEECH_TO_SPEECH_AUTH_TOKEN 只用于上游 WebSocket 前存在认证代理的高级场景。
| 工程边界 | 本次采用的做法 | 带来的好处 | 尚待验证的风险 |
|---|---|---|---|
| 前端选择 | provider registry按会话选择 | 共享会话逻辑不写provider名称分支 | 切换时的旧状态清理和重连竞争 |
| 协议差异 | GA adapter与能力标记 | 避免假定所有Realtime实现完全一致 | 上游协议继续变化后的兼容成本 |
| 音频参数 | 沿用16 kHz PCM默认值 | 不擅自改写上游模型与音色配置 | 不同设备采样率转换与端到端延迟 |
| 结果交付 | Desktop与WebUI共享播放确认语义 | 降低任务结果错序或重复播报 | 打断、断网和后台任务并发时的稳定性 |
版本状态必须单独读
仓库在 8 月 1 日发布的 v1.2.0，包含桌面自动更新、启动卡顿修复、后台 Agent 可用性显示以及实时服务商协议解耦等既有改动。它与 8 月 2 日合入的 speech-to-speech 前端有演进关系，但发布时间和内容边界不同。
8 月 2 日的两个 PR 均合入 main，所以从 GitHub 最新源码安装可以进入预览路径；这不代表 npm install -g qwen-audio-agent@latest 已经获得同样内容。PR 58 的原文同时给出两条约束：“The package version remains 1.2.0”以及“this PR does not trigger the v1.3.0 release”。中文只能忠实表述为“包版本保持 1.2.0，该 PR 不触发 v1.3.0 发布”，不能改写成“发布 v1.3.0”或“升级到 v1.3.0”。
README 又补了一层条件：正式 Release 要等测试完成后再发布。这是将来的计划状态，没有具体截止时间。当前可以确认源码测试入口已经合入，不能确认正式发布日期、npm 分发时间、桌面安装包是否同步，也不能确认测试会否引出新的破坏性修改。
这次更新把“语音提供者”做成了运行时边界，某一家实时模型不再写死在会话逻辑中。前台可替换，后台 Agent 和任务编排保持稳定，才有机会让本地语音、云端语音与不同 Agent 组合在同一套产品壳里共存。
不过，接口兼容只解决了接上线的问题，没有证明体验已经可替换。语音系统的质量由端到端延迟、回声、打断成功率、转写错误、首包时间、播放确认和重连共同决定。源码通过 npm test 与 release:check，说明仓库内测试门槛已过；它不能代替真实麦克风、扬声器、网络和多模型组合下的长时间运行数据。
因此，对开发者最合理的定位是“高信息量预览”：可以开始评估 provider registry 和 Realtime adapter 是否适合自己的语音栈，也可以从源码验证全本地链路；对普通用户和生产部署，则应继续以 v1.2.0 为正式版本锚点，等待 v1.3.0 Release、安装包与迁移说明出现后再判断升级。
从源码试用前要核对的限制
第一类限制来自平台。仓库 README 目前把 macOS TUI 描述为带回声消除的全双工；Linux 与 Windows 默认是半双工，播报时需要按 x 打断。后两者可以开启无回声消除的全双工模式，但官方建议佩戴耳机。因而“接入全本地语音链路”不等于所有桌面平台都已经获得相同的免手动打断体验。
第二类限制来自资源与组合。speech-to-speech 可以替换 STT、LLM 和 TTS，但每种组合的显存、内存、首包延迟和并发能力都不同。Qwen Audio Agent 沿用上游配置，不会替用户选择更小模型，也不会自动保证整条链路都在本地；只要 LLM 或其他组件指向托管服务，“全本地”就不成立。
第三类限制来自可观测性。PR 58 已加入前端设置和运行状态，这是排错入口，不是完整诊断。正式版仍需要回答：连接失败时能否区分上游未启动、协议不兼容、认证错误和音频设备问题；重连后旧 response 是否被清理；后台任务结果落回时能否绑定正确会话；客户端确认播放完成前发生打断时，状态机是否可恢复。
后续应重点检查正式 v1.3.0 的发布资产与可复现测试：GitHub Release 和 npm 包是否同时出现，Linux 与 Windows 是否给出全双工边界，Desktop 与 WebUI 是否共享同一套故障诊断，以及多种 STT、LLM、TTS 组合下的延迟、打断和任务回传是否有连续运行数据。在这些材料出现前，本次事件应保持“源码预览已经合入，正式版本尚未发布”的准确状态。