从 WebSocket 到 RTC：我们怎么用火山引擎给 AI 穿搭顾问装上"眼睛"

一个二手奢侈品电商的"数字试衣镜"落地记录。涉及火山引擎 RTC、豆包多模态大模型、实时视频流与 AI Vision 的集成实战。

---

为什么要做视频对话

我们的产品 Airtist 是一个二手奢侈品平台，里面有个 AI 穿搭顾问叫 Airy。最早 Airy 只能语音聊天——用户描述自己穿了什么，Airy 靠想象力给建议。你能想象这有多别扭。

"我穿了一件……嗯……米色的……有点像风衣但不是风衣的东西。"

这种对话效率极低。我们需要让 Airy 直接看到用户的穿搭，像照镜子一样给出实时反馈。所以有了"数字试衣镜"这个方向：用户打开前置摄像头，Airy 通过视觉理解分析画面，语音告诉你"这条围巾和外套的色调有点打架"。

听起来简单，做起来踩了不少坑。

---

架构演进：WebSocket 方案的痛

先说说我们之前的语音方案长什么样：

前端 AudioWorklet 录音 → PCM 编码 → WebSocket → 后端代理 → 豆包 WebSocket API
                                                              ↓
前端 AudioContext 播放 ← Base64 解码 ← WebSocket ← 后端转发 ← 豆包返回音频

后端充当了一个音频代理，所有 PCM 数据都要经过它中转。这个方案能跑，但问题一堆：

• 延迟大约 500ms，语音对话有明显的"等一下"感
• 前端要自己处理 PCM 编解码、字节对齐、Base64 转换
• 移动端兼容性是噩梦——我们前后修了 9 轮，AudioWorklet 在 iOS Safari 上的表现让人怀疑人生
• 最致命的：这个架构根本没法加视频

所以当产品说"我们要加摄像头"的时候，我们没有在 WebSocket 方案上硬塞，而是直接切到了火山引擎 RTC。

两个方案的核心差异：

维度	WebSocket 语音方案	RTC 视频方案
通信协议	WebSocket（自建代理）	火山引擎 RTC SDK
音频处理	前端手动 PCM 编解码	SDK 内置，不用管
视频能力	没有	原生支持
后端角色	音频代理（重）	Token + AI 启停（轻）
端到端延迟	~500ms	~200ms
移动端兼容	9 轮修复	SDK 已处理

200ms 的延迟差距在语音对话里感知很明显。500ms 你会觉得 AI 在"想"，200ms 你会觉得它在"听"。

---

整体架构

切到 RTC 之后，架构变得清爽很多。后端从"音频搬运工"变成了"门卫"——只管发 Token 和通知云端启停 AI。

sequenceDiagram
    participant U as 用户（H5）
    participant F as 前端 RTC SDK
    participant B as 后端 Spring Boot
    participant V as 火山引擎 RTC 云端
    participant AI as AI Agent（豆包）

    U->>F: 点击视频模式
    F->>F: 请求摄像头/麦克风权限
    F->>B: POST /rtc/token
    B-->>F: { appId, token, roomId, userId }
    F->>V: joinRoom(token)
    F->>F: 开启本地音视频采集 & 发布流
    F->>B: POST /rtc/start-ai
    B->>V: StartVoiceChat OpenAPI（HMAC-SHA256 签名）
    V->>AI: 创建 AI Agent，加入房间
    AI-->>F: AI 加入房间，订阅用户音视频流
    
    loop 实时对话
        U->>F: 说话 / 展示穿搭
        F->>V: 音视频流
        V->>AI: 转发流
        AI->>AI: ASR → LLM（含 Vision 分析）→ TTS
        AI->>V: 语音回复流
        V->>F: 转发给用户
        F->>U: 播放 AI 语音
    end

    U->>F: 点击挂断
    F->>V: leaveRoom + destroyEngine
    F->>B: POST /rtc/stop-ai
    B->>V: StopVoiceChat