做Agent开发的朋友应该都有同感：模型再聪明，只要输入通道只有文本，它就像一个只能听不能看的人。我最近在折腾多模态Agent的时候，一直被一个问题卡住——怎么让Agent真正“看懂”一段视频，而不是只靠文件名和用户描述去猜。直到我把 claude-video 这个 Skill 写完并跑通之后，这个痛点算是彻底解决了。

claude-video 是一个面向Agent的Skill插件，它做的事情很简单：给Agent装上“眼睛”，让Agent能接受一个本地视频文件作为输入，然后输出结构化的视频分析结果，包括内容摘要、事件时间线、关键画面描述、字幕和画面的交叉比对等。如果你正在做Agent开发、AI视频内容理解、自动化视频笔记这类项目，这篇文章应该能帮你省下不少踩坑的时间。我会从设计思路、核心机制、实操步骤到问题排查，把整个实现过程完整讲一遍。

1. 为什么Agent需要一双“眼睛”

1.1 我在实际场景里遇到的卡点

事情起源于一个很朴素的需求：我手头有一批产品演示录屏，大约二十多个，每个都在十分钟到半小时不等，我需要快速提取出每个视频里的操作步骤、界面变化和讲解要点。一开始我的方案很原始，先把视频转成音频，再用语音识别转成文字，最后把文字丢给模型总结。结果发现这个路径有一个致命缺陷——画面信息完全丢失。

比如演示视频里，操作者说“点击右上角的按钮，然后拖拽到左侧”，如果不看画面，你根本不知道“右上角的按钮”长什么样、拖拽产生了什么效果。视频里的视觉信息，比如界面布局、报错弹窗、光标移动轨迹、图表数据变化，这些内容光靠语音转写是拿不到的。这是我做这个项目最直接的动机：Agent要理解视频，必须同时处理画面和声音，缺一不可。

当时我也试过直接把视频上传到一些在线多模态工具里，但限制很明显：时长超出上限、文件太大传不动、处理速度慢，更关键的是这些工具没法集成到我的Agent工作流里。我需要的是一个能被Agent自动调用、本地运行、输出结构化的方案。这个需求催生了 claude-video 这个Skill。

1.2 现有多模态API的边界

你可能要说，现在Claude、GPT这些模型本身不都支持视觉输入吗？把视频关键帧直接扔给模型不就行了？理论上确实可以，但实际操作里有几个绕不开的问题。

第一是上下文窗口的限制。一个小时的视频，按每两秒一帧来算是一千八百帧，直接全部塞进上下文根本不现实，即便塞进去，模型也会在大量冗余信息里迷失重点。第二是视频中的连续动作无法用单张帧表达。比如一个动画演示、一个拖拽操作，单独的某一帧根本看不出因果链，模型会误判。第三是成本，视频帧图片数量一旦上去，多模态接口的token消耗会让人肉疼。

所以核心矛盾是：视频是高密度的连续信息流，而多模态模型的输入是离散的、有数量限制的图片和文本。claude-video 的思路就是在这两者之间架一座桥，把视频这种连续信号，拆解成模型能高效消化的离散单元：关键帧图片序列加带时间戳的音频转录文本。

1.3 claude-video 到底是什么

简单说，它是一个遵循 Agent Skills 规范的自定义技能包。Agent在运行过程中识别到任务涉及“视频理解”“视频总结”“提取视频时间线”等场景时，会读取这个Skill里编写好的说明文档，然后按文档指引调用内置的脚本，完成视频解析，最后把解析结果交给主模型做推理输出。

而它解决的核心问题，就是让Agent在没有原生视频输入能力的前提下，通过“抽帧 + 转录 + 时间轴对齐 + 多模态组装”的方式，把视频变成一组有序的图片和文字材料，再让多模态模型逐段理解并汇总。这套流程最大的价值在于：它不挑视频格式，不依赖云服务，能在本地完整跑通，而且可以嵌入任意Agent框架使用。

如果你正在做这类项目，这个Skill的思路可以直接复用。它适合的读者包括：想给Agent加多模态能力的开发者、做视频内容自动化处理的工程师、研究Agent Skill机制的爱好者，以及需要批量处理培训视频、会议录像、教学课程、产品演示的从业者。

2. Skill机制与整体设计思路

2.1 Skill 到底是什么，它和 Tool、框架有什么区别

现在Agent开发圈里，Skill 和 Tool 这两个词经常被混着用，但实际它们负责的事情不一样。Tool 在我的理解里是面向过程的原子能力，比如“搜索网页”“调用某个API”，输入输出是刚性的，参数固定，一次调用完成一个函数的活。Tool 更像一把螺丝刀，功能明确、即插即用。

Skill 则完全不同，它是一份“岗位说明书”加上配套工具箱。Skill 里通常包含一份 SKILL.md 格式的说明文档，里面写清楚这个技能在什么场景下被触发、需要哪些前置条件、执行流程分几步、每一步调用什么脚本、输出结果长什么样。Agent读取这份文档后，会像人看SOP一样，按步骤执行整个流程。Skill 更像一个微型的业务包，可以包含多个Tool调用、多步决策逻辑和专用提示词。

而 Harness、Agent框架这些东西是承载Agent运行的外壳，负责进程管理、模型调用、工具注册、死循环防护等。Skill 是挂在外壳内部的能力模块，与框架之间是相对解耦的。你完全可以把同一个 claude-video Skill，从一个框架迁到另一个框架，只要框架支持按 SKILL.md 格式识别技能，基本就能无缝使用。

2.2 为什么选 Skill 形态来做视频理解

我一开始也在纠结，视频解析逻辑直接写成Python函数注册成Tool不就行了，为什么非要包一层Skill？做了一半我才明白，视频理解这种任务根本不是一个原子操作能覆盖的，它需要多步编排：先探测视频参数，再决定抽帧密度，接着做音频转录，然后拼接图片，最后组装上下文，每一步之间还有条件判断。如果把这一整串流程塞进一个Tool函数里，函数会变得臃肿且失去灵活性。

Skill 的好处在于，它把决策权交还给了Agent。SKILL.md 里我会写明：如果视频时长小于两分钟，抽帧间隔用2秒；如果大于三十分钟，抽帧间隔调到10秒。Agent在运行时读到这些规则，会根据实际情况调整行为。这种灵活度，是普通Tool函数给不了的。

另外，Skill 天然适合分享和复用。我写完 claude-video 之后，只需要把整个目录复制出来，放到另一个项目的 skills 目录下，再用一句“让Agent去读一下 claude-video 的说明”就能启用。团队的同事拿到这个目录也能直接集成，不需要理解我代码里的所有细节。

2.3 整体工作流：先拆解，再理解，最后汇总

claude-video 的核心设计原则就八个字：先拆解，再理解，最后汇总。视频这东西没法像文本一样直接“读完”，所以第一步永远是拆。整个Skill的工作流可以概括成下面这条链路：

视频文件进入后，Skill先调用 ffprobe 探测视频的时长、分辨率、编码格式、帧率，拿到这些基础参数后，再根据策略执行抽帧和抽音。抽帧阶段生成一批JPEG图片，抽音阶段生成16kHz单声道的WAV文件，然后走语音识别转成带时间戳的文本。接下来是组装阶段：把时间片段内的帧拼成网格图，把对应的识别文本按时间标签对齐，形成多个“时间段素材块”。最后把这些素材块按顺序交给多模态模型，模型逐块理解，最终生成全局分析结果。

这个链路最微妙的地方是“拆”的粒度。拆得太粗，关键画面会被漏掉；拆得太细，上下文会被冗余信息淹没。为了平衡，我做了一个动态策略：默认每五秒抽一帧，但如果检测到画面场景切换频繁，会在切换点附近额外补帧。这个策略在后面章节我会详细说。

3. 关键环节逐个拆解

3.1 第一步先预检视频，不要一上来就抽帧

很多类似的工具项目，一上来就ffmpeg抽帧，结果抽到一半发现视频分辨率是4K，或者时长超过预期，后面全乱套。我在Skill里加入预检这一步，其实是被坑过之后才想明白的。

预检要做三件事：用 ffprobe 拿时长、分辨率、码率、音频流是否存在。时长决定抽帧策略，分辨率决定要不要先压缩，音频流是否存在决定要不要跳过转录步骤。比如我遇到过一个无声的动画演示视频，没有音频流，如果脚本硬着头皮去转录，只会得到一段乱码。

预检的具体实现可以很简单：

ffprobe -v quiet -print_format json -show_format -show_streams input.mp4

解析返回的JSON，拿到时长、宽度、高度、是否有audio_stream这几个字段。然后根据这些参数生成一个 profile，比如“短视频-1080p-有声”“长视频-720p-无声”这样的组合标签，后续步骤都基于这个profile来决策。这一步花了十分钟写，但减少了后面百分之八十的异常情况。

3.2 抽帧策略：均匀抽帧是保底，场景抽帧才是关键

抽帧是整个Skill的视觉基础，也是我调整次数最多的环节。最初我用最粗暴的办法，每秒一帧均匀抽，一个十分钟的视频就是六百张图，处理速度和token消耗都撑不住。后来改成每五秒一帧，信息密度又不够，重要画面恰好落在两帧之间的情况时有发生。

最终的方案是“均匀抽帧保底 + 场景切换补帧增强”。均匀抽帧保证整个视频都覆盖到，场景切换检测则负责捕捉那些画面急剧变化的关键时刻。ffmpeg 提供了场景检测能力，它的原理是计算相邻帧的像素差异，差异超过阈值就判定为场景切换点：

ffmpeg -i input.mp4 -vf "select='gt(scene,0.3)',showinfo" -f null - 2>&1 | grep "pts_time" | awk -F: '{print $2}' | cut -d' ' -f1

譬如一个产品演示视频，画面从桌面切到浏览器时的分值通常会飙到0.5以上，这些切换点往往对应着操作阶段的切换。把切换点时间戳存下来，在切换点前后各补抽一帧，比单纯靠均匀抽帧可靠得多。

抽帧参数方面，我最终的建议是：分辦率统一缩到720p宽度，JPEG质量设为2到3，抽帧间隔默认5秒。720p已经能保留大部分视觉细节，再高分辨率只会白白增加token消耗。如果在处理4K长视频，可以先做一次抽帧前的宽高压缩，能明显提升速度。

3.3 音频转录：时间戳准不准，直接决定后面能不能对齐

音频转录这件事看起来成熟，但其实坑非常多。我选用的是 faster-whisper 这个库，相比原版whisper它的推理速度快很多，而且自带vad过滤静音，能省不少事。提取音频用ffmpeg：

ffmpeg -i input.mp4 -vn -acodec pcm_s16le -ar 16000 -ac 1 audio.wav

降到16kHz单声道是为了匹配语音识别模型的输入要求，同时也能显著减小文件体积，处理一小时音频也就一百多兆。

转录时我要求模型输出带时间戳的JSON或者SRT格式。时间戳精确到毫秒很重要，因为后面要把文本按帧的时间区间进行切分，如果时间戳是整秒的，误差会放大，字幕和画面经常差出两三秒。faster-whisper 的基本用法：

from faster_whisper import WhisperModel
model = WhisperModel("medium", device="cuda", compute_type="int8")
segments, info = model.transcribe("audio.wav", vad_filter=True)
for seg in segments:
    print(f"[{seg.start:.2f} - {seg.end:.2f}] {seg.text}")

模型大小方面，中文视频我用 medium 起步，small 在带口音的普通话上错误率高到没法用。英文视频 small 只要录音清晰也能凑合，但保险起见我还是统一用 medium。int8量化能省将近一半显存，速度影响不大，属于必选项。

3.4 帧图拼接：别一张张丢给模型，要学会打包

抽帧得到的图片如果直接一张张丢给模型，token很快会爆炸。我做了两个层面来解决这个问题。第一个层面是网格化，把六张到九张帧图拼成一张3x3的网格图，模型一次就能看完9个画面。第二个层面是阶段化，先给模型一张“全局导航图”，包含首帧、尾帧和几个关键场景帧的拼接图，让模型对视频内容建立整体概念，再按时间顺序给细化的分段时间素材块。

网格化用Pillow实现起来很简单：

from PIL import Image
paths = ["frames/0001.jpg", "frames/0002.jpg", ...]
images = [Image.open(p) for p in paths]
# 统一缩放到相同尺寸
images = [im.resize((320, 180)) for im in images]
grid = Image.new("RGB", (320 * 3, 180 * 3), color="white")
for i, im in enumerate(images):
    x, y = (i % 3) * 320, (i // 3) * 180
    grid.paste(im, (x, y))
grid.save("grid_0001.jpg", quality=85)

拼接的时候，一定要在网格图下方用蒙版或者文件名标注这一块的时间范围，例如“00:00:00 - 00:00:27”。模型看到带时间标签的画面组合，才能把画面内容和对应时间的字幕关联起来。

3.5 提示词模板：两阶段理解，先全局后局部

组装完素材之后，真正决定输出质量的是提示词模板。我写了两套提示词，一套负责“全局概览”，一套负责“分段细读”，让模型分两步完成理解。

全局概览阶段，输入是一张视频封面拼图和视频基础信息，要求模型输出：视频类型判断（教程、会议、演示、监控等）、整体主题、可能的目标观众。这一步是为了让模型在细读之前脑子里有个框架，知道重点该看哪里。

分段细读阶段，输入是按时间排序的多个素材块，每个素材块包括一张3x3网格图和对应的字幕文本。提示词要求模型按如下结构输出：

• 时间段描述：这一时间段内发生了什么
• 关键视觉元素：画面中出现的关键信息，例如界面按钮、图表数值、人物动作
• 字幕要点：语音内容的信息提炼
• 画面与字幕的匹配度：是否存在说了A但展示的是B的情况

最后再有一个汇总阶段，把分段结果按时间线合并，生成摘要、事件时间线、关键信息列表。看到这里你可能发现了，这个流程本质上是把一个长视频理解任务，拆成了“全局概要 + N个分段细读 + 最后汇总”的三段式结构。这种设计不是因为我偏爱复杂，而是因为模型在限定上下文长度内的表现，一定是局部理解强于全局理解。

4. 实操：把 claude-video 跑起来

4.1 环境准备与目录结构

先把依赖说清楚。我的运行环境是 Python 3.10，主要依赖有 faster-whisper、Pillow、ffmpeg-python，以及anthropic的SDK或你选用的任何多模态模型SDK。如果只是运行抽帧和转录脚本，不接Agent框架，那只要ffmpeg安装好、Python依赖装齐就行。

Skill目录结构我设计成下面这样：

claude-video/
├── SKILL.md
├── scripts/
│   ├── probe_video.py
│   ├── extract_frames.py
│   ├── extract_audio.py
│   ├── transcribe.py
│   ├── build_grids.py
│   └── assemble_context.py
└── resources/
    ├── prompts/
    │   ├── global_prompt.txt
    │   ├── segment_prompt.txt
    │   └── summary_prompt.txt
    └── output_schema.json

SKILL.md 放在根目录，scripts目录放脚本，resources目录放提示词和输出格式定义。这个结构是Agent开发社区里比较主流的Skill组织方式，maintain起来也符合直觉。

4.2 SKILL.md 怎么写才容易被Agent正确触发

SKILL.md 是整个Skill的入口，Agent会不会主动调用它，完全看这份文档写得清不清楚。我第一次写的时候写得过于简洁，Agent经常在用户明确提到“分析一下这个视频”时，还尝试用普通文本方式去处理，而不是触发这个Skill。

问题出在 description 写得不够直白。Agent对技能触发条件的理解，完全来自于 SKILL.md 里的 description 字段和正文里的场景示例。我最后改成了这样一段话：

---
name: claude-video
description: 当用户要求分析、总结、理解一个视频文件，或者需要提取视频中的关键画面、字幕、操作步骤时，使用本Skill。
---

# claude-video

让Agent具备视频理解能力。输入是一个本地视频文件路径，输出是结构化的视频分析报告。

## 适用场景

- 用户提供视频并要求总结内容
- 用户要求从视频中提取操作步骤或教程要点
- 用户需要视频事件时间线或关键画面描述
- 用户需要分析会议录像、产品演示、教学视频

## 资料准备

- 需要本机已安装 ffmpeg 和 ffprobe，并确保视频文件路径可读
- 如果视频没有音轨，自动跳过转录步骤，只做视觉分析

## 执行步骤

1. 运行 probe_video.py 获取视频参数
2. 根据视频时长决定抽帧策略，运行 extract_frames.py
3. 如果存在音轨，运行 extract_audio.py + transcribe.py
4. 运行 build_grids.py 生成网格图
5. 调用多模态模型，先执行全局概览，再执行分段细读，最后汇总
6. 按照 output_schema.json 的格式输出结果

后面这部分内容，Agent在执行时会跟着走。注意里面的“适用场景”部分非常关键，我收集了各种可能触发这个Skill的描述方式，比如“帮我看看这个录屏里做了什么”“这个培训视频讲的是什么”，都写成示例，Agent触发准确率一下就上来了。

4.3 核心脚本的参数逻辑

探针脚本 probe_video.py 是整个流程的起点。它的核心逻辑是：读入视频路径，用ffprobe拿到时长和流信息，然后打印成JSON。这部分不需要什么复杂逻辑，但要注意处理异常情况，比如文件不存在、ffprobe没装、视频有多个音轨等。

抽帧脚本 extract_frames.py 是我调试最多的部分。它的逻辑分两块：先用ffmpeg均匀抽帧，再对场景切换位置补帧。核心参数是帧间隔，我设置的逻辑是：

interval = 5
if duration < 120:
    interval = 2
elif duration > 1800:
    interval = 10

这个规则的背后逻辑是：短视频需要足够密的采样才不会漏信息，长视频如果采样过密，后续处理的费效比就会失控。我实测下来，一个一小时讲座类视频用10秒间隔抽帧，大概三百六十帧，已经足够覆盖内容。

音频转录脚本 transcribe.py 依赖 faster-whisper，我在脚本里加了两个处理：

• 开启 vad_filter，去除静音段，减少无效转写
• 把模型语言参数设为 auto，让模型自动判断中英文，避免中英混说的视频被单一语言模式干扰

build_grids.py 负责把帧拼成网格图，同时记录每个网格对应的起始和结束时间。这里有个细节：同一时间段的网格图和转录文本要共用一个时间键。比如时间键“000120-000145”对应帧网格grid_0024.jpg，也对应转录文本中start在120秒到145秒之间的字幕片段。只有用同一个时间键关联图片和文本，后续上下文组装才能保持对齐。

4.4 一次完整的运行示例

拿一个真实场景示范一下。假设我手头有一段时长8分钟的产品演示录屏，文件叫demo_session.mp4，内容是一个人演示如何配置API密钥并调用接口。如果把这个任务交给配好 claude-video 的Agent，整个执行过程是这样的：

Agent先读取SKILL.md，识别到“产品演示”属于适用场景，于是开始执行。第一步用 probe_video.py 探测，拿到结果：时长480秒，分辨率1920x1080，有音频流。因为视频短于十分钟，抽帧间隔设为2秒，于是抽出了大约两百四十张帧。再通过场景检测，识别出大概六处明显的画面切换点，每个切换点前后补一帧，最终帧文件约两百五十二张。

音频转录部分，faster-whisper 用 medium 模型跑了大约一分钟，生成了带时间戳的转录文本，总字数约九百字。画面拼成二十八张3x3网格图，每张对应约十六秒的视频内容。接下来进入多模态理解阶段，第一轮调用全局概览，模型看到封面和关键帧拼图，确认这是一堂API接入教学。第二轮按时间顺序，把二十八组网格图和字幕片段依次输入给模型，分段细读。最后一轮汇总，输出一份包含操作步骤、涉及界面区域、关键配置参数、常见错误提示的分析报告。

整个流程从输入视频到拿到报告，耗时大约三到四分钟，主要时间花费在转录和模型推理上。如果视频是无声的，转录步骤跳过，整体时间还能再缩短一半。这就是完整的运行效果。

5. 常见问题与避坑实录

5.1 长视频Token爆炸，怎么控制消耗

长视频是整个方案最大的敌人。我做压力测试时，拿了一个两小时的培训视频，按五秒间隔抽帧，光帧就有一千四百多张，即使拼成网格图也有约一百六十张。如果全部塞给模型去细读，token消耗直接爆表，费用也相当可观。

控制Token消耗我摸索出三个有效手段。第一是提高抽帧间隔，长视频从五秒改成十秒甚至十五秒，信息密度损失没有想象中那么大。第二是引入摘要模式，对于超过半小时的视频，先让模型对每十分钟的视频段生成一个“粗摘要”，最后再基于粗摘要生成总报告，而不是让模型细读全部素材。第三是只保留高价值帧，通过场景检测去掉连续重复的静止画面。例如讲座类视频中PPT画面占比很高，画面几乎不变，连续抽帧浪费严重，场景检测可以有效过滤掉这些冗余帧。

5.2 画面对不上字幕，时间轴偏移怎么修

时间轴对不齐这个问题，我踩过好几次。最典型的表现是，模型描述的画面内容，和字幕文本内容对不上，看着很违和。排查下来，根因通常是抽帧的起始时间和字幕转录的起始时间不一致。

ffmpeg抽帧是相对于视频文件开头的绝对时间，而ffmpeg提取音频后再转录，如果音频处理环节有格外的延迟或重采样，时间戳会和原视频有细微偏差。解决的办法很笨但有效：在拼装素材块时，给图片和字幕都打上统一的基于视频绝对时间的时间戳，并且在拼接时允许前后零点五秒的容差。也就是说，我取时间段“00:01:20 - 00:01:36”的帧图，同时也取字幕里开始时间在“00:01:19 - 00:01:37”区间内的转录文本，用这个带容差的方式关联，对齐问题就很少再出现了。

5.3 遇到视频编码奇怪的素材怎么办

视频处理这个领域，最大的不确定因素来自编码格式五花八门的视频文件。我遇到过MTS格式的摄像机原片、写了错误扩展名的MP4、只有单一声道的异常音轨，每一种都能让脚本崩出不同花样的错误。

应对措施是：在probe阶段加一个“解码能力检查”。用ffmpeg尝试解码视频的前几帧，如果失败，先尝试用ffmpeg把视频重封装为标准H.264格式。重封装是转码中成本最低的一种操作，不改变音视频内容，只是把编码容器换成标准格式。大部分异常编码都在这一步得到解决。如果重封装后依然无法解码，大概率是文件本身损坏，我会直接在输出报告中标记“该视频文件无法解析”，而不是让整个流程卡死。

5.4 常见问题速查表

问题	可能原因	解决办法
Agent不触发Skill	SKILL.md的description描述不够直白	在适用场景里补更多触发说法示例
长视频处理后报告很空	抽帧间隔太大，关键内容漏掉	引入场景检测补帧，细化关键片段
转录文本充满乱码	音频质量差、背景音吵或口音重	换large模型、开启vad过滤、分离人声
网格图里画面模糊	动作幅度大，抽帧时刻没踩中关键帧	在场景切换点前后额外补帧
GPU显存不足	whisper模型过大	改用int8量化small/medium模型
视频有画面没声音	音轨缺失或编码异常	probe阶段检测音轨，跳过转录逻辑
API调用超时	单次请求素材块过多	减少单个网格图数量，使用流式调用

5.5 我的几条独家经验

多做几轮实测之后，有几条经验对我帮助最大。第一，分阶段理解比一次性把所有素材塞给模型要靠谱得多，模型在256张图中的表现，远不如先看全局再细看32个分段的表现。第二，转录质量直接决定输出质量，音频转录的错别字会直接带偏模型对视频内容的理解。如果一段视频转录质量太差，宁可让模型只看画面判断内容，也不要拿脏文本硬凑。第三，抽帧策略一定要做成动态的，固定间隔看起来简单省事，但面对不同节奏的视频，效果波动很大，场景检测补帧这个投资非常值得。

还有一个细节，网格图的顺序不要乱。模型读图的习惯是从左到右、从上到下，所以拼接网格图时，帧的时间顺序必须按照这个方向排列，否则模型会把时间线理解错。我自己就曾经因为把帧顺序排反了，模型输出了一段完全倒叙的事件线，后来看输出才发现问题。

6. 结尾的个人体会

这个Skill从构思到跑通，前前后后折腾了两周多，最大的收获不是代码本身，而是我理解了Agent能力扩展的一种通用范式：对于模型原生不支持的高密度信息输入，与其硬塞，不如拆分。视频如此，长文档、大型代码库、复杂日志分析，本质上都是同一个套路——先拆解，再理解，最后汇总。这种“外挂数据管线”的思路，远比等模型原生支持一切输入更现实、更可控。

最后再分享一个小建议：如果你也想给Agent加类似的视频理解能力，先从自己的实际视频场景出发，拿十个真实视频做测试，比研究一百篇原理文章都有用。把抽帧参数、转录模型、提示词模板调整到适配自己的内容类型之后，这个Skill才能真正帮上忙。下一步我准备给 claude-video 加上音频事件检测，比如识别视频中的警报声、掌声等非语音信息，让Agent的理解维度再丰满一些。有兴趣交流的朋友，欢迎在评论区聊聊你遇到的视频理解场景。