前面几篇文章，我们已经成功将 OpenMontage 启动并运行：配置好环境，通过 make demo 渲染出第一个零成本视频，体验了无需 API key 的图片动画与真实素材纪录片，还学会了从参考视频出发让 agent 生成差异化方案，以及如何接入各家 provider 并借助打分选择器挑选合适工具。

这些能力分布在不同的应用场景中，今天我们将它们串联起来，从一个更高维度审视 OpenMontage 如何组织一次完整的视频生产。答案就是 pipeline（生产流水线）。OpenMontage 内置了 12 条 pipeline，每一条都是一套从创意到成片的完整工作流。接下来，我们将逐一了解这些 pipeline 的功能、agent 如何选择，以及我们该如何使用它们。

Pipeline 概览

OpenMontage 将不同类型的视频制作抽象为不同的 pipeline，全部以 YAML 清单（manifest）的形式存放在 pipeline_defs/ 目录下。每条 pipeline 对应一个真实的制作场景，这些我们在入门篇曾提及，现在进一步展开：

此外还有一条 framework-smoke，它是一个最小的两阶段冒烟测试，用于验证框架本身是否正常，不参与实际生产。

这 12 条 pipeline 覆盖了相当广泛的需求：想做知识科普选 animated-explainer，想做吉卜力风动画选 animation，想剪一段电影感预告选 cinematic，想把一期两小时的播客拆成十几条社交短片选 clip-factory，想把视频翻译配音成其他语言选 localization-dub。

实际选择时，可以按几个问题来细分：

• 有现成素材吗？
  • 有自己的录屏 → screen-demo
  • 有一段长视频要拆条 → clip-factory / podcast-repurpose
  • 有别人的参考视频 → 任意 pipeline 配上参考输入（第三篇讲过的玩法）
• 从零开始，需要真人或数字人吗？
  • 要数字人讲述 → a vatar-spokesperson
  • 要真实动态素材、不要 AI 画面 → documentary-montage
  • 纯 AI 生成，再看风格：低成本动画走 animation，电影感预告走 cinematic，知识科普走 animated-explainer

Rule Zero

在动手之前，有一条贯穿 OpenMontage 的硬性规则，官方文档称之为 Rule Zero：任何视频生产请求都必须走 pipeline 系统，没有例外。

这条规则写在 AGENT_GUIDE.md 中。当我们让 agent 制作、生成、产出任何视频时，它必须：

1. 选定 pipeline：将请求匹配到 pipeline_defs/ 中的某一条；若不清楚则直接询问我们
2. 读 manifest：搞清楚这条 pipeline 包含哪些阶段、使用哪些工具、设置哪些质量门禁
3. 跑 preflight：通过 registry 发现当前可用的工具，呈现能力菜单（上一篇学习过）
4. 逐阶段执行：每进入一个阶段，先读取该阶段的 director 技能，再开始工作
5. 调工具前先读 Layer 3 技能：使用任何带 agent_skills 的工具前，先读取它引用的 provider 专属技能

相反，agent 被明确禁止以下行为：

• 编写临时 Python 脚本直接调用工具
• 跳过 pipeline 直接调用 API
• 未读 stage director 技能就生成资产
• 绕过 preflight、checkpoint 或 review

简单来说，我们应将每个视频需求视为一个 pipeline 选择问题：先选对流水线，再读清单，再读阶段技能，最后才动用工具。

Pipeline 的阶段流转

12 条 pipeline 各有侧重，但骨架是相通的。一条「从零全生成」的 pipeline（animated-explainer、animation、cinematic 等）大致包含以下七八个阶段：

1. research（研究）：上网调研选题，收集数据点、受众真实提问和视觉参考，产出带有出处的研究简报。
2. proposal（方案）：基于调研给出 2~3 个差异化概念和分项成本估算，等待我们拍板选择。
3. script（脚本）：将选定的概念写成逐句脚本和旁白文案。
4. scene_plan（分镜）：将脚本拆分为一个个镜头/场景，确定每个场景的画面内容和时长。
5. assets（资产）：按分镜逐个生成或采集素材，包括图片、视频片段、配音、音乐等。
6. edit（剪辑）：决定素材的排列、转场、卡点，产出剪辑决策。
7. compose（合成）：按照剪辑决策将素材渲染、拼合成最终视频。
8. publish（发布）：输出成片，并生成封面、说明等发布物。

不同 pipeline 会在这条主干上有所增减。以现成素材为主的那几条（screen-demo、clip-factory、hybrid、talking-head 等）不走 research/proposal，而是用一个更轻量级的 idea 阶段开场；documentary-montage 甚至没有 script，采集到素材后直接进入分镜；character-animation 则在脚本和分镜之间多插入了角色设计、骨骼绑定两步。但「先想清楚、再写脚本、再分镜、再生成资产、再剪辑、再合成」这条主线是一致的。

每个阶段都有一个专属的 director 技能（一个 Markdown 指令文件），手把手指导 agent 该阶段的操作：读技能、用工具、自审、过 checkpoint（阶段检查点），并在创意决策点请我们批准。例如 proposal（方案）之后通常设有一道人工批准，agent 会停下来等待我们点头再继续。

这里有一个重点值得强调：web research 被放在最前面。在写下脚本的第一个字之前，agent 会先去搜索 YouTube、Reddit、Hacker News、新闻站和学术来源，收集数据点、受众真实提问、热门角度和视觉参考，整理成结构化的研究简报并逐条标注出处。这样产出的视频建立在真实、当下的信息之上，而非凭空编造。

Pipeline 清单详解

开头提过，每条 pipeline 都是 pipeline_defs/ 下的一份声明式 YAML 清单（manifest）。前面又讲了它有哪些阶段，这一节以 animated-explainer.yaml 为例，看看这些阶段和规则具体如何编写。

开头声明基本信息：

name: animated-explainer
version: "2.0"
description: >
  Generated explainer video from topic/idea - fully AI-produced
  with narration, visuals, and music.
category: generated
stability: production
default_checkpoint_policy: guided

这几行相当于 pipeline 的「身份证」：name 是标识，description 一句话说明其产出，stability: production 表示经过完整审计、可放心使用（即表格中的稳定性一列）。

category 是它的大类，共七种：

• generated：纯 AI 从主题生成，不依赖现成素材（animated-explainer 属于此类）
• animation：动效、动画
• cinematic：电影感
• screen_recording：录屏
• talking_head：真人讲话
• hybrid：现成素材 + AI 补充
• custom：其他、自定义

default_checkpoint_policy 设定默认的检查点策略，共三档，本条使用的是 guided：

• guided（默认）：agent 在关键节点停下来征求我们的意见
• manual_all：每个阶段都需要人工审查，最稳妥但最繁琐
• auto_noncreative：非创意阶段自动放行，仅在创意决策点暂停，最省事

再往下是一段 orchestration，负责该 pipeline 的编排策略与预算：

orchestration:
  mode: executive-producer
  skill: pipelines/explainer/executive-producer
  budget_default_usd: 2.00  # 默认预算
  max_revisions_per_stage: 3  # 每个阶段最多返工 3 次
  max_send_backs: 3 # 最多打回上一阶段 3 次
  max_wall_time_minutes: 20 # 墙钟时间上限，防止 agent 在某个环节死磕，无限消耗时间和金钱

其中 mode 和 skill 借用了影视剧组的说法：这条 pipeline 由一个执行制片人（executive-producer）统筹全局，像监制一样管理预算进度、调度各阶段、把关质量。而下面每个阶段各配一位导演（director），是那一步的行家，只对自己这段负责（例如后面会看到的 proposal-director、research-director）。producer 统筹、director 各管一段，正好对应真实制作团队的分工。

接着是 stages 阶段列表，animated-explainer 共八个阶段：

stages:
  - name: research    # 研究
  - name: proposal   # 方案
  - name: script     # 脚本
  - name: scene_plan # 分镜
  - name: assets     # 资产
  - name: edit       # 剪辑
  - name: compose   # 合成
  - name: publish   # 发布

每个阶段都用同一套字段描述。我们以 proposal（方案）阶段为例展开：

- name: proposal
  skill: pipelines/explainer/proposal-director # 该阶段读取哪个 director 技能
  required_artifacts_in:
    - research_brief # 依赖上一阶段的产物
  produces:
    - proposal_packet # 本阶段产出的工件
    - decision_log
  checkpoint_required: true
  human_approval_default: true # 这一步需要人工批准
  review_focus: # 自审时需关注的点
    - Concept options are genuinely different
    - Cost estimate is itemized and honest
  success_criteria: # 验收标准
    - Schema-valid proposal_packet with at least 3 concept_options
    - approval.status is "approved" before proceeding

每个阶段都明确标注了：读取哪个技能、依赖什么、产出什么、是否需要 checkpoint、是否需要人工批准、自审关注哪些点、验收标准是什么。human_approval_default: true 意味着 agent 完成该步骤后会停下来等待我们确认才继续。验收标准往往是硬性指标，例如 research 阶段要求「至少 3 个数据点」「至少引用 5 个带 URL 的来源」，agent 读到这些就知道该做到什么程度才算合格。

阶段之间通过规范化的产物（artifact）衔接：research 产出 research_brief、script 产出 script、scene_plan 产出 scene_plan、assets 产出 asset_manifest、edit 产出 edit_decisions、compose 产出 render_report。每种产物都有对应的 JSON Schema 进行校验，存放在 schemas/artifacts/ 下；上一阶段的产物先通过校验，合法后才进入下一阶段。

以上看到的都是单条 pipeline 自身的 manifest。在其之上还有一层全局配置，位于项目根目录的 config.yaml 中：LLM、输出格式、路径等项目级默认设置都放在这里，预算也是如此。还记得前面 orchestration 中的 budget_default_usd 吗？那只是该 pipeline 单次运行的默认额度；config.yaml 中的这段 budget 管理的是整个项目的资金：

budget:
  mode: warn # observe | warn | cap
  total_usd: 10.00
  reserve_pct: 0.10 # 给重试和清理预留的余量
  single_action_approval_usd: 0.50
  require_approval_for_new_paid_tool: true

total_usd 是全局的总预算上限（$10），单条 pipeline 那 $2 的默认额度也包含在其中；single_action_approval_usd 和 require_approval_for_new_paid_tool 则是全局的批准规则：单次动作超过 0.5 美元，或者要启用一个新的付费工具，都会先询问我们再执行，不会偷偷刷高账单。

这套设计的好处在于，整条流水线的行为（阶段、工具、审查重点、验收标准、批准与预算策略）全部写在可读可改的 YAML 中，我们随时可以打开查看，甚至照着修改一份自己的配置；Python 那边只负责提供工具和持久化。这正是 agent-first 架构的精髓：将人类制作团队的经验，沉淀为 agent 能读懂的指令。

Prompt Gallery 实战

理论讲得差不多了，最后动手实践两个例子。这一节的示例都来自仓库中的 PROMPT_GALLERY.md，那是一份现成的提示词菜单，按花费和用途分好了组：有零成本就能跑的，有花费很低的，也有配置齐全、效果更好的；还按人群分类（老师、开发者、独立开发者、内容创作者）。每条都可以直接复制，挑一条丢给你的 AI 编程助手，它会按照 Rule Zero 选好 pipeline，逐阶段把视频做出来。下面分享两条我自己跑过的。

第一条是吉卜力风动画，走 animation pipeline，属于花费很低的那一档。

做一条 30 秒的吉卜力风动画：黄昏金光下，一座漂浮在云端的魔法图书馆。书本在书架之间飘荡，暖光透过彩色玻璃窗洒进来，一只小猫在书桌上打盹。

跑完十来分钟，就得到一条带镜头运动和配乐的动画短片。下面是我这次跑出来的效果：

第二条是电影感预告片，走 cinematic pipeline，偏向电影质感，花费和耗时都要高一些。

做一条 30 秒的电影感预告片，科幻设定：人类收到一条来自一千年后未来的警告。请使用动态视频片段、电影感配乐和富有张力的标题卡。

我跑出来的结果如下：

两条一对比就能看出来：同样是 30 秒，选择的 pipeline 不同，质感和花费可能差出一个量级。至于每个环节具体调用哪个工具、花多少钱，取决于你配置了哪些 key，你无需操心，agent 会按照上一篇讲的打分选择器，在当前可用的工具中自动权衡。如果你想要的是真实素材而不是 AI 画面，还可以试试 documentary-montage，它从 Archive.org、NASA、Wikimedia 等公开库检索真实片段并剪辑成时间线（第二篇细讲过），触发时在提示词中写明 use real footage only 即可。

具体做什么、做成什么样，完全由你决定。每个人跑出来的内容本就不同，与其照搬我的，不如打开 PROMPT_GALLERY.md，按预算和用途挑一条中意的，修改主体和风格，制作一条属于自己的视频。

小结

今天我们学习了 OpenMontage 的 pipeline 系统，回顾一下：

• 首先，我们认识了 12 条内置 pipeline。OpenMontage 将不同类型的视频制作抽象为不同的流水线，从 AI 全生成的讲解、动画、电影感预告，到录屏、数字人、长视频拆条、多语言配音和真实素材纪录片，基本覆盖了主流场景；具体选择哪一条，按「有没有现成素材、要不要真人、偏哪种风格」来细分即可。
• 随后，我们学习了 Rule Zero。这是贯穿全系统的一条硬性规则：任何视频生产都必须走 pipeline，agent 必须先选流水线、再读清单、再读阶段技能，最后才动用工具，不允许编写临时脚本抄近道。
• 接着，我们梳理了每个 pipeline 的阶段流转。从研究、构思，到脚本、分镜、生成资产、剪辑、合成，多数还有一步发布；每个阶段都配有专属的 director 技能手把手引导 agent 操作，而 web research 被放在最前面，确保成片建立在真实、当下的信息之上。
• 最后，我们打开一份 manifest，看清了 pipeline 到底如何声明。阶段、工具、编排预算、审查重点、验收标准、批准策略，全部写在一份可读可改的 YAML 中，再配合全局的 config.yaml；Python 只负责提供工具和持久化，真正的智能沉淀在这些技能和清单里。

至此，这个 OpenMontage 系列也暂时告一段落了。从安装环境，到零成本生成视频，从参考视频生成差异化方案，到工具发现、Provider 选择，再到今天的 Pipeline 架构，希望读完之后，你不仅知道 OpenMontage 能做什么，更理解了它为什么会设计成现在这个样子。

剩下的，就交给你去实践了。挑一条 pipeline，换一个自己的主题，跑出第一条真正属于自己的视频，也许比继续阅读更多文档更有收获。

参考

• OpenMontage GitHub 仓库
• OpenMontage README
• OpenMontage Prompt Gallery
• OpenMontage Agent Guide