模型变强没有用，创作仍然碎片化！面向长程多模态创作的开放式Harness

近几年，多模态生成模型进步很快。一句指令就能生成图片、视频、音频、网页、UI、分镜，甚至整套演示文稿。只看成品，创作门槛似乎已经大幅降低。

真正的创作却很少是「一句话换一个结果」。一支短片要经历故事梗概、角色设定、镜头规划、参考图、候选画面、视频片段、配音和音乐等环节；一个网站离不开视觉参考、页面结构、交互逻辑、代码实现、预览检查和多轮修改；一套PPT也要兼顾内容筛选、叙事组织、版式设计、图示生成与跨页风格统一。

这些中间材料不是可以随手丢弃的副产品。它们共同构成持续变化的项目状态：哪些素材已经采用，哪些版本被否决，某张图来自哪组参考，某个镜头是否完成，以及用户刚提出的反馈会影响哪个局部。Agent要继续推进项目，就必须读懂并维护这套状态。

现有系统的三点局限

1、Prompt-to-Output工具：擅长快速产出单个素材，但中间尝试、失败版本和依赖关系往往被隐藏或丢弃。到了下一轮，创作者常常只能重新交代上下文。

2、聊天式Agent：能够连续对话和调用工具，但主要上下文仍是一条线性的聊天记录。素材一多，空间布局、版本分支和引用关系便很难在对话中说清楚。

3、节点式工作流：执行步骤清晰可见，却通常需要人工预先搭建固定流程。节点描述的是「怎样运行」，未必能承载一个供Agent持续读取、修改和扩展的创作项目。

现有创作系统与JarvisHub的对比。从孤立工具与固定流程，走向可持续维护的共享项目状态。

真正难的问题已不只是「怎样接入更强的模型」，而是怎样给Agent一个可以长期读写、供用户随时检查，并能在失败后恢复的工作空间。

国内外多所顶尖高校联合推出的JarvisHub正是为这个问题而设计，一句需求只是创作的起点。

项目链接：https://www.jarvishub.site/

演示链接：https://youtu.be/rHUQ5YgjGLw

论文链接：https://github.com/LYL1015/JarvisHub/blob/main/docs/paper/jarvishub_paper.pdf

代码链接：https://github.com/LYL1015/JarvisHub

在JarvisHub中，Agent会围绕同一个项目整理参考、生成候选、维护版本、检查结果，逐步完成图片、视频、网页和演示文稿等多模态交付物。

JarvisHub的代表性创作案例。从叙事媒体、交互式网站到完整演示文稿，Agent在同一张Canvas上持续规划、生成、检查与修改。

上图对应三类典型场景：JarvisHub不是用完即走的内容生成工具，而是一套帮助Agent持续推进并完成项目的开放式创作工作台。

它是一套面向长程多模态创作的Canvas-Native Creative Agent Harness。画布在这里不只是展示最终素材的界面，也是用户与Agent共享的项目状态。

在JarvisHub中，提示词、参考图片、候选结果、版本关系、编辑记录、依赖链路和用户反馈都会以可寻址的Canvas节点与连接保存下来。

Agent可以读取当前画布，判断接下来要做什么，调用合适的工具，再把结果写回同一张画布。用户看到的，正是Agent正在操作的项目状态。

画布不只是界面，也是Agent的外部记忆、行动空间和共享工作台。

技术核心亮点

1. Canvas-Native Project State：把整个创作项目显式保存下来

JarvisHub将创作项目表示为一个可编辑的多模态资产图。每个提示词、参考图、视频片段、网页预览或PPT页面，都是具有稳定ID的节点；素材之间的引用、版本继承、生成依赖、分组关系和流程延续，则由不同类型的边连接起来。

有了这套表示，Agent可以准确指向具体素材，不必依赖「刚才那张图」之类的模糊描述；中间结果也能在后续阶段继续作为输入。节点之间的依赖同样可供检查，用户可以追溯某个结果用了哪些参考、经过了哪些操作。

2. Protocol Bridge：让每一次画布修改都可控、可验证、可恢复

在长程任务中，如果Agent可以随意修改项目状态，就可能覆盖有效版本、误删依赖，或在证据不足时贸然继续。为此，JarvisHub在Agent与Canvas之间设置了Protocol Bridge。

每轮开始时，Bridge会告诉Agent当前项目允许使用的节点类型、操作、工具和素材句柄，并据此生成本轮的Execution Grant。一个动作只有与当前任务相关、存在于能力清单、获得本轮授权且能通过协议提交，才会执行。

换言之，Agent的动作不会隐藏在语言生成中。它创建了什么节点、更新了哪个字段、连接了哪些依赖、工具返回了什么证据，都会成为可检查的状态变更。

3. Agent Runtime：统一调度工具、技能、记忆和子Agent

JarvisHub的Runtime把用户目标转化为具体动作。它先观察画布状态，根据当前权限选择下一步，再调用相应能力，并将结果提交回画布。

工具家族：覆盖Canvas操作，图像、视频和音频生成，本地浏览器、文件与代码处理，验证与修复，以及遵循同一协议的MCP扩展。

Skills：封装分镜设计、参考图生成、Design-to-Web、视频提示词编写和演示文稿构建等可复用流程。

Memory：保留用户偏好、已经确认的决定和过程经验，减少长任务中的前后风格漂移。

Subagents：分别探索可以并行处理的独立子任务，再由主Agent选择结果并合并。

4. Feedback & Trajectory：让反馈真正改变下一步行动

在JarvisHub中，反馈不只是最终评分。用户的选择、拒绝和局部修改，以及评估器发现的缺陷，都会影响Agent的下一步：沿用已有结果、局部修复失败节点、请求澄清，或在证据不足时停止。

系统同时记录完整轨迹，包括用户请求、执行前的Canvas状态、能力清单、授权范围、Agent动作、工具观察、反馈信号、修复决策和更新后的状态。这样一来，可供分析的不只有最终作品，还有作品形成的过程。

方法详解

1. 三层核心架构：Canvas State、Protocol Bridge与Agent Runtime

JarvisHub的整体架构分为三层。Canvas State保存多模态资产、依赖关系、版本选择和用户决策；Protocol Bridge管理身份与项目上下文、能力清单、执行授权和状态变更验证；Agent Runtime负责观察、推理、技能路由、工具编排和结果合并。

JarvisHub总体架构。三层核心组件下方统一记录轨迹、评估信号、人工编辑与检查点。

三层组件围绕同一张Canvas形成闭环：Canvas向Agent提供当前项目状态，Bridge限制并验证可执行动作，Runtime完成工具调用，新生成的素材与状态随后返回Canvas。

2. 画布如何表示一个持续演化的创作项目

在形式化定义中，JarvisHub将第t轮的项目状态写成Ct = (Gt, Xt, Mt, Ut, Lt)。其中Gt是有类型的资产图；Xt保存可编辑内容和素材本体；Mt保存来源、执行元数据和运行状态；Ut记录用户的选择、修改和反馈；Lt则保存节点位置与分组布局。

每个Canvas节点不仅包含输入和输出，还保留稳定标识、节点类型、位置、来源信息和运行状态。因此，系统可以区分「计划中」「运行中」「已完成」「已选中」「失败」或「尚未验证」的素材，并据此决定后续流程。

3. 一轮Agent执行是如何完成的

如图4所示，一轮执行从用户请求开始。Runtime先观察共享Canvas，在当前Capability Manifest与Execution Grant的约束下选择动作，再调用Skills、Memory、Tools或Subagents完成任务。工具结果经Protocol Bridge验证后，提交到共享Canvas。

Agent Runtime Loop。观察Canvas—选择动作—调用能力—返回观察—协议校验—提交更新。

用户可以直接检查画布上的新结果，选择候选、调整局部内容或提出新反馈。下一轮Agent读取的不再是一段压缩后的聊天摘要，而是已经更新的项目状态，因而能够沿着现有进度继续工作。

4. 从全局重做转向局部恢复

复杂创作中的局部失败，并不意味着整个项目都要推倒重来。JarvisHub会显式保存状态与依赖，系统因而可以定位具体的失败节点，并按反馈进行局部修复。

例如，某个视频镜头生成失败时，Agent可以保留已经确认的角色参考、场景设计和其他镜头，只重新生成出错的片段；网页交互出现问题时，也可以沿用视觉方向与已有页面，仅修改对应的代码和预览节点。这种基于项目状态的局部恢复，能明显减少长程创作中的重复工作。

实验结果

三个长程创作案例

论文选取了三个具有代表性的任务来检验JarvisHub的长程创作能力：叙事媒体生成、交互式网页开发和演示文稿生成。它们分别考验跨镜头一致性、设计与代码协同，以及跨页面的内容与视觉统一。

1. 叙事媒体生成：从一句故事设定到连续镜头

第一个案例要求系统围绕「牛仔机器人僵尸拾荒者」制作一段短剧。Canvas同时保存任务描述、故事规划、视觉参考、镜头候选、依赖关系和生成进度。Agent可以沿用已经确定的角色与场景继续制作后续镜头，不必每次重新描述人物外观。

叙事媒体生成案例。上方为Canvas工作轨迹，下方为连续关键帧结果。

最终关键帧中的角色、环境和动作线索在多个镜头之间保持了较好的连续性。镜头背后的规划和素材关系也被完整保留，用户可以随时回到中间节点调整。

2. 交互式网页开发：让设计参考、代码与预览处在同一项目中

第二个案例是创建一个轻盈、具有Awwwards风格和丰富动画的个人摄影网站。传统聊天式Agent常把参考图、代码和预览分散在不同消息或工具页面中；JarvisHub则把视觉参考、布局草稿、实现文件、渲染预览和修改状态放在同一张Canvas上管理。

交互式网页开发案例。Canvas同步管理视觉方向、实现过程与最终页面预览。

最终页面在字体、图片排布、页面结构和整体视觉方向上保持一致。Agent不只生成代码，还能检查渲染结果，并根据预览继续修改。

3. 演示文稿生成：跨页叙事与视觉风格的一致维护

第三个案例要求围绕机器学习中的决策树，制作一套具有Stanford课程风格的演示文稿。任务从内容结构规划开始，随后生成图示、组织页面、制作PPT，并检查多页预览。

演示文稿生成案例。Canvas记录内容规划、图示、页面草稿、依赖关系与最终PPT预览。

最终生成的多页交付物在版式、图示风格、强调色和内容层级上保持一致。相比单独生成某一页，JarvisHub更关注整套演示文稿如何逐步形成。

为什么JarvisHub值得关注

1. 从「最终结果评测」走向「项目过程评测」

对创作任务来说，只看最终结果不足以判断Agent的能力。一个看起来不错的成品，背后的过程可能脆弱且无法复现；一个尚不完美的结果，也可能保留了大量可复用的中间资产和正确决策。

有了完整轨迹，研究者可以进一步评估上下文保持、工具选择、依赖正确性、反馈遵循和修复成功率。未来的Creative Agent Benchmark也不必局限于一个Prompt和目标答案，而可以同时给出初始Canvas、参考材料、约束、反馈事件与检查点。

2. 为Creative Agent提供可积累的数据飞轮

每次运行都会留下结构化的Canvas状态、Agent动作、工具观察、反馈和修复决策。经过用户授权、匿名化、版权过滤和质量控制后，这些轨迹有望成为训练未来Creative Agent的重要数据来源。

模型不仅可以学习「最后应该生成什么」，还可以学习如何规划、何时调用工具、怎样维护多模态状态、何时局部修复，以及如何根据人类反馈继续推进项目。

3. 一个开放的研究Harness，而不是新的封闭创作产品

近期商业产品已显露出Agent辅助创作的趋势，但封闭架构使研究者难以了解其内部如何表示项目状态、检查动作、调度工具和恢复失败。JarvisHub的目标不是再做一个只展示结果的封闭产品，而是开放这些关键机制，为长程创作Agent研究提供基础设施。

结语与展望

JarvisHub把创作画布从静态界面变成Agent的共享项目状态。Canvas State、Protocol Bridge和Agent Runtime将多模态素材、版本依赖、工具调用、反馈与恢复纳入同一工作空间，使Creative Agent能够持续推进任务，并让过程可检查、可干预。

核心贡献包括：

Canvas-Native状态表示：将提示词、参考、素材、版本、依赖和反馈组织成可编辑的多模态资产图。

协议约束的Agent执行：通过能力清单、执行授权和状态验证，使每次画布修改都显式、可追踪、可恢复。

面向长程创作的Runtime：统一编排Canvas、生成、本地执行、修复和MCP工具，并结合Skills、Memory与Subagents推进复杂项目。

过程级轨迹记录：为后续的Agent Benchmark、过程评估和轨迹训练提供结构化数据。

JarvisHub后续仍需补充更系统的量化评测，并继续研究创作决策的语义正确性、跨模型工具协作和轨迹数据治理。它所指向的问题已经十分明确：生成模型越来越强之后，Creative Agent不仅要会生成内容，还要能在共享、可编辑、可恢复的项目状态中持续工作。

参考资料：

https://www.jarvishub.site/

文章来自于"新智元"，作者 "LRST"。