香港大学数据科学实验室 HKUDS 5 月 19 日把 ViMax 的代码库公开到 GitHub，仓库定位是”端到端的智能体视频生成框架”。三天内 Star 数从 0 涨到 6.0k，主要传播渠道是 X 上的 AI 视频圈层。它处理的是当下文生视频最难看的两个问题：单段时长太短、跨镜头一致性失控。
把视频拆成八个步骤再自动化
过去一年开源的视频生成工具大多止步于”输入提示词，输出几秒钟片段”。ViMax 的设计思路相反：它把传统影视生产流程拆成八个具体步骤——脚本生成、分镜设计、参考图筛选、镜头规划、人物一致性检查、并行镜头生成、多机位模拟、长片拼接——每个步骤都对应一个独立的智能体角色，通过中央 orchestration 层串成流水线。
仓库的 README 给了三种入口：Idea2Video（一句话生成完整故事片）、Novel2Video（小说自动改编为剧集）、Script2Video（剧本生成视频）以及 AutoCameo（用户上传一张照片就能把自己嵌入任意剧情成为客串角色）。这四个入口共用同一套底层 agent，只是 prompt 模板不同。
三处具体的工程细节
第一处是 RAG 长剧本生成器。直接把整本小说丢给 LLM 做改编会被上下文窗口卡死，ViMax 用 RAG 把长文档切成可检索的片段，再让 agent 在压缩剧情时按角色和关键情节做段落级召回，避免人物在长片中突然失忆。这套机制对 1M 上下文级别的模型（README 里推荐配 MiniMax-M2.7）效果最明显。
第二处是镜头并行生成。ViMax 把同一机位连续镜头的生成做成并行流，按 README 数据，长视频的整体生成时间因此被压缩；这一项的核心是把”同一场景下后续镜头的首帧”和”前一镜头的末帧”做严格对齐，强制色彩、构图和角色位置一致。
第三处是首帧一致性检查。视频生成器（默认接的是 Google Veo 系列）即便给了正确参考图也可能吐出走样的帧，ViMax 用一个 MLLM/VLM 并行生成多张候选首帧，再让模型自己挑出最一致的那一张，这种做法明显是模仿了人类导演 take 多遍后挑成片的工作流。
面向研究者还是面向创作者
从 quickstart 看，ViMax 还不是一键即用的 SaaS。仓库依赖 uv 管理环境，配置文件里要填 chat model、image generator、video generator 三个 API key，默认走 Google AI Studio 的 Gemini + Nanobanana + Veo 组合。也就是说，跑一次完整长片成本由用户的 Google API 配额决定，仓库本身不涵盖推理算力。
这种架构对研究者价值很高：它给出了”长视频一致性”问题的一个工程化答案，agent 间的交互协议、参考图索引、并行调度都能直接看到代码。对纯创作者来说门槛不低——配置 API key、读 yaml、调试本地路径都需要工程基础，更适合作为下一代视频工具的参考实现而不是直接生产工具。
真正稀缺的不是模型而是导演
视频生成这一年半已经经历了从”几秒片段”到”分钟级故事”的跃迁，但每一次跃迁的瓶颈都不在像素质量，而在叙事一致性。ViMax 的有趣之处是它没有再训新的视频模型，而是把现有 SOTA 视频模型（Veo、Nanobanana）当成最末端的渲染工具，把”导演判断力”外包给了 LLM agent。这个分层假设如果成立，下一波视频开源工具的差异化将集中在 agent 编排层，而不是基模型本身。HKUDS 在 README 里把”Technical Report”放在了 Coming Soon 里，技术细节披露不算彻底，但仓库已经能跑——对想做视频 agent 工程的团队，它至少省掉两三个月的脚手架时间。
参考链接：
