我们注意到一个反直觉的现象：很多语音 Agent 的网络指标全绿，用户体验却像不会听人说话的客服。这篇文章把「全双工」拆成了三件事讲清楚——传输层、推理层、交互认知层——并指出生产事故往往发生在四份状态（收音、模型响应、播放队列、对话历史）对同一事件给出不同答案的时刻。

这是什么

作者的核心论点是：WebRTC 的 sendrecv（双向收发）只解决「音频能不能同时流动」，不解决「谁该说话、何时让话、对方是抢话还是附和」。一个真正可用的全双工语音 Agent 至少需要三层能力同时打通。

传输层负责媒体同时收发，由 WebRTC 等协议保证；推理层要求新输入能改变正在生成的输出，而不是等当前回答播完再处理；交互认知层负责判断一段重叠声音是附和（"嗯""对"）、明确接管（"等等""不对"）、思考中的填充词、还是旁人/背景噪声。三层可以分别成功，也可以分别失败，业界把它们打包成「全双工」一个词，是问题被掩盖的根源。

更棘手的是四份运行状态容易分裂：模型已取消但扬声器还在播、播放已停但对话历史记下了用户没听到的内容、后台把旁人说话创建成新回合。这些分裂不会让系统崩溃，只会让对话"看起来正常、听着别扭"。

行业怎么看

支持作者观点的工程实践正在成型。OpenAI Realtime API 提供的 speech_started / speech_stopped 事件、interrupt_response 开关被作者视为「边界样本」——它给了应用建立打断链路的能力，但事件和开关本身不替应用回答"这次重叠是哪一种交互意图"。文中建议把话权决策显式化为带原因、置信度、后果的结构化输出（例如 decision=BACKCHANNEL_ACCEPT, action=keep_speaking_and_keep_listening），而不是把所有逻辑藏进 VAD（语音活动检测，简单说就是"判断有没有人在说话"的模块）阈值。

但也有需要警惕的反面声音。把全双工拆成三层、要求显式决策对象，听起来工程严谨，实际上可能把一个本该由模型端到端学习的能力，重新退化成规则系统。有研究者担心，过度结构化的"话权控制"会让语音 Agent 失去大模型的流畅感，回到传统 IVR（电话菜单系统）那种机械感。换句话说：交互认知层到底该交给模型学，还是该写成可观测的决策树，目前业内没有共识。

对普通人的影响

对企业 IT：评估语音客服、语音 Agent 供应商时，别只问"支不支持 WebRTC"或"延迟多少毫秒"，要问"打断后对话历史怎么修正""对方说'嗯'时会不会让出话权"。

对个人职场：经常和 AI 语音助手开会的销售、客服、产品经理，未来一年会明显感觉到"哪些产品会听人话、哪些还在抢话"的差距，这会直接影响选型。

对消费市场：智能音箱、车机、AI 客服的"不自然感"短期内不会消失——技术问题已经清晰，但工程落地成本高，真正流畅的对话体验可能还要等一两个版本迭代。