Omni-IO Skills：用 Agent Harness 把现有 agent 改造成"全模态原生"

  • 关联论文：2609.31847
  • 作者：flyP
  • 更新：2026-09-30

一句话结论

Omni-IO Skills 提出一种"即插即用"的 Agent Harness，通过分层 Skill、标准化多模态 IO 接口、依赖感知编排（Declare Execution Graph）、持久化 Asset Registry，让 GPT-5.6 Sol / Claude Sonnet 5 等现有通用 agent 不改动 reasoning core 的前提下，把输入支持率从约 40% 提到 100%，并把相对 Semantic-Quality Coupled Score 从约 27 提到约 75；论文用 27 个 Skill 覆盖 38 个代表性任务、7 种产物模态和 4 类能力族。

解决什么真问题

通用 agent 已经能做长程规划与推理，但在生产环境里其能力被切碎在文本、图像、音频、视频、文档、3D 资产、代码等多种异构模态中。两条主流扩展路线都有痛点：

  1. 扩模型本身：把基础模型扩展到新模态 = 一次昂贵的大模型更新；能力增长被绑死在发版节奏上。
  2. 拼专用模型与工具：把 vision/audio/video 等 specialist model 拼起来，但没有标准说清楚：(a) 流程怎么定义；(b) 中间资产怎么传递；(c) 跨轮修改如何协调；(d) 依赖关系怎么调度。

Omni-IO Skills 走第三条路：不改 agent 推理核心，而是给 agent 加一层harness 层，把"工具调用"升格为"能力组合"。

核心方法：四件套 Harness

Omni-IO Skills 的 harness 由四件套组成。

1. 分层 Skill（Hierarchical Skills）

每个 Skill 是一个可调用单元，论文共实现 27 个 Skill。Skill 之间存在层级关系：父 Skill 描述能力族，子 Skill 描述具体任务，例如"视频理解"父 Skill 之下有"镜头切分"、"事件检测"、"动作时序"等子 Skill。这种分层让 agent 可以按能力族规划而不是在原子工具上做组合爆炸。

2. 标准化多模态执行接口（Multimodal Execution Interface）

所有 Skill 共享统一的 IO 接口：输入是声明式的任务描述 + 资产引用，输出是已注册的 Asset。论文给出 38 个代表性任务覆盖 7 种产物模态（文本、图像、音频、视频、文档、3D 资产、代码）与 4 类能力族（understanding / generation / reasoning / retrieval）。

这个接口有两层价值：

  • 对 agent：规划时面对的是统一接口，无需关心"调哪个模型"。
  • 对执行后端：接口与具体模型/工具解耦，所以执行后端可替换（论文明示"replaceable execution backends"），是测试与降本的关键。

3. 依赖感知编排（Declare Execution Graph）

多资产工作流被显式表示为 Declare Execution Graph（声明式执行图）：

  • 节点 = 一个 Skill 调用。
  • 边 = 数据依赖（"节点 B 需要节点 A 的输出"）。
  • 调度器对独立节点并行执行，对有依赖节点串行，最大化吞吐。

这一步是论文与传统 tool-use agent 的最大差别：传统 agent 把每次工具调用当成一次对话，串行、不可并行；Omni-IO Skills 把整段任务编译成 DAG再调度。

4. 持久化 Asset Registry

每个 Skill 的成功输出被注册到 Asset Registry，下游 Skill 与跨轮（cross-turn）后续步骤都能复用。这等于把"中间产物"持久化，避免在长任务里反复重新生成。

伪代码骨架：

agent_plan = host_agent(task)            # 规划由 host agent 完成
dag = declare_execution_graph(agent_plan) # 编译成 DAG
assets = {}
for batch in scheduler(dag, assets):      # 按依赖并行
    for skill_call in batch.independent:
        output = skill(skill_call, assets)  # 调可替换 backend
        assets[output.id] = AssetRegistry.register(output)
final = compose(assets, dag.sinks)

关键实验与数据

论文主基准是 UniM-90。在两个 host agent 上分别给出提升：

Host Agent 指标 Base +Omni-IO Skills
GPT-5.6 Sol Input-support rate 40.00% 100.00%
GPT-5.6 Sol Relative Semantic-Quality Coupled Score 26.99 74.94
GPT-5.6 Sol Strict Structure Score — 100.00
Claude Sonnet 5 Input-support rate 38.89% 100.00%
Claude Sonnet 5 Relative Semantic-Quality Coupled Score 27.82 77.78
Claude Sonnet 5 Strict Structure Score — 99.78

⚠️ 诚实标注 / 局限性：

  • abstract 未给出 base 模型在 Strict Structure Score 上的具体数值。
  • Input-support rate 从约 40% 提到 100% 的"提升"中，有多少来自"原本不支持的输入被接住"、又有多少来自"task 在 harness 下被重新定义"，abstract 未述。
  • "Semantic-Quality Coupled Score" 是一种相对分（relative），不是绝对质量分，跨论文不可直接比较；abstract 未给定义公式，需查正文。
  • GPT-5.6 Sol / Claude Sonnet 5 是 abstract 的版本命名，作者未在 abstract 中给出与公开商业版本号的对应；原论文版本号体系需查正文 §实验。

1. GitHub 已验（fetch-verify-date 2026-09-30）

  • 论文明示 GitHub 仓库：https://github.com/any2any-mllm/Omni-IO-Skill
  • 28 页 / 11 图 / 18 表 / 项目页可访问（comment 段）。
  • arxiv abs 页 200 OK，v1 提交时间 2026-09-25。

亮点与局限

亮点

  1. harness 层思路干净：不抢 agent 推理核心的戏，让"工具编排"独立演化成"能力合成"。
  2. DAG 调度 + Asset Registry：把并行与跨轮复用做成第一类公民，长任务的吞吐与一致性都受益。
  3. 可替换 backend：执行后端可换，论文已经做出 27 Skill × 多 backend 组合的实证空间。
  4. 覆盖 7 模态 + 4 能力族：实证 harness 不是"只能写文本"的玩具，能落到多模态产物。

局限

  1. 依赖 host agent 的规划质量：planner 仍是 host agent 自身的 reasoning core，Omni-IO Skills 没解决"host agent 规划能力不足"的根本问题；只是把"工具调用层"做厚。
  2. DAG 编译的失败代价：DAG 节点失败 → 必须重调度或回滚，错误恢复策略 abstract 未述；复杂依赖下可能级联失败。
  3. Asset Registry 的存储与版本治理：跨任务/跨会话复用时如何避免"过期资产被错误复用"？abstract 未明示资产过期/版本控制策略。
  4. 评测口径局限：UniM-90 是自建基准，主观质量分（Semantic-Quality Coupled Score）依赖评审者一致性；与 SWE-bench / GAIA / WebArena 等公开榜单不可直接比较。

对工程落地的启发

  1. harness 优先于模型升级：当业务需要多模态能力时，先把"工具编排 + 资产复用 + DAG 调度"做厚，比频繁换基础模型更便宜。
  2. 声明式 DAG > 隐式串行调用：把工具调用从"对话里的 thought-action 串"升级成"DAG 调度器"，立刻获得并行 + 复用 + 错误恢复的可观测性。
  3. Asset Registry 是长任务的"工作内存"：把中间产物显式落库，跨轮复用、跨任务复用、调试回放都受益。
  4. 可替换 execution backend 是降本开关：用同一 Skill 暴露多种 backend（自托管 / API / 第三方），按成本/延迟/质量动态路由。
  5. 评测要双指标：UniM-90 同时报告"输入支持率"（能不能接）与"语义-质量耦合分"（接得好不好），这是多模态 agent 评测的标配维度。

⚠ 工程节 7 个具体坑（现象 / 影响 / 修复）

  1. 坑：Skill 接口标准化失败，host agent 仍要感知 backend - 现象：Skill 内部细节泄漏到 host agent 上下文，planner 仍然为每个 backend 写专门 prompt。 - 影响：host agent 上下文爆炸，harness 层失去"通用 IO 接口"价值。 - 修复：每个 Skill 必须只暴露 (task_spec, asset_refs) -> asset_id 三件套；用强类型 schema + 自动 wrapper 守住边界。

  2. 坑：DAG 并行节点共享同一写资源 - 现象：两个并行 Skill 同时写一个文件/同一 Asset slot。 - 影响：竞态条件，Asset Registry 出现半成品。 - 修复：DAG 编译期对每个 Asset 的写入者做唯一性约束；冲突节点降级为串行。

  3. 坑：Asset Registry 无版本/过期机制 - 现象：上一次任务的中间产物被本次任务复用，导致"看起来对、其实错"。 - 影响：跨轮回放与可调试性归零，故障定位极其困难。 - 修复：每个 Asset 挂 (task_run_id, created_at, schema_version, expires_at)；Registry 暴露"按任务隔离"视图。

  4. 坑：评测指标 Semantic-Quality Coupled Score 不可跨论文比较 - 现象：内部口径分数，外部 benchmark 不能复用。 - 影响：自家 harness 自评高分，但放 SWE-bench / GAIA 等公开榜上未必领先。 - 修复：除内部指标外，必须在 ≥1 个公开多模态榜单（GAIA / OmniGAIA / WorldSense）上报告分数。

  5. 坑：可替换 backend 的能力差异被 Skill 抽象掩盖 - 现象：同一 Skill 在 backend A 输出高质量、backend B 输出低质量，但 Skill 接口不变。 - 影响：上层 planner 误以为 backend 无差异，做出不可靠的成本路由决策。 - 修复：每个 Skill 维护 backend 能力 profile（任务类型 → 质量分 + 成本 + 延迟），路由时按 profile 选择。

  6. 坑：host agent 推理核心"不够强"导致 harness 失效 - 现象：planner 把任务分解得太细（200 个节点）或分解得太粗（5 个节点）。 - 影响：DAG 过细 → 调度开销爆炸；过粗 → 无法并行。 - 修复：给 planner 提供"DAG 大小 hint"（最少/最多节点数），并用 verifier 复检 DAG 是否具备并行性。

  7. 坑：DAG 节点失败缺乏补偿语义 - 现象：某个 Skill 失败后，依赖它的下游节点继续调度，Asset 残留。 - 影响：长任务"卡死"或"半成品"被当作成功交付。 - 修复：每个节点挂 compensation_skill（补偿 Skill），失败时调度器自动反向执行；DAG 顶层加 success-or-rollback 事务语义。

与同方向工作的关系

  • Toolformer / Gorilla / ReAct / ToolBench：解决"agent 怎么选工具"；Omni-IO Skills 解决"工具调用之后怎么合成能力"。
  • LangGraph / Temporal / Airflow：是通用 DAG 编排框架；Omni-IO Skills 是为多模态 agent 特化的版本（声明式 Skill + Asset Registry + 7 模态覆盖）。
  • Voyager / Ghost / AgentScope skill library：偏向"跨任务可复用技能学习"；Omni-IO Skills 偏向"单任务内多模态产物合成"，二者正交可组合。
  • OmniGAIA / WorldSense / GAIA / WebArena：可作为 Omni-IO Skills 的外部评测基准，目前 abstract 只在自建 UniM-90 上验证。

适合谁读

  • 想要多模态产物合成能力（图像/视频/3D/文档/代码）但不想改基础模型的工程团队。
  • 已经在用 LangGraph / Temporal 等编排框架，希望把它们升级为多模态 agent harness 的架构师。
  • 研究声明式 agent 工作流与技能层级的学术同学。
  • 关注成本/质量双指标评测的产品负责人。

速读骨架

  • 问题：通用 agent 推理能力不弱，但生产多模态能力被"工具/模型拼装"拖累，缺统一编排层。
  • 方法：27 个分层 Skill + 标准化多模态 IO 接口 + Declare Execution Graph + Asset Registry。
  • 结果：GPT-5.6 Sol / Claude Sonnet 5 在 UniM-90 输入支持率 ~40% → 100%；相对语义-质量耦合分约 27 → 约 75。

与“工具调用”路线的边界

Omni-IO Skills 与传统 function-calling / tool-use 不在同一个抽象层级：

  • function-calling 关心"agent 一次调哪个 API"；
  • Omni-IO Skills 关心"agent 的一次任务怎么被拆解为多资产 DAG 并调度"。

前者是点的能力，后者是面的能力。生产多模态 agent 的天花板往往由后者决定：点的能力再强，没有 DAG 编排与 Asset 复用，复杂任务仍会"重复生成 + 串行等待 + 一改全重做"。

给论文作者的延伸建议（基于 abstract 推断）

  1. 公开 UniM-90 任务模板与 SQCS 计算公式：让别的 harness 可在同一基准上比较。
  2. 把 DAG 调度失败率与级联成本作为单独指标报告：与 SOTA 准确率并列，是 harness 层最关键的可观测性指标。
  3. 对照公开 benchmark（GAIA / OmniGAIA / WorldSense）：在 ≥1 个公开榜上报告 Omni-IO Skills 的硬分数。
  4. Skill 之间的语义去重与冲突消解：27 个 Skill 在 38 任务上可能有重叠，公开"为什么这样分而非那样合"的取舍记录。

⚠️ 原文 abstract 未明确项：base 模型 Strict Structure Score 原值、Input-support rate 提升的归因、SQCS 定义与公式、host agent 版本号与商业版对应关系、UniM-90 公开访问性、DAG 错误恢复语义；以上需查 PDF 正文或附录。

fetch-verify-date: 2026-09-30（arxiv abs 页 200 OK，v1 提交时间 2026-09-25；项目页 GitHub any2any-mllm/Omni-IO-Skill 已声明）；Web Archive 备援：未触发 WAF/521/403。

⚠️ 原文 abstract 未明确项：base 模型 Strict Structure Score 原值、Input-support rate 提升的归因、SQCS 定义与公式、host agent 版本号与商业版对应关系、UniM-90 公开访问性、DAG 错误恢复语义；以上需查 PDF 正文或附录。

fetch-verify-date: 2026-09-30（arxiv abs 页 200 OK，v1 提交时间 2026-09-25；项目页 GitHub any2any-mllm/Omni-IO-Skill 已声明）；Web Archive 备援：未触发 WAF/521/403。