不是每条流水线都吃参考视频：`reference_input.supported` 这个字段

2026-08-09

选一个视频工具的时候，很多人第一个想问的是：我能不能扔一条我喜欢的片子进去，让它照着那个感觉做一条我的？

OpenMontage 的对外说法里确实有「从参考视频开始」这样一个入口。但如果你把它当成整个系统的通用能力，去随便挑一条流水线开工，可能会在很靠前的地方卡住。原因不复杂，也不需要跑起来才知道——它写在 manifest 里，是一个布尔值。

先看那两行

pipeline_defs/documentary-montage.yaml，顶层元信息之后紧接着的就是这个块：

reference_input:
  supported: false

就这样。没有条件、没有「部分支持」、没有降级说明，一个 false。

这条流水线是 README 那张流水线表里的 Documentary Montage 那一行，做的是主题蒙太奇——manifest 自己的 description 写的是 retrieval-first（检索优先）：从 Pexels、Archive.org（Prelinger 等）、NASA、Wikimedia Commons、Unsplash 建一个语义素材库，再用基于 CLIP 的检索，按一份主题 brief 去填每一个镜头位的描述；剪辑按叙事节拍排列片段，配上音乐同步和跨不同年代素材的统一调色。description 末尾还点名致敬了 Adam Curtis、Chris Marker、Errol Morris 三位。

reference_input.supported: false 和上面那段 description 写在同一份文件的前二十行里。我不打算推断作者为什么这么设计、这两件事之间是不是因果关系；我要说的只是一个查证方法：manifest 顶层这几行连起来读，就是这条流水线对外声明的能力画像，而且它是可核查的文本，不是形容词。

这个字段在哪一层，为什么重要

OpenMontage 的架构决定了这类字段的分量。这个项目把「怎么做」放在 YAML manifest 和 Markdown skill 里，Python 那边只提供工具和持久化，编排由 AI 编码助手读文本来完成。所以 manifest 不是一份可有可无的元数据，它是 agent 实际会去读的那份说明书。

这带来一个对使用者很实际的推论：能力边界的问题，不要去 README 里找答案，去 pipeline_defs/ 下对应的那份 .yaml 里找。 README 讲的是这个系统想成为什么，manifest 写的是这一条流水线当前声明了什么。两者的粒度根本不一样——README 是整个项目共用一份，manifest 是一条流水线一份。

顺带说一句容易踩空的地方：pipeline_defs/ 里的文件名和 skills/pipelines/ 下的目录名并不是处处一一对应。我们实读 pipeline_defs/ 有 13 个 .yaml，skills/pipelines/ 有 12 个子目录，而 README 的流水线表是 11 行、正文另一处写的是 “12 production pipelines”。其中 animated-explainer.yaml 对应的 skill 目录名是 explainer，两边命名不完全一致；framework-smoke.yaml 看名字是冒烟测试用的，不在 README 表里；character-animation 在 pipeline_defs/ 和 skills/pipelines/ 里都有，但没进 README 那张表（README 别处提到过 character-animation 流水线的 SVG/GSAP rig 产出，说明它是真实存在的）。这些数字差异本身就是客观计数结果，以仓库当前状态为准，我不推断原因，也不拿它评价这个项目。这里提它只有一个用处：你想查哪条流水线支不支持参考视频，得按 pipeline_defs/ 里的实际文件名去找，不能按 README 表格里的展示名去猜。

明确一下我们没读过的部分

这一点必须说在前面，否则这篇文章就变成了误导。

我们读的是 documentary-montage.yaml 的前 70 行。这份 manifest 后面的阶段内容、以及另外 12 份 manifest，我们一份都没有打开过。所以：

可以说的是：documentary-montage 这条流水线的 manifest 里，reference_input.supported 是 false。
不能说的是：有几条流水线支持参考视频、哪一条支持、支持的那条是怎么支持的、这个字段是不是每份 manifest 都有。

这个边界不是客套。一个布尔字段在一份文件里为 false，推不出别的文件里是什么。你要知道自己那条流水线的答案，动作很简单：打开 pipeline_defs/ 下对应的 .yaml，在顶层找 reference_input 这个键，看它的 supported 值。找不到这个键也是一种信息，但那意味着什么，得看代码怎么处理缺省，我们没有读到那一层。

同一份 manifest 里，还有三处同样是「边界」的硬值

reference_input.supported 不是孤例。这份 manifest 的前 70 行里，写死的边界还有好几处，值得一起看，因为它们共同说明了一件事：这个项目习惯把限制写成字段，而不是写成文档里的一句提醒。

第一处是扩展开关：

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

四个开关，只有 custom_tools 是 false。也就是这条流水线允许你自定义脚本、自定义 playbook、自定义 skill，但不允许自定义工具。这跟 reference_input.supported 是同一种写法——一句形容词都没有，就是一个能被 grep 到的布尔值。

第二处是编排段的几个上限：

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（执行制片）。budget_default_usd 是 1.00，而仓库根目录 config.yaml 里的全局 total_usd 默认是 10.00——流水线可以自带一份比全局更紧的预算。另外三个是每阶段最多 3 次修订、最多 2 次打回、墙钟时间上限 60 分钟。这些数字同样是文件里写着的，不是我们跑出来的；具体怎么执行以仓库代码和官方文档为准，我们没有运行过这个系统。

第三处是顶层的 stability: beta。同一份 manifest 里还有 default_checkpoint_policy: guided，与 config.yaml 的全局默认一致——说明 checkpoint 策略也是可以按流水线覆盖的。

把这三处和 reference_input.supported: false 放在一起看，manifest 的角色就清楚了：它既是能力清单，也是限制清单。选型的时候，与其在 README 的介绍文字里找感觉，不如把候选那几份 yaml 的前几十行直接读一遍。

那这条流水线的「输入」到底是什么

既然不吃参考视频，它靠什么起步？答案在同一份 manifest 的 stages 段第一个阶段里。

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

idea 阶段的 tools_available 是空数组 []——这个阶段不调任何工具，产出物只有一个 brief。而 checkpoint_required: true 且 human_approval_default: true，第一个阶段就要人来批。

它的 review_focus 写了几条评审关注点：主题问题必须是一句话；调性档位必须是固定清单里的一个值；时长和形态要具体；音乐计划必须有（标了 MANDATORY，只有用户显式退出才能是静音）；end-tag 计划必须有（同样标 MANDATORY，一句收尾的哲理性文案，作为 Remotion end-card 渲染，默认 mode 是 “overlay” 叠在最后几个场景上）；旁白计划要在，但旁白本身是 OPTIONAL——原文给的理由是，音乐加视觉加 end-tag 能撑住调性的话，没有旁白也行。对应的 success_criteria 则要求 brief 是 schema 合法的 artifact，thematic_question、music_plan、end_tag_plan 要在 metadata 里，后两者只有带明确的用户退出说明才可以是 none / null。

所以这条流水线的起点不是「一条参考片」，而是一句主题问题加一组调性、时长、音乐和结尾的约定，并且这份 brief 要过一道人工批准。下一个阶段 scene_plan 的开头写着 required_artifacts_in: [brief]——阶段之间是靠 artifact 名称串起来的，produces 对应 required_artifacts_in。

顺便提醒一句：这些 review_focus、success_criteria 都是写给模型看的评审标准文本，是指令，不是自动生效的工程校验。写着 MANDATORY 不等于系统一定会拦住不合格的 brief，能不能落地取决于你用的 agent 和当时的上下文。

一条实用的自查顺序

如果你的目标就是「照着某条片子做一条」，建议这样确认，而不是先装再说：

先想清楚你要的成片属于哪一条流水线，按 pipeline_defs/ 里的实际文件名找到那份 .yaml；
打开它，先看顶层的 reference_input，再看 stability、extensions、orchestration 这几段；
如果 reference_input.supported 是 false，那「给一条参考片」这个入口在这条流水线的 manifest 层面就没有被声明——至于绕开这个声明会发生什么，属于我们没有读到的执行部分，这里不做推断；
再看 stages 里第一个阶段的 produces 和 review_focus，那才是这条流水线真正要你交的输入。

反过来，什么情况说明不是这个字段的问题：如果你查到的 reference_input.supported 不是 false，而实际效果不如预期，那就跟本文讲的这个边界无关了——那属于阶段执行、素材、评审或渲染环节的事，我们没有读到那些部分，也没有运行过这个系统，这里不做任何推测。

关于 manifest 的完整字段结构和 pipeline_defs/ 的计数差异，我们另有一篇专门讲。这一篇只想让一个字段被看见：在一个把流程写成文本的系统里，能力边界是可以 grep 的。

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