如果你最近在关注 Gemini 3.7 Flash 的多模态能力可能会刷到一个很有意思的讨论让某个智能体观看一段观众鼓掌的视频最终把鼓掌次数准确数出来。乍一听“数鼓掌次数”并不是一个复杂的任务但真正用视觉模型去实现时大多数人会踩到同一个坑——模型可以告诉你“画面中有人在鼓掌”却很难稳定地告诉你“这场掌声一共出现了几次”。这个看似细小的问题恰恰是视频理解类 Agent 走向实用化的一个缩影。如果你也想在自己的项目中落地类似的视频事件计数能力或者想搞懂 Gemini 3.7 Flash 这类轻量级多模态模型在视频场景中到底怎么用这篇文章会把背后的概念、拆解思路、代码结构以及工程排错经验一并展开。1. 为什么“数清鼓掌次数”是多模态视频理解的难题1.1 从通用问答到细粒度事件计数过去的视频理解应用大多停留在“概括一段视频在讲什么”的层面。比如给模型一段发布会录像它能够回答“主持人站在哪里”“现场气氛如何”。这种粗粒度理解本质上是在做文字摘要的多模态版本对准确率的要求没有那么苛刻。但“数清鼓掌次数”这类任务要求就完全不同。它需要模型同时做到定位“鼓掌”这个动作在什么时候发生区分一次鼓掌和多次鼓掌判断画面中多人鼓掌是不是算同一次事件判断画面切换后再次出现掌声是否属于新的鼓掌事件综合画面与声音信息避免“听到掌声但没看到动作”时的漏判。一旦把问题从“看懂”变成“数准”大模型原本以概率生成为核心的推理方式就会遇到压力。模型不能只输出一句“现场有很多人在鼓掌”它必须给出一个可以被验证的数字。1.2 用单次长视频提示很难稳定得到好结果对于很多开发者来说最自然的想法是把一段视频切分成若干帧连同“请判断总共鼓了几次掌”这样的提示一起发给多模态模型。这种做法在短视频、动作单一的片段里可能有效但放到真实视频中会遇到几个典型问题第一上下文长度有限。如果视频长达几十秒甚至几分钟高帧率抽帧会导致输入的图像数量暴涨超过模型上下文限制降低帧率又会丢失鼓掌动作的细节。第二一次性输出任务太复杂。模型需要在同一个回答中完成动作识别、时序拆分、去重、统计多条逻辑链路。多任务叠加时模型容易在某一环出错而且错误很难定位。第三鼓掌不是一个瞬时动作。一次鼓掌可能由连续的多个拍手动作组成也可能伴随欢呼声、镜头切换、多人异步鼓掌等情况。简单从画面中检测“手掌合拢”并不能直接等同于一次掌声。1.3 Agent 化视频理解带来的解题思路“智能体视频理解”并不是一个全新的模型而是一种任务组织方式。它把原来“模型单次回答”的模式扩展成“模型在循环中反复观察、判断、维护记忆并输出结构化结论”的模式。放到鼓掌计数场景中Agent 可以这样工作将长视频切分成多个短视频片段对每个片段单独判断是否出现鼓掌相关事件提取每个事件的时间点、置信度与类型汇总所有片段的结果并对相邻片段边界做去重输出最终的鼓掌次数与事件时间轴。这种设计的好处是每一个步骤的输入和输出都更清晰模型出错时也能比较快地定位。Gemini 3.7 Flash 这类主打低延迟、低成本的模型很适合被放在这种循环中被反复调用因为在 Agent 工作流中模型可能要执行几十次甚至上百次局部判断。下面我们从概念入手再给出一个可运行的最小工程 Demo。2. Gemini 3.7 Flash 与智能体视频理解基础认知2.1 Gemini 3.7 Flash 的产品定位Gemini 3.7 Flash 可以理解为 Gemini 系列中偏向“快速响应、更低推理成本”的模型版本。和追求最强综合能力的旗舰模型相比Flash 这类模型的优势是速度更快、更适合高频次调用。这里需要先提醒一点不同渠道公布的能力矩阵、接口形态和版本名称会随着时间变化。以本文写作时的技术社区讨论来看Gemini 3.7 Flash 被频繁用于多模态 Agent 的编排场景尤其是需要对视频帧、图像和文本进行反复理解的轻量级任务。具体到你的项目时请务必以官方模型文档和可用的 API 说明为准。在视频理解任务中使用 Flash 级模型并不是因为它一定比超大模型更“聪明”而是因为 Agent 场景天然需要大量小步推理。你可以把模型当作一个“每秒钟都在做判断的前端分析器”而 Agent 本身负责规划分析步骤和汇总结果。2.2 视频理解所需的多模态基础要让模型能够数清鼓掌次数前提是它具备多模态感知能力。视觉层面模型需要理解连续帧中人物的手部位置、运动趋势以及群体行为。当画面中有多个人在鼓掌时模型不是只认出一只手而是要判断整个画面是否处于“群体鼓掌”状态。音频层面拍手会产生明显的瞬态声音。真实场景中鼓掌声音往往比画面动作更容易检测但音频的问题是容易混入环境噪声、音乐、欢呼声。对于只接收图像输入的大模型来说如果无法直接读取音轨就需要 Agent 在外部调用音频分析工具来补充信息。Gemini 3.7 Flash 之所以能在这类任务中发挥作用就是因为它在视觉语言理解上有较好的基础可以接受多帧图像或短视频抽帧后的图像序列并基于提示词返回结构化判断。开发者的任务则是设计一套足够可靠的拆分与汇总机制把模型的能力嵌入到业务流程中。2.3 Agent 工作流如何组织视频输入一个视频理解 Agent 通常会由三个角色组成工具层负责视频解码、抽帧、音频事件检测、片段切分。模型层负责对每一个片段进行语义判断识别“是否有鼓掌动作”。编排层负责调用模型、收集结果、维护全局状态、处理跨片段的重叠问题。在工具层开发者需要决定模型的输入形式。较多实践采用的方式是低帧率抽帧把每秒钟 1 到 2 帧的图像传给多模态模型。这样既保留了动作变化的过程又控制了图片数量。模型层输出的内容尽量不要是自然语言描述而应该是结构化的 JSON 事件。例如{ events: [ { type: applause_onset, start_sec: 1.2, end_sec: 4.8, confidence: 0.93 } ] }这种输出便于编排层做进一步统计。如果你让模型直接输出“这里鼓了 3 次掌”在多个片段合并时反而会更难处理。3. 用 Agent 方式实现鼓掌计数的核心原理3.1 把“数数”拆解成可验证的子任务要实现可靠计数第一原则是不要直接让模型面对整段超长视频输出一个总数而是把任务拆解成三步。第一步是片段级动作判断。对每一小段视频模型只需要回答一个子问题这一段时间内画面上是否有人在鼓掌如果分不清动作是鼓掌还是欢呼就降级判断为“疑似”。这个子问题对模型来说足够简单。第二步是事件映射。得到“有人鼓掌”的结果后Agent 还需要知道鼓掌动作何时开始、何时结束。一次鼓掌事件可能跨越多个视频片段因此要用时间戳来标记。第三步是全局聚合。把所有片段级事件按时间顺序排列并合并相邻的事件窗口。如果不做合并同一个持续 6 秒的鼓掌过程可能被两个不同的片段各计数一次导致最终数量翻倍。3.2 分段采样与事件检测分段采样的核心是确定“每个片段看多长”。片段太短比如 1 秒模型很容易误判某个鼓掌动作的半截无法判断这次鼓掌是否已经开始片段太长比如 15 秒又会增加单次模型输入的数据量导致成本上升。对于鼓掌这类持续时间通常为 2 秒到 8 秒的动作比较稳妥的起点是 4 秒一个片段。同时为了让相邻片段之间不遗漏边界处的事件可以引入一定的重叠。例如两个相邻片段之间重叠 1 秒这样动作刚好跨越片段边界时模型能够在两个片段中分别看到完整的过程。不过重叠也会带来重复计数的问题。后面处理时需要基于事件时间戳做去重。3.3 跨镜头、多人场景下的去重策略真实会议、演出视频往往包含多个机位。镜头可能从观众席全景切到某个人的特写再切到主持人。如果单纯按画面判断同一个群体的掌声在镜头 A 中计数一次在镜头 B 中又计数一次就会放大真实次数。去重策略需要综合两条线索一方面看时间线。如果两个事件在时间上有大量重叠那么它们大概率是同一场掌声的不同视角表现。Agent 只保留最早开始的那个事件。另一方面看音频连续性。掌声通常伴随连续的声音能量峰值。如果画面切换了但音轨中的拍手节奏没有中断也应该认为这次鼓掌还在持续而不是新一次鼓掌。一个简单的判断规则可以是新事件开始时间与已有事件结束时间的间隔小于 1 秒则合并两个事件之间没有明显的静音停顿则视为同一事件画面镜头标签发生变化时不自动触发新增计数。这套规则本身不依赖模型能力而是靠工程逻辑保证稳定性。3.4 为什么 Flash 级模型适合这种高频子任务许多人看到“Agent 反复调用模型”的第一反应是会不会太慢、太贵如果每个子任务都调用旗舰级大模型确实成本很高。但换成 Gemini 3.7 Flash 这类低延迟模型后情况会好很多。Agent 视频理解应用通常有大量短小且重复的判断请求。这些请求单次输入尺寸有限问题模式固定输出格式要求明确对速度敏感对“创造性”没有要求。Flash 模型针对这类请求能做到较快的响应因此很适合承担视频 Agent 中的“重复观察员”角色。工程上可以把 Flash 模型用于片段分析与初筛把少数高难度片段交给更大模型进一步确认。这种分级策略在实际项目中很常见。4. 实战搭建一个可运行的鼓掌计数 Agent 示例4.1 项目结构与依赖这一节给出一个聚焦“编排层”的演示工程。它会模拟模型片段级判断结果并完整展示如何利用时间戳合并事件、最终输出计数。真实项目中你只需要把“模拟模型结果”替换成 Gemini 3.7 Flash 的实际多模态返回结果即可。项目结构如下video-count-agent/ ├── requirements.txt ├── config.py ├── video_helper.py ├── multimodal_client.py ├── agent_core.py └── main.py先准备依赖文件。这里只写核心依赖模型 API 的 SDK 请按你实际使用的方式补充。# requirements.txt opencv-python4.5 numpy1.244.2 配置与片段切分config.py负责集中管理演示参数。真实使用中可以把这些参数放到 YAML 或环境变量中。# config.py class Config: # 视频路径 video_path demo.mp4 # 每个分析片段的时长秒 segment_seconds 4 # 相邻片段重叠时长秒 overlap_seconds 1 # 模型推理模式。demo 模式不会真实调用外部模型。 demo_mode True # 真实模型服务名按你的服务商填写 model_name gemini-3.7-flash # 事件合并阈值秒小于该间隔的事件视为同一次鼓掌 merge_threshold 1.0video_helper.py负责从视频中切分出连续片段。演示中我们用 OpenCV 读取视频元信息并按帧区间生成片段。# video_helper.py import os import cv2 def split_video_clips(video_path, segment_seconds4, overlap_seconds1, output_dirclips): 将视频切分为带重叠的小片段。 参数 video_path: 输入视频路径 segment_seconds: 每个片段的时长 overlap_seconds: 相邻片段的重复时长 output_dir: 输出目录 返回 片段文件路径列表 os.makedirs(output_dir, exist_okTrue) cap cv2.VideoCapture(video_path) if not cap.isOpened(): raise RuntimeError(f无法打开视频: {video_path}) fps cap.get(cv2.CAP_PROP_FPS) if fps 0: fps 25.0 total_frames int(cap.get(cv2.CAP_PROP_FRAME_COUNT)) segment_frames int(fps * segment_seconds) step_frames int(fps * (segment_seconds - overlap_seconds)) clip_paths [] clip_index 0 start_frame 0 while start_frame total_frames: end_frame min(start_frame segment_frames - 1, total_frames - 1) out_path os.path.join(output_dir, fclip_{clip_index:04d}.mp4) writer None cap.set(cv2.CAP_PROP_POS_FRAMES, start_frame) current start_frame while current end_frame: ret, frame cap.read() if not ret: break if writer is None: height, width frame.shape[:2] writer cv2.VideoWriter( out_path, cv2.VideoWriter_fourcc(*mp4v), fps, (width, height), ) writer.write(frame) current 1 if writer is not None: writer.release() clip_paths.append(out_path) clip_index 1 start_frame step_frames cap.release() return clip_paths if __name__ __main__: paths split_video_clips(demo.mp4) for path in paths: print(path)这段代码的核心思路是每次从视频中读取一个segment_frames长度的片段在生成完一个片段后起始帧前进step_frames而不是完整的segment_frames这样两个相邻片段之间会有一段重叠避免边界处动作被截断。4.3 模型客户端抽象与演示数据multimodal_client.py是模型入口。在demo_modeTrue时它不会真的调用 Gemini 3.7 Flash而是返回一组预置的事件数据方便读者先跑通编排算法。接入真实模型时只需在这里实现真实请求逻辑。# multimodal_client.py from dataclasses import dataclass, field from typing import List DEMO_EVENTS [ {type: applause_onset, start: 0.5, end: 3.2, score: 0.94}, {type: applause_onset, start: 4.1, end: 6.8, score: 0.88}, # 下面这个事件与上一个间隔小于 1 秒会被合并到同一次鼓掌 {type: applause_onset, start: 5.9, end: 8.0, score: 0.76}, {type: applause_onset, start: 10.3, end: 13.5, score: 0.97}, ] dataclass class ModelEvent: event_type: str start: float end: float score: float def _parse_events(raw_events: List[dict]) - List[ModelEvent]: parsed [] for item in raw_events: parsed.append( ModelEvent( event_typeitem.get(type, applause_onset), startfloat(item.get(start, 0)), endfloat(item.get(end, 0)), scorefloat(item.get(score, 0)), ) ) return parsed def analyze_clip_with_multimodal_model(clip_path: str, model_name: str): 对单个视频片段进行事件级分析。 真实场景下这里需要完成以下步骤 1. 将 clip_path 抽帧为多张图像 2. 将图像列表与提示词一起发送给 Gemini 3.7 Flash 3. 解析模型返回的 JSON 4. 返回 ModelEvent 列表。 下面的代码只用于演示模式便于在无 API Key 的情况下跑通流程。 if model_name demo: # 演示模式返回固定的模拟事件 return _parse_events(DEMO_EVENTS) # TODO: 在这里接入真实多模态模型调用 raise NotImplementedError(请在此处实现真实模型调用)上面的代码中要注意“演示数据”只是为了测试编排逻辑并不代表真实视频一定会识别出这些事件。真实应用中模型的输出格式稳定与否非常关键。4.4 核心 Agent 编排逻辑agent_core.py是整个示例最核心的部分。它把模型返回的事件列表汇总并通过时间间隔判断是否属于同一次鼓掌。# agent_core.py from typing import List from multimodal_client import ModelEvent def merge_events(events: List[ModelEvent], merge_threshold: float 1.0) - List[ModelEvent]: 将时间上接近的事件合并为同一次鼓掌事件。 合并规则如果下一个事件的开始时间与当前事件结束时间 的间隔小于 merge_threshold则认为是同一场鼓掌的延续。 if not events: return [] sorted_events sorted(events, keylambda e: e.start) merged [sorted_events[0]] for event in sorted_events[1:]: last merged[-1] gap event.start - last.end if gap merge_threshold: # 合并为同一次事件结束时间取较晚的一个 last.end max(last.end, event.end) last.score max(last.score, event.score) else: merged.append(event) return merged def count_applause(events: List[ModelEvent], merge_threshold: float 1.0) - int: 统计最终鼓掌次数。 先合并时间接近的事件再去掉置信度极低的误检。 本质上一次鼓掌事件的 onset 只计算一次。 filtered [e for e in events if e.score 0.5] merged merge_events(filtered, merge_threshold) return len(merged) def summarize(events: List[ModelEvent], merge_threshold: float 1.0) - dict: merged merge_events(events, merge_threshold) time_lines [] for idx, event in enumerate(merged, start1): time_lines.append( { rank: idx, start_sec: round(event.start, 2), end_sec: round(event.end, 2), confidence: round(event.score, 2), } ) return { total_applause_count: len(time_lines), events: time_lines, }这段代码中的merge_threshold值得展开讲一下。鼓掌动作往往不是一次干脆的拍手而是一连串“啪啪啪”的声音和手部动作。如果模型把一次持续鼓掌内部的多次拍手都识别成独立事件最终数量会被严重放大。因此Agent 编排层需要把 1 秒内发生的事件合并成一个事件窗口。需要注意这里的评分过滤阈值为 0.5只是一个示例值。真实业务中你需要根据模型在标注集上的表现去调。4.5 主流程运行与验证main.py把所有模块串起来执行。# main.py from config import Config from video_helper import split_video_clips from multimodal_client import analyze_clip_with_multimodal_model from agent_core import summarize config Config() def main(): # 1. 切分视频片段 if config.demo_mode: # 演示模式不需要真实视频使用模型模拟事件 from multimodal_client import DEMO_EVENTS, _parse_events raw_events _parse_events(DEMO_EVENTS) print( Agent 视频鼓掌计数 Demo ) print(演示模式使用预置模拟事件不依赖外部模型 API) result summarize(raw_events, config.merge_threshold) print(f模型返回候选事件数: {len(raw_events)}) print(f合并后鼓掌次数: {result[total_applause_count]}) print(详细事件时间线:) for item in result[events]: print(item) return # 2. 真实视频处理流程 clip_paths split_video_clips( video_pathconfig.video_path, segment_secondsconfig.segment_seconds, overlap_secondsconfig.overlap_seconds, ) model_name config.model_name if not config.demo_mode else demo all_events [] for clip_path in clip_paths: # 3. 对每个片段调用多模态模型 segment_events analyze_clip_with_multimodal_model(clip_path, model_name) all_events.extend(segment_events) # 4. 汇总并输出 result summarize(all_events, config.merge_threshold) print(f视频片段数: {len(clip_paths)}) print(f模型返回原始候选事件数: {len(all_events)}) print(f最终鼓掌次数: {result[total_applause_count]}) for item in result[events]: print(item) if __name__ __main__: main()运行方式很简单pip install -r requirements.txt python main.py在演示模式下预期输出大致如下 Agent 视频鼓掌计数 Demo 演示模式使用预置模拟事件不依赖外部模型 API 模型返回候选事件数: 4 合并后鼓掌次数: 3 详细事件时间线: {rank: 1, start_sec: 0.5, end_sec: 3.2, confidence: 0.94} {rank: 2, start_sec: 4.1, end_sec: 8.0, confidence: 0.94} {rank: 3, start_sec: 10.3, end_sec: 13.5, confidence: 0.97}可以看到模型返回了 4 个候选事件其中第 2 个和第 3 个事件因为时间间隔只有 0.9 秒小于 1 秒的merge_threshold所以被合并为同一个鼓掌事件最终统计结果为 3 次。为了便于验证合并逻辑你也可以修改DEMO_EVENTS中的数据观察不同时间间隔对最终计数的影响。4.6 把演示替换成真实的 Gemini 3.7 Flash 调用把演示打通之后下一步就是接入真实模型。真实调用通常分几步完成第一步从视频片段中抽帧。一般每个片段抽取 3 到 8 帧即可。你可以把帧保存为 JPG 文件再转成 base64 编码。第二步构造提示词。提示词需要明确要求模型输出 JSON。一个比较稳妥的提示词模板如下请分析这段视频片段中是否出现“鼓掌”行为。 判断标准 1. 画面中有人出现双手拍打动作 2. 动作持续超过0.5秒 3. 多人鼓掌时算作一次群体鼓掌事件。 只输出 JSON格式如下 { has_applause: true, events: [ { type: applause_onset, start_sec: 0.8, end_sec: 3.5, confidence: 0.93 } ] }第三步解析模型返回内容。由于多模态模型的输出有时会包含 Markdown 代码块标记建议对模型输出做一次清洗再使用 JSON 解析。需要提醒的是模型 API 的调用方式、支持字段、鉴权方式都可能随产品版本变化。换句话说上文的“真实调用”部分只给了通用思路具体请求参数要以你正在使用的官方 SDK 文档为准。5. 常见问题与排查思路5.1 视频理解计数结果异常排查表问题现象常见原因解决思路计数结果明显偏大模型把一次鼓掌过程中的多次拍手识别成多次独立事件增加事件合并机制调大 merge_threshold计数结果偏小鼓掌动作持续较短落在片段边界处被丢掉增加相邻片段的重叠时长或降低片段切分的时长阈值镜头切换后计数重复不同机位拍的是同一场掌声但模型无法辨认引入音频事件连续线画面镜头标签变化时不做新增计数模型把欢呼误判为鼓掌仅有声音线索缺少手部动作画面在提示词中要求模型同时结合画面动作不要只凭音频判断抽帧太多导致请求超时单片段的图像数量过大降低抽帧 FPS或减少每个片段内的图像数量输出 JSON 解析失败模型返回了多余文字或 Markdown 标记对输出内容做代码块清理并增加重试机制同一个视频重复运行结果不一致多模态模型推理具有一定随机性设置较低的温度参数并增加多次投票机制5.2 动手复现前的自查清单在开始写代码前建议先确认以下几个问题否则很容易在调试时浪费大量时间。第一你使用的视频素材是否具备清晰的掌声动作如果视频本身只有声音没有人物鼓掌画面纯视觉模型很难给出可靠结果。第二你使用的模型是否真正支持多帧图像输入很多模型能够处理单张图像但视频输入和图像序列输入是不同的能力需要确认官方接口支持。第三是否提前定义好评判标准一次鼓掌是从第一次拍手到最后一次拍手结束还是一下拍手就代表一次不同标准会直接影响合并参数的调节。第四是否有足够的测试样本不要只拿一段视频调参至少准备 5 到 10 段不同场景的视频观察计数结果的稳定性。5.3 典型错误直接把所有帧一次性发给模型在实际项目中我看到最多的错误就是把长视频抽帧成上百张图片一次性发给模型然后让模型输出总次数。这种做法在极端简单的场景中可能成功但一旦遇到群像、镜头切换、多段掌声结果会变得不可控。正确的做法应该是让模型做减法先切片段再逐段判断最后用工程逻辑做聚合。模型负责它擅长的语义理解计数和去重交给确定性代码完成。6. 最佳实践与工程建议6.1 事件 Schema 先行在写业务代码前先定义好模型输出的 JSON 结构。下面是一个推荐的事件结构{ version: 1.0, clip_id: clip_0001, has_applause: true, events: [ { type: applause_onset, event_id: evt_0001, start_sec: 0.6, end_sec: 3.4, confidence: 0.95 } ] }字段说明version便于以后升级输出结构时做兼容clip_id来源片段标识event_id每次识别的事件唯一标识方便排查start_sec和end_sec事件开始和结束时间计数合并的关键字段confidence模型置信度用于过滤低质量结果。一旦事件结构固定下来后续无论更换模型版本还是加入新的动作类型修改范围都会被控制在接入层而不是遍布整个项目。6.2 温度参数与多次采样视频事件计数需要的是确定性输出而不是创造性结果。因此真实调用模型时建议将 temperature 设置为 0 或接近于 0 的数值。如果 API 支持 top_p也可以适当降低 top_p减少输出随机性。对于单个高难片段可以重复调用模型 3 次采用投票机制确定最终结果。例如3 次中有 2 次都认为存在鼓掌事件才记为一次事件。这种方法会增加推理成本但能提升计数稳定性适合对准确率要求较高的场景。6.3 长视频与并发处理如果视频非常长比如超过 10 分钟逐片段串行调用模型会非常耗时。推荐把片段切分后的无依赖任务放到消息队列或线程池中并发执行。不过并发处理会带来一次新的挑战切片段、发请求、收结果的顺序可能与原始时间轴不一致。因此每个事件必须携带片段序号和时间戳。汇总层在合并事件前先按start_sec排序然后再执行去重合并逻辑。6.4 安全合规与隐私保护相机拍摄的视频通常会涉及大量人物肖像。即使只是用来测试鼓掌计数也要注意数据合规问题。如果视频中包含可识别身份的个人信息建议先进行脱敏处理比如对人脸做模糊获取视频拍摄方和当事人的必要授权不要将带有个人信息的数据随意上传到第三方模型服务生产环境关注数据保存与访问权限管控。这不是“额外工作”而应该作为视频理解项目的基础前提。哪怕模型能力再强也不能忽略数据使用的合法边界。6.5 日志与人工抽检视频理解类 Agent 与传统接口不同它的问题是“阶段性的”可能在某个镜头切换处漏判也可能在某个噪声片段中误判。因此日志不仅要记录最终结果还要记录所有中间决策。建议至少记录每个片段的模型原始返回解析后的候选事件合并前后的对比最终计数结果。有了这些日志当业务方质疑“为什么这段视频计数不对”时你可以快速定位是哪一层出了问题。7. 总结与下一步路线本文围绕 Gemini 3.7 Flash 和智能体视频理解能力以“数清鼓掌次数”为切入点做了一次系统的工程拆解。你现在应该已经理解了三件事第一视频事件计数不能依赖单次大模型推理而应该通过“切片段、逐段识别、全局合并”的 Agent 方式完成。第二模型的核心作用是做片段级语义判断而确定性去重、时间轴管理、阈值调节等工作应该交给编排代码完成。第三Gemini 3.7 Flash 这类轻量模型很适合承担高频次、低成本的视频理解子任务但前提是你必须设计清晰的事件结构和调用流程。接下来如果你想继续深入可以往三个方向拓展第一个方向是引入音频辅助。在 Gemini 3.7 Flash 不支持直接读取视频音轨的情况下用外部工具先提取掌声音频事件再与视觉事件做交叉验证能够明显提高复杂场景下的计数准确率。第二个方向是构建自己的评测集。挑选包含单人鼓掌、群体鼓掌、镜头切换、欢呼声干扰等不同场景的视频分别标记真实鼓掌次数用评测集比较不同切分长度、抽帧策略和合并阈值的效果。第三个方向是多模型分级。把 Gemini 3.7 Flash 作为初筛模型对于置信度不高的事件片段再调用能力更强的多模态模型做二次确认。这能在保证准确率的同时控制整体成本。如果你准备动手做视频理解类 Agent建议先从一段 20 秒左右的视频开始跑通完整的“切分—调用模型—合并事件—输出 JSON”链路再逐步扩展视频长度与动作类型。所有的复杂系统最终都是从一个能跑通的最小闭环成长起来的。