多模态Agent Skills上下文工程：特征对齐与Token预算管理

做过一段时间带多模态输入的 Agent Skills 落地之后，我有一个很直接的体会：真正的难点往往不在“技能内部应该怎么回答”，而在“多模态信息以什么形式、什么顺序、多少体量进入技能上下文”。传统提示词工程关心的是“话术怎么组织”，但多模态Skill加进来的图像、音频、传感器时序、视频帧，逼着我们把注意力转移到上下文工程上。这篇文章会围绕Agent Skills框架，梳理多模态处理与上下文组装的实操路径：从特征抽取、时序对齐到token预算分配，再穿插一个真实的多模态情感分析踩坑案例。适合正在为Agent设计多模态技能、或者被上下文混乱问题折磨的开发者阅读。

1. 从提示词工程到上下文工程：多模态技能为何重新定义边界

1.1 提示词工程管不了多模态

在纯文本Agent时代，“提示词工程”的核心是把问题讲清楚。系统指令怎么写、Few-shot示例放几个、否定词如何措辞，这些确实能显著改变模型输出。但纯粹文本输入只是大模型最舒服的一种形态，一旦技能要接收一张设计图纸、一帧工业摄像头画面或者一段环境音频，事情就完全不一样了。

原因很直白：模型做不到“凭文本理解像素”。一张1280乘以720的RGB图像，落到模型视角里是几十万甚至上百万个数值，即便视觉编码器压缩之后，也仍然是一大块与文本完全不同分布的信息。音频切片更特殊，它既没有自然语言那种词汇边界，也没有图像那种空间结构，不经过ASR或者音频编码器，模型几乎无法直接消费。于是“把问题说清楚”变成“把输入变成模型能消化的信息结构”，这就是上下文工程出现的背景。

我自己的经验是，提示词工程仍旧重要，但它从主角变成了配角。多模态Skill的成败，首先取决于你给模型装配了什么上下文，其次才取决于你怎么在上下文中措辞。一份把“图像描述”“音频转录”“历史属性表”乱序堆叠的上下文，即便提示词打磨得再精致，模型也容易在里面迷失重点。

1.2 上下文工程的三层操作

把多模态技能做好，我习惯把上下文工程拆成三层操作，每层都有独立决策点。

第一层是内容选择。不是所有多模态数据都有资格进上下文。5分钟的视频，没必要把每一帧都塞进去；30秒的音频，也不是所有段落都要转录。我们要做的是抽帧、切片、过滤无效信号，只保留包含任务关键信息的片段。这个阶段常常被忽略，大家更愿意在模型侧想办法，实际上在输入端少放垃圾，比在模型侧做排除法有效得多。

第二层是表达转换。选中的内容用什么形态表示，直接决定模型的理解难度。这里有三条路线可以选：

• 路线A，原生多模态直读：直接把图像、音频交给原生多模态大模型。优点是信息损失最小，缺点是token消耗高、延迟大，而且很多上下文工程技巧无法施加在这类输入上。
• 路线B，外挂模型转文本：用视觉模型生成图像描述，用ASR生成语音转录，再拼接成文本上下文。优点是可控性高，适合结构化输出；缺点是有信息损耗，描述不出来的细节就丢了。
• 路线C，特征向量化检索：用CLIP这类模型把不同模态映射到同一个向量空间，存入特征文件，任务到来时先检索相关性最高的片段，再把片段转成上下文。

第三层是装配策略。信息选定、形态确定之后，还要决定排列顺序和层级。多项研究都表明，模型对上下文开头和结尾的内容更敏感，对中段内容容易“一带而过”。所以核心约束、输出格式、必须遵守的硬规则要放在上下文两端，检索到的支撑细节放在中段，而且要按重要性从高到低排布。这不是玄学，是注意力机制带来的工程结论。

2. 技能内部的上下文协议：把多模态信息接口化

2.1 给多模态Skill设计输入槽位

Agent Skills真正有工程价值的点，在于“可复用”和“可被调度”。多模态技能如果没有明确的输入协议，调度器根本不知道这个技能能不能处理当前任务。所以我在项目里会给每个多模态技能定义输入槽位schema，声明允许的模态类型、数量上限和时长限制。

下面是一个情感评估技能的真实schema简化版本：

{ "skill_name": "multimodal_emotion_assessment", "version": "0.2", "input_slots": [ { "name": "transcript", "type": "text", "required": true, "description": "对话转写文本" }, { "name": "frame_paths", "type": "image_list", "required": false, "max_count": 8, "description": "关键帧图片路径列表" }, { "name": "audio_segment", "type": "audio_segment", "required": false, "max_seconds": 30, "description": "待分析的音频切片" }, { "name": "attribute_table", "type": "table", "required": false, "description": "说话人属性与历史状态" } ], "context_policy": { "compression": "hierarchical", "retrieval_key": "clip_embedding", "time_alignment": "timestamp_tolerant" } }

定义这样的结构有两个直接收益。一是上层调度器可以精确判断“目前收集到的多模态数据是否匹配这个技能”，二是在上下文组装前，技能内部可以先执行一轮合规性校验，防止把格式错误的数据交给模型。很多线上多模态技能输出不稳定，查到最后都是输入校验缺失，比如图片路径为空、音频切片时长超限，导致模型看到一堆残缺上下文。

2.2 上下文首尾块与中间检索块

有了输入槽位，下一步就是组装策略。我这里用“首尾块固定、中段按检索填充”的方式来组织上下文。

首块放不可动摇的内容：技能目标、任务约束、输出JSON结构。这部分必须完整、稳定，不随输入变化而重写。尾块放“当前输入摘要”，包括模态数量、各模态对应的文本总和，以及硬性要求，比如“如果音频与文本时间戳不一致，请优先采用文本时间戳”。中间块才是检索出来的多模态片段描述。

这样做的原因还是注意力分布。如果指令被淹没在大量图片描述和音频转录中间，模型很可能在中途丢失约束。而把约束固定在两端，即使中间做了上下文截断，核心规则也不会被裁掉。这个细节，几乎每次都能在效果评测里拉开差距。

3. 多模态特征的对齐与统一表达

3.1 为什么需要统一表达空间

多模态任务麻烦的地方，在于不同模态的信息密度和语义粒度不一致。文本说“画面中有一把雨伞”，图像里可能还包括雨伞颜色、纹理、周围人行道积水等大量文本没提到的细节。如果只是简单拼接文本描述，模型很难判断哪些信息可靠，哪些信息只是辅助。

统一表达空间是解决这个问题的常用方案。以CLIP为代表的图文对齐模型，把图像和文本映射到同一个向量空间，让“雨伞图片”和“雨伞文字描述”在空间距离上接近。这样技能内部就可以用余弦相似度计算输入与任务的关联程度，先检索出真正相关的片段，再组装上下文。换句话说，多模态信息不是一股脑全塞给模型，而是先做一轮“相关性排序”。这就像你同时拿到了几份不同语言的说明书，先统一翻译成一份索引目录，再找最相关的几页放进正文。

3.2 特征文件与缓存设计

在实际业务中，特征抽取是计算密集操作。每一帧图像过CLIP视觉编码器，单次并不贵，但数量一多，实时推理就会立刻拖慢整个Agent的响应速度。我的做法是离线预处理：把所有候选图像、视频帧先行抽取特征，保存为独立特征文件，并建立缓存索引。

一份特征文件通常包含三块内容：

• 模态ID与来源路径，用于追溯原始数据
• 特征向量本体，一般是float数组，维度视模型而定
• 元信息，包括时间戳、采集位置、清晰度标记等

当Agent收到多模态请求，技能先读取对应特征文件，通过向量检索选出Top-K相关片段，再把这些片段的描述文本组装进上下文。这样实时请求中就不再包含大矩阵计算，延迟主要发生在向量检索阶段。配合向量数据库或者简单的numpy近似检索，可以在几十毫秒内完成候选筛选。

3.3 时序对齐与“多模态记忆是否包含4D”

多模态任务里最隐蔽的坑，就是时间轴不一致。文本转录里的一句话，可能对应视频第10秒到第12秒，而模型处理时如果不知道这个边界，就会把这句话和完全无关的画面绑定在一起。所以技能内部必须做时序对齐。我的实操经验是三条规则：

第一，统一时间戳精度。文本、图像、音频切片都必须用同一时间基准，精确到毫秒级。如果ASR输出偏移，先做一次整体漂移校正。

第二，设计一个容差窗口。比如“当前文本片段只与时间戳落在±2秒范围内的帧关联”，超过窗口的帧不进上下文。容差窗口太大会引入噪声，太小会丢失内容，需要结合数据特性调整。

第三，建立回退策略。当对齐置信度不足时，宁可丢弃强对齐要求，也要保证主模态的完整性。比如音频与文本对不上，那就退化为“文本+全局视觉描述”，而不是强行拼接出错误的时间对应关系。

这引出一个经常在社区被问到的概念：多模态记忆是否包括4D？如果空间加时间一起算作第四维，那答案是肯定的。但在工程实现里，我不会把4D当成一个整体张量去存，而是拆成“空间特征+时间戳索引”。每个片段携带起始时间和结束时间，检索时先按时间窗口过滤，再按向量相似度排序。这个设计比单纯维护一个4D张量更灵活，也更容易与现有检索链路集成。

4. 上下文预算管理：为多模态请求分配token配额

4.1 token消耗到底怎么算

多模态上下文和纯文本上下文最大的区别，是体量不可控。一段5000字的文本，token数基本可预估；但一个图像列表、一段音频切片，token消耗取决于编码器、分辨率、时长和模型版本。如果技能层不做预算管理，上下文很容易在不知不觉中溢出，然后触发截断策略，把重要信息拦在窗外。

我这里有一个粗略的估算表，具体数值会随模型变化，但量级可以用于预算规划：

拿到这张预算表，实际评估就简单了。比如一个技能输入包含8帧图像、30秒音频转录和一段历史属性表，粗略估算已经超过1500 token，再加上系统指令和输出约束，很可能逼近窗口上限。这时就必须压缩。

4.2 分级压缩策略

压缩不是简单裁剪，而是分层降级。我给技能内部定义了三个压缩层级：

• L0原始细节：保留完整的图像描述、完整转录、全部属性字段。用于对细粒度信息有高要求的任务。
• L1摘要压缩：图像只保留关键物体与空间关系，转录只保留主谓宾和高置信情绪词，属性表只保留与当前任务相关的字段。
• L2关键词级：只输出模态类型、核心实体、情感极性三个维度，其他全部丢弃。

技能运行时会根据当前任务类型和上下文剩余长度，自动选择合适的层级。任务要求“识别图纸上的标注文字”，那图像必须走L0；任务要求“判断这段对话里用户的整体情绪倾向”，图像可以走L1，音频转录甚至可以走L1，把预算留给情绪关键词。

4.3 截断时永远先保护指令

无论预算怎么压缩，总有可能遇到极端输入把窗口占满。此时截断顺序要有明确规则。我的原则是：先裁检索结果片段，再裁历史属性表，再裁音频转录，最后裁图像描述，系统指令与当前输入摘要绝对不裁。

原因不难理解。系统指令是底线规则，裁掉之后模型可能连输出格式都保不住。当前输入摘要是本次请求的核心目的，裁掉之后任务本身就失效了。而检索结果和历史属性属于辅助支撑，缺失时模型仍然可以基于核心输入给出结果，只是细节会粗糙一些。这个优先级顺序，建议写死在技能上下文策略里，不要每次现场判断。

5. 一次真实踩坑：多模态情感分析中的上下文破碎

5.1 症状：情感标签准确率直线下降

有一次我在给一个多模态情感分析Agent技能做优化，输入是对话转写文本、视频关键帧和音频切片，输出是情感极性标签。初版上线后，文本单模态准确率在可接受范围内，但一旦加入关键帧和音频，准确率反而显著下降。这个反直觉的结果很值得复盘。

当时上下文组装顺序是“文本转录+图像描述+音频转录+情感标签示例”。从排版看，信息一个不少，结构也算清晰。但真实效果是模型经常输出自相矛盾的结论，比如文本说“很满意”，图像里有皱眉动作，模型最终给出负面情感。单独看每个模态都没错，合在一起却拼出了一个错误结论。

5.2 根因：时间轴不一致导致上下文错位

逐段排查后，发现问题出在时间对齐，而不是模型能力。ASR服务对这段对话的转写带有固定偏移，某句话标在了第10秒，实际发音发生在第8秒；而关键帧抽取的时间戳来自另一套处理管线，两套时间基准差了近3秒。于是模型看到的“文本第10秒的正面词”与“图像第8秒的负面表情”被强行配成了一对，信息层面出现了矛盾。

更深一层，是技能上下文里没有声明时间戳边界。模型无从知道哪个片段该配哪个片段，只能把几个模态全部视为围绕同一时刻。这就是典型的多模态上下文破碎：每个片段本身没问题，但时间关系断裂后，上下文整体语义就失真了。

5.3 修复：容差窗口与模态优先回退

修复分三步。第一步，在文本片段和视频帧描述中统一加入时间戳前缀，例如“[t=10.2s]”。第二步，在技能指令里写明对齐规则：文本片段只与时间差小于2秒的帧关联，超出容差窗口的帧视为噪声，不参与当前片段推理。第三步，增加模态回退逻辑：当音频文本与视觉帧时间戳无法对齐时，默认丢弃关键帧细节，保留文本在情感判断中的优先权。

修复前后对比非常明显：

多模态结合的准确率不仅超过了纯文本，还因为去掉了冗余帧，token消耗也降低了四分之一。这个案例让我确信，多模态技能优化的第一杠杆不是换更强的模型，而是上下文结构是否真正做到对齐与收敛。

6. 经验沉淀与工具链参考

6.1 多模态技能不是越全越好

我在项目里逐渐形成了一条原则：技能处理哪种模态，应当由任务目标倒推，而不是由数据可得性决定。如果任务本身是文本语义判断，音频和图像即使存在，也不必全部编进上下文。增加模态意味着增加对齐难度和token消耗，除非信息增量足以抵消成本，否则保持克制更明智。

以Agent Skills的调度场景为例，一个优秀的多模态技能应该像一把专用工具，而不是瑞士军刀。收到图像处理任务，调用专门处理图像的技能；收到语音任务，调用带ASR转写和情绪关键词提取的技能。让同一个技能同时处理所有模态，会变成“什么都处理，什么都处理不精”。

6.2 上下文构造链路要可测试

多模态技能和纯文本技能在调试方式上有一个显著差异：纯文本技能改提示词就能看到变化，多模态技能则要验证中间数据。图像描述是否准确、音频转录是否漏词、时间戳是否一致，这些都可能干扰最终结果。

所以我会把每个多模态技能的上下文构造过程拆成独立函数，并为每一步设计单元测试。比如模拟一段“转录文本包含皱眉帧”的输入，断言组装后的上下文中是否出现时间戳并列结构。有了这层保障，线上效果波动时就能快速定位是特征抽取问题，还是装配顺序问题。

6.3 常用工具链参考

以下组合在我几个项目里都验证过稳定性，供参考：

• FFmpeg，负责视频抽帧、音频切片、格式统一
• Whisper或同类ASR，负责音频转文本与词级时间戳
• CLIP或SigLIP，负责图像/文本统一向量化与检索排序
• 向量检索件（如轻量实现），负责特征文件索引与相似度召回
• 缓存数据库，负责存储特征文件与中间描述文本，重复请求直接命中

整个链路排下来，最值得花时间打磨的其实不是模型选择，而是“特征文件怎么命名、时间戳怎么存储、检索结果怎么转上下文”这几个约定俗成的细节。把这些约定固定下来，技能的可复用性会高很多。

我个人体会是，多模态Skill的复杂度是藏不住的，它会把上下文工程的每个缺陷都放大。尽早定义输入协议、统一时间基准、建立压缩层级，比临时调提示词要可靠得多。如果你正在做类似的多模态Agent技能，建议先把上下文组装链路画清楚，再考虑接更多模态源，顺序颠倒的话，大概率会掉进同一个坑里。