让多个 AI 智能体共同完成一部短片，难点并不只是生成图片、视频和配音。真正棘手的是：任务跨越多个阶段，产物格式各异，智能体会崩溃、遗忘，甚至会把一个 94 字节的占位文件当成已经完成的影片。
在一次生成式媒体黑客松中，十支 AI 剧组各自配置了三名角色明确的智能体，并运行在开源多智能体编排试验平台 Scion 中。整个项目累计创建了数百个智能体实例，经过试运行与正式比赛完成 25 部以上作品，最终交付约 44 分钟影片。这场实验说明，多智能体协作能否落地，取决于持久化文件、验收门禁和适合模型能力边界的工作流，而不是智能体之间聊得有多热闹。
三个角色不是三个聊天窗口
每支剧组包含三个核心角色：
- 创意负责人（Idea Person）：编写剧本，定义视觉风格，提出候选创意。
- 技术负责人（Technical Lead）：调用图像、视频、音乐和语音生成工具。
- 剪辑师（Editor）：控制节奏、时间线和最终组装。
此外，教练智能体只在阶段门禁处检查结果，不参与编剧或导演；协调智能体则负责安排十支队伍分五轮运行，每次并行两队。整个活动持续约 21 小时。
这种划分的价值不是模仿电影公司的职位名称，而是把复杂项目拆进不同的上下文窗口。创意负责人关注故事是否成立，技术负责人关注镜头能否生成，剪辑师关注素材能否在时间线上形成完整叙事。不同角色读取同一批文件，却可以做出各自独立的专业判断。
实验中出现过一个很有代表性的情况：创意负责人只在初稿里写了一句散文式台词，剪辑师独立决定在这句话周围留出八秒静默，并在时间线上标记为“不可协商”；技术负责人则反复生成一个镜头，直到花朵在正确帧从花束中分离。三者没有专门开会协调，而是通过共享产物理解项目并继续推进。
这说明角色分工要落到可检查的责任边界上。仅仅给三个智能体不同的人设，却让它们共同修改一份模糊任务列表，通常只会制造重复劳动。
文件是项目记忆，消息只是通知
Scion 允许智能体从模板定义角色、指令、技能和工具，在容器沙箱中运行，并通过共享 CLI 互相创建、发送消息和接收事件通知。同一模板还可以运行在不同模型或执行框架上。
但实验里最重要的协作介质不是消息，而是共享文件系统。消息适合说“时间线已经更新，请检查这个路径”，不适合承载完整的视觉规范、镜头决策或音乐限制。
原因很现实：智能体可能崩溃、耗尽上下文窗口或被系统重启。消息历史里的决定很容易随实例消失，写入文件的剧本、提示词规范和时间线却可以继续存在。某支队伍的剪辑师在最终组装时崩溃，技术负责人读取其时间线计划后完成了交付；纪录片制片智能体也被多次重启，每个新实例都通过前一个实例留下的文件接手工作。
一个可迁移到软件、数据分析或内容生产项目的目录，可以这样实践。以下是假设性的最小结构，并非 Scion 的固定格式：
project/
├── brief.md
├── decisions/
│ ├── visual-style.md
│ └── audio-rules.md
├── stages/
│ ├── 01-concept.json
│ ├── 02-beat-sheet.json
│ └── 03-storyboard.json
├── artifacts/
│ ├── storyboard/
│ ├── clips/
│ └── final.mp4
└── reports/
└── final-gate.json
其中，消息只需要携带状态和路径，例如：
TO: editor
STAGE: storyboard
ACTION: review
ARTIFACT: stages/03-storyboard.json
REFERENCES: decisions/visual-style.md
这种模式把消息变成事件，把文件变成事实来源。接替工作的智能体不必重放整段对话，只需读取当前阶段文件、决策记录和待验收产物。
七段流水线需要七道真正的门
剧组采用了七步流程：概念、节拍表、角色工作坊、分镜、主体生成、组装和最终渲染。每个步骤都设置验证门，至少由另一个智能体检查技术要求，例如分辨率、时长或必需文件是否存在。
门禁必须检查产物本身，不能只接受执行者的文字汇报。早期试运行中，有队伍声称影片已经完成，实际交付的却只是一个 94 字节占位文件。这不是语言表达问题，而是验收协议缺少客观断言。
可以这样实践一个不依赖第三方库的最小交付门禁。运行前把 FINAL_FILE、最低字节数、目标分辨率和时长范围改成项目真实要求；脚本还要求本机安装 ffprobe。
#!/usr/bin/env python3
import json
import os
import subprocess
import sys
from pathlib import Path
FINAL_FILE = Path("artifacts/final.mp4")
MIN_BYTES = 100_000
EXPECTED_WIDTH = 1280
EXPECTED_HEIGHT = 720
MIN_SECONDS = 20.0
MAX_SECONDS = 300.0
def probe_video(path: Path) -> dict:
command = [
"ffprobe",
"-v", "error",
"-select_streams", "v:0",
"-show_entries", "stream=width,height:format=duration",
"-of", "json",
str(path),
]
result = subprocess.run(command, check=True, capture_output=True, text=True)
return json.loads(result.stdout)
def main() -> int:
checks = {
"exists": FINAL_FILE.is_file(),
"minimum_size": False,
"resolution": False,
"duration": False,
}
details = {"file": str(FINAL_FILE)}
if checks["exists"]:
size = os.path.getsize(FINAL_FILE)
checks["minimum_size"] = size >= MIN_BYTES
details["bytes"] = size
try:
metadata = probe_video(FINAL_FILE)
stream = metadata["streams"][0]
duration = float(metadata["format"]["duration"])
checks["resolution"] = (
stream["width"] == EXPECTED_WIDTH
and stream["height"] == EXPECTED_HEIGHT
)
checks["duration"] = MIN_SECONDS <= duration <= MAX_SECONDS
details.update({
"width": stream["width"],
"height": stream["height"],
"duration_seconds": duration,
})
except (subprocess.CalledProcessError, KeyError, ValueError, IndexError) as exc:
details["probe_error"] = str(exc)
report = {"passed": all(checks.values()), "checks": checks, "details": details}
Path("reports").mkdir(exist_ok=True)
Path("reports/final-gate.json").write_text(
json.dumps(report, indent=2), encoding="utf-8"
)
print(json.dumps(report, indent=2))
return 0 if report["passed"] else 1
if __name__ == "__main__":
sys.exit(main())
在项目根目录执行：
python3 gate.py
CI、协调智能体或教练智能体应根据退出码决定是否进入下一阶段。真实项目还可以增加音轨存在性、响度、黑帧、字幕覆盖率和内容安全检查。关键原则是：完成状态必须由可重复的检查得出，而不是由智能体自行宣布。
教练角色也因此有效。它能观察全局，却只能在阶段边界介入。这种约束迫使教练评价已经落盘的结果，而不是持续微观管理每一次生成调用。
生成模型的限制会反过来塑造创作
这些影片组合使用了图像生成、Veo 3.1 视频生成、Lyria 3 音乐生成和 Gemini Flash TTS。一个四分钟项目可能需要 40 多次图像生成、25 个以上视频片段、多个音乐分轨、十余段语音和数百次组装操作。因此，模型之间的接口和素材追踪本身就是工程问题。
角色一致性采用了“参考链”：先生成头像，再用头像生成全身设定，随后把全身设定作为场景测试和正式镜头的锚点。视频镜头则按需求选择文本生成视频、图片生成视频或首尾帧插值。超过八秒的镜头，可以把上一段的末帧作为下一段的首帧继续生成。
不过，模型能力不能只靠流程修补，创意选择也要适配它：
- 黏土动画的轻微晃动可以掩盖时间一致性漂移。
- 剪影动画绕开了面部一致性难题。
- 当安全过滤器阻止生成接吻镜头时，一支队伍改用墙上两个影子合并来表达。
- TTS 语速不能只按提示词估算。有旁白实际以每分钟 108 词输出，而计划值是 130 词，导致成片超时一分钟。
提示词同样需要进入工程规范。泛泛地写“温暖一些”，容易得到通用的电影化画面；写出 #F4A261、no string instruments、no lens flare，则把审美判断转换成可复用、可审查的约束。团队还应记录负面提示词、禁用乐器、角色参考图版本和镜头起止帧，避免每个智能体重新解释风格。
把多智能体系统当成交付系统
这次实验的重点不是证明 AI 可以取代一支电影团队，而是揭示了多智能体项目的可靠性来源。采用类似架构时，可以用下面的清单判断系统是否真的具备协作能力：
- 每个角色是否拥有清晰、互不重叠的交付责任？
- 关键决定是否写入共享文件，而不是只存在于聊天记录？
- 消息是否携带产物路径、阶段和待执行动作？
- 每个阶段是否由非产出者检查实际文件？
- 门禁是否验证大小、格式、时长等客观条件？
- 新智能体实例能否只依靠项目目录恢复工作？
- 创意和技术方案是否主动适配模型的强项、安全限制与随机性？
- 人类反馈是否会更新操作手册、验证规则和工具链？
多智能体协作的核心并不是让更多模型同时发言，而是让不同角色围绕可持久化产物工作，并在明确门禁处承担责任。消息推动流程，文件保存事实，验证决定项目能否继续。做到这三点，智能体即使重启、换模型或丢失上下文，项目仍有机会稳定走到最终交付。