实时语音为人们与 AI 应用互动带来了全新的方式。用户无需打字或浏览菜单，只需自然地说话，就能获得节奏实时、富有情感语境的回应。
打造出色的实时语音体验，关键在于协调现场互动。真正的产品工作由此开始。实时体验即时而逼真；要构建一款能够持续提供这种体验的应用，则是另一项独特的工程挑战。
模型只是系统的一部分。生产级应用需要原生语音基础设施、明确分离对话流程与深度推理，并通过事件驱动控制来管理不断推进的会话。
防护机制和评估仍是主要难点所在。安全检查需要跟上实时音频的节奏，而时机、语气和对话流畅度等转瞬即逝的对话特质，很难用传统评估策略衡量。
如今，大多数支持语音的 AI 应用仍采用同一种工作方式：输入语音，转换成文本，由模型思考，再通过合成语音读出答案。这种方式确实可行。但这种互动给人的感受也与其本质一致：它是一条管道，而不是一场对话。
实时语音改变了这一点。用户可以自然地说话，并获得具有节奏、语气和情感语境的回应。与链式语音转文本管道相比，这种体验更快、更流畅，更像与人交谈，而非操作系统。
我们已经看到，这为一些链式架构难以支持的产品交互场景打开了空间。实时语音智能体可以处理原本需要冗长、受限的交互式语音应答菜单和部门转接才能完成的客户服务互动。它们可以提供辅导和入门引导，跨媒介协助无障碍使用，等等。只要口语对话比文本界面更具优势，就值得构建实时语音功能。
大多数语音应用采用所谓的“链式方法”：将语音转文本、语言处理和文本转语音等独立模型串成管道。这些系统表现良好，也带来了广泛的应用机会，但音频只存在于管道两端。彼此分离的步骤带来了固定结构和额外延迟，使互动不如真实对话自然。
实时语音采用了不同的方法。它不再依赖不同的模型分别负责倾听、思考和表达，而是由单一模型原生处理这三项任务，同时理解并生成音频和转录文本。输入和输出会持续进行，让系统能以自然的时机和富有情感的方式作出回应，保持现场对话的真实节奏。因此，时机、语气和打断处理成为产品的核心组成部分。
实时体验之所以吸引人，是因为它即时自然；其难点则在于所有事情都会同时发生。要支持这种体验，仅仅快速、准确地生成音频还不够。真正困难的是其他所有环节。模型在实时会话中运行；其周围的一切——状态、安全、编排和控制——也必须以同样的实时节奏与对话同步运行。
在链式语音应用中，轮次制对话具有清晰的往返结构。用户说话，系统回应，然后进入下一步。实时语音没有这种结构。双方可能同时说话，也可能都不说话，陷入沉默。用户可能在回复中途打断，也可能在系统说完之前继续追问。打断不再是边缘情况，而是核心互动模式。
正是这种模式让实时应用从根本上成为一个协调问题，也让模型周围的系统与模型本身同等重要。
要规模化支持此类系统，必须专门针对实时互动进行设计。成功投入生产的系统通常都具备以下三个部分。
实时语音会话需要处理音频流传输、轮流发言、打断、连接生命周期和智能体执行。根据应用的部署环境，可能还需要支持电话通信。这些既是体验的基础，也是实现应用规模化的核心。
首要条件是原生语音会话层。实时通信（RTC）框架为应用提供了管理参与者、传输音频流以及在电话通信环境中运行智能体的基础。根据我们的经验，Livekit 尤其实用，它提供低延迟 WebRTC 技术栈，并内置高质量的降噪和抖动抑制功能。自行实现这一层通常不值得承担额外的复杂性。
实时语音的多智能体架构，本质上是为了实现关注点分离。
实时语音模型非常擅长传输对话音频流，但并未针对深度推理进行优化。工具调用、检索或结构化决策等任务，更适合由另一个模型执行。
一种实用模式是响应者—思考者架构。
响应者就是实时语音智能体。它负责维持实时互动：倾听、表达、处理打断并保持对话流畅。其设计优先考虑响应速度、清晰度和情感连贯性。
思考者是另一个由具备推理能力的模型驱动的智能体。它在主交互通道之外运行，负责工具使用、检索和规划等任务。响应者可以在需要时调用它，并将结果融入对话。
有时，思考者可以直接负责推理。在其他情况下，它可以充当一组专业智能体的编排者。核心思路是让更适合推理任务的模型完成这项工作。
好处很直观：响应者可以保持快速、自然和专注，而思考者则负责需要更多时间、上下文或结构的工作。
未来前沿模型的发展或许会让这种方法失去必要性，但就目前而言，我们发现这种模式的表现始终优于单智能体方法。
实时语音系统天然会持续产生事件流。
用户会开始说话、停顿和打断。转录文本会逐步更新。回复会生成并以流式方式传输。外部结果会陆续返回。会话中的条件会不断变化。所有这些都可以作为形成当前特定对话状态的关键事件，被捕捉、传输和存储。没有这些事件，我们就无法进行精细、有针对性的干预。
事件驱动方法为此提供了清晰的管理方式。系统在事件发生时进行捕捉、更新会话状态，并触发适当的后续操作。
轻量级处理程序让实时路径保持敏捷；更新状态机、记录指标、删除敏感信息、更新数据库和退出会话等更复杂的任务，则以异步后台任务的形式触发。
随着功能增加，这些后台任务的数量可能迅速增长。即使很小的产品改动，也可能引入新的事件流和依赖关系。为这种并发建立结构良好的架构非常重要，这样才能让系统在演进过程中始终易于理解且可靠。
这种事件驱动方法还支持一项关键的产品需求：塑造对话本身。实时音频系统不只是生成回复；它还要控制节奏、处理沉默和打断，并决定会话应以何种方式、在何时结束。这些行为都是产品体验的一部分，值得进行明确设计。
随着会话状态根据对话轮数、已用时间或用户行为而变化，系统可以向响应者注入有针对性的指导。当会话接近时限时，系统可以提示智能体帮助用户收尾；如果互动停滞，也可以提供澄清。这些干预很轻量，却能让体验显得经过精心设计且连贯一致。
设计良好的系统会清楚掌握会话状态：谁在说话、对话进展如何，以及哪些条件已经满足。事件流会持续更新这些状态，使系统能在恰当的时机提供恰当的指导。
面向用户的 AI 必须配备防护机制。它们用于保障安全与可靠性、确保合规并防止滥用。在轮次制系统中，运行防护机制的时机很明确：用户说完之后，或回复送达之前。
实时语音消除了大多数这样从容的检查点。用户输入会持续传入。音频输出可能已经开始流式传输。完整转录文本通常会滞后于声音。如果系统等到消息完整后才检查，对话就不再有实时感。
因此，防护机制需要与对话同步运行，才能保持逼真的互动体验。一种做法是将音频流式传入缓冲区，同时在转录片段生成后对其进行异步评估，让安全检查以近乎实时的速度运行，又不会阻塞互动。
当防护机制触发时，系统可以结合上下文作出响应，例如引导对话转向、调整行为，或在适当情况下结束会话。这样既能让防护机制实时运行，又不会损害用户体验。
评估实时对话系统最困难的一点在于，一些最重要的品质——时机、打断、流畅度和语气——无法通过仅基于转录文本的测试来衡量。
标准评估流程会向系统输入真实场景，观察输出并进行评分。对于文本系统或链式音频系统，这很简单：输入文本，检查输出文本。在实时系统中，输入是现场音频，而最重要的对话动态都发生在时间维度上：智能体如何处理重叠语音、响应有多快，以及如何从打断中恢复。
人工测试（直接与智能体交谈）可以捕捉这些特质，却难以规模化。基于转录文本的自动化测试可以规模化，却会丢失区分实时体验优劣的关键信号。
任何单一方法都不够。切实可行的答案是组合使用多层方法：
智能体间评估：由另一个实时智能体扮演特定用户角色，与受测系统进行对话。再由第三个充当评审的 LLM 为互动评分。这样能大规模测试完整音频链路，包括时机和打断处理。
非功能性指标：首段音频生成时间和转录文本情感分析可作为衡量对话质量的量化替代指标。
人工定性审查：对于发现自动化指标遗漏的问题仍不可或缺，尤其是语气和自然度方面的问题。
没有一种方法能涵盖所有方面。要将实时智能体部署到生产环境，必须综合运用这三种方法。即便如此，与文本 AI 相比，实时音频评估工具仍不成熟。
实时语音改变了产品的形态。除了话语本身，时机、打断、沉默和恢复同样影响着用户体验。
这意味着模型只是系统的一部分。生产级实时语音需要原生语音会话层、明确分离表达与推理，并围绕实时会话实施事件驱动控制。防护机制仍是延迟瓶颈，但创新方法可以在很大程度上保留实时体验。
整套技术栈中最薄弱的环节仍然是评估。目前还没有成熟的方法来测试决定实时语音体验好坏的特质：时机、语气、打断处理和对话流畅度。在找到这种方法之前，采用该技术的团队需要结合自动化测试、智能体间测试和人工审查。