用 GPT-Live 接语音助手，轮次控制和打断策略要先定下来

接上实时语音模型之后，“听着能用”和“轮次不乱”是两件事。用户一插话就出现回复被截断、双方同时发声，通常不是模型本身的问题，而是轮次状态没有定义、打断判定没有明确归属。建议在上线前先把两件事定成规则：谁先说话（等待超时的边界），什么时候算打断（打断判定的位置和阈值）。规则写在客户端还是服务端，取决于人声检测在哪一层拿得到、停止生成的信号由谁发出，这两处需要结合具体链路确认，不能照搬别人的架构。

轮次控制和打断策略适合在“单轮问答已跑通、多人同时说话就乱”的阶段先定规则、再调参数。操作上先补会话日志字段，用双方同时发声的时间点判断问题出在打断判定还是等待超时；再把对话拆成静音、说话、可打断、已打断四种状态，明确客户端负责检测人声与上报、服务端负责决定是否停止生成。验证靠三段自测对话加超时日志。边界是：状态机只能减少误判，无法消除网络抖动带来的重复触发，超时值必须结合环境实测再定。

在会话日志里标出双方同时发声的时间点

不要先改逻辑，先让日志能回答“同时发声是谁的问题”。建议每次会话按 turn_id 串起来，客户端采集侧、客户端播放侧、服务端各打一组时间戳。字段清单可以先按下面这些落：

turn_id：轮次编号，同一轮的用户输入与助手输出共用。
speaker：当前说话方，取值 user / assistant。
segment_start_ms / segment_end_ms：该说话方的起止时间，统一用同一时钟源或都换算成相对时间。
vad_event：人声起止事件，取值如 START / END。
interrupt_flag：本轮是否被判为打断。
interrupt_source：判定来自 client 还是 server。
playback_end_ms：助手音频实际播完的时间（被截断时写实际停止时间）。
generation_stop_ms：服务端停止生成的时间。
timeout_hit：本轮命中的超时名，如 turn_end / wait_reply / session_idle。

标记方法是把同一 turn_id 的记录按时间排序后看两个判据：若 speaker=assistant 的 playback_end_ms 晚于 speaker=user 的 segment_start_ms，而 interrupt_flag 为空，说明“同时发声发生了但打断没有判定”，问题在打断判定链路；若用户侧 segment_end_ms 之后很久才出现服务端的下一轮生成开始，且 timeout_hit=turn_end，问题在等待超时。这两类现象要分开处理，混在一起调参数通常越调越乱。

把一段对话拆成静音、说话、可打断、已打断四种状态

把轮次判断从主观感觉变成状态迁移，好处是每条迁移都能用日志核对。四种状态建议这样定义：

静音：两端都没有有效人声，助手也没有在生成或播放。
说话：只有一方在发声，另一方静默；用 speaker 区分是用户在说还是助手在说。
可打断：助手正在发声，且用户插话窗口已开放（例如助手音频已进入播放队列）。
已打断：用户人声越界，判定成立，助手停止生成并清空播放缓冲。

允许的迁移路径和触发条件：

静音 → 说话（user）：人声检测连续超过起音阈值。
说话（user） → 说话（assistant）：用户人声结束后静音时长达到轮次结束阈值，提交一次请求。
说话（assistant） → 可打断：第一条音频帧进入播放队列。
可打断 → 已打断：用户人声在窗口内持续超过最小打断时长。
可打断 → 说话（assistant）：用户人声未达最小打断时长就消失（咳嗽、误触），视为噪声，不回退状态。
已打断 → 静音：停止生成确认返回且播放缓冲清空。
任意状态 → 静音：会话空闲超时触发。

不允许的迁移要显式拒绝，例如静音直接跳到已打断、已打断直接跳到说话（assistant），出现就说明有事件重复投递或乱序。

在客户端和服务端之间划一条判定分工线

常见争议是“要不要停”这个决定放在哪。建议的原则是：客户端只做检测和上报，服务端只做判定和下发，两边都不越界。

客户端负责：采集麦克风、跑人声检测、上报人声起止事件与时间戳、播放助手音频、上报播放进度、收到停止指令后立即清空本地播放缓冲。
服务端负责：维护轮次状态、消费客户端事件、判断是否达到打断条件、决定是否停止生成、下发停止指令、记录轮次日志、做超时兜底。
不建议：客户端自行决定停止生成（多端会不一致，也无法统一记录日志）；服务端自己做人声检测（拿不到未压缩的采集流，延迟也不可控）。

通用接入骨架如下，函数名都是占位，替换成自己链路里的实现即可：

# 客户端：只检测，只上报
on_audio_frame(frame):
    voice = detect_voice(frame)            # 占位：人声检测
    if voice == START:
        send_event("user_speech_start", ts=now_ms())
    if voice == END:
        send_event("user_speech_end", ts=now_ms())

# 服务端：只判定，只下发
on_event(evt):
    st = turn_state.current()
    if evt.type == "user_speech_start" and st == INTERRUPTIBLE:
        if speech_duration(evt) >= interrupt_min_ms:
            turn_state.set(INTERRUPTED)
            cancel_generation()            # 占位：停止生成
            send_command("stop_playback")
    elif evt.type == "user_speech_end" and st == SPEAKING:
        if silence_ms() >= turn_end_silence_ms:
            start_generation()             # 占位：发起新一轮

给打断和等待各设一个超时值并在日志里观察

超时是兜底，不是主逻辑。它的作用是防止双方都等或都抢：等待超时太短会把用户正常的停顿切断，打断阈值太低会把环境噪声当成插话。可以先给一组保守起点，再结合环境确认：

timing:
  vad_onset_ms: 200             # 起音确认，抗环境噪声
  turn_end_silence_ms: 600      # 用户说完多久算一轮结束
  interruptible_after_ms: 400   # 助手开声后多久开放插话窗口
  interrupt_min_ms: 300         # 连续人声达到多久才算打断
  wait_reply_timeout_ms: 8000   # 提交后等首个音频帧的上限
  session_idle_timeout_ms: 60000

两种极端情况可以直接用日志验证：

双方都等：日志里 user_speech_end 之后长时间没有新一轮生成开始，最终命中 wait_reply 或 turn_end。优先怀疑 turn_end_silence_ms 偏大，或人声结束事件在弱网下丢失。
双方都抢：日志里 interrupt_flag 密集出现，助手音频段大量以 generation_stop_ms 提前结束。优先怀疑 interrupt_min_ms 偏小或起音阈值偏低，把背景噪声算成了插话。

验证方式就是按 turn_id 排序后看相邻时间戳的间隔，再统计 timeout_hit 命中分布，确认调整方向，而不是直接凭听感改数值。

用三段自测对话回归验证规则是否生效

每次改完阈值或分工，固定跑同样三段对话，对比日志和听感，避免把正常对话也误判成打断。

正常交替：用户说一句，等助手完整回复后再开口。
期望结果：全程不出现 interrupt_flag=true；turn_id 顺序递增；没有 timeout_hit；助手音频完整播完。
频繁插话：用户短促插入单字、咳嗽、连续抢话。
期望结果：只有超过 interrupt_min_ms 的插话才产生 INTERRUPTED 迁移；短促噪声只留下一条未被采纳的 user_speech_start；每次停止生成后都能进入下一轮，不出现状态卡死。
长时间静音：用户打开麦克风不说话，或中途离开。
期望结果：达到 turn_end_silence_ms 后回到静音；达到 session_idle_timeout_ms 后关闭会话；不反复触发生成开始。

三段跑完仍出现同时发声或状态卡死，就回到第一段的日志判据，先确认是打断判定链路还是等待超时链路，再改配置。规则先定、再调参，比上线后靠用户反馈逐个补要省事。