实时交互

实时语音AI：从回合制到流式的跨越 2026年6月，OpenAI正式发布实时语音API（Realtime Voice API），将端到端语音交互延迟从传统方案的1.5-3秒降低到200-500ms。这是语音AI从"回合制对话"向"流式实时对话"跨越的关键一步。 实时语音API的发布，将彻底改变语音助手、客服、教育、无障碍等应用场景的用户体验。 技术架构 端到端语音模型 传统的语音AI采用"级联"架构： 语音输入 → ASR (语音识别) → 语言模型 → TTS (语音合成) → 语音输出 ↓ ↓ ↓ 耗时 耗时 耗时 总延迟：1.5-3秒 OpenAI的实时语音API采用端到端语音模型： 语音输入 → 语音-语言联合模型 → 语音输出 (单次推理) 总延迟：200-500ms 关键创新：OpenAI训练了一个原生多模态语音模型，直接将语音输入映射到语音输出，中间不经过文本表示。这意味着： 不需要ASR和TTS的级联 模型保留了语音中的韵律、情感、语调信息 可以处理语音中的打断、重叠、语气词 流式处理 实时语音API采用流式处理架构： import openai client = openai.OpenAI() # 流式语音对话 with client.beta.realtime.voice.stream( model="gpt-4o-realtime", voice="echo", # 支持6种声音 input_audio_format="pcm16", output_audio_format="pcm16", ) as stream: # 1. 实时发送语音输入 for audio_chunk in microphone_stream(): stream.input_audio_buffer.append(audio_chunk) # 2. 实时检测说话结束 if stream.input_audio_buffer.speech_stopped(): break # 3. 模型开始处理（200-500ms） # 4. 实时接收语音输出 for audio_chunk in stream.output_audio_stream(): speaker.play(audio_chunk) 整个过程中，用户可以在AI说话时打断它——就像与人类对话一样。 ...

引言 用户在发出一个深层推理问题后，等待智能体输出的那几秒钟，往往决定了产品的第一印象。2025 年以来，几乎所有主流的 AGI 智能体产品都标配了"打字机效果"——字符逐字出现，推理过程可见。但这背后的流式响应架构，远比表面上看起来复杂。 智能体流式响应不只是一个 UI 层面的锦上添花，它直接决定了系统的感知延迟、错误恢复能力和可扩展性。本文将围绕 AGI 智能体流式响应架构的设计展开系统讨论。 一、流式响应的核心技术路径 1.1 SSE：轻量级的首选 Server-Sent Events（SSE）是目前智能体流式响应中最广泛使用的传输协议。与 WebSocket 不同，SSE 天然运行在 HTTP 之上，浏览器原生支持 EventSource API，无需复杂的握手和心跳维护。 在典型架构中，LLM 推理引擎以 token 级别粒度产生输出，经由反代层封装为 SSE 事件流，逐帧推送到前端渲染缓冲区。SSE 的优势在于： 部署成本极低：直接复用现有的 HTTP 负载均衡和鉴权中间件 自动重连：浏览器内置断线重连能力 服务端推送天然单向：符合"模型输出→用户"的单一数据流向 但在多智能体协作（Multi-Agent）场景中，SSE 的单向特性成为瓶颈——当我们需要聚合多个子智能体并行产出的流时，SSE 的连接管理复杂度迅速上升。 1.2 WebSocket：双向互动的基石 WebSocket 在需要双向并行数据流的场景中不可替代。典型的例子是 Agent+Tool 的迭代式推理： 用户提问 → Agent 分析 → 调用搜索工具 → 等待结果 → 整合输出 在这个过程中，Agent 需要一边接收工具的返回数据，一边逐步向用户透传推理进度。WebSocket 的全双工特性让"一边等待工具响应、一边输出推理日志"成为可能。 我们团队在实践中采用的是一种分层混合架构： 外层 SSE + 内层 WebSocket：前端流量入口统一使用 SSE，隐藏后端的复杂性与容错逻辑；而在 Agent Engine 内部，各组件之间以 WebSocket 进行实时通信。 这既保持了前端接入的简洁性，又为内部高并发消息交换保留了灵活性。 ...