让扣子组织多 Agent，让 Godot 接管虚拟片场

2026-08-05

过去一年，AI 视频工作流升级得很快。

最早是把提示词复制到不同模型里：先写剧本，再生图，再图生视频，最后配音剪辑。后来有了 ComfyUI 这样的节点工作流，参数可以保存，模型可以串联，重复生成也不必每次从零开始。

但真正做过连续内容的人都会遇到同一个问题：工具越来越自动，制作人却没有轻松多少。

角色卡、分镜图、视频候选、配音版本、字幕文件和最终剪辑散落在不同窗口。第 7 镜失败了，制作人要自己判断是剧本、构图、动作还是模型的问题；一个 Agent 改了场景，另一个 Agent 可能还在使用旧版本。生成速度提高以后，返工和版本混乱反而更快堆积。

AI 视频工作流真正需要的下一次进化，不是再接一个模型，而是从“自动生成链”升级成一套能够分工、调度、返工和验收的生产系统。

这套系统可以由三层组成：扣子这样的多人多 Agent 工作空间负责组织任务，生成模型负责生产素材，Godot 负责确定性的搭景、镜头、动画和批量渲染。

它们组合起来，才更像一间真正能持续开工的 AI 视频工作室。

第一阶段：提示词接力，人在窗口之间搬运

AI 视频工作流 1.0，本质上是一条人工接力链：

剧本 → 生图 → 图生视频 → 配音 → 字幕 → 剪辑。

每一个环节都可以调用 AI，但环节之间没有共同状态。模型不知道哪个角色设定已经定稿，配音工具不知道台词刚刚改过，剪辑软件也不知道某条视频只是候选版本。

这个阶段最容易产生一种错觉：单次生成只用了几分钟，所以整条视频也应该很快。

实际耗时却藏在生成之后：找文件、改名字、比版本、重新上传参考图、核对台词、寻找失败原因。AI 负责生产，人负责当传送带。

第二阶段：节点工作流，自动了参数，还没有自动生产

ComfyUI 一类节点工具解决了很重要的问题：模型、提示词、控制条件和后处理可以被保存成可复用流程。它让一次生成从“手艺”变成了可以重复执行的配方。

但节点工作流通常只覆盖某一个工位。

它可以完成角色图、动作参考或一段视频的生成，却不会天然管理整集内容的依赖关系。第 8 镜必须等第 7 镜首帧通过，配音必须等待台词锁定，剪辑只能使用已经批准的素材——这些生产规则仍然在制作人的脑子里。

所以，工作流 2.0 自动化的是“怎么生成”，没有完全解决“现在应该生成什么、失败后退回哪里、什么结果才算完成”。

从窗口接力升级为生产图

第三阶段：把一条视频变成一张生产图

工作流 3.0 的核心，不再是一条从左到右的节点连线，而是一张带依赖关系的生产图。

OpenAI 在 Symphony 中采用了类似思路：把项目任务板变成 Agent 的控制面，每个任务进入独立工作区，Agent 持续执行；任务状态、并发限制、失败重试和人工验收由系统统一管理。

Symphony 是编码 Agent 的编排参考实现，不是 AI 视频软件。但它提供了一条非常适合迁移到视频生产的原则：

迁移到 AI 视频后，一集内容不应该再被当成一个巨大提示词，而应该拆成剧本锁定、角色资产、场景资产、镜头工单、声音工单、质检和成片等相互依赖的任务。

只有前置条件通过，下一环节才能开始；失败也不再一律“再生成一次”，而是退回真正需要修改的工位。

扣子“短视频工作群”，更像 AI 制片办公室

扣子官方目前可以确认的能力，是从单个助手升级为“多人、多 Agent 共同在场的工作空间”，可以围绕项目安排不同 Agent 分工，也支持视频项目、项目资产沉淀和本地 Agent 接入。

但我没有找到官方把“短视频工作群”定义为一个独立产品。因此，更准确的理解是：它是建立在扣子多 Agent 工作空间上的一种视频生产组织方式，而不是已经封装完成的一键漫剧工厂。

在这个工作群里，可以设置几种固定角色：

·制片 Agent：拆集数、排依赖、控制预算和截止时间。

·编剧 Agent：锁定台词，输出镜头任务。

·美术 Agent：维护角色圣经、场景锚点和素材授权。

·分镜 Agent：确定景别、机位、动作、时长和上下镜关系。

·声音 Agent：生成对白、旁白、音效和字幕时间码。

·质检 Agent：检查角色漂移、素材缺失、音画同步和导出完整性。

·人类导演：批准创意、权利边界和最终发布。

扣子的价值是让这些角色围绕同一个项目说话、领任务和沉淀资料。但它并不天然理解 Godot 工程，也不能仅靠“@一下”就安全地修改虚拟片场。两者之间仍然需要结构化工单、接口桥和权限规则。

Godot 不负责思考，它负责让镜头说到做到

如果扣子是制片办公室，Godot 更适合被定义成虚拟片场和渲染工位。

纯视频模型很擅长从提示词或参考图生成运动，但同一角色在多个镜头中的位置、镜头轴线、道具关系、灯光方向和运动时长，仍然可能漂移。Godot 的优势恰好相反：它不负责凭空想象画面，却能精确保存角色、场景、摄影机、动画和时间轴。

它可以做五件对连续 AI 视频很重要的事：

1. 锁定角色、道具和场景的空间坐标。

2. 复用同一片场，保持不同镜头的空间连续性。

3. 精确控制摄影机、灯光、动画、字幕和帧率。

4. 批量输出预览片、首尾帧、音频和运行日志。

5. 为 2.5D、3D 或交互式视频保留可编辑工程，而不是只留下一个 MP4。

Godot 官方命令行支持无界面运行、脚本执行、素材导入、错误检查和 --write-movie 录制；Movie Maker 模式可以用固定帧率录制同步音频。这意味着外部 Agent 不必模拟鼠标点击，它可以向一个受控的 Godot Worker 提交工单，再拿回预览视频和日志。

Godot 作为可重复的虚拟片场

一张镜头工单，要成为人和 AI 的共同语言

扣子、模型和 Godot 能否真正协作，关键不在提示词，而在数据合同。

每个镜头至少应该保存以下字段：

这份工单不是让所有 Agent 同时编辑同一个文件，而是给每个工位一份明确的输入和输出约定。

分镜 Agent 可以修改 camera，声音 Agent 只提交音频和时间码，Godot Worker 读取已经批准的字段生成场景。每次运行都记录模型版本、种子、输入素材、输出哈希和失败原因，下一次返工才能真正复现和比较。

不是所有失败，都应该重新生成

进化后的流程最重要的能力，是失败路由。

·文件损坏、接口超时：原工位自动重试。

·显存不足：降低并发或分辨率后重试。

·角色换脸：退回角色参考和生成工位。

·人物站位错误：退回分镜或 Godot 场景工位。

·动作情绪不对：退回动作控制或表演工位。

·台词版本不一致：锁住视频任务，先重新批准对白。

·节奏不好：不要重做全部素材，先回到剪辑和镜头时长。

因此，一条镜头的状态可以设计成：

待拆解 → 条件齐备 → 生成中 → 自动质检 → 人工复核 → 返修 → 已批准 → 已入剪。

Agent 进程成功退出，只代表工具没有报错，不代表镜头完成。只有验收条件和证据包同时通过，任务才能进入下一状态。

一条 60 秒视频，可以这样跑起来

假设一集有 12 个镜头，完整闭环可以这样执行：

1. 人类导演确定故事目标、风格和不可越过的边界。

2. 制片 Agent 把一集拆成 12 张镜头工单，并标记依赖。

3. 编剧和分镜 Agent 补齐对白、景别、动作和镜头运动。

4. 美术 Agent 只为条件齐备的镜头准备角色、场景和道具素材。

5. 生成 Agent 调用图像或视频模型，输出候选素材。

6. Godot Worker 读取工单，组装片场、摄影机、动画、声音和字幕。

7. Godot 批量渲染低清预览，同时输出首尾帧和日志。

8. 质检 Agent 检查画幅、时长、缺失素材、字幕越界、音量和镜头连续性。

9. 人类导演只查看异常镜头和创意分歧，批准后进入正式渲染。

10. 剪辑 Agent 只接收“已批准”素材，生成粗剪和交付清单。

这里的“自动接管”不是取消人，而是让系统接管重复分发、状态查询、低级检查、文件整理和失败重试。人类从每一步都点按钮，转向定义标准、处理例外和做最终判断。

系统处理常规生产，人类只处理例外和终验

多 Agent 协作，必须加一条单写入者规则

多 Agent 最危险的误区，是让所有 Agent 同时修改同一个 Godot 工程。

正确做法是：每个镜头拥有独立工作目录；同一镜头同一时刻只有一个写入者；角色库、场景母版和已批准素材默认只读。Agent 需要修改母版时，必须创建新版本并经过批准，不能直接覆盖。

扣子可以展示和调度任务，但真正的并发、锁、失败重试和文件权限，最好放在独立编排层中。这个编排层可以使用自建服务、工作流引擎或 MCP/HTTP 接口，向 Godot Worker 发送结构化任务。

也就是说，当前合理的连接方式不是“扣子直接控制 Godot 编辑器”，而是：

扣子工作群 → 任务编排服务 → 镜头工单和素材 → Godot Worker → 预览、日志和证据 → 扣子工作群。

第一版只验证一个最小闭环

不要一开始就造一个覆盖编剧、美术、视频、声音、剪辑和发布的大平台。

第一版可以只做 30 秒、6 个镜头，并限制在一个固定角色、一个固定场景和两种摄影机运动。验收以下五件事：

·镜头工单能否被不同 Agent 正确读写。

·Godot 能否根据工单稳定复原场景和机位。

·单独返工第 4 镜时，是否不会污染其他镜头。

·每次渲染能否生成预览、日志、首尾帧和哈希。

·人类批准后，剪辑是否只领取通过版本。

如果这五件事跑通，再增加角色数量、生成模型、并发 Worker、自动口型和长视频。否则，Agent 越多，只会更快地产生无法追踪的素材。

Godot 也有明确边界

Godot 不能自动解决角色身份一致性，也不会凭空提供高质量动作、口型和表演。它能锁住场景几何、摄影机、时间轴和资产版本，但生成质量仍然取决于外部模型和素材。

如果工作目标只是调用视频模型直接生成 MP4，再进入传统剪辑，Godot 的收益可能不高。它最适合以下内容：

·需要反复复用角色和场景的连续短剧。

·需要稳定机位、灯光和空间关系的 2.5D 或 3D 漫剧。

·需要批量预演、镜头替换和可重复渲染的项目。

·未来可能加入交互或分支叙事的内容。

截至 2026 年 8 月 5 日，Godot 4.7.1 是稳定版本；4.7.2 RC1 是候选测试版，4.8 dev2 是开发版本。第一版生产原型建议使用 4.7.1，4.7.2 RC1 只在工程副本或测试分支验证，不能把候选版当成正式生产升级。

AI 视频的下一阶段，是“可管理的生成”

提示词工作流让 AI 能够生成视频，节点工作流让生成可以重复；多 Agent 和确定性引擎的组合，则让视频第一次有机会成为可管理的生产。

扣子负责把人和专业 Agent 组织在同一个项目里，生成模型负责提供画面和声音，Godot 负责把角色、场景、摄影机和时间轴锁进一个可重复执行的虚拟片场，编排层负责状态、权限、重试和证据。

这套架构真正进化的地方，不是一次能叫来多少个 AI，而是终于可以回答四个生产问题：

现在该做什么？谁可以修改？失败后回到哪里？凭什么算完成？

当这四个问题被系统接管，AI 视频才不再是一串生成演示，而是一条能够持续生产、稳定返工和认真交付的流水线。

资料来源

·扣子官方 App Store 页面：多人多 Agent 工作空间、视频项目与本地 Agent 接入

·OpenAI：An open-source spec for Codex orchestration: Symphony

·OpenAI GitHub：Symphony SPEC.md

·Godot 官方版本归档

·Godot 官方命令行文档

·Godot 官方功能列表：Movie Maker 与命令行自动化

·Godot 官方文档：AnimationTree