多模态Skill与上下文工程：Agent落地的关键实践

做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_budget=2000): # 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_chars=80) compressed.append({ "time": clip["time_range"], "text": desc, "visual": visual, }) # Step 3: 按时间线编排 compressed.sort(key=lambda 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预算分配怎么做到心里有数

我给自己定了一套经验值，在不同项目里微调：

总预算建议控制在1500-2500 token之间，剩余留给系统指令和模型输出。超出预算时，我用分层摘要——先对每个片段做独立摘要，再对摘要做高一层摘要，保留关键论据的同时把总长度压下来。

这套上下文构建方式放到了多模态情感分析Skill里，效果显著，后面第5章的案例会具体展开。

4. 多模态融合策略：早期、晚期、中间，你的Skill该选哪一种

前面讲的多模态特征提取和时序对齐，都是"数据准备"层面。但真正决定效果上限的，是"融合"这一步——不同模态的信息在什么阶段、以什么方式结合。

4.1 三种融合方式的本质区别

早期融合（Early Fusion）是在输入端把各模态的原始特征直接拼接，比如把图像特征向量和文本特征向量concat成一个长向量再交给模型。优点是模态间的交互更充分，缺点是计算成本高，对特征对齐要求极高，而且模态不平衡时容易互相干扰。

晚期融合（Late Fusion）是各模态独立推理，最后在决策层做投票或加权。比如图像分类出一个结果、语音分析出一个结果、文本分析出一个结果，然后加权表决。优点是模块独立、速度快、每个子项可解释，缺点是丢失了模态间的关联信息。

中间融合（Intermediate Fusion）是在模型中间层让不同模态做注意力交互，这是目前主流多模态大模型采用的方式。效果最好，但工程复杂度和训练成本都最高。

我在Agent Skill场景里的选择很简单：能做中间融合就做，做不了就用"上下文级软融合"。所谓"上下文级软融合"，是指不给主干大模型喂原始模态数据，而是像第3章那样，把每个模态抽成描述文本，组织成结构化的上下文，让大模型在推理时自然地做跨模态语义融合。实测下来，这种方式的性价比极高。它牺牲了一点点底层特征交互的精度，但换来了极低的工程成本和极强的可调试性，特别适合Agent应用。

4.2 三种融合方式怎么选：一张表看懂

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内部流程

整个流程分五个环节：

1. 音轨抽取：用FFmpeg从视频里抽出音轨，再对音轨做ASR转写。视频画面按场景切换检测抽帧，每帧生成文本描述。
2. 特征抽取：ASR文本做关键词提取和基础情感词典打分；音频抽声学特征；画面描述文本和ASR文本用CLIP向量化用于软对齐。
3. 时序对齐：把ASR文本按时间戳切分，与画面描述片段对齐，生成带时间范围的语义片段。
4. 上下文组装：按第3章的四步流程，把片段压成预算可控的上下文，拼装成提示词的一部分。
5. 模型推理：调用大模型，要求它基于时间线上下文输出情感类别、情感强度、置信度和证据片段。

这个流程里，第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调试时，一定要让每条证据都能回溯到原始输入。我习惯在证据片段里保留时间戳、来源模态和原始摘要，这样当模型给出错误结论时，你能快速定位是特征提取的问题、对齐的问题，还是上下文编排的问题。这是整套方法里性价比最高的一个习惯——不花一分钱，省下无数个排查的深夜。