实时多模态Agent架构：全双工与级联管线对比及800ms延迟优化

我一直觉得实时多模态 Agent 是工程世界里看起来很近、做起来很远的东西。Demo 视频里Agent 能听能说还能中途接话感觉离真人不远了可真要自己从头搭一套全双工对话系统你会发现光是让听写——思考——说话这三件事在一个进程里转起来就已经能把人折腾到怀疑人生。尤其是当你把目标定成端到端延迟 800ms的时候每一个环节的每一毫秒都开始变得斤斤计较。这篇文章我打算把近期做一套实时多模态 Agent 的架构过程完整梳理一遍重点围绕两条技术路线——全双工和级联管线——做对比再拆一下 800ms 延迟目标背后的取舍逻辑。内容里会有状态机设计、流式链路的关键参数、以及我实际踩过的几个坑。如果你最近也在调研类似系统或者正准备从 Demo 走向可用的实时 Agent这篇应该能帮你省下不少弯路。1. 实时对话 Agent 的体验瓶颈到底在哪先说结论实时对话 Agent 的体验瓶颈从来不是模型能不能听懂、能不能答对而是从用户闭嘴到 Agent 开口中间隔了多久。这里的延迟感知非常微妙。排队等电梯、等网页加载你都能多忍几秒但跟人说话的时候超过 800ms 的沉默就已经会让对方觉得你是不是卡住了。真人对话的轮转速度大概在 200-500ms 之间而普通的按一下说话、放开发送式对讲机交互算上端点检测和网络请求动辄就是 2-4 秒体验差距一目了然。800ms 不是拍脑袋定的数字。心理学上对话中的响应间隙Response Gap研究加上语音交互产品多年积累的用户反馈基本都指向同一个区间500-800ms 是自然和迟钝的分界线。低于 500ms 会让人觉得有点抢话高于 800ms 就会让人明显感觉到延迟。所以我在做架构取舍的时候直接把 800ms 定为端到端延迟上限所有技术选型、组件划分、甚至网络传输方式都围绕这个数字展开。但这个 800ms 并不是模型推理时间这么简单。一条完整的实时对话链路里音频采集、语音活动检测VAD、语音识别ASR、大模型推理LLM、语音合成TTS、音频播放每一段都会产生延迟而且这些延迟是串联叠加的。任何一环做不到流式输出整个管道就会退化成录完-处理-播放的批处理模式延迟直接爆炸。所以这里就引出了两种架构思路一种是把识别、生成、合成按顺序串成一条级联管线简单直白另一种是像真人对话一样让音频和语义在多个环节间持续流动也就是全双工。两条路线我都实际搭过下面详细聊聊各自的设计逻辑和取舍。2. 全双工与级联管线两个架构流派的对决2.1 级联管线清晰直观但天花板有限级联管线是大多数人最先想到的方案也是最早一批语音助手采用的方式。它的数据流是单向的用户音频 - VAD 检测说话结束 - ASR 完整识别 - LLM 生成完整回复 - TTS 合成完整音频 - 播放每一步都在等前一步完全结束才启动所以逻辑上非常简单调试的时候也很直观——你能清楚地知道延迟发生在哪个环节。我最早做的一个语音助手原型就是这种结构那时候觉得够用就行结果一测端到端延迟稳定在 2.8 秒左右用户反馈像在跟一个反应很慢的客服说话。级联管线的天花板主要卡在两个地方。第一VAD 端点检测需要等待用户说完。所谓端点检测就是判断用户什么时候开始说话、什么时候说完。为了让识别结果完整VAD 通常会设置一个较长的静音超时比如 600-800ms只有连续这么长时间没有语音能量才判定为用户说完了。这个静音等待时间本身就消耗了近 800ms还没开始识别就已经占了预算。第二ASR 和 LLM 是严格串行的。用户说完 - ASR 把整句话转成文字 - LLM 拿到完整文字才开始生成。ASR 的尾部延迟、LLM 的首字延迟、TTS 的整句合成时间全部累加起来导致响应时间轻松超过 2 秒。即便你把每个组件都优化到极致级联架构也很难突破 1.5 秒的下限因为等待完整输入这个前提就是最大的时延来源。级联管线还有一个体验问题不支持打断。用户正在听回复中途想插一句不对我说错了这个新输入必须等到当前 TTS 播放完才能被处理。在真人对话里这属于根本没法忍的体验。不过我也要说句公道话级联管线并没有过时。在对延迟不敏感的场景比如异步问答、离线转写、知识库检索对话它的稳定性和可维护性反而更适合。因为每个环节的输入输出都是完整、确定的出了问题容易定位模型升级也互不影响。它适合作为正确性优先的基线方案。2.2 全双工让数据像水流一样双向流动全双工Full-duplex的思路是不要等用户说完而是边听边处理。音频一进来VAD 就持续监测语音边界ASR 开始做流式识别每识别出一段文字就立刻丢给一个调度器调度器决定什么时候该让 LLM 开始生成LLM 使用流式输出吐出第一句话的前几个 tokenTTS 就开始合成音频播放。同时系统还在监听用户的输入——哪怕 Agent 正在说话也能被新的语音打断。这听起来很美但实现难度是几何级上升的。核心难点在于状态同步。全双工系统里ASR、LLM、TTS 三个组件各自处于进行中或空闲中的状态而系统需要在某个时刻决定现在到底是该继续听、开始想、开始说还是被打断重新进入等待。这个决策必须足够快而且不能出错——比如 Agent 正在说话时把自己说话的声音识别成用户输入导致自我打断这就是最常见的一个坑后面会细说。全双工有一个核心工程概念流。传统 API 大多是请求——响应模式你发一整个音频文件过去等一整个文本回来。而流式 API 允许数据以 chunk块为单位持续传输。麦克风采集到 20ms 音频就立刻发给 VADASR 每稳定识别出一段文本就通过回调推送出来LLM 以 token 粒度输出TTS 按音频帧生成。整个系统从四段式接力赛变成了多段并行流水线。流水线并行带来的延迟收益是质的飞跃。用户说今天天气怎么样可能只说出了今天天三个字的时候ASR 已经产生了部分结果调度器已经开始预估意图等用户说完怎么样LLM 已经在生成今天晴气温 25 度的前几个词TTS 在第一版文字稳定后立刻开始合成今天晴的音频。用户听到的第一个字几乎只跟 LLM 首 token 延迟和 TTS 首帧延迟有关跟 VAD 的端点检测基本解耦了。当然全双工的代价也很明显系统复杂度高、组件之间的耦合深、流式模型版本的推理结果质量可能略低于非流式版本、并发和资源管理也更麻烦。所以全双工 vs 级联管线本质上不是谁比谁高级而是你的产品到底需不需要那种像真人一样的对话节奏。2.3 两种架构的横向对比对比维度级联管线全双工交互模式半双工一问一答全双工可打断、可插话端到端延迟通常 1500-3000ms可优化到 600-1000ms首 token 响应需等完整输入边听边出结果打断支持基本不支持原生支持系统复杂度低链路直观高需要状态机与流同步流式依赖非必需必需容错与排查容易定位环节问题难追溯需要全链路追踪适用场景异步问答、离线转写、知识库对话语音助手、实时会议、陪伴式对话我自己的判断标准是这样的如果你的产品允许用户按住说话、或者对话节奏不需要太快级联管线足够但如果你想做的是一直开着麦像跟朋友聊天一样跟 Agent 说话那必须上全双工。接下来重点聊 800ms 这个目标是怎么通过架构取舍来实现的。3. 800ms 延迟目标的架构取舍3.1 延迟预算拆解到了真正定目标的时候我习惯先把 800ms 拆成一张延迟预算表再逐项去抠。下面是我当时定的初始预算也是后面所有优化的基线延迟环节预算毫秒说明音频采集与预处理40ms麦克风缓冲 AEC 回声消除处理VAD 检测20ms每帧 20msSilero VAD 单帧推理极快流式 ASR 首token150ms从开始说话到识别出第一个字LLM 首token400ms流式生成首 tokenTTS 首帧合成150ms从拿到文本到第一段音频输出传输与播放缓冲40msWebSocket 传输 播放缓冲合计800ms目标端到端延迟这里有个容易被忽视的点ASR、LLM、TTS 三段延迟在流式架构下并不是简单相加。因为 ASR 边识别边输出LLM 在部分文本触发后就能开始TTS 在部分回复文本稳定后就能启动。实际上从用户开始说话到听到回复更像是ASR 首token LLM 首token TTS 首帧在这个预算里是 150400150700ms加上传输和播放缓冲正好压在 800ms 附近。3.2 首字和首帧是真正的胜负手如果你做过对话系统会发现一个规律用户在意的不是整句话生成完的时间而是第一个字/第一个词出来的时间。只要 Agent 在 800ms 内发出了嗯好的今天这类前置词用户的大脑就会自动判定它已经在回应我了后续句子即使稍慢容忍度也会高很多。所以全双工系统的优化火力必须集中在三件事上ASR 的首 token 延迟、LLM 的首 token 延迟、TTS 的首帧延迟。ASR 首 token 延迟说的是从用户说出第一个字到识别文字出来要多久。传统离线 ASR 要等整个句子结束才开始解码而流式 ASR 用逐步解码的思路每输入一帧音频就更新一次解码状态同时吐出当前最有把握的前缀。实操上我遇到的流式 ASR 方案中有一类是基于分块编码器加 CTC 前缀判定稳定性不错另一类则在每帧输入时结合注意力机制做部分解码首 token 可以压到 100-200ms。选型时不用追求识别准确率最高的模型而要选首 token 快 支持部分结果回调的模型因为流式场景本来就允许后续结果修正。LLM 首 token 延迟是整条链路里最硬的成本。主流模型在做流式推理的时候Prefill预填充阶段要把用户 prompt 里的所有 token 算一遍然后再进入 Decode解码阶段开始输出第一个 token。对于一个几千 token 的 promptPrefill 本身就要几百毫秒。优化手段主要在三点一是输入精简把系统提示词和上下文压缩到最短二是前缀缓存如果用户多轮对话的公共上下文不变可以直接复用计算好的 KV Cache省掉重复 Prefill三是投机采样Speculative Decoding用一个轻量的草稿模型先生成候选 token再由主模型验证首 token 和整体吞吐都能改善。TTS 首帧合成是指从拿到文本到生成第一段可播放音频的时间。传统 TTS 需要合成整句话再播放首帧延迟跟句子长度成正比。而流式 TTS 按句子片段通常 5-20 个字进行合成拿到前几个字就立刻合成对应音频把首帧压到 150ms 甚至更低。选型时要注意模型是否支持流式输入以及音频输出是按 chunk 返回还是整段返回。3.3 语义完整性与低延迟之间的妥协全双工架构里最矛盾的地方在于你为了低延迟很快开始生成但生成时拿到的输入可能不完整——用户才说到一半ASR 只出了部分文本LLM 已经开始回复了结果用户后面又补了关键信息LLM 前面的回复就是错的。这个矛盾在工程上有几种缓解策略但每一种都需要做取舍。第一种是延迟决策策略。调度器不急于在 ASR 出第一段文本时触发 LLM而是等 VAD 检测到一个语义边界——比如用户停顿超过 300ms或者 ASR 出了稳定且相对完整的句子。这样牺牲了一点延迟但回复更准确。我通常把 VAD 的静音判定从 800ms 调低到 450ms然后依赖边说边生成来弥补这个等待。第二种是轻量预判策略。当 ASR 识别出的部分文本已经能触发意图时比如今天天气已经足够触发天气查询调度器可以先让 LLM 生成通用开头——比如好的我来查一下这个开头跟具体内容无关所以不会因为后续文本变化而出错。等后续信息补充完整LLM 再生成实质内容。这是一种先稳住再发挥的思路对体验提升非常明显。第三种更激进把 ASR 的部分结果直接喂给 LLM让 LLM 边接收边修正自己的输出。这需要 LLM 有良好的指令遵循能力能处理追加上下文并调整回答的情况。我在测试中发现部分模型的流式输出会受前面半截话影响产出逻辑不稳所以目前只在特定场景开放这种策略。这里我要强调一个原则800ms 不是每个请求都必须严格卡死的硬指标而是一个工程设计目标。它的内核是用户感受到的响应足够快。有时候为了语义正确性多花 200ms 等待一个完整输入远比快速生成一个错误回复更值得。真正的高手不是在所有场景都追求极限延迟而是知道在哪个环节该松、哪个环节该紧。4. 全双工状态机与流式链路实操4.1 对话状态机设计全双工系统里状态机是最重要的骨架。我一开始走了一些弯路把状态切分做得太细导致状态迁移条件复杂、经常出现死锁。后面精简成 5 个核心状态稳定了很多。状态说明进入条件离开条件IDLE空闲监听系统启动 / 用户沉默超过阈值VAD 检测到语音开始LISTENING用户正在说话VAD 检测到语音开始VAD 检测到静音边界 / 用户持续超时THINKING正在生成回复调度器判定输入足够 / 用户停顿LLM 输出首个 tokenSPEAKINGAgent 正在说话TTS 播放开始TTS 播放结束 / VAD 检测到新的用户语音打断INTERRUPTED被打断正在收敛VAD 在 SPEAKING 中检测到用户语音TTS 停止状态回到 LISTENING状态机的核心逻辑在于任何状态都可能因为用户新输入而被打断。比如 THINKING 状态期间用户又补充了内容这时调度器需要决定是等待当前生成完成还是丢弃当前生成重新用新输入触发。我的策略是如果 LLM 已经生成了超过 30 个 token就让它把当前回复说完这个叫弱打断如果只生成了几个 token就取消并重新进入 LISTENING这个叫强打断。这两种路径的观感差别很大值得多调几轮。4.2 流式链路的关键参数流式链路的参数对延迟影响非常大。下面是我在实操中反复调整后认为比较合理的配置注意这是针对我自己的场景不同环境可能需要微调。音频采集侧采样率统一用 16kHz、单声道、16bit。帧长 20ms也就是每次采集 320 个采样点。这个帧长是 VAD 模型和 ASR 模型都容易处理的尺寸也不会因为帧太小导致频繁的状态切换。麦克风缓冲设置为 2 帧也就是 40ms——缓冲太小容易断流太大会增加延迟。VAD 侧我用的模型是轻量级神经网络 VAD单帧推理时间 1-2ms完全够用。说话开始阈值设为 0.5静音结束阈值设为 0.3。这里要注意开始阈值和结束阈值要留出滞回区间否则会因为噪声抖动导致状态不断翻转。我实测把开始阈值调低到 0.3 的话环境噪声很容易误触发把 Agent 自己播放的音频误判为说话所以 0.5 是一个比较稳的起点。ASR 侧流式识别的 chunk 大小是 160ms也就是 8 帧音频作为一个 chunk 送进去。太大首 token 延迟高太小 ASR 的运算粒度太碎、GPU 利用率低。流式 ASR 会输出部分结果partial result通常每隔几个 chunk 回调一次。我在调度器里设置了稳定文本的判断连续两次回调之间文本变化小于 3 个字就认为这段文本已经稳定可以触发 LLM。LLM 侧prompt 里除了对话历史还会附带上一次 ASR 部分结果和这次触发时的上下文标记。我使用的模型上下文长度是 8k但实际发送时会把历史压缩到最近 4 轮因为长历史会显著增加 Prefill 时间。流式输出通过 SSE 或流式 gRPC 接收每次返回一个 token 就立刻转发给 TTS 调度器。TTS 侧流式合成的粒度是按句子片段控制的。我设置每 5-12 个字形成一个小句段合成后立即推送到播放队列。这个粒度经过测试太短比如 3 个字会让 TTS 合成接口频繁调用、音频节奏生硬太长比如 20 个字又会让首帧延迟回到高区间。小句段之间插入 150ms 的音频静音用来模拟真人说话的节奏停顿。4.3 一个简化版调度器伪代码真正的工程系统里调度器逻辑很复杂但核心思路可以用下面这段伪代码表达当收到 ASR partial_result: 如果当前状态是 IDLE 或 LISTENING: 如果 partial_result 稳定 or VAD 检测到短停顿: 触发 LLM 流式生成 状态 - THINKING 当收到 LLM token: 如果当前状态是 THINKING: 累积 token 到句子缓冲区 如果缓冲区包含完整标点 or 达到 5-12 个字: 发送该片段给 TTS 状态 - SPEAKING 当收到新 VAD 语音开始: 如果当前状态是 SPEAKING 或 THINKING: 将当前 LLM 生成取消若 token 30 停止 TTS 播放音频快速淡出 状态 - LISTENING这套逻辑在真实运行中还有一个细节SPEAKING 状态播放音频时播放队列里可能还有没播完的音频块。打断时不能只是停止播放还要清空播放队列否则旧的 TTS 内容会在打断结束后继续冒出来很影响体验。我当时漏了这一步被用户反馈过我说别说了它还接着说后来加了一个打断即清空的机制才解决。4.4 传输层的选型实时对话的传输层一般有两个选择WebSocket 和 WebRTC。WebSocket 实现简单、调试方便适合作为 MVP 的传输通道。音频、识别文本、生成 token、TTS 音频都可以在同一连接上通过不同消息类型区分。缺点是 WebSocket 本身不保证数据的实时优先级也没有自动处理丢包重传的能力。对语音这种错过了就算了的实时数据这其实问题不大但在网络抖动时会出现短暂的断音。WebRTC 是为实时音视频设计的天然支持音视频流、回声消除AEC、噪声抑制、自动增益控制AGC而且有完善的抗丢包机制。缺点是不好调试信令流程复杂浏览器端的兼容性也偶尔出幺蛾子。我的建议是如果只是内网 Demo用 WebSocket 就行如果要上线面向真实用户的产品务必上 WebRTC——它自带的那套音频前处理模块能帮你省掉大量回声自我打断的问题。5. 常见问题与踩坑实录5.1 VAD 误判导致识别被截断我在最初测试时发现一个高频问题用户正常说话中间稍微停顿了一下比如思考怎么措辞VAD 就判定说完了立刻触发 LLM 生成结果只把半句话送进去Agent 回复自然是答非所问。排查后发现是 VAD 的静音结束阈值太短加上我把静音判定时间设得太激进。我当时的设置为静音 200ms 就判定结束这对抢话场景有利但对正常对话太不友好。解决方案是把静音判定时间调到 450ms同时结合 ASR 的稳定文本判断即使 VAD 判定结束如果 ASR 正在输出中间内容比如以连接词结尾就再等一批 chunk。这类复合判定条件比单纯依赖 VAD 靠谱得多。5.2 Agent 自我打断回声和串音的坑全双工系统最尴尬的场景是Agent 自己的 TTS 声音被麦克风采集回到 VAD 和 ASR结果系统判定用户开始说话于是自我打断。这在没有回声消除的裸麦克风场景下几乎必现。我当时用普通桌面麦克风测试Agent 刚说几个字系统就进入 LISTENING 状态然后 ASR 把 Agent 自己的声音识别成文本送进 LLMLLM 再生成一段新回复——整个对话流程当场变成鬼打墙。解决思路有几个层次第一WebRTC 自带的回声消除模块AEC是最省事的方案它能在系统层面把扬声器声音从麦克风采集信号中减去。但 AEC 对硬件和声学环境有要求不是开了就完全干净。第二软件层做语音来源判重——在状态机里记录当前是否处于 SPEAKING 状态如果是VAD 检测到的语音大概率是自家 TTS 的声音需要额外判断这个语音是不是被打断。判断依据可以是能量方向和频谱特征或者是 Agent 是否正在播放音频。用正在播放音频时 VAD 触发来抑制误判是一种简单的软屏蔽方案。第三物理层面优化使用带物理回声消除的麦克风阵列、耳机式麦克风或者把麦克风放在距离扬声器较远的位置。工程上没有银弹我最终的方案是WebRTC AEC 状态机软屏蔽 物理布局优化三层叠加误打断率才从 20% 降到 1% 以下。5.3 流式 ASR 的文本质量不稳定流式 ASR 的准确率比离线版本要低尤其是对长句和口音重的用户。因为它只能看到当前已经输入的部分音频没法利用后文来修正前文。实际表现就是用户说一句长句ASR 先吐出一个我今天想去公费后面又修正为我今天想去公司然后 LLM 已经按公费生成了一半内容。我的处理方案是两段式文本提交如果用户在 THINKING 或 SPEAKING 状态又产生了新的文本更新调度器会把最新的修正文本作为追加上下文再发给 LLM让 LLM 有机会修正自己的回答。这会造成一定的 token 浪费但能显著提升回复的准确度。同时ASR 的上下文提示contextual biasing也很重要。如果你的 Agent 面向垂直领域比如医疗问答、法律咨询可以把领域热词和专有名词注入到 ASR 的解码器里能明显降低关键词的识别错误率。我在一个医疗场景的测试中加入领域词表后关键词准确率提升了约 8 个百分点对整体回复质量的影响非常大。5.4 成本暴涨与并发瓶颈全双工模式下的成本比普通问答模式高很多原因是模型推理次数更多、上下文更长。级联管线是一次问答一次完整请求而全双工中ASR 是持续运行的LLM 可能因为半截话触发多次生成TTS 也需要多次合成。如果用户的一句话被切成了 3 次触发LLM 就要算 3 次 Prefill成本自然水涨船高。控成本的手段有几个一是更精准的触发策略不轻易用半截话触发 LLM而是等 VAD 判定短停顿或 ASR 显著稳定才触发二是降低无效触发后丢弃的 token 比例比如 LLM 已经生成的 token 数量超过 30 才允许取消减少重算开销三是用模型蒸馏或小模型先兜底——一些简单意图打招呼、确认直接用轻量模型处理只有复杂问题时才启用大模型。并发方面全双工会长时间占用 ASR 和 TTS 实例。如果同时监听 10 路对话就需要维护 10 条独立的音频流、10 个 ASR 连接、10 个 LLM 会话。资源复用很困难因为对话状态是有记忆的不能像普通 API 那样无状态地纯并发。我的建议是给 ASR 和 TTS 引入连接池管理每个会话固定占用一个连接空闲超过阈值就释放。这比每次请求动态建连要稳定得多尤其是长连接场景动态建连的开销会让你损失不少宝贵的流式延迟预算。5.5 传输层的拥塞和缓冲问题WebSocket 传输的时候如果网络出现拥塞音频数据会在接收端排队堆积。因为 ASR 是流式的如果排队时间超过几百毫秒即使后面识别得再快用户感知到的延迟也已经是音频缓冲时间 识别延迟瞬间突破 1 秒。处理办法是让实时数据带上时间戳接收端根据时间戳丢弃已经过期的音频块例如超过 300ms 延迟的块直接丢弃而不是让它积压在队列里。类似看直播时的跳帧策略宁可少识别几个字也不要让延迟滚雪球。我在测试环境里特意用 30% 丢包 高抖动网络模拟启用过期丢弃后延迟从 1.6s 降回了 900ms 左右虽然偶有漏字但整体对话节奏保住了。5.6 常见问题速查表现象可能原因解决建议用户停顿被误判为说完VAD 静音阈值太短静音判定调到 400-500msAgent 自我打断回声消除失效启用 AEC 状态机软屏蔽ASR 识别半截话流式模型视野有限两段式文本提交 领域词表LLM 回复牛头不对马嘴触发时机过早等待稳定文本 短停顿复合触发播放完还有残留音频冒出来打断后播放队列未清空打断时清空播放队列高并发时大量报错会话连接重复建连长连接池 超时释放网络抖动后延迟飙升音频块在接收端堆积按时间戳丢弃过期音频块6. 一些来自实测的经验与后续扩展想法实际操作下来我最大的感受是全双工系统的复杂度主要不在 AI 组件本身而在调度与状态管理。ASR、LLM、TTS 这些模型只要选型合理各自的延迟都能控得很好但把它们放进一个共享的状态机里彼此之间的配合什么时候触发、什么时候打断、什么时候丢弃才是影响最终体验的核心变量。有一件事值得强调全双工系统的调试方式跟传统系统很不一样。传统系统的日志是请求-响应式的好排查全双工是并发的、持续的出问题时往往已经过了好几秒日志里一片混乱。我后来给每个会话加了一个全链路追踪 ID在音频帧、识别文本、LLM token、TTS 音频块上都打上时间戳标记才勉强能定位问题。如果你打算做全双工建议从一开始就设计好这套观测体系否则后面排查一个问题可能要花上几天。关于后续的扩展我最近在尝试的方向是引入意图驱动的预生成在用户还没说完的时候根据前几个词预估多种可能的意图提前准备几段候选回复草稿。等用户说完整句话后从候选草稿里匹配最接近的一条作为回复。这个思路有点类似搜索引擎的预取在特定场景下能把LLM 首 token 延迟几乎抹掉但代价是资源浪费和复杂度的进一步上升目前还在实验阶段。另外多模态的接入方式也值得琢磨。除了语音视觉输入摄像头画面和屏幕输入屏幕共享会带来更丰富的上下文但对流式传输和模型并行提出了更高要求。比如让 Agent 在听你说的同时看你在指哪个东西这需要把视觉编码器也接入调度器并在状态机里增加视觉注意力维度。这个方向我还在探索不过已经有了一些初步的想法如果后续有了成型的结论再另写一篇详细展开。