先给判断方向：Eleven Realtime 这类实时语音 Agent 抢话，通常不是单一参数造成的。语音活动检测（VAD）阈值决定“系统认为用户开始说话了”，打断配置决定“系统在播报中听到用户说话后要不要停”。调灵敏度没改善，多半说明误触发来自噪声段或检测尾部静音判定，而真正让模型闭嘴的是打断策略。可行的做法是先把一次抢话抓成带时间戳的事件，再做两组单变量对照：一组只动检测灵敏度，一组只动打断策略。适用范围是有日志、可改配置、能本地录音的联调环境；线上流量下噪声分布不同，结论需要结合环境确认。

抢话排查的关键是把“检测”和“打断”拆开验证，而不是反复调一个灵敏度参数。建议先录下用户语音起止、模型开始播报、音频被截断三个时间点，再固定打断配置只扫检测灵敏度，固定检测参数只改打断策略。判断依据看日志里检测事件与播报帧是否继续下发，不看主观听感。噪声段和静音段要单独跑，否则会把键盘声误判成用户插话。结论只描述参数与现象的对应关系，换环境需重跑。

复现一次抢话并抓下时间线

先把“抢话”从主观感受变成可度量事件。建议在客户端和服务端各留一份时间基准，用同一个单调时钟（例如毫秒时间戳）记录四类点：用户语音起始、用户语音结束、模型开始播报、播报被截断的位置。如果接入层能拿到音频帧回调，就在帧回调里打点，比在业务层记录更接近真实时序。

本地录音与日志对齐的做法：录制麦克风输入的同时，在每段录音开头打一个标记音（或记录录音开始的 epoch 毫秒），日志里所有事件都带同一基准的时间戳。复盘时把录音拖到对应秒数，就能听出抢话发生时用户是否还在说话、是否有键盘声。

# 通用打点骨架，字段名按你的接入层替换
event_log = {
  "ts_ms": now_monotonic_ms(),
  "event": "user_speech_start | user_speech_end | agent_play_start | agent_play_interrupted",
  "turn_id": current_turn_id,
  "vad_score": vad_score_if_available,
  "playback_offset_ms": played_ms_of_current_audio,
  "mic_rms": rms_of_last_frame,
}

一次完整事件记录应能回答：用户最后一个字结束到模型开口之间隔了多久、模型开口时检测侧是否已判定用户说完、截断发生在播报的第几毫秒。这三项凑齐，才有资格判断是检测提前收尾还是打断策略误停。

固定打断配置，只动检测灵敏度

这一组只回答一个问题：检测侧是否在用户没说完时就判定语音结束，或者被非人声误触发。操作上把打断策略开关、超时、最短播报保护等全部冻结成同一组值，只改检测灵敏度相关参数（阈值、起始判定帧数、结束静音时长一类）。参数名用占位写法，落到你的配置项：

vad:
  speech_threshold: <S>        # 扫描范围从保守到激进，按你的取值区间分 3~5 档
  min_speech_frames: <N>
  end_silence_ms: <E>          # 结束判定静音时长，也是抢话高发项
interrupt:
  enabled: true                # 本组固定不动
  min_play_ms: <固定值>

每组参数至少跑三次，用同一段说话素材，中间留停顿。每次记录字段建议固定为：参数组编号、用户语音起止时间戳、检测判定结束时间戳、模型播报开始时间戳、是否发生截断、截断位置、日志证据行号。三次结果不一致就说明素材或环境不稳，先排除麦克风增益和后台噪声再继续。

如果扫描灵敏度后抢话次数变化明显，问题偏向检测；如果灵敏度从保守调到激进，抢话次数几乎不变，检测侧大概率不是主因，往下看打断策略。

固定检测参数，只改打断策略

这一组验证播报过程中收到用户语音时的停止行为。检测参数全部冻结在上一步表现最稳的一组，只切换打断策略：开启与关闭各跑若干轮，观察模型播报过程中用户开口后，音频帧是否继续下发。

观测点要具体：播报中注入一段用户语音，看输出侧音频帧回调是否在若干毫秒内停止；关闭打断后同样注入，音频帧应继续到当前回复结束。记录模板可以这样写：

case_id | interrupt_enabled | 注入时刻(播报偏移ms) | 音频帧是否继续 | 停止延迟(ms) | 日志证据

如果开启打断后音频帧立即停止，而关闭后继续下发，说明停止行为由打断策略控制，检测只是提供了触发信号。这种情况下继续猛调灵敏度，通常不会解决抢话，反而可能让正常停顿被判成插话。

用静音段和背景噪声段验证误触发

需要区分“用户说话导致打断”和“噪声导致打断”。建议构造三段测试素材：纯静音段（录音但不说话，保留房间底噪）、键盘声段（连续敲击，不加人声）、环境人声段（远处说话或播放一段非目标说话人的语音）。每段时长保持一致，分别跑上面冻结的配置，统计每段内的检测触发次数和打断触发次数。

纯静音段有触发，说明阈值偏低或底噪被当成语音；键盘声段触发而静音段不触发，说明检测对瞬态噪声敏感，可以考虑起始判定帧数或最短语音时长；环境人声段触发属于正常检测行为，但是否要打断取决于产品设计。三段统计放在一起看，才能判断抢话是灵敏度问题还是策略问题。每段测试都要保存原始录音，换环境后重跑，不要沿用上一次的数字。

整理参数组合与现象的对照表

把前四步的结果收进同一张表，形成可复用的排查顺序。列定义固定为灵敏度、策略、现象、日志证据，结论只写现象对应关系，不写推测性因果。

灵敏度 | 策略   | 现象                         | 日志证据
低     | 开     | 用户未说完即被截断            | 播报中段出现 interrupt 事件，检测结束时间早于用户语音结束
低     | 关     | 播报继续，用户语音被淹没      | 检测有事件，播放帧未停止
高     | 开     | 键盘声也触发截断              | 静音/键盘段出现 speech_start
高     | 关     | 噪声段无截断，但检测频繁触发  | speech_start 密集，播放帧持续

排查顺序建议固定为：先抓时间线确认抢话真实存在，再固定策略扫灵敏度，再固定灵敏度切策略，最后用三段素材排除噪声，把结果填表。表里同一现象在不同环境出现差异，属于正常，说明该环境噪声分布或音频链路不同，需要重新采样验证，而不是直接套用上一组结论。