那天晚上我对着一段45分钟的项目复盘录像，想找出所有提到数据库迁移的片段。按固定帧率处理，默认每秒取一帧，整段录像会先被拆成2700个画面，再把这些画面送进模型。问题不只在账单，画面变化很小的白板讨论也可能刚好落在两帧之间，模型看见了会议，却没看见真正有用的那几秒。
2026年9月1日，Google DeepMind 发布了 Gemini 的 Agentic Video Understanding。它把视频处理从固定抽帧改成带工具的主动检索，Gemini 会根据问题决定要看哪些时间段、用多高的帧率，以及要不要读取音频和转写。官方公开口径是，token 消耗最多减少88%，分析成本最多减少66%，细粒度视觉推理准确率最多提高7%。
这篇文章只讲工程上真正有用的部分：固定处理和主动处理差在哪里，模型怎样先定位再放大，官方代码怎样跑通，以及接入生产系统时如何保留成本和延迟的控制。读完之后，你不必把所有长视频都交给新模式，也能判断一段素材是否适合让模型自己做取舍。
这次更新，先改变了视频怎么被看
以前的长视频理解更像一台按刻度工作的扫描仪。接口给出一个固定帧率，系统沿着时间线均匀取图，模型再从这一堆画面里回答问题。Gemini 的静态模式默认每秒一帧，开发者可以调高或调低，但这个参数只改变密度，不会改变取样策略。
把帧率调高，细节更完整，输入画面和费用也一起增长。90分钟的讲座按每秒5帧处理，就是27000个取样位置，里面有大量重复的讲台、字幕和听众画面。把帧率调低，费用容易控制，却会给快速动作和短暂状态留下盲区。固定规则很容易解释，却不懂问题到底在问哪一秒。
Agentic 模式先把视频作为一个轻量引用交给服务端，初始上下文只需要视频时长、容器格式和文件标识等元数据。模型不会一上来把整条时间线全部解码，而是先根据问题规划检索顺序，再调用服务端的视频工具拿回需要的片段。这个变化发生在处理循环里，不需要开发者自己搭一套播放器或切帧服务。
被取回的画面、音频和转写才会成为后续观察结果，视频中没有被检索到的部分不会提前全部进入上下文。官方说明，主动视频理解使用标准的 Gemini API token 计费，没有额外的功能使用费，但思考与输出仍按模型的正常费率计算。于是省下来的输入 token 不等于整次请求零成本，账单要看完整的执行过程。
主动取样的工作循环：搜索、抽帧与转写如何配合
这套机制的骨架是 Think、Act、Observe 循环。Think 是根据问题判断需要什么证据，Act 是向内部视频工具请求某个时间窗或某种模态，Observe 是读取返回结果并决定是否继续查。它和一次性上传、一次性回答的差别，在于每一轮结果都会影响下一轮取样。
模型通常会先从转写开始，因为带时间戳的语音文字适合做导航。问题如果是找某次预算讨论，转写能先给出几个候选时间点，模型再决定是否读取相邻画面。这样做不是把转写当成答案，而是先用便宜的线索缩小搜索范围，把视觉 token 留给真正需要核对的地方。
遇到画面细节时，模型会做时间上的放大。开发者指南给出的思路是，先取一个较宽的区间了解上下文，再把例如第14秒到第16秒的窗口用5到10帧每秒重新查看。如果只需要扫一遍长片段，也可以用0.1帧每秒的低密度方式寻找线索，找到可疑位置后再提高密度。
音频承担的任务也不只是把人声变成文字。说话人的语气、突然出现的提示音、机器的异常声，都可能成为定位依据。模型可以在画面和转写之外读取目标时间段的音轨，再把这个观察结果和视觉证据放在一起判断。对会议、课程、直播和质检录像来说，三种信号往往互相补位。
每一轮检索都不保证一次命中。模型可能先看到终端窗口，再把时间范围向前后扩展，确认这段报错究竟是操作结果还是偶然弹窗；也可能先找到一句话，再回看说话人手边的白板。服务端负责内部工具循环，开发者只需要提出问题和选择处理模式，应用层拿到的是合成后的回答。
百分之八十八少 token，账是怎么算出来的
88%是官方跨标准视频分析基准公布的最高降幅，不是每个视频、每个问题都能固定得到的折扣。这个口径应当和自己的业务数据分开看。Google 重点强调的是长视频，因为长视频的静态处理最容易陷入高帧率太贵、低帧率漏细节的两难。
官方把收益拆成3个维度：token 消耗最多减少88%，分析成本最多减少66%，细粒度视觉推理准确率最多提高7%。三者的分母并不相同，不能把88%直接当成账单下降88%，也不能把7%理解成所有任务的准确率都会增加七个百分点。
输入视频的计费方式也变了一个观察角度。主动模式初始只传视频引用，后面只为执行过程中真正物化的画面片段和音频片段付输入 token；模型的思考步骤、工具调用和文本输出仍按标准费率计入。一次请求调用越多、推理越深，省下的视觉输入就越可能被其他 token 部分抵消。
| 官方公开指标 | 含义 | 解读边界 |
|---|---|---|
| 最多减少88% | 视频分析请求的 token 消耗 | 属于最高值，需按业务集复测 |
| 最多减少66% | 长视频分析成本 | 不是输入 token 的简单等比例换算 |
| 最多提高7% | 细粒度视觉推理准确率 | 依赖任务是否包含稀疏视觉信号 |
准确率提升的来源比较朴素：模型不再被迫用一个固定采样密度覆盖所有时间，而是能在关键位置重看。快速挥手、短暂卡顿、剪辑切点这类信号，原本可能被1秒一次的采样跳过，现在可以在定位后用更高帧率复核。若视频内容均匀、问题只涉及口述，提升空间自然没有那么大。
因此，基准数字适合用来决定是否值得做试验，不适合直接写进预算承诺。上线前应拿同一批视频和同一组问题分别跑静态、主动两种模式，记录输入 token、思考与输出 token、总成本、首 token 延迟、总耗时和人工核验准确率。只有这组数据稳定，路由规则才有依据。
成本估算不能只按视频时长乘一个单价。相同的1小时录像，问一句概览和追问10个精确时间点，模型需要检索的窗口可能完全不同；同一个问题，转写清楚的课程和没有字幕的监控也会走不同的观察路径。把问题类型、可用模态和检索轮次一起记录，才能知道成本变化来自素材、用户提问，还是模型的取样决策。
从分钟级定位到亚秒级检索，开发者拿到什么
最容易感知的能力是亚秒级时刻检索。固定每秒一帧时，200毫秒的状态变化可能完全没有对应画面；主动模式可以先用转写或音频找到大致位置，再把很窄的时间窗拉出来，以更高帧率重新检查。视频剪辑、体育回放、生产线质检和监控检索都可能从中受益。
动态帧率也让计数任务更有操作空间。模型在普通片段里不必维持很高密度，遇到快速动作时再提高取样频率，完成一次观察后还可以回看相邻范围检查是否重复计数。这个过程不是让模型凭感觉报一个数字，而是把采样资源集中到计数真正容易出错的区间。
长视频的另一类问题是大海捞针。用户可能只问某位讲者在几小时录像里提过哪项决定，或某个课程在哪一段演示了一个操作。主动模式先用时间戳转写建立候选位置，再用画面验证，适合把企业培训、会议归档和公开讲座变成可检索的内容库。
异常检测则依赖信号的稀疏性。机器大多数时间都在正常运行，真正值得看的可能只有一小段异响和一个动作；模型可以先找文字和音频线索，再把视觉预算放在可疑窗口。应用仍需明确异常定义、保留原始片段，并让人复核告警，不能把主动取样当成无监督的安全结论。
这项能力目前覆盖 Gemini 3.7 Flash、3.6 Flash 和3.5 Flash-Lite，可通过 Gemini API 在 Google AI Studio 和 Gemini Enterprise Agent Platform 使用。输入来源包括上传的视频和公开 YouTube 视频。不同模型的质量、延迟和价格仍要以当前文档为准，不能因为都叫 Flash 就假定它们的表现完全相同。
官方开发者指南给出的选择建议很实用：超过大约5分钟的讲座、网络研讨会、比赛和会议，可以优先试主动模式；少于5分钟、而且对延迟和全片逐帧精度更敏感的短片，静态模式可能更合适。这个时间不是平台硬阈值，而是路由策略的起点，业务数据应当拥有最终决定权。
用 Python 跑通一次主动视频分析
代码层面不需要自己实现搜索、抽帧和音频切片。当前官方示例使用 Google 的新版 Python SDK，客户端从环境变量读取 API 密钥；视频上传完成并处理到可用状态后，把处理字段放在视频输入对象里。下面这段代码保留了上传、等待和请求3个步骤，可以直接作为最小测试。
运行前安装 google-genai，并在本机配置 GEMINI_API_KEY。文件路径换成自己的视频，问题换成业务查询。示例使用 Gemini 3.7 Flash，是官方开发者指南列出的支持模型之一；如果账号当前可用的模型不同，应先查看模型文档，不要只改字符串后猜测结果。
python
import time
from google import genai
client = genai.Client()
video_file = client.files.upload(file="path/to/lecture.mp4")
while video_file.state.name == "PROCESSING":
time.sleep(2)
video_file = client.files.get(name=video_file.name)
interaction = client.interactions.create(
model="gemini-3.7-flash",
input=[
{
"type": "video",
"uri": video_file.uri,
"mime_type": video_file.mime_type,
"processing": "agentic"
},
{
"type": "text",
"text": "What are the three main arguments presented?"
}
]
)
print(interaction.output_text)
print(interaction.usage.total_tokens)关键不在某个隐藏开关，而在视频输入对象里的 processing 字段。它明确告诉接口用 agentic 方式处理这份媒体，文本输入仍然负责描述任务。返回对象同时提供 output_text 和 usage，测试时应把回答与 token 用量一起保存，后续才能拿它和静态请求做同口径比较。
如果素材来自公开 YouTube，可以把上传得到的 uri 换成公开视频地址，并保留 processing 为 agentic。官方示例使用的是公开视频链接；真实项目仍要考虑访问权限、视频是否可被服务端读取、内容授权和链接失效。不要把一个只能在浏览器里播放的私有链接直接当成公共输入。
主动和静态也能放在同一个请求里。比如把一段长的完整录像设为 agentic，把一段10秒的查询片段设为 static，再让模型在两者之间找对应时间点。每个视频输入独立声明处理方式，适合做长参考视频与短目标片段的匹配实验。
接进生产系统后，别把省下的 token 花回去
测试跑通以后，最常见的误区是立刻把省下来的 token 换成更大的上下文和更多轮验证。如果原来的查询已经够用，先维持同样的输入范围和输出格式，测清成本下降、延迟变化和漏检情况。主动模式的价值是把资源花在有证据的地方，不是给每次请求找理由继续加料。
延迟是另一笔账。模型需要先规划，再等待工具返回，随后才会决定是否继续取样，所以短视频上这段等待可能超过节省的价值。产品可以把视频时长、问题类型和实时性要求放进路由，短片走静态，长片或需要精确定位的请求走主动，而不是把一个开关全量打开。
模型自己决定查几次，也意味着成本不再像固定帧率那样容易用一个公式算完。应用层应记录每次请求的素材时长、处理模式、总 token、总耗时和错误类型，并为单次请求、单个用户和每日总量设预算。预算是系统外层的护栏，不能指望模型自己理解公司的财务上限。
遇到没有语音、没有字幕、画面文字又很少的长视频，主动模式的导航优势会变弱。安静的航拍、无人车间和部分行车记录仪，可能无法先用转写缩小范围。路由器应把音频存在性、转写长度、视频时长和问题是否依赖视觉动作一起纳入判断，必要时回到低帧率静态扫描。
结果验收也要跟着改变。除了回答是否正确，还要抽查模型给出的时间点，确认关键片段确实包含在原视频里；对于计数、异常和安全类任务，应保存被检索的原始窗口，方便复核。主动模式减少的是无关内容的读取，不会自动消除幻觉、权限和内容安全问题。
长会话重复使用同一视频时，可以利用标准的上下文缓存能力；批量任务则可以评估 Gemini Batch API，因为官方开发者指南说明主动视频处理可按标准成本的50%使用批处理。缓存和批处理都属于计费与调度策略，落地前要结合保留时间、数据敏感度和结果时效做测试。
一套稳妥的上线指标至少要分开看5项：输入视频 token、思考与输出 token、总成本、首 token 延迟和人工核验准确率。再加上漏掉关键片段的比例，才能知道系统是真的少读了，还是只是更快地给出了不完整答案。所有指标都按同一批样本对照静态基线，避免只挑成功案例。
测试集不能只放容易搜索的会议。应当混入没有字幕的监控、说话和画面信息不一致的课程、快速动作密集的操作录像，以及答案落在片尾的长素材。每类样本都记录目标时间窗和允许误差，再由人工确认模型有没有找到证据。这样测出来的不是一条漂亮的平均数，而是路由规则在哪些边界会失效。
应用还应保存一次请求的模式、视频时长、问题类型和模型版本。Google 可能更新模型和价格，业务数据也会随素材结构变化；没有这些字段，过几周再看成本上涨时，很难判断是视频变长、模型调用变多，还是路由误把短片送进了主动循环。日志要记录摘要，不要把敏感视频内容无期限留在普通日志里。
主动模式的回答最好带上可核验的时间点，而不是只返回一段自然语言。播放器可以根据时间点打开前后几秒的原片，审核者也能快速判断模型的证据是否充分。对自动剪辑和质检系统，这个时间点就是后续工作流的输入；时间点漂移、片段打不开或引用超出视频范围，都应当进入错误队列。
当主动循环超出预算或服务端暂时失败时，回退策略要保持任务语义不变。可以缩短查询范围、降低静态帧率，或把任务排入批处理，但不能悄悄换成另一个问题再报告成功。生产系统把每次回退原因写入指标，经过一段时间就能看出哪些素材值得预处理转写，哪些素材应当一直走静态路径。
这不是更快的播放器，而是会做取舍的分析器
回到那段项目复盘录像，主动模式真正改变的不是播放速度，而是搜索顺序。模型先从转写和时间戳里找线索，再把画面、音频和帧率用在需要核对的地方。对开发者来说，这等于把手工切片、重复抽帧和多次试错的一部分工作交给了服务端工具循环。
它也不是所有视频的通用加速器。长视频若主要靠无声画面表达，问题又要求逐帧确认，模型仍然需要花资源扫描；短视频若强调立即响应，主动循环的等待甚至可能让体验变差。模式选择不能只看一条最高降幅，而要看素材的信号分布和用户真正关心的证据。
我的判断是：Agentic Video Understanding 值得优先用于长视频检索、快速动作分析和带语音线索的异常定位。生产系统必须保留静态处理回退、应用侧成本上限、时间点抽样复核和按业务集维护的基线。把它当成一个会主动安排观察顺序的分析器，而不是一个更快的播放器，才不会把宣传数字误当成上线承诺。实际落地时，我会先挑一批已经有人工答案的视频做灰度，让主动模式只负责给出候选时间点和证据片段，再由原有流程核对。等漏检率、耗时和成本都稳定下来，再扩大到更多用户；这比先追求一条最高节省比例安全得多，也更容易定位回退应该发生在哪一层。灰度还应覆盖模型升级和服务波动，观察同一个问题在不同版本中的时间点是否漂移，并为无法复核的回答保留人工接管入口。工程上还要把模式选择做成可解释的策略：为什么这条请求走主动，为什么那条请求回到静态，为什么某个时间点需要人工复核。把这些判断写进路由日志，开发者才能在成本、延迟或准确率发生变化时快速定位原因，而不是只看到一个孤立的总 token 数。对同一类素材连续观察一段时间后，还能把这些记录反过来校准路由阈值，让策略跟着真实数据变化，而不是永远停在发布当天的经验判断。