表里 11 行、正文说 12 条、目录里 13 个：OpenMontage 数字对不上的那条流水线

2026-08-09

挑流水线这件事，在 OpenMontage 里比想象中容易踩坑：README 的流水线表格是 11 行，README 正文另一处写的是 “12 production pipelines”，而 pipeline_defs/ 目录里实读是 13 个 .yaml。三个数字，一个都不重合。

这不是什么玄学。差额落在两个具体的文件上，可以逐个数出来。

先把三组数字摆齐

README 表格：11 行。 按表格顺序，这 11 条分别是 Animated Explainer、Animation、Avatar Spokesperson、Cinematic、Clip Factory、Documentary Montage、Hybrid、Localization & Dub、Podcast Repurpose、Screen Demo、Talking Head。每行还有 What It Produces 和 Best For 两列，讲各自产出什么、适合什么场景，这张表怎么读本批另有一篇专门讲，这里只用它的行数和名字。

README 正文：12 条。 同一份 README 的另一处写的是 “12 production pipelines”。

pipeline_defs/ 目录：13 个 .yaml。 实读清单如下：

animated-explainer.yaml   animation.yaml          avatar-spokesperson.yaml
character-animation.yaml  cinematic.yaml          clip-factory.yaml
documentary-montage.yaml  framework-smoke.yaml    hybrid.yaml
localization-dub.yaml     podcast-repurpose.yaml  screen-demo.yaml
talking-head.yaml

skills/pipelines/ 目录：12 个子目录。 一条流水线一个目录：

animation  avatar-spokesperson  character-animation  cinematic  clip-factory
documentary-montage  explainer  hybrid  localization-dub  podcast-repurpose
screen-demo  talking-head

四组数字，11 / 12 / 13 / 12。把它们对齐之后，差在哪里就清楚了。

第一处差额：`framework-smoke.yaml`

pipeline_defs/ 的 13 个里，framework-smoke.yaml 这个名字不出现在 README 表格里，也不在 skills/pipelines/ 的 12 个目录里。从文件名看它与冒烟测试有关——但这份 manifest 的内容我们没有读过，所以只能说到「它的名字如此」，它到底做什么、能不能当正经流水线用，本文不做判断。

把它从 13 里去掉，剩下 12 条，正好与 README 正文的 “12 production pipelines” 吻合，也与 skills/pipelines/ 的 12 个目录吻合。所以 13 与 12 这一层的差，就是这一个文件。

第二处差额：`character-animation`

12 与 11 的差，是 character-animation。

这条流水线同时出现在 pipeline_defs/（有 character-animation.yaml）和 skills/pipelines/（有 character-animation 子目录）里，但不在 README 那张 11 行的表格中。

它并不是 README 完全没提。README 别处确实写到过 “the character-animation pipeline’s SVG/GSAP rig output”，说明它是真实存在的流水线，只是没有进那张表。

更硬的一处交叉印证在 schemas/ 目录。我们实读 schemas/artifacts/ 下的 schema 文件名，其中有四个是 character_design.schema.json、character_qa_report.schema.json、pose_library.schema.json、rig_plan.schema.json——角色设计、角色 QA、姿势库、骨架计划。这四份 artifact 契约与 character-animation 这条流水线在主题上是对得上的。也就是说，同一条流水线在 pipeline_defs/、skills/pipelines/ 和 schemas/artifacts/ 三处都有对应实体，唯独在 README 的表格里缺席。

顺带说明：这些 schema 文件的内部字段我们一个都没有读过，这里只是按文件名说明「存在这样一个 artifact 契约」，不涉及它们的必填项或校验规则。另外 schemas/ 目录本身也是一处计数不一致的地方（README 写的数量与我们实读数出的数量不同），那处本批另有专篇细说。

到这里，三组数字各自的来源已经交代完了：README 表格漏了 character-animation，导致表格 11 行与正文 “12 pipelines” 对不上；pipeline_defs/ 比正文多的那一个是 framework-smoke.yaml。这些全部是我们数出来的客观结果。至于作者为什么没同步、哪个数字才「算数」、哪条流水线更成熟，我们不推断，也不拿这些差异去评价项目。说完就停。

还有一处命名不完全一致

顺着上面的清单往下看，还能发现一处：pipeline_defs/animated-explainer.yaml 对应的 skill 目录名是 explainer，两边命名不完全一致。文件名侧带 animated- 前缀，目录名侧没有。

这一条对使用者是有实际影响的——如果你打算靠「文件名和目录名同名」去自动定位一条流水线的 skill，这条会破例。同样，只陈述差异，不推断原因。

对不上的是「计数」，对得上的是「数值」

把这件事放大之前，值得先补一个对照，否则容易得出跑偏的印象。

我们把 README 的说法逐条对着仓库数过一遍。对不上的确实存在，而且都集中在计数类描述上：流水线表格的行数（11 行 vs 正文 12 条）、schemas/ 目录里的 JSON Schema 数量、TTS provider 的数量（README 的表格与架构图里写的数字不同）。后两处本批各有专篇细说。

但核心治理数值是逐项对得上的。举两处：README 说每一次工具选择都会跑一个 7 维评分引擎，权重是 30%/20%/15%/15%/10%/5%/5%，我们读 lib/scoring.py 第 38-44 行，加权求和里的七个系数与之逐项一致，相加正好 1.00；README 说预算默认总额 $10、单次动作审批阈值默认 $0.50、有 observe/warn/cap 三种模式，config.yaml 里写的也是 total_usd: 10.00、single_action_approval_usd: 0.50、mode: warn，三项全部吻合。

这个区分对读者有用：数一个目录里有几个文件，和读一段配置里的一个默认值，是两种不同强度的信息。 前者容易和文档写作的时间点脱节，后者是白纸黑字写在配置文件和源码里的值，改一行就能被 diff 出来。所以后面选流水线，我们只走后一条路。

那你该按哪份清单选流水线

结论其实很直接：以 pipeline_defs/ 为准，因为那才是 manifest 所在的地方。 README 的表格是一份写给人看的目录；manifest 这一侧则有 schema 兜着——我们实读 schemas/ 目录时，里面确实有一个 pipelines/pipeline_manifest.schema.json（这份 schema 的内部字段我们没有读过，只能说明它存在）。

但「目录里有个同名 yaml」不等于「这条流水线能满足你的需求」。判断依据要落到 manifest 的字段上。我们完整读过的样本只有一份——pipeline_defs/documentary-montage.yaml 的前 70 行，它足以说明 manifest 里有哪些可核查的东西：

顶层元信息：name: documentary-montage、version: "1.0"、category: documentary、default_checkpoint_policy: guided。最后这一项与 config.yaml 里的全局默认一致，但它出现在流水线自己的 manifest 里，说明每条流水线可以覆盖全局的 checkpoint 策略。
stability：这份 manifest 里写的是 stability: beta。稳定性是 manifest 里的一个显式字段，不是靠感觉猜的。
reference_input.supported：这份写的是 false。README 大力宣传「从参考视频开始」，但这条流水线的 manifest 里这个开关是关的——这是可核实的能力边界。不过我们只读了这一份 manifest，有几条流水线支持参考视频，我们不知道，也不推断。
extensions 四个开关：custom_scripts: true、custom_playbooks: true、custom_skills: true、custom_tools: false。四个里只有 custom_tools 是 false，即这条流水线允许自定义脚本、playbook 和 skill，但不允许自定义工具。
orchestration 那一段：mode: executive-producer，budget_default_usd: 1.00，max_revisions_per_stage: 3，max_send_backs: 2，max_wall_time_minutes: 60。这条流水线自带的默认预算是 $1.00，低于 config.yaml 里的全局 $10.00，说明流水线可以自带更紧的预算默认值。这几个是配置默认值，不是花销预测，别拿它推算你自己做一条要花多少钱。
required_skills：这份列了 8 个，1 个执行制片 + 5 个阶段导演（idea / scene / asset / edit / compose）+ 2 个 meta skill（meta/reviewer、meta/checkpoint-protocol）。manifest 本身就把 skill 列成硬依赖，这也是为什么 skills/pipelines/ 下那 12 个目录不是可有可无的装饰。
stages：每个阶段的字段是 name、skill、produces、tools_available、checkpoint_required、human_approval_default、review_focus、success_criteria，后续阶段还出现了 required_artifacts_in。阶段之间靠 artifact 名称建立依赖（produces → required_artifacts_in）。

这些字段的粒度有多细，看第一个阶段就知道。documentary-montage.yaml 里 idea 阶段的 tools_available 是一个空数组 []——这个阶段不调任何工具，纯粹产出一份 brief；同时它的 checkpoint_required 和 human_approval_default 都是 true，也就是第一个阶段就要人签字。它的 review_focus 里，music plan 和 end-tag plan 都标了 MANDATORY，只有用户显式选择退出才能为空，而 narration 本身写的是 OPTIONAL，原文给的理由是音乐加视觉加 end-tag 能撑住调性的话，没有旁白也行。这类取舍不会写在 README 的表格里，只有打开 manifest 才看得到。

由此可以整理出一套自查动作：先在 pipeline_defs/ 里确认有没有同名 .yaml；再看 skills/pipelines/ 下有没有对应目录（记住 animated-explainer 对应的是 explainer）；打开 manifest 看 stability 是什么、reference_input.supported 是不是 false、extensions 里哪几个开关关着；最后把 required_skills 里列的每一条对着 skills/ 目录点一遍。以上核查动作是按 manifest 字段语义整理的，我们没有在本机执行过，以你本地仓库里的实际文件为准。

另外要说清边界：我们只读了 documentary-montage.yaml 的前 70 行，scene_plan 之后的阶段内容，以及其它 12 份 manifest，我们都没有读过。上面那些字段名可以当作 manifest schema 的样子来理解，但每条流水线各自填了什么值，你必须自己去打开对应的那份 yaml。

一句提醒

README 原文说，每条流水线都遵循同一套结构化流程：

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

流程统一，不代表每条流水线的能力边界一样——reference_input.supported: false 那一行就是活生生的反例。所以别只看 README 表格里那句 Best For 就动手，真正要读的是 pipeline_defs/ 里那份 yaml。三组数字对不上这件事本身不值得放大，但它至少提醒了一件事：这个仓库里，README 是导览，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，请以仓库最新内容为准。许可条款请以官方 LICENSE 原文为准，本文不构成法律意见。