为什么 Voice Agent 不能照搬 Coding Agent：实时对话与长任务如何共存

Home | GitHub | Twitter | Youtube | Bilibili

目录：

文本 Agent 与 Voice Agent，差别不在会不会调用工具第一关：系统必须知道什么时候不该说话第二关：慢任务不能占住对话 GPT-Live 与 Qwen-Audio-Agent：解决的是同一张图上的不同位置一句“订会议室”，在 Qwen-Audio-Agent 中如何变成可控的 Work 1. 前台先受理，不等结果前台工具不是功能清单，而是实时路径的“能力白名单”2. Gateway 把“一次说话”变成不会重复执行的任务 3. 后台需要的不是一串转录，而是带信任边界的“协调信封”4. 固定后台 Session 让断线不等于遗忘 5. 后台完成，不等于用户已经收到结果 6. 取消和授权都必须等确认从两个案例抽出的五条设计原则先设响应预算，再决定是否同步让快路径足够小将异步结果送回前台视作一次新的对话决策用显式状态替代“应该已经好了”的猜测为坏天气设计框架怎么选：先问它覆盖哪一层结语：Voice Agent 的分界线不在“会不会说话”AI Agents 知识星球参考文献

在代码编辑器里让 Agent “重构这个函数”，等十几秒通常没有问题。屏幕会告诉你它在读文件、运行测试还是修改代码；你能随时点停止，也能回看它已经写出的内容。

把同一个任务放到语音里，体验马上变了。用户说“帮我订明天下午三点的会议室”，助理沉默五秒，用户并不知道它在查空闲会议室、等待接口，还是根本没听懂。更麻烦的是，用户很可能在这五秒里补一句：“等等，改成后天。”

这不是“语音输出比文本输出更快”就能解决的问题。Voice Agent 面对的是两种不同的时间尺度：一条音频必须持续流动、随时可被打断；另一条搜索、推理、调用工具和执行操作可能要花数秒甚至数分钟。把后者直接塞进前者，语音对话就会停顿；让后台任务完成后直接播报，又会在用户说话时粗暴插入。

更准确的说法是：Voice Agent 不是给 Text Agent 接一个麦克风，而是在一个连续的对话通道上运行 Agent。 它既要决定“什么时候开口”，也要保证“正在办事时仍然在场”。

本文用两个处在不同层次的系统说明这个问题：GPT-Live 重点解决实时媒体和话轮交接；Qwen-Audio-Agent 重点解决长任务的派发、取消、状态追踪、后台 Session 上下文续接与结果送回。它们不是二选一，而是同一个产品中可以叠加的两类能力。

Qwen-Audio-Agent 将前台实时语音层与后台 Agent 层通过 Work 队列解耦；用户面对的始终是同一个助理。图依据项目架构文档绘制。[1] — *Qwen-Audio-Agent 将前台实时语音层与后台 Agent 层通过 Work 队列解耦；用户面对的始终是同一个助理。图依据项目架构文档绘制。*[1]

文本 Agent 与 Voice Agent，差别不在会不会调用工具

把 Coding Agent 当作对照很有帮助，但前提是不要误解对照对象。Coding Agent 也可以并发调用工具、在后台跑测试，甚至把任务交给子 Agent；Voice Agent 也可以采用普通的 STT（语音转文字）—LLM（大语言模型）—TTS（文字转语音）级联。两者真正不同的是交互契约。

文本界面的默认条件	语音交互新增的事实	对架构的影响
输入按消息提交	音频持续到达，停顿可能只是思考或换气	必须处理端点、插话、重叠说话与回声
用户能看见进度和按钮	沉默没有明确含义	需要及时的听觉反馈与可表达的任务状态
结果可编辑、重发、回看	已经听到的内容不能完全收回	要谨慎决定何时播报，并支持中断播放
授权可通过弹窗完成	“可以”可能是在回应别的话	授权必须绑定到具体操作、范围和时效
长任务可以占住界面	用户会继续说、改主意或断线	任务要有独立身份、状态、取消与交付语义

因此，“响应时间”本身也要拆开。用户结束一句话到助理发出第一小段可听声音的时间，是话轮交接和媒体延迟问题；完成会议室预订需要多久，是任务执行问题；任务完成后何时以不打断对话的方式告知用户，又是第三个问题。把这三件事混成一个延迟数字，会掩盖真正的设计取舍。

级联系统把 STT、LLM、TTS 串在一轮请求里；轮次制语音模型虽然直接处理音频，仍需先判断用户是否说完；全双工流式模型则持续听和说。图依据 OpenAI 对 GPT-Live 的公开说明整理。[2][3]

第一关：系统必须知道什么时候不该说话

人类对话不是“你说完，我再说”的严格轮流。我们会用“嗯”“对”表示仍在听，会在对方停顿时等待，也会在对方开始说话时收住自己的话。传统轮次制语音系统常把这件事交给一个端点检测器：先根据静音或语义判断用户是否说完，再让大模型开始回答。判断早了，用户被打断；判断晚了，助理显得迟钝。

GPT-Live 的公开架构选择把这个门控从音频关键路径上移走。它的语音模型是全双工的：输入音频持续进入模型，模型也可以持续生成语音，因此它能在对话进行中反复决定继续听、停一下、简短回应、打断或委派任务。需要搜索或深度推理时，它再异步咨询后台的前沿模型，而不是先冻结语音会话。[2][3]

这不意味着 VAD（语音活动检测）或语义端点检测从此无用。对轮次制模型、电话线路、嘈杂环境和成本敏感场景，它们仍是重要部件。区别在于：全双工模型把“是否开口”当作连续对话理解的一部分；轮次制系统则把它当作启动下一轮推理的前置判断。两条路线服务同一个体验目标，能力边界却不同。

第二关：慢任务不能占住对话

即使模型能够自然地听与说，外部世界仍然很慢。日历 API 可能超时，网页搜索要多轮调用，写文件要经过权限确认，后台 Agent 可能再委派子任务。任何一个动作都不应该阻塞正在流动的媒体。

OpenAI 对 GPT-Live 的描述很直接：音频在客户端和语音模型之间走专用快路径；委派、工具与应用逻辑跨过异步 RPC 边界执行。慢工具可以延迟自己的结果，但不能让音频停止流动。系统甚至把上下文压缩和模型实例迁移也做成“预热新实例、并行运行、就绪后切换”的后台操作，避免重建状态时出现可听见的断裂。[2]

这给 Voice Agent 带来一个简单但容易被忽略的原则：快路径负责维持对话，慢路径负责取得结果；两者之间需要协调，而不是互相等待。

GPT-Live 与 Qwen-Audio-Agent：解决的是同一张图上的不同位置

“快慢路径分离”很容易被说成一条口号。把层次分开看，才知道每一部分要由谁实现。

GPT-Live 的公开架构：实时媒体路径与异步委派路径在媒体前端汇合。官方工程文章强调，慢工具与后台服务不应阻塞媒体流。来源：OpenAI。[2] — *GPT-Live 的公开架构：实时媒体路径与异步委派路径在媒体前端汇合。官方工程文章强调，慢工具与后台服务不应阻塞媒体流。来源：OpenAI。*[2]

系统层	首要问题	GPT-Live 的公开重点	Qwen-Audio-Agent 的公开重点
媒体与对话	何时听、说、暂停和打断	全双工连续交互，维持实时媒体环路	使用 Realtime 前台承接语音对话；具体能力取决于前台模型和客户端
协调与调度	如何让长任务不拖住对话	异步委派，结果回到语音对话	Gateway、Work、幂等、队列、取消与安全交付
执行与工具	如何做多步工作并控制风险	后台模型与工具	持久后台 Agent Session，通过 ACP（Agent Client Protocol，连接后台 Agent 的协议）接入执行能力

GPT-Live 展示的是“语音必须流动”在模型、推理和媒体基础设施上的含义：每一帧音频都要按时到达，重计算都尽量离开实时环路。Qwen-Audio-Agent 展示的则是应用运行时如何把这件事落到任务对象上：什么请求要交后台，后台任务如何被标识，用户改变主意时如何取消，以及结果何时才算真的交付。

后一部分尤其值得展开，因为它是许多语音 Demo 走向真实 Agent 时最先遇到的缺口。

<ins/>

一句“订会议室”，在 Qwen-Audio-Agent 中如何变成可控的 Work

Qwen-Audio-Agent 将用户可见的系统划成实时前台和后台 Agent 两层，并用 Gateway 连接它们。前台负责自然对话和少量轻量工具；所有需要当前信息、文件、应用、代码或多步执行的请求，都归一个持久后台 Agent Session 处理。[1]

这里必须区分两个名字。Qwen 的 Realtime 前台负责接收和生成语音，提供全双工交互这一类媒体能力；Qwen-Audio-Agent 是运行时，负责让这个前台在长任务执行时仍能持续对话。它的架构可以接入不同的后台 Agent，也可以随前台模型与客户端实现变化而调整。把两者混在一起，容易把“自然说话”误当成“后台任务一定不会阻塞”的保证。[1]

Qwen-Audio-Agent 的调度流程：前台受理请求后立即回到对话；Gateway 负责排队、续接后台 Session、构造协调请求，并在安全时机将结果送回前台。图依据项目架构文档和源码整理。[1][4]

用“订会议室，随后改成后天”走一遍，能看清这套架构的价值。

先给出这次交互的时间线。这里的会议室系统只是一个便于理解的业务工具；Work、固定后台 Session 和交付控制才是 Qwen-Audio-Agent 提供的通用运行时语义。

时刻	用户与前台	Gateway / Work	后台 Agent
T0	用户说“订明天下午三点会议室”	关联本次发言的 `turnId`	尚未执行
T1	前台调用 `spawn_thinking`（把慢任务交给后台、立即返回的派发工具），继续听用户说话	创建或复用 `work_id`，返回 accepted	尚未执行
T2	前台可回答“我在处理”或保持倾听	将 Work 放入该用户的 FIFO 队列	续接固定后台 Session，查询会议室并请求确认/预订
T3	用户说“改成后天”	原 Work 进入取消流程；新的明确要求成为新话轮	已启动的操作必须确认取消，不能只改前台文案
T4	用户继续对话或询问进度	记录执行结果，但暂不等同于已交付	返回面向用户的语义材料与可选的内联内容
T5	用户出现空闲窗口	检查交付权、播放冲突与是否已取消	无需直接对用户播报
T6	前台按当前语境说出结果	Work 已为 `completed`；通知在播放完成后标记为 `delivered`	保留必要的 Session 上下文

这个时间线有两个反直觉的地方。第一，用户第二句话不是在修改一段尚未发送的文本：第一句话一旦被派发，后台可能已经开始查询会议室，甚至已经把预订写入日历。“改成后天”实际上是在对原 Work 提出新的变更要求，系统需要先找到对应的 work_id，发起取消并等待确认，再决定是否创建新的预订请求，不能只把前台文案改成“后天”。第二，后台查到会议室也不意味着系统已经可以开口播报；它还要等待用户空闲、获得交付权，并确认当前没有播放冲突。

1. 前台先受理，不等结果

前台判断请求不是即时可答时，调用 spawn_thinking(objective)。spawn_thinking 是个前台工具，它把慢任务交给后台、然后立即返回。它得到的是“已受理”和一个 work_id，不是预订结果；随后立即恢复语音对话。用户可以继续补充要求、询问进度，或说“算了”。项目架构文档把这一点写成硬边界：spawn_thinking 不等待请求的工作完成。[1]

可以把它理解成一次非常短的提交：

accepted 的含义应该严格限定为“调度器已接住请求”。它不表示日历有空位、后台已经开始运行，更不表示外部系统已经写入成功。将这几个状态分开，前台才能对“我已经在处理”“还在排队”“需要你确认”“已经订好”使用不同的话术，而不是把所有过程压成一句含混的“好的”。

这比一句“请稍等”多了一层语义。前台不是在假装已经完成任务，而是明确把工作从对话时钟中剥离出去。至于是否需要说一句确认、说多长、还是保持倾听，应由当前对话状态决定；为了填补沉默而不断播报，既损害体验，也增加语音输出成本。

前台的工具集被刻意压小。当前架构文档只允许它处理派发、日程提醒、查询/取消任务、时间、记忆/清单和转达待定权限等有限职责，不允许它选择后台 Session、执行策略、工具或子 Agent。[1] 这条边界的目的不是限制功能，而是防止实时语音层变成另一个会被慢工具和复杂策略拖住的编排器。

这也解释了一个常见误区：前台不是小一号的后台 Agent。它可以问“刚才那个任务进展怎样”，却不应自行跑一遍日历搜索来回答；它可以把“取消会议室预订”交给 Gateway，却不应猜测哪一个后台 Session、哪一个工具调用需要被停止。前台掌握的是对话现场，Gateway 掌握的是任务身份，后台掌握的是执行细节。

前台工具不是功能清单，而是实时路径的“能力白名单”

这一点在 Qwen-Audio-Agent 的工具设计里看得最清楚。当前架构文档列出八个基础工具：spawn_thinking、schedule_reminder、cancel_agent_task、get_agent_task_status、get_current_time、memory、notes 和 respond_agent_permission。版本升级可能增减具体名称，但它们可归为三类：派发一项慢工作、控制已存在的慢工作、处理不需要后台编排的前台状态。[1]

前台工具只做派发、控制和前台状态管理；后台 Session、工具与执行策略始终留在 Gateway 和 Backend Agent 一侧。依据 Qwen-Audio-Agent 架构文档绘制。[1] — *前台工具只做派发、控制和前台状态管理；后台 Session、工具与执行策略始终留在 Gateway 和 Backend Agent 一侧。依据 Qwen-Audio-Agent 架构文档绘制。*[1]

工具	所属角色	为什么能留在前台	关键边界
`spawn_thinking`	慢路径入口	只提交 Work 并立即返回	`objective` 是保守的请求摘要，不是执行计划
`get_agent_task_status`	观察	用户问“好了吗”时查询已有 Work	只能读进度；不创建新的用户 Work，不重跑任务
`cancel_agent_task`	控制	用户改变主意时发起停止	发起取消不等于取消成功，必须等待确认
`respond_agent_permission`	授权转达	将当前话轮的明确同意/拒绝关联到 pending 请求	不能凭空创建授权、选择工具或改后台策略
`get_current_time`、`schedule_reminder`	前台快捷能力	时间和提醒具有明确、范围小的交互语义	不演变为通用业务工具编排器
`memory`、`notes`	前台拥有的状态	保存档案事实、用户规则或命名清单	受作用域、显式删除和敏感信息策略约束

其中最有价值的不是 spawn_thinking，而是后三个“控制面”工具。很多 Demo 只有“把请求交给后台”的按钮，却没有用户追问、撤销和授权的语义；于是 Agent 要么沉默等待，要么重新跑一遍任务，要么把口头的“可以”错误地当成普遍许可。Qwen-Audio-Agent 把这些动作做成对既有 Work 或既有权限请求的操作，让前台不必知道后台的具体实现。

以状态查询为例。对于普通 Work，Gateway 可以直接返回已知状态；如果 Work 已委派给后台 Session，架构文档规定 Gateway 通过协调者发起一条隐藏的、高优先级 session_status 控制查询。它在已有协调轮次之后执行、优先于普通排队 Work，结果仍走正常的异步播报路径，但这条查询不会变成用户可见的新 Work，也不会被后续“取消刚才的任务”误选为目标。[1] 这是一种很细但很重要的设计：问进度不能导致新任务，新任务也不能把进度查询当作可取消的业务操作。

respond_agent_permission 同样值得单独看。前台可以理解“可以”“不允许”这类自然语言，但只有同时满足三项条件才能转达：存在 Gateway 提供的 pending 请求、请求属于当前 owner、并且用户在当前话轮作出明确决定。文档还将可传递的决定限制为 always 与 reject，其中 always 也只在后台支持时采用 Session 范围的许可。[1] 换句话说，它实现的不是“语音万能确认”，而是“把一次有编号、有范围的授权请求送回原处”。

最后，再看这份白名单里故意没有什么：前台不能创建或续接后台 Session，不能挑选 Agent、工具或子 Agent，不能决定一项工作该同步还是异步执行。这些限制防止模型在实时对话里随意改变后端拓扑，也让替换后台 Agent 不必重新训练前台如何操作每一种工具。对 Voice Agent 而言，少工具不是能力弱，而是把必须实时的控制保持得足够小、足够可预测。

<ins/>

2. Gateway 把“一次说话”变成不会重复执行的任务

这里的“一次说话”指一个已经结束、带有 turnId 的用户话轮，不是一条音频包，也不是一句“意思差不多”的文本。Gateway 要做的第一件事，是给这次话轮一个稳定的受理边界。

这是因为同一个请求可能会重复抵达：前台模型在同一轮发言中重复触发派发，网络重试再次提交，或者 Gateway 重启后重新处理了一次提交。如果第一次请求已经创建了“预订会议室”的 Work，第二次重试就不能再创建一个 Work，否则可能真的预订两次。反过来，用户也可能真的连续两次说“查天气”——第一次没有听清，第二次是新的请求。Gateway 不能靠比较两段文字是否相似来做这个判断。

Qwen-Audio-Agent 把幂等边界放在 turnId 上，并用 work_id 记录这次话轮实际创建的后台任务。可以把它想成下面三步：

用户第一次说“订明天下午三点的会议室”，前台把这次表达标记为 turn_42，Gateway 创建 work_7f3 并返回 accepted。

同一轮因为网络重试再次提交 turn_42，Gateway 查到这次话轮已经受理，就复用原来的 work_7f3，而不是再创建一个预订任务。

用户稍后再次说同样的“订明天下午三点的会议室”，这已经是新的 turn_43。Gateway 不会因为文字相同就把它吞掉，而会把它当作新的请求处理。

实现上，Qwen-Audio-Agent 用内存映射快速拦截同一轮的重复派发，再用稳定的提交键防止重启或重试造成重复创建。前者解决正常运行时的重复调用，后者解决请求已经离开内存之后的重复提交。这样保证的是“同一次表达只受理一次”，而不是“相似的自然语言只执行一次”。[4]

这套设计可以用四个 ID 的分工看得更清楚：

ID	回答的问题	生命周期	不能代替什么
`turnId`	这是用户哪一次发言，也是哪个重复请求的去重边界？	一次话轮	不能表示后台执行上下文
`work_id`	这次话轮实际创建了哪项后台工作？	从受理到交付/失败	不能表示音频连接
voice session ID	这段媒体流属于哪次连接？	一次连接，可断开	不能用来保留长期后台历史
backend session ID	后台 Agent 在哪段上下文里办事？	跨多次语音连接	不能暴露为前台的任务 ID

用户说“改成后天”时，这个区分开始发挥作用。这句话属于新的 turnId，不会覆盖原来的 work_id。以原请求对应的 work_7f3 为例，完整流程是：

前台先把“刚才那项预订”解析为旧的 work_id，确认它属于当前用户，并调用 cancel_agent_task，把取消目标指向 work_7f3。这一步是停止旧 Work，不是创建“后天”的新任务。

Gateway 根据旧 Work 当前所处的阶段执行取消：排队中的 Work 可以直接从队列移除；正在运行或 finalizing 的 Work 要中止当前后台请求；已经 delegated 的 Work 则要向准确关联的后台 Session 发出取消。取消尚未确认前，状态保持为 cancelling，前台只能说“我正在取消”，不能说“已经取消”。[1]

只有 Gateway 收到后端确认、旧 Work 进入 cancelled 后，前台才为“后天”这个新的 turnId 调用 spawn_thinking，创建新的 work_id，例如 work_8a1。新 Work 再独立经历排队、执行、结果确认和安全交付。

如果旧 Work 在取消前已经把预订写入日历，cancel_agent_task 只能停止仍在运行的任务，不能凭空撤销已经产生的日历副作用。这时系统需要把“取消原预订”作为一个有明确目标的补偿操作，确认成功后才能创建新的预订；如果取消失败，就不能直接宣称“已经改好”。

因此，前台通常确实会先调用 cancel_agent_task，但前提是旧 Work 仍可取消；它不会把一次取消当成一次新的业务 Work，也不会把取消请求的发出误报成取消成功。Qwen-Audio-Agent 的取消状态不是一个瞬间的布尔值，而是 cancelling 到 cancelled 或 failed 的过程。[1]

这里有一个可以迁移到任何 Voice Agent 的经验：

不要让自然语言相似度承担交易幂等性。为一次用户表达、一次任务提交、一次外部操作分别设定清楚的身份边界。

3. 后台需要的不是一串转录，而是带信任边界的“协调信封”

语音前台掌握刚刚发生的对话，后台 Agent 通过持久 Session 保留已有执行上下文；两者看到的上下文并不相同。Qwen-Audio-Agent 不把后台请求做成一段裸 Prompt，而是构造结构化信封：包含用户原始转录 final_asr、前台整理的 objective、最近的语音上下文、交付信息，以及用户偏好或长期规则。[4]

把会议室案例缩写成信封，大致是下面的形状；字段名和完整 schema 会随版本演进，重点在信息的分层，而不是复制这段 JSON：

为什么不只发 objective？因为“订会议室”常常缺少后台执行所需的语境：用户前一轮说过“不要太远”，可能是在限定地点；“明天”依赖当前时区；用户又可能在后续一轮纠正为“后天”。把原话、压缩上下文和整理后的目标分开，后台就能在出现冲突时追溯用户真正说了什么，而不是把前台的总结当作不可质疑的命令。

其中最重要的不是字段数量，而是字段的地位。

final_asr 是用户这一次说的话，应作为意图的真源；objective 只是前台为了派发而做的保守整理，不能反过来覆盖用户意图。

最近对话是容量受限的桥接信息，让后台能理解“继续刚才那个”；它不是完整审计记录，也不能无限增长。

用户偏好是参考数据，长期规则是受约束的用户指令；两者都不能绕过权限检查或改变系统安全边界。

这与 Text Agent 的 prompt 拼接看起来相似，但语音让问题更尖锐：转录可能被修订，代词指向高度依赖刚才的现场，用户随口的“可以”又可能被误当作授权。把来源、用途和优先级显式写进协议，比让后台从一大段文本中猜测更可靠。

<ins/>

4. 固定后台 Session 让断线不等于遗忘

WebSocket 和 WebRTC 连接都是暂时的。手机切后台、网络切换、浏览器刷新，都可能中断媒体；用户却仍期待“继续昨天那个任务”。

因此 Qwen-Audio-Agent 为每个 owner 和 backend 保存一个稳定的后台 Session 身份，例如 qwen-audio-agent:<owner>:backend，并在后续请求中续接原生 ACP Session。语音连接 ID 和 Work ID 不改变这个后台身份。[1] 这样，媒体可以重连，后台仍保有处理任务所需的上下文。这里的“续接”指语音连接断开后仍可使用同一后台上下文；它不等于 Gateway 重启后正在运行的 Work 可以无损恢复，后者会被标记为 failed。

调度器在这个稳定身份之前再加了一层串行边界：同一个 owner 的 Work 可以被前台连续提交，但一次只有一个会被送进该后台 Session。这样做并不是否认用户可以提出多个任务，而是避免两条请求同时改写同一段 Agent 历史、争抢同一份权限状态，或让“改成后天”与“订明天”在未知顺序下并发执行。后台若自行委派更细的子任务，那是后台内部的执行策略；从语音运行时的视角，仍然只追踪一个可交付的 Work。[1]

串行化也有代价：一个很慢的任务会让后续 Work 排队。因此产品不应假装“并行提交”等于“并行完成”，而应在前台把可查询的进度、取消和替代方案做清楚。对本来就能安全并行的业务，后台可以通过自己的任务系统并行化，但仍要在对话层保留清晰的交付顺序。

但“持久 Session”不是“永久记忆”。语音现场、用户档案、后台 Agent 历史、已完成 Work 和交付状态，应该有不同的保留、删除与访问策略。把它们混成一个无限增长的对话记录，迟早会在隐私、成本和上下文质量上出问题。

5. 后台完成，不等于用户已经收到结果

这是 Voice Agent 最容易被忽略的一步。

假设会议室查好了，但用户正在说“能不能顺便邀请产品组？”如果后台服务直接把“已订好”播出来，会打断用户；如果刚好另一个结果正在播放，会造成信息重叠；如果用户已经断线，系统还要决定在重连后是否、如何提醒。

Qwen-Audio-Agent 将 Work 状态与结果通知的交付状态分开管理。它的 Work 状态机区分 queued、running、delegated、finalizing、completed、cancelling、cancelled 与 failed；后台完成并确认最终结果后，Work 可以进入 completed。结果随后等待一个安全的双工插入窗口，注入前台并完成播放后，通知才标记为 delivered。用户正在说话、刚打断播放或已有响应待处理时，系统等待并重试，而不是重复塞入同一结果。[1]

一次后台 Work 从请求出发，经 Gateway 与后台 Agent 执行；后台结果先进入 completed，再通过安全交付闸门回到实时语音通道；播放完成后，结果通知才进入 delivered。橙色支路代表取消在交付前终止。机制含义依据 Qwen-Audio-Agent 架构文档。[1] — *一次后台 Work 从请求出发，经 Gateway 与后台 Agent 执行；后台结果先进入* *`completed`，再通过安全交付闸门回到实时语音通道；播放完成后，结果通知才进入* *`delivered`。橙色支路代表取消在交付前终止。机制含义依据 Qwen-Audio-Agent 架构文档。*[1]

状态名的价值，在于把用户可感知的阶段和后台的真实边界对齐：

Work 状态	发生了什么	前台可以怎样说	不能误报成什么
`queued`	Gateway 已受理，等待进入后台 Session	“我已经接到这个请求。”	“已经在日历里创建了。”
`running`	后台正在查询、推理或调用工具	“还在查可用会议室。”	“任务已经取消。”
`delegated`	后台又把子工作交给关联 Session	“它还在处理，我会继续跟进。”	“已经有最终结果。”
`finalizing`	后台正在把已验证的结果整理为可交付内容	通常不需额外播报	“用户已经听到。”
`cancelling`	已请求停止，等待后端确认	“我正在取消这项操作。”	“已取消。”
`completed`	后台已生成并确认最终结果；通知可能仍等待安全播放	“结果已经准备好，我会在合适时机告诉你。”	“用户已经听到。”

这张表不是要求每个产品把所有内部状态都朗读出来。相反，Qwen-Audio-Agent 只向前台投影用户安全、稳定的状态，不暴露后台 Session ID、子 Agent、原始权限载荷或推理过程。状态机的用途是让系统知道何时可以说什么，不是把运维日志变成语音。

这一步揭示了一个重要区分：Work 完成是后台事实；通知交付是对话事实。 如果通知已经进入 delivered，前台才可以确认用户已经听到；如果 Work 已 completed 但通知尚未 delivered，系统应保留结果，不能假设用户已经知道。后台 Agent 可以只返回简洁的语义材料，例如“后天下午三点，A 会议室已预订”，由掌握当下语气和打断状态的前台决定怎样说。GPT-Live 的公开描述同样强调，深度模型的结果会回到语音模型并融入正在进行的交流；Qwen-Audio-Agent 则把“何时把结果送回前台、怎样防重复”具体落实为 Gateway 的交付策略。[2][1]

6. 取消和授权都必须等确认

用户说“别订了”时，最危险的实现是立即把界面改成“已取消”，却没有真正停止后台操作。Qwen-Audio-Agent 对取消采用确认式语义：排队中的 Work 可在本地取消；正在运行或收尾的 Work 需要中止活动请求；已委派的 Work 则需要向关联的后台 Session 发出取消并等待确认。确认前，状态保持为 cancelling。[1]

权限确认也一样。纯语音里，“可以”不能脱离上下文成为万能许可。项目要求前台仅在存在 owner 范围内的 pending 权限请求、当前一轮有明确肯定或否定表达时，才转达决定；前台不能凭空创建请求或修改后台权限策略。[1]

如果自己设计 Voice Agent，至少还应补上三件事：让用户听到操作对象和范围；为授权设置时效；对删除、转账、发送外部消息等高风险操作采用逐次确认。自然语言理解可以帮助解析意图，不能替代授权协议。

会议室案例还有一个实际分支：后台可能先问“B 会议室和 A 会议室都空着，选哪个？”这时系统应把澄清问题带回前台，而不能把 Work 伪装成完成；若选择会触发权限请求，前台再将它作为待确认操作处理。用户的“选 A”必须与那一次待定选择相关联，不能被未来任意一句“可以”误触发。将澄清、授权、取消和最终交付都建模为带 ID 的状态转换，才是 Voice Agent 能在自然语言里保持可控的原因。

<ins/>

从两个案例抽出的五条设计原则

上面的模型和运行时细节，可以压缩成五条原则。

先设响应预算，再决定是否同步

不是所有工具都该扔进后台。读取本地时钟、返回已缓存的状态、完成一次极短查询，可能适合留在快路径；多步推理、联网、文件修改和依赖外部确认的操作则应委派。判断标准不是“是否调用工具”，而是它能否稳定地放进当前话轮的响应预算。

让快路径足够小

GPT-Live 将媒体与业务逻辑隔开，Qwen-Audio-Agent 把实时前台的职责限制在对话和少量协调工具。这是同一条工程直觉：实时路径越小，越容易预测尾延迟、隔离故障、保证每帧按时到达。[2][1]

将异步结果送回前台视作一次新的对话决策

异步结果送回前台不是通知系统里的普通推送。它会抢占用户的注意力，也可能改变当前任务的含义。系统需要检查用户是否正在发言、结果是否仍相关、是否被取消、能否合并表达，以及连接是否还属于原来的用户。对话状态的拥有者应决定表达节奏，后台只提供结果。

用显式状态替代“应该已经好了”的猜测

accepted、running、cancelling、completed 这类状态或回执看似工程细节，实际决定用户能否信任系统。特别是在外部有副作用的场景，不能让“任务正在执行”“任务已停止”“用户已听到结果”共用一个模糊的 done 标记。

为坏天气设计

真实语音流量会有断线、重试、网络抖动、长会话、重叠发言和后台服务失败。OpenAI 在 GPT-Live 的影子流量测试中发现，语音系统的容量不能只看 GPU 吞吐，还要看持续帧处理、队列、网络路径与地理距离；Qwen-Audio-Agent 则明确将 Gateway 重启后的活跃 Work 标记为失败，而不是假装可以安全恢复。[2][1] 这些选择并不华丽，却比“平均延迟很低”更接近生产体验。

框架怎么选：先问它覆盖哪一层

LiveKit Agents 和 Pipecat 都能帮助构建 Voice Agent，但不应和 Qwen-Audio-Agent 或 GPT-Live 当成同类产品比较。

LiveKit Agents 提供 WebRTC 房间、实时媒体、转写、打断处理、Agent 生命周期和多模型集成等通用基础设施；其文档也将任务、工作流、工具和会话作为应用构造块。[5] Pipecat 则以 Python 的实时多模态管道为中心，允许把传输、音频处理、模型与业务逻辑组合起来。[6] 它们提供的是“可搭建系统的部件”。

Qwen-Audio-Agent 更接近一份带有明确协调语义的参考实现：它规定了前台与后台的边界、Work 的生命周期和结果回送方式。GPT-Live 则是托管模型和媒体系统的公开架构，展示了在大规模实时媒体路径上如何保护连续交互。

如果你的首要问题是	优先关注
浏览器、电话或移动端的低延迟音频传输	WebRTC 与媒体框架，例如 LiveKit
需要深度定制 STT、LLM、TTS、视觉和传输管道	可组合管道框架，例如 Pipecat
需要把现有 Agent 接到语音入口，并让任务可取消、可追踪，在语音连接重连后续接后台上下文，再把结果送回对话	Qwen-Audio-Agent 的 Work / Gateway / Session 设计
追求自然的连续听说与极低媒体路径延迟	具备全双工能力的语音模型，以及 GPT-Live 所展示的媒体架构原则

无论选择哪一个，应用仍要自己回答几个问题：最慢的工具需要多久？用户打断后，旧结果还应不应该交付？哪些外部操作需要逐次确认？语音断开后结果保存在哪里？这些不是 Provider 参数，而是产品语义。

结语：Voice Agent 的分界线不在“会不会说话”

Text Agent 的难点通常集中在理解任务、调用工具和呈现结果。Voice Agent 必须在这些工作尚未结束时，继续管理一段正在发生的对话。

这也是为什么 Voice Agent 的关键分界线不在于是否能合成自然的声音。模型决定它能否自然地听与说；运行时决定它能否在说话的同时可靠地做事。

GPT-Live 给出的答案是保护实时媒体路径：连续推理、异步委派，把任何不必实时的重活移出去。Qwen-Audio-Agent 给出的答案是把慢任务做成有身份、有状态、能取消、能追踪的 Work，通过稳定 Session 续接后台上下文，并等到合适时机再交付结果。把两者放在一起看，Voice Agent 的架构就不再神秘：一条路径守住对话，另一条路径完成行动，中间由明确的状态与交付协议连接。

<ins/>