VideoGen-Agent：视频生成Agent的架构设计与工程实践

视频生成这两年变化得非常快。前两年大家还在对着模型一帧一帧抽卡，拼一个能看的镜头都要靠运气；现在圈子里越来越常提一个词：Agent。VideoGen-Agent 就是把视频生成从“单次生成工具”往前推了一大步，让它具备规划、执行、检查、自我修复的完整闭环。说白了，以前我们是跟模型“对话”，让它在那几秒钟里吐一个片段；现在我们是把一个视频项目交给一个智能体，它会自己去拆脚本、分镜头、逐段出片、确认效果，不行了还能自己改。这个转变，就是视频生成进入 Agent 时代最直接的表现。

我最早感受到这个痛点，是在批量做短视频素材的时候。几十条商品视频，如果靠人手一条条改提示词跑生成，一个下午全部搭进去，中途还得盯着一帧一帧看有没有崩。后来我开始给视频生成外层套一个规划和检查的 Agent 外壳，把“零散生成”变成“带反馈的生产线”。这篇文章就以 VideoGen-Agent 这个项目为主线，把视频生成 Agent 该怎么设计、怎么搭建、怎么避坑，完整拆一遍。如果你正准备在自己的项目里做视频生成自动化，或者正在研究 Agent 与多模态模型的结合，这篇应该能直接拿来参考。

1. 视频生成卡在“工具时代”的真相：会调用，不等于会创作

1.1 单次生成工具的四个顽疾

先别急着上架构，我们得先搞清楚一个问题：为什么视频生成需要 Agent？现在各类文生视频、图生视频工具已经不少了，一键生成短视频不是什么稀罕事。但真拿到生产环境里用，你会发现它跟“创作工具”还有一段距离。

第一个顽疾是不可控。一个提示词生成十秒片段，可能前五秒非常满意，后五秒角色变形、场景错乱、光都变了。短视频还能靠多抽几次卡解决，长视频根本没法抽。第二个是不可连续。镜头和镜头之间的过渡，需要人物、场景、光线都保持一致，但单次生成模型根本不关心上一段在哪儿结束。你让它生成第二段的时候，它脑子里没有第一段。第三个是不可批量。真正的商业项目往往要三十条、五十条视频，工具化思路只能循环跑提示词，跑出来的结果还不统一，失败了也没法按原因去调整。第四个是不可审计。模型输出到底行不行，得靠人眼逐条看。没有自动评估，生成流程就没法和工程体系接上。

我习惯用一个类比来解释这事。单次生成模型就像一个手艺很好但只听“单张指令”的画工。你让他画一张猫，他画得不错；但你要一本连环画，他就傻了。连环画需要有人分页、设计构图、检查前后风格，哪一页画崩了还得让他重画。VideoGen-Agent 要做的事，就是给这个画工配上一个“策划加质检加统筹”的团队。

1.2 Agent 不是“自动调模型”，而是事务闭环

很多人容易把 Agent 理解成“自动把模型调起来”。这个理解太浅了。Agent 的核心能力，是能自己决定下一步做什么，并且对最终结果负责。落到视频生成上，就是一个可追踪的闭环：

理解意图 → 规划镜头 → 生成片段 → 质量检查 → 修复或重试 → 确认入库

这个闭环里的每一步，都要有清晰的输入输出，最好还能留下日志。否则出了问题，你只能对着一个黑盒干瞪眼。这也是 VideoGen-Agent 的设计核心：它不是去找一个更聪明的视频生成模型，而是把一层“会干活的智能管理外壳”套在现有模型外面。底座模型偶尔抽风没关系，只要整个流程能发现抽风、纠正抽风，最终交付质量就是稳定的。

2. VideoGen-Agent 的整体架构与四个关键模块

2.1 规划器：把一句话翻译成镜头表

规划器的输入很简单，就是用户原始描述；输出是一张分镜表。但这里有一个很重要的工程约束：不要让它自由发挥写散文，必须输出结构化字段。我们每个镜头都用固定的 JSON 结构，包含场景、景别、主体、运动、光线、镜头运动、时长、声音效果等字段。字段不全就视为规划失败，重新规划。

规划器有两个容易被忽略的门道。第一，提示词里要对输出格式做强约束，不只是说“请输出JSON”，还要在代码里做 schema 校验，不合法就重来。第二，规划器要有一点“镜头语言”常识。比如远景交代环境、中景交代动作、特写交代情绪。没有这个常识，它会把一段本来很连贯的画面切得稀碎，或者全程只用一个大全景，看得人昏昏欲睡。

还有一个很关键的取舍：为什么不直接让视频生成模型去完成“理解加规划加生成”这件事？因为现在很多视频模型的长上下文和复杂指令遵循能力还不够，你让它同一轮里既理解叙事、又规划镜头语言、还输出画面细节，结果往往是两头都做不好。拆开来做，让大语言模型规划文本镜头，让视频模型只负责“某一个瞬间的影像”，各干各擅长的部分，整体反而更稳。

2.2 执行器：多模型协作的出片工序

执行器不是一个简简单单的“文生视频接口”。实际出片需要组合多种模型：关键帧生成用文生图或图生图，用来锁定主体和构图；视频生成用文本或图像条件生成一小段动态画面；如果帧率不够，要加插帧模型；如果分辨率不够，还要加超分模型。执行器的工作，就是调度这些模型，并且统一管理生成参数。

这里有一个实操细节很多人不注意：不同镜头很可能需要不同的底座模型。人物特写用写实模型，场景空镜用风格化模型，效果会差很多。所以执行器里要维护一个“模型路由”，根据镜头类型动态选择模型。我给 VideoGen-Agent 初始设计模型路由时，就是按镜头类型和主体类型做两层判断：先看是场景镜头还是角色镜头，再看是写实还是风格化，最后决定走哪个生成模型。

生成参数也需要有讲究。CFG scale 控制提示词与画面的贴合程度，一般 7.5 左右；调高了画面更锐利，但容易发硬、出现过饱和；调低了画面自由发挥，但可能跟描述对不上。在 Agent 流程里，我们把它设在 7.0 到 8.0 之间，按镜头类型浮动。fps 和目标时长也会影响出片效果，我后面会详细说。

2.3 检查器：Agent 能不能自纠错，就靠这一环

检查器是 Agent 区别于“批量循环生成”的灵魂。如果没有检查机制，Agent 就退化成“把循环调用模型的代码写得好看一点”。VideoGen-Agent 里做了三层检查：

第一层，语义一致性。用 CLIP 把生成视频片段和镜头文本描述分别编码，算相似度分数。低于阈值就判断为不合格，比如你想让猫抬头看窗外，生成结果里猫却在睡觉。第二层，运动质量。用光流估计算运动幅度，如果运动幅度几乎为零，说明生成的是“静态图加极微小抖动”，这种视频看起来就像幻灯片。如果光流变化剧烈且混乱，说明物体穿模了。第三层，时序连贯性。用相邻帧差异判断画面是否闪烁或跳变，差异过大，多半是整体风格不稳。

检查器不能每一帧都全量跑，那样会慢到没法用。我们实际是抽帧检查：每个视频片段抽 8 到 16 帧，先跑快速的 CLIP 检查，再在疑似有问题的片段上追加光流分析。还有一个关键设计：检查不通过之后，不是简单粗暴地“重新生成一遍”。而是按失败原因分类处理。如果语义偏离，就换提示词变体重试；如果运动不足，就提高运动强度系数、增加动态描述；如果时序抖动，就加强插帧质量，或者把片段缩短重新生成。分类处理比盲目重试效率高得多。

2.4 记忆模块：跨镜头一致性的关键

视频生成 Agent 必须管“上下文”。这里的记忆分为几个层次：项目级记忆，保存角色外貌、场景设定、风格参考图；镜头级记忆，记录上一个镜头的最后一帧，作为下一个镜头的起始参考；经验级记忆，把之前失败的提示词和失败原因存下来，避免下次重复踩坑。

跨镜头“变脸”是视频生成 Agent 最常见的翻车点。我们实践下来最有效的一招是：先为每个角色生成一张参考图，锁定长相和服装，后续镜头都用“参考图加文本描述”做图生视频或条件生成，而不是每次都用纯文本从零开始。短期记忆（上一帧衔接）和长期记忆（角色库）配合使用之后，画面一致性会明显改善。这个模块初期容易被忽略，但一旦投入真实项目，它带来的稳定性提升非常可观。

3. 实操实录：搭一套 VideoGen-Agent 并跑通完整流程

3.1 软件栈和项目结构

理论讲完了，下面上真东西。我的环境是 Python 3.10 以上、PyTorch 2.x、CUDA 12.x。规划器接的是支持工具调用的大模型服务，视频生成用 Diffusers 体系加载本地模型，检查器用开源的 CLIP 和光流模型，调度用异步队列。这个组合的好处是每个环节都解耦，哪一环坏了能单独替换。

项目目录大概长这样：

videogen-agent/ ├── config/ │ └── config.yaml ├── agent/ │ ├── planner.py │ ├── executor.py │ ├── inspector.py │ └── memory.py ├── workflows/ │ └── video_pipeline.py ├── output/ └── requirements.txt

依赖安装可以直接写一个 requirements.txt：

torch>=2.1 diffusers>=0.27 transformers accelerate opencv-python clip imageio[ffmpeg] omegaconf openai

这里要提前说一句：视频生成模型很吃显存。想跑相对顺滑的流程，至少 16G 显存起步，720p 以上建议 24G。如果只是 CPU，前面规划部分能跑，但真正生成视频那一步基本等不起。先把硬件预期设对，后面才不会学到一半崩溃。

3.2 一份可落地的 config.yaml 参考

下面是一份精简但能直接起步的配置。我把关键参数都写了注释，方便你根据自己的底座模型调整。

llm: provider: openai-compatible # 使用兼容接口的本地或云端模型 model: planner-model # 换成你实际使用的大模型 temperature: 0.2 max_tokens: 2048 video_backend: model_id: "stabilityai/svd" # 可换成你本地加载的视频模型 default_resolution: [768, 432] # 宽 x 高 num_frames: 12 fps: 24 cfg_scale: 7.5 motion_bucket: 40 inspector: clip_threshold: 0.28 motion_min: 0.3 ssim_min: 0.7 sample_frames: 8 pipeline: target_duration: 20 # 目标视频总时长，秒 max_retries: 3 parallel_workers: 2 preview_width: 512

逐个解释大家容易迷糊的几个参数。temperature 设低，是因为规划器需要稳定输出，理想值在 0.2 左右，太高容易每次产出不一样的分镜。motion_bucket 是运动强度档位，数值越大动作越剧烈，40 左右适合普通运镜和轻度动作。clip_threshold 设 0.28，是我在小批量验证集上试出来的平衡点。如果设到 0.35，重试率会暴涨，一条二十秒视频可能要跑四十分钟。质检是保底线，不是完美主义，这一点后面还会详细讲。

3.3 完整跑一次：橘猫、书桌、窗外的雨

我们用一个具体例子走完整链路。输入提示词是：

“橘猫趴在旧书桌上看窗外的雨，镜头缓慢推近，带一点怀旧和安静的文艺氛围。”

规划器输出的分镜表大概是这样的：

接着执行器拆分每个镜头。核心操作是：先把镜头描述里的主体词、动作词、氛围词拆出来，生成关键帧；再用关键帧加动作描述生成视频短片段。镜头 1 和镜头 2 之间因为有同一只猫的持续性，所以我们会从镜头 1 的最后一帧提取特征，注入镜头 2 的生成条件，而不是让它无中生有。

我实际跑的时候，检查器发现镜头 2 的 CLIP 分数只有 0.24，低于 0.28 阈值。原因是猫的姿态和“抬头”描述不符，生成结果里猫还在趴着。系统自动重试了一次，把动作描述从“抬头望向窗外”改成“头部微微抬起，凝视窗户方向”，第二次分数升到 0.31，通过检查。最后把四个片段按顺序拼接，统一调色，做交叉淡化，合成雨声和背景音，输出成片。

整个过程里，中间产物都会带镜头号、版本号和检查分数。这一步很重要，我吃过亏：第一次没做版本管理，重试的时候旧文件直接被覆盖，想对比前后效果都找不回来，排查起来特别痛苦。

注意：中间产物文件名务必带上镜头号、版本号、检查分数。否则重试几次之后，你根本不知道哪一版是好的，哪一版是坏的，整个流程就乱套了。

3.4 硬件与耗时参考

耗时和显存直接挂钩，这里给一组参考数据。单段 2 到 3 秒的视频片段生成加检查，在 RTX 4090 上大约 1 到 2 分钟；在 A100 上大约 30 到 60 秒。一个四镜头、二十秒左右的短片，加上一次自动重试，4090 全程大约 8 到 12 分钟，A100 大约 4 到 6 分钟。如果只出 720p 预览，时间能压缩到一半以下。

再说一个省算力的技巧：前期所有镜头先按低分辨率出片做 Agent 检查，质量达标之后再做超分放大。不要一上来就直出 1080p。低分辨率下跑一次检查的成本很低，你可以容忍 Agent 多试几次。整体效率反而比高分辨率一次过要高得多。

4. 实战避坑清单：Agent 文档里不会写的细节

4.1 规划器输出“自由化”是最大的坑

规划器跑久了你会发现，它产出的分镜表文字很漂亮，但一旦落进执行器就开始出事。最常见的是总时长对不上：几个镜头时长加起来和目标时长差了好几秒。其次是主体描述不一致：用户从头到尾说的是“戴帽子的人”，规划器在第三个镜头突然写成“黑帽男子”。语义上是同一个意思，但在程序里这就是两个实体，检查器没法判断这是同一角色，相当于凭空多了一个主角。

我们的解决办法是两层。第一层是在解析 JSON 时做硬校验，字段缺失直接判规划失败，重来。第二层是在提示词里加约束，分镜中的主体描述必须复用“主角词库”里的固定词组，禁止自己发明新词。尤其要设置“角色槽位”，告诉规划器整个视频只能出现哪些角色，新增角色会被自动拦截。

4.2 检查器阈值不是越高越好

第一次做质检模块的人，很容易陷入“阈值越高越好”的执念。我踩过这个坑：把 CLIP 阈值从 0.28 调到 0.35 之后，重试率一下子涨了很多，一条二十秒的视频要跑四十分钟，肉眼看起来的效果提升却微乎其微。原因很简单，视频生成模型本身有随机性，检查器设得太严，Agent 会把很多本来可用的片段也判为不合格，然后做无意义的重复劳动。

质检阈值应该基于一个小型验证集来标定。拿一批人工判断过“合格/不合格”的样本，跑一遍检查器，找一个让误杀率不至于过高的阈值。这才是工程化的做法，而不是拍脑袋把分调高。记住，质检是保底，不是完美主义。

4.3 无限重试与 “Agent execution terminated due to error”

Agent 在执行过程中最容易犯的病，就是无限重试。某个镜头一直不过，它就一直生成，把算力全部耗光，最后报 “Agent execution terminated due to error.”。这类错误几乎都会出现在三个地方：显存溢出、中间文件损坏、模型重复加载导致服务崩溃。尤其是超分步骤没有正确释放显存，跑几个镜头之后显存被占满，后面的模型根本加载不进来。

我的做法是给所有任务加三层保险。第一层是最大重试轮数，默认 3 次，超过就进入熔断。第二层是单镜头最长执行时间，超时就杀进程，防止死等。第三层是错误熔断：同一类错误连续出现 3 次，直接跳过当前镜头，并通知规划器把该镜头做简化处理。有了这三层，Agent 最少也能给出一个局部可用的结果，而不是把整条流水线卡死。

4.4 穿帮检查要交给原子化的小镜头

镜头越长，越难定位失败区域。一个镜头如果五秒以上，里面某个片段崩了，你很难说清楚是哪一秒、哪个环节出了问题。我把每个镜头都限制在五秒以内，一旦镜头出问题，立刻把这个镜头拆成更小的原子镜头去重试，而不是把整个镜头从头再来。这个策略既是质量措施，也是排障策略。它保证 Agent 的每一次修复都尽量“对症下药”，不会浪费算力去重新生成一个本来就没什么问题的片段。

5. Agent 化的视频生成适合用在哪，以及下一步想做什么

5.1 我认为最靠谱的落地场景

把整个流程跑通之后，我盘点过哪几类场景真正值得上 Agent，而不是单纯用工具抽卡。最适合的是批量电商短视频生成。商品角度固定、文案固定、只需要按 SKU 批量产出统一风格的演示视频。其次是教育口播配画面，长音频切成小节，每个小节自动配一段示意图或空镜。还有游戏和小说推广里的“镜头预演”，不要求成品级画面，但要求快，一天出几十个方向给团队选。

这些场景的共同特点是：时长短、批量大、质量要求是“稳定可用”而不是“奥斯卡”。Agent 的检查和修复能力，正好把“偶发好片”变成“稳定可用”。如果你需要的是一部精雕细琢、艺术表达很强的作品，那靠 Agent 全自动还是不行，它更适合做辅助工具，而不是替代人类导演。

5.2 从单 Agent 到多 Agent 协作

当任务量上来以后，单 Agent 一条流水线跑效率太低。最直接的优化是并行：几个镜头同时生成。但并行会带来一个新的问题——多个 Agent 同时回写同一份记忆时，很容易互相覆盖。比如两个 Agent 同时更新角色参考图，后写的人会把先写的人覆盖掉，导致生成结果前后不一致。我们用一个中心化的“项目状态表”来管理所有任务和中间文件，每个 Agent 只允许写自己的 slot，角色库等公共资源由控制节点统一读写。多 Agent 协调这件事，协议设计比模型能力更关键。

5.3 下一步：让记忆真正变“长期”

短期记忆，也就是镜头之间的衔接帧，已经能解决大多数一致性问题。但长期记忆还不够完善。一个项目做了一半，隔天继续做，角色最好能复用同一张参考图，而不是重新生成。我们正在把“角色库加风格库”持久化，把每个项目的核心资产，包括角色正脸、场景关键帧、色彩风格描述，统一存下来。这样下次再跑同类型视频，前期质量和效率都会好很多。这个方向一旦跑通，视频生成 Agent 就能从一个“项目流程工具”慢慢变成“个人创作团队”。

我实际折腾这段时间最大的体会是：视频生成 Agent 带来的不是“全自动出片”的神话，而是把视频生产过程变得可审查、可干预、可修复。你不需要全程盯在屏幕前抽卡，但每一步都有迹可循；出了烂片，你能一眼知道烂在哪一步，然后单独修那一步，而不是从头再来一遍。如果你正准备在自己的项目里接入视频生成，我的建议很直接：先把检查器和中间产物管理做好，再谈自动化。哪怕你暂时不搞 Agent，这两件事也能让纯手动流程的效率提升一半。最后分享一个实用技巧：第一次跑项目时，强制让 Agent 输出“镜头规划、失败原因、重试方案”三段日志。这个日志比成片更有价值，它是你理解整个系统、把 Agent 调到顺手的最快的路径。