Agent 语音交互如何更稳、更快？一次高并发消息链路优化实践

作者：雀贤、文婷、复礼、稚柳

随着大语言模型（LLM）、语音识别（ASR）、语音合成（TTS）等能力逐步成熟，AI Agent 开始从文本交互走向语音交互，典型场景包括 AI 教师、AI 情感聊天、AI 助手等。相比文本输入，语音更自然、更实时，用户可以直接通过说话完成提问、练习、任务触发与多轮对话，这也让“和 Agent 用语音对话”真正进入实际业务场景。

但当 Agent 语音交互进入高并发场景后，很多团队会发现：最先遇到瓶颈的，往往不是模型本身，而是支撑实时交互的消息链路。海量会话管理、高频小包传输、异步结果回推、会话生命周期管理等问题会随之集中出现。要让和 Agent 语音交互真正做到更稳、更快，底层链路设计往往才是关键。

本文结合一个典型的高并发智能语音交互场景，介绍如何基于阿里云 RocketMQ LiteTopic 构建一套更稳定、更可靠、更高效的实时语音消息链路架构。

在 Agent 语音交互场景中，系统并不只是“接收一句话、返回一句话”这么简单。一次完整交互背后，往往涉及客户端、网关、业务处理系统，以及 LLM、ASR、TTS 等多个服务之间的协同。

因此，智能语音交互业务会对技术架构提出更高要求：

• 海量会话管理：随着业务规模增长，并发连接数和活跃会话数会迅速上升。每个用户的语音交互都是一个独立会话（Session），系统需要同时维持数万甚至数十万个长连接。

• 高频小包传输：用户按下录音键到松开，形成一个独立会话（Session）。在此期间，客户端会将音频流切片成小包持续传输，需要保证语音包连续、不丢失，避免影响业务正确性。

• 严苛的时效性：客户端对延迟极度敏感，若较长时间内未收到响应，用户体验会明显下降。这对 LLM 在高并发场景下的吞吐能力，以及系统的实时响应通知能力，都提出了更高要求。

正因如此，很多系统在低并发时看起来“可以跑通”，但一旦进入高并发实时语音场景，底层消息架构中的问题就会被迅速放大。

在智能语音交互业务的实际落地过程中，传统消息架构在支撑高并发、低延迟的实时语音场景时，往往会暴露出几类典型问题。

语音交互的消息流转路径通常贯穿：APP <-> Gateway <-> BizProcessSystem (Route) <-> LLM/ASR/TTS。其中，APP 与 Gateway、BizProcessSystem 与 LLM 之间均维持着 WebSocket 长连接。

在这种架构下，整个链路必须严格保持会话粘滞（Session Sticky）。也就是说，某个用户的上行音频流和下行反馈结果，必须精准路由到其当前连接的特定网关节点，以及对应的后端处理实例。

问题在于，在分布式环境下，维护“Session ID 到物理节点 IP”的动态映射表本身就非常复杂。一旦网关节点扩容、重启，或者发生网络波动，路由表同步延迟极易导致消息被投递到错误节点，进而造成连接断裂、数据丢失，破坏交互连续性。

大模型（LLM）的推理过程通常耗时较长且波动明显（秒级甚至分钟级）。若采用同步等待模式，会长时间占用网关和业务线程，导致系统吞吐量急剧下降，甚至引发资源耗尽的雪崩效应。

因此，为了提升吞吐，LLM 调用通常需要改造成异步处理。但异步之后，新的难点也随之出现：最终计算结果（如 ASR 文本、TTS 音频）如何实时、准确地回推给发起请求的那个用户连接？

如果依赖复杂的回调轮询或状态查询，不仅实现复杂，还会进一步增加延迟和维护成本。这也是语音交互架构设计中的核心难点之一。

从业务逻辑上看，为每个独立语音会话（Session）建立隔离的通信通道，是避免数据串扰的理想方案。

但如果为每个 Session 都创建一个标准 RocketMQ Topic，就会带来明显的元数据（Metadata）爆炸问题。海量临时 Topic 会严重消耗 NameServer 和 Broker 的内存与 CPU 资源，导致集群性能急剧下降，甚至影响可用性。

此前，一些场景会采用广播消息的方案来规避这一问题。虽然实现简单，但也存在两个明显缺陷：

• 消息会在所有节点重复投递和过滤，造成大量无效流量与计算资源浪费。

• 所有节点都需要处理全量消息，单节点处理能力容易成为整体容量上限，系统水平扩展受限。

因此，广播模式很难支撑持续增长的高并发语音业务。

语音会话通常具有很强的临时性，并不是永久存在的资源。它的生命周期可能只是一次几分钟的对话，也可能仅存在于一个业务周期之内。

但在传统架构下，会话结束后的路由记录、缓存状态、临时通道等资源，往往需要依赖定时任务扫描或手动清理。这会带来两个典型问题：

• 清理不及时：无效资源长期堆积，占用系统内存和计算资源。

• 清理过早：可能切断仍在进行中的合法交互。

因此，系统需要一种真正适合临时会话场景的机制，能够实现通道的自动创建、自动过期和自动销毁。

针对上述问题，可以基于阿里云云消息队列 RocketMQ 的轻量主题（LiteTopic）模型，构建一套更适合高并发智能语音交互场景的消息中间件架构。

LiteTopic 支持动态创建海量轻量主题，天然具备会话隔离能力，并内置 TTL 自动清理机制。这些特性与 Agent 语音交互场景对“高并发、低延迟、强隔离、易回收”的要求高度契合。

1.1 请求保序与响应隔离的核心架构

• 请求侧：分片音频包采用分区顺序 Topic 上传

  同一个会话的语音包用 SessionID 作为分区顺序的 Key，发送到分区顺序 Topic 中，相同 Key 的消息会按照发送顺序投递给业务处理系统，从而保证同一会话内消息处理有序。

• 响应侧：模型结果通过 LiteTopic 异步通知

• 为每个会话创建一个 LiteTopic：直接使用 SessionID 作为 LiteTopic 名称。每个语音会话拥有独立的消息通道，天然实现消息隔离。

• 每个节点订阅不同的 LiteTopic 集合：应用服务端节点作为 Consumer，只订阅与当前节点相关会话的 LiteTopic 集合，确保消息“点对点”精准投递，无需维护复杂路由表。

• 节点动态订阅 LiteTopic：会话断连后，可以动态删除对应 SessionID 的 LiteTopic 订阅；新会话建立时，可以动态新增对应 SessionID 的 LiteTopic 订阅。当网络异常或者服务节点重启时，也可以利用动态订阅能力续订 LiteTopic 消息，从而保障会话内容连续性。

• LiteTopic 自动创建：LiteTopic 无需预先创建。当生产者发送消息时，如果发现 LiteTopic 不存在，会自动创建，且不影响消息发送耗时。

• 配置合适的 TTL 时间：当 LiteTopic 距离最近一次消息写入超过设定时长后，会被自动删除。可结合实际业务特点，设置合适的 TTL 时长。

1.2 面向运维和问题定位的可观测性

RocketMQ LiteTopic 基于云监控建立了全方位、细粒度的监控、告警与排查体系：

• 智能告警：配置 LiteTopic 的消息堆积量阈值。一旦某会话链路延迟超过预期，立即触发告警。

• 快速定位：收到告警后，运维人员可直接在控制台 Group 详情页查看堆积量最高的 LiteTopic 列表及对应的消费者 IP。借助这种细粒度透视能力，原本大海捞针般的故障定位变成了分钟级的精准修复。

基于 RocketMQ LiteTopic 的轻量化、灵活订阅、自动创建及 TTL 自动删除等原生特性，这套方案在架构层面主要具备以下三方面优势：

2.1 保障长耗时会话的极致连续性

借助 LiteTopic 的自动创建、“一会话一通道”和动态订阅机制，系统可以为每个语音会话建立独立的响应通道。无论 LLM 推理耗时多久，消息都能在专属通道中有序流转，避免多会话间的消息串扰。

同时，即使后端服务发生扩缩容或网络波动，响应消息仍能回到用户当前连接的网关节点，保证长链路交互中的 Session Sticky 和会话连续性。

此外，通过 LiteTopic 的异步通知机制，系统可以避免长耗时线程阻塞，进一步提升整体吞吐能力，让用户在高峰期也能获得流畅的语音交互体验。

2.2 推动应用架构进一步无状态化

在传统方案中，应用通常需要维护“Session ID 到 Node IP”的路由映射，以及配套的心跳保活和异常清理逻辑，状态管理复杂、维护成本高。

引入 LiteTopic 后，路由逻辑下沉到消息中间件层，业务代码只需围绕 SessionID 发送和接收消息。应用节点因此更接近无状态计算单元，不再强依赖本地连接状态表。这样不仅能够降低状态管理复杂度，也让应用更容易进行弹性伸缩和故障恢复，从而提升整体可维护性与容灾能力。

2.3 降低无效调用带来的模型成本

在传统架构中，消息错投或超时导致的“无响应”往往会触发客户端重试，导致同一段音频被重复发送给 LLM 推理，带来额外的 Token 消耗。

通过更精准的会话路由和可靠的投递机制，这套方案能够更好地保障“一次请求，必达响应”，显著减少因链路问题导致的重复调用，从而直接降低 LLM 的无效 Token 成本。

从业务效果来看，引入 RocketMQ LiteTopic 之后，高并发智能语音交互链路通常可以在以下几个方面获得明显提升：

• 用户体验更稳定：可以显著减少因连接状态不一致导致的“无响应”问题，提升语音交互成功率。即使在网络波动场景下，也能更好保障无感知重连，确保交互连续性。

• 系统复杂度更低：不再需要维护复杂的自定义路由表和状态同步逻辑，而是借助 LiteTopic 的原生能力完成会话管理，整体架构更简单，也更易扩展。

• 运维定位更高效：借助细粒度监控与告警，潜在性能瓶颈可以在影响用户前被发现和处理，问题定位与修复效率明显提升。

• 资源成本更可控：借助云消息队列 RocketMQ 版的弹性能力，业务可以按量付费，无需提前预留峰值容量，同时减少重复调用带来的额外模型消耗。

• 业务扩展更从容：更轻量、可扩展的链路设计，也为后续拓展更多实时互动场景打下基础，能够更从容地应对流量增长。

很多团队在构建 Agent 时，往往会优先关注模型能力、推理效果和成本控制。但在高并发实时语音场景中，想把这些能力稳定地交付给用户，消息链路的稳定性、精准性和可扩展性同样不可忽视。

基于 RocketMQ LiteTopic 的这套方案，本质上解决的是几个关键问题：

• 海量会话如何隔离。

• 长链路如何保持 Session Sticky。

• 异步结果如何精准回推。

• 临时通道如何自动管理。

• 系统如何在高并发下保持可观测与可扩展。

RocketMQ LiteTopic 提供了一种更适合高并发实时交互场景的消息架构思路。对于正在推进 Agent、实时互动、大模型应用工程化落地的团队来说，尤其是需要支撑海量动态会话、低延迟响应和灵活扩展的业务，这类能力正在从“加分项”逐步变成“必选项”。

欢迎钉钉搜索（群号：110085036316）或扫码加入 RocketMQ for AI 用户交流群，与我们交流探讨。