文章目录
-
-
- 前言
- [1 先戳破一个伪概念：双向音频≠全双工](#1 先戳破一个伪概念：双向音频≠全双工)
-
- [1.1 sendrecv只管修路，不管交通规则](#1.1 sendrecv只管修路，不管交通规则)
- [2 真全双工，得连闯三关](#2 真全双工，得连闯三关)
-
- [2.1 第一关：传输层，先保证路是通的](#2.1 第一关：传输层，先保证路是通的)
- [2.2 第二关：推理层，新输入能改正在说的话](#2.2 第二关：推理层，新输入能改正在说的话)
- [2.3 第三关：交互认知层，听得见还得听得懂](#2.3 第三关：交互认知层，听得见还得听得懂)
- [3 生产环境最坑的：四份状态各说各的](#3 生产环境最坑的：四份状态各说各的)
-
- [3.1 模型停了，扬声器还在嘴硬](#3.1 模型停了，扬声器还在嘴硬)
- [3.2 声音停了，历史还在脑补](#3.2 声音停了，历史还在脑补)
- [3.3 同一段语音，被解读出八百个意思](#3.3 同一段语音，被解读出八百个意思)
- [4 一个最小事件账本，把乱局捋明白](#4 一个最小事件账本，把乱局捋明白)
- [5 四个对抗探针，比一百次演示都管用](#5 四个对抗探针，比一百次演示都管用)
-
- [5.1 探针A：附和不能夺走话权](#5.1 探针A：附和不能夺走话权)
- [5.2 探针B：实体修正得全套重来](#5.2 探针B：实体修正得全套重来)
- [5.3 探针C：旁人说话别瞎接茬](#5.3 探针C：旁人说话别瞎接茬)
- [5.4 探针D：没听到的别装听过](#5.4 探针D：没听到的别装听过)
- [6 指标别揉成一个数，三层分开算](#6 指标别揉成一个数，三层分开算)
- [7 全双工不是徽章，分场景选才对](#7 全双工不是徽章，分场景选才对)
-
P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看， 传送门https://blog.csdn.net/HHX_01
前言
做语音Agent的圈最近有个特别好笑的误区：只要接了WebRTC开了双向，就敢说自己做的是全双工。
结果实际用起来还是老样子：你随口"嗯"一声它立马掐断回答，你纠正个地名它模型都停了喇叭还多蹦半句，旁边人搭句话它直接新开一轮对话。
就像你碰上个号称善于倾听的朋友，你每喘口气他都立刻闭嘴等你发飙，主打一个过度敏感。
1 先戳破一个伪概念：双向音频≠全双工
很多人嘴里的全双工，其实就是WebRTC的sendrecv模式。
标准写得明明白白：sendrecv只管音频流能同时收发，剩下的一概不管。
1.1 sendrecv只管修路，不管交通规则
说直白点，sendrecv就是给你修了条双向车道。
路能同时跑两边的车，但谁该让谁、加塞算不算违章、副驾喊的话算不算数，它半毛钱都不管。
不少团队验收全双工，就测个RTT、抖动、丢包率，测完就拍板落地。
这跟买车只查轮胎有没有气，就敢吹自己操控好有啥区别。
2 真全双工，得连闯三关
别把全双工当成一个非黑即白的开关。
它得分三层，一层过了都不算，三层全通才是真的。
2.1 第一关：传输层，先保证路是通的
传输层就是基础盘，麦克风能持续上传，扬声器能持续播放。
网络差的时候不崩，切设备的时候能快速恢复，这就及格了。
但这只是必要条件，连入门都算不上。
最典型的伪全双工：音频是实时传了，服务端非得等当前回答播完才把用户语音喂给模型。
说白了就是跑得快的回合制，跟语音条连发没本质区别。
2.2 第二关：推理层，新输入能改正在说的话
很多人觉得，有个cancel接口就算过了这关。
这就像你家电视有个关机键，不等于它知道什么时候该自己关。
比如系统正说"杭州明天有雨"，用户插一句"不是杭州，是青岛"。
不是光把当前生成停了就行，得完成一整套动作。
给新输入记上身份，找到正在跑的响应，判断该停还是该改，同时停模型和客户端播放，最后修正对话历史再重新生成。
很多系统倒好，服务端cancel返回成功了，客户端缓冲里还在播后半句。
主打一个将在外君命有所不受。
2.3 第三关：交互认知层，听得见还得听得懂
这层才是真正拉开差距的地方。
同样是系统说话时出现新声音，意思可能完全不一样。
"嗯""对""我在听"是附和，你接着说就行。
"等等""不对""停一下"是接管，你得赶紧闭嘴。
旁边人聊天、电视声、回声，那是噪声，你别搭理。
很多系统根本不分，只要检测到声音就打断，比班主任抓上课说话还积极。
你咳嗽一声它停，你吸口气它停，隔壁装修它也停，主打一个草木皆兵。
3 生产环境最坑的：四份状态各说各的
真上线了之后你会发现，单个组件挂了反而好修。
最怕的是收音、模型、播放、对话历史四份状态，对同一件事给出四个答案。
就像四个部门汇报同一个项目，一个说交付了，一个说还在开发，一个说用户验收了，一个说需求还没定。
每条日志看都没问题，凑到一起就是一坨乱麻。
3.1 模型停了，扬声器还在嘴硬
最常见的情况：服务端已经把响应取消了，客户端缓冲里的音频还在慢慢播。
后台日志显示成功停止，用户耳朵里却多听了半句尾巴。
光催着调用cancel没用，得给播放队列加版本号，旧响应的音频后续直接拒收，该清空就清空。
3.2 声音停了，历史还在脑补
客户端倒是及时停了，服务端却把整段回答全塞进对话历史里。
下一轮模型默认用户全听完了，说出来的话东一榔头西一棒子，用户听得一头雾水。
必须记清楚用户实际听到了哪个时间点，历史就截到哪，别拿生成完的内容当用户听过的内容。
3.3 同一段语音，被解读出八百个意思
同一段用户说话，VAD检测一次，ASR识别一次，网关再触发一次，来回创建好几个事件。
结果就是既触发了取消，又开了新回合，回声消除完还能再提交一次。
没个统一的事件ID，你根本不知道是哪次决策搞砸的，只能对着一堆正确的日志发呆。
4 一个最小事件账本，把乱局捋明白
想解决上面的问题，不用一上来就搞什么宏大架构。
先做个最小的事件账本，几个核心字段就够。
给每个输入事件一个唯一ID，从收音到决策到停播到改历史，全链路串起来。
哪个响应在跑、为什么做这个决策、播放停在什么时候、用户听到哪了、历史截到哪，一笔一笔记清楚。
不用管你用的是WebRTC还是WebSocket，是端侧模型还是级联方案，这套逻辑都能用。
说白了就是先把账记明白，出了问题才找得到责任人。
5 四个对抗探针，比一百次演示都管用
很多团队演示全双工，就找个场景喊一声"停"，一停就算成功。
这就像考试只背一道题，考了满分也说明不了啥。
真要验收是不是真全双工，拿四个探针挨个测。
5.1 探针A：附和不能夺走话权
系统正说一段长内容，用户中间插一句"嗯""对"。
合格的表现是：识别出是附和，接着往下说，也不新开用户回合。
要是但凡有个短声音就停，说明推理层能取消，但认知层根本没过关。
5.2 探针B：实体修正得全套重来
就用改地名的例子，从用户开口到模型停、播放停、历史截、新回答开始，四个时间点都得记。
只测其中一个延迟，就是在藏状态分裂的问题。
5.3 探针C：旁人说话别瞎接茬
系统播放的时候，旁边放旁人说话的声音或者电视声。
就算不能精准识别说话人，至少别直接打断、别写进主用户历史里。
保守点总比乱接话强。
5.4 探针D：没听到的别装听过
回答到一半强行打断，下一轮问"你刚才最后说啥了"。
要是模型能说出没播放的后半句，说明历史状态根本没对齐。
主打一个系统自己跟自己对话，用户全程蒙在鼓里。
6 指标别揉成一个数，三层分开算
别整什么"全双工延迟"一个总分来糊弄人。
三层能力对应三类指标，本来就不是一回事。
传输层看RTT、抖动、丢包、设备切换恢复，回答的是声音能不能稳定到。
推理层看输入接收、模型取消、播放停止、重规划的延迟，回答的是新输入能不能真的改输出。
认知层看误打断率、附和保持率、噪声污染率，回答的是动作做得到底对不对。
这些指标本来就有张力，你把打断门槛调得极低，延迟肯定好看，但误打断也会暴涨。
就像保安见人就拦，反应是快，挨骂也多。
7 全双工不是徽章，分场景选才对
最后说句实在话，不是所有产品都适合卷全双工。
开放对话、语言陪练、复杂客服这种场景，用户经常插话改口，全双工确实提升体验。
要是就短命令控制、合规播报、高风险确认，老老实实做回合制反而更靠谱。
总不能家里猫叫一声，就把你的支付确认给打断了吧。
全双工是一项场景能力，不是什么高阶成就徽章，没必要为了吹牛逼硬上。
所以以后再有人跟你吹他们的语音Agent是全双工，别问"能不能打断"。
你就追问四件事：为什么打断、停了哪个响应、用户实际听到哪了、下一轮历史改没改。
能答得上来的，才是真的从双向音频，走到了能用的全双工交互。
P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门https://blog.csdn.net/HHX_01