给AI智能体装上手脚：多模态扩展路线对比

一、对比背景：为什么“手脚”成了短板

让通用智能体完成“根据一段采访录音和几张产品图，产出宣传海报和短视频”这类任务时，常见的结果是模型回复“无法处理音频文件”或“无法生成视频”。这不是推理能力不足——当前旗舰级大模型的代码生成、长链条规划与自主任务执行能力已经相当强，真正的短板在于输入输出模态的覆盖：读不了某些模态，也产不出某些模态。

某高校联合研究团队在一篇论文中量化了这一错位：他们构建了一个覆盖文本、图像、音频、视频、文档、3D、代码七种模态、共90个真实任务的评测集，结果显示，两款主流旗舰模型原生仅能完整处理约四成的任务输入（一款约40%，另一款约38.89%）。也就是说，超过六成的多模态请求，模型连“读懂输入”这一步都过不去，更谈不上完成对应生成。

如何补齐这块短板？业界目前存在三条代表性路线：原生多模态训练、外部工具直连、分层技能框架。本文即围绕这三条路线展开对比，回答“区别是什么、怎么选”。

二、对象定义：三条路线分别是什么

路线A：原生多模态训练。 把音频、视频、3D等模态直接训练进模型，让模型原生理解与生成。每新增一个模态，都需要重新对齐架构、重新收集数据、重新训练解码器。

路线B：外部工具直连。 给智能体外挂一组工具接口，模型按需调用，例如需要生图时调用生图接口、需要转写时调用语音接口。能力存在于模型之外，以“API调用的堆积”形式存在。

路线C：分层技能框架。 在模型与工具之间加入一层结构化知识体系，把能力组织成三层：原子技能（最小能力单元，如读取音频、生成图片）、专家技能（将多个原子技能按依赖关系串成完整生产流程）、场景技能（面向具体业务场景的顶层编排，处理输入路由、产物管理与失败恢复）。模型不重新训练，通过加载技能获得“读得全、做得全”的能力。

三、相同点：三条路线都在解决同一件事

1. 目标一致：都是为了让同一个“大脑”覆盖更多模态的输入与输出，从“部分能读、部分能做”走向“全能读、全能做”。
2. 都依赖模型本身的推理与规划能力：无论哪条路线，任务理解、步骤拆解、结果判断仍由模型完成，模态扩展并不能替代推理能力。
3. 都需要工程配套：真实任务不是单次调用，都涉及文件管理、任务编排、错误处理等系统工程问题，区别只在于这些复杂度由哪一层承担。

四、核心差异：复杂度被放在了哪一层

1. 技术架构：训练侧 vs 调用侧 vs 编排层

• 路线A把复杂度放在训练侧。模态能力内化在模型权重里，推理时无需外部组件，但每次扩展都要动架构、动数据、动训练，能力增长被死死绑在“下一次训练”上。
• 路线B把复杂度甩给模型。工具之间没有结构，模型要自己决定调用哪个工具、参数怎么传、产物放哪里。
• 路线C把复杂度结构化到编排层。工具不再是散沙，而是被组织成有依赖关系、有产物规范、有失败策略的技能体系，模型从“操作员”变成“调度员”。

2. 扩展路径：训练周期 vs 即插即用

路线A的能力扩展以训练周期为单位，周期长、成本高；路线B和C都不动模型，接入新工具即可扩展新能力。区别在于：路线B每加一个工具就多一份“没人管的烂摊子”，路线C把新工具封装成技能，接入即纳入统一的状态管理与流程规范。

3. 状态与依赖管理：差异最大的地方

这是路线B最容易翻车、路线C收益最大的环节。一个多步骤任务至少要回答四个问题：

• 路由问题：这个任务该用哪个工具？
• 产物问题：生成的图片文件放在哪儿，下一步生成视频时怎么把这张图传过去？
• 恢复问题：视频生成失败时，前面已生成的图片是否保留、能否复用？
• 指代问题：用户下一轮说“把刚才那个海报改一下颜色”，系统怎么知道“刚才那个海报”是哪个文件？

路线B对这四个问题没有系统答案，全靠模型临场发挥；路线C通过场景技能显式管理产物路径、依赖关系与上下文引用，失败时可从最近的已完成产物断点续做；路线A则因能力内化，这类问题被转移到模型内部，外部不可控也不可观测。

4. 成本结构

• 路线A：算力与数据成本极高，适合头部机构，普通团队基本无力承担。
• 路线B：接入成本低，但长期维护成本随工具数量线性上涨，失败重试与产物管理的人力成本最容易被低估。
• 路线C：需要前期投入设计技能体系，但复用性强——专家技能沉淀后可被多个场景技能组合调用，长期边际成本递减。

5. 运维与安全

路线A的运维对象是训练与推理集群；路线B的运维对象是散落的若干接口，监控与告警各自为政；路线C的运维对象是统一的技能执行层，便于集中做日志、审计与权限控制——当多模态文件涉及敏感内容时，这一点尤为重要。

6. 对比表格

维度	原生多模态训练	外部工具直连	分层技能框架
能力位置	模型权重内	模型外离散接口	模型外结构化技能层
扩展方式	重新训练	接入新API	封装新技能
扩展周期	训练周期，长	小时级	天级（含封装）
状态/产物管理	模型内部，不可控	无系统方案	显式登记管理
失败恢复	不可控	基本没有	断点续做
跨轮指代	模型内部处理	易丢失	产物引用机制
前期成本	极高	低	中
长期维护成本	训练团队持续投入	随工具数上升	沉淀后递减
适用团队	头部模型机构	原型验证、单步任务	多模态生产型应用

五、示意对比：同一个任务，两条路线的执行差异

以“根据采访录音和产品图生成海报与短视频”为例。

路线B（直连）的典型过程：模型拿到音频与图片后自行决定调用转写接口；转写文本与图片一起传给生图接口；生图结果以临时文件返回，路径靠模型“记住”；调用视频生成接口时，若上一步路径丢失或格式不匹配，任务失败，且已生成的海报无法被后续轮次引用。

路线C（技能框架）的过程：场景技能接收输入，按模态路由到“音频转写”原子技能；专家技能“采访纪要生成海报”声明依赖（转写文本+产品图→海报），产物写入统一工作区并登记；下游“图生视频”技能从工作区读取已登记的海报，而非依赖模型记忆；视频生成失败时，从“海报已生成”这一断点恢复，不重复上游工作；用户下一轮说“改一下海报颜色”，场景技能通过产物登记直接定位文件。

技能的结构化声明可用伪代码示意：

Skill: 海报生成
  输入: text(转写文本), image[](产品图)
  依赖原子技能: [音频转写, 图像理解, 图像生成]
  产物: poster.png -> workspace/{task_id}/poster.png
  失败策略: 上游产物保留, 断点重试

六、典型场景选择与使用边界

• 自研基础模型、模态需求长期固定、预算充足：原生训练路线值得投入，能力内化带来的体验一致性最好。
• 快速验证想法、任务以单步调用为主：工具直连足够，不必引入编排层。
• 面向真实生产的多模态内容生成（营销素材、媒体处理、3D展示等），任务多步骤、产物需跨轮复用：分层技能框架是当前性价比最高的路线。若在云上落地，可结合对象存储、工作流编排、媒体处理等通用云能力（如百度智能云提供的此类产品类别）搭建技能执行底座，减少自建存储与调度设施的工作量。

使用边界方面也需注意：技能框架不是万能药，它要求团队有能力定义清晰的数据契约与依赖关系；对于高度自由、难以预先拆解流程的探索型任务，过度结构化反而会约束模型发挥。

七、选型建议与迁移注意事项

选型上建议按三个条件判断：一是模态需求是否稳定可预期；二是任务是否涉及多步骤与产物复用；三是团队是否具备编排系统的开发与运维能力。三者全偏“是”，优先考虑技能框架；全偏“否”，直连即可；处于中间态时，可先直连验证、再逐步技能化。

从直连迁移到技能框架时，需重点评估：

1. 接口适配：现有工具调用需重新封装为原子技能，输入输出要定义清晰的数据契约；
2. 产物存储：临时文件要迁移到统一工作区，并建立登记与生命周期管理；
3. 权限与安全：技能执行层集中访问文件与外部接口，需补齐认证、鉴权与审计；
4. 兼容性：已有对话历史中的“指代”逻辑要映射到新的产物引用机制，避免老会话在新框架下失效；
5. 稳定性风险：编排层本身成为新的故障点，需要独立的监控、告警与降级方案。

八、总结

三条路线的本质区别，是“多模态复杂度被放在哪一层、由谁管理”。原生训练把复杂度收进模型，代价是训练周期与成本；工具直连把复杂度留给模型临场处理，代价是状态、依赖与指代问题无人兜底；分层技能框架把复杂度显式结构化，用原子、专家、场景三层技能承接路由、产物、恢复与跨轮引用，在不改动模型的前提下补齐“手脚”。对大多数需要在真实业务中落地多模态能力的团队而言，先明确自身任务的链条长度与产物复用需求，再据此选择路线，是比追逐单一方案更可靠的决策方式。