一段两小时的会议录像，真正和你有关的内容可能只有第 47 分钟到第 51 分钟。传统做法却很老实，把视频从头喂到尾，再从一大堆 Token 里找答案。

这很像让一个新同事为了回答「昨天谁确认了上线时间」，先把整场会逐字重听一遍。

Qwen 在 9 月 18 日发布 Qwen3.8-Omni-Flash 时，给出了一组很有意思的数据。在 OmniVideoBench 上，Agentic Understanding 把每次查询的 Token 从 145736 降到 79117，同时准确率从 63.4 提到 67.8。省了约 45.7% 的 Token，结果反而更好。

我看到这个数字时，第一反应不是「又一个多模态榜单」，而是一个工程问题终于被摆到了台面上。

多模态 Agent 走不远，往往不是模型看不懂视频，而是系统不知道该看哪一段、何时停、怎样把发现交给下一个工具，以及任务失败后怎样继续。模型只是其中一颗发动机。真正决定它能不能进生产的，是外面那套运行时。

从「把媒体塞进去」到「带着问题找证据」

很多多模态 Demo 的逻辑很直接。上传一段视频，问问题，模型回答。短视频里这已经够用，体验也挺惊艳。

但长度一上来，账就不对了。

音频和视频不是普通文本。视频每多一分钟，就多出帧采样、音轨、说话人、场景切换和时序关系。一个会议记录 Agent 如果每次追问都完整处理原视频，费用会涨，延迟会涨，答案还会被无关内容稀释。你让它总结会议、找一个承诺、再核对某个动作项，实际上是在为同一批素材反复付费。

Qwen 这次强调的 Agentic Understanding，核心不是「模型一次装下更多东西」。它会从问题出发，先粗找候选片段，再对可能相关的片段做更细的观看和推理。官方称这是一种多轮、由粗到细的 evidence gathering。

这个路径听着没那么神奇，却比「一百万 Token 上下文」更接近真实系统。

你如果做过 RAG，大概很容易理解。没人会把整个知识库直接塞进 Prompt，而是先检索、重排、补上下文，再生成回答。长视频也该这样处理。媒体本身是原始语料，时间戳、转写、镜头切分、说话人和关键帧是索引，Agent 的问题才是检索条件。

这里有一个容易被忽略的变化。检索不再只是服务端预先跑好的固定步骤。Agent 可以根据第一轮发现决定下一轮要看什么，比如先定位提到「发布窗口」的片段，再核对是谁说的、承诺是否带条件、画面里的白板有没有补充。

这才是多模态 Agent 有价值的地方。它不是一个会看视频的聊天框，而是一条有目的地采样、验证、交付的工作流。

上下文窗口很大，成本却不会自动变小

Qwen3.8-Omni-Flash 支持 1M Token 上下文，官方披露其在 29 项评测上的平均分比 Qwen3.5-Omni-Plus 提升超过 25%，音频输入按小时计价下降超过 98%，音视频输入下降超过 93%。对需要处理录音、会议和视频素材的团队，这当然是好消息。

不过，低单价常常让人忽略另一个乘法。

一次处理便宜，不等于反复完整处理也便宜。一个客服质检系统如果每天有 1000 小时录音，每段录音又被「总结」「抽查」「找风险表达」「生成培训素材」四个任务各处理一次，瓶颈很快会从模型价格转移到媒体转码、对象存储、队列积压和结果缓存。

很多朋友可能不知道，线上系统最难受的部分常常不是模型调用报错，而是它慢慢把下游拖住。转写服务没跟上，视频帧抽取占满 CPU，任务状态丢在 Redis 里过期，用户刷新页面后又提交了一次同样的长任务。模型能力越强，能被塞进来的需求越多，这些旧问题只会更明显。

我一直觉得，长上下文要当成保险，不要当成默认路径。

保险的意思是，当索引失效、问题确实需要全局语境、或者证据彼此距离很远时，系统有能力把更多媒体带进来。默认路径仍应当是先少看一点，确认不够再扩大范围。这样做不只是省 Token，也让你能解释答案从哪里来的。

对于需要审计的场景，后一件事更重要。Agent 给出「某人已同意变更」时，交付物不该只有一句总结，还应有原视频时间段、转写片段、所用工具版本和决策轨迹。否则它看起来很聪明，出了争议却没有人能复盘。

模型、Harness、工作流，缺一个都会别扭

Qwen 这次不只发了模型，还提到 Qwen-MM-Plugins 和 Qwen-Live Harness。前者用于按需感知、工具调用和工作流执行，后者面向持续的实时多模态交互，处理任务委托、记忆和上下文管理。

这两个配套比发布一个新模型更能说明方向。

过去不少多模态应用的架构是「模型 API 加几个 Prompt」。演示阶段没问题。可一旦要做持续会议助手、实时翻译、视频审片或现场巡检，就会碰到一串不性感但躲不过去的问题。

  • 一段直播音频持续进来，什么时候形成稳定片段，什么时候允许模型先回答
  • 用户中途改了目标，已经跑到一半的转写和检索任务怎么取消或复用
  • 模型要调用剪辑、字幕、日历或工单工具，哪一步有写权限
  • 某个工具超时，任务应当重试、降级，还是把半成品交给人
  • 多轮对话里，哪些媒体事实该保留，哪些临时推断必须丢掉

这些问题没有一个能靠把 Prompt 写得更长解决。

拿 Java 和 Spring 的服务打个比方。Controller 能收到请求，不代表订单就完成了。还得有事务边界、幂等键、消息队列、补偿任务、审计日志和监控告警。多模态 Agent 里的模型调用，也只是一次请求处理。Harness 才是负责状态、调度、工具契约、重试和人工接管的那层东西。

这话听着有点刺耳，但不少团队现在做 Agent，还是把「能调用模型」误当成「已经有系统」。前者一两个下午就能搭出来，后者要面对脏数据、重复事件、超时和权限。恰恰是后者决定用户会不会继续用。

实时不是把流式输出打开就完事

Qwen 还把实时交互单独拎出来，并开源了 Qwen-Live Harness。这个动作很对，因为实时语音或视频 Agent 和批处理任务，根本不是同一种系统。

批处理可以等。你上传一小时课程，十分钟后拿到结构化笔记，大多数人能接受。实时会议助手却不行。它晚半分钟提醒风险点，会议可能已经翻页了。它把同一句话改写三次，用户也会迅速失去信任。

实时场景里，延迟预算要被拆开算。音频采集、静音切分、ASR、说话人分离、模型推理、工具执行、TTS 回放，每一段都在吃时间。一个环节偶尔抖一下还好，几段串起来就会变成明显卡顿。

所以，实时 Agent 不能只追求最完整的答案，还要学会分层交付。先给一个可撤回的短反馈，后台再补证据和完整结论。比如会议中先提示「检测到可能的待确认上线时间」，待说话人和上下文核对完成后，再写入正式纪要。

不是所有内容都适合边听边定论。

这也是我对「全双工、自然对话」保持一点保留的原因。实时感很迷人，但越接近人类交谈，越容易让用户高估它理解了多少。对涉及审批、承诺、医疗、合规和安全的内容，系统应该明确标注哪些是实时草稿，哪些已经经过证据核验。把不确定性藏起来，短期会显得顺滑，长期一定会出事。

一个可落地的多模态 Agent 最小闭环

如果你正在做会议助手、质检、视频知识库或现场作业支持，我不建议一上来就追求万能的「视频 Agent」。先挑一个可验证的闭环。反正我觉得，能把一个窄任务做得可追溯，比让模型展示十种能力靠谱得多。

一个最小架构可以从五层开始。

1. 媒体层只负责保存和切分

原始音视频进对象存储，生成稳定的内容标识和版本号。异步任务做转写、镜头或语义切分、关键帧抽取和说话人识别。这里要保留时间戳和来源映射，别只留下纯文本。

很多系统后面补不回证据链，就是在第一步把原始位置丢掉了。

2. 索引层把「能找」和「能证明」放在一起

向量索引可以帮助召回语义相近的片段，但它不够。还需要关键词、时间范围、说话人、文件版本、场景标签等可过滤字段。一个问题被回答后，应记录引用了哪些片段，而不是只缓存最终自然语言。

你想想看，用户质疑答案时，系统如果只能再说一遍，很像一个不记笔记的同事。能回到 00:47:12 的原话，可信度完全不同。

3. Agent 层负责计划，不直接拥有一切权限

Agent 收到问题后，先决定查什么，调用检索或感知工具，必要时扩大范围。它应当有明确的预算，例如最多查看多少片段、最多运行几轮、单次任务最长多久。预算耗尽时，输出当前证据和未确认部分，不要硬编一个完整结论。

这个事儿我也踩过坑。给 Agent 一个没有边界的「继续找」指令，它不是更认真，而是更容易陷入重复调用，最后烧掉预算还给不出更好的答案。

4. 执行层把工具调用做成可恢复的任务

模型要创建工单、剪视频、发日历邀请时，不要让它直接越过业务服务。用一个有幂等键的任务接口接住，记录请求、审批状态、执行结果和回滚方式。高风险动作默认需要人工确认。

这块需要注意一下。读媒体、写摘要和删除文件，不应是同一个权限等级。多模态输入本身已经很复杂，再把工具权限混在一起，排障会非常痛苦。

5. 评估层检查结果，而不是只看模型分数

离线评测可以看定位准确率、摘要覆盖率、工具成功率、端到端延迟和每任务成本。线上还要看用户是否接受结果、人工修订比例、证据链接点击率、失败重试率。

Qwen 提供的基准成绩有参考价值，但它不是你的生产验收。你的会议语音、行业术语、权限系统和用户追问方式，都不会自动长得和 OmniVideoBench 一样。

别把所有问题都扔给多模态模型

Qwen 的案例里，Agentic Understanding 相比静态理解既降成本又提高准确率，很鼓舞人。不过它也有几个不能跳过的前提。

第一，粗到细的检索路径可能漏掉真正关键的片段。尤其当风险信息表达得很含糊，或答案依赖两个相距很远的镜头时，过早缩小范围会造成自信的遗漏。系统应允许高风险问题切换到更宽的检索或人工复核。

第二，官方的价格下降和基准提升都来自特定计价方法与评测设置。音视频输入的实际成本会受帧率、分辨率、转写策略、重试和缓存命中率影响。拿一组发布数字直接推全年预算，多少有点草率。

第三，开源 Harness 不会替你解决数据治理。会议录像里有客户信息，门店视频里有人脸，客服录音有个人数据。存多久、谁能看、如何脱敏、删除后索引是否同步失效，这些需要在产品设计前就定下来。

不是说多模态 Agent 不行，而是它越能进入真实世界，输入和输出的责任就越具体。把它当成一个会说话的播放器，风险不大。把它放进业务流程，它就必须像一套业务系统那样被设计和验收。

最后，别让一百万 Token 替你偷懒

Qwen3.8-Omni-Flash 的发布给了一个我很认同的信号。多模态能力的下一段竞争，不只是模型能否听懂、看懂，而是能否围绕问题主动取证、调用工具、完成任务，并在实时场景里稳定地活下去。

一百万 Token 很壮观，但用户需要的不是一台把所有录像吞进去的机器。

他们需要的是，在第 47 分钟那句真正重要的话出现时，系统知道该停下来，知道它为什么重要，也知道何时该把决定交还给人。

参考资料