企业官网建设流程全解析

过去的语音Agent项目，用户基本都在跟一个“对讲机”对话：说一句，等半天，再听它回一句，中间还要忍受各种转写的延迟和语气停顿。最近某个开源智能体平台更新了全双工音视频能力，把可打断对话也一起放了出来，说实话有点超出预期。这套更新把链路从半双工彻底拉到了全双工，用户可以在AI说话的任何时候插嘴，AI能立刻停下来听你的新指令，整体交互感从“排队打电话”变成了“面对面聊天”。这篇文章想把这个更新的技术原理、实现路径、接入实操和调试踩坑都掰开聊透，给正在评估或者准备接语音交互的团队一个可以直接落地的参考。

1. 这次更新到底改了什么

1.1 从半双工到全双工，不是简单铺管线

以前我们做语音对话，链路基本都是串行的：录音结束，把整段音频丢给ASR，拿到文本再交给LLM，LLM输出完再做TTS，播放给用户。这套流程所有环节都在等上一个环节完成，所以叫半双工，跟对讲机一样，同一时间只有一方能说话。缺点很明显：延迟叠加严重，用户体验断裂，而且用户一旦发现AI还在播放上一条回复，就只能在旁边干等着，想打断也没办法。

这次更新的核心是将整个对话链路改成全双工。音频流和视频流的采集、传输、处理都不再等待完整结果才开始，而是边采集边传输，边识别边生成，边合成边播放。ASR输出增量文本，LLM基于增量文本做流式生成，TTS读一段播一段，三者的管道被彻底打通。用户在AI说话的同时也能输入语音，系统实时检测到“用户开口了”这个动作，立刻中断当前输出，进入接收指令状态。

从技术实现上看，这远不是改几个接口那么简单。半双工架构是把音频当文件在传，全双工必须把音频当流在跑，两者对系统设计的要求完全不同。流式ASR要处理不完整的输入，TTS要支持音频增量下发，对话管理器要能维护同时发生的输入输出上下文，任何一个环节的设计思路不对，整体就会卡顿或者反过来把用户的语音当成回声处理掉。

1.2 可打断对话：让用户重新掌握对话主导权

在很多真实的对话场景里，打断是一种常态，不是异常。用户可能听到一半改变了主意，可能AI误解了需求需要马上纠正，也可能用户只是突然想起了别的事要优先处理。可打断能力就是让人机交互回归这种天然节奏，而不是让人去适应机器的输出节奏。

这次平台给出的方案包含了完整的打断检测与处理链路：前端用VAD检测用户的语音活动，一旦在AI说话期间检测到人声，就触发打断信号，TTS停止播放，LLM停止生成，系统进入倾听状态。用户后面的输入会被重新识别并作为新的上下文补充到对话中，AI基于最新输入重新组织回复。整个过程响应时间预计在几百毫秒级别，体感上就是“我刚开口，它就已经闭嘴在听了”。

这里值得强调的是，视频能力的加入让打断不只是“停下说话”。全双工音视频意味着AI可以从摄像头画面里读到用户的表情和动作状态，让整个交互具备多模态感知的基础。镜头前用户摇头、举手、张嘴说话这些信号，未来都可以成为打断判断的一部分依据。当前版本既然把音视频全双工这个底座铺好了，后续在这上面做多模态交互就只是时间问题了。

2. 全双工音视频的技术拆解

2.1 媒体传输底座：为什么首选WebRTC这一类实时链路

全双工音视频对传输链路的要求非常明确：低延迟、双向实时、稳定。普通的HTTP请求-响应协议在这里完全不可用，轮询也不行，延迟高且无法承载持续性的双向媒体流。实际工程里最常用的方案就是WebRTC，这套标准把音频采集、编解码、网络穿透、加密传输整个媒体链路都封装好了，浏览器原生支持，移动端也有成熟SDK。

WebRTC的核心是P2P连接，但在真实部署中，绝大多数场景需要一台媒体服务器去做信令转发、流路分发和音视频处理。平台侧的架构大致是这样的：前端通过getUserMedia采集麦克风和摄像头数据，创建RTCPeerConnection连接到服务端，两端通过RTP协议传输音视频包。信令层面用WebSocket或者其他消息通道完成SDP协商、ICE候选交换，这一套流程网上有大量资料，但要做稳定得把STUN和TURN服务器配好，特别是用户处于复杂网络环境时，TURN中继几乎是必须的。

音频编解码器方面，全双工场景基本默认OPUS，这种编码器在窄带、宽带和超宽带下都能工作，而且延迟低、抗丢包能力强，非常适合实时语音交互。视频这边更多是VP8和H264，两者在浏览器兼容性上都还不错，H264在部分移动设备上有硬件编码优势，VP8则在开源生态里更清爽。实测下来，如果视频不是核心交互手段，建议把视频分辨率压在720p以内，码率也控制在1Mbps左右，为语音流留出充足的带宽余量，避免网络抖动时出现语音卡顿。

2.2 流式处理链路：ASR、LLM、TTS如何在低延迟下协同

媒体传输的问题是“路”，流式处理链路解决的是“车”。全双工对话的实现，本质上是要把ASR、LLM、TTS三个重模块全部流式化，并且让它们在对话管理器统一调度下协同工作。

流式ASR的特点是增量返回。用户还在说话的时候，识别结果就已经开始一段段地出来，而不是等用户停顿才输出完整句子。这套机制的工程价值在于，打断场景中系统可以边听边理解，用户在说完“等一下”的瞬间就已经把指令送入了上下文，不用等待一句话完整结束。

LLM侧的流式生成大家比较熟了，类似打字机效果，token一个接一个地从模型输出。但全双工场景里LLM不仅要会流式生成，还要能接收“停止生成”的控制信号。这里工程上要考虑的是如何优雅中断：直接掐断网络请求不现实，会导致资源泄漏，更合理的做法是发送一个终止事件给生成器，让生成器做完当前步就主动释放。

TTS的流式合成要求更高，因为音频必须以“可播放的块”持续下发。传统TTS要等整句文本合成完才返回一个完整音频文件，全双工链路要求TTS引擎在拿到文本块后立即开始合成并推送音频帧。现在主流方案基本都基于流式TTS引擎，首包延迟可以压到几百毫秒，但音质和速度的平衡就需要团队反复调试了。

整个链路协同下来，核心指标就是“用户说完话到AI开始出声”的往返时间。这个时间由ASR端到端延迟、LLM首token时间和TTS首包时间共同决定，链路上任何一环慢了都会拖累整体体验。当前平台的实测水平，稳态网络下首字响应能控制在一秒左右，这个体感已经接近真人对话的节奏了。

2.3 视频通道的加入，带来了哪些额外考量

音频全双工已经很难了，再加入视频通道，工作量不是简单叠加。视频流对带宽的要求比音频高一个数量级，这意味着媒体服务器的转发压力、客户端的解码压力和网络的整体负载都要重新评估。

视频链路的核心问题是同步。音频和视频帧在采集端产生的时间戳不同，传输过程中的抖动也不同，到播放端容易出现音画不同步。全双工场景对音画同步的容忍度比娱乐直播更低，毕竟这不只是让人看着舒服，AI还要去理解画面内容。虽然当前版本还没有把视频理解作为交互主链路，但这个逻辑已经在架构上预留了位置——媒体流端到端经过统一的时序标注，后续接入视觉模型做表情识别、手势判断时，不用重新设计管线。

另一个实际问题是设备能力差异。音频只要麦克风好一点就能有不错的效果，视频却涉及摄像头分辨率、采集帧率、编码性能等多个维度。同一套代码在不同设备上的表现差异可能很大，平台更新里提供了码率自适应和分辨率动态调整的能力，这一点对真实场景落地非常重要。我实际部署时就发现，部分老设备的摄像头采集720p都吃力，强制高码率反而拖垮了整个会议的流畅度，不如主动降级到480p保证音频的实时性。

3. 可打断对话的实现原理与关键设计

3.1 打断的本质：从单向输出升级为双向交互

打断这个词在语音交互里叫Barge-in，本质上是把“AI输出”和“用户输入”这两条原本互斥的通路改成可以并行发生的事件流。系统需要在AI输出的同时持续监听用户输入，一旦确认用户开始说话，就立刻切换状态，把资源从输出侧释放出来，转向输入侧处理。

这件事的难点在于判断“用户是否真的在说话”。环境里到处都有声音，空调噪音、键盘敲击、周围人说话，如果系统把所有这些都当成用户打断信号，那AI会频繁误停，体验反而更差。所以工程上通常采用“VAD预判 + ASR确认”的双重机制：本地VAD先基于音频能量和语音特征做快速初筛，一旦判断有语音活动才触发打断流程，同时把这段音频送入流式ASR确认是不是真的有语义内容，避免把噪声当成指令。

3.2 一条完整的打断链路：从VAD触发到新回复播放

结合平台当前的开源实现，一次完整的打断过程大概是这样的：

1. AI正在播放TTS音频，同时麦克风持续采集上行音频。
2. 前端VAD模块检测到用户语音活动，立即暂停TTS播放，并同步发送打断事件到服务端。
3. 服务端收到打断事件后，向ASR模块确认当前音频流，同时向LLM生成器发送停止指令，终止当前回复的进一步生成。
4. ASR将用户的增量识别文本送入对话上下文管理模块，LLM基于最新上下文重新组织回复。
5. 新的回复文本通过流式TTS生成音频帧，推送到前端播放。

这里有一个容易被忽视的细节：用户打断时说的内容往往不是一句完整的话，比如“不对，我说的是明天”或者“等等，换个思路”。LLM要能理解这种碎片化输入并修正之前的回复，这要求上下文管理模块把“用户打断前的旧请求”、“AI被打断时已输出的内容”、“用户打断时说的新内容”三部分信息都保留并传给模型。很多团队在集成时只传了最新一句用户语音，结果模型完全不理解在聊什么，这个坑我后面还会细说。

3.3 打断工程里最容易翻车的关键细节

第一个细节是TTS播放尾音的残留。打断信号发出后，音频播放器其实还有一小段buffered音频没播完，如果直接把播放器关闭，用户会听到一声“咔”的爆音。规范的处理是先做一个几十毫秒的快速衰减，让音量平滑降到零，再彻底释放播放资源。这个处理说实话很影响主观体验，做好了用户觉得“自然”，做不好用户只觉得“被打断了还是不舒服”。

第二个细节是LLM上下文的错乱。很多时候打断发生在LLM已经生成到一半的时候，这时候强行终止生成，模型可能已经“看过”了部分用户输入，也可能还没看到。如果上下文管理没有处理好，模型会把被打断时的中间状态和新的用户输入混在一起，导致回复逻辑混乱。建议的做法是在记录对话历史时，把“被打断的不完整回复”标记成一个特殊角色条目，让模型明确知道这个输出未完成，不要把它当成既定事实参与后面的推理。

第三个细节是回声干扰。全双工场景下扬声器播放的声音会通过麦克风再次进入系统，如果回声消除做得不彻底，AI自己说的话会被当成用户输入，产生误打断。这实际上是全双工平台最常见的问题，我在多个项目里都遇到过，排查到最后基本都是AEC模块没有针对实际设备做参数适配。理想的方案是设备端开启硬件回声消除，软件端再用AEC兜底，两层配合才能压住回声。

4. 实操：把全双工可打断对话接进自己的项目

4.1 环境准备与快速部署

平台既然开了源，第一步自然是把服务端跑起来。我用的部署方式是Docker Compose拉起整个服务集群，包括媒体服务器、信令服务、ASR服务和LLM网关。镜像拉下来之后，需要重点关注三个配置项：媒体端口范围、STUN/TURN服务地址、ASR模型的语言和热词表。

媒体端口范围这个配置容易被忽略。WebRTC协商成功后，媒体流的传输需要开放UDP端口，如果在云服务器上部署，安全组里没放行端口，音视频数据就会全部卡住，信令层面看着一切正常，但实际没有任何媒体流到达。我一开始就在这个坑里待了一段时间，排查了半天才发现是端口被防火墙拦了。

TURN服务建议直接用开源实现搭一个，不要图省事跳过。开发环境可以靠内网直连撑过去，但测试人员一旦切到4G网络、公司Wi-Fi或者跨运营商网络，P2P打洞失败的概率会大幅上升，没有TURN中继，通话根本建立不起来。

4.2 接入流程与会话建立

前端接入的核心步骤可以归纳成一条链路：

1. 从业务后端请求一个智能体会话ID，拿到用于建立RTC连接的信令票据。
2. 通过WebSocket连接信令服务，交换SDP和ICE候选信息。
3. 创建RTCPeerConnection，将麦克风和摄像头的MediaStream track添加到连接中。
4. 收到AI侧媒体流后，绑定到audio和video元素进行播放。
5. 打开微前端VAD监听，启动打断检测逻辑。

这里要留意一个浏览器策略问题：自动播放策略。Chrome这类浏览器在用户没有与页面交互之前，不允许自动播放带声音的媒体。所以刚开始接入时经常会遇到AI那边已经在生成回复，但前端就是不出声的情况。解决办法很简单，在页面加载完成后主动调用一次play，或者引导用户先点击一次“开始对话”按钮，把用户的交互手势当成解锁自动播放的钥匙。

4.3 需要关注的参数与调试建议

我把实际调试中高频调整的几个参数列成了一张表，方便对照修改：

4.4 我这边实测下来的数据

为了验证效果，我在内网环境做了一组相对完整的测试。硬件是一台普通的Linux服务器当服务端，前端用Chrome浏览器模拟用户，距离麦克风大概30厘米。网络是千兆内网，理论上排除公网抖动干扰。

先说最核心的指标：从用户说完“你好”到AI起声回复“我在”，完整链路大约在1.2秒到1.5秒之间。这个数值包含ASR增量识别、LLM生成首token和TTS合成首包三个环节。业内语音助手的体感分界线一般在1.5秒以内，超过两秒用户就会明显觉得“它在卡”。

再测打断：当AI正在输出一段长回复时，我中途说“停一下”，从开口到播放器暂停出声，大概在300到400毫秒。这个值主要由本地VAD触发速度和播放器缓冲区的刷新频率决定。如果觉得打断偏慢，可以把前端播放器的音频刷新周期调短一点，但要小心这会给解码带来额外压力。

视频流的延迟测试相对宽松，画面端到端大概在500毫秒以内，主要是编码和解码耗时。如果视频不参与核心交互，这个数值完全够用。但如果后续要做视觉理解，这500毫秒可能需要进一步优化，方向是降低编码档次、减少视频帧率或者走硬件编码。

5. 常见问题与排查技巧实录

5.1 回声和啸叫：让AI“听”到自己说话

很多人第一次跑通全双工对话后，遇到的第一个问题不是延迟，而是AI突然变成了复读机——它刚说完一句话，马上又说了一遍“嗯，我在听”，然后陷入自言自语。

排查方向很清晰：先确认AEC是否生效。可以把扬声器的音量从小到大调，观察误触发概率是否随之上升。如果成正比，基本就是回声消除没生效或者参数不对。另一个办法是看服务端的VAD日志，当AI说话时，上行音频里是否检测到了持续的语音活动，如果检测到了，回声嫌疑就跑不掉了。

解决路径一般是这几条：优先开启设备硬件的回声消除能力；其次检查AEC算法的参考信号是否正确接入；最后做系统级的音量平衡测试，把麦克风增益和扬声器音量控制在一个合理区间内。

5.2 打断灵敏度太高或太低

打断不灵敏的典型现象是用户对AI说“等一下”，AI完全没反应，继续说自己的。误打断则是AI突然觉得用户说话了，但用户其实只是在收拾东西碰了一下桌面。

这两类问题都出在VAD参数上。灵敏度太低，用户声音被当成背景噪声；灵敏度太高，背景噪声被当成用户声音。没有一个参数能适配所有环境，所以平台提供动态调整机制是合理的。我的习惯是先采集一段纯环境噪声用于评估本底噪声水平，再把VAD阈值设在本底噪声之上的一个合理余量。

如果用户在高噪声环境下使用，建议开启降噪模块。不少开源降噪算法对稳态噪声（空调声、风扇声）压低效果还可以，但处理瞬态噪声（关门声、键盘声）能力一般。这类场景下更稳妥的做法是让用户靠近麦克风说话，或者换用带指向性的麦克风设备。

5.3 音频流突然中断或不出声

不出声的问题，我前面提到的浏览器自动播放策略是主要原因。页面没有用户交互手势就调用play，浏览器直接把播放请求拦截掉，前端代码不报错，服务端也看不到异常，看起来一切都正常但没有声音。

解决办法是在启动会话前增加一个按钮交互，或是在拿到音频轨道后检测play返回值，必要时提示用户执行一次点击事件来解锁音频播放。

还有一种情况是SDP协商成功但音频轨道始终没有进入对端。这类问题通常是传输层的ICE协商没有完成，最终走了relay模式但TURN服务没配好。检查信令日志里的ICE candidate列表，看最终选用的candidate类型是host、srflx还是relay，如果全是host还能通信说明双方能直连，如果强制relay但TURN不可达，就会黑洞。

5.4 端到端延迟偏大

延迟偏大首先得拆阶段看。在浏览器开发者工具里分别查看ASR结果的返回时间、LLM首token时间和TTS首个音频帧时间，三个数值一对比就能定位瓶颈。

只说一个我踩得比较多的点：很多团队会把LLM的流式输出直接透传给TTS，但LLM的token生成速度并不是稳定的，首token快，中间可能停顿。这时候TTS会一直在等完整的句子块才合成，结果首包延迟被平均掉了。合理的做法是在LLM和TTS之间加一个智能文本分句缓冲，模型输出内容在达到一个语义完整片段后立即交给TTS合成，而不是死等全部的token。

网络层面如果跨地域调用，建议把ASR、LLM、TTS这些重模块部署在靠近用户区域的机房，或者用云厂商的边缘加速能力降低公网延迟。这几个办法叠加下来，端到端时间能收到一个相当可观的水平。

6. 一点个人体会与后续空间

6.1 我的几个经验判断

全双工音视频对话看起来是个模型能力问题，真正做下来会发现是个系统工程问题。模型能力固然是瓶颈之一，但更大量、更琐碎的工程问题集中在流式管线设计、可打断状态机、回声消除和用户体验调优上。团队如果打算做类似的东西，建议先把RTC链路和媒体管线的基础打牢，再往上加模型能力，顺序反了大概率会返工。

接入过程中我反复提醒自己的一点是，全双工对话不等于真人对话，它只是一个音视频通道上跑着的“实时人机会话”。别在宣传上把它拔得过高，实际调试时反而要留出余量。比如在嘈杂环境下、网络波动场景下、不同设备能力下，系统表现差异其实很大，这些边界情况比理想环境更重要。

6.2 后续可以继续深挖的方向

这次更新最让我觉得有想象空间的，是视频流的接入。当前版本里视频主要承担的是实时画面的传输与显示，但既然全双工媒体管线已经铺好，后续在上面做视觉语义理解只是插一个模型的问题。比如通过摄像头画面判断用户是否在点头、摇头、皱眉或者举手，这些信号都可以和语音打断一起参与对话状态管理。

另一个方向是可打断对话与多语言能力的结合。用户用中文打断，AI用粤语、英文或其他语种重新组织回复，这种跨语言的全双工交互，在跨国客服、在线教育、旅居场景里会有很实际的需求。平台目前的架构是模型无关的，换不同语种的ASR和LLM模型就能扩展出去。

最后再给一份实用建议，如果你准备在自己的项目里接入这套能力，第一件事不是看接口文档，而是先把全双工对话的端到端流程在demo里跑通，哪怕只跑一个音色、一种网络环境。跑通之后再逐个参数调，逐个模块优化。先把链路走通，把VAD、打断、回声这些基础体验调好，再贪功能。这套逻辑同样适用所有做语音交互的开源项目——底层体验不达标，功能堆得越多，用户流失越快。