系统综述259项工作：AI创作如何从「会生成」走到「能交付」？

新智元报道 长文、网页、视频和代码经常停在这样的「半成品」状态：海报文案没有写错，却挤出了页面；网站首屏很漂亮，按钮点下去毫无反应；视频里的镜头单看都成立，连起来却丢了人物和节奏；程序刚修好一个模块，另一处又出现回归。 完整作品里的要求彼此牵连，问题又常常要到渲染、播放或运行后才暴露。修复过程需要定位问题、局部修改，并检查改动是否影响其他部分；整体重做会连带改掉已经完成的内容 来自香港科技大学（广州）、浙江大学、中国科学技术大学、清华大学、香港大学、悉尼大学和中山大学的研究团队，围绕作品的持续构造梳理了截至2026年8月20日的259项工作，其中包括230个系统和29个相关基准。 论文链接：https://arxiv.org/abs/2608.28122 项目主页：https://agentic-creation.github.io/ GitHub项目：https://github.com/GeminiLight/awesome-agentic-artifact-creation 从生成结果到持续构造 传统生成系统大多沿着一条单向路径工作：接收指令，生成结果，然后结束。任务足够小、结果容易检查时，这种方式很有效。完整交付物则需要系统持续保留和修改作品状态。 一张科研海报的文案、图表和版式要互相配合；软件仓库中的代码、测试和文档要保持一致；长视频中的人物、叙事和时间线也不能各管一段。修改其中一处，旧的检查结果也可能随之失效。文案变长会挤压版面，数据改变会牵动图表和结论，接口调整会让测试与说明文档一起过期。 综述将Agentic Artifact Creation定义为一种持续构造过程：系统维护一个不断变化的可交付物，并根据中间结果决定下一步生成什么、修改哪里，以及何时停止。 图1｜直接生成沿固定路径得到结果；智能体式创作把作品状态、检查结果和后续修改连成一个循环。 智能体式AI创作系统的功能架构 论文将构造过程拆成三个功能角色：作品表示、构造策略和运行时验证。 论文图4｜Agentic Artifact Creation的功能架构。构造策略选择动作，作品表示提供可编辑的中间形态，运行时验证把观察转成反馈；满足标准后，系统交付作品。 作品表示（Operational Representation）保存当前作品的状态，也决定系统能改到多细。它可以是一份文档、一张场景图、一段可执行代码，也可以是带有图层、节点和依赖关系的结构化表示。系统若只能看到最终截图，很多问题就难以定位；文本块、页面组件或场景对象等可定位结构可以支持局部修复。 构造策略（Construction Policy）负责决定下一步做什么。它结合任务要求、当前状态和已经获得的反馈，选择继续生成、修改某个位置、调用工具、请求人工判断，或在证据足够时停止。 运行时验证（Runtime Verification）观察刚才的行动带来了什么结果。文本可以核对引用，页面需要渲染和点击，程序要编译和运行测试，音视频则要播放。检查结果会直接进入下一步决策。 三个角色循环配合，一次修复通常经过： 明确完成标准 → 保留可定位的作品状态 → 验证当前结果 → 诊断问题 → 构造策略选择动作 → 执行局部修改 → 重新验证 三个功能角色的配合可能支持三种能力： 组合性（Composability） ：作品可以拆成边界清楚的部分，并通过明确的接口衔接。文案、图表和版式可以分别制作，需要时也能替换或调整顺序，组合后再检查是否彼此兼容。 可追溯性（Traceability） ：系统记录要求、动作、作品状态和观察结果之间的关系。结果出现问题时，可以追到相关要求、改动和证据，也能说明一次决策是怎样形成的。 可修订性（Revisability） ：验证结果能够指向受影响的部分，构造策略据此选择修改范围。修完后，系统重新检查相关依赖，并尽量保留已经通过的内容。 六类作品 研究团队以最终交付的作品为中心，将现有工作分为六类：文本、二维视觉、音频、视频、空间作品，以及软件、网站、游戏和模拟等行为型作品。 图2｜文本与视觉作品可以直接阅读或渲染；音视频依赖时间播放；空间和行为型作品往往需要运行或交互后才能判断。 文本和二维视觉通常可以静态检查，句子、段落、图层和图形标记也较容易定位。难点是长距离一致性：改动前文的一项事实，可能要求后文的论证、图表和引用一起更新。 音频和视频需要沿时间序列检查。某个片段单独听起来没有问题，放回完整序列后却可能破坏节奏。视频还要同时处理画面、声音、字幕和镜头之间的关系，反馈通常要等到播放或渲染后才会出现。 空间作品要维护几何、语义部件和物理约束。行为型作品是否合格，则取决于代码、应用或模拟在一段交互过程中如何响应。执行路径越长，获得一组有代表性的观察就越贵，也越难把失败追溯到具体状态。 不同作品的构造难度取决于三个变量：决策之间的关联程度、错误何时可见，以及系统能否在保留已有成果的前提下局部修复。 多Agent协作的成本 把复杂任务拆成子任务，可以降低单步难度，也会增加协调成本。 一个Agent修改文案，另一个Agent负责页面，第三个Agent检查事实。如果文案变长，页面Agent是否知道版面已经失效？事实核查更新了一个数字，图表和结论是否会同步变化？每个Agent都完成自己的局部任务，最终结果仍可能互相冲突。 多Agent系统的难点在于共享状态、依赖关系和完成标准。拆得越细，协调、冲突处理和重新组装的成本越高。对于短小、容易验证的任务，一个能稳定调用工具的单Agent可能更加合适。 共享的作品表示把各个Agent的分工落到同一个可检查、可修改的交付物上，并维持局部结果之间的一致。 总分无法直接指导修复 不少生成系统把评估收束为一个总分。总分适合比较结果，却很难指导修复：它通常不说明问题出现在哪里、由什么引起，也没有给出下一步可以执行的修改。 诊断粒度还必须和编辑粒度对得上。检查器发现整体叙事不连贯，系统却只能重写整篇文章；评估器发现视觉层级存在问题，编辑接口却只能重新生成整张图。反馈再准确，也很难变成可执行修复。 论文把评估对象分成三层： 第一层是 最终作品 ：要求是否满足，内容是否一致，放进真实场景后能不能完成预定用途。 第二层是 构造轨迹 ：错误发现得够不够早，修复是否局部，已经通过的部分有没有被保留下来，过程中花了多少时间、模型调用和人工监督。 第三层是 Agent系统本身 ：同一任务重复运行是否稳定，换一个起点会不会失灵，用户能否修改目标并保留控制，系统更新后是否出现回归。 图3｜先说明评估的是最终作品、构造轨迹还是Agent系统，再说明使用了什么证据、由谁判断，以及在怎样的协议下形成结论。 生成器和评价模型来自相近的模型家族时，可能共享知识缺口、审美偏好和判断盲区。增加LLM Judge的数量并不能保证证据彼此独立。 来源对照、结构化状态、渲染结果、运行行为、构造历史和用户结果属于不同的证据渠道；规则检查、专用模型、LLM Judge和人工评审则是不同的评价者。一次具体的评价信号来自证据渠道与评价者的组合。评估报告需要说明每一种信号能支持什么结论，也要保留彼此冲突的结果。 四项设计原则 第一，把必须保留的要求写进作品状态。完成标准