全双工语音 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：场景、时间线、预期动作、业务真值和证据包共同组成最小评测单位。

传统请求评测通常只有输入、输出和耗时。连续语音中的一次交互却可能同时包含用户语音、系统播放、重叠片段、工具调用、后台任务和网络切换。若只保留最终文本，就无法知道系统为何打断、旧音频是否真的停止、工具结果是否已经过期。

更完整的样本应包含五部分：

yaml 复制代码

case_id: overlap-interrupt-0042
scenario:
  foreground_user: "停一下，改成明天"
  overlap_at_ms: 1850
  background_audio: none
  network_route: turn
expected:
  turn_action: interrupt
  old_playback: stopped
  old_task: cancel_or_stale
  new_intent: update_date
observed:
  trace_id: trace-0042
  utterance_id: utt-0042
  response_id: resp-17
  playback_id: pb-17
  task_id: task-9
business_truth:
  final_date: 2026-08-10
  duplicate_side_effects: 0
evidence:
  - input.wav
  - mixed_output.wav
  - events.jsonl
  - tool-audit.json
  - final-state.json

这里最重要的变化，是把"期望输出文本"改成"期望动作与最终状态"。同一句"嗯"，在不同上下文里可能是附和、犹豫、确认或否定前缀；同样检测到语音重叠，期望动作可能是继续听、简短附和、暂停输出、完全打断或忽略背景声。

所以评测标签不能只有 speech_detected=true，至少需要：

输入角色：当前用户、旁人、媒体背景、回声或未知；
交互意图：开始发言、附和、纠错、打断、继续、取消或无关；
期望话权动作：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：速度、行为、任务和副作用必须独立计量，不能互相抵消。

如果系统对所有重叠语音都停止播放，它的"停止成功率"可能很高，但附和、旁人语音和环境声全部处理错误。因此行为层需要混淆矩阵。

设期望动作与观察动作都来自：

text 复制代码

listen / continue / backchannel / pause / interrupt / ignore

每个类别分别统计 precision、recall 和关键混淆。产品还应关注：

错误抢话率：用户仍在完成同一意图，系统却开始输出；
漏打断率：明确有效打断未停止旧播放或旧任务；
错误打断率：附和、旁人语音或背景声导致旧响应取消；
错误静默率：用户已结束且需要回应，系统长时间无动作；
恢复正确率：暂停或澄清后是否回到正确上下文；
历史一致率：模型后续记忆是否只包含用户实际获得的语义；
旁人误响应率与环境声误激活率。

分母必须公开。例如"错误打断率"可以定义为：在期望不是 interrupt 的重叠样本中，观察为 interrupt 的比例。若用所有样本做分母，数据会被大量安静样本稀释。

对持续运行设备，还可报告每小时 false interruption、每小时误工具调用和每小时无法恢复会话。时间归一化指标更适合比较不同测试时长，但仍要附样本构成。

五、任务层必须以业务状态和副作用为真值

图 8：公开研究把可核验任务完成、全双工交互和真实音频条件放在同一评测问题中。

语音回答听起来合理，不代表任务完成。工具返回 200，也不代表用户目标达成。τ-Voice 将真实领域任务、数据库和现实音频条件放在一起评测，说明语音交互质量与 grounded task completion 必须同时检查。 $S9-S10$

任务层至少包括：

目标完成率：最终业务状态是否满足用户目标；
参数一致率：日期、联系人、金额、位置等是否使用最新版本；
工具选择和参数正确率；
重复副作用数：同一意图是否产生重复下单、消息或设备动作；
取消成功率：取消是否在可取消阶段真正生效；
补偿正确率：不可逆副作用发生后是否进入明确补偿，而非伪造回滚；
过期结果拦截率：旧 task_version 的结果是否被阻止进入当前会话；
交付正确率：有效后台结果是否在合适时机、对正确用户和正确会话交付；
恢复后任务一致率：断线或重启后是否重复执行或丢失状态。

"工具调用成功"只能作为中间证据。真正的业务真值可能来自订单库、日程、设备控制器、传感器或人工确认。高风险机器人动作还要区分 acknowledged 和 completed：收到命令并不等于物理完成。

六、每次测试都应生成可重放的事件账本

一句"听起来有点怪"无法支持根因定位。最小事件账本可包含：

json 复制代码

{
  "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.421+08: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	`< 900ms`	L3	检查分段长尾
有效打断	old playback stop P95	`< 350ms`	L3	阻止连续模式上线
附和	错误取消率	`< 2%`	L3	回退到保守策略
背景语音	每小时误响应	`< 0.2`	L3	强化目标说话人门
工具任务	grounded completion	`> 90%`	L3/L4	禁止自动副作用
取消	重复副作用	`0`	L4	保留人工确认
后台结果	过期结果错误交付	`0`	L3/L4	关闭主动插播
网络恢复	恢复成功率	`> 99%`	L4	保留回合式降级

门槛应来自产品风险、当前基线和用户研究。陪伴场景可以更重自然度，车载控制应更重错误动作与确认，客服要兼顾任务完成和合规。没有通用阈值能同时适配这些场景。

发布门还应满足：关键失败为 0；目标路线样本足够；P95/P99 不被少量样本伪造；高风险副作用通过真实环境；所有失败可回放；版本与配置可复现。

十、一次评测报告必须能回答"变好在哪里，代价是什么"

建议报告包含：

变更对象：模型、提示词、VAD、控制器、播放器、网络或工具；
数据集版本与场景分布；
与上一基线的配对比较；
延迟、行为、任务、副作用和主观体验五组结果；
P50/P95/P99、分母、置信区间或重复实验；
直连/TURN、设备和语言分层；
关键失败样本及可重放证据；
回归、收益与成本；
IMPLEMENTED / VERIFIED / UNKNOWN 证据边界；
上线、继续影子、回退或补数据的唯一建议。

如果新策略让首音快 150ms，却令附和误打断增加、任务完成下降，报告不能只展示最漂亮的折线。评测的目标不是证明新模型更强，而是判断整个系统是否更适合当前产品。

十一、主观自然度有价值，但不能替代事件真值

自然度、节奏、被倾听感、打断舒适度和恢复质量需要人类评价。可以采用成对盲测，让评审在同一场景中比较两个版本；也可以在真实任务后收集"是否需要重复""是否感到被抢话""是否信任任务结果"。

但主观分数不能解释副作用，也不能确认后台结果是否过期。评审可能觉得回答自然，却不知道系统重复创建了订单。因此主观层必须与事件和业务层并列，不能覆盖它们。

隐私同样是硬边界。真实语音、旁人对话和业务状态可能包含敏感信息，应限定采集目的、保留周期、访问范围和脱敏方式。无法安全保存原音频时，至少保留合规派生特征与事件账本，并明确证据缺口。

十二、什么时候不该追求全双工

全双工不是所有产品的默认答案。高风险命令、嘈杂工业环境、网络极不稳定、缺少设备回执，或团队无法建立事件账本时，按键、明确确认和回合式交互可能更可靠。

一个简单替代方案是：保留 WebRTC 低延迟媒体，但业务动作仍要求明确轮次与二次确认；允许用户随时停止播放，却不允许未经确认的语音片段直接改变不可逆任务。只有当行为、任务和证据门都通过，再逐步开放连续交互能力。

这不是保守，而是让交互复杂度与证明能力匹配。

结语：真正的验收对象是系统行为，不是模型演示

全双工语音 Agent 的质量不能被一个平均首音概括。真正的评测对象是：在特定场景里，系统是否选择了正确话权动作，旧输出是否真正停止，任务是否使用最新意图，副作用是否可控，失败是否可重放。

因此最小评测合同应固定五件事：场景、事件时间线、期望动作、业务真值和证据包。延迟回答"多快"，行为回答"该不该"，任务回答"做没做对"，证据回答"能不能证明"。四者同时成立，才有资格说系统更自然、更可靠。

参考资料

$S1$ OpenAI, Voice agents: developers.openai.com/api/docs/gu...
$S2$ OpenAI, Realtime VAD: developers.openai.com/api/docs/gu...
$S3$ OpenAI, Realtime conversations: developers.openai.com/api/docs/gu...
$S4$ OpenAI, Realtime WebRTC: developers.openai.com/api/docs/gu...
$S5$ OpenAI, Realtime with tools/MCP: developers.openai.com/api/docs/gu...
$S6$ Full-Duplex-Bench: arxiv.org/abs/2503.04...
$S7$ Full-Duplex-Bench v1.5: arxiv.org/abs/2507.23...
$S8$ Full-Duplex-Bench v3: arxiv.org/abs/2604.04...
$S9$ τ-Voice: openreview.net/forum?id=2O...
$S10$ τ-Voice code: github.com/sierra-rese...

事实、设计与未知项

已确认事实：公开文档提供 Voice Agents、Realtime VAD/WebRTC/conversation/tools 接口；公开基准覆盖重叠语音和真实任务。
作者设计：本文场景分类、事件账本、指标合同、证据梯度和验收矩阵。
当前项目证据：代码与自动测试支持若干身份、播放回报、中断与网络路径能力，属于实现和局部验证。
未知项：真实生产环境的阈值、声学回路、真实 TURN 长尾、真实机器人动作和用户主观结果，均需后续实测。