给 Agent 装一张嘴：qwen-audio-agent 想解决的不是语音识别

上一次你打断 AI 说话是什么时候？

绝大多数语音助手做不到这一点。你说「等一下」，它继续念；你想补充一个条件，得等它念完，或者干脆重开一轮。更糟的情况是它在查资料——你对着屏幕等了十几秒，不知道它是在思考、卡住了，还是已经放弃了。

QwenAudio 团队 7 月底开源的 qwen-audio-agent，做的事就是把这段体验接上。9 月 23 日发布 2.0，重写了编排运行时；到 11 月初，仓库 3152 star、334 fork，昨晚还在推提交。

它不是一个新的 Agent，是一个语音入口层。

一句话说清架构

麦克风 → 实时语音前端（全双工）→ 简单问题当场答 / 复杂任务经 ACP 交给后端 Agent → 结果念回来。

关键在中间那层「编排运行时」。简单问题前端直接回答，需要搜索、推理、写代码、调工具的，连同上下文一起委派给后端；后端干完，结果回到原来的对话流里念出来。

所以它同时支持两种模式：只想聊天，`AGENT_PROTOCOL=none`，纯语音前台；想让它干活，接一个后端。

值得说的三个设计

① 打断是默认行为，不是特例

它讲的时候麦克风一直开着。用户一说话，输出流立刻截断，转入新一轮输入。这个叫 barge-in，技术上不难，难的是产品上愿不愿意做——做意味着要处理「说到一半被切掉，上下文怎么衔接」。

② 语音前端和后端解耦

前端可以是 Qwen Audio 3.1 Realtime、OpenAI Realtime、Gemini Live、豆包 Seeduplex，也可以是本地跑的 Hugging Face speech-to-speech 或者 MiniCPM-o，完全不联网。后端可以是 Claude Code、Codex、OpenCode、OpenClaw，或者任何支持 ACP 的 Agent。

两边独立选，自由组合。想换成别的语音服务，实现 Realtime Provider 接口就行，不用动网关的会话逻辑。

这个设计的意思很明确：语音能力不该被锁在某一家的产品里。

③ 危险操作会先开口问

删除文件、改系统配置这类动作，执行前会有一个语音确认流程。这比弹窗强制——弹窗你可能会习惯性点「确定」，但要对着一台设备说「可以」，心理门槛高得多。

装起来要多久

需要 Node.js 22.22.2+ 或 24.15.0+，npm 10+。

npm install -g qwen-audio-agent
qwenaudio config

配置文件里填这几行就能跑起来：

QWEN_AUDIO_REALTIME_PROVIDER=dashscope
QWEN_AUDIO_REALTIME_API_KEY=你的百炼 Key
QWEN_AUDIO_REALTIME_MODEL=qwen-audio-3.1-realtime-plus
AGENT_PROTOCOL=none

然后 `qwenaudio` 起网关，另开终端 `qwenaudio webui` 或 `qwenaudio tui`。

想接后端，改一行：

AGENT_PROTOCOL=openclaw

后端模型留空时会沿用 Agent 自己的配置。它支持项目 Session、任务委派、进度查询、取消任务和权限控制。

三个需要提前知道的限制

语言还是英文为主。 README 和文档站都有中文版，但界面文案、部分报错信息是英文的。

一对一连接。 同一个网关里，每个用户同时只能有一个活动客户端，新客户端接手会把旧连接踢掉。

ACP 是硬门槛。 后端必须支持 Agent Client Protocol。主流的几个都支持，但小众工具接不进来，这是设计取舍换来的自由度。

我的判断

这类项目今年出了不少，大多死在「演示很酷，日常没用」。qwen-audio-agent 让我觉得有点意思的地方，是它把「前台快速响应」和「后台慢活」拆开了——不让语音模型去扛搜索和推理，那本来就是它不擅长的事。

真正的考验在后面：任务跑到一半你去打断它，那个取消是真取消还是假取消；后端 Agent 跑飞了，语音层能不能兜住。这些不是靠架构图能看出来的。

顺带一提，它现在支持 `AGENT_PROTOCOL=openclaw`。如果你已经在用这套，接上去的成本基本就是改一个环境变量。

项目地址：https://github.com/QwenAudio/qwen-audio-agent

文档：https://qwenaudio.github.io/qwen-audio-agent/

协议：Apache-2.0