全双工语音 Agent 如何评测从首音延迟到事件级验收元信息文章类型Voice Agent 评测方法与验收合同目标读者正在开发实时语音、客服、车载、机器人或工具型 Voice Agent 的工程团队读者问题除了首音延迟怎样判断系统真的会倾听、会打断、能恢复并正确完成任务核心结论评测最小单位应从一次请求的平均耗时升级为“场景 事件时间线 期望动作 业务结果 证据包”速度、话权、任务和副作用必须分别计量。可带走产物场景集、事件账本、指标定义、证据梯度、验收矩阵和单次报告模板开头300ms 开口可能只是更快地犯错图 1把“快”拆成事件把“好用”拆成行为、任务与副作用。语音 Agent 很容易把首音延迟当作总成绩。模型在 300ms 内开口图表很好看演示也显得流畅。但如果用户只是在句中停顿它就抢话用户说“嗯”表示继续听它却把当前回答取消用户已经改口它仍执行旧工具后台任务结束后它把过期结果插进新话题——那么更快的首音只是让错误更早发生。反过来一个首音稍慢、却能稳定识别停顿、附和、有效打断和旁人语音的系统往往更接近真实可用。对机器人、客服和车载场景尤其如此错误不只表现为一句话不自然还可能变成重复下单、取消失败、设备继续动作或旧结果污染当前会话。因此全双工评测不能问一个问题“平均延迟是多少”它至少要分别回答四个问题系统多久开始响应、多久真正停止播放它在重叠语音出现时选择了正确动作吗工具、后台任务和物理动作最终完成了吗一次失败能否根据音频、事件与业务状态被重放和归因本文给出的不是某个模型的排行榜也不是 GPT-Live 私有评测方法。OpenAI 公共文档可以证明 Realtime 会话、VAD、WebRTC、响应和工具路径存在[S1-S5] Full-Duplex-Bench 与 τ-Voice 可以提供公开任务设计参考[S6-S10] 但场景、阈值、业务真值和发布门禁必须由应用团队建立。一、把评测单位从“请求”改成“场景时间线”图 2公开基准把重叠语音拆成四类它证明场景必须分类不替代业务阈值。图 3场景、时间线、预期动作、业务真值和证据包共同组成最小评测单位。传统请求评测通常只有输入、输出和耗时。连续语音中的一次交互却可能同时包含用户语音、系统播放、重叠片段、工具调用、后台任务和网络切换。若只保留最终文本就无法知道系统为何打断、旧音频是否真的停止、工具结果是否已经过期。更完整的样本应包含五部分case_id:overlap-interrupt-0042scenario:foreground_user:停一下改成明天overlap_at_ms:1850background_audio:nonenetwork_route:turnexpected:turn_action:interruptold_playback:stoppedold_task:cancel_or_stalenew_intent:update_dateobserved:trace_id:trace-0042utterance_id:utt-0042response_id:resp-17playback_id:pb-17task_id:task-9business_truth:final_date:2026-08-10duplicate_side_effects:0evidence:-input.wav-mixed_output.wav-events.jsonl-tool-audit.json-final-state.json这里最重要的变化是把“期望输出文本”改成“期望动作与最终状态”。同一句“嗯”在不同上下文里可能是附和、犹豫、确认或否定前缀同样检测到语音重叠期望动作可能是继续听、简短附和、暂停输出、完全打断或忽略背景声。所以评测标签不能只有speech_detectedtrue至少需要输入角色当前用户、旁人、媒体背景、回声或未知交互意图开始发言、附和、纠错、打断、继续、取消或无关期望话权动作listen / continue / backchannel / pause / interrupt / ignore任务动作保持、修改、取消、补偿或拒绝历史动作保留、截断、澄清或标记不确定。一个样本可以是多标签的。例如用户在系统播报时说“嗯明天不行换后天”前半段可能是附和后半段却构成修正。强迫整段音频只对应一个标签会把真实困难藏进标注噪声。二、场景集必须覆盖八类冲突而不是只测安静房间图 4先覆盖话权、任务、网络和副作用冲突再谈平均延迟。公开 Full-Duplex-Bench v1.5 把重叠场景拆成 interruption、user backchannel、talking to others 和 ambient/background speech。[S7] 这给出一个关键提醒重叠语音不是单一故障。内部场景集还需要连接任务与系统状态。1. 正常轮替与不同长度停顿录制句中 300ms、600ms、1200ms 停顿以及思考词、拉长音和自我修正。检查系统是否把停顿误判为轮次结束也检查为了避免抢话而过度沉默。2. 有效打断在系统播放 0.5 秒、2 秒和 5 秒时插入“停一下”“不是这个”“先别执行”。分别检查模型停止生成、网络停止传输、播放器清空旧队列、历史按实际播放修复以及旧工具或动作是否失效。3. 附和与继续倾听“嗯”“对”“然后呢”可能只表示继续。系统可以简短反馈也可以保持沉默但不应每次都取消主回答或创建新的业务任务。4. 旁人语音与环境声加入电视人声、旁人聊天、咳嗽、键盘、音乐和 AEC 残余回声。测的不是“有没有声音”而是系统是否把非目标输入升级成话权或工具动作。5. 纠错、改口与实体跟踪用户先说错日期、联系人或地点再在同一段或下一段修正。检查最终意图、参数版本和播报是否一致旧参数是否仍可能触发副作用。6. 多步工具与后台任务在查询、下单、日程、导航或机器人动作过程中插入补充、取消和新话题。检查任务是否继续、取消或转为过期完成结果是否仍有资格交付当前会话。7. 网络与媒体故障覆盖直连、TURN、抖动、丢包、短断线、重连和客户端播放队列积压。延迟必须按路线分别统计不能把直连和中继混成一个平均数。8. 恢复与降级让 STT、模型、工具、TTS 或设备回执单点失败。检查系统是明确澄清、切到按键/回合式流程还是悄悄继续并制造错误状态。场景数量不应靠排列组合无限膨胀。更合理的做法是先按风险与真实流量建立基础集再对高失败率和高副作用路径增加参数化样本。三、延迟指标必须绑定事件对而不是只有一个计时器图 5没有明确起点与终点的“首音延迟”不可比较。图 6官方文档证明开始/停止说话事件存在评测体系仍由应用团队建立。“首音延迟”至少有多个起点用户真正停止发声、客户端 VAD 停止、服务端收到音频、ASR 稳定、模型开始生成、TTS 产生首块、网关收到首块、播放器开始播放。不同团队若使用不同起点两个 300ms 根本不可比较。建议把每个指标写成事件对指标起点终点回答的问题输入结束检测延迟声学标注结束speech_stopped系统多久认为用户说完响应首音延迟期望可响应时点客户端playback_started用户何时真正开始听见软件播放打断停止延迟有效打断声学起点旧playback_stopped旧声音多久真正停下新响应恢复延迟打断意图稳定新playback_started系统多久开始回应新意图工具完成播报延迟业务结果可用结果播报开始后台结果交付是否及时重连恢复延迟连接失效新会话可交互故障后多久恢复这里的playback_started/stopped通常仍是播放器软件代理不是麦克风回采证明。声学测试需要另外保存混合输出或回采音频。服务端chunk_sent不能代替播放停止客户端received也不能代替用户听到。统计时至少报告 P50、P95、P99、样本数与失败样本不应只报平均值。还要按设备、网络路线、场景、语言和模型版本分组。一个整体 P95 可能掩盖 TURN 路径或某类手机设备的长尾。四、行为指标的核心是“该不该打断”不是“打断成功率”图 7速度、行为、任务和副作用必须独立计量不能互相抵消。如果系统对所有重叠语音都停止播放它的“停止成功率”可能很高但附和、旁人语音和环境声全部处理错误。因此行为层需要混淆矩阵。设期望动作与观察动作都来自listen / continue / backchannel / pause / interrupt / ignore每个类别分别统计 precision、recall 和关键混淆。产品还应关注错误抢话率用户仍在完成同一意图系统却开始输出漏打断率明确有效打断未停止旧播放或旧任务错误打断率附和、旁人语音或背景声导致旧响应取消错误静默率用户已结束且需要回应系统长时间无动作恢复正确率暂停或澄清后是否回到正确上下文历史一致率模型后续记忆是否只包含用户实际获得的语义旁人误响应率与环境声误激活率。分母必须公开。例如“错误打断率”可以定义为在期望不是interrupt的重叠样本中观察为interrupt的比例。若用所有样本做分母数据会被大量安静样本稀释。对持续运行设备还可报告每小时 false interruption、每小时误工具调用和每小时无法恢复会话。时间归一化指标更适合比较不同测试时长但仍要附样本构成。五、任务层必须以业务状态和副作用为真值图 8公开研究把可核验任务完成、全双工交互和真实音频条件放在同一评测问题中。语音回答听起来合理不代表任务完成。工具返回 200也不代表用户目标达成。τ-Voice 将真实领域任务、数据库和现实音频条件放在一起评测说明语音交互质量与 grounded task completion 必须同时检查。[S9-S10]任务层至少包括目标完成率最终业务状态是否满足用户目标参数一致率日期、联系人、金额、位置等是否使用最新版本工具选择和参数正确率重复副作用数同一意图是否产生重复下单、消息或设备动作取消成功率取消是否在可取消阶段真正生效补偿正确率不可逆副作用发生后是否进入明确补偿而非伪造回滚过期结果拦截率旧task_version的结果是否被阻止进入当前会话交付正确率有效后台结果是否在合适时机、对正确用户和正确会话交付恢复后任务一致率断线或重启后是否重复执行或丢失状态。“工具调用成功”只能作为中间证据。真正的业务真值可能来自订单库、日程、设备控制器、传感器或人工确认。高风险机器人动作还要区分acknowledged和completed收到命令并不等于物理完成。六、每次测试都应生成可重放的事件账本一句“听起来有点怪”无法支持根因定位。最小事件账本可包含{event_id:evt-1048,trace_id:trace-0042,session_id:sess-7,utterance_id:utt-12,response_id:resp-17,playback_id:pb-17,task_id:task-9,event_type:playback.interrupted,producer:rust-client,monotonic_ns:938472993822,wall_time:2026-08-09T10:42:31.42108:00,reason:user_interrupt,played_until_ms:1840,route:turn,schema_version:1}完整证据包通常还应保存原始或经过合规处理的输入音频系统输出和必要的声学回采ASR partial/final 与稳定前缀VAD/turn action 决策及置信和理由模型 response 与 TTS chunk 时间线播放开始、进度、完成和中断回报工具请求、权限、幂等键、结果与最终业务状态网络路线、丢包、抖动和重连信息模型、提示词、代码、配置与数据集版本。不同设备的单调时钟不能直接比较。跨端分析要记录时钟偏移估计或使用事件因果关系避免把墙上时钟误差解释成网络延迟。七、错误归因要沿链路定位而不是默认怪模型同一个“打断慢”至少有四层原因感知层晚发现AEC、噪声或 VAD 没有及时识别有效输入决策层判断慢系统等待更多语义才决定 interrupt控制层取消传播慢response、TTS、网关或队列没有及时停止播放层仍有旧音频客户端缓冲或设备输出没有清空。同样“工具结果错”也可能来自 ASR 实体、模型参数、版本竞态、工具幂等、数据库状态或交付时机。只有音频、事件和业务状态共存才能把失败放到正确责任层。建议每个失败自动生成因果切片从异常业务结果向前追到 task、response、utterance 和原始音频列出最后一个通过的门与第一个失败的门。无法定位的样本也要计数“unknown root cause”长期过高本身就是可观测性失败。八、证据要分四级自动测试不能冒充真实 E2E图 9从静态合同到生产影子逐级升级自动化通过不能直接冒充真实 E2E。L1静态合同Schema、枚举、状态机、配置和代码路径存在。它证明设计已写入系统不证明运行时行为。L2确定性自动测试用合成事件或固定音频验证取消传播、身份隔离、幂等和报告生成。它适合快速回归但不能证明真实声学环境。L3软件集成与声学回路真实进程、真实网络路径、真实播放器并通过扬声器—麦克风回路或录制混音验证打断和回声。它仍可能缺少真实设备、业务系统或用户分布。L4真实设备与生产影子真实机器人/手机/车机、真实 TURN、真实工具环境和受控影子流量具备隐私、回滚与人工复核。只有到这一层才可以讨论上线验收。当前dify_stream_test代码已经有逐轮trace_id、utterance_id、playback_id、播放完成/中断回报、首音到播放开始的字段、TURN 路径识别以及若干中断和旧播放隔离测试。这可以标为IMPLEMENTED与局部VERIFIED。本轮没有运行真实服务器、真实 TURN、声学回路或机器人动作因此不能写成端到端通过相关结论仍为UNKNOWN。九、验收矩阵要同时设质量门和证据门下面是一个示例模板数值仅用于展示结构不是 OpenAI 官方建议也不是本项目实测能力示例指标示例门槛最低证据失败动作正常响应response first audio P95 900msL3检查分段长尾有效打断old playback stop P95 350msL3阻止连续模式上线附和错误取消率 2%L3回退到保守策略背景语音每小时误响应 0.2L3强化目标说话人门工具任务grounded completion 90%L3/L4禁止自动副作用取消重复副作用0L4保留人工确认后台结果过期结果错误交付0L3/L4关闭主动插播网络恢复恢复成功率 99%L4保留回合式降级门槛应来自产品风险、当前基线和用户研究。陪伴场景可以更重自然度车载控制应更重错误动作与确认客服要兼顾任务完成和合规。没有通用阈值能同时适配这些场景。发布门还应满足关键失败为 0目标路线样本足够P95/P99 不被少量样本伪造高风险副作用通过真实环境所有失败可回放版本与配置可复现。十、一次评测报告必须能回答“变好在哪里代价是什么”建议报告包含变更对象模型、提示词、VAD、控制器、播放器、网络或工具数据集版本与场景分布与上一基线的配对比较延迟、行为、任务、副作用和主观体验五组结果P50/P95/P99、分母、置信区间或重复实验直连/TURN、设备和语言分层关键失败样本及可重放证据回归、收益与成本IMPLEMENTED / VERIFIED / UNKNOWN证据边界上线、继续影子、回退或补数据的唯一建议。如果新策略让首音快 150ms却令附和误打断增加、任务完成下降报告不能只展示最漂亮的折线。评测的目标不是证明新模型更强而是判断整个系统是否更适合当前产品。十一、主观自然度有价值但不能替代事件真值自然度、节奏、被倾听感、打断舒适度和恢复质量需要人类评价。可以采用成对盲测让评审在同一场景中比较两个版本也可以在真实任务后收集“是否需要重复”“是否感到被抢话”“是否信任任务结果”。但主观分数不能解释副作用也不能确认后台结果是否过期。评审可能觉得回答自然却不知道系统重复创建了订单。因此主观层必须与事件和业务层并列不能覆盖它们。隐私同样是硬边界。真实语音、旁人对话和业务状态可能包含敏感信息应限定采集目的、保留周期、访问范围和脱敏方式。无法安全保存原音频时至少保留合规派生特征与事件账本并明确证据缺口。十二、什么时候不该追求全双工全双工不是所有产品的默认答案。高风险命令、嘈杂工业环境、网络极不稳定、缺少设备回执或团队无法建立事件账本时按键、明确确认和回合式交互可能更可靠。一个简单替代方案是保留 WebRTC 低延迟媒体但业务动作仍要求明确轮次与二次确认允许用户随时停止播放却不允许未经确认的语音片段直接改变不可逆任务。只有当行为、任务和证据门都通过再逐步开放连续交互能力。这不是保守而是让交互复杂度与证明能力匹配。结语真正的验收对象是系统行为不是模型演示全双工语音 Agent 的质量不能被一个平均首音概括。真正的评测对象是在特定场景里系统是否选择了正确话权动作旧输出是否真正停止任务是否使用最新意图副作用是否可控失败是否可重放。因此最小评测合同应固定五件事场景、事件时间线、期望动作、业务真值和证据包。延迟回答“多快”行为回答“该不该”任务回答“做没做对”证据回答“能不能证明”。四者同时成立才有资格说系统更自然、更可靠。参考资料[S1] OpenAI, Voice agents: https://developers.openai.com/api/docs/guides/voice-agents[S2] OpenAI, Realtime VAD: https://developers.openai.com/api/docs/guides/realtime-vad[S3] OpenAI, Realtime conversations: https://developers.openai.com/api/docs/guides/realtime-conversations[S4] OpenAI, Realtime WebRTC: https://developers.openai.com/api/docs/guides/realtime-webrtc[S5] OpenAI, Realtime with tools/MCP: https://developers.openai.com/api/docs/guides/realtime-mcp[S6] Full-Duplex-Bench: https://arxiv.org/abs/2503.04721[S7] Full-Duplex-Bench v1.5: https://arxiv.org/abs/2507.23159[S8] Full-Duplex-Bench v3: https://arxiv.org/abs/2604.04847[S9] τ-Voice: https://openreview.net/forum?id2Oj6fg0m1j[S10] τ-Voice code: https://github.com/sierra-research/tau2-bench事实、设计与未知项已确认事实公开文档提供 Voice Agents、Realtime VAD/WebRTC/conversation/tools 接口公开基准覆盖重叠语音和真实任务。作者设计本文场景分类、事件账本、指标合同、证据梯度和验收矩阵。当前项目证据代码与自动测试支持若干身份、播放回报、中断与网络路径能力属于实现和局部验证。未知项真实生产环境的阈值、声学回路、真实 TURN 长尾、真实机器人动作和用户主观结果均需后续实测。