有一次做活动素材复盘需要一个听起来很简单、实际非常反直觉的数据一场演讲过程中台下观众一共鼓了多少次掌。我第一反应是用音频处理。把录音拉出来做波形检测设一个能量阈值高过多少就算一次掌声。结果算法数出来四十多次人工对照视频一帧帧确认真正让全场节奏明显变化的掌声只有七八轮。差距这么大并不是代码写得不好而是这个任务从一开始就被引导到了错误方向鼓掌信息在听觉通道里充满噪声、混响和重叠在视觉通道里反而是相当清晰、有开始有结束的事件。标题里的那个案例——Gemini 3.7 Flash 借助智能体视频理解能力数清鼓掌次数——如果只看结果会觉得这不过是一次模型展示但把过程拆开它其实是“多模态视频理解 智能体工作流”配合完成真实任务的一个典型样本。我关心的问题不是它数得有多准而是这件事背后的迁移当模型能真正看懂一段视频里的动作、时序和群体行为过去大量需要肉眼回放、人工标注才能完成的琐碎分析就变成了一组可执行、可复查、可复用的智能体步骤。这篇文章我想顺着这个案例把问题拆开讲清楚为什么计数任务这么容易做错视频理解到底补上了哪块能力智能体在流程里起了什么作用以及真实落地时要怎么验证、怎么避坑。1. 数掌声为什么比想象中难先纠正一个解题方向1.1 音频通道天然不适合做事件计数单次拍手的声音特征是短促、高频、能量集中看起来很适合做阈值检测。但真实活动录音里问题远没那么干净。第一个问题是单位混淆。“拍手一声”和“一轮掌声”不是同一个粒度。一个人在台上试麦时拍两下手和全场听众持续鼓掌八秒在音频能量图上可能都会被标记成“有声音”。如果目标是一轮一轮地数掌声就必须先对相邻的拍手声做聚类合并而聚类边界非常难定掌声渐弱时什么时候算结束主持人刚说完话观众里又冒出零散几声算新的还是算上一轮的尾巴第二个问题是环境干扰。讲座现场有讲话声、笑声、音乐、桌椅移动、咳嗽、空调噪声。观众离麦克风远的时候掌声能量可能还不如一声清嗓子的音量高。加上场地混响每一个真实掌声都会在波形上拖出好几条尾巴阈值和窗口稍不一致计数结果就完全漂移。所以音频更适合做“是否有人在拍手”的提示信号不适合直接承担“数清楚几次鼓掌”的最终判断。这不是算法工程师不用心而是问题本身放错了模态。1.2 真正的可靠信号其实在视觉通道里换个角度看画面一个人鼓掌时双臂会周期性靠近双手拍合躯干有轻微前倾一群人鼓掌时画面里会出现一片相对同步的往复动作从安静的聆听状态进入群体动作状态再随着掌声结束回到安静状态。这个起止边界在画面里通常比在音频里更干净。这意味着“数清楚鼓掌次数”不应该被定义成声音能量检测问题而应该被定义成一个视觉事件分割问题在时间轴上找到所有“多数人从非鼓掌状态进入鼓掌状态并持续一段时间再退出”的片段然后统计片段数量。过去这类工作靠人肉完成成本高且枯燥。传统计算机视觉方案要先做人员检测、姿态估计、手部关键点跟踪再用启发式规则判断动作是否属于鼓掌工程链路极长换一个机位就要重新调参。而具有视频理解能力的多模态模型天然跨过了“识别关键点”这一步它可以直接理解画面中的动作语义。1.3 先定义“一次鼓掌”再去数这里还有一个经常被忽略的前提任务定义。在开始计数之前至少要确定“鼓掌一次”指什么单人拍手一下短促事件粒度最小。一轮群体掌声多数人进入鼓掌状态并持续一段时间随后结束。一轮掌声内部还有强弱变化如果中途掌声一度明显中断又重新爆发是算两轮还是一轮。对不同目标正确答案不同。标题案例里的“数清鼓掌次数”如果目标是数群体性、有一定持续时间的一轮轮掌声那模型在视觉上要捕捉的其实是群体状态切换而不是某一只手的动作。定义没定清楚再强的模型也会给你一个“看起来像模像样但不知道在算什么”的数字。所以真正专业的做法是先把任务定义写成可执行规则目标事件是什么、开始和结束怎么判断、相邻事件怎么合并、模糊情况怎么处理。这个规则既写给模型也写给人。2. Gemini 3.7 Flash 这类视频理解模型解决的其实是“时间语义”2.1 输入从“单帧识别”变成了“整段视频理解”传统图片理解模型只能看一张静态图。要观察鼓掌单帧画面不够你无法从一张照片判断一个人是在鼓掌还是仅仅举着双手、准备喝水、和旁边人打招呼。动作是一个随时间展开的过程只靠静态帧容易误判。Gemini 3.7 Flash 所属的这类多模态模型支持直接输入视频或按规则抽样的帧序列让模型在整个时间跨度上做推理。用户不再需要先写一个视频抽帧服务再写一个人体检测模块再写一个动作分类器而是可以直接把视频素材交给模型用自然语言描述要统计的事件模型返回带时间起止的结果。这是交互方式的改变也是能力边界的改变过去计算机视觉要按“检测、跟踪、分类、后处理”搭流水线现在很多长尾动作任务可以先用模型能力去理解再针对误差做校验。2.2 “看懂鼓掌”不等于识别手掌而是理解一段时间里的群体状态如果把“数清鼓掌次数”这件事拆细模型真正需要具备多层语义理解能识别画面中“人在做拍手动作”。能判断这种动作是少数人偶然发出还是多数人共同进入的群体状态。能把连续画面中的动作状态划分成“安静—鼓掌—安静”这样的时间段。能区分一次长时间掌声内部的中断并决定是否拆分。这已经不只是视觉识别而是一种“时间轴上的场景理解”。模型要把每几秒的画面变化与语言指令对齐输出结构化事件列表。它在某些视频里甚至能写出“第 12 秒开始出现零星掌声第 15 秒进入全场鼓掌持续约 9 秒后结束”这样的描述。顺着这个能力再往前走一步就很容易想到既然能数掌声那能不能数喝水次数、人员进出次数、举手次数、危险动作出现的次数视频理解的价值不只是“看懂内容”而是“把视频变成可以查询、可以统计、可以触发后续动作的结构化数据”。2.3 这类模型之所以适合跑进智能体流程关键在效率我个人不太建议把每个视频分析任务都交给最重的旗舰模型去跑。视频理解本身计算量大如果还要在智能体流程里反复调用延迟和成本会迅速放大。Gemini Flash 系列在 Gemini 产品线里的定位偏轻量、低延迟这类模型更适合承担需要多次迭代、批量执行、快速返回中间结果的任务。Gemini 3.7 Flash 的视频理解案例之所以能做成智能体流程一个隐含前提就是模型调用成本足够低、响应足够快否则多轮“分段—复核—汇总”的智能体循环根本跑不动。这也是选型时容易忽略的不要只看谁“能力更强”要看你的流程需要调用多少次、单次延迟是多少、单位成本能不能支撑正式使用。先看模型定位再设定流程往往是更稳妥的顺序。3. 智能体不是包装它负责把“一次判断”变成“一条流程”3.1 单次提示词调用为什么不够你也许觉得既然模型能看懂视频给它一句“请统计这段视频里观众一共鼓了几次掌”它直接输出答案不就完了单次调用确实可能成功而且在小样本演示里看起来非常惊艳。但它有几个问题第一输出不稳定。同一段视频、同一句提示词连续跑几次模型给出的边界和总数可能不一样。多模态模型在时间边界上的判断天然存在一定随机性。第二无法定位错误。如果模型把两个隔着很久的掌声段误合成一次你只能看到一个错误总数不知道模型在哪一步理解偏了。第三难以复核。要确认结果是否可信必须让模型把结论依据带出来是在第几秒发现的画面里发生了什么如果模型只给一个总数人工根本没有办法验证。智能体要解决的核心并不是“让模型更聪明”而是把一次模糊的单步判断拆成可观察、可干预、可复核的多步流程。3.2 一个可复用的四步流程分段、判别、合并、复核针对“数掌声”这类事件统计任务可以抽象出一个通用框架分段让模型把整段视频切成候选事件片段输出每个候选片段的起止时间。判别对每个候选片段做第二轮视频理解判断它是否符合“群体同时鼓掌并持续一段时间”的定义。合并把相邻的、属于同一轮掌声的片段合并消除因为噪声导致的碎片化。复核输出带边界和说明的事件列表抽样让人工确认低置信度片段。把这段流程反过来看最重要的是第 4 步结果必须保留依据。输出一个“总次数为 7”对使用者没有意义使用者更想知道的是“第 7 次发生在什么时间、怎么判断的”。只要把中间步骤暴露出来即使模型偶尔数错人也能够很快修正而不是返工重跑。落地时大致的伪流程可以长这样输入视频文件 V任务定义 D 1. 段扫描V - 候选事件 [{ start, end, 描述 }] 2. 逐段复核对每个候选事件再次调用视频理解判断是否保留 3. 事件合并按 D 中“一次掌声”的边界规则合并相邻事件 4. 结果生成输出 [{ start, end, note }] 总数并附置信度 5. 人工抽查对低置信度事件做 10%~20% 抽样复核这个流程看起来只是多了几步但它换来了可靠性、可解释性和可复用性。3.3 可用平台很多先想清楚要自己搭还是用现成的现在做智能体工作流的选择比以前多很多Dify、扣子Coze、LangGraph以及各类云厂商提供的智能体平台都有成熟的编排能力。把视频上传节点、视频理解模型调用节点、JSON 解析节点和人工复核节点串起来可视化界面里就能完成。对想快速验证想法的人现成平台通常是最优解因为它已经把多步调用、记忆、异常处理这些工程细节封装好了。对数据有保密要求、需要私有化部署、或者已经有一套视频处理系统的团队更值得走自建路线把模型请求封装成内部服务再接入现有任务队列。我自己更建议的顺序是先用手上最容易使用的平台把 3 到 5 条样本视频跑通验证“这个任务到底能不能用视频理解模型完成”再决定是否投入资源做工程化封装。很多人一上来就设计复杂架构结果连模型能否稳定识别目标事件都没验证过这是本末倒置。4. 从“能跑通”到“可复现”一次完整的最小验证怎么设计4.1 先用小样本验证不要急着批量跑单次跑通只能说明流程没有断不能说明方案可用。真正决定能不能长期使用的是漏检率和多检率而这两个指标必须拿人工标注结果去对照。我第一次跑这类任务时犯过一个典型错误拿一条完整的 30 分钟演讲视频直接丢进去让模型数全场掌声。结果流程确实跑完了输出也生成了一份时间轴但后来人工抽查时才发现后半段漏了两个很短的掌声片段。原因不是模型不认识鼓掌而是演讲很长模型对后半段素材的注意力分配不足或者视频被压缩采样后漏掉了关键帧。正确做法是建立小样本验证集选择 3 到 5 条视频优先选择画面里有清晰观众席、掌声边界明显的素材。每条截取 30 到 90 秒不要一上来就处理完整长视频。至少让一名人工标注者写出“掌声发生了哪几轮”的参考结果。用同样的流程连续跑 2 次观察结果是否稳定。检查漏检、多检、边界偏移三类误差再决定是否扩展。验证项可以按下面这个维度去设定验证项建议值原因测试视频数量3 到 5 条太少看不出偶然性单条视频时长30 到 90 秒成本低便于快速迭代鼓掌定义统一为“一轮群体掌声”减少歧义结果可对照参考标准一名以上人工标注用来计算误差重复运行次数每条至少 2 次观察计数漂移情况4.2 提示词里要写清楚定义和输出格式这里的提示词不是简单说“数一下鼓掌次数”。要给模型明确的任务边界、排除条件和输出结构。一个常见写法你是一个视频事件分析器。下面输入一段会议/演讲现场视频。 请找出所有属于“观众掌声”的片段。掌声的定义是 画面中多数观众同时做出拍手动作并且该状态持续一段时间后结束。 零星的一两声不算纯环境噪声不算。 输出格式为 JSON 数组每个元素包含 - start_second开始秒数 - end_second结束秒数 - confidence置信度取 0 到 1 - note判断依据一句话即可 如果画面中没有符合定义的掌声输出空数组 []。 不要输出任何解释性文字。要求 JSON 输出有两个好处一是让后续智能体流程能稳定解析二是迫使模型进入“事件列表”而非“自由发挥”的语言模式。如果模型在回答里夹带大段说明下游节点解析时很容易出错。不要忘记长视频的处理。如果平台对视频长度有限制或者某次需要分析完整演讲通常要先按固定时长切割视频把每段结果汇总。切割时保留前后 3 到 5 秒重叠区避免掌声在切缝处被生生拆开。4.3 漏检、多检、计数漂移按什么顺序排查真实使用中一定会遇到模型结果不理想。千万不要一上来就怀疑模型不行按照下面的链路走大多数问题都能定位到更具体的环节。看现象是漏检、多检还是边界偏移现象不同处理方式完全不同。看输入视频是否清晰观众是否在画面里鼓掌有没有明显动作如果观众在远景里只有二三十像素高那模型漏检更多是素材限制不是流程问题。看定义提示词里是否把“零星拍手”和“群体掌声”混在一起如果连人都分不清“数哪一次”模型当然更分不清。看流程分段时是否漏掉了某些片段长视频是否被截断相邻事件是否被不合理地合并逐段复核是否真的执行了看模型边界视频里有复杂剪辑、频繁切换机位、快速摇镜头时模型在时间轴上可能会把不同机位的画面当成交替出现的场景导致计数偏差。此时要考虑分镜处理后再理解。建议在实际过程中把每一步中间结果都存下来。只要看到“哪一个环节开始出现偏差”就不会陷入对模型能力本身的空泛怀疑。5. 这套方案的边界要写在使用之前5.1 适合什么场景从工程经验看视频理解加智能体计数最合适的是“人工标准难以规模化”的场景活动视频复盘统计演讲过程中的掌声次数、互动时段。课堂教学观察统计学生举手次数、起立次数、小组讨论片段。会议视频检索从长会议里找出与会人员有明显情绪反馈的时间段。直播内容二次整理按事件把直播片段拆出结构。这些场景的共同特点是允许存在少量误差但需要能快速定位关键事件并且希望把人工从“从头到尾看视频”里解放出来。5.2 不适合什么场景也要诚实写清楚这套方案不擅长什么。如果视频画面里观众是背影、人数非常多、或者每个人只有很小的像素面积模型很难从视觉上判断鼓掌边界。此时依靠音频模块做辅助可能更好但音频本身也有回声和重叠的问题两种情况叠加只能降级为“候选提示”不能当作精确统计。如果鼓掌声很微弱、持续时间很短或者鼓掌者和镜头之间有遮挡计数准确度会明显下降。更极端的是画面只有一个人在拍手、镜头还一直晃动这种素材别说模型人去看都容易漏判。如果用户需要的是“用于司法认定、医疗判断、极高精度审计”的事件计数那这类模型的输出只能作为辅助参考绝不能当作唯一依据。所有由概率模型生成的判断都需要保留原始素材、中间结果和人工复核链路。下面是针对具体使用的一个判断表场景维度适合使用谨慎使用观众人数画面中可见多数人画面只拍背影或远景掌声形态群体同时鼓掌边界明显零散、微弱、被遮挡视频质量清晰、稳定、观众区域可见低分辨率、快速剪辑精度要求统计趋势、粗粒度事件法律取证、医疗判断处理成本短视频可批量长视频海量且缺少预算5.3 如果要做成产品还缺什么能力一个 Demo 和一套稳定产品的差距通常不在模型能力而在这几件事评估集、版本管理、兜底策略和日志。必须建立自己的评估集。把测试视频和人工标注结果保存下来每次替换模型版本、调整提示词或修改智能体流程后都要在同一套评估集上跑一遍比较数字是变好还是变差。没有评估集一切改进都只能靠“感觉”。必须给低置信度结果留出口。当模型的 confidence 低于某个阈值时不能直接把计数结果写进报表而应该进入人工复核队列。高召回场景可以把阈值压低高精度场景可以把阈值抬高。必须记录日志。每一次调用的模型版本、视频输入、提示词、输出结果、耗时、置信度都要留下来。否则以后用户问“上次那个视频为什么少统计了一次”你根本没法回答。6. “看懂视频”之后真正改变的是智能体与真实世界的交互方式6.1 视频理解让“内容处理”变成了“事件处理”以前的视频分析系统更多是围绕检索来做用户搜索“演讲者”系统找到演讲者出现的画面。这仍然是静态信息匹配。而当模型能识别动作、时序和事件后视频系统可以做的事情发生了质变它不再回答“画面里有什么”而是回答“画面里发生了什么、发生在什么时候、我应该接着做什么”。活动负责人可以自动获得掌声密度报告课程设计师可以自动获得课堂互动时间轴内容团队可以自动把直播切割成带事件标签的片段。这些以前根本无法自动化因为每一条都需要一个真人把视频完整看一遍。智能体在这个链条里的角色是把“模型看懂视频”转换为“按规则执行后续动作”。模型负责感知和理解智能体负责安排流程、调用节点、判断是否复核、输出结果。两者结合视频才从“存储的录像”变成“可编程的数据来源”。6.2 智能体开发需求增长的背后是任务形态的变化这也能解释为什么行业内对智能体开发的需求增长得这么快。今天判断一个软件工程师值钱的技能不再只是会写 API 接口还要能把 AI 模型能力组合进真实业务流知道某个长尾任务应该拆成几步知道每一步该用模型还是规则知道如何设计人工复核知道怎样评估结果变化。这类能力需要的不是某一个模型的使用技巧而是一种工程思维方式把模糊问题定义清楚把不可靠的单步调用变成可验证的多步流程把一次性的成功变成可以重复运行的服务。视频理解只是其中的一个输入源。以后很多业务团队里会多出这样一个角色它既懂怎么让 AI 看视频又懂怎么定义业务事件。一个没有编程背景的内容运营用现成智能体平台也能搭建一条“视频掌声统计”流程一个后端工程师则可以把这条流程封装成企业内部的媒体分析 API。两者其实在做同一件事把模型能力落到具体业务判断上。6.3 请把第一次成功变成一个可复用的验证资产回到标题里那个数掌声的案例最值得借鉴的不是模型本身而是流程方法。如果你想在真实场景里做类似的视频分析智能体我的建议很简单不要只追求“跑通一次”而是把第一条测试视频、第一份人工标注结果、第一版提示词、第一次输出抽样报告全部保存下来。它们是你之后就这个任务做迭代的全部起点。下一次遇到的新任务比如“统计一张台上谁最先举手”“找出直播里用户情绪最激动的三个片段”“统计视频里出现了多少次安全违规动作”都可以复用同一套框架定义目标事件先用小样本找出模型能看懂的边界再进入流程化验证。一个能跑通、能解释、能抽检、能记录版本的小系统永远是空谈大模型概念更有价值的东西。人仍然在流程里负责定义问题、验证错误、兜住边界。这正是智能体时代给人留下的位置把复杂规则交给流程把最终判断握在手里。