实时AI文本流处理：RelayRouter与WebSocket长连接架构实践

实时 AI 这个词最近被聊得很多，但大多数讨论都停在"能实时对话""能生成视频头像"这类表层体验上。Gemini Live Avatar 这类产品确实把实时交互的观感拉满了，可如果你是一个做文本工作流、做后台系统、做数据管道的工程师，看完热闹之后大概率会有一个疑问：这玩意儿跟我每天写的业务代码到底有什么关系？我真正关心的不是聊天窗口里那个会动的头像，而是当模型开始以"流"的方式持续产出内容时，我的文本处理链路该怎么接、怎么路由、怎么保证不丢不乱。这篇就从这个角度切入，聊聊 RelayRouter 在文本工作流里到底站在什么位置，以及为什么 WebSocket 这类长连接机制会成为绕不开的基础设施。不管你是刚接触实时推送的前端，还是已经在写 Django 后台推送的老手，这里面的取舍逻辑和踩坑经验应该都能对上你的场景。

1. 从 Gemini Live Avatar 的表象往下挖一层

1.1 实时 AI 真正改变的不是界面而是数据流形态

很多人第一次看到 Gemini Live Avatar，注意力全在那个能对口型、有表情的虚拟形象上。这很正常，视觉冲击力最强的东西总是最先被记住。但如果你把注意力从界面上移开，去看它背后的数据是怎么流动的，会发现一个更本质的变化：传统的"请求-响应"模式被打破了。

过去的 AI 调用基本是这样的：前端发一个完整的 prompt，后端等模型把整段话生成完，一次性返回，前端再渲染。这个模式简单、好调试，但代价是用户要盯着空白屏幕等好几秒。而实时 AI 把这个过程拆成了连续的 token 流或者音频帧流，模型一边生成，服务端一边往外推，前端一边消费一边渲染。数据不再是"一整块"，而是"一条持续不断的河"。

这个变化听起来只是体验优化，实际上它把整个工程链路的重心从"计算"挪到了"传输和编排"。因为一旦数据变成流，你就必须回答一连串新问题：这条流用什么协议传？中途断了怎么办？多个流之间怎么协调？文本流和音频流怎么对齐？这些问题在传统的请求-响应世界里根本不存在，但在实时场景里全是硬骨头。

1.2 文本工作流为什么也需要"实时"思维

有人会说，我又不做虚拟人，我就处理文本，实时跟我没关系。这个想法其实是个误区。文本工作流里"实时"的需求一点都不少，只是它不像视频头像那么显眼。

举几个很常见的场景。第一个是长文档的流式生成，比如让模型写一份几千字的报告，用户希望看到内容一点点冒出来，而不是等半分钟突然刷出一整屏。第二个是后台任务的进度推送，比如一个批量文本清洗任务跑在后台，前端要实时知道处理到第几条了、有没有报错。第三个是多步骤 Agent 工作流，一个任务要经过检索、摘要、改写、校对好几个环节，每个环节的中间结果都需要及时反馈给用户或者下一个环节。

这些场景的共同点是：数据是持续产生的，消费方需要尽快拿到，而且往往有多个消费方或者多个处理阶段。这跟 Gemini Live Avatar 面对的底层问题是一模一样的，只不过一个传的是音视频帧，一个传的是文本片段。所以别被"Avatar"这个词骗了，它展示的是一套通用的实时数据流架构，文本工作流完全可以、也应该借鉴这套思路。

1.3 RelayRouter 出现的背景：流多了就需要调度

当你的系统里只有一条流的时候，怎么传都行，直接开个连接怼过去就完事。但真实系统里往往同时存在好几条流：用户 A 的对话流、用户 B 的文档生成流、后台任务的进度流、系统告警的通知流。这些流的优先级不一样、生命周期不一样、消费方也不一样。

如果没有一个统一的调度层，代码很快就会变成一团乱麻：每个业务模块自己开连接、自己管心跳、自己处理重连，重复代码一大堆，出了问题还特别难排查。RelayRouter 这类组件要解决的就是这个问题——它站在流的中间，负责把不同来源的数据流按规则路由到不同的消费方，同时统一处理连接管理、心跳保活、断线重连这些脏活累活。

你可以把它理解成一个"流的交通枢纽"。上游是各种数据生产者（模型输出、后台任务、数据库变更），下游是各种消费者（前端页面、其他微服务、消息队列），RelayRouter 在中间决定哪条流该往哪走、走哪条道、堵了怎么办。这个定位决定了它在文本工作流里不是一个可有可无的装饰，而是当流多起来之后必然会出现的那个中间层。

2. RelayRouter 在文本链路里到底承担什么角色

2.1 它不是模型，也不是前端，而是中间的"分发器"

先把定位说清楚，避免概念混淆。RelayRouter 既不是跑模型推理的地方，也不是渲染界面的地方，它就是一个纯粹的分发和调度组件。模型负责生成内容，前端负责展示内容，RelayRouter 负责把内容从前者可靠地送到后者。

这个定位有点像快递分拣中心。商家（模型）把包裹（数据）交给分拣中心，分拣中心根据地址（路由规则）决定这个包裹该发往哪个片区（消费方），然后安排运输（连接管理）。分拣中心自己不生产包裹，也不拆包裹看内容，它只关心"这个包裹该去哪、怎么去最稳"。

理解这一点很重要，因为它决定了你该怎么用它。如果你指望 RelayRouter 帮你做文本清洗、格式转换、内容审核，那是用错了地方，这些应该在它上游或者下游的专门环节做。它的价值在于把"传输"这件事从业务逻辑里彻底剥离出来，让业务代码只关心"我要发什么"，而不用操心"怎么发才不丢"。

2.2 路由规则决定了文本流的走向

RelayRouter 的核心能力是路由，而路由的本质是一套"根据什么条件把数据发到哪"的规则。在文本工作流里，常见的路由维度有这么几类。

第一类是按会话或用户路由。用户 A 的流只能发给用户 A 的页面，绝不能串到用户 B 那里去。这是最基本的安全边界，实现上通常靠连接建立时绑定的身份标识来做匹配。

第二类是按消息类型路由。比如一条流里既有正文内容，又有状态通知，还有错误信息，不同类型的消息可能需要走不同的处理路径。正文直接推给前端渲染，状态通知可能还要写一份到日志系统，错误信息则要触发告警。

第三类是按优先级路由。高优先级的流（比如用户正在等待的交互响应）走快速通道，低优先级的流（比如后台批量任务的进度）可以适当缓冲、批量发送，避免占用太多连接资源。

第四类是按处理阶段路由。在多步骤工作流里，一个任务的输出可能是下一个任务的输入，RelayRouter 需要知道当前这条流处于哪个阶段，该把它交给哪个下游处理器。

这四类规则在实际系统里往往是组合使用的。设计路由规则的时候有个经验：规则要尽量简单、可预测，能用配置表达的别写死在代码里。因为路由规则一旦复杂到需要读代码才能理解，后面维护的人会非常痛苦，出问题也很难定位到底是哪条规则匹配错了。

2.3 和直接开 WebSocket 相比，多这一层值不值

这是很多人会纠结的问题：我直接在前端和后端之间开个 WebSocket 不就行了，为什么要多引入一个 RelayRouter？答案取决于你的系统复杂度。

如果你的系统只有一条流、一个消费方、逻辑简单，那确实没必要，直接开 WebSocket 最省事。但一旦出现下面这些情况，中间层的价值就体现出来了。

从表里能看出来，RelayRouter 的价值不是"能不能做到"，而是"做到之后好不好维护"。它把散落在各处的连接管理、心跳、重连、路由逻辑收敛到一个地方，短期看是多了一层，长期看是省了无数重复代码和排查时间。我的经验是，当你的系统里同时活跃的流超过三条，或者消费方超过两个，就该考虑上这一层了。

3. WebSocket 为什么是文本流推送的主力协议

3.1 从轮询到长连接的演进逻辑

要理解 WebSocket 为什么适合文本流推送，得先看看它替代了什么。最早的时候，前端想知道后台有没有新数据，用的是轮询：每隔几秒发一次请求问"有数据吗"。这个方式简单粗暴，但问题很明显——大部分请求都是空手而归，浪费带宽和服务器资源；而且数据产生的时刻和前端拿到的时刻之间有个延迟，最快也要等一个轮询周期。

后来有了长轮询，前端发一个请求，服务器 hold 住不返回，直到有数据或者超时才返回。这比定时轮询好一些，但每次拿到数据后还得重新发请求，连接反复建立销毁，开销依然不小。

WebSocket 的思路完全不同：一次握手之后，连接就一直保持着，双方随时可以往对方那边发数据，不需要每次重新建立连接。对于文本流这种"数据不定时产生、需要尽快送达"的场景，这个特性几乎是量身定做的。数据一产生就能立刻推出去，延迟可以做到毫秒级，而且没有反复建连的开销。

3.2 WebSocket 在文本场景下的几个关键特性

WebSocket 有几个特性特别契合文本工作流，值得单独拎出来说。

首先是全双工。连接建立后，前端和后端可以同时发数据，互不阻塞。这在交互式文本场景里很有用，比如用户一边输入新的指令，模型一边推送上一轮的生成结果，两边互不干扰。

其次是消息边界清晰。WebSocket 是基于消息的，每一帧就是一个完整的消息，不像 TCP 那样是字节流需要自己切分。对于文本来说这省了很多事，你发一条 JSON，对面收到的就是一条完整的 JSON，不用自己处理粘包拆包。

第三是协议开销小。握手阶段有点开销，但连接建立之后，每一帧的头部开销很小，比 HTTP 每次都要带一堆 header 划算得多。对于高频的小文本消息，这个优势很明显。

第四是浏览器原生支持。前端不用引入额外的库，直接用浏览器自带的 WebSocket API 就能用，这对前端来说门槛很低。

3.3 什么时候 WebSocket 反而不如 SSE 合适

WebSocket 虽好，但不是所有文本推送场景都该用它。有一个经常被忽略的替代方案是 SSE（Server-Sent Events）。SSE 也是长连接，但它是单向的——只能服务器往客户端推，客户端不能通过这条连接往回发。

如果你的场景是纯推送，比如后台任务进度、日志流、模型生成结果的单向输出，那 SSE 其实更合适。原因有几个：SSE 基于普通 HTTP，走的是标准端口和标准协议，穿透各种中间层更省心；SSE 自带断线重连机制，浏览器会自动重连，不用自己写；SSE 的实现比 WebSocket 简单得多，服务端就是保持一个 HTTP 响应不关闭，持续往里写数据。

反过来，如果你的场景需要双向通信，比如用户要能随时打断生成、发送新的指令，那 WebSocket 更合适。所以选型的时候先问自己一句：这条连接需要双向吗？不需要的话，SSE 往往是更省事的选择。很多团队一上来就用 WebSocket，结果发现根本用不到双向能力，白白增加了复杂度。

4. 把文本流跑起来：从后端推送到前端消费的完整链路

4.1 后端推送的几种实现路径

后端要往 WebSocket 连接里推数据，实现方式取决于你用什么技术栈。这里说几种常见的路径。

如果你用的是 Django，原生是不支持 WebSocket 的，因为 Django 的设计是同步的请求-响应模型。要在 Django 里做 WebSocket，通常要引入 Channels 这个库，它把 Django 的异步能力补齐了，让你能写消费者（consumer）来处理 WebSocket 连接。Channels 的核心概念是 channel layer，它负责在不同的进程之间传递消息，这样你的后台任务进程才能把数据推给持有 WebSocket 连接的进程。

如果你用的是 FastAPI 或者 Node.js，那 WebSocket 支持是原生的，写起来直接得多。FastAPI 里一个@app.websocket装饰器就能定义一个端点，Node.js 里用ws库几行代码就能跑起来。

还有一种路径是用消息队列做中转。后台任务把数据丢进 Redis 的 pub/sub 或者 RabbitMQ，WebSocket 服务订阅这些频道，收到消息后再推给对应的连接。这种方式解耦得最彻底，后台任务完全不用关心有多少个 WebSocket 连接，扩展性最好，但架构也最复杂。

选哪种取决于你的团队技术栈和系统规模。小项目直接在后端进程里推就行，大项目建议走消息队列中转，中间状态用 Redis 缓冲。

4.2 前端消费文本流的代码骨架

前端这边，消费 WebSocket 文本流的核心就是监听onmessage事件，拿到数据后更新界面。但真正写好有几个细节要注意。

const ws = new WebSocket('wss://your-host/stream'); ws.onopen = () => { console.log('连接已建立'); // 建立后可以发送身份认证或订阅指令 ws.send(JSON.stringify({ type: 'subscribe', channel: 'doc-123' })); }; ws.onmessage = (event) => { const msg = JSON.parse(event.data); if (msg.type === 'chunk') { // 追加文本片段 appendText(msg.content); } else if (msg.type === 'done') { finalize(); } else if (msg.type === 'error') { handleError(msg); } }; ws.onclose = () => { console.log('连接关闭，准备重连'); scheduleReconnect(); }; ws.onerror = (err) => { console.error('连接出错', err); };

这段代码看着简单，但有几个坑。第一，onmessage里拿到的event.data是字符串，如果后端发的是 JSON 就得 parse，parse 失败要有兜底，不然一条坏消息能把整个处理逻辑搞崩。第二，文本片段追加的时候要考虑渲染性能，如果一秒来几十条消息，每条都触发一次 DOM 更新会卡，通常要做一个缓冲，攒一小批再统一渲染。第三，onclose里一定要有重连逻辑，而且重连要加退避，不能一断开就疯狂重试，那样会把服务器打垮。

4.3 消息格式设计：让文本流可扩展

消息格式设计是个容易被忽视但影响深远的事。一开始可能只想着传文本内容，但很快你就会发现还需要传状态、传错误、传元数据。如果一开始没设计好，后面就是不断地打补丁。

我的建议是统一用一个带type字段的 JSON 结构，所有消息都走这个格式。比如：

{ "type": "chunk", "seq": 42, "content": "这是文本片段", "timestamp": 1700000000000 }

type用来区分消息种类，seq是序号用来检测丢包和乱序，content是实际内容，timestamp用于调试和排序。这个结构简单但够用，后面要加字段也不影响老客户端。

序号这个字段特别值得强调。文本流最怕的就是丢片段或者乱序，用户看到的内容就断了或者错位了。有了序号，前端就能检测出"我收到了 41 和 43，缺了 42"，然后主动请求补发或者提示用户。没有序号的话，丢了都不知道丢了。

5. 心跳、重连、丢包：文本流稳定性的三个硬骨头

5.1 心跳机制为什么不能省

WebSocket 连接建立之后，如果长时间没有数据往来，中间的网络设备（路由器、负载均衡、防火墙）可能会认为这条连接已经没用了，悄悄把它断掉。而两端可能都不知道连接已经断了，还在傻等。这就是所谓的"连接但不接受信息"的典型症状——前端以为连着，后端以为连着，实际上中间早就断了。

心跳机制就是解决这个问题的。原理很简单：客户端或者服务端定期发一个很小的消息（ping），对方收到后回一个（pong）。只要心跳还在正常往来，就说明连接是活的。如果连续几个心跳周期都没收到回应，就判定连接已死，主动关闭并重连。

心跳间隔的设置有个权衡。太短了浪费资源，太长了发现断线不及时。经验值一般在 15 到 30 秒之间。如果你们的网络环境比较复杂，可以适当缩短到 10 秒。另外要注意，心跳消息本身要足够小，别搞个几百字节的 JSON，那样心跳本身就变成负担了。

let heartbeatTimer = null; let lastPong = Date.now(); function startHeartbeat(ws) { heartbeatTimer = setInterval(() => { if (Date.now() - lastPong > 45000) { // 超过三个周期没收到 pong，判定断线 ws.close(); return; } ws.send(JSON.stringify({ type: 'ping' })); }, 15000); } // 收到 pong 时更新 lastPong

5.2 断线重连的正确姿势

重连这件事，写对了不难，写错了很坑。最常见的错误是无脑重连：一断开就立刻重连，失败了立刻再试，结果服务器一抖动，成千上万个客户端同时疯狂重连，直接把服务器打挂。这叫重连风暴。

正确的做法是加退避。第一次断开等 1 秒重连，失败了等 2 秒，再失败等 4 秒，以此类推，直到一个上限比如 30 秒。这样即使服务器短暂不可用，客户端的重连请求也是分散开的，不会形成尖峰。

let retryDelay = 1000; const MAX_DELAY = 30000; function scheduleReconnect() { setTimeout(() => { connect(); retryDelay = Math.min(retryDelay * 2, MAX_DELAY); }, retryDelay); } // 连接成功后重置 function onOpen() { retryDelay = 1000; }

还有一个细节是重连之后的状态恢复。如果断开期间有数据产生，重连后怎么补上？这就要靠前面说的序号了。前端重连后告诉后端"我最后收到的序号是 42"，后端从 43 开始补发。没有这个机制的话，断开期间的数据就永久丢了。

5.3 丢包和乱序的检测与补救

WebSocket 底层是 TCP，理论上不会丢包也不会乱序。但实际系统里，"丢"往往发生在应用层：比如后端推的时候连接刚好断了，这条消息就没发出去；或者前端处理消息的时候抛异常了，这条消息就被跳过了。

检测的手段就是序号。前端维护一个期望序号，每收到一条就比对，发现跳号就说明中间丢了。补救的方式有两种：一种是前端主动请求补发缺失的序号区间，另一种是后端在重连时根据前端上报的最后序号自动补发。前者实时性好但实现复杂，后者简单但依赖重连。

乱序在单条 WebSocket 连接里基本不会出现，但如果你的数据经过了消息队列中转，多个消费者并行处理，就可能乱序。这时候序号同样能派上用场，前端按序号排序后再渲染就行。

6. 实战中那些文档不会告诉你的坑

6.1 代理和负载均衡对长连接的干扰

WebSocket 连接要经过很多中间层：CDN、负载均衡、反向代理。这些中间层很多是为短连接设计的，对长连接支持不好。最常见的问题是空闲超时——代理觉得这条连接太久没数据了，直接掐断。而你的心跳间隔如果比代理的超时时间还长，就会出现"心跳还没发，连接已经被掐了"的情况。

解决办法是让心跳间隔小于中间层的最短超时时间。具体是多少得看你的部署环境，一般负载均衡默认空闲超时是 60 秒，那心跳设 30 秒以内就比较安全。另外有些代理需要显式配置才支持 WebSocket 的协议升级，这个在部署的时候要确认，不然连接根本建不起来。

6.2 多实例部署下的连接归属问题

当你的服务部署了多个实例，前面挂了负载均衡，问题就来了：用户 A 的连接可能落在实例 1 上，但产生用户 A 数据的后台任务可能跑在实例 2 上。实例 2 想推数据给用户 A，但它手里没有用户 A 的连接，推不了。

这是多实例部署下最典型的坑。解决办法是引入一个共享的消息中转层，比如 Redis 的 pub/sub。实例 2 把数据发到 Redis 的某个频道，所有实例都订阅这个频道，实例 1 收到后发现"这是用户 A 的数据，而用户 A 的连接在我这"，就推出去。这样不管数据在哪个实例产生，都能送到持有连接的那个实例。

这个方案的关键是频道设计。可以按用户 ID 分频道，也可以用一个全局频道然后靠消息里的目标标识来过滤。前者更高效但频道多，后者简单但每个实例都要处理所有消息。用户量大的话建议按用户分片，比如按用户 ID 的哈希值分成若干频道。

6.3 前端渲染性能：别让高频消息拖垮页面

文本流的特点是消息可能非常密集，尤其是模型快速生成的时候，一秒几十条很正常。如果每条消息都触发一次 DOM 操作，页面很快就会卡顿。

优化的思路是批量渲染。用一个缓冲区把收到的文本片段先攒起来，用requestAnimationFrame或者定时器每隔一小段时间（比如 50 毫秒）统一渲染一次。这样 DOM 操作的频率就降下来了，视觉上依然是流畅的。

let buffer = ''; let scheduled = false; function appendText(text) { buffer += text; if (!scheduled) { scheduled = true; requestAnimationFrame(() => { document.getElementById('output').textContent += buffer; buffer = ''; scheduled = false; }); } }

还有一个细节是自动滚动。文本不断追加，用户希望看到最新的内容，所以要自动滚到底部。但如果用户手动往上滚去看历史内容了，你就不能强制把他拉回底部，否则体验很糟。判断逻辑是：只有当滚动条本来就在底部附近时，才自动滚动。

6.4 连接数暴涨时的资源控制

每个 WebSocket 连接在服务端都要占资源：一个 socket、一些内存、可能还有心跳定时器。连接数一多，资源消耗就很可观。一个实例能撑多少连接，取决于你的内存和文件描述符限制。

文件描述符是个容易被忽略的点。Linux 默认的单进程文件描述符上限通常是 1024，每个 WebSocket 连接占一个，那超过 1024 个连接就建不起来了。要支持更多连接，得调高这个限制，同时也要调高系统的整体限制。

另外心跳定时器如果每个连接一个，连接多了定时器也很多。更好的做法是用一个全局的定时器，每隔一段时间遍历所有连接检查一次，而不是每个连接单独开定时器。这样定时器数量是固定的，不随连接数增长。

7. 把 RelayRouter 放进真实文本工作流的几种姿势

7.1 长文档生成场景的流式编排

长文档生成是文本工作流里最典型的流式场景。用户提交一个主题，模型开始生成，内容一段段推给前端。这个场景里 RelayRouter 要做几件事。

首先是分片路由。模型输出的 token 流可能非常细碎，直接推给前端太频繁，RelayRouter 可以做一个缓冲，攒成有意义的句子或段落再推。其次是多路分发，同一份生成结果可能既要推给前端展示，又要写进数据库存档，还要发给审核服务检查，RelayRouter 把这些下游都接上，上游只管发一次。

还有一个细节是生成中断的处理。用户可能中途取消生成，这时候 RelayRouter 要能收到取消信号，通知模型停止，同时把已经生成的部分保存下来，而不是直接丢弃。这个"部分结果"在很多场景下是有价值的。

7.2 后台任务进度推送的轻量方案

后台任务进度推送是另一个高频场景，而且它比长文档生成简单得多，往往不需要 WebSocket 这么重的方案。如果只是单向推送进度，SSE 就够了，甚至用轮询都能接受。

但如果任务很多、进度更新很频繁，WebSocket 加 RelayRouter 的组合就更合适。RelayRouter 在这里的价值是统一管理所有任务的进度流，前端只需要连一个连接，就能订阅多个任务的进度，不用为每个任务单独开连接。任务完成后，RelayRouter 负责关闭对应的流，前端收到完成消息后更新界面。

这个场景里有个实用技巧：进度消息要做节流。一个任务可能每秒更新几十次进度，但前端根本不需要这么高的刷新率，每秒更新两三次就够了。RelayRouter 可以在中间做节流，把高频的进度更新合并成低频的推送，既省带宽又省前端渲染开销。

7.3 多步骤 Agent 工作流的阶段衔接

多步骤 Agent 工作流是最复杂的场景，因为它涉及多个处理阶段的衔接。一个任务可能经过检索、摘要、改写、校对四个阶段，每个阶段的输出是下一个阶段的输入，同时每个阶段的中间结果都要反馈给用户。

RelayRouter 在这里扮演的是"阶段调度器"的角色。它知道当前任务处于哪个阶段，知道这个阶段的输出该往哪送。阶段之间的数据传递可以通过 RelayRouter 内部完成，用户看到的是一条连续的流，实际上背后经过了多次路由和转换。

这个场景的难点是错误处理。如果某个阶段失败了，整个工作流怎么办？是重试当前阶段，还是回退到上一个阶段，还是直接终止？这些策略要在 RelayRouter 的路由规则里定义清楚。我的经验是，每个阶段都要有独立的超时和重试配置，不能用一个全局配置糊弄，因为不同阶段的耗时和失败率差别很大。

8. 选型与落地时我个人的几条判断标准

聊了这么多原理和实现，最后说几条我在实际项目里总结出来的判断标准，都是踩过坑之后才想明白的。

第一条，先问"这条流需要双向吗"。不需要双向就别上 WebSocket，SSE 更省事。很多团队一上来就 WebSocket，结果发现根本用不到双向能力，白白增加了服务端复杂度。双向能力只有在用户需要实时干预生成过程的时候才真正必要。

第二条，流的数量超过三条再考虑 RelayRouter。少于三条的时候，直接管理连接的成本比引入中间层还低。中间层是有维护成本的，它自己也会出问题，别为了架构好看而过早引入。

第三条，心跳间隔一定要小于中间层的最短超时。这个坑我踩过不止一次，表现是连接莫名其妙就断了，排查半天才发现是代理把空闲连接掐了。部署前一定要确认清楚链路上所有中间层的超时配置。

第四条，序号字段从第一天就要有。别觉得刚开始简单就不加，等到发现丢消息的时候再补，前端后端都要改，成本高得多。序号是文本流可靠性的基石，早加早省心。

第五条，多实例部署必须配消息中转。单实例的时候怎么推都行，一旦上了多实例，连接归属问题立刻就会暴露。Redis pub/sub 是最轻量的方案，够用就别上更重的东西。

第六条，前端渲染一定要做批量。这是纯性能问题，但直接影响用户体验。高频消息不批量渲染，页面必卡，没有例外。

这套东西说到底，核心就一句话：实时 AI 的价值不在于界面多炫，而在于它逼着我们把数据流这件事想清楚。Gemini Live Avatar 只是把这个问题用最显眼的方式摆到了台面上，而 RelayRouter 加上 WebSocket 这套组合，是解决文本工作流里同类问题的一个务实答案。想清楚你的流有几条、往哪走、断了怎么办，剩下的就是按部就班地实现和调优了。