OpenMontage 实战：用 AI 代理与 Remotion 构建代码驱动的视频生产流水线

1. 从“剪辑软件”到“代码驱动”：OpenMontage 到底在解决什么问题

第一次看到 OpenMontage 这个名字，加上 agentic、AI coding assistant、Remotion、Veo 这几个关键词，我脑子里冒出来的第一个判断是：这大概率不是又一个“拖拽式在线剪辑工具”，而是把视频生产这件事，往“代码化、可编排、可被 AI 代理接管”的方向推了一步。事实也确实如此。OpenMontage 的核心思路，是让 AI 编程助手（比如 Codex CLI 这类能在终端里读写文件、执行命令的代理）去操作一个基于 Remotion 的视频工程，把“写代码”和“出片子”这两件事缝在一起。

这件事为什么值得单独拿出来讲？因为传统视频剪辑的工作流里，人和工具的关系是“我操作界面，界面渲染结果”。而 OpenMontage 这类项目把关系改成了“我用自然语言描述意图，AI 代理去改代码，代码再渲染出视频”。中间那层图形界面被抽掉了，取而代之的是一套可版本控制、可复用、可批量生成的工程结构。对于需要批量产出内容、或者想把视频生产接进自动化流水线的人来说，这个转变的意义远大于“少点几下鼠标”。

它适合谁？我梳理了三类人。第一类是前端或全栈开发者，本来就熟悉 React 生态，Remotion 对他们来说几乎没有学习门槛，OpenMontage 只是把“用 React 做视频”这件事包装得更适合 AI 代理操作。第二类是内容团队里负责技术基建的人，需要一套能稳定批量出片的方案，而不是每次靠人工在剪辑软件里重复劳动。第三类是对 agentic 工作流感兴趣、想找一个真实可落地场景来练手的开发者——视频生成这个场景足够复杂，又足够直观，出片效果一眼就能验证对错。

需要先泼一盆冷水：OpenMontage 不是“输入一句话就出大片”的魔法。它的本质是把视频拆成可编程的组件（场景、字幕、转场、音频轨、素材引用），然后让 AI 代理在这些组件层面做增删改。你给它的指令越结构化、越贴近工程语言，它执行得越稳；你给一句“帮我做个炫酷的片子”，它大概率会给你一堆需要返工的代码。理解这一点，后面的所有操作才不会跑偏。

2. Remotion 作为底座：为什么是它，而不是别的方案

2.1 Remotion 的核心机制：把时间轴变成函数

要理解 OpenMontage，绕不开 Remotion。Remotion 做的事情，用一句话概括：它让你用 React 组件来描述视频的每一帧，然后通过一个渲染器把这些组件逐帧截图、编码成视频文件。视频里的“第 3 秒第 12 帧长什么样”，在 Remotion 里就是一个纯函数——输入是当前帧号frame，输出是这一帧的 DOM 结构。

这个设计带来的直接好处是：视频变成了确定性产物。同样的代码、同样的输入参数，渲染出来的结果完全一致。这对 AI 代理极其友好，因为代理改完代码后，可以通过重新渲染来验证改动是否符合预期，形成“改代码 → 渲染 → 看结果 → 再改”的闭环。相比之下，传统剪辑软件里的操作是状态化的、难以用文本描述的，AI 代理很难精确控制。

Remotion 里几个关键概念必须搞清楚，否则后面看 OpenMontage 的工程结构会一头雾水：

• Composition（合成）：一个视频工程的基本单位，定义了视频的宽高、帧率、总时长，以及用哪个组件来渲染。
• useCurrentFrame()：在组件里获取当前帧号的 Hook，所有随时间变化的动画都基于它计算。
• interpolate()：把帧号映射成任意数值区间，是做位移、透明度、缩放动画的核心工具。
• Sequence / Series：控制组件在时间轴上的出现时机和顺序，相当于剪辑软件里的“轨道”。

我实测下来，Remotion 最容易被低估的一点是它的spring()动画函数。很多人做视频动画习惯用线性插值，结果出来很生硬。spring()模拟的是物理弹簧，带阻尼和刚度参数，做出来的入场动画自然得多。OpenMontage 如果要在场景切换上做出质感，这个函数的使用频率会非常高。

2.2 为什么不用纯 FFmpeg 或模板引擎

有人会问：批量生成视频，直接用 FFmpeg 拼命令，或者用 After Effects 的模板加数据驱动不就行了？我对比过这几条路线，结论是各有适用场景，但 OpenMontage 选 Remotion 有它的道理。

关键差异在于“可被 AI 代理操作”这一条。FFmpeg 命令是线性的、难以局部修改的；AE 模板是二进制工程文件，AI 代理基本无法直接编辑。而 Remotion 工程就是一堆.tsx文件，AI 代理可以像改普通前端代码一样去改它，改完还能跑测试、跑渲染验证。这个特性决定了 OpenMontage 的技术选型。

2.3 Veo 在链路里的位置：生成素材，而非生成成片

关键词里出现了 Veo，这里必须澄清一个常见误解。Veo 这类视频生成模型，在 OpenMontage 的链路里扮演的是“素材供应商”角色，而不是“成片生成器”。也就是说，它负责根据文本提示生成一段几秒的镜头素材，这段素材再被 Remotion 工程当作staticFile或远程 URL 引用进来，参与后续的剪辑、叠加字幕、配乐。

为什么不让 Veo 直接生成整条片子？因为生成模型对时长、节奏、字幕、精确转场的控制力很弱，而且每次生成结果不可复现。而 Remotion 负责的是“确定性编排”——把生成出来的素材放到精确的时间点上，加上可控的动画和文字。两者分工明确：一个负责“无中生有”，一个负责“精确组装”。把这条边界划清楚，工程结构才不会乱。

3. 让 AI 代理真正干活的工程结构设计

3.1 目录约定：代理能不能干活，一半看目录

我踩过最大的一个坑，就是一开始把 Remotion 工程结构搞得太“自由”，结果 AI 代理每次改代码都要先花大量时间理解文件之间的关系，改出来的东西经常放错位置。后来我固定了一套目录约定，代理的命中率明显提升。这套约定不是 OpenMontage 官方强制的，但基于我对 agentic 工作流的理解，这是让代理稳定工作的合理实践。

project/ src/ compositions/ # 每个视频一个 Composition 入口 Main.tsx scenes/ # 场景组件，一个场景一个文件 IntroScene.tsx ProductScene.tsx OutroScene.tsx components/ # 可复用原子组件 Subtitle.tsx LowerThird.tsx Background.tsx data/ # 数据与配置，与视觉分离 script.json assets.json styles/ # 全局样式与主题变量 theme.ts public/ assets/ # 本地素材：图片、音频、生成的视频片段 remotion.config.ts

这个结构的关键在于“数据与视觉分离”。data/script.json里放的是文案、时间点、素材引用，scenes/里放的是怎么渲染。AI 代理改文案时只动 JSON，改视觉时只动组件，职责清晰，出错概率大幅下降。我试过把文案硬编码在组件里，结果代理每次改文案都要动 JSX，很容易顺手改坏结构。

3.2 给代理的“操作手册”：一份 AGENTS.md 顶十次对话

agentic 工作流里，最被低估的文件是给代理看的说明文档。Codex CLI 这类工具在进入项目时，会优先读取根目录下的约定文件（不同工具命名不同，常见的是AGENTS.md或类似约定）。这份文件写得好不好，直接决定代理是“一次做对”还是“反复返工”。

我总结的AGENTS.md应该包含这几块内容：

• 项目定位：一句话说清这是 Remotion 视频工程，产物是 MP4。
• 目录职责：每个目录放什么，禁止跨目录乱放。
• 命名规范：组件用 PascalCase，数据文件用 camelCase，场景文件以Scene结尾。
• 渲染命令：明确写出npx remotion render的完整参数，代理验证时直接用。
• 禁止事项：比如“不要修改remotion.config.ts的帧率”“不要在组件里写死文案，一律从 data 读取”。

提示：这份文档要写得像给新同事的交接说明，而不是给机器的指令集。代理对自然语言的上下文理解能力很强，但对隐含约定一无所知。你省下的每一句说明，都会变成后面的一次返工。

3.3 渲染验证闭环：让代理自己看结果

OpenMontage 这类项目最有价值的地方，是它能形成“代理改代码 → 渲染 → 检查 → 再改”的闭环。但这里有个现实问题：代理本身“看”不到视频。它只能看到渲染命令的退出码、日志输出，以及你额外提供的帧截图。

我的做法是在工程里加一个轻量的验证脚本，渲染完成后自动抽取几个关键帧存成 PNG，代理可以通过读取这些图片文件（多模态代理）或者通过像素级校验脚本来判断结果。对于纯文本代理，就退而求其次，让它检查渲染日志里有没有报错、时长是否符合预期、文件大小是否在合理区间。

# 渲染并抽取关键帧的验证脚本示例 npx remotion render src/index.ts Main out/video.mp4 --props=./src/data/script.json npx remotion still src/index.ts Main out/frame-check.png --frame=90

这个闭环听起来简单，但它是 agentic 视频工作流和传统“AI 生成视频”最本质的区别。传统方式你只能祈祷生成结果是对的，而这里代理有明确的验证手段，错了能自己修。我在实际项目里，把渲染验证脚本配好之后，代理独立完成一个 30 秒片子的成功率从大概三成提升到了七成以上。

4. 从零跑通第一条片子的完整操作链路

4.1 环境准备里最容易翻车的三个点

环境搭建这一步，看起来是体力活，但翻车点集中得惊人。我把踩过的坑列出来，你照着避。

第一个坑是 Node 版本。Remotion 对 Node 版本有要求，版本太低会在安装阶段就报奇怪的错。建议直接用 Node 18 或 20 的 LTS 版本，用nvm管理版本最省心。我见过有人用系统自带的旧版本 Node，折腾一下午没装上。

第二个坑是 Chromium 依赖。Remotion 渲染底层依赖无头浏览器，在部分 Linux 环境里缺系统库会导致渲染阶段崩溃，报错信息还特别隐晦。如果你在容器或服务器上跑，提前把字体、图形库这些依赖装齐，别等到渲染时才排查。

第三个坑是素材路径。Remotion 里引用本地素材必须走staticFile()，直接写相对路径在开发预览时可能正常，渲染时就找不到文件。这个坑我踩过两次，后来养成习惯：所有素材引用一律走staticFile，路径统一放在public/assets/下。

# 推荐的环境初始化流程 nvm install 20 nvm use 20 npm init video # Remotion 官方脚手架 npm install npx remotion studio # 启动预览，确认环境正常

4.2 用自然语言驱动代理改工程的实际对话范式

环境跑通后，重头戏是让 AI 代理真正参与进来。这里的关键不是“怎么问”，而是“怎么把意图拆成代理能执行的原子操作”。我总结了一套对话范式，实测比一次性给大指令稳定得多。

第一步，先让代理熟悉工程。开场不要直接下任务，而是让它读一遍AGENTS.md和src/目录结构，复述一遍它理解的目录职责。这一步能筛掉大量“代理理解偏差”导致的问题。

第二步，把任务拆成“数据改动”和“视觉改动”两类，分开下指令。比如“把script.json里第二段文案改成 XXX，时间点往后延 0.5 秒”是一个纯数据任务；“给IntroScene加一个从下方弹入的标题动画，用 spring 缓动”是一个纯视觉任务。混在一起下，代理容易顾此失彼。

第三步，每次改动后强制渲染验证。指令里明确写“改完后运行渲染命令，确认无报错，并报告输出文件时长”。代理会照做，你也能第一时间发现问题。

注意：不要指望代理一次改对复杂动画。我的经验是，涉及时间轴精确对齐的改动，最好由人先给出关键帧数值，代理负责实现，而不是让代理自己“感觉”该在几秒出现。代理对时间的直觉远不如对代码结构的理解。

4.3 一个可复用的场景组件模板

为了让代理有稳定的“参照物”，我建议在工程里预置几个高质量的场景组件模板。代理在新增场景时，会倾向于模仿现有代码风格，模板质量直接决定它产出的质量。下面这个是我常用的入场场景模板，结构清晰，代理很容易照着改。

import { AbsoluteFill, useCurrentFrame, interpolate, spring, useVideoConfig } from 'remotion'; export const IntroScene: React.FC<{ title: string; subtitle: string }> = ({ title, subtitle }) => { const frame = useCurrentFrame(); const { fps } = useVideoConfig(); const titleProgress = spring({ frame, fps, config: { damping: 200 } }); const titleY = interpolate(titleProgress, [0, 1], [60, 0]); const titleOpacity = interpolate(frame, [0, 20], [0, 1], { extrapolateRight: 'clamp' }); return ( <AbsoluteFill style={{ backgroundColor: '#0a0a0a', justifyContent: 'center', alignItems: 'center' }}> <div style={{ transform: `translateY(${titleY}px)`, opacity: titleOpacity, textAlign: 'center' }}> <h1 style={{ color: '#fff', fontSize: 72, margin: 0 }}>{title}</h1> <p style={{ color: '#888', fontSize: 28, marginTop: 16 }}>{subtitle}</p> </div> </AbsoluteFill> ); };

这个模板里，spring负责入场缓动，interpolate负责透明度渐显，extrapolateRight: 'clamp'保证动画结束后不会继续变化。代理照着这个结构改，基本不会出大错。我把它放在scenes/目录下作为参考实现，并在AGENTS.md里注明“新增场景请参考 IntroScene 的结构”。

5. 批量生产与参数化：OpenMontage 真正的价值区

5.1 把文案、素材、时长全部外置成数据

单条片子跑通只是起点。OpenMontage 这类方案真正的价值，在于把视频生产变成“数据进、视频出”的流水线。要做到这一点，工程里所有会变化的东西都必须外置成数据，组件只负责渲染逻辑。

我通常把可变部分拆成三层：

• 内容层：文案、标题、字幕文本，放在script.json。
• 素材层：图片、音频、生成视频片段的引用路径，放在assets.json。
• 节奏层：每段的起止时间、转场时长，放在timing.json。

这三层分离之后，批量生产就变成了“换 JSON 文件”的操作。代理可以帮你根据一份 CSV 批量生成几十个 JSON，然后循环渲染。我实测过一个场景：把 50 条产品文案批量做成 15 秒短视频，从数据准备到全部渲染完成，人工介入的时间不到一小时，剩下的都是机器在跑。

5.2 渲染性能与并发：别让最后一步拖垮整条链路

批量渲染时，性能瓶颈往往出现在编码阶段。Remotion 支持并发渲染，通过--concurrency参数控制同时渲染的帧数。这个值不是越大越好，它受 CPU 核心数和内存限制。我的经验值是设为 CPU 核心数的 1.5 倍左右，再高收益递减，还容易因为内存不足崩溃。

另一个容易被忽略的点是素材预加载。如果视频里引用了大量远程素材，渲染时每帧都去请求会非常慢。正确做法是提前把素材下载到public/assets/，渲染时走本地路径。这一步在批量场景下能省下大量时间。

5.3 版本控制与回滚：视频工程也是工程

把视频做成代码工程，最大的红利之一就是可以像管理代码一样管理视频。每次改文案、改动画，都是一次 commit。渲染出来的 MP4 不进版本库，但生成它的代码和数据进版本库。这样任何时候都能复现任意一版视频，也能清楚知道“这版和上版差在哪”。

我建议在package.json里配一个渲染脚本，把渲染命令、参数、输出路径都固化下来。代理和你自己都用同一条命令，避免“我本地能跑，你那边不行”的经典问题。

{ "scripts": { "render": "remotion render src/index.ts Main out/video.mp4 --props=./src/data/script.json", "render:preview": "remotion render src/index.ts Main out/preview.mp4 --scale=0.5" } }

render:preview用半分辨率快速出片，用于快速验证内容，确认无误后再跑全分辨率。这个习惯能帮你省下大量等待时间，尤其是在代理反复迭代的阶段。

6. 实操中那些文档不会告诉你的坑

6.1 代理改代码的“过度自信”问题

AI 代理有个通病：它改完代码后，倾向于告诉你“已完成”，但实际渲染可能报错。这不是它故意骗你，而是它在没有执行验证的情况下，基于代码静态分析做出了乐观判断。我的应对方式是：在所有涉及代码改动的指令末尾，强制加上“改完后必须运行渲染命令，把实际输出贴出来”。只要加上这一句，代理的“过度自信”问题基本消失，因为它不得不面对真实结果。

另一个相关问题是代理喜欢“顺手重构”。你让它改一个文案，它可能顺手把组件结构也调整了。这在大型工程里是灾难。解决办法是在AGENTS.md里明确写“只做被要求的改动，不要重构未提及的代码”。这条规则我加进去之后，代理的行为收敛了很多。

6.2 时间轴对齐：帧号是唯一真理

做视频最反直觉的一点是：时间不是连续的，是离散的帧。Remotion 里所有时间计算最终都要落到帧号上。我见过太多人用秒来做动画计算，结果在 30fps 和 60fps 之间切换时全乱套。

正确做法是：所有时间参数在数据层用秒表示（对人友好），进入组件后第一时间乘以fps转成帧号，之后所有计算都在帧号域进行。useVideoConfig()提供的fps就是干这个的。这个习惯能帮你避开大量“预览正常、渲染错位”的诡异问题。

提示：如果你发现动画在预览里正常，渲染出来却对不上，九成是时间单位混用了。先检查是不是有地方直接用了秒而没转帧。

6.3 字体与中文排版：渲染环境的隐形杀手

中文视频项目里，字体问题几乎是必踩的坑。开发机上装了字体，预览正常；渲染服务器上没装，出来的片子全是方框或者默认字体。Remotion 渲染时用的是无头浏览器环境，它只认系统里实际安装的字体。

解决方案有两个：一是把字体文件放进public/assets/fonts/，用@font-face显式加载；二是在渲染环境里预装所需字体。我推荐第一种，因为它不依赖环境，工程自包含，换台机器也能跑出一样的结果。中文字体文件通常较大，注意做子集化，只保留用到的字符，能显著减小体积。

6.4 音频同步：被忽视的最后一公里

视频做得好不好，音频同步占一半。Remotion 里音频通过<Audio>组件引入，用startFrom和endAt控制播放区间。常见问题是音频比画面慢半拍，或者转场时音频突兀截断。

我的处理经验是：给音频加淡入淡出，哪怕只有 0.2 秒，听感也会自然很多。转场处的音频不要硬切，用interpolate做一个短促的音量包络。这些细节在文档里往往一笔带过，但实际成片的质感差异非常明显。代理一般不会主动做这些，需要你在指令里明确要求。

7. 我对这套工作流的真实判断

用了一段时间 OpenMontage 这套思路之后，我最大的体会是：它改变的不是“视频做得好不好看”，而是“视频生产的组织方式”。以前做视频，人和软件是一对一的，做十条就要重复十次操作。现在做视频，人和代码是一对多的，写好一套工程，换数据就能出十条、一百条。AI 代理在这个过程里的角色，是帮你把“改代码”这个动作自动化，而不是替你决定片子长什么样。

它也有明确的边界。视觉创意、节奏把控、品牌调性这些事，代理目前还做不好，也不该指望它做。它擅长的是执行明确的结构化改动：改文案、调时间、换素材、加标准动画。把这些交给它，人就能腾出精力去处理真正需要判断力的部分。

如果你打算上手，我的建议是从一条 15 秒的简单片子开始，把工程结构、AGENTS.md、渲染验证脚本这三样东西先搭起来。这三样搭好之后，后面无论是加场景、换素材还是批量生产，都是在稳固地基上盖楼。反过来，如果一上来就追求复杂效果，工程结构一团乱，代理再强也救不回来。这套东西的门槛不在技术，在于你愿不愿意先把“工程化”这件事做扎实。