做Agent落地这一年多我最大的感受是真正拦住我们的往往不是模型不够聪明而是模型看不懂我们喂给它的东西。尤其当输入不止文本时——用户上传了一张截图、发来一段语音、录了一段视频或者工单里带着一堆传感器读数——问题就从模型会不会做变成了怎么让模型正确理解这些不同模态的信息。这一篇是Agent Skills系列的第六篇。前几篇我们解决了Agent怎么调用工具、怎么编排Workflow、怎么配置记忆今天把重点放在两个紧密咬合的主题上多模态Skill与上下文工程。先说结论多模态Skill不是把图片、音频原样塞给大模型那么简单。我实测下来几乎所有直接硬塞的方式都会遇到同一类问题——上下文窗口告急、不同模态信息互相打脸、模型抓不住重点。而真正让多模态Skill跑起来的是背后的上下文工程怎么把图像、音频、文本、时序信息重新组织成一个清晰、紧凑、有逻辑链的语义空间再交给模型。这篇文章我会从输入侧的现实问题讲起然后是特征提取与对齐、上下文构建、融合策略最后用一个多模态情感分析Skill的完整例子收尾适合所有正在做Agent、RAG和多模态应用的工程师参考。1. 为什么Agent迟早要处理多模态输入侧的三个现实问题先别急着聊模型和算法我们看业务侧的真实输入。我接过的项目里客服工单分析是最典型的多模态场景用户吐槽你们这个功能怎么又卡了附带一张手机截图再丢来一段录屏或者语音消息。纯文本Agent在拿到这些输入时等于只看见了问题的一小块碎片。截图里的报错码、语音里的急躁语气、录屏里反复点击同一个按钮的节奏这些都是关键信息但它们不在同一个数据形态里。这种场景推着我们把多模态从锦上添花变成了必选项。但真上手之后你会发现有三个绕不开的现实问题。1.1 模态异构像素、波形和token怎么坐到一张桌上文本输入给Agent的是token图像是一堆像素矩阵音频是一串波形采样点视频还要再加上时间轴。它们的底层表示完全不同没法直接做拼接。有的人想到先把图片用base64编码塞进Prompt音频转成频谱图再喂给视觉模型实测效果都很差。原因也很简单大模型在文本空间里的推理能力最强你把像素和频谱图硬塞进去它看是看到了但推理链条会被割裂。所以第一步要解决的是如何让不同模态的信息在进入Agent主干之前都被翻译成某种可统一处理的中间表示。这个中间表示可以是文本描述可以是特征向量也可以是结构化JSON但必须满足信息不丢失太多 能被下游模型理解两个条件。关于这块的具体做法我放在第2章详细说。1.2 窗口预算上下文不是无限大的行李箱很多同行低估了多模态输入的体量。一段30秒的语音转成文本大概150个token不算多但一张高分辨率截图经视觉编码器处理后可能要几百甚至上千个token一段10分钟的视频如果按秒抽帧那就是600帧图像的信息量。就算用上了长上下文模型直接全部塞进去也是灾难成本飙升、响应变慢、模型注意力被无关信息稀释。上下文工程的核心约束从来都是预算。你要像收拾行李箱一样决定哪些信息值得占地方、哪些东西可以压缩成一句话、哪些直接扔了。这个思路贯穿整篇文章后面我会专门给出一套token预算分配的例子。1.3 语义对齐同一事实不同模态各说各话就算你把各种模态都转换成了文本或向量还有一个更隐蔽的问题它们各自表达的内容可能不在同一层语义上。用户说网络很差截图里信号满格语音里语气焦虑录屏里页面转圈转了一分钟。如果只看字面文本结论是用户网络差结合图像和视频真实结论可能是服务端接口超时。这就是语义对齐要解决的问题让Agent能把不同模态的信息放到同一个时间轴和同一个因果链里去理解。语音反映情绪文字反映事实图像反映状态它们应该像一个项目组里的不同角色互相补充验证而不是各讲各的、互相矛盾。这块我放在第2章的时序对齐和第4章的融合策略来展开。2. 先让每种模态自报家门多模态特征提取的工程套路很多人一提到多模态就想到端到端大模型恨不得把原始像素和波形直接扔进一个巨无霸网络。但做Agent Skill我们的目标不是训练一个多模态大模型而是把已有模型能力组装成可用的功能。所以工程上最常见的路径是先用专门模型把每种模态抽成摘要级信息再让主干大模型基于这些摘要做推理。2.1 图像别让模型看原图先让模型读图我处理图片的习惯是分三步OCR、描述、结构化抽取。OCR负责把截图里的文字抠出来这对工单类场景尤其重要报错码、按钮文案、弹窗内容都是关键证据图像描述模型负责生成自然语言说明比如页面右上角显示红色错误提示主区域为空白结构化抽取则是用目标检测模型把界面元素、障碍物、物体位置输出成JSON。三步做完一张图就变成了一段有逻辑的文本和一组结构化字段。选择具体模型时不需要追求最大参数。CLIP系模型做图像-文本匹配很稳适合判断这张图和这段描述像不像BLIP、Qwen-VL这类可以做更细的caption生成OCR就用现成的PaddleOCR或Tesseract。我现在的默认做法是文本密集的截图走OCR优先自然场景图走caption模型优先两者输出一起保留。实践下来caption模型对密集小字的识别能力远不如OCR稳定反过来OCR面对纯自然场景也几乎无能为力。2.2 音频先转文字再补声学特征音频的常见处理思路是ASR转写加声学特征抽取。ASR负责把语音变成文本这样内容线索就进到了大模型的文本空间里但转写会丢掉语气、情绪、停顿这些信息。比如你真厉害这句话书面看是夸奖配上阴阳怪气的语气就变了味道。所以对情感分析类Skill我会额外抽取声学特征语速、音量均值与方差、基频范围、静音段占比。这些特征不需要深度学习模型用librosa之类的音频库就能提取成本极低但对情绪判断的帮助非常明显。2.3 视频抽帧是门手艺活视频本质上就是图像序列音频轨道字幕轨道。处理视频时最容易犯的错是拼命抽帧。我见过有人每秒抽3帧10分钟的视频处理完上下文爆炸成本也爆炸。我的做法是场景切换检测加固定间隔抽帧结合先用简易的场景检测算法找出画面突变点每个镜头取首尾两帧和中间一帧再加上一个较宽的固定间隔比如每10秒1帧做兜底。这样既能覆盖视频的核心内容又不会让信息过载。2.4 时序对齐把信息统一盖在时间轴上当你手里有了图像描述、ASR文本、声学特征下一步就是对齐。这步做不好后续融合理念再先进也没用。我用的方案是给每条信息打上统一的时间戳把硬对齐和软对齐结合。硬对齐是指画面和语音在同一个时间区间内比如第10秒到第20秒画面是产品演示语音也在讲功能那这两条信息直接关联软对齐是指跨时间的语义关联比如语音在第5秒提到这个地方一闪一闪但画面里的高亮效果出现在第12秒这时需要用语义向量相似度来做跨时间匹配。对齐结果我习惯存成结构化的时间片段{ sample_id: case_001, timeline: [ { start: 0.0, end: 8.5, modality: [video, audio], asr_text: 你看这个页面打开非常慢, visual_desc: 屏幕停留在加载动画超过6秒, acoustic: {speed: 2.1, pitch_variance: 0.35, silence_ratio: 0.08}, intent: 报障, sentiment: negative } ] }做完这一步我们手里的信息就从一堆异构原始数据变成了一组带时间戳的结构化语义片段。这为后面的上下文工程打好了地基。3. 上下文工程多模态Skill真正的胜负手如果说特征提取解决的是信息能不能被看懂上下文工程解决的是信息以什么形态进入模型、以什么顺序呈现、哪些被保留哪些被丢弃。这一步我甚至觉得比模型选型还重要。3.1 上下文工程不是提示词工程这两个概念经常被混为一谈。它们的边界其实很清楚提示词工程解决的是怎么问包括角色设定、指令撰写、few-shot示例设计上下文工程解决的是给什么包括检索哪些内容、如何压缩、怎么排序、如何控制token预算。打个比方提示词是对话的开场白和提问技巧上下文是这次对话你能拿出来的证据材料。多模态场景下证据材料的形态和质量直接决定结论质量上下文工程的重要性被数倍放大。3.2 多模态上下文构建的四步流程在实践里我把上下文构建拆成四个步骤过滤、压缩、编排、注入。过滤把噪声信息剔除。模糊帧、无关背景音频、重复的截图都可以在这个阶段去掉。压缩对保留的信息做摘要级加工。图像用一句话描述长语音用摘要模型压缩表格只保留关键字段。编排按时间线、因果链或优先级给信息排序。多模态场景我基本按时间线编排因为模态间的跨引用需要时间锚点。注入把编排好的信息组装成模型可读的格式并严格控制总token不超过预设预算。下面是我在项目里直接用过的一段伪代码帮大家理解四步流程如何串起来def build_multimodal_context(sample, max_budget2000): # Step 1: 过滤噪声帧/片段 valid_clips [ clip for clip in sample[timeline] if clip[visual_desc] is not None and clip[asr_text] ! and clip[importance_score] 0.4 ] # Step 2: 压缩给每个clip分配token上限 compressed [] for clip in valid_clips[:8]: # 限制片段数量 desc clip[asr_text][:200] # 截断文本长度 visual summarize(clip[visual_desc], max_chars80) compressed.append({ time: clip[time_range], text: desc, visual: visual, }) # Step 3: 按时间线编排 compressed.sort(keylambda x: x[time][0]) # Step 4: 注入拼装成结构化Prompt块 blocks [] for item in compressed: block f[{item[time][0]}-{item[time][1]}s] block f语音: {item[text]} | 画面: {item[visual]} blocks.append(block) context \n.join(blocks) return trim_to_budget(context, max_budget)这段代码不复杂但三个细节值得注意片段数量上限、文本截断长度、最终的总预算裁剪。这三点都是预算思维的体现。3.3 token预算分配怎么做到心里有数我给自己定了一套经验值在不同项目里微调信息类型原始形态预算建议说明工单文本500字正文300-500 token尽量保留原文截断会丢失细节图像截图1080p截屏80-150 token用OCR文本一句话描述语音内容60秒录音150-300 tokenASR全文摘要视频画面10秒片段40-80 token/片段抽帧后生成caption声学情感特征统计特征30-50 token转成结构化数值描述总预算建议控制在1500-2500 token之间剩余留给系统指令和模型输出。超出预算时我用分层摘要——先对每个片段做独立摘要再对摘要做高一层摘要保留关键论据的同时把总长度压下来。这套上下文构建方式放到了多模态情感分析Skill里效果显著后面第5章的案例会具体展开。4. 多模态融合策略早期、晚期、中间你的Skill该选哪一种前面讲的多模态特征提取和时序对齐都是数据准备层面。但真正决定效果上限的是融合这一步——不同模态的信息在什么阶段、以什么方式结合。4.1 三种融合方式的本质区别早期融合Early Fusion是在输入端把各模态的原始特征直接拼接比如把图像特征向量和文本特征向量concat成一个长向量再交给模型。优点是模态间的交互更充分缺点是计算成本高对特征对齐要求极高而且模态不平衡时容易互相干扰。晚期融合Late Fusion是各模态独立推理最后在决策层做投票或加权。比如图像分类出一个结果、语音分析出一个结果、文本分析出一个结果然后加权表决。优点是模块独立、速度快、每个子项可解释缺点是丢失了模态间的关联信息。中间融合Intermediate Fusion是在模型中间层让不同模态做注意力交互这是目前主流多模态大模型采用的方式。效果最好但工程复杂度和训练成本都最高。我在Agent Skill场景里的选择很简单能做中间融合就做做不了就用上下文级软融合。所谓上下文级软融合是指不给主干大模型喂原始模态数据而是像第3章那样把每个模态抽成描述文本组织成结构化的上下文让大模型在推理时自然地做跨模态语义融合。实测下来这种方式的性价比极高。它牺牲了一点点底层特征交互的精度但换来了极低的工程成本和极强的可调试性特别适合Agent应用。4.2 三种融合方式怎么选一张表看懂对比维度早期融合晚期融合上下文级软融合实现难度中高低中低模态间交互充分弱中等靠语义理解可解释性差好好对数据对齐要求极高低中计算成本高低中典型适用场景训练专用模型快速原型、多分类决策Agent Skill、RAG应用4.3 用CLIP理解什么叫统一语义空间很多做多模态的同行第一次接触CLIP时都会惊讶于它的简洁把图像编码器和文本编码器在同一个向量空间里训练图像与对应文本的向量距离被拉近。这样一来一只猫的文字描述和一张猫的照片就能在同一个向量空间里比较相似度。这个思路给我们的启示是多模态统一处理并不意味着所有模态要变成一模一样的文件格式而是它们在语义层面能被同一个度量标准对齐。实际操作里我会用CLIP的文本编码器给图像描述文本和ASR文本做向量化接着用余弦相似度做软对齐和去重。这一步让之前对齐的时间片段有了统一的语义坐标后续融合的稳定性大幅提升。4.4 融合权重怎么调如果走的是晚期融合或加权融合最头疼的是权重设置。不同业务场景下各模态的可靠性完全不同。比如客服工单里用户文字描述通常是事实主体截图是佐证但在视频内容理解场景里视觉信息可能比语音更权威。我的经验是先用规则权重跑基线。比如文本0.5、图像0.3、音频0.2然后用一小批验证集调参。如果验证集够大再把规则权重换成可学习的逻辑回归权重。不要一上来就上大模型学习融合权重容易过拟合。5. 实操案例一个多模态情感分析Skill的完整落地过程前面讲了很多方法论这章用我做过的一个多模态情感分析Skill来完整串一遍。之所以选情感分析是因为它对模态间语义对齐的要求特别典型文字说挺好的语音语气冷淡画面脸色疲惫三个模态信息矛盾模型必须能综合判断。5.1 需求与输入输出定义业务需求来自一个用户反馈分析平台用户上传一段吐槽视频或者一段录音加一张截图系统需要自动判断用户情绪状态和核心诉求。我定义Skill的输入是一段视频文件路径、一份ASR文本可选、一张用户界面截图可选输出是一份结构化情感报告。输出格式定义为{ skill: multimodal_sentiment_analyzer, overall_sentiment: negative, sentiment_score: 0.82, confidence: 0.75, evidence: [ {time: [0, 5], modality: speech, text: 打开这个页面一直转圈, signal: asr_text}, {time: [3, 12], modality: visual, desc: 加载动画持续超过8秒, signal: screen_capture}, {time: [0, 8], modality: acoustic, features: {speed: 1.9, pitch_variance: 0.3}, signal: annoyed_tone} ], intent: report_issue, suggestion: 优先排查页面加载超时问题 }5.2 Skill内部流程整个流程分五个环节音轨抽取用FFmpeg从视频里抽出音轨再对音轨做ASR转写。视频画面按场景切换检测抽帧每帧生成文本描述。特征抽取ASR文本做关键词提取和基础情感词典打分音频抽声学特征画面描述文本和ASR文本用CLIP向量化用于软对齐。时序对齐把ASR文本按时间戳切分与画面描述片段对齐生成带时间范围的语义片段。上下文组装按第3章的四步流程把片段压成预算可控的上下文拼装成提示词的一部分。模型推理调用大模型要求它基于时间线上下文输出情感类别、情感强度、置信度和证据片段。这个流程里第4步是灵魂。我把时间线片段严格按时间顺序编排并在Prompt里明确要求推理必须引用证据片段编号这样模型不会凭空臆断。5.3 效果和典型Badcase在自建验证集上的结果纯文本情感分析的准确率约78%加上图像和声学特征后准确率提升到87%左右。尤其在反讽和口是心非这类场景提升最明显。但有两个Badcase值得拿出来说。一类是反讽句比如用户说你们速度可真快啊语音语气是愤怒的文字是褒义的。ASR文本单独看是正向声学特征显示愤怒这时候上下文里如果没有声学特征辅助模型就会判断错误。第二类是画面和语音不同步用户先拍了一下屏幕再开始解说抽帧时如果只抽到解说画面会漏掉最开始的关键屏拍。解决方式是保留每个片段的起止时间戳并允许模型发现早期视觉信息与后期语音信息跨片段关联。这类Edge case完全靠算法调优很难根治必须配合上下文设计上的留白给模型提供跨片段引用的能力它才能跳出局部把全局串联起来。6. 踩坑记录与调优心得多模态Skill落地中的四个关键教训6.1 坑一抽帧密度不是越高越好我第一次做视频理解时以为抽帧越密信息越全。结果10分钟视频抽了600帧每帧生成描述光是图像描述就占了几千token模型在浏览这些碎片的时候反而抓不住关键内容。后来改成了场景切换检测加固定兜底抽帧片段量控制在8到15个效果反而提升了。教训是上下文的价值密度比上下文长度更重要。6.2 坑二上下文顺序会直接影响模型结论同一个证据集合按时间正序排列和倒序排列模型给出的结论可能不同。我在测试中发现模型对最后看到的信息有天然的偏重。所以上下文编排必须刻意设计要么严格按时间正序并且在Prompt里明确时间流动方向要么把最重要的证据放在开头和结尾两个位置来对冲位置偏差。千万不要默认排序无所谓。6.3 坑三各模态的权重失衡会让融合退化成单模态如果某个模态的特征特别冗长比如ASR文本占了总token的80%模型几乎就忽略了图像和声学信息融合名存实亡。我踩过这个坑之后给每个模态设了token上限宁可压缩文本也要保证图像描述和声学特征进得来。情感分析场景里视觉和声学特征往往只有几百token但它们承载的信息密度极高必须保。6.4 坑四资源受限时的降级方案不是所有团队都有钱租一堆GPU跑CLIP和BLIP。资源紧张时图像caption可以用开源小模型甚至本地OCR加规则描述声学特征用轻量库抽取ASR用云厂商接口。数据量不大的情况下效果损失没有想象中那么大。我还试过只把关键帧转成base64放进LLM的视觉接口跳过显式的caption生成准确率下降不到3个百分点但费用上升不少。这个降级路径对中小团队很友好。最后分享一个小技巧多模态Skill调试时一定要让每条证据都能回溯到原始输入。我习惯在证据片段里保留时间戳、来源模态和原始摘要这样当模型给出错误结论时你能快速定位是特征提取的问题、对齐的问题还是上下文编排的问题。这是整套方法里性价比最高的一个习惯——不花一分钱省下无数个排查的深夜。