StreamVibe：你还没开口，视频 agent 得先猜出你卡在哪

速览

一、把「什么时候开口」交给模型后，瓶颈立刻落到用户没说出口的意图上

StreamVibe 把「该不该说话」直接写进模型的输出空间。在每一个时间步，模型只看到当前与过去的画面、已经出现的意图、以及自己此前说过的话，然后输出一个二选一的动作：沉默，或者响应。这一步看起来只是把交互时机工程化，论文真正的判断在别处：一旦模型必须自己决定开不开口，卡住它的就不是时机，而是用户没说出口、并且会在中途改掉的那点需求。

论文用三个任务形态把这件事摊开。显式意图像「下载完了通知我」，条件由用户点名，模型只需盯住并照单执行。隐式意图像「帮我做迷你果酱面包卷」，用户只给目标，没给任何触发条件，模型必须自己从画面里认出「该切掉面包边」这个时刻并主动说出来。动态意图再往前一层：用户先说「遇到困难就帮我」，中途又追加「告诉我下一步该做什么」，模型得在任务还开着的时候把新约束并进去。三种情况下该说的话完全不同。StreamVibe

图注：上半 (a) 用示例气泡分别示意显式、隐式与动态三类意图，显式气泡是「下载完通知我」，隐式气泡是「帮我做面包卷」得到「先切掉面包边」，动态那一行标注了修订、组合、打断。下半 (b) 列出既有范式的三条失效路径：只依赖显式请求、状态跟踪不足、意图适配有限。StreamVibe

论文把这套落差归因到既有范式的三条失效。只认显式请求，于是用户不问就不帮，隐式意图下整个该帮的时刻被漏掉。交互状态跟不上，于是反复给已经给过的建议，或者该出声时没声音。意图更新被忽略，模型还在回答上一个问题。这三条正好对应论文的三件套：按意图难度分层的基准负责把这三件事测出来，流式策略模型负责学「此刻说不说、说什么」，外置的 Harness 负责把意图维护成会被作废、会被替换的状态。

需要说明的是，图里的示例回复是论文给出的示意文本，不是模型在基准上的实测输出。这张图只承担建立直觉的任务，后文的数字都另有出处。

二、难度是造出来的：4,100 条样本按显隐三档配比，再配两套评测协议

StreamVibe-Bench 真正新增的东西有两样，规模只是外壳。第一样是把「意图有多难」变成可以配比的样本量，第二样是把「隔离判断」与「连续轨迹」拆成两套不能互相换算的评测。

构造流程决定了隐式那一档不是贴标签贴出来的。每条样本从任务视频与用户情境出发，先由 Gemini-3.8-Flash 产出候选 help point、响应窗口与参考回复，再交给四位评审独立复核。任何一人有异议，就要全员重审或直接丢弃，最后只保留四人全票通过同一版本的那份。这条规则针对的正是隐式意图：用户没有明说触发条件，「哪个时刻该提醒切面包边」这种判断只能靠事先构造的证据点，不能让标注员随手写一句话了事。一致性审计给出的 Fleiss κ 是 0.84，落在几乎完全一致的区间。StreamVibe

最终规模是 4,100 个评测样本、20,546 个 help points、183.4 小时视频，按 600 条显式、2,000 条隐式、1,500 条动态配比。档内还按证据形态再切，显式分一次性事件、状态跃迁与重复出现，隐式分下一步引导、学习解释、状态监控与工具使用，动态分修订、追加与打断。显式最少、隐式最多，这个配比本身说明了这套基准想把评测重心放在哪。

图注：(a) 是从任务视频与用户情境到证据标注、四人复核、1 FPS 因果流的构造链路，(b) 的环形图给出 4,100 条样本在显式、隐式、动态三档的分配，(c) 把 pointwise 与 trajectory 画成两条时间轴，(d) 是视频时长与每样本证据点数的联合分布。StreamVibe

两套协议的区别不只是难度，量级也不同。pointwise 在标注点附近采正负时间戳，逐个独立判断此刻该不该响应，历史可以喂 gold history，误差不会累积。trajectory 让模型在整条流上连续跑，每一步都以自己刚生成的历史为条件。在 pointwise 下显式档的时机 F1 是 0.558，而 trajectory 区块只剩 0.123（两种设置覆盖的模型集合不同，不是同一模型的配对结果）。所以论文把它们分成两个区块汇报，跨区块比强弱没有意义。

指标也分两条线。时机维度看 Precision、Recall、F1，另加一个 near-miss FPR，专门统计「在标注点附近但不该说的地方说了」的比例。内容维度看 ANS 与 Content F1，由 Claude Sonnet 4.6 给时间匹配上的每条回复打 0 到 4 分。Content F1 的分母同时含预测数与标注数，所以漏掉一个意图和多说一句废话都会被罚，这也是它比 ANS 更能反映持续交互质量的原因。

这条线在 2025 年由 ProactiveVideoQA 定义成可测问题，那时问题是开头一次性给完，模型只决定何时开口；此后 IPIBench 补上多轮交错，GuideMe 把证据点规模推到 47.8K。StreamVibe-Bench 补的是把显式、隐式、动态三层意图放进同一个基准，再配上面那套不能互相代偿的协议。ProactiveVideoQA IPIBench GuideMe

三、训练分两步：先学会别乱说，再学会在证据点上说得准

两阶段训练解决的是同一个问题的两半。在视频流里沉默帧远多于该说话的帧，直接监督会把模型推向一直沉默；而一长串沉默里往往只有一个该说话的点，奖励必须能准确落到那个点上，否则模型不知道该为哪一次决策负责。

先把「流式」这件事说清，它是工程约束而不是形容词。模型每一步只能看当前与过去的帧，帧 token 与对话 token 按时间顺序交错排进同一条序列，该沉默的帧由 streaming EOS 预测损失监督，该回答的帧走标准语言模型损失。2024 年的 VideoLLM-online 已经把这套结构做出来了，但它的上下文里始终有一条用户提问，回答的是「看到了什么、什么时候说最贴合」。主动式要多回答一句：现在到底该不该说。VideoLLM-online

图注：自下而上是时间轴上的提问、视频帧与回答，中间一层是交错排好的文本 token 与帧 token。顶部训练目标行里，沉默帧上方是成组的 EOS，回答区间上方是正常文本输出，冻结的编码器与可训练的投影分别标了雪花与火焰。VideoLLM-online

第一阶段叫 Adaptive Streaming SFT。它按当前训练分布调整决策 token 的权重，沉默与响应哪一边稀缺就抬哪一边，同时用一条独立的文本损失保住回复生成能力，避免模型只学会闭嘴。这一步的效果是拿敏感度换误触发：相对底座模型，时机 F1 提高 10.1 个点、召回提高 16.4 个点，但 near-miss 误触发率也恶化了 4.1 个点。

第二阶段 Localized Trajectory RL 负责把误触发拉回来。它的对手是「整条轨迹一起优化」的老做法：一整条流只给一个奖励，模型无法判断是哪一次决策挣来的分，奖励信号因此被稀释、正确与错误的行为混在一起。更早的 StreamPro（2026-05）走的是全轨迹 GRPO 加多粒度奖励这条路，把奖励拆成轮级与轨迹级两档，但优化范围仍是整条流。StreamVibe 的做法不同，把 rollout 直接裁到 help point 附近，让每一步的功劳和过失都能对上号。StreamPro

讲解：奖励怎么只落在该说话的那一步

点级奖励是时间对齐分乘内容质量分，再做一对一匹配；另有一档轨迹级奖励压冗余与冲突，两者按 0.7 与 0.3 加权。乘性组合是这套设计的关键。答在错误时刻，时间对齐分接近 0，内容再准乘积也接近 0；答在正确时刻但内容跑偏，质量分会把乘积压下来。一对一匹配则保证一个标注点只能被一条回复认领，多说的算多余，漏掉的算没答，两种错误都不会在平均里互相抵消。

两步合起来是一笔交易。相对 SFT，RL 把误触发率降了 6.0 个点，ANS 提高 3.1 个点，代价是召回掉 2.5 个点。两阶段训练做的是把「敢说」和「说得准」分开调，先让模型不再一味沉默，再让它只在证据点上开口。

四、意图得存成会过期、会被替换的状态，塞进更长的上下文解决不了

意图跟踪的关键不在记住更多历史，而在给每个意图一条独立、会过期、可被替换的生命周期，并把「维护状态」与「决定动作」拆成两个组件。这一章是全文最容易被读歪的地方，因为它看上去像又一个长上下文 agent，实际上不是。

Harness 在每次决策前把三样东西编译成一段紧凑文本交给策略：交互状态、意图生命周期、分层记忆检索出的片段。策略给出回复之后，Harness 再把这次交互写回状态。边界要守住：策略 π 仍是唯一决定沉默还是响应、以及说什么的组件，Harness 不替它开口。状态外置的意义在于每个意图可以被单独作废和替换，而不是把更多历史塞进更长的上下文。

图注：左侧是一条表格操作界面在三个时间点的画面流，中部 Harness 分成三块：用户任务进展、意图生命周期、分层记忆，三者经状态整合汇入下方的策略模型，由它决定等待还是开口，右侧给出对应时刻的两条建议。下半是两阶段训练的流程示意。StreamVibe

交互状态以带 id、时间戳、来源的类型化事件增量更新，重复事件被忽略。一个容易略过的细节是证据门槛：只有交互或感知证据足够时才改状态，而且模型自己刚说出口的建议不算用户进展的证据。没有这条约束，模型会把自己的猜测当成事实再喂回自己。

生命周期把两件事分开记账：请求本身是否还有效，以及某个具体事件是否已经被覆盖。一次性提问「下载完通知我」答完就关单；持续性请求「发现我漏步骤就提醒」报告一次只把那个事件标成已处理，请求本身仍然有效，等着后续证据。一个意图可以对应多个证据点，全部覆盖前一直保持 active。

这套结构和一张有状态的工单很像。意图出现是开单，证据点没覆盖完就一直在处理中，条件满足才关单，用户改口则开一张新单替换旧的。对应关系要说清：开单对应意图被创建，关单对应证据被覆盖，替换对应修订或追加。这个比方只覆盖状态机这一层，不覆盖「谁去说话」那一层，工单不会自己开口，策略才会。

讲解：一个意图怎么开单、续命、关单

分层记忆则是三级压缩。32 秒一个 chunk，5 条中期摘要汇总成 1 个长期文本块，保留 8 块，先进先出淘汰。检索按 focus string 的词面重叠排序，再按近期性补齐，每类最多取 3 条，不用 embedding 模型，也不用学习式检索器。要回答的问题是「几十小时流里哪些旧事还跟当前意图有关」，而不是「怎么把历史全装进去」。

这四条只说明同一件事有四种放法，不判优劣。PWR 的计划状态解决的是「用户走到第几步」，没有多意图并存；EgoMemo 靠检索代替状态机；ProactEgoMem 把过期翻译成一次工具调用的终止。StreamVibe 选的是把意图做成可单独寻址对象那条路，代价是必须自己维护一套状态更新规则。PWR Vinci2 ProactEgoMem

五、内容维度掉得比时机维度狠，摘要那两个提升数字在正文找不到口径

读这篇论文的结果要抓两件事：收益确实集中在「意图会变」这一层，而摘要给出的两个百分比在正文里找不到对应口径。两件事合起来才是对它的合理评价。

主表分两个区块，必须先看清这一点。pointwise 区块里放的是专有模型与离线开源模型，trajectory 区块里只有开源离线模型、开源流式模型和本文两行，因为流式模型不支持 pointwise 评测。两个区块的基线集合本来就不同，跨区块比谁更强无效。trajectory 区块每个意图层级 6 个指标共 18 格，其中 9 格由 StreamVibe-VL 的 RL 版本拿到最佳；动态意图下的精确率、召回与时机 F1 都不是最佳，原文自己的措辞也只是优于开源基线。外部泛化同样是「开源模型里最好」：EgoProactive 宏平均 59.5，高于 Qwen3.5-9B 的 46.2 与 JoyAI 的 41.0，但闭源 Gemini-3.8-Flash 的 64.96 更高。StreamVibe

真正能说明问题的是分层诊断。在该设置下对全部可用模型取均值，内容维度从显式 0.552 掉到隐式 0.307、动态 0.334，时机维度只从 0.712 掉到 0.642、0.674。模型还大致能卡住「什么时候该说」，但「该说什么」在意图变模糊或变复杂时塌得更狠。换成用模型自己生成的历史跑整条流，内容分再退 45.3%、61.5%、51.2%，说明单点判断对并不等于持续交互稳。

Harness 的增益分布也指向同一件事。SFT 加 Harness 后三档的时机 F1 都是正的，分别是 +4.4、+1.9、+6.4 个点，误触发降幅在动态层最大，达 13.9 个点。RL 加 Harness 在显式与隐式的时机 F1 上反而是负的，为 −3.4 与 −9.7，但在显式上把内容分拉高 12.8 个点。收益最一致的落点是动态意图的误触发，这恰好与「意图会变」这个诊断对得上。

长时程没有解决。视频超过 5 分钟，时机 F1 只剩 0.041，作者自己把长时程的意图与环境共同演化列进了未来工作。

摘要宣称 StreamVibe-VL 在响应时机与回答质量上比基线提升 10.7%，Harness 再带来 12.3% 的主动交互增益。这两个数字在正文、主表、诊断图与附录各表里都没有复述，对比基线集合、指标定义、平均方式与生效子集都无从确认。能写的只有「摘要宣称、正文口径未明」，也不能拿诊断图里的 +10.1 个点或 +12.8 个点顶替，那是完全不同的统计口径。

失败的位置大致有三条。意图在演化中跟踪不住，LLMs Get Lost in Evolving User Intent 把静态单轮任务改造成意图逐轮演化的环境，多数格子退化，任务函数中途切换时最狠，不过它是纯文本的工具型任务，只能作一般性证据。反应快不等于知道该不该参与，DIVE 测出领先实时模型的平均反应延迟已到亚秒级，平均窗口响应率上限只有 53.77%，而它把参与决策、时机、质量拆成三个互不代偿的维度，StreamVibe 只评了其中两条，DIVE 还含音频维度，与本文纯视觉设定不同。第三条是长时程与长期记忆，至今没有定论。Evolving Intent DIVE

图注：左侧是模型输出与响应时间两路输入，中间三个并列模块分别给响应质量、参与决策与时机打分，右侧三路汇成总评分。参与决策那一格里对话上下文与目标槽汇入一个说或不说的判断，时机那一格把响应时间落在早、准点、晚的时间轴上。DIVE

StreamVibe 的贡献不是让视频 agent 学会抢答，而是把「用户没说出口的意图会变」这件事变成了可以分层测量、可以用状态机制承载、也仍然没被解决的问题。

想深入可以读原文：StreamVibe: Proactive Video Agents for Evolving User Intent — arXiv:2610.34662

参考文献

• StreamVibe: Proactive Video Agents for Evolving User Intent，Chengzhi Liu 等，arXiv:2610.34662v1（2026-10-26），https://arxiv.org/abs/2610.34662
• ProactiveVideoQA: A Comprehensive Benchmark Evaluating Proactive Interactions in Video Large Language Models，Yueqian Wang 等，arXiv:2507.09313v2（2025-07-15），https://arxiv.org/abs/2507.09313
• IPIBench: Evaluating Interactive Proactive Intelligence of MLLMs under Continuous Streams，arXiv:2605.27074v1（2026-05-26），https://arxiv.org/abs/2605.27074
• GuideMe: Multi-Domain Task Guidance and Intervention in Streaming Video，arXiv:2607.02991v1（2026-07-03），https://arxiv.org/abs/2607.02991
• Plan, Watch, Recover: A Benchmark and Architectures for Proactive Procedural Assistance，Kaustav Kundu 等，arXiv:2606.04970v2（2026-10-12），https://arxiv.org/abs/2606.04970
• StreamPro: From Reactive Perception to Proactive Decision-Making in Streaming Video，Ao Li 等，arXiv:2605.16381v1（2026-05-11），https://arxiv.org/abs/2605.16381
• SyncPro: Synchronous Reasoning and Responding for Proactive Streaming Video Understanding，arXiv:2610.32132v1（2026-10-23），https://arxiv.org/abs/2610.32132
• Vinci2: Providing Proactive Assistance in Continuous Egocentric Videos，arXiv:2607.11523v1（2026-07-13），https://arxiv.org/abs/2607.11523
• ProactEgoMem: Benchmarking Proactive Memory in Streaming Egocentric Video，Ruotong Liao 等，arXiv:2610.30089v2（2026-10-26），https://arxiv.org/abs/2610.30089
• LLMs Get Lost in Evolving User Intent，Jihoon Tack 等，arXiv:2607.20734v1（2026-07-22），https://arxiv.org/abs/2607.20734
• DIVE: Benchmarking Full-Duplex Interaction with Visual Engagement in Continuous Streams，Yuhang Chen 等，arXiv:2610.28405v1（2026-10-20），https://arxiv.org/abs/2610.28405
• VideoLLM-online: Online Video Large Language Model for Streaming Video，Joya Chen 等，arXiv:2406.11816v1（2024-06），https://arxiv.org/abs/2406.11816