企业官网建设流程全解析

实时 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，结果维护成本翻倍。判断标准其实很简单：

实时 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 的核心是一张路由决策表。这张表决定了"什么消息走什么通道"。我的设计大致如下：

这张表不是拍脑袋定的，是根据每类数据的"丢失代价"和"延迟敏感度"两个维度权衡出来的。控制信令丢了整个会话就乱套，所以优先级最高且不重试（重试反而可能造成状态错乱）；后处理任务丢了可以慢慢补，所以走低优先级通道。

4.3 故障转移时的状态一致性

路由层最难的部分不是"切通道"，而是"切完之后状态还对得上"。举个具体场景：用户正在说话，WebSocket 突然断了，RelayRouter 把文本输入切到 HTTP 备用通道。这时候问题来了——断线前那半句已经通过 WebSocket 发出去的话，服务端收到了吗？如果收到了，切到 HTTP 后会不会重复处理？

我的解法是给每条消息带一个幂等键（idempotency key），由session_id + seq组成。服务端维护一个近期已处理消息的滑动窗口，收到重复键就直接丢弃。这样无论消息走哪条通道、重试几次，业务层都只处理一次。

这个机制听起来简单，但它是整个故障转移能成立的前提。没有幂等保证的故障转移，等于给系统埋雷。

5. 实测中暴露的问题与排查链路

5.1 连接"看着是好的"但消息发不出去

这是我最开始遇到的最诡异的问题。监控面板显示连接状态是OPEN，心跳也在正常收发，但业务消息就是发不出去，或者发出去没回应。

排查链路是这样的：

1. 先看bufferedAmount，发现它一直在涨，说明消息堆积在发送缓冲区。
2. 再看服务端日志，发现服务端根本没收到这些消息。
3. 怀疑是中间网关的问题，抓包发现 TCP 层有重传，但应用层数据没上去。
4. 最终定位：网关的空闲超时是 30 秒，而我的心跳间隔设成了 45 秒，连接被网关悄悄断了，但客户端和服务端都没感知到。

修复就是把心跳间隔压到 20 秒，并加上连续未回应判定。这个问题让我彻底明白：心跳间隔必须小于链路上最短的那个空闲超时，不能想当然。

5.2 文本乱序导致的"答非所问"

第二个坑是文本乱序。实时通道里，音视频和文本混在一起，如果应用层不做序号管理，文本可能后发先至。表现出来就是 AI 的回答对不上用户的问题。

排查过程：

1. 在消息信封里加上seq，发现收到的文本seq确实不是递增的。
2. 定位到是 RelayRouter 在切换通道时，两条通道的消息合并顺序没对齐。
3. 修复方案是在路由层加一个重排序缓冲区，按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 那种炫酷的数字人，底层跑的还是这些朴素的工程原则——把连接管好，把状态对齐，把该走的路走对，剩下的交给渲染层去表演就行了。