2.96 万 Star 的 OpenMontage，把 AI 视频生成做成了一套 Agent 剧组

大家好，我是若风。

最近看 AI 视频项目，我有一个很强的感受。

大家都在卷模型，卷 5 秒、10 秒、1080p、人物一致性、镜头运动。可真正折磨创作者的，往往不是单个镜头生成不出来，而是一条完整视频根本不像一个人做出来的。

脚本是一种气质，画面是另一种气质，字幕又突然像模板套出来的。最后看起来不是短片，是一堆素材被塞进了时间线。

calesthio/OpenMontage 想解决的正是这个缝隙。截止 2026 年 6 月 30 日，它拿到了 29,583 Star，3,328 Fork，主语言是 Python，协议是 AGPL-3.0。README 里那句口号很猛，世界上第一个开源的 Agentic Video Production System。

坦白讲，这种话我通常会先打个折。

但我把源码翻了一圈，发现它有意思的地方不在「能不能生成视频」，而在它把视频生产拆成了一套 Agent 能读、能执行、能审计的剧组流程。你不是点一个按钮等模型吐片。你把 Claude Code、Cursor、Copilot、Codex 这类 AI 编程助手放进一个仓库，让它按剧组手册干活。

这才是 OpenMontage 最值得拆的地方。

它不是视频模型，是一间写在仓库里的制片厂

很多 AI 视频工具的工作流是这样的，用户输入 Prompt，系统选择模型，生成素材，拼一下，导出。

OpenMontage 的结构完全不同。它把自己定义成 instruction-driven video production system。Python 不是总导演，Python 只负责工具和持久化。真正的编排逻辑，放在 YAML manifest 和 Markdown Skill 里，由 AI Agent 逐段读取。

这个选择很反直觉。

一般工程师会想，既然是复杂流程，那就写一个 orchestrator，把状态机、分支、回滚、审核全塞进代码。OpenMontage 偏偏反过来。它让代码只提供手和账本，让 Agent 读说明书做判断。

PROJECT_CONTEXT.md 里把架构分成三层。第一层是 tools/tool_registry.py，回答「有什么工具」。第二层是 skills/，回答「OpenMontage 里该怎么用」。第三层是 .agents/skills/，回答「底层技术本身怎么工作」。这三层连起来，像一个给 AI 编程助手准备的剧组知识库。

说真的，这比「又接了几个视频 API」更像新东西。

因为视频生产不是一个 API 调用。它是一串决策，选题、研究、脚本、分镜、资产、剪辑、合成、发布。任何一步偷懒，成片都会露馅。

OpenMontage 的核心判断是，既然现在的 AI 编程助手已经会读文件、跑命令、改代码，那就不要再造一个黑盒 SaaS。把制片厂写进仓库，让 Agent 自己照着流程推进。

这有点像把导演手册、器材库、预算表和质检单，全塞进 Git 里。

12 条流水线，靠 YAML 把「创意」变成合同

README 说它有 12 条 production pipeline。我核了一下源码，pipeline_defs/ 下面现在有 13 个 YAML，其中 framework-smoke.yaml 是测试用，剩下刚好 12 条生产流水线。

这不是随便列个菜单。比如 pipeline_defs/animated-explainer.yaml 里，一个动画解释视频被拆成 research、proposal、script、scene_plan、assets、edit、compose、publish 八个阶段。每个阶段都写明了要产出什么 artifact，要不要 checkpoint，要不要人类审批，成功标准是什么。

你想想看，这已经不是 Prompt 了。

这是合同。

proposal 阶段要求至少 3 个概念选项，成本估算要拆成 line items，还要得到用户批准才能继续。script 阶段要求字数和时长误差在 10% 内。scene_plan 阶段要求不能连续 3 个以上同类型场景。compose 阶段要求输出文件存在，并通过 ffprobe 验证。

更有意思的是，很多规则不是写给程序看的，而是写给 Agent 看的。比如 compose 阶段明确说，render_runtime 必须和 proposal 里锁定的一致，静默切换渲染引擎是 critical governance violation。

这句话如果写进普通代码注释里，可能没人看。但写进 pipeline manifest 里，Agent 每次执行到这个阶段都要读。它就从注释变成了操作规程。

这就是 OpenMontage 的第一层价值，把创意工作里那些「靠经验」的判断，尽量变成可读、可检查、可恢复的流程合同。

Tool Registry 是它的器材库，不是 imports 清单

第二个关键文件是 tools/tool_registry.py。

这个文件做的事情挺朴素，但位置很关键。它会遍历 tools/ 包，把所有继承 BaseTool 的具体类自动注册进来。每个 tool 继承自 tools/base_tool.py，带着同一套 contract，名字、版本、tier、capability、provider、runtime、依赖、输入输出 schema、fallback、agent_skills、成本估算。

表面看，这是一个插件系统。

但对 Agent 来说，这其实是器材库。

OpenMontage 不希望 Agent 靠记忆猜「我能不能用 Kling」「我有没有 FFmpeg」「这个任务应该用 Piper 还是 ElevenLabs」。它让 Agent 在 preflight 阶段读 registry，拿到 support envelope 和 provider menu，再把真实可用能力呈现给用户。

BaseTool.get_info() 里会返回工具的 usage_location，也就是这个工具类定义在哪个文件。video_selector 在执行成功后，还会把 selected_tool_usage_location、selected_tool_agent_skills、alternatives_considered 塞回结果里。

这点很实用。Agent 不只是知道自己选了哪个 provider，还知道为什么选、还有哪些候选、接下来该读哪些 Layer 3 Skill。

我粗略扫了当前源码，tools/ 里已经有 87 个 BaseTool 子类。这个数字和 README 里的 52 tools 或架构图里的 48 tools 对不上。我的理解是，仓库增长很快，README 的营销数字已经不是严格同步的工具清单。真要判断能力，应该看 registry，而不是看首页那几个数字。

这也算一个小提醒。

项目热的时候，文档里的数字会追不上代码。

选 provider，不是「谁能用就用谁」

OpenMontage 很容易被误解成「把一堆视频 API 包起来」。但 lib/scoring.py 和 tools/video/video_selector.py 说明它不是这么想的。

ProviderScore 里有 7 个维度，task_fit、output_quality、control、reliability、cost_efficiency、latency、continuity。权重也写死了，任务匹配占 30%，输出质量 20%，控制能力 15%，可靠性 15%，成本效率 10%，延迟和连续性各 5%。

这套权重不一定完美，但它至少承认了一件事。

视频工具选择不是「哪个可用」的问题，而是「哪个适合这条片子」的问题。

video_selector 里的 execute() 支持 rank 模式，能返回候选 provider 的排序和解释。正常生成时，它会先准备 task context，再过滤候选，再调用 rank_providers() 排名。成功后，结果里还会带上 selection_reason 和 alternatives_considered。

这个细节很重要。因为 Agent 最怕黑盒替换。用户说要真实运动镜头，系统悄悄退化成静态图加 Ken Burns，这种东西一眼就假。OpenMontage 至少在设计上把 provider 选择变成可解释记录，而不是靠模型当场拍脑袋。

坦率的讲，这也是我对它最有好感的一点。它没有假装 AI 视频是魔法。它承认这是一堆供应商、一堆本地工具、一堆 fallback 的组合，然后把选择过程写出来。

真正有意思的是 real-footage 路线

README 里最会营销的一点，是它反复强调自己不只是「拿几张图动一动」。它还有 real-footage documentary path，用免费或开放素材做真正的视频剪辑。

源码里这条线落在 pipeline_defs/documentary-montage.yaml 和 lib/corpus.py。

Documentary Montage 这条 pipeline 的描述很明确，它会从 Pexels、Archive.org、NASA、Wikimedia Commons、Unsplash 这些来源构建语义素材库，再用 CLIP 检索填充每个分镜 slot。它的 assets 阶段要求每个 slot 刚好选一个 clip，每个素材都要带 provider、original_url、license，标准路径下 corpus size 要大于 slot count 的 8 倍，检索分数要不低于 0.22。

lib/corpus.py 则是这条路线的心脏。它把本地素材库拆成 clips/、thumbnails/、embeddings.npy、tag_embeddings.npy 和 index.jsonl。JSONL 保持人类可读，npy 保持向量检索效率。每个 ClipRecord 里都有 source、source_url、license、duration、width、height、motion_score、dominant_colors 这些字段。

检索不是简单关键词搜。rank_by_text() 会融合视觉 embedding 和 tag embedding，默认 tag_weight 是 0.3，还可以用 motion_min 把死画面过滤掉。find_similar_set() 用 Maximal Marginal Relevance 做相似但不重复的素材集合，默认 diversity 是 0.3。diversify() 则在候选 clip 里贪心挑互相不太像的片段。

你看，这里就有点专业味了。

它不是说「找点素材」。它知道纪录片式 montage 最怕同质素材连着出现，也知道免费素材库里会有很多低运动量、像照片一样的视频。于是它把 motion_score、相似度、多样性都变成了可操作字段。

这条路线对独立创作者很有价值。因为不是每个人都要 Veo、Kling、Runway 生成所有镜头。很多时候，用真实公开素材剪出一条有节奏的片子，比硬生成更稳，也更便宜。

质量门禁，是它和玩具项目的分水岭

OpenMontage 最不像玩具的地方，是它到处在写「别把烂片交出去」。

lib/delivery_promise.py 里有一个很直接的设计，先分类 delivery promise。比如 motion_led 要求真正的运动镜头，min_motion_ratio 是 0.7，而且 still fallback 不允许偷偷发生。代码还特意把 Remotion 的 text_card、chart、kpi_grid 这类东西归为 animated slides，不算 real motion。

这句话听着有点狠，但很对。

很多所谓 AI 视频就是 animated slides。它有转场，有字幕，有动效，但不是视频。OpenMontage 至少在规则层面承认这两者不同。你承诺的是 motion-led，就不能拿一堆会动的 PPT 糊弄过去。

还有 tools/analysis/composition_validator.py，它会在渲染前检查 composition JSON。有没有 cuts，cut 的 out_seconds 是否大于 in_seconds，素材文件是否存在，旁白是否比视频更长，音乐是否比视频更短。这些检查不酷，但救命。

你做过视频就知道，最崩的不是模型生成失败，而是最后渲出来音频被截断、字幕错位、素材路径断了、时间线有洞。OpenMontage 把这些低级错误前置检查，方向是对的。

当然，这里也有个源码层面的瑕疵。CompositionValidator 把依赖写成了 binary:ffprobe，但 BaseTool.check_dependencies() 只处理 cmd:、env:、python: 三种前缀。更微妙的是，CompositionValidator.get_status() 直接返回 available。也就是说，按当前代码读法，这个工具的状态检查不会真的因为缺 ffprobe 而失败。

这不是致命问题，执行时 probe 仍然可能暴露错误，而且大多数用户装 OpenMontage 本来就会装 FFmpeg。可它说明一个现实，OpenMontage 的质量门禁设计得很认真，但实现层还有一些边角没完全收紧。

开源项目就是这样，理念很大，细节会慢慢补。

它的边界，不在生成能力，而在执行纪律

OpenMontage 的优势很明显，流程透明、可扩展、可审计，适合 AI 编程助手接管一条复杂生产线。

但它的使用门槛也不能装作不存在。

第一，它不是普通用户的一键视频工具。Quick Start 里需要 Python 3.10+、FFmpeg、Node.js 18+，然后 make setup。后面还要让 AI coding assistant 读仓库、跑流程、处理资产。你要的是 CapCut 式体验，这个项目不适合你。

第二，外部 provider 的钥匙很多。没有 API key 也能走 Piper、Archive.org、NASA、Wikimedia、Remotion、FFmpeg 这些免费路径，但如果要 FLUX、Veo、Kling、Runway、ElevenLabs、Suno，成本和账号复杂度会立刻上来。README 说「more keys = more tools」，这句话很诚实。

第三，bus factor 偏集中。GitHub contributors 接口里，calesthio 有 141 次贡献，第二名只有 6 次。仓库并未归档，2026 年 6 月 30 日还有 push，活跃度没问题。但这么大的系统如果主要靠一个人推进，后续稳定性要观察。

第四，AGPL-3.0 协议要认真看。做个人项目、内部实验问题不大。要把它改造成商业 SaaS，尤其涉及网络服务，AGPL 的义务不能当 MIT 用。

所以我不会把它推荐给「想今晚发 3 条短视频」的人。

OpenMontage 更像给另一类人准备的工具，愿意把视频生产当工程来做的人。你愿意读 manifest，愿意让 Agent 按阶段推进，愿意接受 checkpoint 和审批，愿意为了可复现牺牲一点一键爽感，它才有意义。

最后说两句，别只盯着模型

我一直觉得，OpenMontage 最值得迁移的不是视频领域本身，而是它背后的一个模式。

可以叫 Crew-in-Repo Pattern，仓库里的剧组模式。

它的核心不是「用 AI 做视频」，而是把一个复杂创作流程拆成四类东西。第一类是 pipeline manifest，定义阶段和成功标准。第二类是 tool registry，定义真实可用的手。第三类是 Skill 文档，定义每个岗位怎么干。第四类是 reviewer 和 checkpoint，定义什么时候停下来检查。

这套模式不只适合视频。

写研究报告可以这么做。做课程可以这么做。做产品发布可以这么做。甚至做开源项目维护，也可以这么做。

关键是别让 Agent 只拿到一个大 Prompt。给它一间工作室，里面有岗位说明、器材清单、预算规则、验收标准和停机条件。

你想想看，未来很多 Agent 产品可能都会走到这一步。单次调用会越来越便宜，真正稀缺的是流程设计。谁能把复杂任务拆成可读、可恢复、可验证的生产系统，谁就更接近真正能工作的 Agent。

OpenMontage 还不完美，文档数字会漂，依赖检查有边角，生态还很依赖主作者。

但它抓住了一个很重要的方向。

AI 视频的下一步，不只是更强的视频模型。

而是让 AI 学会像一个剧组那样工作。