一份 manifest 有哪些字段：从 `stability: beta` 说起

OpenMontage 把「一条流水线怎么跑」写成了 YAML，放在 pipeline_defs/ 下，一条流水线一个文件。agent 拿到你的需求之后要先读这份 manifest，才知道有哪些阶段、每个阶段归哪份 skill 管、什么时候停下来等你点头。

也正因为这样，manifest 是这个项目里最好核查的一层：README 讲的是这条流水线适合做什么，而真正把流程约束成形的是这些字段里的具体值。这篇就把一份 manifest 拆开看。

先说清楚我们读到了哪一步：样本是 pipeline_defs/documentary-montage.yaml，我们实读的是这份文件的前 70 行。scene_plan 之后的阶段内容，以及 pipeline_defs/ 下其余 12 份 manifest，我们都没有读过。所以下面出现的字段与数值只对这一份负责，别默认另外几条流水线也长这样。

顶层：六个字段先交代身份

文件开头是这样一段：

name: documentary-montage
version: "1.0"
description: >
  Retrieval-first thematic montage pipeline. Builds a semantic corpus of real-world
  footage from Pexels, Archive.org (Prelinger et al.), NASA, Wikimedia Commons, and
  Unsplash, then uses CLIP-based
  retrieval to fill slot descriptions from a thematic brief. The edit arranges clips
  by narrative beat with music sync and uniform color grade across mixed-era footage.
  Inspired by Adam Curtis / Chris Marker / Errol Morris tone poems.
category: documentary
stability: beta
default_checkpoint_policy: guided

name 是流水线标识，version 写的是 "1.0"，category 是 documentary。description 用 YAML 的折叠块写了一整段，里面点明这条流水线走的是检索优先的路子，素材来自 Pexels、Archive.org（Prelinger 等）、NASA、Wikimedia Commons 和 Unsplash，用 CLIP 检索去填充镜位描述，剪辑按叙事节拍排列并做音乐同步和统一调色；结尾还点名致敬了 Adam Curtis、Chris Marker、Errol Morris。

这段 description 的位置值得留意：它不是给人看的营销文案，是给 agent 读的上下文。agent 要靠这几句判断「用户这个需求是不是该走这条流水线」。换句话说，顶层这几行承担的是分诊的活儿——name 和 category 负责归类，description 负责说清这条路的取材方式和成片调性，让选错流水线这件事在最前面就能被拦下来。

stability: beta 是标题里那个字段

manifest 里有一个显式的稳定性标记，这条流水线自己标的是 beta。

这个字段的价值在于它是项目方自己在代码仓库里留下的口径，不是外人的评价。你在评估要不要把某条流水线放进日常工作流之前，先看这一行，比读十段 README 更省事。我们只在这一份 manifest 里见过它取 beta 这个值，其它流水线标什么、有没有别的取值，本文不做推测。

顺带说一句边界：stability 是一个自述标记，它告诉你项目方怎么定位这条流水线的成熟度，不等于任何关于稳定性的保证或者不保证。看到 beta 该做的事是把预期调低一点、把人工检查留厚一点，仅此而已。

default_checkpoint_policy: guided

这一行和仓库根目录 config.yaml 里的全局 checkpoint 策略默认值是同一个值 guided。两处出现同一个键名的意义不在于值恰好相同，而在于流水线这一层有资格写这个字段——也就是说 checkpoint 策略可以被单条流水线覆盖，全局默认只是兜底。

reference_input：一个只有两行的能力边界

reference_input:
  supported: false

这条流水线的 manifest 明确写了不支持参考视频入口。这是 manifest 里最典型的「能力声明」型字段——它不控制流程细节，只回答一个是非题。这个字段单独拿出来能讲不少东西，我们另有一篇专门写它，这里只强调一点：读 manifest 的时候，这类布尔字段比阶段列表更值得先扫一眼，因为它决定的是「你这条路走不走得通」，而不是「怎么走」。

orchestration：治理旋钮都在这六行

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

mode 叫 executive-producer（执行制片），skill 指向同名的 skill 路径——也就是说编排这一层同样由一份指令文件承担。这与 AGENT_GUIDE.md 里写的分工是一致的：原文明写 Python 代码里没有编排逻辑、创意决策、评审逻辑或 checkpoint 策略，Python 提供的是工具与持久化。

后面四个数字是这份 manifest 里最硬的部分：默认预算 $1.00、每个阶段最多修订 3 次、最多打回 2 次、墙钟时间上限 60 分钟。

budget_default_usd: 1.00 这行要和全局对着看。config.yaml 的 total_usd 默认是 10.00，而这条流水线自己写的是 1.00——说明单条流水线可以带一个比全局更紧的预算默认值。这是可核查的结构事实。

同时必须说清楚它不是什么。这几个数字是 manifest 里的默认值，具体怎么被执行、超了会发生什么，取决于 config.yaml 里的预算模式和运行时的实现，我们没有运行过这个系统，也没有读全相关实现。所以别把这一行读成「花不超过一美元」，更不要拿它去推算你自己做一条片子要花多少钱——README 里那几个成本数字同样是项目方自己标注的金额，不是我们验证过的报价。

max_revisions_per_stage 和 max_send_backs 这两个上限则透露了另一件事：这套流程预设了「阶段会被打回重做」。修订和打回是两个不同的计数器，说明返工在设计里是常态路径，不是异常分支。

extensions：四个开关里只有一个是 false

extensions:
  custom_scripts: true
  custom_playbooks: true
  custom_skills: true
  custom_tools: false

自定义脚本、自定义 playbook、自定义 skill 都开着，只有 custom_tools 关着。

这是一条挺清晰的边界表达：这条流水线欢迎你改指令层的东西（skill 和 playbook 都是文本），但不接受你往里塞自定义工具。如果你的改造计划是「写个新工具挂进去」，那么在这条流水线上，第一步不是动手写代码，而是先确认这个开关。

required_skills：manifest 把 skill 列成硬依赖

required_skills:
  - pipelines/documentary-montage/executive-producer
  - pipelines/documentary-montage/idea-director
  - pipelines/documentary-montage/scene-director
  - pipelines/documentary-montage/asset-director
  - pipelines/documentary-montage/edit-director
  - pipelines/documentary-montage/compose-director
  - meta/reviewer
  - meta/checkpoint-protocol

8 条，结构很整齐：1 个执行制片 + 5 个阶段导演（idea / scene / asset / edit / compose）+ 2 个 meta skill（meta/reviewer 和 meta/checkpoint-protocol）。

这份清单和 AGENT_GUIDE.md 里 Rule Zero 那句收尾（原文：The intelligence is in the skills, not in improvised code）是对得上的：流程的每一步都对应一份 Markdown 指令文件，而且是写进 manifest 的硬依赖，不是可选的参考读物。评审（reviewer）和检查点协议（checkpoint-protocol）也被列在同一份清单里，和阶段导演平级。

这一点对读者的实际意义是：想知道某条流水线到底会怎么干活，光看 manifest 不够，required_skills 里列的每一份文件都得跟着翻。manifest 只给出骨架和闸门位置，具体每个阶段怎么做由那几份 Markdown 决定。同时也要记住这些 skill 的性质——它们是写给模型看的指令文本，列进 required_skills 表示这条流水线声明依赖它们，不代表运行时一定会被完整读到并照做。

再往下还有两行：

compatible_playbooks:
  custom_allowed: true

和 extensions 里的 custom_playbooks: true 是呼应的。

stages：字段模板长什么样

再往下是 stages。以第一个阶段 idea 为例，一个阶段用到的字段是 name、skill、produces、tools_available、checkpoint_required、human_approval_default、review_focus、success_criteria；到了第二个阶段 scene_plan，又多出一个 required_artifacts_in。

阶段之间的连接方式就藏在这两个字段里：上一阶段 produces 出一个 artifact 名字，下一阶段用 required_artifacts_in 声明自己要吃哪几个。依赖关系是按 artifact 名字连的，不是按顺序隐式连的。

idea 阶段本身有三处值得记：tools_available 是空数组 []（这个阶段不调任何工具），checkpoint_required: true 和 human_approval_default: true（第一个阶段就要人批）。至于 review_focus 和 success_criteria 里那几条具体标准，够单独写一篇，我们另有一篇专门拆一个阶段的字段结构，这里不展开。

读一份陌生 manifest 时，先看哪几行

把上面的顺序倒过来，就是一份可以复用的检查路径：

1. stability —— 项目方自己怎么标这条流水线的成熟度
2. reference_input.supported 这类布尔能力声明 —— 先确认路走不走得通
3. orchestration.budget_default_usd —— 这条流水线自带的预算默认值，和 config.yaml 的全局值对着看
4. extensions 的四个开关 —— 你打算做的改造属于允许的那一类吗
5. required_skills —— 这条流水线依赖哪些 skill，缺一份就是缺一环
6. stages 里每一阶段的 checkpoint_required 与 human_approval_default —— 你要在哪几处停下来看

最后补一句计数上的事实：pipeline_defs/ 目录下我们数出 13 个 .yaml 文件，其中 framework-smoke.yaml 从名字看是冒烟测试用的。这个数字和 README 里的说法对不上，本批另有一篇专门讲那组数字的差异，这里只陈述我们数出来的结果，不做推断。

---

本文依据 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，请以仓库最新内容为准。 安全相关做法请结合自身环境评估，本文不构成安全方案建议。