Rule Zero：所有制作都必须走流水线，五步与五条禁令

2026-08-09

如果只允许你读 OpenMontage 仓库里的一节文档，读 AGENT_GUIDE.md 的 Rule Zero。

原因很简单：这个项目把编排逻辑全放在文本里，Python 那边不负责决定流程该怎么走。既然没有代码在管流程，那么「流程长什么样」这件事就只存在于契约文本中，而 Rule Zero 就是那份契约里语气最硬的一节。

它在哪、它说了什么

AGENT_GUIDE.md 是一份 714 行的 agent 契约，我们实读到 46 个标题。Rule Zero 排在 First Interaction — Onboarding、Reference Video Entry Point 之后，标题全称是 Rule Zero — All Production Goes Through a Pipeline。这一节开头加粗的原文只有一句：

Every video production request MUST go through the pipeline system. No exceptions.

每一个视频制作请求都必须走流水线系统，没有例外。原文用 MUST 和 No exceptions 两个词把余地堵死了。适用范围写得很宽：用户要求 make / create / produce / generate 任何视频内容时——预告片、讲解片、短片、动画或其它——下面五步都要走。

五个必做步骤

第一步，确定流水线。 把请求匹配到 pipeline_defs/ 里的某一条流水线，原文补了一句「不清楚就问用户」（If unclear, ask the user）。这一句其实是整节里最容易被忽略的实操点：它承认「这个需求归哪条流水线」不是总能自动判定的，允许 agent 停下来问，而不是硬套一条最像的。仓库 skills/pipelines/ 下我们实读到 12 个子目录，一条流水线一个，名字像 explainer、documentary-montage、talking-head 这样直白。如果你想做的东西在这 12 个名字里找不到归属，第一步就会卡住，这是设计使然，不是 bug。

第二步，读流水线 manifest。 路径是 pipeline_defs/<pipeline>.yaml，原文说读它是为了知道有哪些阶段（stages）、工具（tools）和质量闸（quality gates）。注意这一步是「读」而不是「跑」——manifest 在这个架构里承担的是剧本角色，agent 得先知道全程有几站、每站卡在哪儿，才谈得上后面的逐阶段执行。顺带一提，manifest 里可能带自述的状态字段，比如 documentary-montage.yaml 里就写着 stability: beta，这类信息就在第二步这一眼里。

第三步，跑 preflight。 原文的动作是通过 registry 发现可用工具，并展示能力菜单（capability menu）。这一步的作用是把「理论上支持什么」换成「你这台机器上此刻真的能调什么」。契约里 Mandatory Preflight 一节下面还挂着 Provider Menu (Mandatory at Preflight)、Setup Offer Protocol 这些子标题，光看标题就知道 preflight 不是走个过场，Provider Menu 被标为 Mandatory。这几节的正文我们没有读过，不展开细则。

第四步，逐阶段执行。 原文是对每一个阶段，在该阶段做任何工作之前先读阶段导演 skill，路径规则是 skills/pipelines/<pipeline>/<stage>-director.md。原文里 EACH 和 BEFORE 两个词都用了大写，顺序被写死：先读，后做。

第五步，调工具前先读 Layer 3 skill。 判定条件很具体——使用任何带 agent_skills 字段的工具之前，先去读 .agents/skills/ 里被它引用的那份 skill。这个字段就是第五步的开关：工具声明了依赖，agent 就得补课。原文把这些 skill 的内容描述为 provider 专属的提示词指导、参数优化和质量技法，并称能显著改善输出——这是文档自己的措辞，不是我们的评价，我们没有跑过任何一条流水线，无从比较有没有读 skill 的差别。体量上，我们实读 skills/ 下 156 个 .md、.agents/ 下 567 个，相加 723 个，第五步指向的 .agents/skills/ 就在后面那一大堆里面。

这里有一处可以核实的差异值得记一笔。同一份 AGENT_GUIDE.md 的 What OpenMontage Is 一节也给了一个五步核心循环：选一条流水线 → 跑 preflight → 从 registry 发现真实工具 → 向用户呈现概念、工具计划、制作计划和成本 → 带 checkpoint 逐阶段执行。两个五步不是同一份清单：Rule Zero 里没有「向用户呈现计划和成本」这一步，核心循环里也没写「读阶段导演 skill」。两处口径不同，以仓库当前状态为准，我们不推断哪一份更完整。

五条禁令

Do NOT 后面跟着五条，逐条对应的其实都是「抄近路」的具体形态：

写临时 Python 脚本直接调工具
跳过流水线直奔 API 调用
在没读阶段导演 skill 之前就生成素材
用某个工具时不查它的 Layer 3 skill 里的提示词指导
绕过 preflight、checkpoint 或 review

把这五条和五步对着看，会发现它们是一一咬合的：第一条和第二条堵的是第一、二步（不走 manifest，自己写脚本或直连 API），第三条堵第四步，第四条堵第五步，第五条堵第三步以及后面的检查点与评审。这不是五条随手列的注意事项，是五步的反面写法。

第一条和第二条尤其针对熟手。一个能写 Python 的人翻完 tools/ 目录，最自然的反应就是 import 一个工具类自己拼个脚本跑——快、直接、看得见。这一节明确禁止的正是这个动作。原因在这一节的收尾金句里：The intelligence is in the skills, not in improvised code.（智能在 skill 里，不在即兴写的代码里。）绕过流水线省掉的不是样板代码，是 manifest 里那些阶段划分和质量闸，以及导演 skill 里的执行标准。

契约最后一节 What Not To Do 又列了十条，前三条基本是 Rule Zero 的复述，第一条还直接标了「见 Rule Zero」。那一节我们另有一篇专门讲，这里不重复。

这十条到底能不能被强制执行

这是读 Rule Zero 时最该保持清醒的一点。

AGENT_GUIDE.md 里写得很明白：Python 代码里没有编排逻辑、创意决策、评审逻辑或 checkpoint 策略，这些决策都由 agent 在指令引导下做出。反过来推一句：既然没有代码在管编排，那也就没有代码会在你绕过流水线时把你拦下来。Rule Zero 的十条是写给模型看的约束文本，是指令，不是运行时的闸门。它写了「必须先读导演 skill」，不等于装好之后模型一定会读；能不能落地，取决于你用的是哪个 agent、当时上下文里塞了多少东西、你自己有没有在中途催它抄近路。

想验证这一点，可以去看根目录的 config.yaml 里两个默认值：checkpoint.policy 默认是 guided（另两个可选值是 manual_all 和 auto_noncreative），budget.mode 默认是 warn（另两个是 observe 和 cap）。默认档位选的是「引导」和「警告」，不是「全部人工」和「硬性封顶」。同一份配置里 total_usd: 10.00、single_action_approval_usd: 0.50、reserve_pct: 0.10、require_approval_for_new_paid_tool: true 这几行也在——它们是配置里的默认值，不是我们验证过的行为，具体怎么执行请以仓库代码和官方文档为准。把这几行配好不等于就不会超支，真正拦住花销的仍然是你在每个创意闸上的批准动作。这里也不做「这样配就安全了」的结论。

所以 Rule Zero 的正确读法是：把它当成一份你和 agent 之间的协议，而不是一道系统防线。协议有没有被遵守，需要你自己检查——检查的抓手就是它规定的那些可核查产物：preflight 有没有真的展示能力菜单、每个阶段开工前有没有引用对应的 <stage>-director.md、checkpoint 有没有落盘。

什么时候你会想绕过它，以及绕过的代价

如果你只是想拿某个工具生成一张图看看效果，Rule Zero 显然是重的。契约不给这个例外，原文写的是 No exceptions。这时候你要清楚自己在拿什么换什么：绕过流水线换来的是快，付出的是这条链上后半段全部作废——README 描述的流程里，checkpoint 会把状态写成 JSON，可恢复，带决策日志和成本快照；合成之前还有一道校验闸，管交付承诺、幻灯片风险和渲染器治理；渲染完还有一轮自审。你手写的那个脚本不进这条链，上面这些东西一个都不会为它产生。

判断依据大致是这样：一次性的探索、想确认某个 provider 到底有没有配好，这类动作本来就该走第三步的 preflight 而不是自己写脚本；而只要产物是要交出去的成片，Rule Zero 要求的五步就没有哪一步是纯仪式——每一步都对应着后面某个闸门要用的输入。

最后提醒一句性质问题。README 里那些成本数字（几段演示视频各自标的总额、示例 prompt 那几档区间）都是项目方在 README 中自行标注的金额，不是我们的实测结果，也不能拿来推算你自己做一条要花多少钱；同样，文档里 dramatically improve、significantly better 这类说法是 README 与 AGENT_GUIDE.md 的措辞，不是我们的判断。仓库里有流水线自标 stability: beta，本地 LLM 支持在 README 里写的是 “Coming soon”——那就是计划，不是现有能力。读契约的时候，把这些一并计入预期。

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