一个阶段的八个字段：produces、review_focus 与 success_criteria

看 OpenMontage 的流水线 manifest，前半段那些 stability、orchestration、extensions 是流水线级别的元信息，读起来像项目说明。真正决定「跑起来会发生什么」的，是 stages: 下面每一项的那几个字段——它们是 agent 在这个阶段的行动依据。

这篇只讲一件事：一个阶段由哪些字段构成，每个字段管什么，review_focus 和 success_criteria 这两个看着像同义词的东西到底差在哪。

样本用 pipeline_defs/documentary-montage.yaml 的第一个阶段。需要先说清边界：我们只读了这份 manifest 的前 70 行，scene_plan 之后的阶段内容、以及其它几份 manifest，我们都没有读过，所以下文不会出现本文没引用的字段。

先把这一段原文摆出来

stages:
  - name: idea
    skill: pipelines/documentary-montage/idea-director
    produces:
      - brief
    tools_available: []
    checkpoint_required: true
    human_approval_default: true
    review_focus:
      - Thematic question is ONE sentence
      - Tone register is ONE value from the fixed list
      - Duration and shape are concrete
      - Music plan is present (MANDATORY — silent only if user explicitly opted out)
      - End-tag plan is present (MANDATORY — one philosophical closing line, rendered as Remotion end-card, default mode "overlay" on final scenes, unless user explicitly opted out)
      - Narration plan is present (narration itself is OPTIONAL — absence is fine if music + visuals + end-tag carry the register)
    success_criteria:
      - Schema-valid brief artifact
      - thematic_question present in metadata
      - music_plan present in metadata (source may be `none` ONLY with explicit user opt-out note)
      - end_tag_plan present in metadata (text, palette, duration, mode — may be `null` ONLY with explicit user opt-out note)

数一数，八个字段：name、skill、produces、tools_available、checkpoint_required、human_approval_default、review_focus、success_criteria。

标题说八个，严格讲是八加一。紧接着的第二个阶段多出来一个字段：

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

required_artifacts_in 只在有前置依赖的阶段出现。idea 是链条起点，所以它没有这一项。

顺带记一处可核查的命名差异：README 给的统一阶段流写的是 research -> proposal -> script -> scene_plan -> assets -> edit -> compose，而这份 manifest 的 stages 第一项名字是 idea，不是 research；scene_plan 则两处都在。差异摆在这儿，以仓库当前状态为准，我不推断原因。

produces 与 required_artifacts_in：依赖靠名字对齐

这两个字段是整条流水线的接缝。idea 阶段 produces: [brief]，scene_plan 阶段 required_artifacts_in: [brief]——同一个字符串 brief 把两个阶段串了起来。

这个设计有个直接后果值得记住：阶段之间的耦合不是靠顺序，是靠 artifact 名称。 你在 stages 列表里的排列顺序只是书写顺序，真正说明「谁等谁」的是这一对字段。所以要读懂一条流水线的实际形状，别按从上往下的顺序念，把每个阶段的 produces 和 required_artifacts_in 抄下来对一遍，才能看出哪几步其实互不依赖。

反过来，你自己改 manifest 的时候，最容易出错的也是这里：改了某个阶段 produces 的 artifact 名，就得同步改所有把它写进 required_artifacts_in 的下游阶段，否则依赖会断在一个纯字符串上。

skill：字段值要能在 required_skills 里找到

skill 指向一份 Markdown 指令文件的路径。idea 阶段指的是 pipelines/documentary-montage/idea-director，scene_plan 指的是 pipelines/documentary-montage/scene-director。

这两个值都能在这份 manifest 顶部的 required_skills 清单里找到——那份清单一共 8 条：1 个 executive-producer + 5 个阶段导演（idea / scene / asset / edit / compose）+ 2 个 meta skill（meta/reviewer、meta/checkpoint-protocol）。也就是说，manifest 把「这条流水线要读哪些指令文件」写成了硬依赖，阶段级的 skill 字段只是从这份清单里取一条来用。

这也解释了阶段字段为什么可以写得这么克制：具体怎么做，写在 skill 那份 Markdown 里，manifest 只声明用哪一份。 按 README 的说法，每个阶段都有一个专门的 director skill，agent 读 skill、用工具、自检、checkpoint 状态，并在创意决策点请求人类批准。

tools_available: []：这个阶段一个工具都不调

idea 阶段的 tools_available 是空数组。这不是「还没填」，它和 produces: [brief] 是配套的——这个阶段的产出物就是一份 brief 文本，不生成任何素材，自然不需要工具。

对读者的实际意义是：要知道一条流水线在哪几步会动用外部能力，先扫一遍各阶段的 tools_available 空不空。 空数组这一段不经手任何工具调用；非空的那几个阶段才是排查外部依赖失败时首先要盯的位置。至于调用工具会带来多少开销，manifest 这一层没写，orchestration 段只给了这条流水线的默认预算与时间上限，具体金额得看你实际接的是哪些服务，我们没有运行过，不做估算。

另外注意这个字段的名字是 available 而不是 required：它给的是这个阶段可用的工具范围，不是必须依次执行的清单。具体在这个范围里怎么挑，按前面说的分工，写在对应的 director skill 里，manifest 这一层不管。

checkpoint_required 与 human_approval_default：第一个阶段就要人批

这两个都是 true。链条的第一步就是一道 checkpoint，而且默认要人批准，不是跑到最后再让你验收。

manifest 顶部还有一行 default_checkpoint_policy: guided，与 config.yaml 里的全局默认一致——说明每条流水线可以覆盖全局的 checkpoint 策略，只是这条没覆盖。

要注意这两个字段的性质：它们是 manifest 里的声明，由读 manifest 的 agent 去执行，不是引擎层写死的开关。human_approval_default 里的 default 也提示了它是个默认值，不是不可改的硬约束。所以别把它当成「配了就一定会停下来等你」的保证；能不能真停下来，取决于执行这条流水线的 agent 是否照着契约走。

review_focus 与 success_criteria：这两个不是一回事

这是本篇最值得展开的一处。两个字段都是自然语言列表，都在讲「什么算好」，但看写法就能分出层次。

success_criteria 那四条长这样：schema 合法的 brief artifact、thematic_question 出现在 metadata 里、music_plan 出现在 metadata 里、end_tag_plan 出现在 metadata 里。全都是「有没有」「结构对不对」——是能一条条核对的闸门条件。

review_focus 那六条则是：主题问题必须是一句话、tone register 必须取自固定清单里的一个值、时长与形态要具体、music plan 必须在、end-tag plan 必须在、narration plan 要在。它们讲的是「写得对不对、够不够收敛」——是给评审那一步用的关注点，判断依据是读文本，而不是查字段存不存在。

用一句话区分：success_criteria 回答「这个阶段能不能过闸」，review_focus 回答「评审的时候该盯哪几处」。前者偏结构校验，后者偏内容质量。两者在这个阶段有重叠（music plan 和 end-tag plan 两边都提到了），但重叠的写法不一样：review_focus 关心它在不在、是不是被显式豁免；success_criteria 关心它作为 metadata 字段是否存在，并且写清了豁免时的合法取值——music_plan 的 source 可以是 none，end_tag_plan 可以是 null，但都只在有用户显式退出说明的前提下成立。

配套的还有 manifest orchestration 段里的三个上限：每阶段最多 3 次修订、最多 2 次打回、墙钟时间上限 60 分钟。也就是说评审不过是有后果的，但重试次数有封顶。

一处反直觉：旁白是可选的，音乐不是

review_focus 里那三条把话说得很明确：music plan 标了 MANDATORY，end-tag plan 标了 MANDATORY，只有用户显式选择退出才允许为空；而 narration 本身标的是 OPTIONAL，原文给的理由是「音乐 + 视觉 + end-tag 能撑住调性的话，没有旁白也行」。

按一般人对「AI 做视频」的想象，旁白往往是默认必备项，配乐才是可加可不加的装饰。这条流水线的默认判断反过来了。需要说清的是：这是 documentary-montage 这一条流水线的取向，它在 manifest 里自标 stability: beta；别的流水线怎么写，我们没读，不做推断。

end-tag 那条还顺带交代了实现细节：一句收尾的哲学式台词，渲染成 Remotion end-card，默认 mode 是 overlay、叠在最后几个场景上。这句话被写在评审关注点里，而不是藏在某个渲染参数里——manifest 里这类字段就是这么用的：把创意约定写成人和模型都读得懂的文本。

这套 schema 怎么用

如果你要读懂或改写一条流水线，按这个顺序看阶段字段效率最高：

1. 先扫 produces 与 required_artifacts_in，把 artifact 依赖图画出来，这决定了流水线的真实形状
2. 再看 tools_available，哪几段会真的去调工具，一眼就分出来了
3. 然后看 checkpoint_required 和 human_approval_default，标出人会被叫住的位置
4. 最后读 review_focus 和 success_criteria，前者告诉你这个阶段在乎什么，后者告诉你它卡在哪

最后重复一遍边界：本文引用的阶段字段与取值全部来自 pipeline_defs/documentary-montage.yaml 的前 70 行，另有两处转述自 README（统一阶段流那一行，以及每阶段配一个 director skill 的说法）。我们没有安装或运行过这个系统，也没有跑过这条流水线。这些字段的实际执行效果取决于读它的 agent，manifest 本身只是声明。

---

本文依据 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，请以仓库最新内容为准。