五道质量闸：从人类审批到渲染前拦截

2026-08-09

看 OpenMontage 的 Production Governance 一节，很容易把那五条读成一份 QA 检查清单——好像它们是并列的、渲染完一起跑一遍。其实不是。这五道闸分布在链条的三个不同位置上：有的在任何创意决策之前，有的卡在合成之前，有的在渲染之后才启动。搞清楚每道闸站在哪，比记住它们叫什么有用得多。

README 这一节的开篇原话是：OpenMontage 像对待真正的工程那样对待视频制作，每个阶段都有质量闸、审计链路和强制执行。这是项目方自己的措辞，下面我尽量把它换算成能查证的东西。

第一道其实排在最前面：源素材探测

按 README 的顺序，Source media inspection 排在第五条，但它触发的时机是整条链上最早的。规则是：当用户自带素材时，系统会探测每一个文件——分辨率、编码、音频声道数、时长——并在做出任何创意决策之前建立规划推论。

这一条的原文金句值得抄下来：No hallucinating content from filenames.（不许从文件名幻觉出内容。）

放在 agent 编排的语境里，这句话的含义很具体。一个模型拿到 interview_final_v3.mp4 这样一个文件名，是完全可以顺着名字往下编的：编出它是一段访谈、编出它有人声、编出它大概多长，然后基于这些编出来的属性去写脚本。这道闸要求的是先探测再规划，把探测结果当成规划输入。对应的实现文件是 lib/source_media_review.py，产物契约是 schemas/artifacts/source_media_review.schema.json——这个 schema 的内部字段我们一个都没读过，这里只说明存在这样一份契约。

人类审批闸：落点在 checkpoint 写入器

README 对这道闸的定语是 enforced, not suggested（强制的，不是建议的）。会暂停等你签字的位置有五处：proposal、script、scene plan、生成出来的素材、以及 publish。评审在 Backlot 看板上可视化进行。

但这段里真正有信息量的不是”会暂停”，而是它把强制点放在了哪里。README 的原文写的是：checkpoint 写入器会拒绝一个没有记录批准的「已完成」闸控阶段；并且每一个被取代的 checkpoint 都会被归档，所以审计链路——包括闸的状态迁移——在修订之后仍然存活。

这个设计取向值得单独说一句。在一个”agent 就是编排器”的系统里，如果审批闸只写在 Markdown 契约里，那它就是一条写给模型看的指令，模型读不读、读了照不照做，取决于当时的上下文。而把校验放到 checkpoint 写入这一步，意味着这道闸的执行不完全依赖模型的自觉——想把某个闸控阶段标成”已完成”，就得有一条批准记录在。至于这段校验的代码怎么写、拒绝之后发生什么，我们没有读过那部分实现，不展开。

顺带说，“被取代的 checkpoint 归档”这条和审计链路是一套东西：决策日志跨所有阶段持久化，方向是让你事后能追溯输出为什么长这样。关于决策审计和那 20 份 artifact 契约，我们另有一篇专门讲。

渲染前拦截：三种阻断条件

Pre-compose validation 是本篇标题里”渲染前拦截”那半句。README 列了三种会阻断渲染的情况：违反交付承诺（举的例子是”动效主导”的视频里 80% 是静图）、幻灯片风险分为 critical、渲染器 family 缺失。这一条的原文理由很直白：在浪费 GPU 时间之前抓住坏掉的计划。

第一种阻断条件可以落到数值上。lib/delivery_promise.py 定义了八种交付承诺类型，其中 motion_led 那一行的 min_motion_ratio 是 0.7，源码内联注释写的是：至少 70% 的镜头必须是真实动效——视频/动画，不是 Remotion 幻灯片。README 举的”80% 是静图”正好是这条规则被踩穿的样子。八种承诺类型的全表和 0.7 这个数字本身，我们各有一篇专门讲，这里只用与阻断直接相关的这一行。

更关键的是这个模块的 docstring 说明了它想防的是什么：它要拦的最具破坏性的失败模式，是在用户不知情的情况下，从”动效主导”悄悄降级成”静图主导”。交付承诺在提案阶段设定并锁定；compose 阶段如果兑现不了，系统必须停下来问，而不是悄悄替换。

配套的实现细节里有一处很能说明设计意图：DeliveryPromise 数据类的 approved_fallback 字段只有两个具名取值——"animatic"（动态分镜）和 "still_led"（静图主导）——否则就是 None，而反序列化时的默认值正是 None。也就是说，“降级必须被显式批准”这件事在数据类这一层的落点，就是默认状态下没有任何被批准的回退路径（校验逻辑本身怎么用这个字段，我们没读过，不展开）。同一个数据类里另外两个默认值也一并记下：tone_mode 默认 "corporate"（可选 cinematic、educational、corporate、playful、raw 五个），quality_floor 默认 "presentable"（draft、presentable、broadcast 三档里的中间档）。

第三种阻断条件是渲染器 family 缺失。合成运行时的选择本身我们另有一篇专门讲，这里不展开——只补一句在本篇范围内查得到的事实：score_slideshow_risk() 的函数签名里同时带着 renderer_family 和 render_runtime 两个可选参数，而这个参数的 docstring 原文说得很清楚：评分逻辑当前对运行时是中立的——文字很重的 HyperFrames 合成和文字很重的 Remotion 合成一样”幻灯片化”；但这个参数仍然是契约的一部分，好让调用方把 runtime 和 family 一起记录下来。一个不参与打分、只为了让审计链路完整而保留的入参，比任何一句愿景描述都更能说明这套设计在意什么。

幻灯片风险：唯一给了明确数字门槛的那道闸

前面三种阻断条件里，只有幻灯片风险这一项在源码里能查到确切的判定门槛。lib/slideshow_risk.py 的模块 docstring 写得很完整：给一份视频计划打 6 个维度的分，每个维度 0-5 分，分越低越好，判定是这样四档：

Verdict:
  < 2.0: strong
  < 3.0: acceptable
  < 4.0: revise
  >= 4.0: fail — should not proceed to compose

average 是六个维度的算术平均，返回时 round(average, 2)。最后那句 should not proceed to compose 把这道闸和上一节的合成前拦截直接接到了一起——幻灯片评分不是一份参考意见，≥ 4.0 就是不该进 compose。

还有一个边界情况值得记住：scenes 为空时函数直接返回 average: 5.0、verdict: "fail"、dimensions: {}。没有场景等于满分最差、直接判失败，而不是返回一个”暂无数据”。这是一种防御性的默认取向：缺输入按最坏算。

六个维度分别是 repetition（重复）、decorative_visuals（装饰性视觉）、weak_motion（弱动效）、weak_shot_intent（弱镜头意图）、typography_overreliance（过度依赖排版）、unsupported_cinematic_claims（无支撑的电影感宣称）。每一维具体怎么打分，是六个 _score_* 私有函数在做，那部分代码我们没有读过，所以这里不描述它怎么判定”重复”——只能说存在这六个维度和上面这套阈值。

这里有一处措辞上的差异可以如实记下：README 那条写的是”幻灯片风险分为 critical 时阻断”，而模块 docstring 里的四个判定字面是 strong / acceptable / revise / fail，没有 critical 这个词。两处措辞不一致，以仓库当前状态为准，我不推断哪个是准的。

渲染之后还有一道

第五道是 Post-render self-review：每次渲染后运行时会跑 ffprobe 校验、在 4 个位置抽帧检查黑帧和坏掉的叠层、分析音量查静音和削波、核验交付承诺是否被兑现、检查字幕是否存在。README 给的收尾是：评审不通过，视频就不会被呈现。这道闸的五项检查我们另有一篇逐项拆，这里只标出它在链条上的位置——它是唯一一道拿成品文件当输入的闸。

这五道闸该怎么读

把位置理一遍，整条链大致是这样咬合的：素材探测在最前，喂给规划；人类审批闸沿途设了五处，强制点落在 checkpoint 写入；合成前那道闸同时接受交付承诺校验和幻灯片评分两路输入；渲染后那道闸对着成品跑技术检查。前四道拦的是计划，最后一道拦的是成品。

有两件事要说清楚，免得读出过强的结论。

一是性质。这五条里，能落到源码常量上的其实只有一部分——幻灯片的 2.0/3.0/4.0、min_motion_ratio 的 0.7、approved_fallback 默认 None，这些是文件里写死的数值，查得到。而”人类审批闸是强制的""评审不通过视频就不会被呈现”这类表述，是 README 的措辞；对应的执行代码我们没有逐行读完，所以只能转述，不能替它担保。

二是我们的位置。我们没有安装或运行过这个系统，没有让任何一道闸真的拦下过任何东西。上面每一个数字都来自读文件，不是来自跑流程。你要判断这套治理在你的场景里够不够用，最靠谱的做法是自己打开 lib/slideshow_risk.py 和 lib/delivery_promise.py 把阈值对一遍——本文引用的每一个数值都在这两个文件里，对照着看一遍比读任何转述都可靠。

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