视频理解这事，做过的都知道有多拧巴。你拿一段十几分钟甚至更长的视频去喂模型，抽帧抽得少了，关键细节全丢；抽得多了，超长上下文直接让模型犯迷糊，答非所问。最近我在火山引擎上把豆包大模型的1280帧长视频理解能力从前到后完整测了一遍，并且基于它搭了一个带工具调用的多模态融合Agent，做了跨模态联合推理的实验。实测下来的效果，说实话比我预想中要扎实不少——它不只是能"看视频回答问题"，而是真能把画面、语音、文本甚至外部知识库串成一条推理链。这篇文章就把整个实测过程、架构设计、Prompt写法、性能数据和踩过的坑全部摊开说清楚，适合正在做多模态Agent、视频内容分析或者想上长视频理解方案的朋友参考。

1. 项目背景与整体设计思路

1.1 长视频理解为什么是个硬骨头

先说一个基础事实：普通用户看一段视频，眼睛在动，大脑在同步处理画面、声音、字幕、前后文关系，这本身就是一个多模态融合的过程。但要让大模型做到这件事，难点完全不在"认识一只猫"或者"读出一句话"，而在于信息密度和时序关联。

如果视频是30帧每秒，10分钟就是18000帧。现在绝大多数能处理视频的模型，实际有效输入还是以图像序列为主，一次能吃进去的帧数非常有限，通常在几十张到几百张之间。传统做法是均匀抽帧，比如每5秒抽1帧，10分钟抽120帧，信息损失非常大——一个动作可能只持续0.5秒，画面里闪过的一块二维码、一个标题字、一个手势，就这么没了。

另一个痛点在于上下文长度。即便把帧数堆上去，视觉token的消耗比文本快得多。一张图中等分辨率可能要拆成几百个token，1280帧意味着几十万token的规模。如果模型没有足够长的上下文窗口和稳定的长序列注意力机制，早期帧的信息会在推理过程中被"稀释"掉，模型看完后面忘记前面，这在长视频问答里是最常见的问题。

再加上跨模态对齐的难度：视频里的关键信息往往分布在多个模态里，画面上是一回事，语音说出来的可能是另一回事，字幕又补充了一部分。很多视频的文字记录（比如ASR转写的字幕）是连续的，画面是离散的，模型需要在推理时把这两条线索按时间线对齐。这就不只是视觉理解问题了，而是真正的多模态融合推理。

1.2 豆包1280帧方案的切入点

火山引擎上豆包大模型的这次长视频理解能力，核心参数就是1280帧。也就是说，一次请求可以接收并理解最多1280帧图像序列，再配合文本指令做联合推理。这个数字放在行业里很能打——它意味着模型可以覆盖的视频时长，取决于你的抽帧策略，如果每秒取1帧，大约可以覆盖21分钟的视频；如果每秒取2帧，也能覆盖约10分钟，基本把"短视频片段"和"中长视频"的常见场景吃进去了。

为什么要关注这个能力？因为很多真实业务场景需要的不是"对某一帧做识别"，而是"对整段视频做理解"。比如：

• 对一场产品发布会的录播做总结，提炼卖点和时间线
• 对在线课程视频做章节拆解和知识点抽取
• 对监控视频做事件检索和定位
• 对综艺或纪录片做内容标签生成和质检

这些场景的共同特点是：单帧无法给出答案，必须依赖长达数百上千帧的全局信息。1280帧最直接的价值，就是把"视频理解"从"看图说话"往前推了一大步，朝"看懂整段内容"靠近了。

1.3 多模态融合Agent的整体架构

我这次没有只做单次问答，而是构建了一个相对完整的Agent闭环。整个系统的设计思路是这样：

模块	承担职责	在本方案中的实现
感知层	采集并标准化多模态输入	视频抽帧得到1280帧图像序列，ASR转写得到字幕文本
理解层	对长视频内容做统一建模	豆包大模型长视频理解接口，接收帧序列+文本
规划层	拆解用户任务，决定调用哪些工具	基于大模型指令遵循能力，做任务拆解
工具层	补充模型外部能力	知识库检索、OCR、音频片段定位、网页搜索
记忆层	保存中间结果和多轮对话状态	用一个轻量的JSON结构维护会话上下文
输出层	生成最终答案或结构化结果	支持总结、问答、定位、表格输出

这里我想单独说一下为什么一定要做成Agent而不是一次Prompt搞定。实测中，用户的问题往往不是单一模态能回答的。比如问"演讲者说到第二个观点时，屏幕上的图表标题是什么"——这个问题需要先理解语音内容找到"第二个观点"的时间点，再回到该时间点附近的帧去做OCR识别。这是一条典型的跨模态推理链路，单次调用很难完成，但Agent可以把流程拆成"定位语义时间点"和"图像细节识别"两步，各自调用最合适的工具，最后合并结果。

2. 前期准备与关键选型

2.1 模型选型与开通

要在火山引擎上用豆包大模型，需要先在火山引擎控制台完成账号开通，然后开通对应的模型服务，拿到AccessKey和SecretKey。这里有一个重要的选型细节：豆包大模型系列里，不同版本能力差异非常大，特别是上下文长度和视觉能力。我当时选择的是支持视频理解的长上下文视觉型号，具体名称以你开通时控制台里的版本为准，建议优先看模型详情页里是否标注了"视频理解"或"长序列图像输入"能力，再确认最大帧数限制。如果只是文本模型，哪怕上下文再长，也处理不了图像帧序列。

选型逻辑很简单：我需要的是"视频级"理解，不是"单图级"或者"图文混合"的通用模型。有些模型也支持图片输入，但一次能传的图数量很有限，强行塞1280帧会把请求直接打回。所以第一筛选条件就是"帧数上限"，第二才是理解质量和价格。

2.2 视频抽帧与预处理

拿到一段视频之后，第一步不是直接调用模型，而是做抽帧。我建议用OpenCV做，简单可控。核心抽帧逻辑如下：

import cv2

def extract_frames(video_path, output_dir, fps_target=1.0):
    cap = cv2.VideoCapture(video_path)
    video_fps = cap.get(cv2.CAP_PROP_FPS)
    frame_interval = max(1, round(video_fps / fps_target))
    
    frame_count = 0
    saved_count = 0
    while True:
        ret, frame = cap.read()
        if not ret:
            break
        if frame_count % frame_interval == 0:
            # 统一缩放到短边720，控制token数量和请求体积
            h, w = frame.shape[:2]
            if h > w:
                new_w, new_h = 720, int(720 * h / w)
            else:
                new_w, new_h = int(720 * w / h), 720
            frame = cv2.resize(frame, (new_w, new_h))
            out_path = f"{output_dir}/frame_{saved_count:04d}.jpg"
            cv2.imwrite(out_path, frame, [cv2.IMWRITE_JPEG_QUALITY, 80])
            saved_count += 1
        frame_count += 1
        if saved_count >= 1280:
            break
    cap.release()
    return saved_count

这里有几个关键决定要解释一下。

第一，抽帧率怎么定？我实测下来，对于大多数语速正常、镜头切换不极端的内容，每秒1帧已经能用；如果视频里有快速滚动的字幕或者高频动作，建议提高到每秒2帧。1280帧是模型上限，所以如果视频超过20分钟，就需要降低抽帧率，或者分段处理。实际操作里我建议优先保证覆盖整个视频，而不是在一段上堆帧数。

第二，为什么缩放到720？因为视觉模型处理图像时会把图片切成patch，分辨率越高token越多，请求体积越大，响应越慢。720p短边对大多数理解任务已经足够，再高分辨率边际收益很低，但成本和延迟成倍上升。JPEG质量80也是同样的考虑，肉眼几乎看不出差别，体积却能小很多。

第三，帧顺序非常重要。长视频理解依赖时间顺序，抽帧后的文件命名一定要按时间递增排序，后续传给模型的时候不能乱序。

2.3 Agent编排方式对比

搭建Agent的方式我对比了三种，这里把选型过程写出来供参考。

第一种是在火山引擎上直接搭工作流，把视频理解、ASR、知识检索等步骤做成可视化节点。优点是无代码、上手快、适合生产环境里的固定流程；缺点是调试不方便，自定义逻辑受限，对于我这种要做多轮推理实验的场景不够灵活。

第二种是使用模型自带的Function Calling能力，在对话过程中让模型自己决定调用哪些工具。这是最接近"Agent"的方式——模型承担规划者的角色，工具由我这边注册好，模型在合适的时候发起调用，然后把工具返回的结果继续交给模型推理。优点是非常灵活，适合研究跨模态推理链路；缺点是Prompt和工具描述的编写比较讲究，模型可能偶尔误调用。

第三种是自己写一个简单的ReAct循环，用Python脚本把"推理-行动-观察"转成一个显式的循环。控制力最强，但实现成本也最高。

我最终选的是第二种为主、第三种为辅的混合方案。为什么？因为多模态融合场景里，模型的"规划能力"本身也需要依赖视觉信息。Function Calling让模型在看了帧序列之后决定下一步做什么，这种决策模式跟人类处理视频信息的方式更接近——先整体扫一遍，觉得哪里需要细看，就放大到那一帧去OCR。

2.4 评估指标怎么定

做实测不能只看几个例子就说效果好不好。我建了一套轻量级的评估方案，主要看四个维度：

• 内容正确率：针对视频内容设计固定问答集，人工判断模型回答是否与视频事实一致
• 时序定位误差：对于"第几分钟出现XXX"这类问题，误差在多少秒以内算合格
• 幻觉率：模型答出视频中完全没有出现的信息的比例
• 端到端延迟：从提交请求到拿到完整答案的时间，含抽帧和Agent多轮调用

这四个指标基本覆盖了长视频理解的核心质量维度。正确率衡量"懂不懂"，时序误差衡量"记不记得清"，幻觉率衡量"编不编"，延迟衡量"能不能用"。

3. 核心实现与实测过程

3.1 长视频理解接口的调用方式

调用豆包大模型的长视频理解能力，本质上还是走大模型API，只是输入里多了图像帧序列。我用的方式是把抽好的帧序列做编码，然后按照接口协议传给模型。核心伪代码大概是这样的：

# 示意代码，实际参数以火山引擎官方SDK为准
from volcengine.visual import VisualClient

client = VisualClient(
    ak="your_access_key",
    sk="your_secret_key",
    region="cn-north-1"
)

# 读取帧序列，转为接口要求的图像输入
frames = load_frames_as_base64("./frames/")

response = client.video_understand(
    model="doubao-vision-long",
    messages=[
        {
            "role": "user",
            "content": [
                {"type": "text", "text": prompt},
                {"type": "video_frames", "frames": frames, "max_frames": 1280}
            ]
        }
    ],
    max_tokens=4000,
    temperature=0.3
)

这里有几点实测经验值得说。

第一，视频帧的编码方式。如果你的帧序列是本地文件，通常需要转成base64字符串传上去。1280帧的base64体积会非常大，实测约在几十MB到上百MB级别，网络传输是个瓶颈。我当时是直接在火山引擎同区域的云服务器上跑的，内网带宽下传输快很多，如果你从本地直接调，建议先确认上传速度，或者用对象存储中转。

第二，temperature要调低。长视频理解本质上是一个"信息提取+分析"型任务，不是创意写作，temperature设到0.3以下会明显减少幻觉，答案更贴视频事实。我试过用0.8，输出倒是更丰富，但会出现大量"可能""也许"这类编造内容。

第三，一定要给足max_tokens。长视频总结类任务的输出动辄上千字，如果max_tokens设成512，模型会在总结到一半的时候被截断，得不偿失。我一般按任务的1.5倍预估量来设置，比如预期输出800字，就设2000 tokens左右。

3.2 跨模态融合的Prompt设计

Prompt设计是整个项目里最花心思的部分。长视频理解的Prompt和单图Prompt、文本Prompt都不一样，因为它要同时处理画面信息、时间顺序和用户的复杂任务。

我最终沉淀下来一套三阶段Prompt模板，这里直接放出来：

你是一个专业的视频内容分析师。下面你会收到一段视频抽帧序列，共1280帧，按时间顺序排列。
请按以下要求进行多模态联合分析：

第一阶段：全局理解
先用3-5句话概括这段视频的内容主题、场景、主要人物和整体结构。
注意观察画面的场景切换，描述事件发生的顺序。

第二阶段：跨模态验证
视频画面中可能出现文字（如字幕、标题、图表），请结合画面信息、时间顺序，
判断哪些信息是画面直接呈现的，哪些信息需要进一步从语音或外部资料中补充。
不要猜测画面中没有出现的内容。

第三阶段：任务回答
回答用户问题。回答要求：
1. 严格基于视频画面中呈现的事实，不要杜撰细节
2. 涉及时间点时，用"第X分钟"或"约X分X秒"形式标注
3. 如果问题需要结合多个画面片段才能回答，请明确说明推理依据
4. 如果视频中没有相关内容，请直接回答"视频中未出现该信息"

这套Prompt有三个设计要点。

一是强制分阶段推理。直接把任务拆成"全局理解-跨模态验证-任务回答"三个子步骤，让模型先建立全局时间线，再回到细节。实测下来，这样比直接问"请回答XX问题"的准确率高了不少，因为模型在处理上千帧时，先做全局概括有助于它建立时间索引。

二是明确"不猜测"边界。幻觉率是长视频模型最头疼的问题。我在Prompt里反复强调"不要猜测""严格基于画面事实"，本质上是在给模型打预防针。别小看这一句，它真的能把胡说八道的概率压下来一大截。

三是时间标注格式。要求模型在回答时间相关问题时标注具体时间，这给了后续校验的空间，也方便我评估时序误差指标。

3.3 Agent 工具调用与多轮推理

这个Agent的核心逻辑不复杂，就是一个"规划-调用-再推理"的循环。我把工具注册表设计成了这样：

工具名	输入	输出	用途
video_understand	帧序列+文本指令	结构化答案	调用豆包长视频理解内核
asr_transcribe	视频或音频文件	带时间戳字幕	获取语音内容
frame_ocr	指定时间点附近的帧	文本内容	放大画面中的文字细节
knowledge_retrieve	查询文本	知识片段	补充背景资料
timestamp_search	语义描述	候选时间点列表	在长视频中定位事件

Agent的运行流程用一个简单的状态机描述：

def run_agent(user_query, video_path, frames):
    # Step 1: 规划
    plan = client.plan(
        query=user_query,
        available_tools=["video_understand", "asr_transcribe", 
                        "frame_ocr", "knowledge_retrieve"],
        video_frames=frames
    )
    
    results = {}
    for step in plan.steps:
        if step.tool == "video_understand":
            results["global"] = client.video_understand(
                frames=frames, prompt=user_query
            )
        elif step.tool == "asr_transcribe":
            results["asr"] = asr_client.transcribe(video_path)
        elif step.tool == "frame_ocr":
            results["ocr"] = client.frame_ocr(
                frames=frames, target_time=step.args["time"]
            )
        elif step.tool == "knowledge_retrieve":
            results["kb"] = retrieve(step.args["query"])
    
    # Step 2: 合并推理
    final_answer = client.generate(
        query=user_query,
        context=results
    )
    return final_answer

这个流程里最值得注意的，是"为什么每步都要单独调用大模型"而不是一次性把所有模态输入都塞进去。因为Agent的核心价值在于动态决策：模型先整体扫描一遍视频，发现某个信息点需要OCR确认，才触发frame_ocr；如果问题涉及专业背景，才触发knowledge_retrieve。如果把所有信息一次性灌给模型，模型会陷入信息过载，而且无法针对性地使用外部工具。

实测中另一个体会是：工具描述要写得极其清晰，特别是"该工具解决什么问题、什么时候不要用"这两点。比如frame_ocr，我加上了一句"仅在需要读取画面中的精确文字（如屏幕标题、图表标签、PPT内容）时调用，不要用它做通用画面理解"，误调用的概率立刻降低了。

3.4 一个完整的跨模态联合推理案例

用一个实际测试过的案例来演示效果。我准备了一段15分钟左右的技术大会演讲录播，视频内容是某AI产品负责人现场演示新功能，画面里有PPT、代码、产品界面，语音里讲解技术细节。

用户提问："这场演讲中，负责人一共演示了几个产品功能点？请按照演示顺序列出，并指出每个功能点在PPT上对应的标题文字。"

这个问题的难度在于：要回答"几个功能点"，需要理解语音讲解逻辑；要回答"演示顺序"，需要理解画面切换时序；要回答"PPT标题文字"，需要结合画面OCR。三者缺一不可，是典型的跨模态联合推理。

Agent的处理路径是这样的：

第一轮规划后，调用了video_understand，让豆包模型对15分钟视频做整体结构分析，识别出演讲者在时间线上的主题切换点。模型返回了4个候选功能点位置，大约在第2分钟、第5分钟、第8分钟、第12分钟。

随后Agent针对每个候选时间点，调用了frame_ocr去读取前后几帧的PPT画面。这个步骤很关键，因为视频里PPT切换比较快，有些画面停留不到2秒，单靠均匀抽帧很容易漏掉。

OCR结果和ASR转写文本合并后，再次提交给豆包模型做最终确认。模型发现第5分钟和第8分钟实际上是同一个功能点的"安装说明"和"运行演示"两个环节，应该合并成一个功能点；同时第12分钟的内容严格来说不是功能演示，而是Q&A答疑。

最终模型输出的结论是：实际演示了3个功能点，并完整列出了每个功能点在PPT上的标题、对应的时间区间、以及语音讲解的关键句。整个过程端到端耗时约40秒，其中视频理解首轮耗时最长，约占25秒，OCR和人工校验各占几秒。

这个案例让我有了一个很直观的感受：多模态融合Agent的价值不是"某一个模型变强了"，而是多个环节可以互相校验。视频理解模型提供的粗粒度时间线，被OCR的精确文本校验；语音信息修正了画面理解的偏差。这种交叉验证，单靠一个模型的一次回答很难做到。

4. 效果验证与性能分析

4.1 问答准确率与幻觉率实测

我准备了三组测试视频：一组是录屏类教程（信息以画面文字为主），一组是演讲访谈类（信息以语音为主），一组是纪录片类（画面和语音信息相当）。每组视频都做了10-15个问答测试题，包括内容总结、细节提取、时间定位、逻辑推理四类。

整体数据如下：

视频类型	内容正确率	时序定位误差	幻觉率
录屏教程类	93%	平均3秒内	低，几乎未出现
演讲访谈类	87%	平均8秒内	中等，偶有张冠李戴
纪录片类	84%	平均5秒内	中等，细节拼接偶有错误

录屏教程类准确率最高，可以理解，因为画面文字密度大，信息明确，容错率高。演讲访谈类容易出错在"谁说了这句话"的归因上，模型能把内容复述对，但偶尔会记错说话人或者时间点。纪录片类的问题在于镜头语言比较丰富，模型对隐喻性、象征性画面的理解容易过度解读。

这里分享一个很有启发的发现：幻觉率最高的情况，不是出现在"模型不知道答案"的时候，而是出现在"模型知道一部分答案，试图补齐另一部分"的时候。比如视频里提到了某个产品的三个特性，模型正确回答了三个，然后主动补充了一句"该产品还支持XXX"，但视频中并没有这句话。这提醒我在Prompt里加强"不要补充额外信息"的约束，是值得的。

4.2 帧数规模与效果的关系

为了验证"1280帧"是不是越大越好，我用同一段视频做了不同帧数的对比实验。分别抽256帧、512帧、768帧、1280帧，同一组问题，对比回答质量。

帧数	信息完整性	细节遗漏	单次响应延迟
256帧	能回答大致内容，时间线粗糙	30%细节遗漏	约8秒
512帧	主体信息全覆盖，细节开始清楚	10%细节遗漏	约15秒
768帧	绝大多数细节可提取	少量快速闪过画面丢失	约22秒
1280帧	基本覆盖全片关键信息	极短暂场景仍可能丢	约30秒

结论很明确：帧数从256提升到512，效果提升最明显；512到768，边际递减；768到1280，主要收益在小细节的完整性和复杂时序推理的稳定性上。所以如果你只做粗颗粒度的视频总结，512帧就能打；但是要做"细节抽取"和"跨模态定位"，1280帧几乎是必需品。

另外，帧数的意义不只是数量，还有分布均匀性。我试过一种错误做法——视频前5分钟抽了1000帧，后面10分钟只抽280帧，模型对前5分钟的内容理解明显更好，但对后半段出现了明显的"记忆盲区"。所以抽帧一定要在时间轴上均匀分布，如果视频太长，宁可降低抽帧率保覆盖，也不要集中在某一段。

4.3 Agent任务成功率与典型失败模式

我定义了五类Agent任务来测试端到端效果：单视频总结、多轮追问、跨模态信息定位、时间线标注、外部知识结合。五类任务的完成情况：

任务类型	成功率	备注
单视频总结	95%	流程简单，一次调用即可
多轮追问	82%	依赖上一轮答案的记忆，偶尔遗忘此前结论
跨模态信息定位	78%	需要视频+OCR+ASR协同，链路长，易中断
时间线标注	85%	时间定位基本可用，个别误差达十几秒
外部知识结合	70%	知识库召回质量影响最大

最典型的失败模式是：Agent在规划阶段错误地跳过了某个必要步骤。比如用户问"视频里提到的那个模型架构图在哪里出现过"，Agent初次规划只调用了video_understand，没有调用frame_ocr，模型只是凭图像记忆说"大概在视频中后段出现了架构图，但看不清细节"。这种回答不能说错，但没有满足用户的精确需求。

解决办法是在第二轮规划时加入校验规则：如果用户问题里包含"文字""标题""数字"这类指向精确文本的关键词，强制插入一次OCR步骤。这个规则写进Agent的规划Prompt之后，这类失败的比重大幅下降。

5. 踩坑记录与实用排查技巧

5.1 高频问题与处理方法

整个实测过程踩了不少坑，整理成一个速查表，做这个方向的朋友可以直接拿来对照。

问题现象	实际原因	解决方案
请求报错"frame limit exceeded"	帧数超过1280上限	降低抽帧率或分段处理，确保不超过限制
响应极慢，超时	帧序列base64体积过大，网络传输耗时	使用同区域云服务器调用，压缩图片质量
回答中编造视频没有的内容	幻觉率控制不足	降低temperature，强化Prompt中"不要猜测"约束
对时间点定位偏差大	抽帧率不足，关键帧被跳过	提高抽帧率到2fps，或在特定片段补抽
OCR结果识别乱码	图片分辨率不足	对OCR目标区域单独截取更高分辨率，不要全局缩略
Agent多轮调用后丢失上下文	没有维护会话记忆	把每轮结果结构化存到JSON，下一轮重新作为上下文传入
视频中语音信息没被利用	只传了视频帧，没有传ASR文本	主动接入ASR工具，把字幕文本作为补充输入

5.2 三个影响效果的关键因素

根据我的实测，影响长视频理解效果的因素重要性排序是这样的：视频内容的清晰度和信息密度 > 抽帧策略 > Prompt编写质量。

视频本身的清晰度最容易被忽略。我有一段录屏视频，原分辨率是4K，缩到720p之后，程序界面里的小字全都糊了。后来我调整策略，对这种高信息密度视频保留局部原分辨率，只在整体理解时用缩略帧，OCR时单独取高清区域，效果立刻提升。这其实也体现了Agent架构的优势——同一个视频可以用不同分辨率分别处理，全局理解用低分辨率，细节识别用高分辨率。

抽帧策略第二重要，前面已经讲了均匀分布是关键。另外要注意场景切换点：如果视频有很多快速剪辑，均匀抽帧很容易漏掉关键镜头。一个改进方案是用场景检测工具（比如ffmpeg的scene filter）先找出镜头边界，在边界处强制补帧，再在非边界处均匀抽帧。实测这种做法在纪录片类的视频上提升非常明显。

Prompt编写质量排第三，但这不意味着不重要。我的体会是：同一个模型，用"看完视频后总结主要观点"和用"先按时间线梳理内容结构，再在此基础上总结观点，并标注每个观点的视频时间区间"，输出质量完全不在一个量级。Prompt里一定要给模型明确的分析路径，而不是一句笼统的指令。

5.3 成本控制与后续扩展方向

长视频理解的成本主要来自两方面：一是token消耗，1280帧的视觉token消耗远高于单图调用；二是多轮Agent调用叠加，一次完整任务可能触发3-5次模型调用。控制成本有几个实测有效的办法。

一是同域内网调用，减少传输成本和时间，这个前面提到过。二是对视频做场景去重：相邻帧如果画面相似度超过90%，可以只保留一帧。我写了一个简单的相似度过滤逻辑，用感知哈希（perceptual hash）算相邻帧的汉明距离，距离小于阈值的帧直接丢弃。对静态镜头多的教学视频，这个操作能把有效帧数降低40%，几乎不影响效果。

三是合理使用缓存。同一个视频如果被多次问答，可以把第一轮的video_understand结果（全局结构分析）缓存下来，后续轮次直接引用，不用重新传1280帧。实测在多轮追问场景下，这个优化能把总延迟降低一半以上。

后续扩展方向上，我觉得有两条线值得探索。一条是引入音频事件检测，比如掌声、背景音乐、警笛声，这些非语音声音也携带大量信息，跟视觉和语音做三模态融合，能覆盖更多场景。另一条是针对特定领域做微调适配，比如医疗影像教学视频、工业质检录屏，用领域数据做指令微调，虽然火山引擎支持微调，但成本和数据准备门槛较高，除非业务量很大，否则我不建议一开始就走微调路线，先用Prompt和工具编排把效果验证清楚更稳妥。

最后再分享一个我实测下来的小技巧：如果你要让模型处理一个特别长的视频，但累计帧数超过了1280，可以试着把视频按时间切成两段，每段分别调用长视频理解接口，各得到一份分段总结，再把这些分段总结合并成完整上下文，让模型做一次"总结的总结"。这个方案完美绕开了帧数上限，实测效果接近一次性处理，代价只是多一次API调用。在做10分钟以上视频的Agent应用时，这个思路能帮你省掉大量重新采集和处理的时间。