最近把Qwen3.5-Plus 拉到真实业务里跑了一圈原生多模态、图文混合预训练、2 小时视频全量理解、跨应用 Agent 自动化这几个词在宣传页上连在一起时没啥感觉真到落地阶段才发现每一个都要单独补课。这篇东西不聊口号只说我实际验证过的技术理解、工程方案和绕坑思路图文混合预训练到底改变了什么能力长视频理解在成本上怎么算账以及一个“视频解读到报告生成再到多应用分发”的 Agent 流程从零搭起来会遇到哪些问题。适合正在评估多模态大模型选型、或者准备把 Agent 接到真实工具链里的朋友参考。1. “原生多模态”到底动了哪根技术柱子1.1 从外挂式到原生式训练方式的分水岭先说一个容易被忽略的事实市面上大多数“能看图的大模型”并不是真正的原生多模态而是“外挂式多模态”。传统的做法是找一个人家训练好的视觉编码器比如把图片转成特征向量再接一个小映射层把这个向量转换成语言模型能读懂的 token然后拼在文本序列前面。整个图片理解能力基本依赖视觉编码器的输出质量语言模型本身对图像没有直接的感知它只是拿到了一份“翻译后的文本”。这个机制最大的问题是图像在模型眼里是“一段外文”语言模型是在读别人翻译好的内容而不是自己看原图。遇到图文关系复杂的场景比如某个界面截图里按钮的位置、表格里行列的对应关系、一段视频里动作的前后因果外挂式模型经常会丢细节。我拿同样的物料做过几个对照实验明显能感受到外挂式模型对图片里“位置关系”的描述容易含糊原因就在于图像被压缩成特征向量时细节已经被过滤掉了一轮。而 Qwen3.5-Plus 这种原生多模态模型走的是另一条路。它把文本、图片、视频统一成同一种序列建模方式在预训练阶段就用图文混合数据直接训练模型内部没有“先看图片再翻译成文字”这个中间过程。图像信息从一开始就是序列的一部分和文本 token 一起参与注意力计算。通俗讲外挂式模型像是一个“靠翻译读外文资料的人”原生多模态模型则是一个“从小同时学两门语言的人”它看到一份图文混排的材料时不会把图当成附件而是当作正文的一部分去理解。1.2 图文混合预训练的数据组织与建模逻辑图文混合预训练听起来高大上其实核心就一句话把文本和图片按原始文档的排版顺序混合成长序列让模型预测下一个 token而这个 token 可能是文字也可能是图片块的编码。预训练语料里大量采用网页正文、产品说明书、图文教程、短视频片段这类天然图文交错的数据模型在训练时学到的不是“这张图描述了什么”而是“这段文字和这张图共同组成了一个什么样的信息块”。这里有一个对 Agent 开发非常关键的点原生多模态模型对“同一对象的不同模态描述”有更一致的理解。举个例子给一段 HTML 文本和一张对应的网页截图外挂式模型要分别处理两路输入再尝试对齐而原生模型在预训练阶段就见过大量“文本配图”交错的数据它天然擅长把截图里的结构信息和 DOM 文本对应起来。做跨应用 Agent 时模型经常需要同时读页面截图、表单字段、按钮文案这种一致性理解能力直接影响操作成功率。我跑完第一轮测试后最大的感触是原生多模态模型在选择“该调用哪个工具”时更稳。因为它不仅能看懂页面当前的渲染状态还能结合页面源码判断按钮的真实可用性而不会只凭截图瞎猜。1.3 对外挂式与原生式能力差异的对比观察我自己做过一组粗略对比用同一个任务分别测试两类模型任务很简单给一张带数据的图表截图要求模型提取表格内容并回答某个字段的最大值。外挂式模型在图表边缘有折线图的情况下偶尔会把坐标轴刻度和数据表行搞混原生模型对“图表中不同区块”的区分明显更清楚给出的提取结果更接近真实数据。这个现象不意外因为图文混合预训练让模型见过大量“折线图数据表说明文字”同屏的样本它对这类复合信息的组织方式已经有先验认知。当然原生多模态不是万能药它解决的是“理解一致性”问题不等于每种具体任务都一定最强。但如果你要做跨应用 Agent需要模型在截图、文本、结构数据之间来回切换判断那么原生这个前提条件基本是刚需不建议选外挂式方案硬顶。2. 2 小时视频全量理解长上下文背后要算一笔账2.1 “全量理解”的算力账2 小时视频到底吃掉多少 token2 小时视频听起来只是一个时长数字换算成模型输入量就非常恐怖。2 小时也就是 7200 秒假设按照每秒抽 1 帧就是 7200 帧每帧经过视觉编码器压缩成 256 到 512 个 token那么总计大概在 180 万到 370 万 token 之间。这个数量级直接击穿了绝大多数模型上下文窗口的物理上限所以“全量理解”这件事背后必须有配套工程要么窗口够大要么压缩足够狠要么分片递归。Qwen3.5-Plus 能在标题里直接打“2 小时视频全量理解”说明它在以下三个层面都做了文章第一是长上下文窗口至少要把百万级 token 当作基本盘第二是视觉 token 压缩策略让单帧画面的表示成本尽可能低第三是位置编码的扩展性让超长序列下不同帧之间的时序关系仍然可被建模。从实际使用的角度我不建议开发者只盯着“能不能吃进 2 小时视频”这个结果更要关心“吃进去之后理解质量如何”。长序列建模有一个众所周知的衰减现象序列越长模型对远处信息的召回能力越差。所以哪怕上下文窗口足够大工程上仍然要做分片、锚点、摘要的配合不能一把梭。2.2 视频输入的工程准备与提示词组织方式在实际开发里给模型传视频通常有三种姿势传本地文件路径、传网络 URL、或者直接把抽好的帧序列传过去。我建议优先使用平台支持的视频文件直传接口让模型内部自己决定采样策略这样能最大程度保留关键帧信息。在提示词组织上不要把需求写成“总结这个视频”而要明确给出“输出维度”比如主题、发言人、关键时间点、行动项、风险点。我常用的模板是让模型按 JSON 结构返回并每条结论后面附上时间戳依据。这样后续做 Agent 自动化时报告直接结构化不需要再做一层后处理。提示第一次跑长视频任务前建议先用一个 10 分钟的短视频调通链路确认视频上传、采样参数、token 消耗预估都正常再放到 2 小时的正片上去跑否则排查周期会被拉长好几倍。2.3 长视频任务的实际输出形态与人力成本变化我拿一个实际项目做了验证输入一段产品评审会议的录像要求输出“议题清单、决策结果、遗留问题、负责人和截止时间”。模型返回的报告基本可以直接进入周报时间点引用也能对应上原始录像的某个片段。以前这种活需要一个实习生抽半天素材、再花半天整理成纪要现在模型首轮就能给出 80% 质量的初稿人工只需要做校对和补漏。这个效率提升不是简单的“快 2 倍”而是把一个需要固定人力的任务变成了可并发、可重复的自动化流水线。当然视频质量比较差、多人同时说话、重点信息只出现在某一块白板上时模型仍然会漏这个后面单独讲。3. 跨应用 Agent 开发的三个前置准备3.1 让模型“会调用工具”的核心机制Function Calling跨应用 Agent 的基本交互模式不是让模型直接操作应用而是让模型在需要某个能力时输出一个结构化的工具调用请求由你的代码去执行。这里的核心机制就是 Function Calling。Qwen3.5-Plus 对 Function Calling 的支持属于我现在比较满意的水平多轮对话中模型既能在前一轮的工具结果基础上继续推理也能在同一个回复里同时发起多个工具调用。开发时你只需要把工具声明成一个 JSON Schema模型会在合适时机把“调用哪个函数、传什么参数”返回给你。from openai import OpenAI client OpenAI( base_urlhttps://your-endpoint.example.com/v1, api_keyyour-api-key, ) tools [ { type: function, function: { name: create_calendar_event, description: 创建日历会议邀请并返回会议链接, parameters: { type: object, properties: { title: {type: string, description: 会议标题}, attendees: {type: array, items: {type: string}, description: 参会人邮箱列表}, start_time: {type: string, description: 会议开始时间ISO8601格式} }, required: [title, attendees, start_time] } } } ]3.2 工具注册表把应用能力翻译给模型听工具注册表是 Agent 项目里不对齐就容易翻车的部分。模型的工具调用质量很大程度取决于你把工具“描述”得多清楚。我见过很多失败的 Agent 项目问题不在模型而在工具描述写得含糊。工具描述要满足三个原则描述里包含触发条件、包含输入参数的口径说明、包含返回结果的格式说明。比如“创建日历事件”这个工具如果 description 只写“创建事件”模型可能在用户问“帮我约个会”时犹豫要不要调用如果写清楚“当用户需要安排会议、约会、日程时调用”触发准度立刻提高。另外参数说明也要详细到“值的取值口径”。比如 start_time 字段要写清楚是本地时间还是 UTC时间段是 30 分钟还是 60 分钟。模型根据参数描述生成参数描述不明确它就自己猜一猜就会出数据格式错误。3.3 最小运行环境与配置参考在正式开发之前我建议先搭一个最小环境避免后面在依赖地狱里挣扎。我当前用的是 Python 3.11SDK 走 OpenAI 兼容协议只需要两个核心依赖。pip install openai python-dotenv环境变量建议单独用.env管理不要硬编码在代码里LLM_BASE_URLhttps://your-endpoint.example.com/v1 LLM_API_KEYyour-api-key LLM_MODELqwen3.5-plus DEFAULT_TIMEOUT600长视频任务很容易超过常规 HTTP 超时时间我一般把 timeout 设到 600 秒以上或者直接采用异步任务模式提交视频处理请求后轮询任务状态等模型侧生成完成再拉结果。这比一个长连接挂在那里要稳得多。4. 做一个“视频解读→报告→多应用分发”的 Agent 流程4.1 需求拆解与流程设计这个流程模拟的是一个很典型的场景你有一段 2 小时的会议录像需要自动提取决策和待办然后把待办分发到日历、任务管理、企业微信机器人、共享表格四个地方。流程拆成四步第一步调用视频理解接口得到结构化报告第二步做规则判断把行动项分类第三步按分类触发不同工具第四步把各工具返回结果回填到一张总表。整个过程用一个主循环驱动。带工具的 Agent 架构听起来复杂核心代码其实就三层第一层负责和模型对话第二层负责维护工具列表和工具执行函数第三层是主循环负责检查模型是否返回 tool_calls、执行工具、把结果带回模型。4.2 核心代码实现import json import time from openai import OpenAI client OpenAI( base_urlhttps://your-endpoint.example.com/v1, api_keyyour-api-key, ) MODEL qwen3.5-plus def analyze_video(video_path: str) - dict: resp client.chat.completions.create( modelMODEL, messages[ { role: user, content: [ {type: text, text: ( 分析这段视频输出 JSON {\topics\: [...], \decisions\: [...], \action_items\: [{\task\: \\, \owner\: \\, \due\: \\}]} )}, {type: video, video_path: video_path}, ], } ], response_format{type: json_object}, ) return json.loads(resp.choices[0].message.content) def create_calendar_event(task_info: dict) - str: # 这里接日历服务的真实 API return fcreated event for {task_info[task]} TOOL_FUNCS { create_calendar_event: create_calendar_event, } def run_agent_task(video_path: str): step 0 max_steps 8 tools [ { type: function, function: { name: create_calendar_event, description: 为行动项创建日历事件, parameters: { type: object, properties: { task: {type: string}, owner: {type: string}, due: {type: string} }, required: [task, owner, due] } } } ] messages [ {role: system, content: 你是任务分发助手。先从视频中提取行动项再为每个行动项调用工具。}, {role: user, content: [{type: video, video_path: video_path}]}, ] while step max_steps: resp client.chat.completions.create( modelMODEL, messagesmessages, toolstools, ) msg resp.choices[0].message if not msg.tool_calls: print(最终回答:, msg.content) break messages.append(msg) for call in msg.tool_calls: args json.loads(call.function.arguments) if call.function.name in TOOL_FUNCS: result TOOL_FUNCS[call.function.name](args) else: result funrecognized tool: {call.function.name} messages.append({ role: tool, tool_call_id: call.id, content: json.dumps({result: result}), }) step 1 if step max_steps: print(达到最大步数流程未完全结束)4.3 运行过程与结果校验我把一段 2 小时产品评审录像丢进这个流程模型第一步先返回了完整的 JSON 报告识别出 3 个议题、5 条决策、8 个行动项。随后主循环逐个为行动项调用日历工具。这里有个细节值得注意模型会一次性发起多个 tool_calls而不是一个一个来这比早期模型快很多。你要做的就是在代码里遍历 tool_calls 列表全部执行完再一起返回结果。结果校验时我会让模型在最终回答里附一份“分发结果对照表”把每个行动项和对应的工具返回值绑定。这样我只需要人眼扫一眼是否所有行动项都已成功分发不需要回查日志。这个习惯我一直保留因为 Agent 流程一旦跑起来最怕的就是“看起来成功实际某一步静默失败”。5. 坑位梳理长视频与 Agent 链条中最容易翻车的几个点5.1 上下文超限分片递归摘要怎么做我实测下来2 小时视频一次性让模型全量处理在超大窗口模型上可行但费用较高。更稳妥的方案是分片递归每 20 分钟切一个片段分别生成片段摘要再把所有摘要合并成完整报告。这个方案有两个直接好处单个请求的 token 量可控某个片段失败时可以只重跑那一片不必全量重来。分片摘要的风险是跨片段的关联信息丢失比如前面提出的问题后面才有结论单看第一段摘要会误以为没有结果。我的处理办法是在全局摘要阶段专门让模型做一次“跨片段信息聚合”提示词里写明“如果多个片段出现同一主题先合并再总结不要单独罗列”。5.2 工具调用失控死循环的防御手段带 Function Calling 的 Agent 最容易出现的问题是多轮对话失去终止条件。模型可能在完成所有任务后仍然继续调用工具或者在某个工具返回异常后反复重试同一个调用一直绕不出来。防御手段我建议至少加三层第一层是 max_steps 上限我默认设 8 步超过就算未完成第二层是结果识别工具返回特定标记比如 error 或 no_data 时让模型停止继续调用并解释原因第三层是给所有工具加幂等键用 task_id 去重防止同一个行动项被重复创建事件这在真实业务里非常实用。5.3 多模态幻觉被放大让输出可溯源多模态模型和纯文本模型一样会产生幻觉但在 Agent 场景里幻觉的代价更大因为模型一旦把视频里不存在的内容写进报告后续分发工具也会照单全收。我的经验是强制让模型所有结论都带“依据锚点”视频结论给时间戳、截图结论给坐标或元素位置、网页操作结论给对应的页面原文摘录。提示词里我常加一段话“所有输出条目必须以可验证的事实为依据凡是视频中没有出现的细节必须注明不确定性禁止编造负责人、日期、数据。”长视频理解尤其需要这个约束因为视频信息密度太高模型很容易把不同片段的信息串在一起形成虚假记忆。5.4 抽帧策略失当快速变化画面的信息丢失虽然模型接口会自动抽帧但当视频里有高速变化的局部区域比如白板板书过程、PPT 动画、快速滚动的代码编辑器自动抽帧很可能漏掉关键中间态。我的补救措施是给视频理解接口多加一个“重点关注区域”的说明比如“请重点分析第 40 分钟到第 60 分钟白板上的内容变化”让模型在时间维度上加大采样密度。这个办法不是每次都有用真遇到高频变化的关键内容我建议把对应片段单独截取成短视频再喂一轮比完整视频硬扛更可靠。5.5 函数参数类型与校验模型生成函数参数时偶尔会给错类型比如日期字段少一位秒数、数组字段传成了逗号分隔的字符串。我在执行工具前会加一层 json schema 校验不合法就直接返回校验错误信息给模型让它自行修正。实测下来给模型返回“参数校验失败原因start_time 需要 ISO8601 完整格式”比直接抛异常给用户要好得多模型会自动重新生成参数。5.6 长任务中断恢复与检查点设计视频理解或跨应用分发跑十几分钟时中途很可能因为网络抖动、服务超时、限流等原因中断。如果流程没有检查点重跑一次又要花十几分钟。我给每个步骤都写了状态标记video_done、report_done、tool_done每完成一步就把中间结果落盘。重启时检测到 video_done 就直接跳过视频分析读取落盘报告继续节省大量时间。这个设计在做长视频批量处理时尤其重要几十条视频排队跑任何一条失败都不该拖垮整批任务。从这次完整开发经历来看原生多模态带来的提升不是单点能力上的“更强”而是把原来需要多种模型拼接、多种格式转换、多层对齐的复杂链路压缩成了单一模型内部的统一理解。我的体会是技术宣传里的每一项能力落到工程上都需要配套的流程设计和防御机制模型提供理解力上限稳不稳定则取决于你的工程兜底。视频理解、Agent 调用、跨应用分发这三段链路串起来之后节省的人力成本确实明显但投入的调试时间也不少。这里面的关键是不要被“全量理解”“自动化”这些词冲昏头脑先拿小样本验证能力边界再逐步放大到真实场景。
