Gemini Live Avatar 第一次出现在我屏幕上时我的第一反应和多数人一样视频里的虚拟人能跟我眼神接触了。但冷静下来真正让我觉得有工程挑战的不是那个动画头像而是它背后那条在没有头像的年代里就应该做对、却大多数团队都没做对的文本工作流。把聊天变成视频听上去是把交互界面从文本升级到音视频但在系统架构层面这更像是在原来文本链路的外围套了一层采集与渲染壳。聊天界面改成视频用户感受到的是实时AI可系统内部依然是音频转文本、文本进模型、模型出文本、文本转语音。Avatar只是把最后一步从语音扩展成了带口型的视频流。所以如果你问我实时AI的门槛在哪里我的答案不是视频渲染而是文本工作流。这篇文章会从Gemini Live Avatar这个具体例子切入聊一聊为什么文本工作流是实时AI的真正主角以及RelayRouter在这种工作流里究竟站在什么位置、能解决哪些实际问题。1. 实时AI的“视频皮”和“文本骨”1.1 Gemini Live Avatar 演示很炫但奥妙不在视频大概的场景很多人应该都见过用户在手机前说话屏幕里的虚拟形象同时做出表情和口型还能被用户中途打断然后自然接话。表面上看这确实是比普通聊天更像“人类对话”的交互方式。但只要你拆过这类系统的数据流就会发现几乎所有“智能”都发生在文本层面而不是视频层面。一次典型的交互大致是这样的麦克风采集到原始音频经过语音识别模块转成文本这段文本会被用来做意图识别、提取关键参数然后和当前会话的上下文合并打包成完整的提示词发送给大语言模型模型返回一段回复文本这段文本再被送给语音合成模块生成音频顺便驱动虚拟形象的口型和表情。Avatar只是在“模型出文本”这一步之后多接了一个视觉渲染模块真正决定“下一句怎么说”的还是那段回复文本。视频渲染部分当然有技术难点但它是相对独立的一块口型同步、表情控制、视频编码、弱网传输。这些能力在直播、游戏、视频会议领域已经被打磨了很多年不是实时AI独有的新问题。可文本工作流不一样它横跨语音识别、语义理解、记忆管理、模型调度、工具调用、结果校验等多个环节而且这些环节还不是简单的先后关系经常是并行、条件分支、回退重试交织在一起。哪一个环节没有做对用户在视频里看到的都是同一个结果AI开始说胡话。1.2 被高估的视频渲染被低估的文本编排我见过不少做实时AI演示的团队Demo花了很多精力在虚拟资产、口型效果和流媒体推流上但一进入多轮对话问题立刻暴露用户上一句话还在聊天气下一句话中间插了一句“等等改成周五”AI就忘了前面在聊什么或者两个AI Agent同时要更新会话记忆结果后返回的那个把先返回的覆盖了再或者某次模型响应慢了一点整个通话就卡在那里没有超时降级也没有任何过渡话术。这些问题和视频渲染一点关系都没有。它们全部来自文本工作流的编排缺陷。在传统聊天机器人里文本流是简单的一进一出问题还不明显但到了实时AI场景用户会随时打断、随时修正多个任务可能并行推进系统可能同时开着多个子Agent去查航班、订餐厅、查天气。这个时候“消息如何从识别结果变成模型输入、从模型输出变成下一个Agent的输入”就成了一件需要专门设计的事。我并不是说视频渲染不重要。而是说如果文本工作流不稳Avatar渲染得再精致用户聊两句也会觉得“这AI有点傻”。反过来只要文本工作流足够稳哪怕虚拟形象只是个简单的圆球体验也会很流畅。这就好比你买手机屏幕再好看系统一用就卡你也会退货。文本工作流就是那个系统Avatar只是那块屏幕。1.3 RelayRouter的名字为什么出现在这里在折腾过几轮实时AI项目之后我把相当一部分注意力放到了文本消息的路由层。这个路由层处理的不是网络层的转发也不是消息队列的异步任务而是“会话语义下一条文本消息该去找哪个组件”。我把这套组件沉淀下来取了一个很直白的名字RelayRouter——文本工作流里的消息中继与路由。RelayRouter 的定位非常明确它不负责语音识别也不负责生成回复它负责让正确消息在正确时间抵达正确的处理节点。它像一个站在业务逻辑和底层模型之间的调度员知道用户当前的会话状态知道哪条消息该去调用意图识别、哪条消息该去触发工具调用、哪条消息该被暂停等待其它任务完成。很多人一听说“路由”第一反应就是消息中间件但实际上两者的责任边界并不一样。后面的章节我会专门展开讲。2. 一条文本消息在实时AI里的完整旅程2.1 从语音转写到意图分发消息一出生就要被分流先看一个最简单的实时交互用户说“帮我订一间周五晚上的双人餐厅”。语音识别模块可能输出一串带候选结果的文本比如“帮我订一间周五晚上的双人餐”或者“帮我订一件周五晚上的双人餐厅”。这时系统已经不能只把这段文本原封不动丢给大模型因为后面还站着好几个组件安全过滤器要看有没有敏感词意图识别器要判断这是“订餐厅”而不是“订酒店”实体提取要抓出“周五晚上”“双人”这些参数上下文管理要检查之前有没有聊过别的日期。这些组件之间是有依赖的。理想情况下安全过滤和意图识别可以并行因为它们互不影响但意图识别一旦得出“订餐厅”的结论接下来才能决定要不要挂上“餐厅搜索”这个工具。如果你在每个环节之间都用硬编码的 if-else 去串代码会变得极其难以维护而且每加一个能力就要改一次主流程。更麻烦的是语音识别经常会给出多个候选文本系统可能要先等待一小段静音来判断用户是不是说完了接着再决定用哪个候选结果进入后续流程。这个“决定”本身就是一种路由。RelayRouter 的做法是把这类分流逻辑写成路由规则。消息进入路由器后先按规则做一次“预路由”比如并发触发 safeCheck 和 intentDetect等到这两个结果都回来后再根据意图字段决定走 restaurantAgent 还是 hotelAgent。每条规则都可以独立修改不需要动主流程。这才是实时AI文本工作流里最基础的需求。2.2 多Agent协作时的读写冲突与会话状态真正让事情复杂起来的是会话状态。单个文本请求串行处理时状态管理非常简单拿上一轮的上下文拼上这轮输入发给模型得到输出存回上下文。但用户不会总是顺序说话。他可能同时询问两个事项也可能中途打断AI的回答。系统为了提升响应速度通常会启动多个Agent并行处理不同子任务。比如用户说“帮我订周五晚餐顺便看看周六的天气”这个请求里至少有“订餐厅”和“查天气”两个子任务。两个Agent并行处理表面上是好事但会话状态只有一份。如果订餐厅Agent先跑完把“用户要订周五晚8点双人餐”写回上下文查天气Agent后跑完它只知道要查周六天气写回上下文时很可能把之前订餐记录覆盖掉。这种情况在实时AI里非常常见因为文本消息之间的时序不再是单纯的先后顺序而是并发交错。RelayRouter 在处理这类问题时会给每个会话维护一个“消息代际”。同一轮用户消息派发出去的所有子任务共享同一个代际ID。只有当这个代际里所有子任务都返回了才允许把它们的写回结果合并再推进到下一个代际。也就是说同名写入冲突在路由层就被拦截不是等到下游模型发现上下文丢了才察觉。这个方法听起来很朴素但在没有路由层的系统里你通常得靠程序员小心翼翼地在回调里加锁改一处崩两处。2.3 超时、熔断与降级实时的代价由文本层承担实时语音交互对延迟的口味非常严格。用户话说完模型的首包响应最好在500毫秒到1秒内出来否则就会感觉“卡”。但大模型的单次推理时间很难保证高峰期可能突破1.5秒。这时你不可能让用户对着一个沉默的虚拟形象干等常规解法是走降级路径先用一个更快的轻量模型生成一句过渡回应比如“稍等我马上帮你查”同时后台继续调重量级模型生成真正答案等答案回来后再替换显示。这套降级逻辑如果写在业务代码里会非常难缠因为你要同时处理“过渡句已发出”和“最终答案回来”两个消息的时序。RelayRouter 可以把降级规则做成路由配置主模型目标超时200毫秒未返回就自动把原始文本消息转发给备用模型备用模型也无响应则直接进入预先定义的回复模板节点。除了超时还有熔断如果主模型连续三次超时就进入熔断状态五分钟内所有会话的慢模型请求全部改走快速通道。这些能力说到底是“文本路由的容错策略”。视频渲染层不会关心你调的是哪个模型、等了多久它只知道收到文本就渲染。所以实时AI的体感质量很大程度取决于文本层能不能在模型抖动时依然稳定地把一条消息送到正确的出口。3. RelayRouter 的职责边界它解决的是“业务路由”问题3.1 三个核心概念Input、Output、Route要理解 RelayRouter核心就是三个概念输入消息、输出目标、路由规则。输入消息是一条带有元信息的文本比如来源是ASR、WebSocket、客户端提交还是工具回调消息本身可能是用户原话也可能是某个Agent的处理结果。输出目标是下游节点包括不同的大语言模型、Agent实例、工具执行器、知识库检索、文本后处理模块等。路由规则负责决定“这条文本该去哪个目标”。我习惯把消息设计成和HTTP请求类似的格式分成Header和Payload。Header里放会话ID、消息ID、消息类型、优先级、时间戳、来源标识Payload放真正的文本内容。这样的好处是路由规则可以直接读取Header不需要解析文本本身。比如“typeuser”的消息进入用户输入处理链“typetool_result”的消息进入Agent上下文合并链“priorityhigh”的消息可以插队。Payload则保持为纯文本方便下游任何组件消费。这套设计非常轻轻到你完全可以在一个服务里实现不必引入复杂的编排引擎。它解决的问题也不是“十万级消息吞吐”而是“会话级别的文本流控制”。你可以把它想象成一个非常聪明的分拣中转站每进来一个包裹看一眼标签就往对应的传送带上放。3.2 RelayRouter vs 消息队列 vs API网关很多做后端的人一听到“路由器”会立刻想到API网关或消息队列。这三者看起来都能“把消息从A送到B”但实际解决的问题很不一样。我做了一张对比表方便你一眼看清边界维度消息队列如Kafka/RabbitMQAPI网关RelayRouter核心能力异步解耦、削峰填谷、消息持久化外部协议接入、鉴权、限流、路由到后端服务业务语义路由、会话状态感知、条件分支/降级/重试关注层级传输通道服务边界会话与业务逻辑是否感知模型/Agent不感知不一定感知深度感知典型问题一条消息进了队列谁消费、怎么排序请求进到服务后会话里该怎么办消息该调用哪个Agent要不要等另一个结果可不可以插队实际上RelayRouter 完全可以构建在消息队列之上。上游ASR把文本写到KafkaRelayRouter作为消费者读出来按业务规则处理后再决定把消息投递给哪个下游组件。它们不是替代关系而是分工队列负责“不丢”网关负责“进得来”RelayRouter负责“发得准”。我写这篇文章的重点是很多团队容易跳层有了消息队列就觉得业务语义路由也解决了于是把所有判断逻辑堆在消费者代码里最后变成一团意大利面。你需要的是一个独立的、以会话为中心的路由层。3.3 为什么叫 Relay看一次完整交互里的消息接力“Relay”这个词来自接力赛。实时AI里一条用户语音从“进入系统”到“变成输出视频”本质上就是一段文本接力第一棒是ASR转写出的文本第二棒是意图识别和实体提取产出的结构化结果第三棒是上下文拼接后形成的完整提示词第四棒是模型输出的答复文本。每一棒都由不同组件处理组件之间靠消息传递交接而 RelayRouter 就是那个站在接力点旁的裁判决定下一棒什么时候出手、交给谁、前一棒是否作废。我举个多轮修正的例子。用户先说了“帮我订周五晚上七点的餐厅”几秒后又说“算了改成六点”。ASR会产出两条文本片段如果不做路由处理系统会把它们当成两个独立请求第一个请求已经发起餐厅搜索第二个请求又要重新订一次。但用户的真实意图并不是订两次而是修正第一次。RelayRouter 在发现第二条文本携带了“改了/算了/重新”这类修正信号后可以先把上一条未完成的消息标记为废弃再把第二条文本合并到原上下文只追加一个“用户改时间为六点”的事件然后继续交给餐厅Agent。没有这种路由语义AI就会傻乎乎给用户订两个餐位。这段接力过程完全发生在文本层面和视频形象无关。所以我说Avatar只是接力赛的最后一段赛道而RelayRouter守着每一棒交接。这也是文章标题想强调的实时AI不只是把聊天变成视频真正困难的是把文本工作流组织成一场不乱的接力赛。4. 在真实项目里用 RelayRouter 搭建文本工作流4.1 最小落地示例从订阅消息到动态路由RelayRouter 的设计不需要依赖任何特定框架。为了说清楚落地方式我写了一个极简Python示意代码它表达了核心思想注册一组“条件到处理函数”的映射然后让消息按顺序匹配条件命中哪个就交给哪个处理函数。class RelayRouter: def __init__(self): self.routes [] self.default_handler None def add_route(self, condition, handler): self.routes.append((condition, handler)) def set_default(self, handler): self.default_handler handler async def route(self, message): for condition, handler in self.routes: if condition(message): return await handler(message) if self.default_handler: return await self.default_handler(message) raise ValueError(fNo route matched message: {message.header})实际项目里我通常会在入口处比如WebSocket收到文本消息调用它async def on_user_text(header, payload): msg TextMessage(headerheader, payloadpayload) result await relay_router.route(msg) # result 可能是文本、也可能是一组工具调用指令 await send_to_avatar(result)这个最小版本足够跑通一个Demo但生产中还需要加上超时、重试、中间结果缓存。我会把每条消息的header.trace_id打印到结构化日志里方便排查“这条消息到底走了哪些节点”。这也是一个很实用的排错技巧。4.2 规则配置意图、会话状态、优先级如何组合路由规则最好不要写到代码里而是做成可配置条件。我用JSON作为规则描述简单、可解析、适合中小团队。下面是一组实际使用的规则片段{ routes: [ { id: weather_route, condition: payload.intent weather session_state ! busy, target: weather_agent, timeout_ms: 800 }, { id: booking_fast_route, condition: payload.intent booking header.priority high, target: fast_llm, timeout_ms: 200 }, { id: fallback_route, condition: true, target: default_llm, timeout_ms: 1500 } ] }这套配置的核心是条件表达式。你可以从消息Header取会话ID从Payload取意图类型甚至可以从Redis里取一个“当前会话是否busy”的状态放进session_state。使用时RelayRouter 按顺序从上往下匹配命中就停止。这里有一个很容易被忽略的点规则顺序是有意义的。更具体的规则要放在前面兜底规则放在最后否则所有消息都会命中兜底规则后面写什么都没意义。我还建议把“优先级”做成一个头字段。当用户在说话中途打断AI时WebSocket会收到一个“interrupt”事件RelayRouter 看到priorityhigh会先把当前正在处理的低优先级消息暂停或作废再处理新的高优先级消息。这个插队机制只靠代码判断会特别绕但放到路由配置里就像给快递贴了个“加急”标签一样自然。4.3 面向Gemini Live Avatar类场景的接入调整如果你要接的是类似Gemini Live Avatar这种多模态实时对话接入点在两个地方上行是ASR结果到RelayRouter下行是RelayRouter输出到TTS和视频渲染。上行方面ASR输出往往不是一句话而是一组带时间戳的候选片段。RelayRouter可以把这些片段累积到“当前语音回合”里等到检测到静音或ASR返回final标志才把这轮完整文本作为一条消息发出。这个缓冲逻辑放在Router里比放在ASR回调里更合理因为后续的意图识别和上下文合并需要的是完整回合而不是中间片段。下行方面大模型的输出是流式token如果每个token都直接路由给TTS语音会非常生硬因为TTS需要按句子或短语切分才有好的韵律。RelayRouter可以设置一个聚合策略按标点把token流切成短语每个短语作为一条独立消息发给TTS同时保留一个“完整回答”的消息给Avatar的口型动画使用。这样既不牺牲首包延迟又不会让虚拟形象看起来像在做木偶式嘴巴机械开合。另外要处理的问题是打断。用户一旦开口说话上行ASR会立刻产出新文本RelayRouter需要把这个信号变成“中断”消息通知下行TTS停止当前播放、通知视频渲染恢复为聆听状态并且把当前已经流式生成的回复标记为“被取消”。如果不做这个动作就会出现用户说话时Avatar还在继续张嘴的诡异画面。这种实时交互的细节十有八九都发生在文本消息的路由策略里而不是视频素材里。4.4 实测中容易踩的四个坑第一个坑是消息乱序。实时交互里同一个会话的多个请求可能经过不同的处理链路返回顺序和发送顺序不一致。你会看到模型先回答了一个较晚的问题或者上下文被一个早期的结果覆盖。最简单的解法是在RelayRouter里给每个会话维护一个自增序号所有下游返回都必须携带这个序号路由器只有确认序号连续才写入会话上下文。乱序消息先放到待处理队列不能直接往上下文里塞。第二个坑是上下文爆炸。多个Agent并行工作时每个Agent都想把自己检索到的内容追加到上下文很快就把模型窗口撑爆。我推荐的做法是在RelayRouter里单独维护一份“会话摘要”每次要发给大模型的提示词都不是完整历史而是摘要加当前消息。摘要可以由一个专门的Lightweight模型定期更新也可以直接用规则截断。这样路由规则的“target”就不是直接把消息转发过去而是在转发前先做一层上下文压缩。第三个坑是模型输出不可靠。路由规则里写“intent weather”但实际上游返回的可能是“intent Weather”或者“意图是天气”这时候后面就会找不到匹配规则。我在RelayRouter里加了一个轻量校验步骤路由后拿到处理结果先校验返回的字段是否符合约定schema不符合就重新路由到纠错节点。这一步也别做得太复杂只要保证进程不崩掉就行。第四个坑是条件表达式过多导致调试困难。规则越写越多时你很难知道一条消息到底没命中哪条规则。所以我们给每条消息都加了一个trace_id在规则匹配失败时记录未命中的条件和消息字段快照。线上排查问题时只要搜trace_id就能看到消息在路由层的完整决定过程。这个小投入比任何单元测试都管用。5. 如果只记住一条别让文本工作流拖住实时AI5.1 先梳理文本流再做视频皮从我自己的项目经验看做实时AI最容易犯的错误是温室里造车在理想网络条件下做Avatar演示一分钟对话看起来很漂亮一旦放到真实环境里低延迟、弱网、用户打断、模型超时全部涌过来文本工作流瞬间变成一团乱麻。原因是前期没有把文本流当做一个独立系统来设计。我强烈建议在动视频渲染之前先画一张文本消息时序图把用户从说话到看到回应的全过程拆开标注出每个环节的输入、输出、超时时间、失败降级路径。这张图画完之后你会发现绝大多数难点都在文本层而不是Avatar层。5.2 你现在就可以动手的三步如果你也想在自己的项目里引入类似RelayRouter的思路不妨按这个顺序来第一列消息类型。把实时场景里所有可能出现的文本消息列出来用户语音转写、系统指令、工具调用结果、上下文修正、打断信号、模型流式输出。每种消息都要知道从哪里来关键字段是什么。第二定义路由路径。给每种消息画出正常路径、超时路径、失败路径。比如用户语音转写要去“意图识别”和“安全过滤”工具返回结果要回“会话处理器”模型输出要发生“TTS”和“Avatar渲染”。这一步不需要写代码先用文档格子画清楚。第三把路径变成配置和代码。用RelayRouter这类路由组件把路径固化成规则然后从最简单的单一会话开始测试逐步加入多Agent并行、打断降级。每次加一条规则观察日志里的trace链路确认没有打乱已有流程。我现在做的所有实时AI项目都默认把RelayRouter这层放在最前面。它不解决智能问题但解决智能的稳定问题。就像电路里的电压稳定器没有它芯片再强也会频繁重启。如果你正准备把聊天升级成视频、把文本升级成实时语音我建议你先回去看一眼你的文本工作流经不经得起用户一句“等一下我改主意了”。经不起的话Avatar做得再真也没有用。