📄 JarvisHub: An Open Harness for Canvas-Native Multimodal Creative Agents
标签：#音视频生成 #多模态模型 #开源工具 #音频理解 #Transformer
6.2/10 | 创新 1.2/2 | 严谨 1/1.5 | 实验 0.1/1.5 | 清晰 0.8/1 | 影响 0.3/1.5 | 开源 1.5/1.5 | 复现 0.3/0.5 | 工程 1/1.5
✅ 6.2/10 | 前50% | 文档类型：系统技术报告 | 评分置信度：高 | #音视频生成 | #多模态模型 | #开源工具 #音频理解 | arxiv
👥 作者与机构
- 共同核心贡献者（按字母序排列）：Yunlong Lin（未说明）、Zixu Lin（未说明）、Zhaohu Xing（未说明）
- 贡献者：Biqiang Li（未说明）、Chenxin Li（未说明）、Haonan Wang（未说明）、Haitao Wu（未说明）、Hengyu Liu（未说明）、Jianghai Chen（未说明）、Kaituo Feng（未说明）、Kaixin Li（未说明）、Shawn Chen（未说明）、Shijue Huang（未说明）、Sixiang Chen（未说明）、Tsung-Yi Ho（未说明）、Wenxuan Huang（未说明）、Xiangyan Liu（未说明）、Xiaomeng Hu（未说明）、Xuanhua He（未说明）、Yan Sun（未说明）、Yunqing Zhao（未说明）、Zhiqin Yang（未说明）、Zehan Wang（未说明）、Zhengyang Tang（未说明）
- 学术顾问：Tianyu Pang（未说明）、Xiangyu Yue（未说明）
- 团队署名：JarvisX Team，具体机构未明确标注
💡 毒舌点评
将画布提升为代理的共享项目状态，这一设计直觉不错，架构分层也清晰，代码直接可跑。但硬伤是致命的：通篇没有一个数字——没有准确率、没有完成率、没有延迟、没有用户研究、没有任何形式的对比。三个"定性案例"加上几张截图就敢交稿，这在语音/音乐/音频领域的从业者眼里，基本是一篇来自隔壁社区的概念展示，远够不上系统验证的门槛。
📌 核心摘要
- 要解决的问题：现有多模态创意工具（聊天式代理、节点工作流、单次生成工具）无法为长周期创作过程维护统一的、可编辑的项目状态，导致上下文丢失、版本混乱、反馈难以利用。
- 方法核心：提出 JarvisHub——一个以"画布"为共享状态的代理运行时框架，将创意项目表示为可编辑的类型化节点图（canvas state），用协议桥约束代理对画布的读写，并通过三层架构（画布状态层、协议桥、代理运行时）统一规划、生成、反馈和轨迹记录。
- 与已有方法的区别：不同于聊天式代理（上下文仅限于线性对话）、节点式工具（需手动编排管线）或单次生成系统，JarvisHub 把画布本身作为代理的外部记忆、行动空间和项目状态，支持持续、可干预、可回溯的多模态创作。
- 主要实验结果：论文未提供任何定量实验结果或基线对比，仅展示了三个长周期任务的定性工作区截图和最终生成样例（叙事媒体生成、交互式网页开发、演示文稿生成）。
- 实际意义：为多模态创意代理的研究提供了一个开放、可复现的运行环境，能够收集包含状态、动作、反馈的完整轨迹，用于基准构建、过程评估与代理训练。
- 主要局限性：缺乏量化评估和对比实验；最终作品质量完全依赖调用的外部生成模型；协议桥只能保证操作合规，不保证创意决策的语义正确性；轨迹数据用于公开研究前需经过质量过滤、同意获取、匿名化和版权审核。
🔗 开源详情
- 代码：https://github.com/LYL1015/JarvisHub
- 模型权重：论文中未提及（使用外部商业模型）
- 数据集：论文中未提及
- Demo：https://www.jarvishub.site/（项目主页，论文中标注为 Project Page）
- 复现材料：论文中提及配置细节见 GitHub 仓库，但正文未展开说明
- 论文中引用的开源项目：未提及（论文引用的生成模型与工具均为商业或未给出开源链接的第三方系统，如 GPT-5.5、GPT Image 2、Seedance 2.0、Gemini 3.1 Pro）
🏗️ 方法概述和架构
JarvisHub 是一个面向长周期多模态创作的画布原生代理运行环境，其设计核心是将画布视为唯一真实的项目状态，而非仅是用户界面。整个系统由三个层次组成：画布状态层、协议桥和代理运行时，三者围绕"观察-行动-更新-记录"的循环构建完整的代理工作流。
整个系统的整体架构如下图所示。
下图展示了JarvisHub的三层架构，包括画布状态层、协议桥和代理运行时，以及工具族和轨迹记录组件，直观呈现了画布原生的执行循环。
1. 画布状态层（Canvas State Layer） 画布状态 \(\mathcal{C}_t\) 被形式化定义为 \((\mathcal{G}_t, \mathbf{X}_t, \mathbf{M}_t, \mathbf{U}_t, \mathbf{L}_t)\)，其中 \(\mathcal{G}_t = (\mathcal{V}_t, \mathcal{E}_t)\) 是类型化构件图。\(\mathcal{V}_t\) 为画布节点集，\(\mathcal{E}_t \subseteq \mathcal{V}_t \times \mathcal{R} \times \mathcal{V}_t\) 为有向类型化关系边集，边类型包括引用使用、版本谱系、生成依赖、分组和工作流延续等。\(\mathbf{X}_t\) 存储可编辑内容和构件载荷，\(\mathbf{M}_t\) 存储来源和执行元数据，\(\mathbf{U}_t\) 记录用户选择、编辑和反馈，\(\mathbf{L}_t\) 存储空间位置和组布局。每个节点 \(v_i\) 表示为 \((\mathrm{id}_i, k_i, \mathbf{p}_i, \mathbf{x}_i, \mathbf{y}_i, \mathbf{m}_i, s_i)\)，包含稳定标识符、节点种类（文本、图像、视频、音频、UI 组件等）、空间位置、可编辑输入字段（如提示词）、生成输出或资源句柄、来源与执行诊断信息、运行时状态标记。这种表示使得备选方案、被拒绝的草稿、用户反馈和局部编辑记录都能作为可寻址、可复用的画布元素长期留存，解决了传统聊天式代理仅能依赖线性上下文的问题。
2. 协议桥（Protocol Bridge） 协议桥充当代理与画布之间的受控接口。每轮交互中，代理接收用户查询 \(q_t\) 和当前画布状态 \(\mathcal{C}_t\)，同时获得能力清单 \(\Gamma_t\)（声明当前项目可用的节点类型、变异操作和工具）和执行许可 \(\Omega_t\)（限制本轮允许的具体动作）。代理提出的动作 \(a_t\) 必须被编码为经过校验的工具调用、画布变更、评估请求或澄清请求，只有通过桥的验证才能实际执行并写入画布。执行后产生观察 \(o_t\)，并可能收到来自人类用户、模型评估器、辅助代理或结构化评估器的反馈信号 \(f_t\)，该反馈可诱导修复或后续决策 \(r_t\)。状态转移由 \(\mathcal{C}_{t+1} = \mathcal{F}(\mathcal{C}_t, a_t, o_t, f_t, r_t)\) 定义，所有画布更新由此显式化、可审计化。
3. 代理运行时（Agent Runtime） 代理运行时根据当前上下文和允许的动作空间进行决策，其授权动作空间 \(\mathcal{A}_t = \mathcal{A}(\Omega_t, \Gamma_t, \mathcal{C}_t, q_t)\) 限定了每轮可执行的操作。运行时将能力组织为五个工具族：画布工具（读写、创建、连接、分支节点）、生成工具（图像/视频/音频/复合媒体生成）、原生工具（浏览器、文件、代码执行、幻灯片等外部操作）、恢复工具（结构化反馈、局部修复、检查点）和 MCP 工具（通过 Model Context Protocol 扩展的外部能力）。在这些底层工具之上，运行时还引入三项高层机制：技能（Skills，封装故事板、参考引导生成、设计到网页重建、视频提示、幻灯片构建等可复用创作流程）、记忆（Memory，保存用户偏好和跨轮决策）和子代理（Subagents，支持独立子任务的并行探索，最终结果写回共享画布）。整个循环过程被记录为完整轨迹 \(\tau = \{(q_t, \mathcal{C}_t, \Gamma_t, \Omega_t, a_t, o_t, f_t, r_t, \mathcal{C}_{t+1})\}_{t=1}^{T}\)，包含每轮的状态快照、动作、观察、反馈和变更，为后续评估与训练提供原始数据。
代理运行时通过一个闭环过程处理用户请求，具体流程如下图所示。
下图详细说明了代理运行时的观察、选择、调用和返回步骤，强调了技能、记忆、工具和子代理的支持，以及通过协议桥验证更新并记录轨迹。
💡 核心创新点
- 画布即项目状态：将创意项目的所有素材、版本、依赖、反馈均建模为可编辑的类型化图节点和边，使画布从视觉界面变为代理与人类共用的外部记忆与行动空间。这在之前以对话历史或手动流程为主的工作中并未被系统性地实现。
- 协议桥约束的代理行动：引入能力清单与逐轮执行许可机制，强制代理的所有画布交互都必须通过规范化、可审计的接口，从而保证长周期创作中的操作一致性和可恢复性。
- 面向长周期创作的统一工具与高层机制：将画布操作、媒体生成、外部工具调用和修复工具统一在同一运行时的权限与状态管理下，并通过技能、记忆和子代理提供层次化的任务编排能力，超越了单纯的工具调用型代理。
- 轨迹驱动的分析范式：将代理的完整决策过程（状态、动作、反馈、修复）作为一等记录对象，使得创意代理的评估可以从只看最终作品拓展到过程级分析，为后续基准构建和代理训练提供了结构化数据来源。
与现有创意系统相比，JarvisHub的画布原生设计提供了显著不同的工作模式。
下图对比了提示到输出工具、聊天机器人平台和节点式工作流工具，突出了JarvisHub如何通过共享画布统一项目状态，支持长周期创作。
📊 实验结果
我们选取具有代表性的长周期创意任务对 JarvisHub 进行评估，以展示其在真实创意工作流中的能力。实验重点考察画布原生的运行环境能否支持需要持久项目上下文、迭代式素材生成以及反馈驱动优化的高价值任务。
实验设置
所有任务在相同的 JarvisHub 环境中运行。主代理后端使用 GPT-5.5，图像生成后端使用 GPT Image 2，视频生成后端使用 Seedance 2.0，多模态评估后端使用 Gemini 3.1 Pro。更详细的模型后端配置见开源仓库：https://github.com/LYL1015/JarvisHub。
长周期创意任务
如下表所示，我们在三个具有代表性的长周期创意任务上评估 JarvisHub：叙事媒体生成、交互式网页开发以及演示文稿生成。这些任务覆盖了常见的、需要将开放目标逐步转化为连贯交付物的创意工作流，涉及规划、参考资料组织、中间素材生成、反馈和局部修改。
| 任务 | 定义与挑战 | 代表性输出 |
|---|---|---|
| 叙事媒体生成 | 将故事、剧本或场景简介转化为具有时间连贯性的视觉或视听序列，测试叙事规划、身份保持、风格一致性和跨镜头连续性。 | 角色参考图、场景设计、分镜草图、镜头计划、生成的图像序列、视频片段和动态分镜。 |
| 交互式网页开发 | 将设计目标、信息结构或交互需求转化为渲染后的网页制品，测试布局设计、交互逻辑、前端代码、预览检查和迭代修改之间的协调。 | 静态页面、动态网站、着陆页、网页界面、交互原型、渲染预览和前端实现。 |
| 演示文稿生成 | 将话题、源文档、报告或沟通目标转化为结构连贯的多页幻灯片，测试内容选择、叙事组织、幻灯片布局、视觉合成和跨页一致性。 | 演示文稿、学术报告、项目报告、提案演示、面试演讲、视觉摘要和说明性图表。 |
定性结果
对于每项任务，我们从两个互补视角进行展示：以画布为中心的生产过程的工作区轨迹，以及最终交付物的生成制品。这些成对视图展示了规划、参考资料、素材、依赖关系和代理进度如何在长周期工作中保持可检查，以及累积的画布状态如何支撑连贯的输出。
- 叙事媒体生成：该案例将一部短剧提示转化为连贯的视觉序列。工作区轨迹使故事规划、视觉参考、依赖关系和生成进度清晰可见。最终输出展示了画布如何在各镜头间保持叙事和视觉连续性。
- 交互式网页开发：该案例将美学与交互简报转化为渲染后的摄影网站。工作区轨迹使设计参考、实现进度、预览和修订状态清晰可见。最终输出展示了画布如何在迭代式网页构建过程中保持视觉方向和界面一致性。
- 演示文稿生成：该案例将一个机器学习讲座话题转化为结构化的幻灯片组。工作区轨迹使内容规划、视觉组装、预览和任务进度清晰可见。最终输出展示了画布如何在多页交付物中保持主题结构和视觉风格一致性。
关键结论：论文未提供任何定量实验结果、对比表格或消融实验。所有案例均未报告生成质量评分、用户研究、完成时间、任务成功率或与基线系统（如聊天式代理、节点式工具）的比较数据。
🔬 细节详述
- 训练数据：不涉及模型训练，未说明数据集。
- 损失函数：不涉及训练目标，未说明。
- 训练策略：不涉及模型训练，未说明学习率、批次大小等。
- 关键超参数：未说明任何模型级超参数。使用的后端模型为 GPT-5.5、GPT Image 2、Seedance 2.0、Gemini 3.1 Pro，论文提及配置细节见 GitHub 仓库，但未在正文中提供温度、采样等推理配置。
- 训练硬件：未说明。
- 推理细节：未给出解码策略或流式设置。
- 正则化或稳定训练技巧：不适用。
⚖️ 评分理由
创新性 (1.2/2)：将画布提升为代理共享项目状态、通过协议桥约束代理动作并记录完整轨迹，构成了一种新颖的长周期多模态创作代理运行范式，概念设计有启发性，但尚未达到范式颠覆性突破。
技术严谨性 (1.0/1.5)：方法形式化定义清晰，三层架构和工具族划分合理，但协议桥在动作被拒后缺少回退与修复策略、画布状态膨胀未讨论，系统鲁棒性存疑，限制了技术严谨性。
实验充分性 (0.1/1.5)：完全未提供定量实验结果，无端到端质量、延迟、吞吐、成本、基线对比、用户研究或任何数值指标，三组定性截图远不能满足系统报告对端到端效能和部署验证的要求。
清晰度 (0.8/1)：整体结构清楚，架构图和公式有助于理解画布状态模型、协议桥和运行时循环，定性案例展示直观；但推理超参数等关键配置未在正文说明。
影响力 (0.3/1.5)：为多模态创意代理提供了开放运行环境和轨迹收集框架，对相关社区有潜在参考价值，但核心贡献聚焦视频/图像/网页等领域，对语音/音乐/音频读者群体直接影响很小。
开源 (1.5/1.5)：核心框架代码已在GitHub完整开放，项目主页可访问，仓库包含基本使用说明，符合核心产物完整开放且文档较完整的标准，未依赖闭源私产作为不可替代组件。
可复现性 (0.3/0.5)：代码和配置细节存放于仓库，但论文正文未披露推理超参数（温度等）、无标准化评测协议和复现步骤，实验仅依赖作者挑选的定性案例，复现路径不够明确。
工程/实践价值 (1.0/1.5)：构建了可运行且代码可用的画布原生代理环境，五族工具与技能、记忆、子代理设计具备工程实用性，但缺乏系统性能指标、压力测试与部署约束分析，工程成熟度有限。
🚨 局限与问题
论文明确承认的局限
- 实验仅为定性演示，未完成正式的基准测试或排行榜。
- 最终作品质量高度依赖所调用的外部模型和工具，JarvisHub 本身只负责编排。
- 协议桥仅保证操作合规，不能确保代理的创意决策在语义上正确。
- 记录下的轨迹在用于公开研究数据前需经过质量过滤、同意获取、匿名化和版权审核。
审稿人发现的潜在问题
- 缺少任何形式的系统级评估或对比实验，无法判断画布原生代理相比聊天式或节点式代理究竟在任务效率、产出质量、用户负荷等方面是否有实际优势。论文声称的"可检查性"“可复用性"等优势均无实证支撑。
- 画布状态会随长周期工作不断膨胀，论文未讨论图规模、冗余节点处理或存储开销问题，系统中是否存在状态压缩或剪枝策略未提及。
- 协议桥的权限和执行许可机制未给出拒绝动作后的回退或修复策略，当代理频繁被拒时可能陷入停顿，系统鲁棒性存疑。
- 安全性、多用户并发编辑时的冲突解决、版权敏感材料的代理使用权限等实际部署问题未被涉及，这些对于真实创意工作流至关重要。
- 所有案例均由作者自行运行和挑选，无第三方独立评估，存在选择偏差风险。截图展示的"成功案例"无法反映系统在普通用户手中的实际表现。
- 论文声称轨迹可用于训练未来代理，但未讨论如何从这些轨迹中定义训练信号或奖励，这一声明目前仅停留在设想层面。