StreamArena：面向持续交互与长时序的智能体流式视频理解 StreamArena: Toward Continuous, Interactive, and Long-Horizon Agentic Streaming Video Understanding
首个联合评估四项能力的小时级流式视频基准，配合双层解耦的StreamMind架构
前置知识
流式视频理解（Streaming Video Understanding）
指智能体持续、在线地摄入无界的音视频流，在视频不断播放的同时自主整合历史记忆、实时感知当前事件、并在没有用户提示时也能主动介入的系统范式。与传统逐轮（turn-based）模型预先把视频切成片段、被动等待用户提问不同，流式理解强调因果连续性：物理事件不会按预设的时间边界或用户触发发生，系统需要不间断地处理 2 fps 甚至更高频率的帧流，并随时响应或主动发起交互。其核心挑战在于维持小时级的多模态记忆并保持低延迟。
本文的整个基准和架构都围绕流式视频理解展开，理解这一范式与传统离线视频问答的根本区别，是把握论文问题定义和方法设计的前提。
多模态大语言模型（MLLM）
能够同时处理图像、视频、音频和文本的大语言模型，例如论文中使用的 Qwen3.5-397B-A17B、Gemini 3.5 Flash、Kimi-K2.6 等。这类模型通过视觉/音频编码器把多模态输入映射到与文本对齐的 token 序列，再用 Transformer 做推理生成。在流式场景中，MLLM 既要对当前帧和同步音频做实时感知，又要在收到历史性问题时召回过去的视觉证据，是本文各架构组的共同骨架。
论文比较了五类系统，几乎全部以 MLLM 为骨干，理解 MLLM 的工作方式和它在流式场景下的延迟来源（采样、编码、推理），是理解 StreamMind 为何要把记忆构建移出响应关键路径的关键。
主动交互（Proactive Interaction）
指智能体在没有收到新用户提示的情况下，自主监测某个未来条件、并在该条件发生时主动发起响应的能力。论文中用户先注册一条监测指令（如「当 XiaoYe 带 Moli 去吃冰淇淋时告诉我 start」），之后系统自行在流中巡查，直到目标事件出现才发出提醒。这种能力要求系统有持续 vigilance（警觉），与传统的「问—答」被动模式有本质区别，是流式智能体区别于普通视频问答模型的核心标志之一。
主动交互是 StreamArena 评估的四项能力之一，也是 StreamMind 之所以需要独立的 Monitor Worker 的根本原因，理解它才能理解为什么响应延迟和主动触发需要两条不同的执行路径。
因果访问与双重时间标注（Causal Access & Dual Temporal Grounding）
因果访问指模型在回答 $t_q$ 时刻的查询时，只能看到 $t_q$ 之前的视频内容，不允许偷看未来帧，这模拟了真实部署中的时序约束。双重时间标注则要求标注者为每个问题（query）和每段支撑证据（evidence）都单独打上时间戳，从而既能强制因果访问，又能度量「证据到查询的时间差」（evidence-to-query gap），还能明确规定主动响应应在何时发生。两者结合使得评测无法靠只看最近几帧或语言先验来作弊。
论文反复强调已有基准因缺乏因果访问和时间标注而被「最近帧捷径」击败，理解这两个概念才能明白 StreamArena 的标注协议为什么这么严格，以及为什么简单基线能刷高传统分数。
双层解耦架构（Two-Tier Decoupled Architecture）
一种把「延迟敏感的交互」和「长时序的认知计算」分离到两层、由功能特化的 worker 独立调度的系统设计。前端层（frontend tier）负责与用户交互和任务派发，包含 Front Worker 和若干 Monitor Worker；后端层（backend tier）负责构建持久记忆和检索密集的推理，包含 Memory Writer、Router、Recall、Search 等 worker。各 worker 通过按需请求通信、共享只含「到目前为止观测」的记忆。这种解耦让前端能即时响应，又在需要时访问长时序证据。
StreamMind 的全部创新都建立在这个架构之上，理解 worker 分工和异步记忆构建，是理解论文方法、延迟下降和四项能力提升机制的钥匙。
研究动机
把自主多模态智能体部署到机器人、可穿戴设备等持续真实环境中，要求它们能摄入无界音视频流并维持小时级的记忆，但现有评测严重滞后于这种需求。绝大多数评测依赖短片段（多为 3 到 18 分钟）和选择题格式，这种设计让一个只看最后四帧的极简基线就能匹敌甚至超过复杂的流式模型——语言先验和答案选项暴露了大量捷径。即便是 Doubao、GPT-Realtime-2 这类低延迟系统，也仍困在「被动等待提示—响应」的循环里，缺乏自主发起交互的警觉。已有基准虽然分别在长视频理解、在线感知或主动响应上有价值，但普遍把它们割裂评估；而且许多流式基准用短片段加选择题，使最近帧捷径（recency shortcut）大行其道。实验中 AURA 在五分钟内的历史准确率尚有 25.4%，但超过 30 分钟就跌到 10.5%，VST 把过去视觉证据压成文本摘要后历史回顾只有 21.2%，ThinkStream 在感知/回顾/主动/工具四项上仅得 8.0%/7.5%/1.2%/1.8%——这些数据清楚地揭示了现有设计在持续交互与长时序多模态理解之间的根本张力。
本文的目标是本文的双重目标是：一方面建立一套能暴露当前流式系统短板、并指导未来模型发展的评测框架；另一方面提出一种切实可行的架构来缓解「持续交互」与「长时序多模态理解」之间的张力。具体而言，作者希望基准能覆盖真实时间尺度（小时级而非分钟级）、强制因果访问、用开放式生成而非选择题消除答案线索，并联合评估四项部署能力：实时感知、历史回顾、主动交互与多模态工具使用。在方法侧，作者希望构造一种既能即时低延迟响应用户查询、又能在没有提示时主动监测未来条件，同时还能在小时尺度上保留可检索的多模态证据的架构，最终在共享骨干下大幅降低查询到回答的延迟而不显著牺牲准确率。
与已有工作不同的是，本文的独特切入角度体现在评测与架构两条线。在评测上，StreamArena 是第一个在持续音视频流上联合评估上述四项能力的基准：它有 243 段平均 88.8 分钟的全长视频（远长于现有流式基准的 3 到 18 分钟），采用开放式问答避免语言捷径，并通过双重时间标注强制因果访问、度量证据到查询的间隔。在架构上，与「只保留最近观测」（如 AURA）、「把过去压成文本」（如 VST）、「在模型内部反复压缩」（如 StreamForest/ThinkStream）三类路线不同，StreamMind 选择双层解耦：前端负责交互和监测，后端异步构建持久的多模态记忆并按需检索，从而把记忆构建和多步推理移出响应关键路径。这种「持久状态复用」的视角是与已有方法的本质区别。
核心方法
本文方法由「基准」和「架构」两部分构成。StreamArena 的构建思路是：从七个领域采集至少 60 分钟、至少 1080p、含中英文音频的 YouTube 视频；30 名博士级标注者为每段视频起草约 20 组多轮问答，两组独立交叉验证者仅依据视频作答并订正，第三组盲审；三阶段流程删去约 27% 草稿，最终保留 243 段视频、共 3,646 组开放式问答，覆盖 263 个感知、877 个回顾、1,732 个工具、774 个主动任务。StreamMind 的整体技术路线是双层解耦：前端层含 Front Worker（交互网关与派发器）和若干 Monitor Worker（各自独立生命周期地监测未来条件）；后端层含 Memory Writer（把帧和语音持续转化为分层事件、实体关系图与关键帧的 Memory Bank）、Router Worker、Recall Worker（内容寻址检索）和 Search Worker（图像检索+外部文本搜索）。系统以 2 fps 顺序摄入帧，连续流驱动监测与记忆构建，事件驱动消息才激活后端召回或搜索，前端非思考、后端思考以兼顾低延迟与深度推理。
核心创新点是「把延迟敏感的交互与长时序认知彻底解耦」。与已有方法的本质区别在于：recent-window 方法（AURA、MiniCPM-o）丢弃了窗口外的观测，五分钟外就大幅退化；text-summary 方法（VST）把视觉证据压成文字，丢失细粒度视觉信息；model-internal 压缩方法（StreamForest、ThinkStream）在模型内反复压缩，长期细节难保留。StreamMind 不走这三条路，而是让 Memory Writer 在查询到达之前就异步把流固化成结构化的多模态记忆（分层事件 + 实体关系图 + 关键帧），查询到来时 Recall/Search 只按需检索相关片段。这使「持久状态复用」成为可能：响应延迟只包含查询触发的路由、召回、搜索和推理，而不含早先完成的连续处理，因此能在保留 89.7% 池化准确率的同时把延迟降低 66.2%。此外，功能特化的 worker 各自独立调度（如 Monitor Worker 每秒唤醒一次），让主动警觉不占用 Front Worker。
方法步骤详情
方法分四步。基准构建：标注者起草约 20 组带时间戳的多轮问答，两组交叉验证者凭视频订正，第三组盲审后保留约 73% 草稿。记忆构建：Memory Writer 把帧与语音固化为 Memory Bank——分层事件层聚合 micro→macro→super 事件，实体关系图跨时间链接人、物、地点，事件保留关键实体、时间边界与代表帧。前端派发：Front Worker 在「直接作答」「委托后端检索」「实例化 Monitor」三路径中选择；Monitor 每秒唤醒、条件满足才通知前端。后端检索：Router 把请求分解为 Recall/Search 子任务并发执行，Recall 做内容寻址检索，Search 做图像与外部文本检索，由 Router 居中调解，支持先召回关键帧再以帧为锚做搜索的级联。指标上，准确率 $\mathrm{Acc}=\frac{1}{N}\sum_i\mathbf{1}[\mathrm{Judge}(\hat{a}_i,a_i^{*})=1]$，主动准确率要求触发时刻与内容同时正确（$\mathrm{TimeOK}$：$-0.5\,s\le t^{pred}-t^{gt}\le 2.0\,s$），延迟 $L=t_{resp}-t_{query}$。
技术新颖性
技术新颖性体现在多个层面。评测上，StreamArena 是首个在持续音视频流上联合评估四项能力的小时级基准，平均时长 88.8 分钟远超现有流式基准；它坚持开放式问答并用双重时间戳强制因果访问，使「只看最后四帧」之类的捷径无处遁形；其主动评测还要求触发时刻和内容同时正确，并由 Gemini 3.1 Pro 做严格的事实核心二元裁决。架构上，StreamMind 首次把流式理解明确拆成前端交互/监测与后端记忆/检索两个独立调度的层级，并用功能特化的 worker（Front、Monitor、Memory Writer、Router、Recall、Search）替代单体模型；其中「持续摄入构建记忆、按需召回检索」的状态复用范式是把延迟下降 66.2% 的根本来源。此外，Router 居中、Recall 与 Search 不直接通信但可级联（先召回关键帧再以帧为锚做图像检索）的设计，是把工具使用相对提升 228.1% 的关键机制。整体上，这是把「持久多模态记忆、主动监测、检索」视为互补组件而非可互相替代的时间上下文形式的系统化尝试。
实验结果
主结果（Table 3）显示 StreamMind 在流式系统中四项能力全部第一：相对最强流式基线，RTP +58.4%、HR +53.7%、Tool +228.1%、Proactive +54.7%，数值为 44.5%/34.9%/56.1%/11.6%（人类参考 91.8%/95.2%/91.5%）。HR 分层（L1–L4，≤5/5–15/15–30/>30 min）为 31.5/46.7/34.6/17.1，而 AURA 从 25.4% 跌到 10.5%，证明 recent-window 路线在远距证据上崩溃。延迟（Table 4）方面，共享 Qwen3.5-397B-A17B 下 StreamMind 把 RTP/HR/Tool 延迟从 83.8/117.4/62.8 秒降到 12.9/30.7/28.1 秒，池化延迟 81.4→27.5 秒（−66.2%），保留 89.7% 池化准确率。诊断（Table 5）揭示多模态必要性：仅 ASR 在 RTP 仅 4.2%、仅视觉 26.8%、视觉+ASR 32.4%；图 3 表明加帧主要利好 HR、提分辨率全面提升、思考模式提升 HR/Tool 但略降 RTP。HR 从 L2 到 L4 降 63.4%，说明长时序记忆是效用估计而非容量问题。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 实时多模态感知（RTP） | 准确率（%） | StreamMind 44.5% | 最强流式基线（AURA 28.1%） | 相对提升 58.4% |
| 历史回顾（HR） | 准确率（%） | StreamMind 34.9%（L1–L4：31.5/46.7/34.6/17.1） | 最强流式基线（VST 21.2%；AURA 从 25.4%→10.5%） | 相对提升 53.7%，且各时间桶相对增益 24.0%–73.0% |
| 多模态工具使用（Tool） | 工具使能的端到端准确率（%） | StreamMind 56.1% | ThinkStream 1.8%（最强对应流式基线） | 相对提升 228.1% |
| 主动交互（Proactive） | 内容与触发时刻同时正确的准确率（%） | StreamMind 11.6%（L1–L3：16.6/9.5/7.5） | ThinkStream 1.2%（最强对应流式基线） | 相对提升 54.7% |
| 查询到回答延迟（共享 Qwen3.5-397B-A17B） | 平均延迟（秒，越低越好） | StreamMind 池化 27.5s（RTP 12.9/HR 30.7/Tool 28.1） | 离线 Qwen3.5-397B-A17B 池化 81.4s（RTP 83.8/HR 117.4/Tool 62.8） | 相对降低 66.2%，保留 89.7% 池化准确率 |
局限与改进
作者坦承的局限主要有三。其一，长时序记忆仍显著退化：StreamMind 的 HR 从 L2 的 46.7% 降到 L4 的 17.1%，跌幅达 63.4%，作者明确指出这「不是容量问题」，而是在摄入阶段未来查询未知、难以估计哪些多模态细节值得以何种保真度保留，这正是其自述的主要未来工作。其二，骨干规模带来的比较不公平：StreamMind 用的是 Qwen3.5-397B-A17B 这样的大模型，因为其 worker 需要可靠的指令跟随来做结构化记忆、工具路由和条件监测；而 AURA、MiniCPM-o、StreamForest、ThinkStream 等基线用的是更小的微调骨干，因此作者并不把每一项准确率增益都归因于架构本身，只能在与同骨干离线 Qwen3.5-397B-A17B 的延迟对比中隔离出系统层面的权衡。其三，主动交互没有离线对照物（它要求在无新查询下持续监测），且其绝对准确率（11.6%）距离人类 91.5% 仍有巨大鸿沟。此外，评测依赖 Gemini 3.1 Pro 作为 LLM 裁判，开放式问答的判分本身存在主观性与潜在偏差，论文未深入讨论裁判模型自身的稳健性。
独立分析的弱点
第一个弱点是长时序记忆的效用估计缺失。当前 Memory Writer 在摄入时并不预知哪些细节会被未来的问题问到，只能无差别地固化事件，导致 L4（>30 分钟）桶大幅退化；改进方向是引入从检索结果中学习的机制，估计证据效用并自适应地以更高保真度保留不确定的多模态细节，例如可学习的关键帧选择或基于不确定性的记忆写入策略。第二个弱点是骨干规模与系统设计的混淆。StreamMind 与小骨干基线的比较同时混淆了模型容量和架构两因素，难以单独评估每个 worker 的贡献；改进方向是用同一中小骨干做组件消融，并报告 worker 级别的边际增益。第三个弱点是主动交互的绝对水平过低（11.6%）。Monitor Worker 每秒唤醒并依赖条件判断，但 L3（>4 分钟）仅 7.5%，说明长时间跨度的条件追踪仍不稳定；改进方向是引入专门的时序条件表示和事件触发的层次化监测。第四个弱点是基准的标注是静态快照式的、对真实部署的开放性覆盖有限，例如工具任务被限定为 Google Search；改进方向是支持更丰富的工具集、动态环境和真实低延迟的端到端流式评测。
未来方向
作者明确提出的方向包括：从检索结果中学习以估计证据效用、在摄入时自适应保留不确定的多模态细节（adaptive fidelity）；评估更小的骨干以及 StreamMind 各个架构组件的独立贡献；以及面向真实「常驻」多模态智能体（机器人、可穿戴设备）的持续处理效率优化。基于本文成果可延伸的方向包括：把双层解耦架构扩展到更多模态（如深度、触觉、传感器流）和更复杂的工具生态；研究记忆的遗忘与压缩策略以平衡小时级保留与存储成本；将主动交互与强化学习结合，让智能体学习「何时主动开口」的最优策略；探索把 StreamMind 的状态复用范式迁移到其他需要长上下文的任务（长文档理解、软件智能体）；以及用 StreamArena 作为 testbed 系统比较记忆机制（检索式、参数式、外部知识库）的边界。
复现评估
复现性中等偏上但不完整。论文标题标注了 Website、Code、Benchmark 三个资源链接，表明作者有意公开基准与代码，但本文为 v1 预印本，须以最终发布为准。数据侧统计完整（243 段视频、七领域、88.8 分钟均长、3,646 组问答、四类能力题量、HR 与 Pro 分层、证据到查询间隔中位 12.1 分钟），并详述三阶段标注与质检流程。评测协议侧明确 Gemini 3.1 Pro 裁判、TimeOK 容忍区间 $-0.5\,s\le t^{pred}-t^{gt}\le 2.0\,s$、各系统帧预算（StreamMind 2 fps 持续摄入，离线最多 128 帧，AURA/MiniCPM-o 取最近 30 秒，VST 最多 384 帧，StreamForest 最多 2,048 帧）。方法侧给出 worker 分工与数据流，但缺少 prompt 模板、写入频率、检索索引等工程细节。算力上依赖 Qwen3.5-397B-A17B 大骨干及多并发 worker，复现完整系统需相当 GPU 资源；端到端工程复现难度较高。
论文图表
