实时语音 AI 助手教程：从语音识别到客服机器人工作流

适用人群

这篇教程适合客服产品经理、开发者、在线教育团队、播客工具作者和智能硬件团队。如果你的场景只是偶尔语音输入，手机键盘自带语音识别就够了；如果你需要连续对话、低延迟回复和业务系统查询，才需要完整实时语音架构。

核心链路

一个典型链路是：麦克风采集音频，语音活动检测判断用户是否在说话，语音识别把音频转成文字，对话模型理解意图并决定是否调用工具，业务工具返回结果，模型组织回复，语音合成把文本变成声音，播放器播出。用户中途打断时，系统要停止播放并重新进入监听。

每一环都会影响体验。语音识别错一个关键词，后面全错；工具调用慢，用户会以为系统卡住；语音合成没有情绪，客服体验会像机器人朗读。

第一步：选择技术方案

如果你追求最快上线，可以用提供实时语音能力的平台，把识别、对话和合成放在一个连接里。优点是延迟低、集成简单；缺点是成本和可控性受平台影响。如果你要强定制，可以拆开 STT、LLM、TTS 三段，例如 Whisper / Deepgram / Azure Speech 做识别，大模型做对话，ElevenLabs / Azure / 火山 / Fish Audio 做合成。

新手建议先用一体化方案跑通原型，再拆分优化。不要一开始就同时调三家供应商，否则排查延迟会很痛苦。

浏览器端录音骨架

下面是最小的浏览器录音代码。真实项目需要把音频流送到实时语音 API 或自己的 WebSocket 服务。

async function startVoiceSession() {
  const stream = await navigator.mediaDevices.getUserMedia({ audio: true });
  const recorder = new MediaRecorder(stream, { mimeType: "audio/webm" });

  recorder.ondataavailable = async (event) => {
    if (event.data.size === 0) return;
    ws.send(event.data);
    console.log("audio chunk", event.data.size);
  };

  const ws = new WebSocket("wss://your-domain.example/voice");
  recorder.start(250);
  return () => {
    recorder.stop();
    stream.getTracks().forEach((track) => track.stop());
  };
}

后端事件流设计

client: audio_chunk
server: transcript_delta
server: user_turn_finished
server: tool_call_started
server: assistant_text_delta
server: audio_delta
server: assistant_turn_finished

界面验收图要截两张：浏览器授权麦克风界面、实时转写和回复的控制台日志。语音教程没有这些图，读者很难判断延迟和事件流。

第二步：定义客服场景边界

语音助手最适合处理高频、规则清楚的问题：订单状态、退款流程、套餐介绍、预约改期、设备排障。它不适合直接处理高投诉、高赔付或强法律责任的问题。上线前要列出“可自动回答”“必须转人工”“只能记录不能承诺”三类问题。

例如用户问“我的订单到哪了”，助手可以调用订单查询工具回答；用户说“我要投诉并要求赔偿”，助手应该记录诉求并转人工，而不是自行承诺金额。

第三步：处理打断与轮次

语音对话里，用户经常会打断助手。系统必须支持 barge-in：检测到用户重新说话时，停止当前 TTS 播放，清空未播完内容，把新语音送入识别。否则用户会觉得自己在和录音机说话。

轮次管理也很重要。模型需要知道当前对话状态：用户身份是否确认、问题是否已分类、是否已经调用过工具、是否等待用户补充信息。不要把所有历史对话无脑塞进上下文，保留最近关键轮次和结构化状态更稳。

第四步：接入业务工具

客服助手的价值来自工具调用。常见工具包括订单查询、工单创建、知识库搜索、预约修改、短信发送。工具必须有权限控制和审计。用户身份未验证前，不能透露订单详情；涉及修改操作时，要复述关键信息并让用户确认。

建议所有高风险操作采用“两步提交”：第一步生成操作预览，第二步用户确认后执行。这样可以避免识别错误导致误操作。

第五步：优化延迟

语音体验的关键指标是首字延迟和完整响应延迟。可以从四处优化：使用流式识别，边说边转；让模型流式输出，不等整段完成；TTS 支持流式合成，边生成边播；工具调用加缓存和超时。客服场景中，如果工具超过 3 秒没返回，助手应先说“我正在查询，请稍等”，而不是沉默。

质量评估怎么做

上线前不要只在安静办公室里试。至少准备三类测试：安静环境、嘈杂环境、用户打断。每类测试 20 到 30 个真实问题，记录识别错误、答非所问、延迟过长、转人工失败等问题。语音助手的质量指标可以包括：首字延迟、识别准确率、任务完成率、转人工成功率、用户重复提问次数。

客服场景还要做话术评估。AI 不能过度承诺，不能在用户情绪激动时机械复读流程，也不能泄露隐私。建议把敏感话术做成规则：退款、赔偿、投诉、账号安全、未成年人、医疗法律等问题触发更保守的回复和人工转接。

还要单独测试“沉默”。用户停顿、犹豫、说半句话、背景有人插话时，系统不应该立刻打断或给出错误结论。可以设置短暂停顿确认，例如“我听到你想查询订单，是这个意思吗？”这种确认会多花一秒，但能减少很多误操作。

常见坑

| 现象 | 该看哪个指标 | 修法 | |------|--------------|------| | 用户说完后等很久 | 首字延迟 | 开启流式识别、流式生成、流式 TTS | | 用户打断无效 | barge-in 成功率 | 检测到新语音立刻停止当前播放 | | 答非所问 | STT 错词率 | 对产品名、人名、订单号加热词或二次确认 | | 客服承诺过度 | 敏感意图拦截率 | 退款、投诉、赔偿类问题转人工或只生成草稿 | | 人工接手还要重问 | 转人工摘要缺失 | 转接时带上用户问题、已查工具、失败原因 |

转人工摘要可以固定成这个结构：

{
  "userIntent": "查询退款进度",
  "verifiedIdentity": true,
  "toolsCalled": ["getOrderStatus"],
  "lastKnownStatus": "退款审核中",
  "handoffReason": "用户要求人工确认到账时间"
}

替代方案

如果实时要求不高，可以做“语音留言 → 转写 → AI 回复草稿”，由人工确认后回拨或发送短信。如果业务复杂，可以先做坐席辅助，让 AI 在旁边给人工客服提示答案，而不是直接面向用户。坐席辅助风险更低，也更容易获得内部支持。

小结

实时语音 AI 助手不是把聊天机器人加个声音，而是一套低延迟、可打断、可接业务工具的对话系统。先从低风险客服问题做起，明确转人工边界和权限规则，再逐步扩展到销售、培训、硬件助手等场景。