本文范围：只讲清 App 内实时语音聊天的产品链路，以及 0 到 1 做出第一个可用版本的路径。

先说结论

我在豆包 App 里点下电话按钮后，手机不是录完一段语音再发给 AI，而是一直保持连接：

• 我说话时，声音边录边传。
• 系统判断我说完后，回答边生成边播放。
• 我中途插话，旧回答马上停止，新要求接着当前话题继续。

所以，实时语音聊天不是文字聊天外面套一个麦克风。它是一条持续运行、能判断轮次、允许打断、记得上下文的音频会话。

这里的“打电话”只是 App 内像电话一样聊天，不是拨手机号，也不一定经过运营商电话网。

语音输入法怎样把声音变成文字，单独见 豆包和微信语音输入法怎样把我说的话变成可编辑文字？。

就跟着一次做饭往下拆

我进厨房前打开豆包电话模式，把手机立在灶台旁。开始做番茄炒蛋后，双手又湿又油，我直接问豆包：

番茄炒蛋是先炒鸡蛋，还是先炒番茄？

豆包说到放糖时，我马上插话：

等一下，我不想放糖，怎么做？

最后我又说：

帮我设一个 3 分钟的计时器。

这时产品要同时做到：听清厨房噪声里的问题，不抢话，尽快开口，被插话后马上停，还要真的启动计时器。任何一项失败，这通“电话”都会露馅。

一句话怎样走完一圈

前面的声音不断向后传，前面的回答不断往回播，所以它像通话，而不是互相发送语音留言。

这条链路里有三种责任：

• 音频系统：收音、传输、去回声和播放。
• 模型：理解我说了什么，并生成回答。
• 会话系统：管理轮次、上下文、打断、工具和失败恢复。

一个语音模型 API 不是完整产品。

真正决定体验的四件事

别在我停顿时抢话

我可能会说：

番茄炒蛋是先炒鸡蛋……嗯……还是先炒番茄？

中间的安静只是犹豫，不是说完。系统如果只看静音时间，就会抢答；等得太久，又会让我尴尬地空等。

因此，它要结合有没有人声、停顿多久、句子是否完整和当前对话状态来判断轮次。

VAD（Voice Activity Detection，语音活动检测）：判断现在有没有人在说话，但不能独自判断一句话的意思是否说完。

尽快开口，但别断断续续

等待来自整条链路：收音、网络、轮次判断、模型生成、声音生成和播放缓冲都会花时间。

回答通常会流式返回：第一小段刚生成就先播放，后面的继续生成。缓冲太少，弱网时会卡；缓冲太多，开口又会变慢。

所以，实时是一整条延迟链路，不是一个模型参数。

我插话后，它真的停下来

我说“不想放糖”时，系统不能只关掉扬声器，还要：

• 停止旧声音。
• 取消服务端还没生成完的旧回答。
• 记住我实际听到了哪里。
• 把新要求接回番茄炒蛋的上下文。

否则，它会继续自说自话，或者以为我听过实际没听过的内容。

选级联，还是端到端语音

最容易搭建的级联路线是：

声音 → ASR → 文字 → LLM → 回答文字 → TTS → 回答声音

ASR（Automatic Speech Recognition，自动语音识别）：把人说的话变成文字。

TTS（Text-to-Speech，语音合成）：把回答文字变成声音。

级联路线容易逐段检查和替换，适合第一个版本；代价是等待会叠加，语气和情绪也可能在文字中转时丢失。

截至 2026-07-29，火山引擎公开的豆包端到端实时语音模型使用 Speech-to-Speech 路线，也就是声音直接进、声音直接出。它更容易降低等待并保留语气。

但无论走哪条路线，外面都仍然需要传输、轮次、上下文、打断、工具、权限、日志和评测。端到端模型不等于端到端产品。公开方案也不能证明豆包 App 内每条请求都使用同一个模型或路由。

什么时候它才成了 Agent

我问“番茄炒蛋先炒什么”，系统给出语音回答，这只是实时语音聊天。

我说“帮我设一个 3 分钟计时器”时，如果它只回答“好的”，任务并没有完成。真正的 Agent 行为是：

• 模型判断需要调用计时器。
• 运行层真的创建计时任务。
• 工具返回成功或失败。
• 模型根据真实结果继续告诉我。

Agent 的关键不在语音，而在于它能不能调用真实工具，并根据结果继续完成任务。

如果我从 0 到 1 构建

先证明做饭时用语音提问确实有用，再一层层增加实时、多轮、打断和工具，不需要一开始复刻完整豆包。

第一版直接使用成熟的 ASR、LLM 和 TTS：

• 按住按钮录一句话。
• 服务端识别文字并生成回答。
• 浏览器播放声音，同时展示两边文字。

需求成立后，再升级流式传输、自动判停、多轮上下文、弱网重连和插话打断。最后只接一个计时器工具，因为它在做饭场景里真有用，成功与失败也容易验证。

实现时至少分开客户端、实时连接、轮次与取消、模型适配、会话状态、工具运行和事件日志。技术语言不是核心，事件、状态、取消和时间线才是实时语音产品的核心。

怎样判断第一个版本成立

我会反复测试同一组动作：询问做菜顺序、中途说“不放糖”、继续追问、启动 3 分钟计时器。

重点只看：

• 我说完后多久听到第一段回答。
• 系统抢话、等太久和被厨房噪声误触发的比例。
• 插话后，旧播放和旧生成是否真的停止。
• 下一轮是否保留正确上下文。
• 计时器是否真的创建成功。
• 下一次做饭时，我是否还愿意使用。

最重要的产品指标不是声音多像真人，而是：

它有没有让我在双手不方便时，少碰手机也能把事情办完。

本文目前只是经过当前官方资料校准的产品与工程蓝图，还没有对应的本地运行 Demo。

考考你

实时语音聊天为什么不是给文字聊天加一个麦克风？

因为它还要持续处理音频传输、轮次判断、流式播放、回声、打断和已听上下文。

为什么不能只靠静音判断我说完了？

人会停顿和犹豫，环境还有噪声。系统还要结合句子是否完整和当前对话状态。

级联路线和端到端语音路线有什么区别？

级联路线由 ASR、LLM 和 TTS 接力，容易调试；端到端路线直接接收并生成声音，更容易降低延迟、保留语气。两者都需要模型外的会话系统。

为什么打断后还要修正对话历史？

模型可能生成了很多内容，但我只听到一部分。没听见的后半段不能成为下一轮已经发生的对话。

从 0 到 1 为什么先做按住说话？

按钮能明确开始和结束，最快验证语音问答是否有用。需求成立后，再投入自动判停和自然打断。

它什么时候才出现 Agent 行为？

当系统会调用计时器等真实工具，并根据工具结果继续完成任务，而不是只生成一段语音时。

参考

• 以前的公开文章：通过语音和大模型对话
• 豆包 App：App Store 产品说明，版本 14.4.0，产品说明与版本信息核对于 2026-07-29。
• 火山引擎：端到端实时语音大模型，核对于 2026-07-29。
• 火山引擎：对话式 AI 实时交互发版说明，核对于 2026-07-29。
• 火山引擎视频云技术团队：豆包大模型支持实时语音通话了，核对于 2026-07-29。