实时 AI 这个概念最近被聊得最多的场景基本都是语音对话、数字人视频、屏幕共享那一套。Gemini Live Avatar 出来之后很多人第一反应是这不就是把聊天升级成视频通话了嘛。但如果你真的动手接过这类实时接口会发现一个反直觉的事实真正难啃的骨头不在视频渲染而在文本工作流怎么和实时通道共存。我最近在折腾 RelayRouter 这套路由层的时候踩了不少坑也理清了一些之前一直模糊的边界。这篇就把我理解的实时 AI 里文本工作流到底站在什么位置讲透顺带把 WebSocket 心跳、连接保活这些绕不开的细节掰开揉碎说清楚。不管你是刚接触实时接口的新手还是已经在做多模态编排的老手应该都能从里面捞到点能直接用的东西。1. 为什么实时 AI 聊天变视频是个危险的简化1.1 视频只是最外层的表现底层是通道复用问题大多数人看到 Gemini Live Avatar注意力全在AI 有脸了、能动了、口型对上了。但从工程角度看视频流只是最外面那层皮。真正决定这套系统能不能用的是底下那条长连接通道怎么同时承载音频、视频、文本、控制信令这四类完全不同的数据。这四类数据的特性差异极大。音频要求低延迟、允许丢包、可以压缩视频要求带宽稳定、对抖动敏感文本要求可靠送达、不能乱序控制信令要求即时、优先级最高。把它们塞进同一条 WebSocket 连接里就像让四种车速完全不同的车跑同一条车道——不做好分流和优先级必然堵车。我一开始也以为实时就是把原来的请求-响应改成流式推送。实测下来完全不是。原来的文本工作流是发一条、等一条、处理一条节奏是离散的实时通道是永远开着、随时来数据节奏是连续的。这两种节奏混在一起最容易出问题的就是状态管理——你不知道当前这条文本到底是属于上一轮对话的收尾还是新一轮的开场。1.2 文本工作流在实时场景里反而更脆弱有个现象挺有意思语音和视频出点小问题用户往往感知不到卡一下、糊一下都能忍但文本一旦错位、重复、丢字用户立刻就觉得这 AI 坏了。原因是文本承载的是精确语义而音视频承载的是氛围和情绪。所以在实时 AI 系统里文本工作流的可靠性要求其实比音视频更高。它不能容忍乱序、不能容忍重复投递、不能容忍半截消息。这就引出一个核心问题当音视频走的是尽力而为的实时通道时文本要不要也走同一条通道如果走同一条怎么保证它的可靠性不被音视频的抖动拖累我的结论是文本工作流应该有自己的路由策略而不是简单搭在实时通道上蹭车。这正是 RelayRouter 这类路由层存在的意义——它不生产数据它负责决定哪类数据走哪条路、按什么优先级、失败了怎么补偿。1.3 RelayRouter 到底在解决什么把 RelayRouter 理解成一个交通调度中心最贴切。它站在客户端和多个后端服务之间手里握着几条不同的通道实时 WebSocket、普通 HTTP、可能还有消息队列然后根据数据类型、优先级、当前通道健康度决定每条消息怎么走。它解决的三个核心问题通道选择文本走可靠通道音视频走实时通道控制信令走最高优先级通道。故障转移实时通道断了文本能不能自动切到备用通道继续跑而不是整个会话崩掉。状态同步多条通道之间的会话状态怎么保持一致避免视频里 AI 说了一半文本这边完全不知道。理解了这三点你就明白为什么我说实时 AI 不只是聊天变视频——视频是给人看的路由是给系统活的。没有靠谱的路由层再炫的数字人也只是个会动的花瓶。2. WebSocket 在实时 AI 里的真实角色与常见误用2.1 WebSocket 不是更快的 HTTP新手最容易犯的错是把 WebSocket 当成性能更好的 HTTP 请求。这个理解会直接导致架构设计跑偏。HTTP 的本质是无状态、请求驱动——你不问它不答。WebSocket 的本质是有状态、事件驱动——连接一旦建立双方都可以随时主动推数据。这个差别带来的直接后果是WebSocket 连接本身成了一个需要被管理的资源。它会长连、会占用内存、会超时、会半死不活。你得给它做心跳、做重连、做背压控制。而 HTTP 你基本不用操心这些发完就完事。在实时 AI 场景里一条 WebSocket 连接往往要活几十分钟甚至几小时。这么长的时间里网络抖动、中间设备超时踢连接、服务端重启都是家常便饭。所以连接管理不是可选项是必答题。2.2 什么时候该用 WebSocket什么时候别硬上不是所有实时需求都得上 WebSocket。我见过不少项目明明只是每隔几秒拉一次状态也硬套 WebSocket结果维护成本翻倍。判断标准其实很简单场景特征推荐方案原因服务端需要主动推送、双向频繁交互WebSocket长连接双向通信省去反复建连开销单向、低频的状态更新SSE 或轮询实现简单无需管理连接生命周期请求-响应为主、偶尔推送HTTP 长轮询复用现有基础设施改造成本低音视频流 文本 信令混合WebSocket 路由层需要通道复用与优先级调度实时 AI 对话属于最后一类所以 WebSocket 是合理选择。但注意合理不等于所有数据都塞进去。我的做法是音视频和控制信令走 WebSocket纯文本的持久化、检索、后处理走 HTTP 或消息队列由 RelayRouter 统一编排。2.3 一条连接承载多路数据的坑把音频、视频、文本塞进一条 WebSocket第一个坑就是消息边界。WebSocket 本身有帧的概念但应用层如果不好好设计消息格式很容易出现半条消息被当成完整消息处理的情况。我的经验是应用层一定要有自己的消息信封envelope至少包含这几个字段{ type: text | audio | video | control, seq: 1024, session_id: abc-123, timestamp: 1710000000000, payload: {} }type决定路由seq用于检测乱序和丢包session_id用于多会话隔离timestamp用于超时判断。别小看这几个字段少了任何一个后面排查问题都会让你怀疑人生。第二个坑是背压。音视频数据产生速度可能远快于消费速度如果不管不顾地往连接里灌内存会涨、延迟会飙。WebSocket 的bufferedAmount属性就是给你做背压用的——当它超过阈值时你得主动降采样或丢帧而不是硬塞。3. WebSocket 心跳机制从原理到能落地的实现3.1 为什么必须有心跳不做会怎样很多人觉得心跳是锦上添花不做也能跑。我实测过不做心跳的连接在移动网络下平均十几分钟就会变成假死状态——TCP 层面连接还在但数据已经发不出去了。这种假死最坑因为你的代码以为连接是好的还在往里发消息实际上全石沉大海。心跳解决三个问题探活确认对端还活着能收能发。保活防止中间设备负载均衡、网关因为长时间无数据而主动断开连接。延迟测量通过心跳往返时间估算当前网络质量为路由决策提供依据。注意心跳不是发个 ping 就完事。真正有用的心跳必须能检测到连接假死也就是发出去没回应的情况。只发不等回应的心跳等于没做。3.2 心跳间隔怎么定一个可计算的思路心跳间隔没有万能值但有个计算逻辑。核心约束是心跳间隔必须小于中间设备的最短空闲超时时间。常见的网关空闲超时是 60 秒负载均衡可能是 30 秒。所以心跳间隔取 15 到 25 秒比较稳妥。但还要考虑另一个因素检测延迟。如果你希望连接断了之后 30 秒内能发现那心跳间隔加上超时判定时间要小于 30 秒。假设心跳间隔 15 秒连续 2 次没回应就判定断开那最坏情况检测延迟约 30 秒刚好卡线。我的实际配置是心跳间隔20 秒超时判定连续 2 次未收到 pong重连退避1s、2s、4s、8s上限 30s这套参数在移动网络和 Wi-Fi 下都跑得比较稳。如果你的场景对断线更敏感可以把间隔压到 10 秒代价是流量和电量消耗上升。3.3 一个能直接用的心跳实现下面这段是客户端侧的心跳逻辑用 JavaScript 写思路通用class Heartbeat { constructor(ws, options {}) { this.ws ws; this.interval options.interval || 20000; this.maxMissed options.maxMissed || 2; this.missed 0; this.timer null; this.onDead options.onDead || (() {}); } start() { this.stop(); this.timer setInterval(() { if (this.missed this.maxMissed) { this.stop(); this.onDead(); return; } this.missed; this.ws.send(JSON.stringify({ type: control, payload: { action: ping } })); }, this.interval); } pong() { this.missed 0; } stop() { if (this.timer) { clearInterval(this.timer); this.timer null; } } }服务端收到ping后回一个pong客户端在onmessage里识别到pong就调用heartbeat.pong()重置计数。逻辑很朴素但能挡住 90% 的假死问题。3.4 心跳和业务消息的优先级冲突这里有个容易被忽略的细节心跳消息和业务消息共用一条连接时心跳可能被业务消息堵在后面。如果业务消息量很大心跳发不出去就会误判连接断开。解决办法是给心跳单独开一条轻量连接或者在应用层给心跳消息最高优先级插队发送。我倾向于后者因为多开连接会增加管理复杂度。具体做法是在发送队列里给control类型的消息打最高优先级业务消息排队时让心跳先走。4. RelayRouter 如何编排文本工作流与实时通道4.1 文本工作流的三段式拆分在实时 AI 系统里文本工作流其实可以拆成三段每段对通道的要求完全不同输入段用户输入的文字、语音转写结果。要求低延迟进入系统可以容忍偶尔的重复。处理段意图识别、检索、工具调用、大模型推理。要求可靠、可重试、可追踪。输出段最终回复文本、中间状态提示。要求可靠送达、顺序正确、不能丢。RelayRouter 的价值就在于它能让这三段走不同的路。输入段走实时通道抢低延迟处理段走可靠通道保证不丢输出段根据内容类型决定走哪条。我踩过的一个坑是一开始把三段全塞进 WebSocket结果处理段一旦遇到慢查询整条连接都被拖住音视频也跟着卡。后来把处理段拆出去走 HTTP实时通道只负责输入和输出整个系统立刻顺畅了。4.2 路由决策表怎么设计RelayRouter 的核心是一张路由决策表。这张表决定了什么消息走什么通道。我的设计大致如下消息类型优先级首选通道备用通道重试策略控制信令最高WebSocket无不重试直接重连用户文本输入高WebSocketHTTP最多 2 次模型输出文本高WebSocketHTTP最多 3 次音视频流中WebSocket降级为纯音频不重试丢帧后处理任务低HTTP / 队列无指数退避重试这张表不是拍脑袋定的是根据每类数据的丢失代价和延迟敏感度两个维度权衡出来的。控制信令丢了整个会话就乱套所以优先级最高且不重试重试反而可能造成状态错乱后处理任务丢了可以慢慢补所以走低优先级通道。4.3 故障转移时的状态一致性路由层最难的部分不是切通道而是切完之后状态还对得上。举个具体场景用户正在说话WebSocket 突然断了RelayRouter 把文本输入切到 HTTP 备用通道。这时候问题来了——断线前那半句已经通过 WebSocket 发出去的话服务端收到了吗如果收到了切到 HTTP 后会不会重复处理我的解法是给每条消息带一个幂等键idempotency key由session_id seq组成。服务端维护一个近期已处理消息的滑动窗口收到重复键就直接丢弃。这样无论消息走哪条通道、重试几次业务层都只处理一次。这个机制听起来简单但它是整个故障转移能成立的前提。没有幂等保证的故障转移等于给系统埋雷。5. 实测中暴露的问题与排查链路5.1 连接看着是好的但消息发不出去这是我最开始遇到的最诡异的问题。监控面板显示连接状态是OPEN心跳也在正常收发但业务消息就是发不出去或者发出去没回应。排查链路是这样的先看bufferedAmount发现它一直在涨说明消息堆积在发送缓冲区。再看服务端日志发现服务端根本没收到这些消息。怀疑是中间网关的问题抓包发现 TCP 层有重传但应用层数据没上去。最终定位网关的空闲超时是 30 秒而我的心跳间隔设成了 45 秒连接被网关悄悄断了但客户端和服务端都没感知到。修复就是把心跳间隔压到 20 秒并加上连续未回应判定。这个问题让我彻底明白心跳间隔必须小于链路上最短的那个空闲超时不能想当然。5.2 文本乱序导致的答非所问第二个坑是文本乱序。实时通道里音视频和文本混在一起如果应用层不做序号管理文本可能后发先至。表现出来就是 AI 的回答对不上用户的问题。排查过程在消息信封里加上seq发现收到的文本seq确实不是递增的。定位到是 RelayRouter 在切换通道时两条通道的消息合并顺序没对齐。修复方案是在路由层加一个重排序缓冲区按seq排序后再交给业务层超过一定时间窗口还没到的消息就触发补拉。这个缓冲区的大小要权衡太小了乱序纠正不过来太大了延迟高。我最后定的是 200ms 窗口实测能覆盖绝大多数乱序情况。5.3 重连风暴把服务端打挂第三个坑更惨烈。有一次线上抖动大量客户端同时断线重连结果重连请求把服务端打挂了形成雪崩。根因是重连没有退避所有客户端都在同一时间重连。修复方案是指数退避 随机抖动function getReconnectDelay(attempt) { const base Math.min(1000 * Math.pow(2, attempt), 30000); const jitter Math.random() * 1000; return base jitter; }随机抖动是关键它把重连时间打散避免惊群。这个教训让我在之后所有长连接项目里第一件事就是加重连退避。6. 把文本工作流放对位置的几条经验6.1 文本不该追求和音视频一样实时很多人有个执念既然叫实时 AI那文本也得毫秒级响应。其实没必要。文本的价值在于准确和完整不在快那几十毫秒。为了追求极致低延迟把文本也塞进实时通道反而牺牲了可靠性得不偿失。我的原则是文本的延迟目标定在用户感知不到等待即可通常 300ms 到 1s 都算合格。把省下来的可靠性预算用在幂等、重试、顺序保证上收益大得多。6.2 路由层要能看见业务语义RelayRouter 如果只是个无脑转发器价值有限。它必须能理解消息的业务语义——知道哪条是控制信令、哪条是用户输入、哪条是模型输出才能做出正确的路由决策。这就要求消息信封设计得足够清晰且路由规则要可配置、可热更新。我见过把路由规则硬编码在代码里的做法每次调整都要发版非常痛苦。把规则抽成配置配合灰度发布才能快速响应线上变化。6.3 监控要盯住连接质量而不只是连接状态连接状态只有OPEN和CLOSED两种但连接质量是个连续谱。我现在的监控面板会盯这几个指标心跳往返时间RTT的 P50 和 P99消息发送到确认的平均耗时重连频率各通道的消息积压量这些指标能提前预警连接要出问题而不是等它彻底断了才发现。特别是心跳 RTT 的 P99一旦飙升往往意味着网络要抖了可以提前降级。6.4 一个容易被忽略的细节会话恢复实时会话断线重连后用户期望的是接着刚才继续而不是从头再来。这要求服务端能保存会话上下文并在重连时快速恢复。我的做法是会话状态定期快照到 Redis重连时带上session_id和最后收到的seq服务端从快照恢复并补发seq之后的消息。这样用户几乎感知不到断线。这个机制配合前面说的幂等键能覆盖绝大多数断线场景。7. 关于实时 AI 架构的一点个人体会折腾完这一整套我最大的体会是实时 AI 的难点从来不在实时两个字而在实时和可靠怎么共存。音视频可以为了实时牺牲可靠文本不行文本可以为了可靠牺牲一点实时音视频不行。这两者的矛盾只能靠一个聪明的路由层来调和。RelayRouter 这类组件的价值不在于它多复杂而在于它把哪类数据走哪条路这件事从业务代码里抽了出来变成可配置、可观测、可演进的独立层。没有这一层实时 AI 系统会随着功能增加越来越乱最后变成一锅粥。如果你现在正在做类似的东西我的建议是先把消息信封和幂等键设计好再把心跳和重连退避做扎实最后再考虑路由策略的精细化。顺序别反了反了就得返工。Gemini Live Avatar 那种炫酷的数字人底层跑的还是这些朴素的工程原则——把连接管好把状态对齐把该走的路走对剩下的交给渲染层去表演就行了。