先问你一个问题。
你有没有遇到过这种情况：让Claude或者GPT帮你处理一个任务，比如"根据这段采访录音和几张产品图，帮我做一份宣传海报和一个短视频"，结果它告诉你,"抱歉，我无法处理音频文件",或者"我无法生成视频"?
这不是模型不够聪明。GPT-5.6 Sol和Claude Sonnet 5这些顶级模型，推理能力已经强到能写代码、能做长链条规划、能自主执行复杂任务。问题出在另一个地方：它们的"手脚"跟不上"脑子"。
这篇来自新加坡国立大学和牛津大学团队的论文，就是在解决这个"脑子很强，手脚很弱"的错位问题。他们给这些通用智能体装上了一整套可插拔的"生产能力"，让它不用重新训练，就能听音频、看视频、读3D模型、生成海报、剪辑视频、写代码建网页。这套系统叫Omni-IO Skills。
先说说这事到底难在哪
你可能觉得，模型不会处理某种模态，那就给它接一个工具不就行了？现实没这么简单。
论文里提了两条现有的路，但都走不通。第一条路是把更多模态直接塞进模型里训练，让模型原生理解音频、视频、3D。这条路的代价极高，每加一个模态就要重新对齐架构、重新收集数据、重新训练解码器，模型的能力增长被死死绑在了"下一次训练"上。
第二条路是给智能体接一堆外部工具，让它按需调用。这条路听起来轻巧，但真正麻烦的不是"接工具"这个动作本身，而是接完之后一系列没人管的烂摊子:哪个任务该用哪个工具？生成图片之后，图片文件放在哪儿，下一步生成视频的时候怎么把这张图传过去？如果生成视频失败了，前面辛苦生成的图片是不是就白费了？用户下一轮对话说"把刚才那个海报改一下颜色"，系统要怎么知道"刚才那个海报"是哪个文件？
这些问题，都不是"接一个API"能解决的。它们本质上是编排问题、依赖管理问题、状态管理问题。
论文里给出了一组很扎心的数据。在一个叫UniM-90的测试集上（涵盖文本、图像、音频、视频、文档、3D、代码七种模态的90个真实任务），GPT-5.6 Sol原生只能完整处理40%的任务输入，Claude Sonnet 5更低，只有38.89%。也就是说，超过六成的多模态请求，这两个顶级智能体连"读懂输入"这一步都过不去，更别提生成对应的输出了。
这就是这篇论文要啃的骨头：怎么在不碰模型一根汗毛的前提下，让它从"读得懂一部分、做得出一部分"变成"全都能读、全都能做"。
Skill不是插件，是分层的"生产流程手册"
Omni-IO Skills的核心设计是一套叫Skills的分层知识体系，一共分三层：原子技能、专家技能、场景技能。
原子技能*：最小的可独立执行单元，比如"生成一张图"、"理解一段视频"、"合成一段语音"，一个技能对应一个具体操作。
这个分层设计不是拍脑袋想出来的。你可以这样理解它:如果你去请一个装修队，装修队里既有专门贴瓷砖的工人（对应原子技能），也有能独立完成"整个厨房翻新"的项目负责人（对应专家技能），还有能统筹"整套房子装修，包括厨房、卫生间、客厅一起弄"的总包（对应场景技能）。
如果没有这三层区分会怎样？你会发现，简单任务和复杂任务用的是同一套流程，做一张海报也要走完整的项目审批流程，做一整套装修方案也只能靠临时拼凑瓷砖工人们自己商量。前者是杀鸡用牛刀，效率低；后者是没有统筹能力，容易出岔子，质量没保障。
专家技能*：针对单一最终交付物（比如一张海报、一段完整视频）的完整生产流程，包含需求分析、任务规划、素材生成、成品组装、质量检查、局部返工。
场景技能*：面向具体应用场景（比如社交媒体发帖、求职材料准备）的顶层协调者，负责判断这次请求到底需要哪几样交付物，再调度对应的专家技能或原子技能去完成。
举个论文里的实际例子。用户说"我想推广我的产品，帮我生成材料"，系统会先激活"活动物料"这个场景技能。这个场景技能判断出用户需要海报、带音效的宣传视频、落地网页三样东西，于是把任务拆解给"海报设计"专家技能和"复杂视频制作"专家技能，这两个专家技能又进一步拆解成图像理解、图像生成、视频生成、音效生成、代码生成这五个原子技能。
整个拆解过程是自动的，用户完全不需要知道背后有几层调度在跑。
目前系统一共实现了27个Skills，覆盖38类代表性任务，横跨教育科研、商业营销、职场发展、创意产业等多个领域。这个数字不是终点,论文特意强调了每一层Skill的扩展方式，新增一个原子技能只需要封装一个新工具并写一份规格说明，不需要动系统的其他部分。
四层架构：把"知识"和"实现"彻底切开
光有Skill体系还不够，因为Skill描述的是"要做什么"，而具体"怎么做"，也就是用谁家的API、传什么参数，是另一回事。如果把这两者混在一起写，后果会很麻烦：哪天OpenAI的图像生成接口改版了，或者你想换成另一家更便宜的服务商，就得把所有相关的Skill文档全部重写一遍。
Omni-IO Skills用了一个很干净的四层架构来解决这个耦合问题。
第一层是Skill入口层，负责理解用户请求、挑选合适的Skill、把高层Skill层层展开成可执行的具体任务。第二层是MCP工具服务层，它把这些任务翻译成标准化的工具调用接口。
MCP*：Model Context Protocol的缩写，一种让智能体统一访问外部工具和资源的标准协议。
第三层是提供商与配置层，负责把"生成一张图"这个抽象能力，实际绑定到某个具体的服务商、某个具体的模型上，比如OpenAI的gpt-image-2，或者备选的fal.ai的flux/schnell。第四层是资产注册表，负责记录所有生成出来的文件，给它们发一个全局唯一的身份证号，这样不管文件实际存在硬盘的哪个路径下，后续任务都能通过这个身份证号找到它。
这四层分离带来的好处，用一个类比可能最容易理解。想象你在一家连锁餐厅点餐，菜单上写的是"招牌牛肉面"，而不是"某某供应商三月份到货的某批次澳洲牛肉加某工厂生产的面条"。你点单的时候完全不关心供应链细节，后厨换了供应商，菜单上的名字照样不变，你照样能点到"招牌牛肉面"。如果菜单直接写死了供应商信息，那供应商一旦换掉，整份菜单都要重印，顾客也会一脸懵。
Skill层就是那份"菜单"，它只关心语义层面的"生成一张图"，具体由谁来生成、用什么模型生成，是配置层悄悄换掉的事，Skill文档本身一个字都不用改。
论文里给出的绑定表也印证了这套设计的实用性，图像生成默认走OpenAI的gpt-image-2，备选走fal.ai的flux/schnell；视频生成默认走阿里的wan2.7，备选走fal.ai的Kling 1.6；3D生成默认走Tripo AI，备选走Meshy。换掉任何一个，都只是改配置文件里的一行字，然后重启工具服务，不涉及任何Skill重写。
DEG：给多模态任务排一张真正靠谱的施工图
现在问题来了，一个复杂请求拆成一堆原子任务之后，这些任务之间是有先后顺序和依赖关系的。比如你要生成一段"以某张产品图为首帧"的视频，那这段视频生成任务必须等那张产品图先生成出来。但同时，生成海报素材和生成宣传视频音效，这两件事互相之间没有关系，完全可以同时进行。
如果不区分哪些任务能并行、哪些必须排队会怎样？两种情况都很糟糕。要么系统傻乎乎地把所有任务串成一条队列，一个一个做，效率极低，用户等到天荒地老；要么系统胡乱并发所有任务，结果那个需要"首帧图片"的视频任务在图片还没生成出来的时候就开始执行，直接报错。
Omni-IO Skills用了一种叫做DEG（Declare Execution Graph，声明式执行图）的结构来解决这个问题。
DEG*：把一个复杂任务拆解成一系列带依赖关系的节点，节点之间用有向边表示"谁必须等谁先完成"，系统据此进行分批调度和执行。
这个思路很像工地上的施工进度表。盖房子要先打地基，再砌墙，最后装修，这些工序有严格的先后顺序，没法颠倒。但与此同时，电工布线和水管安装可以同时进行，因为它们互不依赖。一份好的施工进度表会把这两类情况都标注清楚：哪些是"必须先后"，哪些是"可以同时"。如果没有这份进度表，要么工人们干等着不敢动手，要么电工和水管工在同一面墙上打架。
DEG执行时会先做结构校验，确认每个依赖引用都能找到对应节点、整个图里没有循环依赖（也就是A等B、B又等A这种死锁情况）。校验通过后，系统按"批次"（论文里叫Wave）调度：所有前置依赖都已完成的节点，会被打包成一个批次并发执行。
论文里那个产品推广的案例把这个机制展示得很清楚。第0批次先分析产品参考图；第1批次同时生成海报素材、生成视频和音效（这两件事互不依赖，并发跑）；第2批次把这些素材组装成最终的宣传视频和海报；第3批次生成落地网页。整个过程走完，如果用户后来只是想改一下落地网页的风格，系统不需要把前三批次全部重做，只要把已经生成好的产品分析结果和宣传素材直接拿来复用，只重新执行第3批次那一个节点就够了。
这里还有个细节值得说一下,如果某个节点执行失败了会怎样？系统不会因为一个节点炸了就把整张图全部推倒重来。失败节点的后续依赖任务会被取消，但那些跟失败节点没有依赖关系的独立分支会继续正常执行。这种"局部失败不影响全局"的设计，某种程度上和现代分布式系统里的容错思路是相通的：单点故障不该拖垮整个系统。
资产注册表：让每一份生成的文件都有身份证
最后一块拼图是资产注册表，它解决的是一个特别容易被忽视但极其重要的问题:生成的文件，到底应该怎么被记住和找到？
论文里给每个注册的资产设计了一份结构化记录，包含唯一ID、类型、子类型、本地路径、生成时描述、生效参数、所属对话轮次、以及如果是修订版本的话指向源文件的溯源指针。
这套设计解决了两个实际痛点。第一是跨任务复用，同一轮对话里，如果A任务生成的图片要被B任务当作输入，B任务只需要拿着资产ID去查，不用关心文件到底存在哪个目录下。第二是跨轮次复用，用户在今天生成了一张夜景照片，明天说"把昨天那张夜景照片做成一个短视频"，系统能通过语义匹配在注册表里找到那张图的记录，直接把它当作一个"已完成"的节点接入新的执行图，完全不需要重新生成。
这个设计避免了一个很容易踩的坑。如果没有持久化的资产管理，每一轮对话都是从零开始，那"昨天生成的那张图"这种日常表达用户根本没法说出口，因为系统压根不知道"昨天"发生过什么。这就好比你每天去同一家裁缝店做衣服，但裁缝完全不记得你上次量过的尺寸，每次都要重新量一遍,效率低不说，体验也极差。
注册表的写入是原子操作并且加了文件锁，避免多个并发节点同时写入时互相覆盖。而且记录是只追加、不覆写的，也就是说同一个海报被修改了三次，注册表里会留下三条独立记录，每一条都能单独被检索和回溯，方便追踪版本历史。
实测效果：从"看不懂"到"全都会"
说了这么多架构设计，最终还是要看数据说话。
论文在UniM-90这个测试集上，对比了两个智能体在"原生状态"和"装上Omni-IO Skills之后"的表现。这里有几个指标需要先解释一下。
输入支持率*：智能体能完整接收并处理所有输入模态的任务比例。语义质量耦合分数（SQCS）*：同时衡量回答的语义正确性和生成质量的综合指标。结构分数*：衡量输出结构是否完整、是否覆盖了所有要求的模态。
先看输入支持率，这个数字变化最直观。GPT-5.6 Sol从40%涨到100%，Claude Sonnet 5从38.89%涨到100%。这意味着原本六成左右读不懂、处理不了的多模态任务，现在全都能接住了。
| 指标 | GPT-5.6 Sol（原生） | GPT-5.6 Sol（+Skills） | Claude Sonnet 5（原生） | Claude Sonnet 5（+Skills） |
|---|---|---|---|---|
| 输入支持率 | 40.00% | **100%** | 38.89% | **100%** |
| 相对SQCS | 26.99 | **74.94** | 27.82 | **77.78** |
| 相对严格结构分数 | 19.14 | **100.00** | 20.30 | **99.78** |
| 相对宽松结构分数 | 28.89 | **100.00** | 26.67 | **100.00** |
相对SQCS这个指标涨幅尤其值得细看。GPT-5.6 Sol从26.99涨到74.94，提升了47.95个百分点；Claude Sonnet 5从27.82涨到77.78，提升了49.96个百分点。这不是简单的"能不能做"的差别，而是"做得好不好"的差别，说明Omni-IO Skills不只是打通了输入输出通道，连带着输出质量本身也大幅提升了。
结构分数的表现更是接近满分,GPT-5.6 Sol在严格结构分数和宽松结构分数上都达到100%，Claude Sonnet 5也分别达到99.78%和100%。这说明系统在多模态工具调用、素材组织、输出结构控制这几件事上做得相当扎实。
论文里还给了两个具体案例。一个是"艺术教程生成"：用户提供一段绘画教学视频和配套讲解音频，要求生成一份包含11张图片的图文教程。系统调用教育分享场景技能来做整体规划，用视频理解技能提取画画步骤，用音频理解技能还原讲解顺序，最后用图像生成技能做出11张连贯的教程图。另一个是"产品推广"案例，前面已经详细讲过流程，最终生成了一张4:5海报、一段精确10秒的9:16竖版宣传视频、一个响应式的HTML/CSS/JavaScript落地页，三样东西风格统一，产品身份（粉色瓶子的形状、logo、标识）在所有素材里保持一致。
这两个案例说明一件事:系统不只是让智能体"能做"这些任务，而且能在多个输出之间保持内容和风格的一致性，这恰恰是真实生产场景里最容易出问题、也最考验编排能力的地方。
写在后面
读完这篇论文，最触动我的不是那些漂亮的百分比提升，而是一个更底层的判断：把"让AI更聪明"和"让AI更能干"这两件事分开来看待，可能是更务实的路径。
现在整个行业似乎默认了一种假设，模型越大、参数越多、训练数据越全，它就应该无所不能。但这篇论文提供了一个反例:GPT-5.6 Sol和Claude Sonnet 5的推理能力已经足够强，缺的从来不是"脑子"，而是"手脚"和"工具箱"。给它们装上一套外部的技能体系，不改一行模型权重，输入支持率就能从不到四成飙到百分之百。这某种程度上说明，很多所谓的"模型能力瓶颈"，其实是系统工程问题，而不是算法问题。
另一个让我反复琢磨的细节是DEG里那个"失败节点不拖垮全局"的设计。这背后其实是一种对不确定性的坦然接纳,系统设计者从一开始就承认，某个环节一定会出错（图像生成失败、API超时、内容审核拒绝），与其追求"永不失败"，不如把注意力放在"失败了怎么最小代价地兜底"。这种思路其实在很多工程系统里都能看到影子，但把它系统性地用在多模态智能体编排这件事上，我觉得是这篇论文比较扎实的贡献。
论文里也留了一些没铺开讲的问题，比如当两个Skill的执行策略产生冲突时（比如场景技能判断需要生成海报，但专家技能内部检查发现素材质量不达标，该重新生成还是降级交付），目前的机制是"最多两轮自主返工，之后向用户求助"，这个阈值是怎么定出来的，论文没细说。另外，Skill之间的扩展目前还是靠人工编写规格说明，如果未来Skill库涨到几百上千个，会不会出现新旧Skill功能重叠、触发条件冲突的情况，这也是个悬而未决的问题。
一个AI智能体真正"全能"起来，靠的可能不是一个更大的模型，而是一整套精心设计的分工体系。这个体系里没有一个环节是天才式的突破，但把这些环节严丝合缝地拼在一起，效果却是实打实的质变。
Q&A
Q1：Omni-IO Skills是什么？
A：Omni-IO Skills是一套可插拔的智能体能力扩展系统，通过分层Skill体系、标准化执行接口、依赖感知调度和持久化资产管理，让GPT-5.6 Sol、Claude Sonnet 5这类通用智能体无需重新训练就能处理文本、图像、音频、视频、文档、3D、代码七种模态的输入输出。
Q2：Omni-IO Skills会不会取代智能体本身的模型能力？
A：不会。它完全不修改宿主模型的推理核心，只是在模型和外部工具之间搭了一层协调层，负责选技能、传素材、管依赖、记结果，模型的规划和推理能力还是由GPT-5.6 Sol或Claude Sonnet 5自身提供。
Q3：Omni-IO Skills目前支持哪些具体任务？
A：目前系统包含27个Skills，覆盖38类代表性任务，涉及教育科研、商业营销、职场发展、创意产业等领域，比如生成宣传海报、制作带音效的视频、写求职材料、整理会议纪要、生成3D游戏资产等。
