🎯 问题
turn-based 流水线两大结构病：能量 VAD 分不清犹豫/backchannel/打断；tool call 放说话前加延迟、放说话后误一轮、混进语音通道毁语音。
缺的是'在一条同步时间轴上听、说、想、动'的模型。外挂 semantic VAD 补救仍要付检测器延迟且看不到助手内部状态——作者论证足够大的原生双工模型能把这些决策吸收进核心会话能力。这段论证是'回合制假设不成立'的语音域证词。
双流三通道形式化：物理上两条音频流（用户/助手）在会话时钟上，模型接口上三条语义通道——动作通道是骑在助手时间轴上的纯文本流。每 chunk (160ms)：用户 2×80ms 因果特征（只观测）、助手 TA4（1 文本锚+4×40ms 音频 token）、动作 ≤10 文本 token（延迟转写/planning/turn-taking 标签/JSON tool call），以 <|action_end|> 强制对齐时钟。
🔧 机制
动作通道给每个动作对象和 VAD 式决策一条专用、带时间戳、与助手音频共同解码的文本车道；10 token/chunk 是部署预算不是架构约束。
关键模式：backchannel 触发工具调用（用户插句'放披头士'，助手话不断、play_music 照发）；多动作调用（一句话调 AC+音乐+导航，各 call 锚定各自 chunk 按语义顺序发射）。tool call 发射于说话中途时，读 chunk 索引即得精确时间戳。
时间锚定 trick（亚秒延迟的原因）：TA4 的文本锚左对齐不带精确时间，于是强制动作通道在'字符实际被说出的 chunk'发出助手转写——把模型内部时钟在三通道间钉死。训练两阶段：CPT（双工对话+双侧 ASR 建时序先验）→ post-training（4 交互行为+3 调用模式）；消融显示两阶段顺序不可换（先能力后时序则语音流畅度崩）。溢出 token 顺延后续 chunk。
📊 结果
DuplexSLA-Bench 2,100 例：turn-taking 四场景全部亚秒（无 prefill ~0.30s、平均准确率 94.34%）；tool call 精度持平 ASR+LLM 级联、延迟低 ~4×。
对照发现：商业 API（闭源双工）准确率高但延迟 >1s 且不暴露 backchannel 标签；开源双工底座没有针对性 post-training 在 pause 子集上直接崩溃——pause 鲁棒性必须显式监督。tool call 判定协议：函数名匹配+参数一致（LLM 判语义冲突）+触发时间窗合法（不早于真值 1s/不晚于音频尾 3s）——timing-aware 协议本身可借鉴。
工具域：50 个车舱/智能家居 function schema + 3 交互控制标签。关键局限：动作是对话内 API 调用——无被控视觉环境、无工具结果回流（发出即完成，不处理返回值）；benchmark 自建自评；权重/代码 coming soon，数字暂不可复现。
💡 对主线的启示
'动作与说话同轴'最完整模型侧方案；权重放出即进被测池；缺失轴=动作不改变环境、无墙钟压力。
三点：① 160ms 共享时钟+动作通道时间戳与 duplex-omni-agent 的 timeline/chunk 协议同族，per-chunk 动作预算=部署预算的表述给 chunked decode budget 调度一个模型侧对应物；② related work 点名时标注缺失轴（无视觉闭环、无时延-成败测量）；③ 入被测池前重查 repo 权重状态。
评测协议可借鉴处：'accuracy（行为对不对）+ delay（对时距语义锚多远、只在命中时计）'的双指标形制，和 tool call 的时间窗合法性判据——都是把'时机'升为一等公民的现成协议件。对照：τ-Voice（评测侧语音双工+任务完成）、Omni-DuplexEval（omni 双工评测零动作）、STITCH/SHANKS（说时想/听时想）。