语音交互实战：基于 WebRTC 与 AI 接口构建实时语音对话系统

语音交互实战：基于 WebRTC 与 AI 接口构建实时语音对话系统

随着大模型技术的爆发，人机交互的方式正在经历一场从'指令式'到'对话式'的深刻变革。传统的文本交互虽然成熟，但在移动场景、驾驶辅助或无障碍应用中，语音交互才是刚需。然而，很多开发者在尝试构建语音对话系统时，往往会陷入'能听会说但反应迟钝'的尴尬境地。

传统的语音交互流程通常是：录音 → 上传文件 → 后端识别 (STT) → 大模型处理 (LLM) → 语音合成 (TTS) → 返回播放。这种'一问一答'的串行模式，导致用户说完话后需要等待数秒才能听到回复，这种延迟在实时对话场景下是致命的。

本文将探讨如何利用 WebRTC 技术与 AI 接口，构建一个低延迟、全双工的实时语音对话系统，打破交互延迟的壁垒。

核心技术架构：从串行到流式

要解决延迟问题，核心在于将'文件级'处理转变为'流式'处理。我们不再等待用户说完一句话才开始识别，而是边说边识别；不再等大模型生成完整回复才开始合成，而是边生成边合成。

1. WebRTC：实时通信的基石

WebRTC（Web Real-Time Communication）不仅是一个协议，更是一套强大的 API 集合。在浏览器端，它提供了 getUserMedia 用于采集音频，以及 RTCPeerConnection 用于传输。但在与 AI 服务对接的场景中，我们通常利用 WebSocket 建立双向数据通道，配合 WebRTC 的音频采集能力，实现音频流的实时上传。

2. AI 接口的流式响应

现代 AI 接口（如 OpenAI 的 Whisper、GPT-4o、阿里通义千问等）大多支持流式传输。

• STT (语音转文本)： 支持流式识别，实时返回中间结果。
• LLM (大语言模型)： SSE (Server-Sent Events) 流式输出 Token。
• TTS (文本转语音)： 流式合成，生成一段音频片段即刻推送，无需等待全文。

架构流程图解

环节	传统模式	流式优化模式
采集	录音结束后上传	实时采集音频流
识别	全量音频上传后识别	边说边识别
生成	等待完整 Prompt 生成	流式生成 Token
合成	全文生成后合成	流式切片合成
体验	延迟 3-5 秒 +	延迟 < 1 秒

实战代码：构建浏览器端语音流客户端

为了演示，我们将使用 JavaScript（浏览器端）和 Python（模拟后端转发）来构建核心链路。这里我们采用'WebSocket + MediaRecorder'方案，这是一种比标准 WebRTC 更易于与现有 HTTP 服务集成的轻量级实时方案。

1. 前端：音频采集与流式发送

前端的核心任务是捕获麦克风数据，切片发送，并即时播放后端返回的音频流。

// 实时语音交互核心类
class VoiceAgent {
  constructor(wsUrl) {
    this.ws = new WebSocket(wsUrl);
    this.mediaRecorder = null;
    this.audioContext = new (window.AudioContext || window.webkitAudioContext)();
    // 初始化 WebSocket 监听
    this.ws.onmessage = (event) => this.handleServerMessage(event);
  }

  // 开始录音与发送
  async startListening() {
    try {
      // 1. 获取麦克风权限
      const stream = await navigator.mediaDevices.getUserMedia({ audio: true });
      // 2. 创建 MediaRecorder，设置为实时切片（每 100ms 切片一次）
      // 这里的 mimeType 需根据浏览器支持情况调整，Chrome 通常支持 webm/opus
      this.mediaRecorder = new MediaRecorder(stream, { mimeType: 'audio/webm;codecs=opus' });
      this.mediaRecorder.ondataavailable = async (event) => {
        if (event.data.size > 0 && this.ws.readyState === WebSocket.OPEN) {
          // 3. 将音频 Blob 转为 ArrayBuffer 发送给后端
          const buffer = await event.data.arrayBuffer();
          this.ws.send(buffer);
        }
      };
      // 4. 开启切片发送循环，timeslice 参数控制实时性
      this.mediaRecorder.start(100);
      console.log("开始监听...");
    } catch (err) {
      console.error("麦克风获取失败:", err);
    }
  }

  // 处理服务端返回的流式音频
  handleServerMessage(event) {
    // 假设后端直接返回音频流数据
    if (event.data instanceof Blob) {
      this.playAudioChunk(event.data);
    }
    // 处理文本中间态（可选，用于 UI 显示识别文字）
    else if (typeof event.data === 'string') {
      const data = JSON.parse(event.data);
      console.log("AI 正在思考:", data.text);
    }
  }

  // 实时播放音频片段
  async playAudioChunk(audioBlob) {
    const arrayBuffer = await audioBlob.arrayBuffer();
    // 解码音频数据
    const audioBuffer = await this.audioContext.decodeAudioData(arrayBuffer);
    // 创建音频源并播放
    const source = this.audioContext.createBufferSource();
    source.buffer = audioBuffer;
    source.connect(this.audioContext.destination);
    source.start(0);
  }

  stopListening() {
    if (this.mediaRecorder) {
      this.mediaRecorder.stop();
      this.ws.send(JSON.stringify({ type: 'stop' }));
    }
  }
}

代码解析：

• 切片策略： mediaRecorder.start(100) 是关键。它每 100 毫秒触发一次 ondataavailable，模拟了实时流传输，避免了长录音带来的等待延迟。
• 解码播放： 使用 Web Audio API 的 decodeAudioData 可以动态解码音频片段，实现'边下边播'，这是实现低延迟响应的最后一步。

2. 后端：AI 接口的编排与转发

后端扮演'中间人'角色，负责将音频流转发给 STT 服务，将文本流转发给 LLM，再推送给 TTS。以下是一个基于 Python FastAPI 的简化逻辑。

from fastapi import FastAPI, WebSocket
import asyncio
import json

app = FastAPI()

# 模拟 AI 服务调用函数
async def get_stt_text(audio_chunk):
    # 实际开发中调用如 Whisper API (流式版)
    # 这里仅作模拟，返回识别到的文本
    return "你好"

async def get_llm_stream(text):
    # 模拟 LLM 流式返回
    yield "我是"
    await asyncio.sleep(0.1) # 模拟网络延迟
    yield "AI 助手"

async def get_tts_audio(text):
    # 模拟 TTS 合成，返回音频 bytes
    # 实际开发中调用如 Azure TTS 或 OpenAI TTS
    return b"fake_audio_data_binary"

@app.websocket("/ws")
async def websocket_endpoint(websocket: WebSocket):
    await websocket.accept()
    while True:
        try:
            # 接收前端音频数据
            data = await websocket.receive_bytes()
            # 1. 语音识别 (STT)
            user_text = await get_stt_text(data)
            # 2. 大模型推理 (LLM) - 流式处理
            async for text_chunk in get_llm_stream(user_text):
                # 发送文本中间结果给前端展示
                await websocket.send_json({"type": "text", "content": text_chunk})
                # 3. 语音合成 (TTS) - 流式合成
                audio_chunk = await get_tts_audio(text_chunk)
                # 4. 发送音频流回前端
                await websocket.send_bytes(audio_chunk)
        except Exception as e:
            print(f"Error: {e}")
            break

实战注意点：

• VAD (语音活动检测)： 在实际工程中，不能一直发送音频流，否则会产生大量噪音和无效数据。前端或后端需要集成 VAD 算法，检测到用户'正在说话'时才发送数据。
• 全双工通信： 上述代码是同步处理的（说完才处理）。更高级的架构会将'听'和'说'解耦，允许用户随时打断 AI（Barge-in），这需要更复杂的状态机管理。

总结与思考

从传统的'录音 - 上传'模式转向基于 WebRTC 和流式 AI 的实时交互，不仅仅是技术栈的升级，更是用户体验维度的质变。在实际落地中，我总结了几个关键点：

1. 延迟是体验的生命线： 超过 1.5 秒的延迟会让用户感到明显的'对讲机感'。流式处理是唯一的解法。
2. 工程复杂度的权衡： 如果只是做 Demo，直接调用 OpenAI 的 Realtime API 是最快的路径；但如果要商业化落地，自建 WebSocket 网关、集成 VAD、优化 Opus 编码传输，是降低成本和保护数据隐私的必经之路。
3. 开发者转型的思考： Web 开发习惯了无状态的 HTTP 请求，而实时语音交互要求我们习惯'有状态'的长连接编程。处理网络抖动、数据包乱序、音频缓冲区管理，这些偏底层的知识将是 Web 开发者转型 AI 工程化的重要护城河。

语音交互是 AI 应用落地的'最后一公里'，打通这条路，你的应用才能真正'开口说话'。