前言不多说直接进正题。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之前必须定一个技术底座这个选择直接决定了后面所有工作的复杂度。**CLIPContrastive 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如果你用更细的patchtoken数会上升。音频同样不便宜我印象里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并接入Agent4.1 环境准备与依赖清单下面进入可以直接复现的部分。我以一个图文双模态情感分析Skill为例目标输入是一张图片加一段短文本输出是对应情绪的标签和置信度。先准备环境。我的推荐环境是Python 3.10以上PyTorch 2.xCUDA 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_nameViT-B-32, pretrainedlaion2b_s34b_b79k, devicecuda): self.device device self.model, _, self.preprocess open_clip.create_model_and_transforms( model_name, pretrainedpretrained ) 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, keepdimTrue) 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, keepdimTrue) 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的最终回复是“这个场景下图像和文本传递的情绪高度一致我判断你当前的情绪状态偏向消极是否需要聊聊出现的原因”整个请求的耗时构成是这样的图像特征提取约68msGPU文本特征提取约12msMLP融合约1msLLM生成约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 问题速查表症状可能原因快速解决上下文2轮后失效历史记录预算过大或滑动窗口写错检查prompt组装设置硬性预算上限推理显存溢出多模态特征未降维或批量太大单样本逐条推理特征提前缓存特征相似度不区分缺少L2归一化特征向量输出后立即归一化图片理解严重走偏视觉编码器不适合该领域换微调过的编码器或加领域数据融合结果不如单模态模态间冲突未处理引入冲突检测与回退机制接口响应越来越慢特征文件未生效仍在重复计算补缓存核对缓存key策略这张表基本上覆盖了我踩过的坑里最典型的几个。如果你遇到的不在上述之列我强烈建议从“拆开来看”入手——先把多模态Skill的感知层、语义层、输出层分别跑一遍看看哪一层的结果不合理逐层排查比黑盒式猜测要快得多。6. 这个方向还能怎么扩展前面聊完了Skill的实现和上下文工程再分享一些我后续计划做的事情给你做个参考。第一个方向是把多个多模态Skill组合成一条流水线。现在的实现里视觉Skill只负责输出情感标签但如果用户问的是“这个视频里的笑点出现在哪些时间点”就需要视频理解Skill先做关键帧抽取音频Skill再做语气分析最后汇总成时间线。Skill之间的协作协议值得提前设计好。第二个方向是评估集的建设。多模态Skill的评测比文本Skill复杂得多因为正确答案往往不是唯一的。我打算整理一个小规模的图文情绪评估集分成“上下文完整”、“上下文被压缩”、“模态信息冲突”三档分别测试Skill在不同压力下的表现。没有靠谱的评估集你就永远不知道上下文工程做到什么程度才算合格。第三个方向是把上下文工程的预算控制做成动态自适应的。现在的比例是拍脑袋定死的后面想尝试根据每轮的实际token消耗来动态调整四个桶的占比比如在历史对话变长时自动压缩得更狠在图片信息密度高时自动给当前输入桶更多空间。这个方向做出来之后Agent的上下文管理才算是真正有了一点智能的味道。这些扩展方向短期内不会全部落地但至少说明多模态Skill和上下文工程这个组合往上走的空间还很充足。希望这篇的实操内容能帮你少踩几个坑尤其是我在前面反复强调的特征缓存、预算分配、模态冲突这三个点抓好这三个你的多模态Agent水平就能超过大部分人。