OpenMontage 的七个阶段：research → proposal → script → scene_plan → assets → edit → compose

2026-08-09

翻 OpenMontage 的 README，最容易被当成排版装饰扫过去的，是这一行：

research -> proposal -> script -> scene_plan -> assets -> edit -> compose

README 给它的定语是「每条流水线都遵循同一套结构化流程」。这种句子在项目主页上太常见了，看多了会自动打折。但这一行在这个仓库里不是口号——它在 manifest 里是有字段、有依赖关系、有上限数字的。这篇就把这行箭头拆到能自己核查的位置上。

这行字的出处，以及它配套的那句解释

README 在给出这条链之后紧跟着解释：每个阶段都有一个专门的 director skill，是一份 markdown 指令文件，教 agent 到底怎么执行这个阶段。agent 读 skill、用工具、自检、把状态 checkpoint 下来，并在创意决策点上请求人类批准。

所以这七个词不是给人看的流程图标签，是给 agent 的执行分段：每到一段，先去读那一段对应的 markdown，再动手。

七个里最值得单拎出来的是第一个。README 用引用块特别强调了网络调研是一等公民的阶段：在写下脚本的第一个字之前，agent 会搜索 YouTube、Reddit、Hacker News、新闻站点和学术来源，收集数据点、受众问题、趋势角度和视觉参考，然后在一份结构化的 research brief 里为一切标注引用。README 别处进一步把这个量化成 “15-25+ web searches”。

这个数字是 README 自称的，我们没有跑过任何一次制作，也没有验证过实际会搜多少次，转述到此为止，不做延伸。真正能核查的部分是「research 被当成一个独立阶段」这件事本身——它有名字、有位置、排在 script 前面，而不是揉进写脚本那一步里顺手做掉。一个阶段一旦被单列出来，就意味着它在这套结构里可以有自己的产出物、自己的验收标准和自己的检查点，下面拆 manifest 的时候会看到这几样东西具体长什么样。

箭头落到文件里长什么样

要看这行箭头怎么被写成配置，最方便的样本是 pipeline_defs/documentary-montage.yaml。先说清边界：pipeline_defs/ 目录里实读有 13 个 .yaml，我们只读了这一份，而且只读了前 70 行。这一节出现的所有字段都来自这 70 行，其余流水线、其余阶段一律不描述。

这份 manifest 的顶层元信息是这样的：

name: documentary-montage
version: "1.0"
category: documentary
stability: beta
default_checkpoint_policy: guided

stability: beta 是一个显式的稳定性标记，写在 manifest 里，不是我们的评价。default_checkpoint_policy: guided 与全局 config.yaml 的默认值一致，说明这个策略是可以由单条流水线覆盖的——同一个键在两层里都能出现。

阶段之间的箭头，本质是 artifact 名字

七个词之间的 -> 具体靠什么连起来？看阶段定义就明白了。第一个阶段：

stages:
  - name: idea
    skill: pipelines/documentary-montage/idea-director
    produces:
      - brief
    tools_available: []
    checkpoint_required: true
    human_approval_default: true

第二个阶段的开头：

  - name: scene_plan
    skill: pipelines/documentary-montage/scene-director
    required_artifacts_in:
      - brief

上一阶段 produces 出一个叫 brief 的 artifact，下一阶段用 required_artifacts_in 声明自己要吃 brief。箭头就是这么来的：不是靠顺序号，是靠 artifact 的名字对上。

这一点对读者有直接用处。你想知道某条流水线的某一步到底交出什么东西、下一步凭什么开工，不用去猜，也不用读代码，打开对应的 pipeline_defs/<pipeline>.yaml，把 produces 和 required_artifacts_in 对着看一遍就是答案。顺带记住一件事：在这份 manifest 里，把两步真正绑在一起的键是 artifact 名（brief），而不是阶段名（idea、scene_plan）。这两套名字是分开的，读 YAML 的时候别把它们混着找。

一个阶段里有哪些字段

把这两段合起来数，manifest 的阶段 schema 是这么几个键：name、skill、produces、tools_available、checkpoint_required、human_approval_default、review_focus、success_criteria，以及后续阶段出现的 required_artifacts_in。

从 idea 这一个阶段就能读出三条硬事实。

第一，tools_available 是空数组 []。这个阶段不调任何工具，纯产出一份 brief。也就是说，检索素材、生成画面、渲染这些真正干活的能力，在流水线的第一步是被显式清空的：这一步只负责把想法定下来，工具留给后面的阶段。至于这样安排会带来什么样的开销差别，manifest 里没写，我们也没有跑过，不做推算。

第二，checkpoint_required: true 且 human_approval_default: true。第一个阶段就要人点头，不是等到出片前才让你看。

第三，review_focus 与 success_criteria 这两栏才是阶段的真正含金量。idea 阶段的 review_focus 里写着：主题问题必须是一句话、调性取值必须来自固定清单、时长与形态要具体，然后是三条关于内容元素的规定——music plan 标了 MANDATORY，end-tag plan 也标了 MANDATORY（原文说明是一句收尾的哲思句，作为 Remotion end-card 渲染，默认 mode 为 overlay 叠在最后几个场景上），只有用户显式选择退出才能没有；而 narration 本身标的是 OPTIONAL，原文给的理由是音乐 + 视觉 + end-tag 撑得住调性的话，没有旁白也行。

success_criteria 则把这些要求收成可判定的条目：brief 要 schema 合法、thematic_question 要在 metadata 里、music_plan 要在 metadata 里（source 为 none 仅在有用户显式退出说明时允许）、end_tag_plan 要在 metadata 里（含 text、palette、duration、mode，为 null 同样需要显式退出说明）。

换句话说，「阶段」在这个系统里不只是一个执行分段，还自带一张验收单。想知道某个阶段会拿什么标准卡你，看的就是这两栏。

箭头不是只能往前走

README 那行链条画的是单向流，但 manifest 里明确写了往回走的额度：

orchestration:
  mode: executive-producer
  skill: pipelines/documentary-montage/executive-producer
  budget_default_usd: 1.00
  max_revisions_per_stage: 3
  max_send_backs: 2
  max_wall_time_minutes: 60

编排模式叫 executive-producer（执行制片），并且指向一份同名 skill。每个阶段最多修订 3 次、最多打回 2 次、墙钟时间上限 60 分钟。budget_default_usd: 1.00 这条也值得对照着看：全局 config.yaml 的 total_usd 默认是 10.00，而这条流水线自带的默认预算是 1.00，说明单条流水线可以给自己设更紧的额度。这些都是配置里的默认值，不是花销预测，你实际会花多少取决于你走的路径，manifest 管不了这件事。

配套的 required_skills 一共 8 条：1 个执行制片（pipelines/documentary-montage/executive-producer）、5 个阶段导演（idea / scene / asset / edit / compose，路径形如 pipelines/documentary-montage/idea-director）、2 个 meta skill（meta/reviewer 和 meta/checkpoint-protocol）。manifest 直接把 skill 列成硬依赖，这一点和「流程写在文本里、agent 读文本执行」的整体架构是一致的。

一处对不上的命名，说完就停

README 那行通用阶段流的七个词是 research、proposal、script、scene_plan、assets、edit、compose。而我们实读的这份 manifest 里，第一个阶段的 name 是 idea，不是 research；required_skills 里列的五个阶段导演是 idea、scene、asset、edit、compose。两处命名对不上。

按仓库当前状态陈述到这里为止。我们不推断哪一处是准的、为什么会这样，也不拿这个差异去评价这个项目。要提醒的只有一件事：如果你打算按 README 那七个词去某份 manifest 里搜 name: research，可能搜不到——以你打开的那份 YAML 里的实际 name 为准。

同样的边界还有一条：这份 manifest 我们只读了前 70 行，scene_plan 之后的阶段内容没读过，另外 12 份 manifest 也没读过。所以「每条流水线都遵循同一套流程」这句话，我们只能转述 README 的说法，不能替它作证。

拿这行箭头能干的三件事

回到实用层面。知道了阶段流的结构，有三个动作是你自己就能做的，不需要装任何东西。

想知道某条流水线在哪几步会拦住你要人批：打开对应 pipeline_defs/ 下的 YAML，逐个阶段看 checkpoint_required 和 human_approval_default。这两个键的取值就是答案，不用等跑起来才发现。

想知道某一步到底要交什么：看那个阶段的 produces 和 success_criteria。前者给 artifact 名字，后者给验收条目。

想知道卡在某一步会怎样：看 orchestration 里的 max_revisions_per_stage 和 max_send_backs，额度是写死的数字。

这三件事的共同点是——答案都在你 clone 下来的文本里，不在文档的形容词里。这个项目把流程写成了可读配置，那检查配置就是最省事的核实方式。至于每个阶段的 director skill 具体教了 agent 什么，那是另一批 markdown，我们没有读过，本文不描述。

本文依据 OpenMontage 官方仓库（github.com/calesthio/OpenMontage）的 README、 AGENT_GUIDE.md、config.yaml、pipeline_defs/ 与 lib/ 下的治理模块整理，核对日 2026-08-09。本文内容为仓库源码与文档口径，我们没有安装或运行过该系统，也没有调用过其中任何一个 provider API，文中出现的成本数字均为项目方在 README 中自行标注的金额，非我们的实测结果。该项目以 AGPL-3.0 发布，部分流水线在 manifest 中自标 stability: beta，请以仓库最新内容为准。