OpenMontage 两套合成运行时怎么选：默认分工与各自的表达边界

在 OpenMontage 里，「这条片子用 Remotion 还是 HyperFrames」不是渲染那一步随手能改的实现细节。README 的原文规则写得很硬：运行时在提案阶段被选定，记进 render_runtime，并通过 edit_decisions 锁定；在运行时之间静默切换是一次治理违规（governance violation）。

也就是说，这个决定发生在你还没看到任何一帧画面之前。你得在纸面上判断，而不是渲两版对比着挑。既然如此，就值得把 README 到底写了什么、哪些是它的措辞、哪些是可以核对的数值，一条条摆开。

README 把它们并排放在哪一张表里

在 README 的 Composition & Rendering 一节里，这张表其实是三行：Remotion、HyperFrames、FFmpeg。

Engine	Type
Remotion	Local (Node.js)
HyperFrames	Local (Node.js ≥ 22)
FFmpeg	Local

FFmpeg 那行 README 描述的是核心视频装配、编码、字幕烧入、音频复用和调色——它不参与这道二选一，是两条路都要走的后段。真正互斥的是前两行。

Remotion 那行，README 列出的是：基于 React 的程序化视频——弹簧动画图片场景、数据揭示、章节标题、主视觉卡、TikTok 式逐词字幕、场景转场（fade/slide/wipe/flip）、Google Fonts、带淡入淡出曲线的音频，以及 TalkingHead 合成。这行末尾还有一句加粗的话很关键：当没有配置任何视频生成 provider 时，agent 生成静态图，由 Remotion 把它们变成完全动起来的视频。

HyperFrames 那行，README 列出的是：HTML/CSS/GSAP 程序化视频——动态排版、产品宣传片、发布视频、自定义动态图形、registry blocks（数据图表、颗粒叠层、着色器转场）、website-to-video 工作流，以及绑定骨架的 SVG 角色动画；并注明通过 npx hyperframes 使用，无需 checkout 整个 monorepo。

先把限定说清楚：以上两段都是 README 自己的能力清单，我们没有用这两套运行时渲染过任何东西，也没有任何画质、速度、稳定性方面的对比依据。README 在这里没有给两者做优劣排序，我们也不替它排。

默认分工：README 只给了两条半规则

README 在零密钥能力那节明确写了默认分工，原文口径是这样：

• Remotion 是数据驱动讲解片、以及任何使用既有 React 场景栈的需求的默认；
• HyperFrames 是动态图形密集、天然适合用 HTML + GSAP 表达的需求的默认，包括 character-animation 流水线的 SVG/GSAP 骨架输出。

第三条是指路：README 说完整的决策矩阵在 skills/core/hyperframes.md。这个文件我们没有读过，这里只提它的名字，不描述它里面写了什么——真要做正式选型，那份文件才是权威口径。

所以纸面上能拿到的判据只有两个半：内容形态（数据驱动讲解 vs 动态图形密集）、技术栈存量（有没有既有 React 场景栈）、以及一条硬绑定（character-animation 流水线默认走 HyperFrames）。除此之外的维度，README 没给，我们不编。

「锁定」这件事，在契约里有三处互相印证

运行时一旦定下来就锁住，不是 README 顺口一说，仓库里能找到互相印证的三处：

1. README 零密钥那节写的是「在提案阶段在 Remotion 与 HyperFrames 之间做选择，并锁定为 render_runtime」；
2. AGENT_GUIDE.md 里有一节标题就叫 “Present Both Composition Runtimes (HARD RULE)“——两套运行时必须都呈现给用户；
3. 同一份 AGENT_GUIDE.md 的 What Not To Do 里有一条：不要在没有事先告知用户的情况下更换 provider、模型或渲染路径。

这三条合起来的意思是：你在提案那一刻会（应该）同时看到两套运行时，选完就进 edit_decisions，后面 agent 想换得先跟你说。

需要提醒一句性质问题：这些都是写给模型看的约束文本，是契约条款而不是工程上的强制机制。契约里写「必须都呈现」，不等于你用的那个 agent 一定会照做；能不能落地取决于它当时的上下文。所以真到了提案环节，值得你自己确认一下 render_runtime 到底被写成了什么。

一处可以自己核对的数字：Node 18+ 和 Node ≥ 22

这一篇要落到的具体数值就在这儿，而且它是两处 README 文本之间的落差。

README 的 Quick Start 里，Prerequisites 一共四项：Python 3.10+、FFmpeg、Node.js 18+，以及一个 AI 编码助手。而上面那张 Composition & Rendering 表里，Remotion 的 Type 写的是 Local (Node.js)，没标版本；HyperFrames 写的是 Local (Node.js ≥ 22)。

两处口径不一致，以仓库当前状态为准。我不推断哪个是对的、也不猜为什么没同步，这里只说明它对你的影响到哪一步为止：按最低前置条件（Node 18）装出来的环境，可能达不到 HyperFrames 那行标注的下限。 至于会不会真的跑不起来、跑起来会怎样，我们没有安装和运行过这个系统，不做断言。

对应的动作也简单：在提案阶段考虑 HyperFrames 之前，先用 node -v（Node 自带命令，不是本项目的命令）看清本机装的是哪一档。如果你打算走 character-animation 这条默认绑定 HyperFrames 的路，这一步尤其别跳。

安装期的不对称：一个在仓库里，一个在 npx 后面

这两套运行时在仓库里的存在形态完全不一样，而这一条在能力表里是看不出来的，得回到安装那一节才有。

Remotion 有实体目录 remotion-composer/，README 的架构图把它标注为 React/Remotion 的视频合成引擎。没有 make 时的手动安装串里，它是明确的一步：

• macOS/Linux：python3 -m venv .venv && source .venv/bin/activate && python -m pip install -r requirements.txt && cd remotion-composer && npm install && cd .. && python -m pip install piper-tts && cp .env.example .env
• Windows PowerShell：py -3 -m venv .venv; .\.venv\Scripts\Activate.ps1; python -m pip install -r requirements.txt; cd remotion-composer; npm install; cd ..; python -m pip install piper-tts; Copy-Item .env.example .env

README 单独记了一条 Windows 已知问题：如果 npm install 报 ERR_INVALID_ARG_TYPE，改用 npx --yes npm install。对着上面那两串看一眼就明白它落在哪儿：整条手动安装串里 npm install 只出现一次，就在 cd remotion-composer 之后。也就是说这条已知问题对应的是 Remotion 这一侧的依赖安装步骤。README 只写到这里，会不会遇到、遇到之后是否照改就行，我们没有执行过，不做断言，实际以你本地的输出为准。以上安装串照抄自 README。

HyperFrames 在仓库里没有对应的目录，因为 README 明说它是通过 npx hyperframes 消费的，不需要 checkout monorepo。仓库里与它相关的文件是 lib/hyperframes_style_bridge.py，这个文件确实存在，内部实现我们没有读过，不展开。

这条差异落到决策上是：选 Remotion，依赖在 make setup / 手动安装那一步就落到本地了；选 HyperFrames，依赖是在用的时候由 npx 这条路径去拿的，而且它标着更高的 Node 下限。

零密钥路径下，两条各自的落点

README 的「What You Get With Zero API Keys」表里，两套运行时都在免费清单里——Composition (React) 是 Remotion，Composition (HTML/GSAP) 是 HyperFrames。也就是说，这道选择题不是「付费才有第二个选项」。

同一节给的两条接近免费的路径，正好各挂一个运行时：

• 图片型视频：Piper 念脚本，图片提供视觉，Remotion 把它们做成有打磨的剪辑；
• 本地角色动画：SVG 骨架、姿势库、GSAP 时间线，HyperFrames 渲染卡通角色表演到 projects/<project-name>/renders/final.mp4。

那个输出路径是 README 在这一节里唯一写死的一处落盘位置，值得记下来。README 只写到路径为止，产物具体是什么形态、跟另一条路的产物有什么差别，它没说，我们也不往下推。

顺带一个能自己数的结构性事实：这张零密钥能力表一共 7 行——Narration、Open footage、Extra stock、Composition (React)、Composition (HTML/GSAP)、Post-production、Subtitles。合成这一件事在 7 行里独占两行，两行并排列在同一张免费清单上，README 没有在这里标注主次。配合前面那条「提案阶段选定并锁进 render_runtime」的规则看，这道题在流程上确实是要被明确回答一次的，不是渲染时才浮现的实现细节。

一条纸面上的决策路径

把上面这些串起来，从你的处境倒推：

1. 先看流水线。如果走的是 character-animation，README 已经把 HyperFrames 写成默认，这一步基本没得选。
2. 再看内容形态。数据驱动的讲解片、要复用既有 React 场景栈——README 的默认是 Remotion；动态图形密集、你本来就想用 HTML + GSAP 表达——README 的默认是 HyperFrames。
3. 看有没有配视频生成 provider。一个 provider 都没配的情况，README 明写了 Remotion 那条「静态图变成完全动起来的视频」的兜底路径；HyperFrames 那行没有对应的表述。
4. 看 Node 版本。这是唯一一个你现在就能用一条命令查清的硬条件，先查再提案。
5. 看你介不介意依赖形态。要不要在装环境时就把 Node 依赖落到 remotion-composer/ 里，还是接受用的时候走 npx。

有几个维度我明确不比：渲染速度、成片画质、稳定性、上手难度、社区规模。README 没给这些的数据，我们也没有跑过这个系统，比了就是编。真需要更细的判据，去读 skills/core/hyperframes.md 里那份完整决策矩阵。

最后回到开头那条治理规则：因为选择被 edit_decisions 锁住，「先渲一版看看再换」在这套流程里本来就不是预设动作。真正的比较窗口是提案那一刻——那也正是 AGENT_GUIDE.md 要求两套运行时都摆出来的原因。把上面这五步在那一刻问一遍，比事后想换划算得多。

---

本文依据 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 原文为准，本文不构成法律意见。