OpenFilm 项目分析：Coding Agent 怎样制作、检查与编辑视频

OpenFilm 官方仓库

AI 参与说明（Agent：Codex）：本文由 Codex 根据 OpenFilm 官方 README、格式规范、固定提交源码及 GitHub 发布与 CI 记录辅助分析，并使用 humanizer-zh 编辑中文正文。资料整理于 2026-10-12；分析基于 main 的提交 e0a80d515fa13457ece08925575d5453c0b0fc6d，最新公开 GitHub Release 为 v0.1.5。场景选择与采用建议属于本文判断；实际验证范围在文末列出。运行记录：模型 gpt-6.1-sol，reasoning effort ultra，执行入口 Codex Desktop，提供方 openai；CLI 版本 0.162.0-alpha.17.2（不代表桌面 App 版本）。

OpenFilm 把 Coding Agent 已会使用的 HTML、CSS 和 JavaScript 接到视频制作流程中：Agent 编写画面和剪辑文件，Studio 展示结果并接受人工修改，CLI 检查画面与导出视频。它最值得研究的部分，是可编辑的工程格式和反馈工具。 视频生成模型、配音和音乐服务通过外部 Provider 接入。

我的判断是：它适合产品演示、技术讲解、图表动画和短片制作，已经有完整工具链的雏形；采用时仍应按早期的本地开发者工具评估，尤其要确认桌面 Agent 的权限设置、手动编辑的范围和实际渲染成本。

从一句需求到一份可以继续编辑的工程

以“做一段 20 秒的命令行工具发布视频，包含功能说明和音乐”为例，OpenFilm 的工作方式是：

1. Coding Agent 读取 OpenFilm 的 MANUAL，为项目编写 film.html、各镜头的 HTML 页面和素材。
2. Studio 随文件变化更新，用户可以调整时间轴、文字、颜色、位置和尺寸。
3. Agent 用 look 查看 Contact Sheet、单帧或时间区间，收到资源错误和画面检查结果后继续修改。
4. 用户从 Studio 导出，或明确要求 Agent 用 render 生成文件。

影片制作、编辑和本地渲染不要求 OpenFilm 账户。需要生成配音、音乐、图片或视频时，再在 Settings → Providers 配置自己的服务凭据；模型和服务费用仍取决于所接入的 Provider。不能把“不要求账户”理解为生成素材无需费用。README · MANUAL

制作过程会留下可读、可修改的工程。用户要把“功能 A”改成“功能 B”，可以修改文字元素，也可以让 Agent 改对应页面，无需对着已导出的 MP4 重新描述整段视频。

格式把剪辑安排与画面代码分开

film.html 表达 Track 和 Clip 的安排。一个 <section> 对应一个 Track，iframe、video、img、audio 分别承载网页画面、视频、图片与声音；at 表示在影片中开始的秒数，#t=in,out 表示素材使用的时间区间，CSS 表示摆放和外观。前面的 Track 位于画面上层。SPEC

A page exposes window.film.frame(t), and the picture must depend only on t. 这是格式的关键约束。场景页可以使用 DOM、SVG、Canvas、WebGL 或其他浏览器绘图能力，OpenFilm 不要求使用 React。duration 声明时长，ready 可让宿主等字体和素材加载完成再绘制。Page contract

下图说明各部分的职责。外部 Provider 按需参与，本地渲染不必经过它们。

flowchart TB
    author["Coding Agent / Studio"] -->|"写入工程文件"| project["film.html / Pages / Assets"]
    provider["Provider"] -->|"按需生成素材"| project
    project --> host["Chromium / frame(t)"]
    host --> look["look：反馈用于修订"]
    host --> render["render / FFmpeg"]
    render --> output["MP4 / WebM / MOV"]

源码中，film-doc.mjs 是格式的共同读写入口，Studio、预览、检查与导出复用同一份 Clip 数据解释。这能减少“编辑器看见一种时间轴，导出器解释成另一种时间轴”的分歧；格式一致仍需要测试支持，不能仅凭共享模块保证所有路径正确。film-doc

frame(t) 为什么重要，look 又能检查什么

普通网页动画常在上一帧的状态上继续计算。视频编辑器却要随时跳到某个时刻，导出也可能把不同区间交给多个进程。因此下面两种写法含义不同：

// 顺序相关：重复画同一个 t，位置仍会变化。
x += speed;

// 根据时间计算：重复画同一个 t，位置保持相同。
x = startX + speed * t;

这只是概念片段；后文给出完整 HTML 示例。Host 还会控制页面时钟、动画与随机数，以帮助稳定绘制；作者仍须避免依赖上一次调用留下的状态。物理模拟等有历史依赖的内容，可预计算后按时间取值，或先生成视频素材。Host

look 会对抽取的画面按不同顺序重复绘制，比较结果，并检查页面错误、缺失字体与声音、部分文字裁切，以及找不到目标元素的 overrides。这是有用的自动反馈，却不能证明全部时间点都正确，也不能评价叙事、审美、素材权利或商业效果。规范还明确允许一定像素差异；确定性约束不等于不同 GPU、字体环境与机器的逐像素一致保证。look · Determinism

渲染则由 Chromium 绘制帧，FFmpeg 编码、拼接并处理音频。源码默认输出 MP4，采用 H.264/AAC；透明导出使用 WebM 或 MOV。每个并行 Worker 启动独立浏览器，默认数量按 CPU 与每实例约 3 GB 的内存预算计算，最多 8 个。4K、复杂 WebGL 和多次子帧采样的 Motion Blur 会增加工作量；源码机制不能替代实际机器上的性能测试。render

Studio 的可编辑范围有边界

Studio 把元素文字、样式、位移等修改记录为 overrides，并写回工程文件。Agent 后续编辑时应保留这些记录、稳定的元素标识和 locked Track。重写页面时若删除了被覆盖的元素，人工修改可能失去目标，look 会报告这类问题。MANUAL · Overrides check

“可以编辑任何内容”要结合画面的实现来理解：作为 DOM 元素的标题、按钮和形状可以选择和调整；Canvas/WebGL 内部画出的图形不会自动成为可选择的 DOM 元素。用户需要经常修改的文字，应放在 DOM 中；复杂绘图内部的变化仍需修改代码或素材。

当前 main 的 Studio 默认开启 Linkage：符合时间关系的标题、B-roll 和声音可以随主 Track 的 Clip 移动，跨多个镜头的长背景音乐通常保持原位。声音与场景在格式中仍是独立 Clips，直接改 film.html 时要维护它们的时间关系。另有显式分组和 Sync lock，不能把这几种机制都称为自动音画绑定。Timeline preferences · Linkage implementation

Studio 会在最新文件上重放基于 Clip ID 的编辑，并尽量保留未修改的源码文本；这有助于 Agent 与用户轮流工作。它不构成多人实时协作或所有并发写入都能自动合并的保证。任务设计上仍宜让 Agent 修改明确的镜头，避免同时整体重写时间轴。Film edits

专业剪辑器导出也有类似边界。导出的 XML 保留时间轴和素材，但 HTML 场景会烘焙成带 alpha 的 ProRes 4444，部分无法用 Basic Motion 表达的变换也会烘焙。进入 Premiere Pro 或 DaVinci Resolve 后可以继续剪辑这些素材，原来的 DOM、CSS 和网页动画结构不会成为目标软件的原生可编辑图层。NLE export

桌面 Agent 的权限是采用前必须确认的条件

Electron 桌面应用把 Studio 与聊天放在一起，通过 ACP 启动用户已有的 Coding Agent；自带 Agent 路径也使用 Pi 与用户自己的模型凭据。这部分让制作体验更集中，但引入了普通视频预览之外的本地执行能力。Agent integration · Pi agent

最需要注意的源码事实是：对提供相应模式选项的适配器，桌面 UI 强制为 Claude Code 设置 bypassPermissions、为 Codex 设置 agent-full-access；其他部分入口使用 yolo、--allow-all 等参数，部分 ACP 权限请求直接自动批准。自带 Pi 具有 read、bash、edit、write 工具。不能把桌面版理解成只允许操作影片文件的受限执行环境。Forced preferences · Agent flags

还有两项边界需要注意：

• Studio 只监听本机地址，编辑器与影片页面使用不同 origin；所有影片项目仍共享同一个 film origin，源码明确说明它们并非彼此隔离。Security · Film origin
• 媒体服务凭据写入本地 providers.json，以目录和文件权限保护；桌面自有模型凭据优先使用 safeStorage，加密不可用时存在明文退化路径。不能统一描述成“全部保存在系统钥匙串”。Provider keys · Desktop storage

据此，初次试用可先采用 CLI 与 Studio，沿用自己的 Coding Agent 权限策略；若选择桌面集成，应审查所打开项目的脚本与素材来源。单独工作目录有助于整理工程；若要限制 Agent 对本机资源的访问，还需要实际的隔离环境。这是基于源码权限行为的采用建议，不是已验证的安全保证。

最小示例：一段可乱序绘制的三秒动画

下面两个完整文件组成一个无外部素材、无第三方绘图库的示例。film.html 安排一个 Clip；title.html 根据 t 计算方块位置。重复请求 t=1.5，方块应始终停在相同位置。

film.html：

<!doctype html>
<html lang="zh-CN">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=640, height=360">
</head>
<body>
  <section>
    <iframe id="title" src="title.html#t=0,3"></iframe>
  </section>
</body>
</html>

title.html：

<!doctype html>
<html lang="zh-CN">
<head>
  <meta charset="utf-8">
  <style>
    html, body { margin: 0; width: 100%; height: 100%; }
    body { background: #17232b; color: #ffffff; font-family: sans-serif; }
    h1 { position: absolute; left: 40px; top: 50px; font-size: 36px; }
    #marker { position: absolute; left: 40px; top: 220px;
      width: 40px; height: 40px; background: #ffce74; }
  </style>
</head>
<body>
  <h1 id="heading">OpenFilm 示例</h1>
  <div id="marker"></div>
  <script type="module">
    const marker = document.querySelector('#marker');
    window.film = {
      duration: 3,
      frame(t) {
        const progress = Math.max(0, Math.min(1, t / 3));
        marker.style.transform = `translateX(${progress * 500}px)`;
      },
    };
  </script>
</body>
</html>

把两个文件保存在同一项目目录，再从该目录运行以下命令。已发布 CLI 要求 Node.js 22.2+、FFmpeg；首次使用会下载 headless Chromium。Studio 的版本历史还需要 Git。源码开发则要求 Node.js 22.18+ 与 pnpm 9，这与已发布 CLI 的前置条件不同。Install and commands · Source setup

# 固定本次已公开发布的版本，便于复现。
npx -y openfilm@0.1.5 open .
npx -y openfilm@0.1.5 look
npx -y openfilm@0.1.5 render --fps 30

预期结果是：Studio 显示一个三秒 Clip，look 生成画面检查结果，render 在工程旁生成三秒 MP4。本文实际验证了格式解析和浏览器内乱序绘制；本轮未执行上述已发布 npm CLI 的完整安装、look 与 MP4 导出。这些预期来自官方命令文档，应在试用时继续确认。

成熟度与适用场景怎样判断

2026-10-12 查询时，仓库创建于 2026-10-04，公开 GitHub Release 最新为 v0.1.5，SPEC 仍标记为 0.1 — draft。创建日期只能说明当前仓库的公开记录，不能用来推断此前没有开发积累。Repository metadata · v0.1.5 · SPEC

共享格式模块、覆盖检查、文件编辑测试、三平台 CI、npm 打包审计和 secrets 扫描，都是工程化的正面证据。CI 明确不启动 Electron，因此不能据此认定桌面窗口、安装器、真实 Agent 登录和导出交互全部通过。当前 Windows 桌面发布配置还注明尚未代码签名。CI · Windows release

固定分析提交的实际 CI 记录中，Ubuntu、macOS 测试与 pack、audit 成功，Windows 的 pnpm test 失败；对应 release workflow 也失败。这里仅记录查询时的状态，没有据此判断失败根因，也不代表已发布 v0.1.5 具有相同失败。当前源码的 Linkage、代理素材和剪映导出等新变化，也不能仅凭 package.json 仍写 0.1.5 就归入已发布版本。该提交 CI · Release workflow · Commit

代码采用 MIT License；OpenFilm 名称和标志另有商标约束。二次开发分发时应同时阅读两份文件，不能把代码许可理解为品牌使用许可。LICENSE · TRADEMARK

本轮运行了固定源码中的 src/film-doc.test.mjs，24 项测试全部通过，覆盖格式解析、时间区间、修改后写回与若干边界；另外验证了示例页面的乱序绘制。没有运行 OpenFilm 全量测试、桌面安装器、真实 Provider、完整视频导出或性能基准。因此本文能支持架构理解和试用决策，不能代替生产验收。

进一步阅读：Agent 产品中的 Work 是什么 · Agent 开发中的测试方法 · Agents 栏目导航。