前阵子整理 Voice Agent 学习笔记，重新把 Justin Uberti 那场关于实时语音架构的分享翻出来过了一遍。这老兄的经历挺有意思，WebRTC 是他牵头搞出来的，后来的职业路线走到了 OpenAI，负责 Realtime AI 方向。从浏览器里的点对点音视频通信，到今天大模型驱动的实时语音对话，这两个事情放在同一个人身上，本身就很有故事性。

市面上聊大模型语音的文章不少，但大多停在“怎么调 API”的层面，很少讲清楚背后的架构逻辑到底是怎么演变过来的。这篇笔记我想换个角度，不纠结某个具体函数的用法，而是从 Justin Uberti 的技术路线切入，把 WebRTC 和 OpenAI Realtime API 放在一起做一次架构层面的比较分析，顺便把我自己在接入实时语音时踩过的坑、总结的判断标准也写进去。不管你是正在选型、准备自研语音管道，还是单纯想搞清楚“实时 AI 语音”和“传统通话”在系统设计上的本质差异，这篇内容应该都能给你一些参考。

1. 从 WebRTC 到 Realtime AI：一条贯穿“实时”的技术路线

1.1 WebRTC 的十年遗产：Web 实时通信的地基

WebRTC 2008 年启动，2011 年开源，后来成为 W3C 和 IETF 的标准。它的核心目标是让浏览器之间能直接进行实时音视频通信，不需要装插件，不需要额外客户端。这个目标听起来简单，但要同时解决音视频采集、编码、网络传输、NAT 穿越、回声消除、抖动缓冲这一整串问题，工程量非常大。

WebRTC 最核心的几个组成模块包括：getUserMedia（音视频采集）、RTCPeerConnection（点对点连接管理）、RTP/RTCP（实时传输协议）、SDP（会话描述协议）、ICE/STUN/TURN（网络穿透）。这套体系把实时通信里最难的部分做成了浏览器原生能力，开发者只需要用几个 JavaScript API 就能打通一条端到端的音视频通道。

用生活中的类比来理解，WebRTC 就像在互联网上修了一条“专用电话线”。普通 HTTP 请求是你去邮局寄一封信，寄出去等着回信，一来一回有明确的时间间隔。而 WebRTC 修好的是持续保持连接的双向通话管道，说话的同时就能听到对方的声音，不需要等完整的数据包到达。

在这里我对 WebRTC 最看重的，其实是它在“弱网对抗”上积累的那套机制。实时通信和文件传输最大的区别在于对延迟的敏感性，文件下载慢一点没关系，但通话过程中卡顿半秒，人就能明显感觉到。WebRTC 设计了丢包重传、前向纠错、带宽估计、码率自适应这些策略，让音视频在不太理想的网络环境下也能维持可用。这套思路后来在做 AI 实时语音时，几乎原封不动地被继承了下来。

1.2 从“人对人”到“人对机器”：通信范式发生质变

WebRTC 生来是为“人对人”设计的。两个人在通话时，双方是对称的：你可以说话，我也可以随时插话，语音活动检测（VAD）负责判断当前谁在说话，媒体流在两端之间双向流动。

但到了 Voice Agent 场景，端到端的对象变成了“人与 AI 系统”。这个变化看起来只是把一端从“人”换成“机器”，实际上整个通信范式的假设都被推翻了。

人对人通话时，双方都有完整的听觉和语义理解能力，网络层只需要透明地传输音频数据，不需要理解内容。而人对 AI 对话时，系统不仅要传输音频，还需要实时理解语义、判断说话意图、决定何时回应、控制打断逻辑。原本在 WebRTC 中由“人脑”完成的工作，现在全部转移到了系统侧。

这就是为什么 Justin Uberti 后来在 OpenAI 做的 Realtime 架构，不能简单地“把 WebRTC 拿来用”。WebRTC 提供的是媒体传输能力，但 AI 语音需要的不仅是“传输”，而是“传输 + 理解 + 生成 + 交互控制”的一体化设计。传统的 ASR（语音识别）+ LLM（大语言模型）+ TTS（语音合成）级联架构，有三个明显的问题：

第一是累积延迟。语音先要做端点检测，等待用户说完，然后送去 ASR 识别成文本，再交给 LLM 生成回复文本，最后让 TTS 把文本转成语音。每个环节都是串行的，每一步都要等待上一部完全结束，整体响应延迟往往在 1.5 秒以上，有时候甚至到 2-3 秒。真人对话中，超过 500 毫秒的停顿已经能感觉到“不太自然”了。

第二是信息丢失。语音转文本过程中，语气、停顿、情绪、语速这些信息全被丢掉了。一个基于文本的 LLM 只能看到“用户说了什么”，看不到“用户怎么说”。用户焦虑、犹豫、不耐烦这些细微的信号，都藏在语音的非文本特征里，但这些信息在传统级联架构中根本无法传递。

第三是打断处理困难。级联架构里，如果用户想打断 AI 的回答，必须等到当前 TTS 输出结束后才能处理新指令，或者需要额外开发一套复杂的打断检测机制。怎么做都会显得笨拙，交互体验和真人对话相去甚远。

Justin Uberti 在访谈中反复强调的“架构重构”，核心就是针对这几个问题做重新设计。不是做技术表演，而是用端到端模型和事件驱动的会话协议，把“理解”和“生成”提前到流式传输层面。

2. OpenAI Realtime API 的架构重构思路

2.1 传输层选型：为什么是 WebSocket 而不是 WebRTC

OpenAI Realtime API 没有沿用 WebRTC，而是选择了基于 WebSocket 的全双工通信。很多从 WebRTC 背景转过来的开发者一开始不理解，毕竟 WebRTC 才是“实时通信的正统”。但如果把 AI 语音场景的特点摆出来，就会发现这个选择非常合理。

WebRTC 是为点对点设计的，两端之间需要经历完整的信令协商流程：交换 SDP 描述、ICE 候选、建立 DTLS 加密通道。这在浏览器对浏览器的场景下没问题，因为两端都具备完整的 WebRTC 能力。但在 AI 语音场景里，一端是浏览器或移动 App，另一端是云端 AI 服务，这种“终端到服务器”的连接模式，用 WebRTC 反而过于复杂了。

WebSocket 则提供了一个更直接的方式：客户端连上一个 URL，服务端和客户端之间直接以消息为单位互相发送数据。没有复杂的协商过程，连接建立简单，调试容易，配套工具链也更丰富。对于 AI 服务来说，WebSocket 的“消息 + 事件”模型和后台处理的逻辑天然匹配——收到一条音频消息，模型处理，回一条音频消息，整个过程是天然的异步事件流。

另一个关键原因在于，OpenAI 的音频处理模型运行在数据中心里，服务器之间和服务器内部的网络质量远好于普通用户的公网环境。WebRTC 那些复杂的弱网对抗机制，在“用户到数据中心”这段链路上还需要，但在“数据中心内部”完全是多余的。用 WebSocket 把复杂留在本地，把简单暴露给开发者，反而更符合 AI 语音 API 的定位。

2.2 会话层的设计：事件驱动 + 函数调用

Realtime API 在设计上的核心，是“一切皆是事件”。连接建立后，客户端和服务端之间流动的是定义好的事件序列。

我这里整理了一些开发中最常用到的事件，做了一张简表，方便对照理解：

事件类型	方向	含义
session.created	服务端→客户端	会话创建成功，携带会话配置
session.updated	双向	会话配置更新（如修改指令、VAD 阈值）
input_audio_buffer.speech_started	服务端→客户端	检测到用户开始说话
input_audio_buffer.speech_stopped	服务端→客户端	检测到用户停止说话
conversation.item.created	服务端→客户端	对话中的某条记录被创建
response.create	客户端→服务端	客户端请求模型生成回复
response.audio.delta	服务端→客户端	模型生成的音频增量片段
response.done	服务端→客户端	本轮回复生成完毕
function_call	服务端→客户端	模型请求调用某个外部函数

这种事件驱动的设计，把传统上是“黑盒”的语音交互过程，拆解成了可观测、可控制、可干预的步骤。实时语音调试最怕的就是不知道当前系统在做什么，事件模型让一切都有迹可循。

function calling 的引入是我认为最有价值的设计之一。早期语音助手最大的痛点是“只会聊天、不能办事”，而借助函数调用，模型可以在对话过程中直接请求执行技能：查天气、下单、控制智能家居。而且这些函数调用的结果还能以事件的形式回传给模型，再通过 TTS 播报给用户，形成完整的“听→理解→行动→反馈”闭环。

这里有一点需要提醒：Realtime API 的函数调用是“单向请求”，模型发出 function_call 事件后，需要应用层去实际执行并把结果通过 conversation.item.create 回填回去。这个“外部执行”的环节一定是应用开发者自己控制的，OpenAI 不会替你去操作你的数据库或者业务系统。所以设计函数调用的边界很重要，尽量把单个函数的职责设计得单一、明确，不然模型很容易在复杂指令下“蒙圈”。

2.3 VAD 的语义化：从“声音检测”到“语义检测”

传统 WebRTC 或者说传统语音交互里的 VAD，核心是“能量检测”。实现思路是判断一段音频信号的能量是否超过阈值、持续时间是否够长，如果够长就认为是“有人说话”。这种算法在安静的室内环境表现还行，但遇到噪音环境、语速犹豫、轻声说话时，误判率会明显上升。

OpenAI Realtime API 对 VAD 做了语义化改造。系统不仅在判断“有没有声音”，还在判断“是不是有意义的语音输入”。在内部的架构重构中，VAD 模块会结合模型对语义片段的预测，区分出“背景噪音”“语气词”“有效说话内容”和“说话停顿”，并据此更准确地标记出一次有效语音输入的起止点。

这带来的最直观体验改善是“打断识别”。过去 AI 语音交互最尴尬的场景就是：AI 正在回答，用户突然想补充一句话，结果系统听不到或者反应不过来。语义化 VAD 配合事件驱动架构，让系统能在用户开口的第一时间就感知到“用户有新输入”，暂停当前回复，进入聆听状态。整个“抢话—被识别—被打断—重新响应”的循环，流畅度已经接近真人对话。

不过语义化 VAD 也带来一个实际开发中需要注意的点：因为判断的是“语义”，系统的行为会带有一定概率性，偶尔会出现在用户只是咳嗽、叹气时被误判为说话开始的情况。这就需要在应用层做好事件序列处理：收到 speech_started 事件后，并不一定非要打断当前 TTS，可以加一段很短的“观察窗口”，确认用户确实在说话后再真正执行打断，能有效降低误触概率。

3. 架构重构里的关键工程决策解析

3.1 延迟账本：一次指令要过多少关

实时语音体验的好坏，最终都要落到“延迟”上。我们把一次完整的交互拆开，算一笔延迟账：

• 声学采集：设备拾音，约 20-40ms
• 音频编码与上行传输：约 50-100ms
• 服务端接收与 VAD 判断：约 20-50ms
• 模型推理（理解 + 生成）：这是大头，约 200-500ms
• 音频下行与播放：约 50-100ms

简单加总，传统级联架构一次的端到端延迟轻松超过 1 秒，而 Realtime API 通过端到端流式处理，通常能做到 500ms 左右，好的网络条件下甚至能压到 300-400ms。有人可能会问：差这几百毫秒真的有那么重要吗？

我在实际做 Voice Agent 的时候，做过一个不太严谨但很有感受的对比测试：同一套话术，延迟在 800ms 时用户就觉得“这个 AI 反应有点慢”，降到 350ms 时用户反馈“感觉像在和一个真人说话”。人对延迟的敏感程度远超我们通常的想象，尤其是在“对话节奏”这种需要毫秒级同步的体验上。

要控制延迟，有几个工程决策值得留意。第一，音频格式选择要合理。Opus 编码在低码率下音质保持好，编码延迟也低；PCM16 则完全没有编解码开销，适合服务端已有算力的情况。第二，尽量开启流式输出，不要等完整回复生成完再播放，要边生成边播。第三，上传音频时尽量把单帧切小（比如 20ms 一帧），降低服务端等待“一段完整语音”的缓冲时间。第四也是最重要的：网络路径要短。国内接海外节点延迟天然高，反向代理选错区域也可能白白多出几十上百毫秒，需要自己把握好服务部署的地域策略。

3.2 打断检测与半双工/全双工切换机制

传统语音机器人有一个隐藏的“半双工”问题。半双工就是同一时间只能一个人说话，一个人说的时候另一个人只能等着。早期的 IVR（交互式语音应答）系统就是这样，用户说完要等 3 秒确认静音，然后才进入识别。这种方式的好处是逻辑简单，坏处是对话节奏非常机械。

现代 Voice Agent 追求的是“全双工”体验，本质上就是“随时可以插话”的自由度。实现全双工体验的关键不仅在于底层的全双工传输通道，更在于上层的“轮流说话”控制逻辑。

Justin Uberti 在 OpenAI Realtime 架构里用了一个“turn-taking”的概念：系统通过 VAD 事件和模型自身语义判断，动态决定当前应该由谁说话。当用户开始说话时，模型即使正在生成音频，也会被“新输入”打断；当用户停顿超过阈值，模型会判断是否应该恢复回应。这个“发言权切换”不是简单的定时器，而是综合语义、角色、上下文做出的动态决策。

我在实现打断逻辑的时候踩过一个坑：开始以为只要检测到用户音量超过阈值就打断，结果环境里有点噪音，AI 每隔几秒就被“吓”得停下来。后来改成两层判断——先等 speech_started 事件触发，再叠加一段约 250ms 的观察期，确认用户确实在连续说话才执行打断。加了这层“防抖”之后，误触率大大降低，交互稳定性也上来了。

3.3 多模态融合：音频、文本与函数调用的协同

Realtime API 一个很有意思的设计是“多模态输入输出”。它不是单纯的“音频进、音频出”，而是同时支持音频、文本、函数调用这些不同模态的事件在一个会话里自由组合。

举个例子。用户说“帮我查一下北京明天天气，然后告诉我适合穿什么”。系统内部的执行链路是这样的：音频进入模型，模型理解语义后触发一个查询天气的函数调用，函数执行返回结构化数据，模型把数据组织成一段语音回复，同时把文字内容作为字幕同步输出到客户端。整个过程跨了音频、文本、函数三个模态，但都在同一个事件流里闭环完成。

这种设计对应用开发者的启发是：不要只把 Realtime API 当成一个“语音识别 + 文字生成 + 语音合成”的工具箱，而要把它当成一个“实时多模态会话中枢”。音频是主要通道，文本可以用来做日志、调试、字幕、搜索索引，函数调用用来对接业务系统。

我在自己的项目里，就经常把对话过程中的文本事件和函数调用事件落库，一方面用于事后分析对话质量，另一方面可以作为检索增强的语料来源。这些“副产物数据”的价值，很多时候比单纯的语音识别准确率更有意义，因为它们包含了完整的人机交互语义链。

4. 给 Voice Agent 开发者的架构选型建议

4.1 什么时候用 Realtime API，什么时候用传统级联

OpenAI Realtime API 确实把实时语音的体验拉到了新的高度，但并不意味着所有场景都应该无脑选它。我需要先把两种方案的适用边界讲清楚。

先看一个对比表格，从几个关键维度做比较：

维度	传统级联（ASR + LLM + TTS）	Realtime API（端到端实时）
端到端延迟	1.5s 以上，受环节数量影响	300-800ms，取决于网络和模型负载
打断体验	弱，需要额外开发，延迟高	强，VAD 事件 + 语义判断原生支持
成本	按 API 调用次数计费，可控	按音频时长计费，实时流式剔除了“按轮计费”概念，成本更高
定制能力	各环节可单独替换，灵活度高	端到端模型，定制空间有限
音色控制	TTS 可自由切换，支持声音克隆	支持声音配置，但切换方案不如独立 TTS 引擎灵活
上下文管理	应用层完全控制，可自由注入	事件驱动，需要按事件协议管理上下文

基于这个对比，我的选型建议是这样的：

如果你的场景主要是“简单的指令式问答”，比如“设置一个 5 分钟后的闹钟”“播放某首歌”，传统的级联架构完全够用。因为这类交互对延迟不敏感，用户能接受等个 1 秒多，而且指令清晰，ASR 识别率有保障。

如果场景是“开放式自由对话”，比如“陪用户聊会儿天”“心理咨询”“语音教练”，那 Realtime API 的优势就非常明显。这种场景下，用户在意的不是“命令执行得准不准”，而是“对话是否自然”“能不能随时插话”“AI 接话是否及时”。这些恰恰是级联架构最难补齐的短板。

还有一种混合架构也值得考虑：主对话走 Realtime API 保持自然体验，但把函数调用里“确定性强的部分”剥离出来，用规则或专用模型兜底。比如用户说“帮我订一杯咖啡”，对话层只负责把需求解析清楚，真正下单的动作通过传统的后端服务去执行，执行结果再回填到对话里。这种方式既保证了对话体验，又保留了业务系统的可控性。

4.2 客户端集成中的几个常见“坑位”

我把自己在实际开发中遇到的坑整理成了一份清单，基本每个新接入的开发者都会踩到其中几个。

麦克风权限和音频焦点是个典型的“看起来简单，实际很麻烦”的问题。在浏览器端，getUserMedia 必须在用户手势（如点击按钮）之后才能调用，不然会被浏览器安全策略拒绝。在移动端，App 需要在后台也能继续发送音频，这就涉及音频焦点管理和后台运行权限，处理不好会出现“App 切到后台，麦克风直接静音”的问题。

回声消除是我认为最容易被低估的一个环节。有些开发者在电脑上测试没问题，一到真机（尤其是手机免提模式）就发现 AI 一直在重复识别自己说的话，或者出现“刺耳的啸叫”。解决思路是使用系统级的回声消除能力：浏览器端可以开启 echoCancellation 参数，移动端则要选择支持 AEC 的音频采集模块。注意：一旦开启了回声消除，就不要在应用层再叠加一套降噪逻辑，两套算法互相干扰反而会产生更奇怪的声音。

断线重连和会话恢复是一个稳定性的问题。实时语音通道毕竟是长连接，网络切换（比如 Wi-Fi 切到 4G）很容易导致连接中断。Realtime API 提供 session 概念，但客户端需要自己实现“检测到断线→保存当前会话状态→重连→恢复上下文”的闭环逻辑。这里有一个细节值得注意：断线期间用户说的内容会丢失，重连成功后要不要主动提示用户补话，还是悄悄等待下一轮输入，这个交互策略需要按场景权衡。

音频参数的选择也有讲究。WebRTC 生态通常默认 Opus，Realtime API 也原生支持 Opus。Opus 在 16-24kbps 的低码率下就能保持不错的音质，适合带宽受限的场景。如果业务对延迟有更高要求，可以选择 PCM16 16kHz 单声道，省去编解码时间，但带宽占用会明显上升。一个小建议：不要盲目追求高采样率。语音对话的频带通常在 20Hz-8kHz，16kHz 采样率已经完全够用，用 44.1kHz 不仅浪费带宽，还会增加服务端的处理开销。

4.3 事件序列处理的三条铁律

开发基于 Realtime API 的应用，本质上是在写一个事件状态机。这里有三条我在实践中总结出来的铁律，每条背后都有血泪教训。

第一条：不要把事件处理写成简单的 if-else 瀑布流。Realtime 的事件是异步乱序到达的（虽然理论上服务端的消息序列是有序的，但经过代理、中间件之后，客户端接收到的实际顺序需要自己保证），而且同一时刻可能有多条事件并发到达。规范的做法是维护一个独立的事件队列，按事件类型分发到各自的状态处理函数。

第二条：对每个事件都要有“重复送达是常态”的容错意识。网络重传或客户端重连后，之前的事件可能被重复推送。如果这些事件里还包含业务副作用（比如触发了一次扣费函数调用），重复执行就是事故。解决方案是在应用层为每个事件维护一个去重 ID，处理过的直接跳过。

第三条：不要依赖事件通知去维护会话状态，会话状态要以服务端下发为准。客户端本地缓存的会话状态可能过期，正确做法是把服务端下发的 session 状态作为“唯一真源”，本地只做展示和缓存。客户端要改配置的时候，通过 session.update 事件请求修改，等服务端回包确认后再更新本地视图。

5. 常见故障排查与优化速查表

聊了这么多架构层面的东西，最后把一些高频故障的排查思路和优化手法整理成速查表，方便大家在实际项目中快速定位问题。

现象	可能原因	排查思路与解决方案
首包延迟高，用户说完要等很久才有反馈	VAD 尾音静音阈值设置偏长；上传音频缓冲太大	调小 speech_stopped 延迟阈值；单帧音频降低到 20ms 一帧；“热启动”保持连接预先加载模型上下文
音频断断续续，偶尔丢字	网络丢包率高；客户端抖动缓冲太小	在客户端做一定深度的抖动缓冲；考虑加冗余编码；监测丢包率做码率自适应
AI 总是“抢话”或“把用户当背景音”	VAD 敏感度设置过低；背景噪音干扰	调整 VAD 阈值到适中档位；开启客户端降噪；在事件判断上增加“观察窗口”防误触
打断不生效	打断逻辑只依赖音量；服务端对打断有静默期限制	改用语义化 VAD 事件驱动打断；减少“打断冷却时间”参数；确认音频上行是否持续
函数调用不执行 / 结果不反馈	函数命名对模型不够直观；缺少 function_call 事件处理	把函数名写得语义化，参数设计简单明确；确认代码里处理了 function_call 并正确回填结果
出现回音 / 啸叫	回声消除未开启或参数错误	打开 echoCancellation；检查是否有两层降噪叠加；避免在头部又做一次 AEC
WebSocket 连接频繁断开	服务端空闲超时；代理层断连	实现心跳 ping-pong；断开后按 session 恢复重连；检查代理超时设置

这些问题的排查思路，很多都是通用的网络优化手段。我的经验是：遇到故障先别急着改代码，先把客户端日志和服务端事件日志拉出来对照着看一遍，通常能定位到 80% 的问题。实时语音系统的调试，日志的完整性和可追踪性比什么都重要。

关于弱网优化，我多说两句。移动端最大的敌人是“网络切换”和“信号弱区”。网络切换时 WebSocket 连接大概率会断开，重连逻辑必须做进客户端基础能力里，不能指望用户去点刷新。信号弱区的核心矛盾是丢包，这时候有两个思路：一个是在客户端做前向纠错，用冗余数据包换取容错率；另一个是降码率，在音质可接受范围内把 Opus 目标码率从 32kbps 降到 16kbps，能显著提升弱网下的流畅度。具体用哪个策略，建议根据应用场景动态调整：有线/ Wi-Fi 下走高音质低冗余，弱网下走低码率高冗余。

还有一个很多人容易忽略的点：沉默压缩。通话过程中有大量“静音”时段，传统 VoIP 会在静音时不发送数据包以省带宽。做 AI 语音时，可以让客户端在 VAD 判定为“无人说话”时暂停音频上行，只发控制消息。这样能有效降低服务端的音频处理压力，也能减少按音频时长计费场景下的成本。

6. Voice Agent 的工程化延展与个人体会

把这套架构重读一遍，我最大的感受是：所谓“架构重构”，不是推翻重来，而是把符合新场景的能力重新组合。WebRTC 留给行业最宝贵的遗产，不是它的 API 怎么调用，而是那套围绕“实时”构建的系统化思维——网络不好怎么办、用户抢话怎么办、音频怎么保活、状态怎么同步。这些工程问题在 WebRTC 时代就存在，到了 Realtime AI 时代只是换了一套外衣。

Justin Uberti 的职业经历恰好串起了这条线。他当年做 WebRTC，本质上是想在不可控的公共互联网上构建可控的实时通信通道；现在在 OpenAI 做 Realtime AI，又是在为智能体构建一条从人类感知到模型理解的实时通道。两件事的技术方案不同，要解决的问题却一脉相承：如何在毫秒级的约束下，让“信息”以最接近人类习惯的方式流动起来。

对于正在做 Voice Agent 的开发者，我最后分享几个判断标准，都是我踩过几次坑之后总结出来的：

第一，能用“事件状态机”想清楚的问题，就不要用“回调函数”糊弄过去。语音交互天然是流式、多事件、可能乱序的，只有把状态转移理清了，系统才具备进化能力。

第二，延迟优化不是“加到高配服务器”就万事大吉。性能瓶颈往往出现在音频采集、网络传输、事件处理这些“非模型”环节。先做端到端延迟测量，定位热点，再做针对优化，顺序不能反。

第三，把函数调用当作 Voice Agent 的“肌肉”。只聊天不会干活的语音助手没有持久价值，尽早把业务能力封装成模型可调用的函数接口，让 AI 真正成为“能动手的助手”。

第四，保持对成本的敏感。Realtime 类 API 按音频时长计费，全双工、长时间在线都会显著推高成本。在业务设计上，要能精准控制“AI 在听”的时间窗口，该关闭下行时果断关闭，该降级到文本时也果断降级，成本控制才能落到日常运营中。

这套实时语音架构演进方向的梳理，算是手头 Voice Agent 笔记中比较关键的一块。后续我打算基于这套理解，把“VAD + 打断 + 函数调用 + 上下文管理”这几个模块逐步组件化，沉淀成一套可复用的音视频智能体骨架工具，到时候再来分享更具体的工程实现细节。