很多开发者在接触多模态 AI 时都会遇到一个共同的疑惑模型明明能“看到”视频也能“听懂”问题但一旦任务是“数清楚这段视频里到底鼓了几次掌”它就变得不够可靠。有人会以为这是模型理解能力不够但实际上问题的核心往往不在“看懂”这一步而在于模型是否被赋予了像智能体一样拆解任务、分段分析、反复验证的能力。最近“Gemini 3.7 Flash 借智能体视频理解能力准确数清鼓掌次数”这个演示之所以值得关注不在于“鼓掌”这个动作本身有多难识别而在于它把一类典型问题暴露了出来凡是需要连续观察、事件计数、时间戳对应的视频任务单靠一次“看图说话”式的调用很可能失败只有把视频理解能力放到智能体工作流里让模型学会“先取样、再分析、后汇总、最后校验”才能得到稳定可用的结果。这篇文章会从一个具体任务入手拆解视频理解型智能体的工作方式说明它和传统单轮多模态调用的差别再给出可以照做的环境准备、工作流设计、代码示例、效果验证和排错建议。无论你是在做内容审核、运动分析还是想给视频数据加上一层事件检索能力这套思路都能直接参考。1. 这篇文章真正要解决的问题如果只是给模型一张舞台照片问“台上在做什么”绝大多数多模态模型都能给出像样的回答。但换成一段几十秒的现场视频问“观众一共鼓了几次掌”难度就完全不同了。第一个难点是时间连续性问题。鼓掌是一个重复性动作单次鼓掌大约只持续零点几秒。模型如果只看视频里的抽样帧很可能把两次鼓掌看成一次或者漏掉掌声已经开始但画面里手被遮挡的那些动作。第二个难点是计数一致性。模型既要识别出“鼓掌”这个事件还要在时间轴上标记每一次事件的起止时间然后才能避免把同一段动作重复计数。第三个难点是视频长度和计算成本的矛盾完整视频直接全部塞给模型既可能超出上下文窗口也会让响应时间变得无法接受。“Gemini 3.7 Flash 借智能体视频理解能力准确数清鼓掌次数”这个演示的巧妙之处就是把“数清楚鼓掌次数”从一个单纯的多模态识别问题变成了一个智能体工程问题。模型不再试图一次性完成所有推理而是把任务拆成几个子目标先把视频切成可分析的片段再对每个片段做动作事件识别然后汇总所有片段的时间戳和事件类型最后通过一轮或多轮校验打消重复计数。通过 Flash 系列轻量模型的快速迭代整个工作流可以用较低成本完成。所以读完本文你能得到几样实际可用的东西一套适合视频事件计数的智能体架构一个从原始视频到结构化计数结果的代码框架以及一套能帮助你判断结果是否可信的验证思路。对智能体开发新手来说这篇文章也能帮忙理解为什么 Agent 通常不只是“调用一个大模型”而是“编排多个能力和结果”。2. 拆解“数清鼓掌次数”Agent 需要哪几项核心能力2.1 视频理解不等于视频分类传统的视频理解任务很多会被简化成“对视频抽帧再用图像模型对每一帧分类”。这种做法对图像描述、场景识别勉强可用但对鼓掌这种有明确时间跨度的动作事件来说直接抽帧会因为关键帧选择不准而丢失信息。真正的视频理解至少要同时建模画面中的空间信息和时间信息。也就是说模型需要知道“画面里有一双手”只是第一步它还需要知道“这双手在什么时间段内发生了连续运动”。Gemini 3.7 Flash 这类多模态模型可以把视频作为时间连续的输入来理解而不只是单张图片的拼接。这种能力让 Agent 可以直接对视频片段提问例如“这段视频中第几秒到第几秒出现了鼓掌动作”而模型给出的答案往往不是一个裸数字而是带时间范围的文本输出。准确数清鼓掌次数依赖的正是这种时间感知能力。2.2 Agent 在视频任务里扮演什么角色Agent 在这里并不是一个神秘的概念。它更像是一个“任务调度者”理解用户意图决定调用哪些能力分析模型返回的结果并在结果不够清晰时发起新一轮工具调用。如果把视频理解能力比作一个熟练的审片员Agent 就是给审片员派活的导演。导演不会让审片员一口气看完三小时素材后凭印象作答而是会让审片员先按剧本结构分段再看某一段里的具体动作最后把每段的场记单合在一起。在鼓掌计数场景里Agent 的工作流可以拆成以下几步接收用户指令明确目标和输出格式。对视频文件生成分段策略比如按固定时长切分或按场景变化切分。调用视频理解模型对每个分段执行动作识别。汇总各分段输出对相邻分段的事件做去重合并。输出一个带时间戳的 JSON 结果包含总次数和每一次事件的起止时间。如果发现计数结果有跨片段的连续性风险可以重新检查重叠边界区域。2.3 计数类任务真正需要的是结构化推理对“鼓掌次数”这种统计型问题如果模型只是回复一句“大约鼓了五到六次”工程价值不大。可用的答案必须能被后续系统继续处理最好直接是{ applause_count: 6, events: [ {start: 2.3, end: 4.1, type: applause}, {start: 5.6, end: 8.9, type: applause} ] }因此视频理解 Agent 不仅要识别事件还要把事件输出为带固定 schema 的结构化数据。这也是 Gemini 3.7 Flash 这类模型在智能体场景里的优势它可以按照 system prompt 中给定的 JSON 格式返回结果便于 Agent 直接解析并使用。能力项传统图像分类模型单轮视频多模态调用视频理解型智能体时间连续动作判断弱中强长时间视频覆盖无法覆盖受上下文限制可以通过分段解决事件去重和计数稳定性不支持不稳定通过工作流较稳定结构化输出通常没有可以但不易校验适合接入工程链路可解释性低低较高因为带时间戳这个表格清楚地说明了为什么“智能体 视频理解”的组合值得单独讨论它不是把模型能力简单叠加而是用编排逻辑弥补单次模型调用的短板。3. 原理分析为什么 Agent 能把“鼓掌计数”做得更稳3.1 从“看画面”到“在时间轴上定位事件”要让模型数清楚鼓掌次数本质上是让模型在视频时间轴上找到所有具备“鼓掌”语义的区间。拍手动作有几个显著特征双手在水平方向快速接近、手掌接触后立刻弹开、声音通常伴随动作出现。如果只看某一帧很难判断“这两个手掌靠近”是在鼓掌还是在拍蚊子又或者只是一次准备动作。Agent 需要做的通常是让视频理解模型在比较小的片段内完成因果判断。所以在工程处理上Agent 往往先做“短片长、多分片”的策略。比如把十分钟的视频按 15 到 30 秒切分对每个分片单独判断“是否鼓掌、鼓掌次数、起止时间”。为什么不能用更大的分片因为视频模型的输入 token 有限分片越大模型对时间细节的关注越容易被稀释。短片长还有一个好处即使模型出现误判也只会影响这一小段结果定位和修复成本都更低。3.2 重叠窗口解决边界重复计数做过时间序列处理的开发者应该很熟悉滑动窗口带来的边界问题。假设视频从第 30 秒切到第 60 秒模型识别出第一次鼓掌结束于第 31 秒第二次鼓掌开始于第 29.8 秒那么这实际上可能是同一次鼓掌事件跨越了切分点结果被两个分段各自统计一次。Globis 计数工作流的核心技巧是在相邻分段间设置重叠区间。每个分段除了分析自己的有效区间还会带上前后几秒的冗余画面。最后汇总阶段Agent 根据事件的起止时间做重叠合并。如果两个事件在一个时间窗口内相交且动作类型相同就将其合并为一个事件并取最早开始时间和最晚结束时间。合并逻辑并不复杂但当模型输出格式统一时这套逻辑可以很稳定地复用到拍手、跳跃、点头、举手等所有周期性动作视频任务里。3.3 智能体调用视频理解能力的两种形态从工程设计上看“智能体借视频理解能力”通常指两种形态。第一种是模型原生应用视觉输入Agent 把视频分片和问题一起作为 prompt 内容让模型直接回答。这种形态适合 Gemini 这类端到端多模态模型。开发者只需把视频分片传给模型并在 prompt 中强调“请回到 JSON 格式”。第二种是模型先通过工具调用去获取视频关键信息。Agent 可以拆解得到行动计划并且主动调用外部工具比如先让视频抽帧工具截取关键瞬间再让模型分析截帧。两种形态可以结合模型先看简短视频了解内容再抽取事件关键帧做精细判断。哪种更好取决于场景。如果任务要求高准确率和较少 token 消耗通常建议先用工具抽帧粗筛再用模型精细识别。4. 环境准备与前置条件下面内容以“Python FFmpeg Gemini 多模态接口”给出一个可复现的通用方案。由于各 SDK 版本迭代很快代码中涉及的模型名称和接口细节可能发生变化请以官方最新文档为准。4.1 基础环境为完成该演示思路建议准备以下环境操作系统Linux 或 macOS 均可Windows 可使用 WSL2 或直接安装 FFmpeg。Python3.10 或更高版本。FFmpeg用于视频切割、抽帧和获取视频信息。Python 依赖包google-genai或google-generativeai二选一即可ffmpeg-python便于在 Python 中控制视频切割json、os、subprocess等标准库。4.2 安装命令示例# Python 环境建议使用虚拟环境 python3 -m venv .venv source .venv/bin/activate # 安装 FFmpeg # Ubuntu / Debian sudo apt update sudo apt install -y ffmpeg # macOS # brew install ffmpeg # 安装 Python 依赖 pip install google-genai ffmpeg-python # 验证 FFmpeg 是否可用 ffmpeg -version如果安装google-genai失败可以切换到传统 SDKpip install google-generativeai4.3 视频材料准备准备测试视频时不用追求内容复杂。找一段带有清晰掌声的视频时长控制在 20 到 60 秒并用人工方式记录一次鼓掌次数和时间范围。这个人工标注结果会成为后续验证模型输出是否准确的“基准答案”。注意测试视频如果涉及人物肖像、活动画面、版权内容务必确认自己拥有合法处理权限。涉及生产环境的视频分析时应使用经过授权或有明确版权的素材不可把隐私内容直接放入大模型请求中。5. 智能体视频理解工作流完整示例与代码实现5.1 第一步把长视频切成适合模型处理的片段视频理解任务中直接上传几十分钟的原始视频既可能超过模型的输入限制也会降低事件识别准确率。先用 FFmpeg 把视频拆成短视频片段是视频 Agent 最常见的预处理方式。下面是一段使用ffmpeg-python和原生subprocess配合的切割脚本演示如何从原始视频中按固定时长切分片段同时保留重叠窗口。# 文件路径scripts/cut_video.sh #!/bin/bash INPUT_VIDEO$1 OUTPUT_DIR$2 SEGMENT_SECONDS10 OVERLAP_SECONDS2 mkdir -p $OUTPUT_DIR # 以 10 秒为一段相邻片段多保留 2 秒冗余 ffmpeg -i $INPUT_VIDEO -c copy -map 0 -segment_time 10 \ -f segment -segment_format_options movflagsfaststart \ $OUTPUT_DIR/segment_%03d.mp4 echo 视频切分完成请检查 $OUTPUT_DIR 目录如果希望代码可动态获取视频时长并按重叠窗口切分推荐使用ffprobe获取时长后逐段切割。这类处理没有太多算法深度关键是确保分段之间的重叠足够避免边界漏检。5.2 第二步Agent 主流程循环处理每段视频接下来是核心部分Agent 主流程。这里不再写死所有逻辑而是把 Gemini 多模态模型当作一个“视频分片分析工具”。主循环读取每个切分后的视频片段发送给模型要求模型输出 JSON 格式的事件列表。所有分片均分析完成后Agent 再把所有 JSON 结果做合并去重。由于具体的模型 SDK 在持续更新下面代码采用“示例模型名 关键注释”的写法。你需要根据当前安装的 SDK 版本把模型名替换成可用的视频理解模型。# 文件路径agent_video_counter.py import json import os import glob from typing import List, Dict, Any # 以 Gemini 官方 Python SDK 为例不同版本安装方式不同请以当前 SDK 为准 # from google import genai # from google.genai import types OUTPUT_DIR ./segments ANALYSIS_PROMPT 你是一名视频动作事件分析师。请分析这个视频片段找出其中所有“鼓掌”动作。 要求 1. 不要遗漏鼓掌事件也不要将非鼓掌动作识别成鼓掌。 2. 返回 JSON不要输出其他解释文字。 3. JSON 格式如下 { events: [ {type: applause, start: 1.2, end: 3.4}, {type: applause, start: 5.0, end: 6.1} ] } 如果视频中没有鼓掌事件返回 {events: []} def analyze_video_segment(segment_path: str) - Dict[str, Any]: 调用视频理解模型分析单个视频片段。 具体调用方式会依赖 SDK 版本这里保留一个可运行的最小示例骨架。 # 不同 SDK 的视频上传方式不一可能是本地文件引用也可能是 File API。 # 请根据自己使用的 SDK 文档补充。 model gemini-video-model-demo prompt ANALYSIS_PROMPT # 伪代码示意 # response client.models.generate_content( # modelmodel, # contents[prompt, load_video_part(segment_path)] # ) # text response.text # 下面直接构造一个空的解析函数便于流程串联。 text {events: []} try: data json.loads(text) for event in data.get(events, []): event[source_segment] os.path.basename(segment_path) return data except json.JSONDecodeError: return {events: [], parse_error: text} def merge_events(all_events: List[Dict[str, Any]], merge_gap: float 1.0) - List[Dict[str, Any]]: 合并来自不同分片的密集事件。 如果两个鼓掌事件的时间间隔小于 merge_gap视为同一次鼓掌。 if not all_events: return [] events_sorted sorted(all_events, keylambda x: x[start]) merged [events_sorted[0].copy()] for event in events_sorted[1:]: last merged[-1] if event[start] last[end] merge_gap and event[type] last[type]: last[end] max(last[end], event[end]) else: merged.append(event.copy()) return merged def main() - None: segment_files sorted(glob.glob(os.path.join(OUTPUT_DIR, *.mp4))) all_events: List[Dict[str, Any]] [] for segment_path in segment_files: result analyze_video_segment(segment_path) all_events.extend(result.get(events, [])) final_events merge_events(all_events) report { total_video_events: len(final_events), applause_count: len([e for e in final_events if e[type] applause]), events: final_events, } with open(result.json, w, encodingutf-8) as f: json.dump(report, f, ensure_asciiFalse, indent2) print(json.dumps(report, ensure_asciiFalse, indent2)) if __name__ __main__: main()这里有几处需要注意。merge_gap参数很有价值。如果视频里两次鼓掌间隔很短比如在一轮热烈掌声中模型可能把一个持续 3 秒的鼓掌事件拆成多个片段。设置合理的时间合并窗口能有效减小重复计数。当然如果任务要求的是统计“每一次单次拍手”而不是统计“一轮掌声”就需要把 merge_gap 调小甚至关闭。5.3 第三步支持模型在回答前先使用工具上面的示例属于“Agent 分批调用模型”的简单形态。更进一步可以在 prompt 中让 Agent 先对视频片段进行场景分析再决定使用哪一类工具。比如对鼓掌检测来说很有用的辅助信息是声音波形。Agent 如果发现某个时间段音频能量很强就可以把这段视频的关键帧传给视觉模型二次确认。不过这类工具调用链路一旦复杂就必须考虑工具返回内容的可靠性和可观测性。建议把每一次工具调用的输入和输出都记录到日志中至少包括调用时间。传入的视频片段路径。所用的 prompt 版本。模型返回的原始文本。解析后的 JSON。是否出现解析异常。这些日志会是后面排查“数错了”的最重要依据。5.4 运行与预期效果按照上述流程建议按下面的步骤运行# 1. 给脚本加执行权限 chmod x scripts/cut_video.sh # 2. 切分视频 ./scripts/cut_video.sh lecture.mp4 ./segments # 3. 运行 Python 智能体流程 python agent_video_counter.py如果一切正常控制台会输出一份 JSON 结果其中applause_count字段对应总鼓掌次数events数组则给出每次鼓掌的大致起止时间。如果applause_count为 0但视频里明明有掌声通常需要先检查视频分段结果再看模型是否成功读取了视频文件。6. 效果验证如何判断“数清楚”是真的可靠6.1 不能只看总次数对不对把模型输出的总次数和人工统计的总次数做对比是最直观的验证方式但还远远不够。一次漏检和一次重复计数可能互相抵消总数看起来一模一样实际上事件分布已经完全错误。更合理的验证方式是同时比较事件总次数是否一致。每个事件的起止时间与标注时间是否大致重合。事件类型标签是否一致。下面给出一个简单的验证函数用来计算预测事件与人工标注事件的匹配度。这里把两个事件视为匹配的条件是事件类型一致且时间交集占并集的比例大于某个阈值。# 文件路径evaluate_events.py from typing import List, Dict, Any def event_iou(event_a: Dict[str, Any], event_b: Dict[str, Any]) - float: start max(event_a[start], event_b[start]) end min(event_a[end], event_b[end]) intersection max(0.0, end - start) union_start min(event_a[start], event_b[start]) union_end max(event_a[end], event_b[end]) union max(0.0, union_end - union_start) if union 0: return 1.0 if event_a[type] event_b[type] else 0.0 return intersection / union def match_events(pred_events: List[Dict[str, Any]], gt_events: List[Dict[str, Any]], iou_threshold: float 0.5) - Dict[str, Any]: matched_pred set() matched_gt set() for p_idx, pred in enumerate(pred_events): for g_idx, gt in enumerate(gt_events): if p_idx in matched_pred or g_idx in matched_gt: continue if pred[type] gt[type] and event_iou(pred, gt) iou_threshold: matched_pred.add(p_idx) matched_gt.add(g_idx) precision len(matched_pred) / len(pred_events) if pred_events else 1.0 recall len(matched_gt) / len(gt_events) if gt_events else 1.0 f1 2 * precision * recall / (precision recall) if (precision recall) 0 else 0.0 return { precision: round(precision, 4), recall: round(recall, 4), f1: round(f1, 4), matched_count: len(matched_pred), pred_count: len(pred_events), gt_count: len(gt_events), } if __name__ __main__: ground_truth [ {type: applause, start: 1.0, end: 3.0}, {type: applause, start: 10.0, end: 12.0}, ] predictions [ {type: applause, start: 1.2, end: 3.1}, {type: applause, start: 11.8, end: 12.5}, ] print(match_events(predictions, ground_truth))运行该脚本后会看到输出结果中包含 precision、recall、f1 等指标。如果 F1 偏低看到底是漏检还是误检漏检通常表现为 recall 低。可能原因包括视频画质差、动作幅度小、单次鼓掌时间过短、分段后动作被切碎。误检通常表现为 precision 低。可能原因包括模型把掌声、欢呼、靠近麦克风的动作甚至双手整理衣领的动作识别成了鼓掌。6.2 用“多段素材 多次重复”测试稳定性视频理解模型的输出有一定随机性。相同视频片段同一模型可能在不同温度设置下产生不同的事件边界。聪明做法是准备至少 5 段测试视频每段视频跑 3 至 5 次观察结果方差。如果结果波动大可以考虑降低模型的 temperature 参数或在 prompt 中增加“基于画面内容客观判断不要猜测”的约束。为了形成稳定的质量基线建议记录一份简单的验证清单测试项验证方法通过标准鼓掌事件召回比较人工标注事件是否都在模型输出中出现recall 不低于 0.8鼓掌事件误识别用没有掌声的视频测试模型输出事件应尽量少总次数稳定性同片段重复多次次数误差不超过 1 次时间戳准确度人工记录的掌声范围与输出范围比较IoU 大于 0.5 算匹配长视频覆盖用 5 分钟以上视频测试分段能力无片段遗漏绝对理想的值可能因视频场景不同而差异很大。但如果测试过程严格遵守同一套标准你的 Agent 工作流是不是真的比“直接把整段视频丢给模型”更稳定就可以得到明显证据。7. 视频理解智能体的常见问题与排查方法在实际把视频理解能力接入智能体时开发者经常在一开始就发现效果不如预期。以下问题来自我在视频分析和 Agent 开发中常见的真实技术损耗基本都可以通过调整工程链路来解决。问题现象可能原因排查方式解决方案模型输出不是 JSON提示词约束不够或模型版本对 JSON 输出支持弱查看原始返回文本使用结构化输出参数在提示中增加“只返回 JSON不要解释”鼓掌总数少了很多长视频被直接输入模型上下文有限查看视频是否被正确转码、分段增加视频分段逻辑启用重叠窗口同一段掌声被数两次相邻分段边界重叠导致重复事件未被合并打印各分片返回的事件时间戳调整 merge_gap完善事件合并逻辑没鼓掌的视频也检测出鼓掌音频或视觉信息被误判单独检查音频轨内容在 prompt 中强调“画面中双手接触并快速分离才算鼓掌”单独片段识别正常整体结果乱Agent 汇总逻辑没有统一事件格式检查各分片返回的 start/end 字段类型在解析层强制转换成 float并做排序与去重响应时间较长分片过多但任务可并行观察各分片耗时引入并发调用同时注意 API 限流其中最容易被忽视的是“Agent 汇总逻辑”。很多人以为问题出在视频理解模型不够聪明结果查了半天发现其实是模型对每个分片都返回了正确事件但汇总脚本里没有排序去重。所以建议在系统设计初期就把模型输出格式当成 API 契约来管理。模型输出必须能被机器读取后续一切统计、校验、报警才能自动化。另一个高频问题是把视频理解与音频理解混为一谈。鼓掌虽然通常伴随声音但有的视频里会出现后期添加的鼓掌声效或者现场其他噪音。如果任务要求精确识别“画面人物做出的鼓掌动作”Agent 应该把判断依据限制在视觉内容上否则容易产生由音频引起的误报。8. 视频理解 Agent 落地时的最佳实践与工程建议8.1 先稳定输出格式再提升准确率不管用哪种视频理解模型第一优先级都不是让模型“想得更深”而是让模型输出可以被程序稳定解析。建议在 prompt 中加入固定的 JSON Schema同时在代码层保留原始输出日志。一旦准确率下降可回溯对比当时模型版本和输出结构。不要试图依赖模型“随心所欲”的文本回答这会让后续所有 Agent 逻辑变成脆弱的字符串匹配。8.2 用 Agent 做校验而不只是做识别一个成熟的鼓掌计数 Agent不应只做一次视频分析就给出结果。可以增加一次校验步骤Agent 列出所有检测到的事件后把事件时间点附近的若干关键帧重新截图并让模型做二次验证。如果第二次识别结果与第一次相差过大就触发重新分析。这种“多轮自我校验”机制是 Agent 相对单次模型调用价值最大的地方之一。具体实现时可以在每一轮校验前加上简单的计数规则例如# 校验规则示例 def check_count_confidence(events, max_count20): if len(events) max_count: return need_review for event in events: if event[end] event[start]: return invalid_timestamp return ok8.3 注意数据权限和最小化传输视频文件通常含有敏感信息。如果使用云端多模态 API必须遵守权限边界并在数据处理前获得合法授权。对可落到本地的任务建议先对视频做场景裁剪只截取涉及判断的片段再上传。同时API 请求和返回结果中的视频原始文件、检测到的事件数据也要有明确的保存期限和删除策略。不要在提示词里加入无关个人信息避免数据泄露风险。8.4 不要把计数结果直接当成“最终事实”模型对视频事件的时间边界判断往往有几百毫秒甚至更大的误差。因此如果业务场景涉及自动处罚、用户行为判断或任何高风险决策建议把 Agent 输出标记为“初筛结果”并由人再复核。Agent 可以帮助审核员快速定位高潮时间段而不是完全替代判断。9. 下一步如何把演示能力变成自己的实战项目Gemini 3.7 Flash 及相关视频多模态模型近期的演示最值得关注的一点是模型本身的快速迭代减少了视频理解的技术摩擦力但真正决定成败的还是工作流。如果你现在想动手建议从一个更简单但能完整跑通的项目开始不必一开始就追求“精确数清鼓掌次数”。可以选择客厅摄像头录下的一段活动视频标注“人站起坐下”的次数或者体育比赛视频里“得分后击掌”的次数。这样的事件比鼓掌边界更清晰训练和验证都比较容易。跑通后再加入音频、多角度、长短镜头切换等干扰因素。如果你更关心 Agent 开发本身可以研究两条技术路线一条是模型自身直接消费视频输入另一条是模型通过工具调用查询外部视频分析服务。前者依赖多模态模型的持续迭代后者更接近现有系统集成方式。两条路线不冲突也适合做对比实验。在长期项目中建议把 Prompt 模板、视频分片参数、事件合并规则都当成需要版本管理的代码资产而不是临时写在配置文件里的魔术数字。这样当模型升级到新版本后你可以快速判断是模型能力提升导致效果变化还是你的视频拆解策略已经过时。把“数清楚鼓掌次数”当作一个标尺它可以度量视频理解模型的时间感知能力更可以度量你在智能体工程上的编排水平。下一次再看到类似的惊艳演示不妨把它拆开看几步模型到底做了什么Agent 又在外面做了哪些包抄。理解了这一层你的收获远比记住“某模型会数数”更有价值。建议收藏这篇文章也欢迎在评论区交流你自己的视频理解方案。如果你能从“把一段视频变成结构化事件列表”这个最小闭环开始动手很快就能体会到视频理解 Agent 与传统单轮模型调试的差异。
从鼓掌计数看视频理解智能体：如何用Agent工作流实现稳定事件识别
很多开发者在接触多模态 AI 时都会遇到一个共同的疑惑模型明明能“看到”视频也能“听懂”问题但一旦任务是“数清楚这段视频里到底鼓了几次掌”它就变得不够可靠。有人会以为这是模型理解能力不够但实际上问题的核心往往不在“看懂”这一步而在于模型是否被赋予了像智能体一样拆解任务、分段分析、反复验证的能力。最近“Gemini 3.7 Flash 借智能体视频理解能力准确数清鼓掌次数”这个演示之所以值得关注不在于“鼓掌”这个动作本身有多难识别而在于它把一类典型问题暴露了出来凡是需要连续观察、事件计数、时间戳对应的视频任务单靠一次“看图说话”式的调用很可能失败只有把视频理解能力放到智能体工作流里让模型学会“先取样、再分析、后汇总、最后校验”才能得到稳定可用的结果。这篇文章会从一个具体任务入手拆解视频理解型智能体的工作方式说明它和传统单轮多模态调用的差别再给出可以照做的环境准备、工作流设计、代码示例、效果验证和排错建议。无论你是在做内容审核、运动分析还是想给视频数据加上一层事件检索能力这套思路都能直接参考。1. 这篇文章真正要解决的问题如果只是给模型一张舞台照片问“台上在做什么”绝大多数多模态模型都能给出像样的回答。但换成一段几十秒的现场视频问“观众一共鼓了几次掌”难度就完全不同了。第一个难点是时间连续性问题。鼓掌是一个重复性动作单次鼓掌大约只持续零点几秒。模型如果只看视频里的抽样帧很可能把两次鼓掌看成一次或者漏掉掌声已经开始但画面里手被遮挡的那些动作。第二个难点是计数一致性。模型既要识别出“鼓掌”这个事件还要在时间轴上标记每一次事件的起止时间然后才能避免把同一段动作重复计数。第三个难点是视频长度和计算成本的矛盾完整视频直接全部塞给模型既可能超出上下文窗口也会让响应时间变得无法接受。“Gemini 3.7 Flash 借智能体视频理解能力准确数清鼓掌次数”这个演示的巧妙之处就是把“数清楚鼓掌次数”从一个单纯的多模态识别问题变成了一个智能体工程问题。模型不再试图一次性完成所有推理而是把任务拆成几个子目标先把视频切成可分析的片段再对每个片段做动作事件识别然后汇总所有片段的时间戳和事件类型最后通过一轮或多轮校验打消重复计数。通过 Flash 系列轻量模型的快速迭代整个工作流可以用较低成本完成。所以读完本文你能得到几样实际可用的东西一套适合视频事件计数的智能体架构一个从原始视频到结构化计数结果的代码框架以及一套能帮助你判断结果是否可信的验证思路。对智能体开发新手来说这篇文章也能帮忙理解为什么 Agent 通常不只是“调用一个大模型”而是“编排多个能力和结果”。2. 拆解“数清鼓掌次数”Agent 需要哪几项核心能力2.1 视频理解不等于视频分类传统的视频理解任务很多会被简化成“对视频抽帧再用图像模型对每一帧分类”。这种做法对图像描述、场景识别勉强可用但对鼓掌这种有明确时间跨度的动作事件来说直接抽帧会因为关键帧选择不准而丢失信息。真正的视频理解至少要同时建模画面中的空间信息和时间信息。也就是说模型需要知道“画面里有一双手”只是第一步它还需要知道“这双手在什么时间段内发生了连续运动”。Gemini 3.7 Flash 这类多模态模型可以把视频作为时间连续的输入来理解而不只是单张图片的拼接。这种能力让 Agent 可以直接对视频片段提问例如“这段视频中第几秒到第几秒出现了鼓掌动作”而模型给出的答案往往不是一个裸数字而是带时间范围的文本输出。准确数清鼓掌次数依赖的正是这种时间感知能力。2.2 Agent 在视频任务里扮演什么角色Agent 在这里并不是一个神秘的概念。它更像是一个“任务调度者”理解用户意图决定调用哪些能力分析模型返回的结果并在结果不够清晰时发起新一轮工具调用。如果把视频理解能力比作一个熟练的审片员Agent 就是给审片员派活的导演。导演不会让审片员一口气看完三小时素材后凭印象作答而是会让审片员先按剧本结构分段再看某一段里的具体动作最后把每段的场记单合在一起。在鼓掌计数场景里Agent 的工作流可以拆成以下几步接收用户指令明确目标和输出格式。对视频文件生成分段策略比如按固定时长切分或按场景变化切分。调用视频理解模型对每个分段执行动作识别。汇总各分段输出对相邻分段的事件做去重合并。输出一个带时间戳的 JSON 结果包含总次数和每一次事件的起止时间。如果发现计数结果有跨片段的连续性风险可以重新检查重叠边界区域。2.3 计数类任务真正需要的是结构化推理对“鼓掌次数”这种统计型问题如果模型只是回复一句“大约鼓了五到六次”工程价值不大。可用的答案必须能被后续系统继续处理最好直接是{ applause_count: 6, events: [ {start: 2.3, end: 4.1, type: applause}, {start: 5.6, end: 8.9, type: applause} ] }因此视频理解 Agent 不仅要识别事件还要把事件输出为带固定 schema 的结构化数据。这也是 Gemini 3.7 Flash 这类模型在智能体场景里的优势它可以按照 system prompt 中给定的 JSON 格式返回结果便于 Agent 直接解析并使用。能力项传统图像分类模型单轮视频多模态调用视频理解型智能体时间连续动作判断弱中强长时间视频覆盖无法覆盖受上下文限制可以通过分段解决事件去重和计数稳定性不支持不稳定通过工作流较稳定结构化输出通常没有可以但不易校验适合接入工程链路可解释性低低较高因为带时间戳这个表格清楚地说明了为什么“智能体 视频理解”的组合值得单独讨论它不是把模型能力简单叠加而是用编排逻辑弥补单次模型调用的短板。3. 原理分析为什么 Agent 能把“鼓掌计数”做得更稳3.1 从“看画面”到“在时间轴上定位事件”要让模型数清楚鼓掌次数本质上是让模型在视频时间轴上找到所有具备“鼓掌”语义的区间。拍手动作有几个显著特征双手在水平方向快速接近、手掌接触后立刻弹开、声音通常伴随动作出现。如果只看某一帧很难判断“这两个手掌靠近”是在鼓掌还是在拍蚊子又或者只是一次准备动作。Agent 需要做的通常是让视频理解模型在比较小的片段内完成因果判断。所以在工程处理上Agent 往往先做“短片长、多分片”的策略。比如把十分钟的视频按 15 到 30 秒切分对每个分片单独判断“是否鼓掌、鼓掌次数、起止时间”。为什么不能用更大的分片因为视频模型的输入 token 有限分片越大模型对时间细节的关注越容易被稀释。短片长还有一个好处即使模型出现误判也只会影响这一小段结果定位和修复成本都更低。3.2 重叠窗口解决边界重复计数做过时间序列处理的开发者应该很熟悉滑动窗口带来的边界问题。假设视频从第 30 秒切到第 60 秒模型识别出第一次鼓掌结束于第 31 秒第二次鼓掌开始于第 29.8 秒那么这实际上可能是同一次鼓掌事件跨越了切分点结果被两个分段各自统计一次。Globis 计数工作流的核心技巧是在相邻分段间设置重叠区间。每个分段除了分析自己的有效区间还会带上前后几秒的冗余画面。最后汇总阶段Agent 根据事件的起止时间做重叠合并。如果两个事件在一个时间窗口内相交且动作类型相同就将其合并为一个事件并取最早开始时间和最晚结束时间。合并逻辑并不复杂但当模型输出格式统一时这套逻辑可以很稳定地复用到拍手、跳跃、点头、举手等所有周期性动作视频任务里。3.3 智能体调用视频理解能力的两种形态从工程设计上看“智能体借视频理解能力”通常指两种形态。第一种是模型原生应用视觉输入Agent 把视频分片和问题一起作为 prompt 内容让模型直接回答。这种形态适合 Gemini 这类端到端多模态模型。开发者只需把视频分片传给模型并在 prompt 中强调“请回到 JSON 格式”。第二种是模型先通过工具调用去获取视频关键信息。Agent 可以拆解得到行动计划并且主动调用外部工具比如先让视频抽帧工具截取关键瞬间再让模型分析截帧。两种形态可以结合模型先看简短视频了解内容再抽取事件关键帧做精细判断。哪种更好取决于场景。如果任务要求高准确率和较少 token 消耗通常建议先用工具抽帧粗筛再用模型精细识别。4. 环境准备与前置条件下面内容以“Python FFmpeg Gemini 多模态接口”给出一个可复现的通用方案。由于各 SDK 版本迭代很快代码中涉及的模型名称和接口细节可能发生变化请以官方最新文档为准。4.1 基础环境为完成该演示思路建议准备以下环境操作系统Linux 或 macOS 均可Windows 可使用 WSL2 或直接安装 FFmpeg。Python3.10 或更高版本。FFmpeg用于视频切割、抽帧和获取视频信息。Python 依赖包google-genai或google-generativeai二选一即可ffmpeg-python便于在 Python 中控制视频切割json、os、subprocess等标准库。4.2 安装命令示例# Python 环境建议使用虚拟环境 python3 -m venv .venv source .venv/bin/activate # 安装 FFmpeg # Ubuntu / Debian sudo apt update sudo apt install -y ffmpeg # macOS # brew install ffmpeg # 安装 Python 依赖 pip install google-genai ffmpeg-python # 验证 FFmpeg 是否可用 ffmpeg -version如果安装google-genai失败可以切换到传统 SDKpip install google-generativeai4.3 视频材料准备准备测试视频时不用追求内容复杂。找一段带有清晰掌声的视频时长控制在 20 到 60 秒并用人工方式记录一次鼓掌次数和时间范围。这个人工标注结果会成为后续验证模型输出是否准确的“基准答案”。注意测试视频如果涉及人物肖像、活动画面、版权内容务必确认自己拥有合法处理权限。涉及生产环境的视频分析时应使用经过授权或有明确版权的素材不可把隐私内容直接放入大模型请求中。5. 智能体视频理解工作流完整示例与代码实现5.1 第一步把长视频切成适合模型处理的片段视频理解任务中直接上传几十分钟的原始视频既可能超过模型的输入限制也会降低事件识别准确率。先用 FFmpeg 把视频拆成短视频片段是视频 Agent 最常见的预处理方式。下面是一段使用ffmpeg-python和原生subprocess配合的切割脚本演示如何从原始视频中按固定时长切分片段同时保留重叠窗口。# 文件路径scripts/cut_video.sh #!/bin/bash INPUT_VIDEO$1 OUTPUT_DIR$2 SEGMENT_SECONDS10 OVERLAP_SECONDS2 mkdir -p $OUTPUT_DIR # 以 10 秒为一段相邻片段多保留 2 秒冗余 ffmpeg -i $INPUT_VIDEO -c copy -map 0 -segment_time 10 \ -f segment -segment_format_options movflagsfaststart \ $OUTPUT_DIR/segment_%03d.mp4 echo 视频切分完成请检查 $OUTPUT_DIR 目录如果希望代码可动态获取视频时长并按重叠窗口切分推荐使用ffprobe获取时长后逐段切割。这类处理没有太多算法深度关键是确保分段之间的重叠足够避免边界漏检。5.2 第二步Agent 主流程循环处理每段视频接下来是核心部分Agent 主流程。这里不再写死所有逻辑而是把 Gemini 多模态模型当作一个“视频分片分析工具”。主循环读取每个切分后的视频片段发送给模型要求模型输出 JSON 格式的事件列表。所有分片均分析完成后Agent 再把所有 JSON 结果做合并去重。由于具体的模型 SDK 在持续更新下面代码采用“示例模型名 关键注释”的写法。你需要根据当前安装的 SDK 版本把模型名替换成可用的视频理解模型。# 文件路径agent_video_counter.py import json import os import glob from typing import List, Dict, Any # 以 Gemini 官方 Python SDK 为例不同版本安装方式不同请以当前 SDK 为准 # from google import genai # from google.genai import types OUTPUT_DIR ./segments ANALYSIS_PROMPT 你是一名视频动作事件分析师。请分析这个视频片段找出其中所有“鼓掌”动作。 要求 1. 不要遗漏鼓掌事件也不要将非鼓掌动作识别成鼓掌。 2. 返回 JSON不要输出其他解释文字。 3. JSON 格式如下 { events: [ {type: applause, start: 1.2, end: 3.4}, {type: applause, start: 5.0, end: 6.1} ] } 如果视频中没有鼓掌事件返回 {events: []} def analyze_video_segment(segment_path: str) - Dict[str, Any]: 调用视频理解模型分析单个视频片段。 具体调用方式会依赖 SDK 版本这里保留一个可运行的最小示例骨架。 # 不同 SDK 的视频上传方式不一可能是本地文件引用也可能是 File API。 # 请根据自己使用的 SDK 文档补充。 model gemini-video-model-demo prompt ANALYSIS_PROMPT # 伪代码示意 # response client.models.generate_content( # modelmodel, # contents[prompt, load_video_part(segment_path)] # ) # text response.text # 下面直接构造一个空的解析函数便于流程串联。 text {events: []} try: data json.loads(text) for event in data.get(events, []): event[source_segment] os.path.basename(segment_path) return data except json.JSONDecodeError: return {events: [], parse_error: text} def merge_events(all_events: List[Dict[str, Any]], merge_gap: float 1.0) - List[Dict[str, Any]]: 合并来自不同分片的密集事件。 如果两个鼓掌事件的时间间隔小于 merge_gap视为同一次鼓掌。 if not all_events: return [] events_sorted sorted(all_events, keylambda x: x[start]) merged [events_sorted[0].copy()] for event in events_sorted[1:]: last merged[-1] if event[start] last[end] merge_gap and event[type] last[type]: last[end] max(last[end], event[end]) else: merged.append(event.copy()) return merged def main() - None: segment_files sorted(glob.glob(os.path.join(OUTPUT_DIR, *.mp4))) all_events: List[Dict[str, Any]] [] for segment_path in segment_files: result analyze_video_segment(segment_path) all_events.extend(result.get(events, [])) final_events merge_events(all_events) report { total_video_events: len(final_events), applause_count: len([e for e in final_events if e[type] applause]), events: final_events, } with open(result.json, w, encodingutf-8) as f: json.dump(report, f, ensure_asciiFalse, indent2) print(json.dumps(report, ensure_asciiFalse, indent2)) if __name__ __main__: main()这里有几处需要注意。merge_gap参数很有价值。如果视频里两次鼓掌间隔很短比如在一轮热烈掌声中模型可能把一个持续 3 秒的鼓掌事件拆成多个片段。设置合理的时间合并窗口能有效减小重复计数。当然如果任务要求的是统计“每一次单次拍手”而不是统计“一轮掌声”就需要把 merge_gap 调小甚至关闭。5.3 第三步支持模型在回答前先使用工具上面的示例属于“Agent 分批调用模型”的简单形态。更进一步可以在 prompt 中让 Agent 先对视频片段进行场景分析再决定使用哪一类工具。比如对鼓掌检测来说很有用的辅助信息是声音波形。Agent 如果发现某个时间段音频能量很强就可以把这段视频的关键帧传给视觉模型二次确认。不过这类工具调用链路一旦复杂就必须考虑工具返回内容的可靠性和可观测性。建议把每一次工具调用的输入和输出都记录到日志中至少包括调用时间。传入的视频片段路径。所用的 prompt 版本。模型返回的原始文本。解析后的 JSON。是否出现解析异常。这些日志会是后面排查“数错了”的最重要依据。5.4 运行与预期效果按照上述流程建议按下面的步骤运行# 1. 给脚本加执行权限 chmod x scripts/cut_video.sh # 2. 切分视频 ./scripts/cut_video.sh lecture.mp4 ./segments # 3. 运行 Python 智能体流程 python agent_video_counter.py如果一切正常控制台会输出一份 JSON 结果其中applause_count字段对应总鼓掌次数events数组则给出每次鼓掌的大致起止时间。如果applause_count为 0但视频里明明有掌声通常需要先检查视频分段结果再看模型是否成功读取了视频文件。6. 效果验证如何判断“数清楚”是真的可靠6.1 不能只看总次数对不对把模型输出的总次数和人工统计的总次数做对比是最直观的验证方式但还远远不够。一次漏检和一次重复计数可能互相抵消总数看起来一模一样实际上事件分布已经完全错误。更合理的验证方式是同时比较事件总次数是否一致。每个事件的起止时间与标注时间是否大致重合。事件类型标签是否一致。下面给出一个简单的验证函数用来计算预测事件与人工标注事件的匹配度。这里把两个事件视为匹配的条件是事件类型一致且时间交集占并集的比例大于某个阈值。# 文件路径evaluate_events.py from typing import List, Dict, Any def event_iou(event_a: Dict[str, Any], event_b: Dict[str, Any]) - float: start max(event_a[start], event_b[start]) end min(event_a[end], event_b[end]) intersection max(0.0, end - start) union_start min(event_a[start], event_b[start]) union_end max(event_a[end], event_b[end]) union max(0.0, union_end - union_start) if union 0: return 1.0 if event_a[type] event_b[type] else 0.0 return intersection / union def match_events(pred_events: List[Dict[str, Any]], gt_events: List[Dict[str, Any]], iou_threshold: float 0.5) - Dict[str, Any]: matched_pred set() matched_gt set() for p_idx, pred in enumerate(pred_events): for g_idx, gt in enumerate(gt_events): if p_idx in matched_pred or g_idx in matched_gt: continue if pred[type] gt[type] and event_iou(pred, gt) iou_threshold: matched_pred.add(p_idx) matched_gt.add(g_idx) precision len(matched_pred) / len(pred_events) if pred_events else 1.0 recall len(matched_gt) / len(gt_events) if gt_events else 1.0 f1 2 * precision * recall / (precision recall) if (precision recall) 0 else 0.0 return { precision: round(precision, 4), recall: round(recall, 4), f1: round(f1, 4), matched_count: len(matched_pred), pred_count: len(pred_events), gt_count: len(gt_events), } if __name__ __main__: ground_truth [ {type: applause, start: 1.0, end: 3.0}, {type: applause, start: 10.0, end: 12.0}, ] predictions [ {type: applause, start: 1.2, end: 3.1}, {type: applause, start: 11.8, end: 12.5}, ] print(match_events(predictions, ground_truth))运行该脚本后会看到输出结果中包含 precision、recall、f1 等指标。如果 F1 偏低看到底是漏检还是误检漏检通常表现为 recall 低。可能原因包括视频画质差、动作幅度小、单次鼓掌时间过短、分段后动作被切碎。误检通常表现为 precision 低。可能原因包括模型把掌声、欢呼、靠近麦克风的动作甚至双手整理衣领的动作识别成了鼓掌。6.2 用“多段素材 多次重复”测试稳定性视频理解模型的输出有一定随机性。相同视频片段同一模型可能在不同温度设置下产生不同的事件边界。聪明做法是准备至少 5 段测试视频每段视频跑 3 至 5 次观察结果方差。如果结果波动大可以考虑降低模型的 temperature 参数或在 prompt 中增加“基于画面内容客观判断不要猜测”的约束。为了形成稳定的质量基线建议记录一份简单的验证清单测试项验证方法通过标准鼓掌事件召回比较人工标注事件是否都在模型输出中出现recall 不低于 0.8鼓掌事件误识别用没有掌声的视频测试模型输出事件应尽量少总次数稳定性同片段重复多次次数误差不超过 1 次时间戳准确度人工记录的掌声范围与输出范围比较IoU 大于 0.5 算匹配长视频覆盖用 5 分钟以上视频测试分段能力无片段遗漏绝对理想的值可能因视频场景不同而差异很大。但如果测试过程严格遵守同一套标准你的 Agent 工作流是不是真的比“直接把整段视频丢给模型”更稳定就可以得到明显证据。7. 视频理解智能体的常见问题与排查方法在实际把视频理解能力接入智能体时开发者经常在一开始就发现效果不如预期。以下问题来自我在视频分析和 Agent 开发中常见的真实技术损耗基本都可以通过调整工程链路来解决。问题现象可能原因排查方式解决方案模型输出不是 JSON提示词约束不够或模型版本对 JSON 输出支持弱查看原始返回文本使用结构化输出参数在提示中增加“只返回 JSON不要解释”鼓掌总数少了很多长视频被直接输入模型上下文有限查看视频是否被正确转码、分段增加视频分段逻辑启用重叠窗口同一段掌声被数两次相邻分段边界重叠导致重复事件未被合并打印各分片返回的事件时间戳调整 merge_gap完善事件合并逻辑没鼓掌的视频也检测出鼓掌音频或视觉信息被误判单独检查音频轨内容在 prompt 中强调“画面中双手接触并快速分离才算鼓掌”单独片段识别正常整体结果乱Agent 汇总逻辑没有统一事件格式检查各分片返回的 start/end 字段类型在解析层强制转换成 float并做排序与去重响应时间较长分片过多但任务可并行观察各分片耗时引入并发调用同时注意 API 限流其中最容易被忽视的是“Agent 汇总逻辑”。很多人以为问题出在视频理解模型不够聪明结果查了半天发现其实是模型对每个分片都返回了正确事件但汇总脚本里没有排序去重。所以建议在系统设计初期就把模型输出格式当成 API 契约来管理。模型输出必须能被机器读取后续一切统计、校验、报警才能自动化。另一个高频问题是把视频理解与音频理解混为一谈。鼓掌虽然通常伴随声音但有的视频里会出现后期添加的鼓掌声效或者现场其他噪音。如果任务要求精确识别“画面人物做出的鼓掌动作”Agent 应该把判断依据限制在视觉内容上否则容易产生由音频引起的误报。8. 视频理解 Agent 落地时的最佳实践与工程建议8.1 先稳定输出格式再提升准确率不管用哪种视频理解模型第一优先级都不是让模型“想得更深”而是让模型输出可以被程序稳定解析。建议在 prompt 中加入固定的 JSON Schema同时在代码层保留原始输出日志。一旦准确率下降可回溯对比当时模型版本和输出结构。不要试图依赖模型“随心所欲”的文本回答这会让后续所有 Agent 逻辑变成脆弱的字符串匹配。8.2 用 Agent 做校验而不只是做识别一个成熟的鼓掌计数 Agent不应只做一次视频分析就给出结果。可以增加一次校验步骤Agent 列出所有检测到的事件后把事件时间点附近的若干关键帧重新截图并让模型做二次验证。如果第二次识别结果与第一次相差过大就触发重新分析。这种“多轮自我校验”机制是 Agent 相对单次模型调用价值最大的地方之一。具体实现时可以在每一轮校验前加上简单的计数规则例如# 校验规则示例 def check_count_confidence(events, max_count20): if len(events) max_count: return need_review for event in events: if event[end] event[start]: return invalid_timestamp return ok8.3 注意数据权限和最小化传输视频文件通常含有敏感信息。如果使用云端多模态 API必须遵守权限边界并在数据处理前获得合法授权。对可落到本地的任务建议先对视频做场景裁剪只截取涉及判断的片段再上传。同时API 请求和返回结果中的视频原始文件、检测到的事件数据也要有明确的保存期限和删除策略。不要在提示词里加入无关个人信息避免数据泄露风险。8.4 不要把计数结果直接当成“最终事实”模型对视频事件的时间边界判断往往有几百毫秒甚至更大的误差。因此如果业务场景涉及自动处罚、用户行为判断或任何高风险决策建议把 Agent 输出标记为“初筛结果”并由人再复核。Agent 可以帮助审核员快速定位高潮时间段而不是完全替代判断。9. 下一步如何把演示能力变成自己的实战项目Gemini 3.7 Flash 及相关视频多模态模型近期的演示最值得关注的一点是模型本身的快速迭代减少了视频理解的技术摩擦力但真正决定成败的还是工作流。如果你现在想动手建议从一个更简单但能完整跑通的项目开始不必一开始就追求“精确数清鼓掌次数”。可以选择客厅摄像头录下的一段活动视频标注“人站起坐下”的次数或者体育比赛视频里“得分后击掌”的次数。这样的事件比鼓掌边界更清晰训练和验证都比较容易。跑通后再加入音频、多角度、长短镜头切换等干扰因素。如果你更关心 Agent 开发本身可以研究两条技术路线一条是模型自身直接消费视频输入另一条是模型通过工具调用查询外部视频分析服务。前者依赖多模态模型的持续迭代后者更接近现有系统集成方式。两条路线不冲突也适合做对比实验。在长期项目中建议把 Prompt 模板、视频分片参数、事件合并规则都当成需要版本管理的代码资产而不是临时写在配置文件里的魔术数字。这样当模型升级到新版本后你可以快速判断是模型能力提升导致效果变化还是你的视频拆解策略已经过时。把“数清楚鼓掌次数”当作一个标尺它可以度量视频理解模型的时间感知能力更可以度量你在智能体工程上的编排水平。下一次再看到类似的惊艳演示不妨把它拆开看几步模型到底做了什么Agent 又在外面做了哪些包抄。理解了这一层你的收获远比记住“某模型会数数”更有价值。建议收藏这篇文章也欢迎在评论区交流你自己的视频理解方案。如果你能从“把一段视频变成结构化事件列表”这个最小闭环开始动手很快就能体会到视频理解 Agent 与传统单轮模型调试的差异。
