过去两年语音助手产品经历了一轮密集升级从“先唤醒再说话”变成了流式实时对话。但我一直觉得这类产品还只算半成品——因为对话双方始终互相“看不见”。真人交流时眼神、眉毛、嘴角、手势这些非语言信息一刻不停地在传递而传统语音模型把这些信号浪费了大半。最近行业里两件事放在一起看基本把方向挑明了Tavus 发布的 Griffin 主打全双工视频交互持续读懂表情和动作Inworld 则直接收购了语音智能体平台 Ultravox。这两件新闻不是孤立的发布或资本操作它们指向同一个问题对话系统要从“能接话”进化到“在场”。这篇文章我想从技术逻辑、评测标准和工程落地三个角度拆解顺便说说这两件事对做数字人、语音机器人、互动内容的人到底意味着什么。如果你是做多模态模型、实时音视频应用或者正在选型数字人方案的开发者这篇会比较对胃口。1. 两条消息背后的同一条主线1.1 Griffin从语音对话到视频互动的跳跃Tavus 这次推出的 Griffin名字听起来像新模型代号实际落在“视频交互”这个很少人做透的赛道。市面上大多数数字人产品本质上还是“语音对话 预先录好的口播视频”模型负责决定说什么画面要么循环播放预设片段要么靠唇形同步技术把音频对齐到一张脸上。这种方式有个硬伤系统没有真正观察对方。对方皱眉、点头、走神它一概不知也无法根据对方的实时反应调整自己的表情和节奏。Griffin 的思路是从“视频输入”直接进模型。它把摄像头画面里的表情和动作当作对话上下文的一部分然后同步生成自然的面部回放和语音回应。这就把“AI 客服/销售”从只有一维声音的交互提升到二维甚至三维的情境理解对方笑了它可以更热情对方困惑它可以放慢语速并皱眉确认对方准备打断它可以停下来接话。这便是全双工里最值钱的部分不是能同时说话而是能同时感知和回应。1.2 Inworld 收购 Ultravox语音技术开始被当作基础设施Inworld 本来主攻角色 AI 与游戏对话收购 Ultravox 这个语音智能体平台乍看像补齐语音能力往深看其实是在抢人机交互的入口。Ultravox 这类平台做的事情是把语音识别、大模型对话、语音合成、打断检测、降噪串成一条可运维的流水线并给开发者提供实时会话 API。收购的意义不在产品功能叠加而在于行业开始默认语音智能体不是“一个模型”而是“一套工程系统”。谁把多模态输入、实时推理、网络传输、音频播放这些环节封装得更顺手谁就能占据下一波应用生态。Inworld 拿了 Ultravox等于把“让角色开口说话”的底层桩打得更深下一步自然是从语音走向表情与动作——因为游戏里和虚拟世界里角色本来就需要用脸和身体表达。1.3 两条线的交叉点Griffin 做的是“视频双向对话模型”Inworld 买的是“语音实时对话基建”两者看似一上一下实际交叉点非常清晰未来两到三年实时 AI 交互将默认包含视觉通道。语音仍然是核心入口但表情和动作会成为分辨“这个 AI 有没有人情味”的决定性差异。谁先解决“持续读懂对方”这件事谁就能在数字人、客服、教育、陪伴这些领域建立明显的体验优势。2. 全双工视频交互到底难在哪里2.1 “全双工”意味着比说话更早地听通信里的全双工指双方可以同时收发数据。落到对话系统里它意味着打断检测Barge-in、语音活动检测VAD、发言权管理这些模块必须并行工作。传统方案是一问一答AI 不说话的时候就干等用户用户话没说完 AI 插嘴会被视为 bug。全双工模型要求系统持续估算对方是不是要停了对方这句是问句还是自言自语我什么时候可以接过话头Griffin 这类模型把这个问题推进到视觉层面不仅要听还要看。对方低头看稿可能是准备长时间发言对方抬头张嘴可能是马上要打断你对方眼神飘走可能已经不耐烦。真正难的是把这些视觉线索和音频线索以毫秒级同步融合而不是“先识别完脸部再识别语音”这种串行处理。2.2 持续读懂表情和动作本质是流式认知很多人以为表情识别就是把每一帧丢进一个图像分类器输出“开心、难过、困惑”。实际产品里这样做根本不可用。真实对话里表情是流动的一个 300 毫秒的皱眉可能只是眨眼引起的肌肉牵动一段 2 秒的微笑可能伴随着头部晃动和语音重音。如果模型只做帧级判断就会产生大量误报导致 AI 回复节奏忽快忽慢。我理解 Griffin 这类模型的突破在于把表情识别变成“时间序列事件”而不是“独立帧标签”。模型需要回答的不只是“他笑了”而是“他在我说到价格时笑了并且紧接着有一个前倾动作大概率表示感兴趣”。这个能力要求视觉编码器和对话状态管理深度绑定而不是接一个外挂视觉 API。这也是为什么很多团队做数字人时发现单看表情识别准确率挺高一旦接入实时对话就一塌糊涂——上下文丢了识别结果就没有行为意义。2.3 端到端延迟的硬指标实时视频交互的延迟预算比纯语音更苛刻。语音对话的业界常见体验标准是端到端延迟不超过 800 毫秒AI 说话前停顿两秒用户就会明显觉得卡。视频交互里还要加上摄像头采集、画面编码传输、视觉模型推理、面部生成渲染这几段链路每一步都在抢那点有限的延迟预算。通常的工程拆解是摄像头采集约 30~50ms网络传输 50~100ms视觉编码与推理 100~300ms大模型流式生成首字 300~500ms音频播放加渲染 50~100ms。加一起就逼近 1 秒还没算抖动和排队。所以做全双工视频模型的公司真正的护城河很大程度在工程优化模型设计时就要考虑流式推理而不是把整段视频录下来再处理生成侧要用轻量级渲染管线保证表情变化跟得上对话节奏。3. Griffin 这类模型常用的技术框架拆解3.1 从语音模型演进到多模态对话模型据我观察现在做实时视频对话模型的团队起点往往不是视觉模型而是语音对话模型。原因很直接对话的骨架是语义和节奏视觉信息是增强层。团队会把一个经过 RLHF 的流式语音模型作为基座再叠加视觉编码分支让视觉 token 和语音 token 在同一个 Transformer 里参与注意力计算。这种做法的好处是复用了大量成熟的对话能力比如上下文管理、安全对齐、长文本记忆。缺点也很明显视觉编码会让输入序列大幅变长。一秒钟视频如果按每秒 8 帧抽帧每帧再切成几十个 patch token输入长度会爆炸。所以工程上一般会做视觉特征压缩比如把相邻帧的相似 patch 合并或者用一个轻量视觉编码器输出低维特征再在层数较少的投影层里融合。3.2 流式视觉编码与轮次状态管理实时场景里不能等用户说完一整句再做视觉理解而是边看边理解。一个常见的方案是滑动窗口维护最近 N 秒的视觉与音频特征模型每 200 毫秒左右进行一次状态更新。这种设计下表情事件可以被当成“对话事件”写进状态记忆。比如“用户在 14:32:05 做出惊讶表情”后续生成回复时会回溯这个事件从而调整话术。这里的难点不在事件检测而在事件排序与优先级。用户可能边说边笑边摇头边提问多个非语言信号在同一个时间窗口叠加。模型要决定哪个信号支配当前对话意图。我见过一些团队用额外训练的“交互意图头”来解决它会输出“赞同、质疑、困惑、打断、转移注意”这类高层状态再把这些状态作为生成时的控制信号。这么做比直接让语言模型读一堆视觉 token 更稳定推理消耗也更小。3.3 生成与感知的双向优化Griffin 榜上提到的“生成与感知双榜第一”对应的是两类能力同时打磨。生成侧要保证 AI 的数字人形象说出的每一句话、做出的每一个表情都自然唇形同步准确、表情不僵硬、头部运动不违和。感知侧则要求系统准确读懂用户的表情、动作、目光方向并转化为对话策略。这两者在训练里经常互相打架。感知侧希望模型关注用户所有细微动作生成侧又希望模型不要因为芝麻大的动作就改变回复。平衡的办法一般是在多任务目标里设置一个“交互价值”函数只有那些会影响对话走向的非语言信号才值得显著改变生成结果。比如用户叹气可能值得调整话术用户眨眼则不需要。从公开资料看Griffin 这类新模型正尝试把两种目标统一进同一个训练框架让感知结果直接作为生成条件而不是像老方案那样感知和生成各跑各的。4. VideoFDB 评测体系在衡量什么4.1 生成维度像不像、动没动、连不连贯VideoFDB 不是只测“生成的视频像不像真人”这种单一指标。生成维度通常会拆成多个子项面部动作是否与语音内容匹配、唇形同步误差、表情时序是否符合上下文、头部姿态是否自然、背景与光线是否一致。理解这类榜单关键在于区分“单帧质量”和“时序质量”。很多数字人模型单帧截图可以做到很逼真但视频连续播放时会发现表情线性插值、嘴型对不上重音、头部动作有机械感。评测体系把时序连贯性单独拿出来打分实际上是在逼模型做好时间建模而不是靠单帧生成糊弄人。4.2 感知维度模型能不能读懂非语言信号感知维度考的是模型从视频里提取交互信息的能力。常见评测任务包括表情分类、动作识别、目光方向估计、情绪强度回归还有更高级的“交互事件检测”——例如判断对方是否准备打断、是否出现困惑、是否转移注意力。感知任务最怕的就是测试集过简单。如果测试片段都是演员刻意做出的夸张表情模型很容易靠背景纹理或肤色纹理作弊。合理的评测会包含大量自然对话的切片表情变化幅度小、遮挡多、光线差让评测更接近真实产品环境。这也是为什么“感知榜第一”比“识别准确率 99%”更有参考价值后者可能只是在实验室自建数据集上刷出来的。4.3 跑榜之外真正要关注泛化能力榜单能说明一定问题但做落地的人都知道真实场景是评测集永远覆盖不了的。我曾参与过类似数字人项目的选型发现一个规律拿公开榜单选模型第一年还可以第二年就会碰到各式各样边角情况——用户戴眼镜、侧脸对着镜头、光线半明半暗、宠物突然入镜模型的感知能力会急剧下降。所以看 VideoFDB 或任何榜单时建议关注三个信息测试数据是否包含多视角和多光线条件、是否有长视频时序评测、是否允许模型在线更新状态。这三个点比名次更能预测模型落地后的真实体验。如果评测用的是 5~10 秒短片那对长对话场景的参考价值就要打折。5. 落地场景谁最需要这类模型5.1 客服与销售有表情的“真人”服务客服和销售是数字人最先规模落地的领域原因很现实话术相对标准客户问题相对收敛ROI 容易算清楚。传统语音客服已经能把效率做得很高但体验上一直缺温度。接入全双工视频交互后AI 销售可以观察到客户在听到价格时的表情变化判断是不是价格敏感从而及时调整报价策略或切换推荐方向。我见过一些实际的 Pilot 项目团队把数字人放在线上信贷面签场景里以前需要人工审核的部分现在让 AI 通过视频追问和表情观察辅助判断。这种做法短期内不可能完全替代人工但可以显著降低重复性面签的运营成本。关键是这种场景对“持续读懂表情”的需求是硬性的不是锦上添花。5.2 教育与陪伴互动节奏比内容更重要在线教育里AI 老师的价值不在于讲得多好而在于能不能像真人老师一样捕捉学生的状态。学生走神、皱眉、点头、低头都是重要的教学信号。Griffin 这类模型让 AI 老师可以看着学生的脸调整讲解速度和重复次数这比任何“学习数据分析”都来得更直接。陪伴场景更看重“被看见”的感觉。用户对着摄像头说话AI 角色如果能同步做出关切、惊喜、调皮的表情并反馈“我看到你笑了是不是想到什么开心的事”这种体验比纯语音陪伴上了一个大台阶。尤其面向儿童和独居老人时视觉反馈带来的安心感很难用语言量化。5.3 内容生产从后期换脸到实时生成视频内容生产领域也有明确需求。以前做虚拟主播或视频二创需要录制大量素材再剪辑表情、口型、情绪全部要靠素材拼凑。全双工视频交互模型可以把“内容生成”变成“实时直播里的自然行为”创作者面对一块屏幕和摄像头就能生成专属角色角色会实时回应创作者的表情和语音。这条线的商业化空间很大但也最容易踩坑。创作者要求的不只是技术稳定还有风格一致性。同一个数字人昨天生成出来是温柔型今天变成活泼型用户就会出戏。我目前看到的做法是给模型配置“角色风格向量”在推理时注入固定风格 token保证前后生成的一致性。6. 语音智能体并购事件带来的行业信号6.1 Ultravox 这类平台的价值Ultravox 之所以值得被收购不是因为语音识别准确率多高而是它把语音对话的复杂工程封装成了开发者友好的接口。语音智能体产品的难点从来不只是模型还涉及延迟、打断、噪声、回声、对话状态管理。一个平台如果能让开发者半小时内跑通“用户说话 - AI 思考 - AI 回复”的闭环并且在弱网环境下保持低延迟那它就构成了事实上的分发入口。这类平台还有一个隐藏价值对话数据与评估体系。语音智能体跑得越多沉淀的数据越能反哺模型优化。收购方拿到的不是一个静态 API而是一条不断自我进化的数据管线。这也是我觉得 Inworld 收购 Ultravox 比单纯买一个语音模型要聪明得多的原因。6.2 语音智能体如何演进为视频智能体从行业节奏看语音智能体接下来几乎必然走向视频智能体。原因有三个第一端侧算力与带宽在持续增长处理实时视频已经不再奢侈第二用户对交互体验的要求在提高“只能听不能看”的 AI 显得冰冷第三多模态大模型已经证明视觉信号能显著提升对话理解能力不用就是浪费。但演进不会是一步到位。现实路径大概率是先做“语音为主、视频为辅”AI 保持语音对话作为主通道同时感知对方表情动作来修正语言风格。等视频生成质量、延迟和成本都达标后再切换到“视频对等交互”形态。Griffin 这类产品的意义就是提前把后一种形态的标杆立起来给行业一个明确的演变方向。7. 从工程视角看接入这类模型的几个关键问题7.1 先想清场景再选模型形态很多团队犯的错是直接用最贵的视频对话模型解决所有问题。实际上不同场景对模型能力的要求差异极大。如果只是录播式数字人播报用 Griffin 这类全双工模型就是杀鸡用牛刀如果是销售面签这种强互动场景纯语音模型又撑不住。我建议做选型前先列三个问题用户是否需要实时改变化身的表情来回应系统是否需要理解用户的非语言信号业务是否容许 1~2 秒的延迟如果三个答案都是否老老实实用传统 TTS 口播视频方案成本低且稳定。如果有一个答案是是才需要考虑全双工视频模型。7.2 延迟预算估算把每一段链路写下来接全双工视频模型不能只看模型本身多少毫秒。我通常建议按“端到端用户体验路径”画一个延迟预算表先算出总价再决定哪些环节可以优化视频采集30~60ms取决于摄像头和采集 SDK上传传输80~200ms取决于用户网络和 CDN 节点视觉感知推理100~300ms取决于模型规模和 GPU对话模型推理300~700ms首 token 延迟是关键语音合成首包150~300ms数字人渲染与播放50~150ms加在一起轻则 700ms重则 1.7 秒。如果超出 800 毫秒的体验线就要做取舍牺牲历史视觉帧、用端侧小模型做预筛、或者提前合成可被打断的占位回复。每项优化都要单独验证不能拍脑袋。7.3 评测不能只看榜单无论 VideoFDB 排名多高落到自己场景前都要自建小规模验证集。我习惯的做法是用自己业务里真实的用户片段跑 50~100 轮对话记录数字人在不同状态下的表情是否合适专门测试边缘情况用户侧对镜头、戴口罩、强逆光、多人入镜用双盲评估让测试人员同时打分“真实感”和“互动恰当性”不要只看生成逼真度这些自测结果比公开榜单更决定项目成败。公开榜单考核的是模型上限业务落地考验的是模型在脏数据、弱网、低端设备上的下限。一个在下限场景崩掉的模型榜单再高也不适合投产。7.4 成本控制与规格选择实时视频交互模型的推理成本比纯语音高一个量级。视觉编码器加视频生成模型一张 A 系列甚至 H 系列卡可能只够支撑几个并发。做预算时要把并发数乘上平均会话时长再算峰值。我见过一些团队为了压成本把“感知”和“生成”拆到不同机器跑一台服务器专门做人脸表情识别把结果传到另一台服务器做对话生成和视频渲染。这样虽然延迟高一点但资源利用率会好很多。前期量不大时这是不错的中庸方案等用户量上来再上端到端一体推理也不迟。8. 我的一些观察与经验做了一段时间多模态实时交互项目我最大的体会是这类技术真正的瓶颈不是模型能力而是产品经理和工程师能不能把“表情”“动作”“语气”这些模糊信号翻译成明确的产品规则。模型给你一个“用户可能困惑”的感知结果你要决定接下来是放慢语速、换一种说法、还是直接问一句“是不是哪里不清楚”。这个决策逻辑目前没有任何公开模型能替你完成。如果你准备在自己的产品里引入全双工视频交互我给一个比较具体的建议先别急着追求“完全自然”。先给系统设定几种固定状态比如“默认讲解”“重点强调”“表达困惑”“友善延展”让模型在这几个状态间切换再逐渐放开自由度。这样既能让用户感受到表情动作的价值又不会因为模型偶尔跑偏而失控。最后再分享一个我在选型时的小技巧看全双工模型发布会不要只盯着演示视频。把注意力放到他们如何处理打断、如何处理长时间沉默、如何从错误的感知判断里恢复。这些细节比几个漂亮的 demo 片段更能反映技术成色。Griffin 这次宣传里特意强调“持续读懂表情动作”说明行业终于开始正视这些细碎但致命的问题了。