VideoSeek: Long-Horizon Video Agent with Tool-Guided Seeking

读前先抓住结论

VideoSeek 这篇论文解决的不是“怎样训练一个更强的视频多模态模型”，而是一个更工程、更像 agent 的问题：当视频很长、问题很具体时，模型到底需不需要把整段视频都看完？ 论文的答案很明确：很多长视频问答并不需要密集解析全视频，真正需要的是沿着视频的时间线、叙事线和因果线，主动寻找对答案关键的证据。

它的核心方法是把视频理解改写成一个长程 think-act-observe 循环。模型每一轮先根据问题和已收集证据思考，再选择一个视频工具行动，随后把工具返回的观察加入轨迹。这个循环让模型可以先粗看全局，再跳到可能相关的时间段，最后只在必要位置做短片段精查。换句话说，VideoSeek 把“看视频”从一次性输入变成了一个可规划、可纠错、可停止的寻证过程。

论文最值得记住的贡献是三件事。第一，它提出了一个轻量工具箱：<overview> 建立全局故事线，<skim> 快速扫候选区间，<focus> 对短片段做细粒度确认。第二，它不依赖预先构建的完整视频数据库，而是让 agent 在完整对话轨迹里保留观察并动态调整下一步。第三，实验不是只看准确率，而是把准确率和平均处理帧数放在一起读，强调“用少得多的帧取得强结果”。

实验结果很锋利：在 LVBench、Video-MME、LongVideoBench 和 Video-Holmes 上，VideoSeek 通常只看几十帧，却能超过或接近看几百、几千甚至上万帧的方法。比如 LVBench 加字幕设置中，它达到 76.7% 准确率，只用 27.2 帧；相比同样用字幕的 GPT-5 基线，准确率高 10.2 个点，同时帧数少约 93%。这不是一个小修小补式优化，而是在视频 agent 的计算范式上换了问题入口。

不过这篇论文也不该被理解成“少看帧永远更好”。VideoSeek 有两个隐含前提：视频里存在可利用的逻辑流，且 thinking model 能判断下一步该看哪里。如果视频高度随机、问题要求全局统计，或者底层模型没有足够强的推理和工具规划能力，主动寻证就可能过早停止或错过关键证据。

为什么长视频不能只靠密集解析

传统视频语言任务通常把视频 $\mathbf{X}$ 和问题 $\mathbf{Q}$ 一起交给模型，让模型直接生成答案 $\mathbf{Y}$。这在短视频、单事件问题里很自然，因为模型可以把有限帧数压入上下文。但长视频带来的麻烦不是“多几帧”这么简单，而是视觉输入、字幕、时间关系和事件链都会迅速膨胀。模型如果先均匀抽帧，再把每个片段都描述一遍，成本会跟视频长度一起上升。

近年的 Video-LMM 往往仍是单次前向范式：选一批帧，编码，回答。视频 agent 则进一步加入检索、关键帧选择、多粒度描述或数据库构建，但很多方法仍然要先对整段视频做昂贵预处理。论文举的典型例子是 DrVideo 按 0.2 FPS 把长视频转成文本长文档，DVD agent 和 MR. Video 则以 2 FPS 构建多粒度视频描述。这类方法能提高覆盖率，却把“可能有用的信息”全部提前加工了。

VideoSeek 的反问是：如果一个问题只需要视频中很小一段证据，为什么要先为整段视频付费？ 论文在 LVBench 上观察到，超过 80% 的问题可以通过检查原视频少于 5% 的内容回答。这个观察是整篇方法的动机根部：长视频理解的瓶颈不只是模型能力，也包括证据采样策略。

这里的“视频逻辑流”是论文中很重要但容易被读薄的概念。它不是一个显式训练出来的新模块，而是视频天然包含的时间、叙事和因果结构：人物先进入房间再拿起物体，字幕先提到某个线索后镜头切向场景，悬疑短片里的动作和结果存在因果关系。人类看视频时会利用这些结构跳看，VideoSeek 则把这种行为转成 agent 工具调用。

这个概念也解释了为什么“少看帧”不是随机抽样。随机少看帧会牺牲召回，因为关键证据可能被跳过；沿逻辑流少看帧则是在用已有线索提高下一次观察的命中率。比如问题问“主角为什么离开房间”，agent 不需要平均查看所有户外镜头，而是应先找人物进入、对话冲突、动作转折等可能解释原因的片段。VideoSeek 的工具调用就是把这种选择显式化。

从系统角度看，密集解析范式更像离线索引：先把视频压成尽可能完整的文本或多粒度记忆，再让回答模型检索。主动寻证范式更像在线调查：每次只为当前假设收集下一块证据。前者适合反复查询同一个视频库，后者适合单次或少量查询、视频很长、问题目标明确的场景。VideoSeek 的实验设置更接近后者，因此它的优势集中体现在平均查看帧数上。

所以 VideoSeek 相对相关工作的定位可以这样理解：它不和 Video-LMM 比谁的视觉编码器更强，也不把自己限制在固定 coarse-to-fine 搜索树里；它更像是在问，已有强推理模型如果配上合适工具，能不能用更少视觉观察完成长视频任务？ 这让它自然落在“工具使用”和“长程 agent workflow”的交叉点。

方法总览：把视频问答改写成寻证轨迹

论文的方法部分先做了一个形式化改写。传统视频问答建模的是 $p(\mathbf{Y} \mid \mathbf{X}, \mathbf{Q})$：给定视频和问题，直接预测答案。VideoSeek 认为这不足以描述长视频任务，因为真正的解题过程包含许多中间动作：先看哪里、看到了什么、还缺什么证据、什么时候停止。

因此论文把任务改写成预测一条轨迹 $\tau$ 和最终答案 $\mathbf{Y}$。每个时间步 $t$，agent 产生一个三元组 $\langle z_t, a_t, o_t \rangle$。其中 $z_t$ 是内部推理，$a_t$ 是要执行的动作或工具调用，$o_t$ 是工具返回的观察。多个三元组串起来，就是这次视频问答的寻证历史。

这个公式的实际含义很具体：如果轨迹 $\tau$ 选得好，答案生成阶段就不用在海量无关帧里找线索；如果轨迹选得差，即使最后的回答模型很强，也可能缺少关键证据。VideoSeek 的方法重点正是改善 $p(\tau \mid \mathbf{X}, \mathbf{Q})$，让轨迹更短、更相关、更像人类带着问题找证据。

这里还有一个容易忽略的建模选择：论文没有把 $\tau$ 视为不可见的内部变量，而是让它由 thought、action、observation 组成，并在对话历史中积累。这意味着轨迹既是推理过程，也是下一轮决策的输入。每个工具返回的观察不只是给最后答案使用，还会改变后续行动分布。例如 overview 发现某段出现车祸线索，下一轮 skim 就可能围绕这个时间段；focus 发现线索不充分，后续又可能回到更宽区间搜索。

这种轨迹式建模把长视频任务拆成了两个难度不同的子问题。第一个子问题是“怎样得到足够好的证据集合”，它依赖工具和 planning；第二个子问题是“怎样用证据回答问题”，它依赖语言与多模态推理。密集抽帧把两个问题混在一起，模型既要在上下文里找证据，又要完成推理。VideoSeek 则把找证据显式拆出来，让错误更容易定位：是工具看错了、位置找错了，还是最终推理错了。

这张总览图左侧有一个关键视觉细节：红色表示已查看帧，灰色表示未查看帧。VideoSeek 的目标不是覆盖所有灰色区域，而是让红色帧集中在最可能支撑答案的位置。也就是说，它追求的是证据密度，而不是帧覆盖率。

这种设计还有一个隐含收益：中间轨迹本身就是一种可解释结构。密集解析方法可能给你一个很长的视频描述，但很难说明“模型为什么去看这几处”。VideoSeek 的轨迹记录了每次 thought、action 和 observation，读者可以沿着轨迹检查它是否真的在追踪问题相关线索。

对开发者来说，这种结构还方便做错误分析。若最后答案错了，可以回看轨迹：overview 是否给了错误 storyline，skim 是否没有覆盖真正片段，focus 是否选得太窄，还是 answer action 太早触发。相比一个端到端视频模型直接输出错误答案，这种 agent workflow 更容易插入日志、人工审计、工具替换和策略改进。

当然，轨迹不是免费午餐。每一轮工具调用都会增加调度和模型调用开销，最终 runtime 未必总是低于一次性抽帧模型。论文附录也承认 runtime 受网络延迟、后端 GPU、API 调度和视觉语言 tokenization 影响。因此 VideoSeek 的效率论证主要建立在帧数和 token 消耗上，而不是绝对墙钟时间。

三件工具：overview、skim、focus

VideoSeek 的工具箱看起来很简单，但设计重点在“时间粒度分工”。如果只有一个工具，agent 很容易陷入两种坏情况：要么一直粗略看，找不到细节；要么过早精查，浪费预算在错误位置。三个工具把这种取舍拆开，让模型可以先建立地图，再缩小区域，最后确认细节。

<overview> 是全局工具。它在整段视频上均匀采样固定数量帧，生成简短描述，让 agent 快速知道视频大概发生了什么、有哪些人物和场景、可能有哪些事件转折。论文强调 overview 通常在开始阶段使用，因为它给后续探索提供“地图”。如果没有这个地图，后面的 skim 和 focus 就像在没有坐标的时间线上盲跳。

<skim> 是区间工具。当 agent 已经推测某个时间段可能相关，但这个时间段仍然太长时，skim 会用较少帧快速检查该区间，并突出和当前查询最相关的内容。它的作用不是给出最终答案，而是帮助 agent 决定“这个方向值得继续挖吗”。这正好填补 overview 和 focus 之间的粒度空档。

<focus> 是验证工具。它针对较短 clip，以更高帧率做细粒度分析，适合读文字、认人物、数物体、确认动作发生的瞬间。它在工具箱里最接近“证据锤定音”的角色：前两类工具把搜索空间缩小，focus 则用更贵但更准的观察来降低最后回答的风险。

工具参数由一个尺度因子 $\alpha$ 控制。论文设置中，<overview> 采样 $16\alpha$ 帧，<skim> 在至少 $4\alpha$ 秒的片段上采样 $4\alpha$ 帧，<focus> 以 1 FPS 处理最多 $4\alpha$ 秒的短片段。附录分析显示，不同 benchmark 的合适 $\alpha$ 不同：LVBench 视频更长，最终设为 4；其他三个 benchmark 设为 2。

这组参数让 VideoSeek 具备一个很实用的工程性质：它不需要为每个视频都写死固定帧预算，而是可以用 $\alpha$ 调整整体观察强度。更长、更复杂的视频可以给略高预算；短视频或字幕线索充分的任务则可降低预算。

工具设计还有一个不太显眼但很重要的点：这些工具都围绕“当前 query”运行，而不是只做通用视频描述。尤其是 skim 和 focus，会带着 agent 生成的子查询进入指定时间段。这意味着 VideoSeek 的观察不是中立摘要，而是为当前问题服务的证据提取。

这也解释了为什么工具输出应当尽量结构化。一个好的 overview 不应该只是“视频里有很多人在活动”，而应给出时间段、场景变化、关键人物和可能的事件节点；一个好的 skim 应该把候选片段中与问题相关的时刻标出来；一个好的 focus 应该回答 agent 自己提出的局部问题。工具返回越像可引用证据，轨迹就越有用；工具返回越像泛泛 caption，下一轮 planning 就越容易漂移。

在工程实现上，三类工具可以不必都由同一个大模型承担。overview 可以用便宜模型或快速视频 captioner 生成粗线索，skim 可以结合字幕检索、镜头切分或轻量视觉模型，focus 再调用昂贵的强多模态模型。论文实现中使用 GPT-5 解释视觉内容，但方法本身是 model-agnostic 的，关键是工具之间存在清晰的成本和粒度梯度。

算法与实现细节

Algorithm 1 把上面的想法落成了一个可执行 loop。它接收用户问题 $\mathbf{Q}$、视频 $\mathbf{X}$、系统指令 $\mathcal{I}$、thinking model $\theta_{\text{think}}$、工具箱 $\mathcal{T}$ 和最大轮数 $N$。输出是最终答案 $\mathbf{Y}$。论文默认最大 turn limit 是 20，默认 thinking model 是 GPT-5。

1Require: User query $\mathbf{Q}$; video $\mathbf{X}$; system instruction $\mathcal{I}$; thinking model $\theta_{\text{think}}$; toolkit $\mathcal{T}$; max turn limit $N$.2Ensure: Answer $\mathbf{Y}$.3Initialize reasoning trajectory $\tau \leftarrow \langle \mathcal{I}, \mathbf{Q} \rangle$4Initialize toolkit $\mathcal{T} \leftarrow \mathcal{T} \cup \texttt{<answer>}$5$\mathbf{Y} \leftarrow \varnothing$6for $t = 1$ to $N$:7  $(z_t, \alpha_t) \leftarrow \theta_{\text{think}}(\tau)$  # reasoning and tool-planning8  if $|\alpha_t| = 1$ and $\alpha_t = \texttt{<answer>}$:9    $\mathbf{Y} \leftarrow \textsc{ParseAnswer}(\alpha_t)$10    break11  $o_t \leftarrow \textsc{CallTools}(\alpha_t, \mathbf{X}, \mathcal{T})$12  $\tau \leftarrow \tau \cup \langle z_t, \alpha_t, o_t \rangle$13if $\mathbf{Y} = \varnothing$:14  $\tau \leftarrow \tau \cup \mathcal{I}_{\text{answer}}$15  $\mathbf{Y} \leftarrow \theta_{\text{think}}(\tau)$16return $\mathbf{Y}$

第一步初始化 $\tau \leftarrow \langle \mathcal{I}, \mathbf{Q} \rangle$ 很关键。VideoSeek 不把状态散落在外部数据库里，而是把系统规则、用户问题、历史 thought、工具调用和观察都累积在轨迹中。这样每次 thinking model 看到的是完整上下文，可以判断哪些证据已经看过，哪些结论还不稳。

第二步把 <answer> 加入工具箱，说明“回答”本身也是一种行动。这个设计能避免 agent 被迫每轮都调用视频工具。当它认为证据足够时，就应该停止寻证并输出答案。很多 agent 的成本失控，恰恰来自缺少可靠停止机制；VideoSeek 至少在算法层面显式把停止纳入动作空间。

第三步是主循环。thinking model 输出两样东西：内部推理 $z_t$ 和动作计划 $\alpha_t$。动作计划可以是 <overview>、<skim>、<focus> 或 <answer>。如果是唯一的 <answer>，算法解析答案并结束；否则就调用工具，把新观察 $o_t$ 追加回轨迹。

这里最容易误解的是：VideoSeek 不是固定顺序地 overview -> skim -> focus。论文案例明确展示，它可以先 overview，再 focus，如果证据不足又 skim 扩大搜索。也就是说，工具粒度提供可能性，真正的控制策略由 thinking model 根据当前轨迹决定。

如果循环走满还没有答案，算法会追加一个直接回答指令 $\mathcal{I}_{answer}$，让模型基于已有轨迹合成答案。这个兜底不是为了鼓励猜测，而是防止 agent 在长视频里无限寻证。工程复用时，这个分支应该配合“不确定时说明依据不足”的输出规范，否则容易把不充分证据包装成自信答案。

附录里的系统 prompt 也值得看。它把 agent 行为拆成 Role、Environment、State、Workflow、Toolkit 和 Operational Rules 六部分。Role 规定它是高效视频理解系统；Environment 定义视频、字幕和问题；State 定义历史轨迹；Workflow 定义 Thought -> Action -> Observation；Toolkit 定义工具；Operational Rules 则约束证据、时间戳、不猜测和工具调用纪律。

这些 prompt 细节说明 VideoSeek 并不只是“给模型几个函数”。系统指令明确要求 agent 像谨慎的人类观看者一样，从部分观察和视频逻辑结构中回答问题；状态部分把历史轨迹定义成 thought-action-observation 列表；操作规则要求收集带时间戳的支持证据、显式检查充分性、在不确定时避免猜测。换句话说，prompt 在这里承担了 policy shaping 的作用：它把工具能力转化成相对稳定的寻证行为。

初始用户 query 也不是简单把问题发给模型，而是注入视频元信息，例如时长和可用字幕。工具调用 prompt 则包含起止时间、采样时间戳、字幕以及工具特定指令。这个设计让每次工具调用都有明确边界，避免模型在“想看哪里”和“实际看到哪里”之间产生混淆。对长视频 agent 来说，时间戳是一等公民；没有时间戳，轨迹很难成为可复查证据链。

1tool_budget = {2    "overview": {"frames": 16 * alpha, "scope": "full_video"},3    "skim": {"frames": 4 * alpha, "min_segment_seconds": 4 * alpha},4    "focus": {"fps": 1, "max_clip_seconds": 4 * alpha},5}6 7trajectory = [system_instruction, user_query]8for turn in range(max_turns):9    thought, action = thinking_model(trajectory)10    if action.name == "answer":11        break12    observation = call_video_tool(action, video, tool_budget)13    trajectory.append((thought, action, observation))

这段伪代码展示了复用 VideoSeek 思路时真正要实现的对象：一个可累积的轨迹、一个按查询调用的视频工具层、一个能在证据充分性和下一步动作之间做判断的 thinking model。论文的新意不在复杂代码，而在把这三者组织成一个稳定闭环。

如果把这个算法移植到真实系统，还需要补上几类保护。第一，工具调用参数要验证，例如时间区间不能越界，focus 的片段长度不能超过预算。第二，answer action 最好要求输出引用到的时间戳或观察编号，这样能把最终答案和轨迹绑定。第三，达到最大轮数后的兜底回答应区分“有足够证据的回答”和“基于有限观察的推测”，否则用户会误以为 agent 完整检查过视频。

实验结果怎么读

实验部分有两个读法。第一，看准确率，VideoSeek 是否真的答得更好。第二，看平均处理帧数，它是否用更少视觉预算做到这件事。只看准确率会低估这篇论文，因为它真正想证明的是“主动寻证比密集解析更划算”。

长视频理解部分覆盖三个 benchmark：LVBench、Video-MME long subset 和 LongVideoBench long subset。LVBench 由 103 个小时级视频构成，包含 1549 个多选问题，强调长期记忆和扩展理解；Video-MME long 平均视频时长约 2466 秒；LongVideoBench long split 覆盖 900 到 3600 秒的视频。它们共同测试的是模型在长时间轴上定位和整合信息的能力。

在 LVBench 无字幕设置中，VideoSeek 达到 68.4%，平均只用 92.3 帧。它比 GPT-5 基线高 8.3 个点，同时只用约 24% 的帧数。更有意思的是，它接近 DVD 的 74.2%，但 DVD 使用 8074 帧，VideoSeek 只用约 1% 的帧预算。这个对比说明 VideoSeek 并不是简单地和弱模型比，而是在挑战强视频 agent 的成本结构。

LVBench 有字幕时，VideoSeek 的优势更明显：76.7% 准确率，平均 27.2 帧。字幕让视频逻辑流以文本形式暴露出来，agent 可以更容易判断该跳到哪里，因此帧数反而下降。这支持论文关于“逻辑流帮助少帧理解”的假设：当叙事线索更清楚时，视觉精查只需要用于确认关键位置。

Video-MME long 上，无字幕 VideoSeek 达到 70.1%，用 60.9 帧，超过 GPT-5 的 67.9% 和 DVD 的 67.3%。有字幕时，它达到 81.2%，只用 15.9 帧，高于 GPT-5 的 78.1% 和 Gemini 1.5 Pro 的 77.4%。这组结果说明，VideoSeek 的收益不仅出现在一个数据集上，也不仅依赖字幕；字幕只是进一步放大了逻辑流优势。

LongVideoBench long split 上，VideoSeek 达到 73.5%，平均 29.6 帧。它比 GPT-5 高 9.0 个点，比 DVD 高 4.9 个点，同时只用 DVD 和 MR. Video 约 1% 的帧数。对长视频而言，这个数字很重要：视频越长，密集解析成本越夸张，主动寻证的边际价值越大。

Video-Holmes 则测试复杂视频推理，包含 270 部人工标注悬疑短片和 1837 个问题，覆盖社会推理、意图动机链、时间因果推断、时间线分析、多模态线索推理、物理异常推理和核心主题推断。VideoSeek overall 达到 47.3%，平均只用 42.7 帧，超过 GPT-5 的 44.1% 和 Gemini 2.5 Pro 的 45.0%。它在 SR、TA、MHR、CTI 上是最高，TCI 第二。

这个结果的意义不只是“又赢了一个表”。Video-Holmes 的问题常常需要把分散线索串起来，例如人物动机、时间顺序、视觉暗示和剧情反转。VideoSeek 的 think-act-observe 轨迹正适合这类任务，因为每轮观察都可以改变下一步的搜索策略。它不是一次性把视频变成固定表示，而是在推理过程中逐步补证据。

不过，Video-Holmes overall 的绝对数值仍然只有 47.3%。这提醒我们：VideoSeek 改善的是搜索与证据利用方式，不代表复杂视频推理已经被解决。对于悬疑、隐喻、反事实或需要常识补全的问题，底层模型的推理能力仍是瓶颈。

读这些结果时还要注意，平均帧数不是每个样本的固定上限，而是 agent 在不同问题上动态使用工具后的统计。简单问题可能 overview 后就能回答，困难问题可能多次 skim 和 focus。这个分布式预算是 agent 方法的优势之一：它可以把计算花在困难样本上，而不是给所有视频同样多的帧。

此外，字幕条件下帧数显著减少，不应被解读为“视觉不重要”。更准确的解释是，字幕帮助 agent 定位，视觉工具负责验证。很多视频问题需要确认谁在场、物体在哪里、动作是否发生，这些仍然依赖视觉观察。字幕降低的是搜索成本，而不是完全替代视频证据。

主结果表还有一个细节：VideoSeek 并不是在所有单项上都绝对压倒所有方法。例如 LVBench 无字幕设置中，DVD 的准确率仍然更高，但它使用的帧数是 VideoSeek 的几十倍。论文真正强调的是性能和预算的联合最优，而不是每个格子都第一。对实际系统来说，这种 trade-off 往往更有意义：如果额外几千帧只换来有限准确率收益，产品侧可能更愿意选择更轻的寻证式方案。

因此，评估 VideoSeek 时最好把它看成一条 Pareto 曲线上的点。横轴是视觉观察成本，纵轴是答案准确率。密集 agent 可能靠高覆盖率取得高分，单次 LMM 可能实现简单但预算固定，VideoSeek 则试图靠主动选择把点推向左上角。论文 Figure 1 右侧正是在表达这件事：它把 standalone LMM 和 video agent 放到同一个 accuracy-frame 空间里，让效率差异变得一眼可见。

消融、成本与案例

论文的消融回答了一个关键质疑：VideoSeek 的收益到底来自哪里？是因为选帧更好，还是因为 GPT-5 本身强，还是因为工具 prompt 写得更细？三个分析分别对应视频逻辑流、thinking model、工具箱设计和中间推理。

首先是视频逻辑流。论文观察到，一旦引入字幕，VideoSeek 在 LVBench 和 Video-MME 上准确率明显提升，同时帧数显著下降。作者解释说，字幕提供了更明确的文本故事线，显式暴露了跨场景逻辑流。agent 可以借此更快定位关键区域，避免在无关画面上浪费帧。这是对“逻辑流使少帧理解可行”的直接支持。

其次是 thinking model 消融。在 LVBench 无字幕设置中，默认 GPT-5 作为 thinking model 时，VideoSeek 达到 68.4%，平均 92.3 帧，4.42 轮。换成 GPT-4.1 后，准确率降到 53.0%，帧数和轮数也下降，说明非 thinking model 可能过早自信停止。换成 o4-mini 后，准确率为 58.5%，但帧数和轮数反而更高，说明弱一些的推理能力会让更多工具调用无法转化成更好答案。

这个结果特别重要，因为它说明 VideoSeek 不是“工具越多越好”。工具只是提供观察通道，真正决定观察是否有效的是 reasoning policy：何时继续、何时收缩、何时验证、何时回答。如果 thinking model 判断力不足，agent 可能要么少看错答，要么多看仍然抓不到重点。

工具箱消融则显示，三个工具都有效，但贡献不等。完整工具箱在 LVBench 无字幕上是 68.4%。去掉 <overview> 后降到 55.1%，掉 13.3 个点；去掉 <skim> 降到 62.4%，掉 6.0 个点；去掉 <focus> 降到 63.7%，掉 4.7 个点。overview 掉点最大，说明全局故事线是后续寻证的地图。

附录的中间推理分析进一步区分了“帧选择”和“agent 推理”。作者构造 GPT-5*：让 GPT-5 使用 VideoSeek 选出的同样帧。GPT-5* 比原始 GPT-5 更好，说明 VideoSeek 的选帧确实更有信息量；但 GPT-5* 仍低于完整 VideoSeek，说明收益不只来自额外视觉证据，也来自多轮中间推理和轨迹组织。

成本方面，附录报告 LVBench 上 GPT-5 基线无字幕用 384 帧、83K token、66.1 秒；VideoSeek 用 92.3 帧、49K token、135.9 秒。有字幕时，GPT-5 用 384 帧、97K token、71.3 秒；VideoSeek 用 27.2 帧、57K token、89.7 秒。也就是说，VideoSeek 在帧数和 token 上更省，但 runtime 不一定更短，尤其无字幕时多轮调用会带来延迟。

这组数据给工程复用一个现实提醒：如果你的瓶颈是视觉 token、模型输入成本或长视频预处理，VideoSeek 很有吸引力；如果你的瓶颈是实时响应延迟，多轮工具调用可能需要异步执行、缓存、批处理或更小模型来补。

案例图的价值在于展示“reasoning before observing”。agent 不是被动接收采样帧，而是先说清楚自己缺什么，再选择工具去补。这个过程更像侦查：每一轮观察都改变下一轮搜索假设。对于需要跨时间线定位线索的问题，这种动态调整比固定帧采样更自然。

从消融和案例合起来看，VideoSeek 的有效性来自三层耦合。底层是工具粒度，保证 agent 有不同成本的观察手段；中层是轨迹记忆，保证每次观察能影响后续行动；上层是 thinking model，负责判断证据充分性和下一步方向。只保留其中任意一层都不够：有工具但无轨迹会变成孤立调用，有轨迹但无强 reasoning 会变成冗长日志，有强模型但无工具则仍受限于一次性输入预算。

这也是为什么论文没有把工具设计做得特别复杂。复杂工具未必带来更好 agent；如果工具边界不清，模型反而更难规划。VideoSeek 选择三个功能互补、语义清楚的工具，让模型容易在自然语言 reasoning 中表达下一步需求。对 agent 系统来说，工具接口的可理解性本身就是能力的一部分。

局限与复用启发

VideoSeek 的第一个局限是对视频逻辑流的依赖。论文最强的效率收益出现在问题答案集中于少数关键片段、字幕或粗略 storyline 能帮助定位的时候。如果任务要求统计全视频中所有事件，或者答案取决于大量分散且无明显叙事关联的细节，主动寻证可能漏掉证据。

第二个局限是对 thinking model 的依赖。消融已经说明，换成 GPT-4.1 或 o4-mini 后性能明显下降。这意味着 VideoSeek 的工具箱本身不是万能插件；它需要模型具备足够强的证据充分性判断、时间定位推理和停止决策能力。工程落地时，底层模型如果较弱，可能需要更明确的策略约束或外部 verifier。

第三个局限是延迟。帧数和 token 降低不等于用户等待时间一定降低。多轮 think-act-observe 会引入串行调用，尤其 focus、skim 工具背后仍要调用视觉模型。要把 VideoSeek 用在实时产品里，需要考虑工具并行、候选段缓存、字幕预处理、低成本粗模型和高成本精模型的分层。

第四个局限是评测形式。论文主要在视频 QA benchmark 上验证，指标是 accuracy 和帧数。这非常适合证明“少帧答题”能力，但还不能完整覆盖开放式视频摘要、连续监控、全局事件检索、低风险安全场景等需求。对于这些任务，少看帧可能不是目标，完整覆盖反而更重要。

第五个边界是答案可追溯性。论文展示了轨迹和案例，但 benchmark 最终仍以选择题或问答准确率为主。在真实应用里，用户常常不仅要答案，还要知道答案来自视频哪一段。VideoSeek 的轨迹天然适合做引用，但系统必须强制把最终答案绑定到 observation 和时间戳，否则 agent 仍可能把中间推理中的猜测包装成证据。

因此，复用这篇论文时不要只看平均帧数，也要设计失败时的行为。如果工具没有找到关键证据，agent 应该能说“当前观察不足以确认”，而不是为了完成任务强行回答。主动寻证的价值在于用少量高质量证据支持结论；一旦证据不足，诚实暴露不确定性比继续压缩帧数更重要。

这也是它和普通抽帧策略最大的区别：抽帧策略只决定输入，VideoSeek 同时决定输入、解释过程和停止时机，并让调试者能回看每一步证据来源。

如果要把 VideoSeek 思路迁移到自己的 agent 项目，可以先从三个抽象层复用。第一层是状态：维护完整轨迹，而不是只保留最新观察。第二层是工具：按成本和粒度拆工具，让 agent 能先粗后细、也能必要时反向扩大搜索。第三层是停止：把 answer 做成显式 action，并让模型在回答前检查证据充分性。

在非视频场景中，这套结构也有启发。长文档 QA 可以把 overview 换成目录/摘要扫描，skim 换成章节粗读，focus 换成段落精读；代码仓库问答可以把 overview 换成文件树和符号索引，skim 换成相关文件片段，focus 换成函数级阅读或测试运行。VideoSeek 的本质不是视频专用技巧，而是一种“带预算的证据搜索 agent”。

真正落地时，我会把它拆成一个可观测系统来做。每条轨迹都记录问题、工具名、工具参数、返回证据、引用时间戳、token 和耗时；每个答案都附带证据列表；每次失败都能归因到定位、观察、推理或停止。这样才能持续优化 agent，而不是只调 prompt。VideoSeek 的论文给了一个原型范式，但生产系统还需要可监控、可缓存、可回放的工程外壳。

另一个可复用启发是预算自适应。论文用 $\alpha$ 控制工具帧预算，不同数据集取不同值。实际产品中也可以根据视频长度、字幕质量、问题类型和用户延迟要求动态设定预算。例如“找某个细节”的问题可以给较小 overview 和更早 focus；“概括整段视频”的问题则不适合过度稀疏，应该提高全局覆盖。主动寻证不等于永远省预算，而是把预算和任务绑定。

部署时还可以把 VideoSeek 做成分层模式。快速模式只允许少量 overview 和一次 focus，适合低延迟问答；标准模式允许多轮 skim 和 focus，适合复杂问题；审计模式则保存完整轨迹、所有观察和引用时间戳，适合高风险场景。这样同一套 agent 协议可以服务不同成本档位，而不是为每类需求重写系统。

如果要继续研究，最自然的方向是学习更好的工具调用策略。当前论文主要依赖强 thinking model 和 prompt 规则，下一步可以用轨迹数据训练一个轻量策略模型，预测何时 overview、何时 skim、何时 focus、何时 answer。也可以引入 verifier 检查最终答案是否被足够证据支持。这样 VideoSeek 的思想会从 prompt-driven agent 进一步走向 data-driven evidence seeking。

最后，论文留给 agent 工程的一个重要判断是：上下文越长，越不应该默认把所有信息塞进上下文。 更可扩展的方向可能是让模型学会带着目标寻找证据，在每一步付出最小必要观察成本。VideoSeek 在长视频上给出了一个清晰样例：用工具把世界切成可探索的局部，用轨迹把探索变成可解释的推理链，用实验同时约束准确率和成本。