多模态Skill与上下文工程：从特征处理到Agent落地

前言不多说，直接进正题。Agent Skills这个系列写到第6篇，前几篇聊的都是纯文本场景下的Skill设计，到了多模态这里，很多朋友会发现原来的思路突然不灵了：图片、音频、视频片段这些非文本输入，没法简单塞进一层System Prompt里完事，特征异构、token开销大、时序对不齐，随便一个问题就能把Agent卡死。这篇就把多模态Skill和上下文工程放在一起讲透，结合我实际调过的一个图文情感分析Agent，拆开来看多模态场景下Skill到底该怎么设计、上下文该怎么管。

先说清楚这篇适合谁看。正在做Agent应用、想把多模态能力接进自己的Agent里、但又被上下文窗口和特征差异折磨过的开发者，这篇可以直接抄作业。刚入门的朋友也不用慌，我会把CLIP、特征提取、上下文预算这些基础概念用类比和实例讲明白，你看完至少能知道多模态Skill的骨架长什么样，以及从哪儿下手踩坑最少。

1. 多模态Skill的定位与整体设计思路

1.1 Agent Skills体系里的“技能卡”逻辑

Agent Skills本质上是一组可复用、可插拔的能力单元。你可以把Agent想象成一个操作系统，Skill就是安装在上面的应用程序，需要时加载、用完就卸载，不需要把所有功能全塞进模型权重里。这个设计最大的好处是隔离性和可扩展性：每个Skill管好自己的输入输出、依赖和上下文需求，Agent只负责任务分发和结果汇总。

到了多模态场景，这个“技能卡”逻辑变得更加重要。纯文本Skill说白了就是“给模型一段指令文本”，但多模态Skill意味着Agent要临时接入视觉编码器、音频编码器、特征检索库，甚至要维护一个跨模态的记忆缓存。如果不做模块化隔离，这些复杂的依赖关系会在Agent启动时就把上下文窗口塞满，推理速度也会肉眼可见地变慢。

我在实际项目中会把多模态Skill拆成三个层次：

• 感知层：负责把原始输入（图片、音频、视频帧）转成机器学习模型能理解的张量或特征向量，这一层通常用到CLIP的image encoder、whisper的audio encoder这类组件。
• 语义层：把异构的特征统一映射到一个共享语义空间，让文本、图像、音频的特征可以互相比较和对齐，这是多模态Skill和普通工具型Skill最本质的区别。
• 输出层：根据语义层的对齐结果，生成文本回答、情感标签、检索排序或者结构化的JSON输出，供Agent的调度模块消费。

这个分层设计的好处是每一层的改动不会波及其他层。比如今天我嫌CLIP的视觉特征不够细，换成SigLIP，只需要动感知层，语义层和输出层的接口保持不变。如果你一开始就把这些逻辑揉在一个大函数里，后期想换模型或者加一个输入模态，基本就要重写整个Skill。

1.2 多模态场景下的三个核心痛点

多模态Skill做起来难，背后其实是三个绕不开的痛点在捣乱。

第一是特征异构。图片是一堆像素矩阵，音频是一帧帧的波形采样点，文本是离散的token序列，三种东西本来就不在一个向量空间里，粗暴地拼在一起喂给模型，模型根本学不到跨模态的对齐关系。这就好比你把三个讲不同语言的人拉进一个会议室，不配翻译，讨论效率一定是零。必须要有一个统一的语义空间来做中转。

第二是上下文窗口的资源饥渴。都说多模态模型能吃图能听音，但代价是输入token成倍上涨。一张224x224的图片切patch之后经过视觉编码器，产生的视觉token动辄几百上千个，一段10秒的音频采样转成频谱特征之后，token量也不小。如果你的Skill把原始输入直接怼进上下文，两三轮对话之后窗口就爆了，后面的指令根本进不去。

第三是跨模态的时序信息难以对齐。这种问题在视频和语音场景里尤其致命。比如你要做一个视频情感分析Skill，画面里的人在第八秒露出笑容，音频里他说到第十秒语气才明亮起来，文本转录里这句话出现在第十二秒的位置，三个模态的事件在时间轴上不同步，如果直接“各看各的”，Skill给出的结论一定是错的。

我见过很多翻车项目，基本都是在这三个痛点上栽跟头。不是说模型不够强，而是Skill设计的时候没有把特征处理和上下文管理当成一等公民来对待。想要做出真正能落地的多模态Agent，第一步就是正视这三个问题。

2. 技术底座：多模态模型的选型与特征处理

2.1 模型选型：CLIP、LLaVA、BLIP怎么挑

做多模态Skill之前必须定一个技术底座，这个选择直接决定了后面所有工作的复杂度。

**CLIP（Contrastive Language-Image Pre-training）**是我用的最多的底座模型。它的核心思路是用海量的图文对做对比学习，让模型学会把图片和对应的文本描述拉近、把不相关的推开。训练完之后，图像encoder和文本encoder输出的特征向量落在同一个空间里，直接可以做向量相似度计算。CLIP的门槛低、生态好、社区权重多，关键是它把“统一语义空间”这件事做成了开箱即用，对于Agent Skill来说这是最有价值的部分。

LLaVA是另一种路线，它是把视觉编码器和LLM深度融合，能够直接输出复杂推理的文本。如果你需要让Agent基于图片内容做多轮对话、逻辑推理，而不是单纯做相似度检索，LLaVA这类视觉语言模型更合适。缺点是推理开销大，视觉token占比高，上下文压力比CLIP大一个量级。

BLIP则更适合图文理解与生成并存的场景，比如图片打标签、图像描述、图文检索。它在细粒度理解上比CLIP好，但对齐空间的鲁棒性略差。

我自己的经验是：如果Skill的核心任务是“从多模态输入里抽取特征、做检索、做对齐”，无脑选CLIP类模型；如果核心任务是“看图说话、多轮推理”，选LLaVA这种端到端VL模型；如果两者都要，就做两级结构，感知层用CLIP抽特征，语义层挂一个VL模型处理复杂理解任务。这样的组合能兼顾速度和效果，不至于每个请求都白白烧算力。

这里要提一下多模态数据集的重要性。我在做情感分析Skill的时候没有先用商用数据集，而是自己整理了一个小规模的图文数据集，大概1400条样本，覆盖了正面、负面、中性三类情绪。确认各个类别的分布均衡之后再进入训练和调优阶段。这个习惯帮我躲过不少坑——有些开源数据集里的图片和标签本身就没对齐，模型学习到的所谓“关系”到了真实场景就完全失效。

2.2 特征提取与多模态特征文件缓存

多模态Skill和文本Skill性能差距最大的地方在于特征提取的花费。文本输入可以直接走tokenizer，耗时几乎可以忽略，但一张图片要过图像encoder做前向计算，在CPU上推理可能要吃几十毫秒甚至上百毫秒，在边缘设备上更夸张。

所以我在真实项目里会引入多模态特征文件机制。简单来说就是“特征抽取一次，复用N次”。对于同一个图片文件，我会跑一次视觉编码器，把输出的特征向量序列保存成本地的npy或pt文件，后续Agent再遇到这张图片的时候直接读特征文件，跳过重复计算。特征文件为了减少重复计算，通常还会在离线阶段就批量生成好，形成一个特征库，运行时只是查表加载。

这个做法的收益在向量检索场景里最明显。如果Agent要在一个包含1000张图片的图库里做相似度检索，线上推理时高频调用视觉编码器是灾难，但提前把1000个特征向量都算好、建立索引，查询时的耗时降到了几次乘法运算的量级。

需要注意的是，特征文件有版本和时效性。如果你换了一个编码器，或者重新训练过模型，旧的特征文件就失效了，必须重建。我习惯在文件命名里带上模型版本的hash，比如clip_vit_b32_8fa3c2.npy，一旦模型参数变化，文件名自然变化，缓存间的错乱就避免了。

2.3 多模态融合与时序对齐：上下文工程的前置条件

多模态融合算法这个话题展开说有大把论文，但在Agent Skill的语境下，我们只需要掌握两个概念：早期融合和晚期融合。

早期融合是把不同模态的特征在底层就拼接起来，喂给模型做联合推理。优点是跨模态的交互信息保留完整，缺点是特征维度爆炸、训练成本高，而且不同模态特征的数值尺度差异大，拼之前要做好归一化，否则某个模态会把另一个模态的信息“冲淡”。

晚期融合更常用在Agent场景里，先用各自的编码器抽特征，在决策层做加权融合。比如我的情感分析Skill里，图片通过CLIP视觉编码器抽出一个特征向量，文本通过文本编码器抽出另一个特征向量，最后把两个向量拼接后丢进一个轻量的分类头，输出情感标签。这种做法计算量小、各模态可以独立优化、也方便对每个模态的结果做错误分析。

时序对齐是另一个必须在上下文工程之前解决的问题。我在视频情感分析的实际踩坑是：视频帧每隔0.5秒抽一帧，音频被切成2秒一个片段，文本转录按照句子打时间戳，三者各自产生了独立的“事件序列”，但时间轴的粒度不一样。直接融合的时候，模型的注意力被错误的对齐关系带偏，明明是同一瞬间的情绪状态，三个模态却指向三个不同时间点。

解决办法是建立统一的时间戳映射表。先选定一个基准时间轴（通常是音频的时间轴，因为它的采样率最高、精度最细），然后把每个视觉事件和文本事件按照最近邻原则映射到最近的音频时间点上。这个对齐表做好之后，再去做跨模态的注意力计算，效果立刻不一样。简单一点说，就是先把三台各走各的时钟校准到同一台标准时钟上，再去谈怎么融合。

3. 上下文工程：从提示词工程到上下文工程

3.1 提示词工程 vs 上下文工程

现在的讨论热点从“提示词工程”转向“上下文工程”，不是概念炒作，而是技术重心在真实转移。提示词工程解决的是“怎么说”的问题，你通过优化指令文本的措辞、结构、示例，让大模型更准确理解意图；但到了Agent和多模态时代，“给什么不做什么”往往比“怎么说”更致命——与其执着于一条完美的Prompt，不如先把喂进去的上下文管理好。

我把上下文工程理解成三层：

• 第一层是上下文内容的选择：系统指令放什么、用户输入放什么、历史记录放多少、Skill工具返回什么。
• 第二层是上下文的格式与结构：图片以原始像素还是以特征形式进入上下文，多模态信息该用url引用还是base64内嵌。
• 第三层是上下文的生命周期：哪些信息需要每次请求都带、哪些可以缓存、哪些用完即弃。

在多模态Skill里，如果三层不管理好，一个图片理解任务的上下文体积可能是纯文本任务的数十倍。同样一个Agent，别人在大模型上下文里只放一条“图片基本描述+用户问题”，你却把整张图片的原始像素和中间层特征全塞进去，效果不一定更好，账单上却要多付好几倍的钱。

3.2 上下文窗口的预算分配与多模态token换算

做上下文工程第一步是把“token预算”这件事量化。很多人对上下文窗口的理解只停留在“总共能装多少token”，但真正重要的是**“每个环节分配多少token”**。我把一个多模态Agent的上下文预算分成四个桶：

• 系统指令桶：固定占比，用来写清楚Agent的角色、能力边界、输出格式、安全约束。这个桶尽量精简，通常控制在总预算的10%以内。
• 会话历史桶：存储与用户的过往对话，需要做滑动窗口，只保留最近N轮。
• 工具结果桶：多模态Skill返回的图像描述、检索结果、情感标签等，这是动态变化的，需要做摘要和精简。
• 当前意图桶：本次用户请求的完整内容和相关的原始输入，这部分最重要，分配的比例应该最大，至少留出50%以上。

借着一张图片的实际体感来说，我在一个8K上下文的Agent里跑多模态情感分析，结构是这样的：系统指令800 token，历史对话1000 token，工具结果摘要600 token，当前输入（图片特征描述+裁剪后的像素块+用户问题）约4300 token，剩下一部分留给生成的输出。这套比例是在多次测试后调出来的，如果历史对话桶太大，图片的理解质量肉眼可见地下降。

多模态token换算的核心规律是：一张224x224的图片经过vision transformer切patch之后，产生的视觉token数量级在几百到一千之间，具体取决于patch size模型配置。14x14的patch配置下大概是256个patch，对应256个视觉token；如果你用更细的patch，token数会上升。音频同样不便宜，我印象里whisper编码器对10秒音频抽取的特征，在LLM里展开后能到一两千个token的量级。所以预处理这一步做得越狠，上下文压力越小。

3.3 压缩与路由：在有限窗口里塞进有效信息

预算定了之后，真正的挑战是“内容塞不下”。多模态场景尤其严重，干货就那么多，但原始输入体量太大，必须压缩。压缩手段我常用三种。

第一种是关键帧提取。视频场景里，与其把每一帧都送进上下文，不如先做一个镜头分割和关键帧筛选，只挑出画面变化最大的帧。我做过一次实验，10分钟的视频抽出来大约60个关键帧，信息覆盖度能达到完整帧序列的85%以上，但上下文体积缩到原来的十分之一。

第二种是语义摘要。把Skill的原始输出先交给一个小参数模型做一次压缩，生成结构化的摘要再进上下文。比如图片检索Skill的默认输出是10条候选结果，每条带200字描述，我让一个3B小模型把这些描述压缩成三条要点，总token从2000降到400。这个过程会损失一些细节，但保住主干信息，对大多数任务来说够用了。

第三种是分层缓存。对于历史会话中已经处理过的多模态内容，我会在第一次完整理解后把结果存进外部向量数据库，后续对话里只引用一个简短的缓存key。这样旧图片不需要再次完整进入上下文，但Agent依然记得这个图片“之前分析过、结论是什么”。

路由策略也是上下文工程里容易被忽视的环节。Agent不应该每次请求都唤醒所有Skill，而是根据用户意图的意图分类结果，动态决定调用哪个多模态Skill、加载哪些上下文。比如用户说“帮我看看这张图里有什么”，那只路由到视觉理解Skill；用户说“从这段视频里找出所有人笑的瞬间”，那才需要路由到视频分析Skill。路由做得好，上下文工程的压力至少减半。

4. 实操：构建一个多模态Skill并接入Agent

4.1 环境准备与依赖清单

下面进入可以直接复现的部分。我以一个图文双模态情感分析Skill为例，目标输入是一张图片加一段短文本，输出是对应情绪的标签和置信度。

先准备环境。我的推荐环境是Python 3.10以上，PyTorch 2.x，CUDA 11.8及以上。核心依赖如下：

pip install torch torchvision pip install open-clip-torch pip install transformers pip install scikit-learn pip install numpy

模型方面，我选用open_clip的ViT-B/32权重，因为它在精度与推理速度之间比较均衡。情感分类头则是一个简单的两层MLP，输入维度就是CLIP文本特征和图像特征的拼接维度。

这里补充一句：不要一上来就上最大的模型。ViT-L/14的视觉特征质量确实更好，但推理显存占用高，在Agent高频调用场景下会让你等到怀疑人生。先用小模型把整个Skill跑通，再根据实际瓶颈决定是否升级。

4.2 特征提取模块与Skill注册实现

特征提取模块是Skill的核心骨架，我把代码整理成下面这样：

import torch import open_clip class MultiModalExtractor: def __init__(self, model_name="ViT-B-32", pretrained="laion2b_s34b_b79k", device="cuda"): self.device = device self.model, _, self.preprocess = open_clip.create_model_and_transforms( model_name, pretrained=pretrained ) self.tokenizer = open_clip.get_tokenizer(model_name) self.model.to(device).eval() def extract_image_features(self, image_tensor: torch.Tensor) -> torch.Tensor: with torch.no_grad(): image_tensor = image_tensor.to(self.device).unsqueeze(0) features = self.model.encode_image(image_tensor) features = features / features.norm(dim=-1, keepdim=True) return features.cpu() def extract_text_features(self, text: str) -> torch.Tensor: with torch.no_grad(): tokens = self.tokenizer([text]).to(self.device) features = self.model.encode_text(tokens) features = features / features.norm(dim=-1, keepdim=True) return features.cpu()

这里有两个细节值得注意。第一个是特征归一化。CLIP的对比学习目标天然需要特征向量在单位球面上比较才有意义，我会对输出的特征向量做L2归一化，否则后面算相似度时数值不稳定。第二个是推理时要包在torch.no_grad()里，这既是省显存也是省时间，Agent的高频调用场景里每一毫秒都值得抠。

Skill的注册层面，我设计了一个轻量的注册表，让Agent能够通过技能名称动态加载模块：

class SkillRegistry: def __init__(self): self.skills = {} def register(self, name: str, skill): self.skills[name] = skill def get(self, name: str): return self.skills[name] def available_skills(self): return list(self.skills.keys()) registry = SkillRegistry()

这样做的目的是把“Skill的调用方”和“Skill的实现方”解耦。Agent不用关心底层是CLIP还是别的模型，只要能通过名字拿到对应的Skill实例就行。后续如果写了音频Skill或者视频Skill，直接注册进去，Agent的调度逻辑完全不用改。这个模式抄作业的价值很高。

4.3 Agent调度与多模态上下文组装

接下来的关键部分是Agent怎么调度这个Skill，以及怎么把多模态结果组装进上下文。

我实现的Agent遵循一个简单的循环：接收用户请求、判断意图、路由到对应Skill、收集输出、把输出整理成指定的上下文格式、调用LLM生成最终回复。代码如下：

class SimpleAgent: def __init__(self, registry, llm): self.registry = registry self.llm = llm self.conversation_history = [] self.max_history_tokens = 1000 def handle_request(self, user_text: str, image_tensor: torch.Tensor): # 1. 路由：简单判断是否包含图片理解需求 if image_tensor is not None: skill = self.registry.get("multimodal_sentiment") skill_result = skill.run(image_tensor, user_text) else: skill_result = "no multimodal input" # 2. 组装多模态上下文 context_prompt = self._build_context(user_text, skill_result) # 3. 调用LLM生成回复 response = self.llm.chat(context_prompt) self._update_history(user_text, response) return response def _build_context(self, user_text, skill_result): # 预算分配：系统指令800 token + 最近历史1000 + 本轮上下文 system_prompt = "你是多模态情感分析助手，基于图片与文本输出情绪判断。" recent_history = self._sliding_window_history() # 多模态信息要转成密集摘要形式，不是原始像素 multimodal_block = ( f"[多模态分析结果]\n" f"图片情感特征: {skill_result['image_emotion']}\n" f"文本情感特征: {skill_result['text_emotion']}\n" f"融合判断: {skill_result['fused_emotion']} " f"(置信度: {skill_result['confidence']:.2f})" ) return system_prompt + "\n" + recent_history + "\n" + multimodal_block + "\n用户: " + user_text

这段代码里最关键的一点是上下文的组装方式。我没有把原图塞给LLM，而是先让Skill把图片转成一条精简的情感特征描述。原始图片可能对应几百个视觉token，但这条描述文本只有几十个token，信息流密度反而更高。这体现的就是上下文工程的核心思路：让LLM只接触它真正需要的处理信号，而不是给它甩一堆原始的多模态数据。

_sliding_window_history是另一个不能省的功能。我维护一个双端的deque，每次新对话追加一条记录，当历史token数超过1000时，从最老的记录开始弹出。这样历史对话桶的占用保持恒定，不会侵蚀当前输入桶的预算。

4.4 演示效果与参数开销实测

用上面这套流程，我实测了一个真实的案例：给Agent一张阴天下雨的行人照片，加一句文本“唉，今天又要加班到很晚”。图像情感特征模型判断偏“消极”，文本情感特征也偏“消极”，融合后的输出是“消极，置信度0.87”。Agent的最终回复是：“这个场景下图像和文本传递的情绪高度一致，我判断你当前的情绪状态偏向消极，是否需要聊聊出现的原因？”

整个请求的耗时构成是这样的：图像特征提取约68ms（GPU），文本特征提取约12ms，MLP融合约1ms，LLM生成约900ms。相比直接把原图喂给一个图文大模型动辄几秒钟的推理，这个Skill的响应速度要快得多——代价是损失了模型对画面细节的深层理解，但对于情感标签这个任务，这样的取舍完全划算。

我也顺带测过上下文体积：同样的请求如果用原始的“图片像素+完整LLM推理”方案，一次请求大约消耗1100个视觉token加500个文本token；用我的Skill方案，多模态信息压缩成一段不到100个token的摘要，总token消耗降了一个量级。在服务多用户并发的场景里，这个差距会直接反映在成本和延迟指标上。

5. 常见问题与排查技巧实录

5.1 上下文溢出与多模态信息被截断

表现：Agent在第二轮之后突然忘记图片里的关键信息，或者回复质量明显下降。

排查路径：先检查上下文里实际装入的内容，打印出每次请求发送给LLM的prompt，看多模态摘要块是否被截断了。我见过一个案例，历史窗口的滑动逻辑写错了方向，旧对话没被及时弹出，导致当前输入只装了一半。

解决办法：多模态摘要块固定放在系统指令后面、历史记录前面，这样可以保证在截断发生时，多模态信息优先保留。另外，务必对每个模块的长度做断言，一旦超预算就触发摘要压缩，而不是硬截断。

5.2 特征缓存失效导致结果陈旧

表现：同一个图片文件，第一天分析是“正向”，第二天分析变成“负向”，而且模型没换。

排查路径：检查特征文件是否被错误复用。最常见的原因是图片文件被覆盖更新，但文件名没变，特征缓存命中后返回了旧特征。另一个原因是模型权重更新后，特征文件没有同步重建。

解决办法：缓存key不能只用文件名，要把文件修改时间（mtime）和文件大小一起作为缓存key的一部分。模型版本变化时，所有旧特征文件要标记为失效，可以通过我在前面提到的版本hash文件名方案来规避。

5.3 多模态融合结果比单模态更差

表现：图文分开看都挺准，融合之后反而判错。

排查路径：先跑一次“模态归因分析”——分别记录只用图像特征、只用文本特征、融合特征的准确率，看问题出在哪。我遇到的情况往往是图像和文本的情绪方向不一致（比如图片开心但文本抱怨），等权重加权时没有考虑一致性，导致融合向量方向混乱。

解决办法：融合之前先算一下两个模态特征的余弦相似度。如果相似度低，说明模态之间存在冲突，这时候应该回退到置信度更高的那个单模态结果，或者让LLM在回复里明示“图片来源的情绪和文本来源的情绪存在冲突”。加一个冲突阀值，能显著减少融合翻车的比例。

5.4 问题速查表

这张表基本上覆盖了我踩过的坑里最典型的几个。如果你遇到的不在上述之列，我强烈建议从“拆开来看”入手——先把多模态Skill的感知层、语义层、输出层分别跑一遍，看看哪一层的结果不合理，逐层排查比黑盒式猜测要快得多。

6. 这个方向还能怎么扩展

前面聊完了Skill的实现和上下文工程，再分享一些我后续计划做的事情，给你做个参考。

第一个方向是把多个多模态Skill组合成一条流水线。现在的实现里，视觉Skill只负责输出情感标签，但如果用户问的是“这个视频里的笑点出现在哪些时间点”，就需要视频理解Skill先做关键帧抽取，音频Skill再做语气分析，最后汇总成时间线。Skill之间的协作协议值得提前设计好。

第二个方向是评估集的建设。多模态Skill的评测比文本Skill复杂得多，因为正确答案往往不是唯一的。我打算整理一个小规模的图文情绪评估集，分成“上下文完整”、“上下文被压缩”、“模态信息冲突”三档，分别测试Skill在不同压力下的表现。没有靠谱的评估集，你就永远不知道上下文工程做到什么程度才算合格。

第三个方向是把上下文工程的预算控制做成动态自适应的。现在的比例是拍脑袋定死的，后面想尝试根据每轮的实际token消耗来动态调整四个桶的占比，比如在历史对话变长时自动压缩得更狠，在图片信息密度高时自动给当前输入桶更多空间。这个方向做出来之后，Agent的上下文管理才算是真正有了一点智能的味道。

这些扩展方向短期内不会全部落地，但至少说明多模态Skill和上下文工程这个组合，往上走的空间还很充足。希望这篇的实操内容能帮你少踩几个坑，尤其是我在前面反复强调的特征缓存、预算分配、模态冲突这三个点，抓好这三个，你的多模态Agent水平就能超过大部分人。