HyperFrames vs Remotion：AI Agent 视频制作新路线
大家好，我是若风。
这两天我看了一个很有意思的开源项目：heygen-com/hyperframes。截至 2026 年 5 月 19 日，它在 GitHub 上已经有 19.2k Star，涨得很快。
一开始我以为它只是又一个 “HTML 转视频” 工具。毕竟这件事听起来不新鲜：用浏览器渲染页面，截图，丢给 FFmpeg，最后合成 MP4。很多人自己写脚本也能做个简化版。
但把 HyperFrames 的 README、官网文档、CLI、渲染流程，以及它和 Remotion 的对比放在一起看以后，我发现重点不是“它能不能渲染视频”。说实话，这个转折还挺有意思，因为我一开始也差点把它归到“浏览器截图 + FFmpeg”的工具箱里。
真正有意思的地方在于：它把视频制作这件事，重新改造成了 AI Agent 能稳定执行的工程任务。
这句话听起来有点绕，我换个说法。以前我们说”用代码做视频”，默认对象是开发者：你写 React、写 Python、写 timeline、写插值函数，然后用工具把它渲染出来。现在 HyperFrames 的对象更像是 Agent：你给它一个主题、一份文档、一个网页、一个产品页面，它能生成 HTML、安排动画、预览、修错、再渲染。这个变化不大，但挺关键的——视频不再只是剪辑软件里的时间线，它开始变成一个可以被代码审查、可以被 CI 验证、可以被 Agent 反复修改的构建产物。
直说吧
HyperFrames 最值得看的，不是“HTML 也能做视频”这个表层卖点，而是它押注了一个方向：
未来很多短视频、产品演示、教学动画、数据可视化视频，不会先进入剪辑软件，而是先进入代码仓库。
它的核心判断有 5 个。
第一，视频制作会被拆成工程流水线。 文案、素材、动画、配音、字幕、渲染、压缩、版本管理，本来就是一串可编排步骤。只要每一步能被结构化描述，Agent 就可以接管大量重复劳动。别问我怎么知道的，很多“做条视频很快”的需求，真正耗时间的不是剪那一下，而是反复改 10 个小细节。
第二，HTML 是 Agent 最容易写对的视觉格式。 Remotion 的赌注是 React 组件，Motion Canvas 的赌注是 TypeScript 动画 DSL，Manim 的赌注是 Python 场景对象。HyperFrames 更激进：直接让 Agent 写 HTML、CSS、GSAP 和数据属性。
第三，确定性渲染比“看起来能跑”重要。 官网文档强调它是 frame-by-frame、seek-driven 的渲染方式，同一输入应该得到同一输出。对 Agent 来说，这很关键，因为 Agent 不能只靠“我感觉动画差不多”交付。它需要的是可复现的帧，而不是一次侥幸成功的播放。
第四，开源视频制作赛道正在分层。 Remotion、HyperFrames、Motion Canvas、Manim、MoviePy、Editly、Revideo、Pixelle-Video 解决的不是同一个问题。有人管浏览器渲染，有人管动画表达，有人管剪辑合成，有人管 AI 素材流水线，有人管从主题到短视频的全自动生成。
第五，HyperFrames 不是 Remotion 的简单替代品。 它更像是面向 Agent 工作流的一次重构：把“开发者写组件”改成“Agent 写网页”，把“项目工程”改成“视频构建任务”。
一句话概括：
HyperFrames 的野心，是把视频从剪辑工作台搬进 Agent 的执行循环。
HyperFrames 到底是什么
从官方介绍看，HyperFrames 是一个开源视频渲染框架：你用 HTML 定义视频内容，用 data-start、data-duration、data-track-index 这类属性描述时间线，再通过 CLI 预览和渲染。最小路径大概是这样：
npx hyperframes init my-video
cd my-video
npx hyperframes preview
npx hyperframes render它要求 Node.js 22+ 和 FFmpeg，渲染时会通过 headless Chrome 捕获每一帧，再交给 FFmpeg 编码。官网文档里也把流程拆得很清楚：先 doctor 检查环境，再 preview 看浏览器预览，最后 render 输出 MP4、MOV 或 WebM。
我自己试着跑了一下，从 npx hyperframes init 到浏览器里看到第一个可交互的预览，大概 3 分钟。默认模板生成的是一个带文字淡入效果的简单 composition，HTML 结构一目了然。说实话，那一刻我还挺意外的——不是因为它多炫，而是因为它太朴素了，朴素到你觉得自己也能写。但恰恰是这种朴素，才让 Agent 有下手的空间。
如果只是这样，它可能只是一个工程化包装。但 HyperFrames 真正不一样的地方，是它从一开始就把 Agent 当成一等公民。README 里给的第一种 Quick Start 不是”开发者先读教程”，而是：
npx skills add heygen-com/hyperframes也就是说，它会把框架知识打包成 skills，让 Claude Code、Cursor、Gemini CLI、Codex 这类编程 Agent 知道怎么写 composition、怎么用 GSAP timeline、怎么跑 CLI、怎么处理媒体、怎么从网站生成视频。
这点很重要。
很多工具说自己“AI-friendly”，实际意思是“你可以问 AI 怎么用我”。HyperFrames 更进一步：它把“怎么正确使用我”写成 Agent 可加载的操作说明。不是把文档丢给模型让它猜，而是把正确路径提前铺好。
这就像从“给人看文档”变成“给 Agent 装驱动”。
它的技术底座：网页、时间线、逐帧捕获
HyperFrames 的技术路径并不神秘，反而很直白。
它把一个视频看成一个网页，页面里的元素不是随便出现，而是带着时间属性：
<div
id="stage"
data-composition-id="demo"
data-start="0"
data-width="1920"
data-height="1080"
>
<video
data-start="0"
data-duration="5"
data-track-index="0"
src="intro.mp4"
></video>
<h1 class="clip" data-start="1" data-duration="4" data-track-index="1">
Welcome to HyperFrames
</h1>
</div>这套设计的好处，是把”视频时间线”藏进了普通 HTML 结构里，开发者能看懂，Agent 也能生成。更关键的是，动画运行时不是只能选一种——HyperFrames 通过 Frame Adapter 模式支持 GSAP、Lottie、CSS 动画、Three.js、WAAPI、Anime.js 等方式，不是要求所有人都改写成某个专属 DSL，而是尽量复用 Web 生态里已经成熟的动画表达。
渲染时，它走的是确定性路线：把时间 seek 到某一帧，等待页面进入对应状态，捕获当前画面，再编码。官网介绍里提到 frame = floor(time * fps)，每一帧通过 Chrome 的 beginFrame 捕获，再交给 FFmpeg。
这就是它和普通“录屏式”工具最大的差别。
录屏像是拿摄像机对着浏览器拍一遍，期间任何抖动、延迟、资源加载问题都可能混进去。逐帧捕获更像编译：第 137 帧应该是什么状态，就让页面直接到第 137 帧，然后拿结果。这个差别在人工预览时可能不明显，但一旦进入自动化流水线，就会决定你后面是安心还是崩溃。对人来说这是工程质量，对 Agent 来说这是生存条件——它最怕的不是”不会写 HTML”，而是”无法判断自己生成的东西有没有稳定复现”。如果每次渲染结果都飘，它就没法进入修复循环。
为什么 HeyGen 要开源这个东西
HeyGen 本身做 AI 视频，按直觉讲，它完全可以把 HyperFrames 做成内部工具，或者包装成 SaaS 功能。
但它选择开源，我理解有两个原因。
第一个原因，是视频生产的上游正在代码化。
今天很多视频不再从素材库和剪辑软件开始，而是从一段需求开始：把这个 PDF 变成 45 秒 pitch，把这个 CSV 变成柱状图竞赛，把这个产品页面变成 9:16 发布视频，把一篇文章变成带字幕和旁白的讲解。以前这些需求听起来像“找个会剪辑的人”，现在越来越像“给 Agent 一条可执行任务”。
这些需求的共同点是：输入很结构化，输出很重复，风格可以模板化，中间过程需要迭代。
这正是 Agent 擅长的地方。
第二个原因，是 HeyGen 需要一个更开放的“视频前端”。
AI 视频平台如果只提供最终渲染结果，会很难进入开发者工作流。开发者需要的是可控的中间层：我能不能改 timeline？能不能换字幕样式？能不能接自己的 TTS？能不能从网页生成？能不能在 CI 里跑？
HyperFrames 把这层打开了。
它不是在替代 HeyGen 的 AI 视频能力，而是在补一个“Agent 可以操作的视频制作层”。如果这个层变成生态入口，HeyGen 后面无论接 avatar、配音、口播、翻译，都会更自然。
和 Remotion 的真正差异
说到代码做视频，绕不开 Remotion。
Remotion 的定位很清楚：用 React 编程式生成视频。它有 Studio、Player、Server-side Rendering、Lambda、Cloud Run、Captions、Recorder 等一整套产品能力，GitHub 上截至 2026 年 5 月 19 日已经有 47.2k Star。它成熟、文档完整、生态强，很多商业级项目已经在用。
但 Remotion 有两个前提。
第一，你要接受 React 是视频表达语言。
第二，你要接受它的许可证边界。Remotion 代码在 GitHub 上，但官方 README 也提醒，它是特殊许可证，在某些公司场景下需要公司许可证。
HyperFrames 的切入点刚好不同。
它说：别让 Agent 学 React 组件树了，让它写 HTML。
这个差异不只是语法喜好，而是生产方式的差异。
如果你的团队本来就是 React 技术栈，想做高度组件化、参数化、可复用的视频系统，Remotion 依然很强。尤其是你需要 Remotion Lambda 这类生产渲染能力时，它的成熟度不是新项目能马上追上的。
但如果你的核心场景是“让 Agent 快速把内容变成视频”，HyperFrames 的 HTML 路线就更轻。Agent 不需要先把一段网页重写成 JSX，也不需要绕过 React 组件边界；它可以直接生成一个能预览的 HTML composition，再用 CLI 修。
我更愿意把它们看成两种入口：
所以，HyperFrames 不是一句“干掉 Remotion”就能概括。
更准确的说法是：Remotion 把 React 变成视频语言，HyperFrames 把网页变成 Agent 的视频语言。
还有哪些流行的开源视频制作项目
我顺手把同类项目也梳理了一遍。这里要先划清边界：所谓“制作视频”，其实至少有 5 条路线。
1. React 到视频：Remotion
Remotion 是这一代“代码做视频”最有代表性的项目。它的优势是 React 生态、组件复用、Studio 预览、服务端渲染和云端渲染能力完整。
它适合做参数化视频：比如每个用户一条年度报告视频，每个商品一条促销视频，每场比赛一条自动战报。你把数据喂进去，React 组件负责把数据变成镜头。
它的问题也很明确：如果团队不是 React 体系，学习成本会被放大；如果你非常在意 OSI 意义上的开源许可证，也要认真看它的商业授权边界。
2. HTML 到视频：HyperFrames 和 Helios
HyperFrames 是这篇文章的主角。它更像 Agent 时代的视频构建工具：HTML 作为 composition，GSAP / Lottie / CSS / Three.js 作为动画层，Chrome + FFmpeg 作为渲染层。
我还看到了一个新项目 Helios，方向也类似：让浏览器原生动画变成视频，强调 CSS、WAAPI、GSAP、Framer Motion 等 Web 标准动画可以直接工作。它目前规模还小，但思路值得观察，因为它和 HyperFrames 站在同一个趋势上：不要重新发明动画语言，尽量驱动浏览器本身。
这条路线的核心优势，是贴近 Web。
如果未来 Agent 要把网站、产品页、PPT、数据面板变成视频，这条路会很自然。
3. 动画编辑与解释型视频：Motion Canvas 和 Manim
Motion Canvas 是一个 TypeScript 动画库加实时预览编辑器，官方说它适合制作信息型矢量动画，并同步旁白。它截至 2026 年 5 月 19 日有 18.5k Star，MIT 许可证。
它的气质很像“开发者版 After Effects for explainer video”：不是拿素材剪辑，而是用代码生成动画。尤其适合技术讲解、课程视频、产品概念动画。
Manim 则更经典。它是 Python 生态里的数学动画引擎，3Blue1Brown 把这种风格带火以后，Manim Community 继续维护社区版本。它截至 2026 年 5 月 19 日有 38.5k Star，适合数学、物理、算法、科普解释类视频。
Motion Canvas 和 Manim 的共同点是：它们非常适合“解释一个抽象概念”。
缺点也明显：它们不是通用短视频流水线。你要先会写动画逻辑，才能得到好结果。
4. 自动剪辑与素材合成：MoviePy、Editly、Revideo
MoviePy 是 Python 视频编辑库，能做剪切、拼接、标题、合成、特效、音视频读写。它截至 2026 年 5 月 19 日有 14.6k Star，适合写自动剪辑脚本、批处理视频、做数据驱动的素材拼装。
Editly 是 Node.js 生态里的声明式视频编辑工具，用 JSON / JS 描述 clips、images、audio、titles、transitions，再用 FFmpeg 合成。它的定位更接近“命令行版模板剪辑器”。
Revideo 则是从 Motion Canvas fork 出来的项目，目标是把原本偏独立编辑器的能力，改造成开发者可以拿来构建视频编辑应用的库。它强调 TypeScript 视频模板、动态输入、渲染 API 和 React 预览组件。
这条路线更偏“后期合成”。
它不一定负责创造素材，而是把已有视频、图片、音频、字幕、模板编排到一起。
5. AI 全自动短视频流水线：Pixelle-Video
值得注意的是 AIDC-AI/Pixelle-Video，它不是 HyperFrames 这种”渲染框架”，而是更接近完整短视频工厂。
它的 README 里写得很直接：输入一个主题，自动完成视频文案、AI 配图/视频、语音解说、背景音乐和一键合成。项目支持 Web 界面、ComfyUI、RunningHub、Edge-TTS、Index-TTS、多种 LLM、横竖屏模板、自定义素材、数字人口播、图生视频、动作迁移等能力。截至调研时，它在 GitHub 上有 18k Star，Apache-2.0 许可证。
这类项目的价值，不在于它的底层渲染多优雅，而在于它把“创作流程”打包好了。
如果说 HyperFrames 更像一把工程师手里的视频构建刀，Pixelle-Video 更像一条面向内容生产者的自动化流水线。你不一定关心每一帧怎么 seek，你关心的是：给它主题，多久能出一条能发的平台短视频。
它也提醒我们一件事：开源视频制作工具不只会沿着“更好的代码渲染框架”演进，也会沿着“更完整的内容生产系统”演进。
一张赛道地图
把这些项目放到一起看，我会这样分：
这张表里最关键的不是 Star 数，而是时间线由谁控制。Remotion 让 React 控制时间线，HyperFrames 让 HTML 和可 seek 的动画控制时间线，Motion Canvas / Manim 让动画代码控制时间线，MoviePy / Editly / Revideo 让剪辑脚本和模板控制时间线，Pixelle-Video 让 AI 内容流水线控制时间线。
这个判断比”谁更流行”更重要。因为你选工具时，真正要问的不是”哪个项目 Star 多”，而是：
我想控制的是画面逻辑、素材拼接、动画表达，还是整条内容生产流程？
这个问题想清楚，后面的选型会轻松很多。
HyperFrames 适合什么，不适合什么
我觉得 HyperFrames 适合 4 类场景。
第一类是产品演示视频。
比如一个 SaaS 新功能上线，你希望快速生成 20 秒介绍：标题淡入、界面截图滑动、三个功能点逐个出现、最后 CTA。用 HyperFrames 写 HTML + CSS + GSAP 很自然，Agent 也容易改。
第二类是网页转视频。
它本来就有 website-to-video 的技能入口。把已有网站、落地页、数据页面变成视频，比让 Agent 重新设计一套 React composition 更顺。
第三类是数据可视化短视频。
CSV、报表、榜单、GitHub Star 变化、融资时间线，这些都可以先变成 HTML 图表，再加动画和旁白。
第四类是 Agent 驱动的视频生产。
这可能是最核心的场景：你不想亲自调 timeline，而是希望 Agent 先生成一个版本，你看预览以后用自然语言改：“标题再大一点，节奏快一点，3 秒处加一个 lower third，结尾换成深色背景。”
但它也不适合所有场景。做高度复杂的商业视频编辑器，Remotion、Revideo 或自建渲染服务可能更成熟。做数学证明、算法可视化、物理模拟，Manim 仍然更专业。批量剪素材、拼 B-roll、处理很多真实视频片段，MoviePy / Editly 这种剪辑库更直接。想一句话生成完整短视频而且不想碰代码，Pixelle-Video 这种流水线项目会更接近需求。
HyperFrames 最舒服的位置，是中间那层：
你愿意用 Web 技术表达画面，但希望 Agent 替你完成大部分搭建、迭代和渲染。
几个容易踩坑的判断
这里我再补 3 个反面判断，免得这篇文章看起来像”哪个都挺好”。
一个常见的误区是把”能生成视频”当成同一种能力。Remotion 和 HyperFrames 解决的是可编程渲染，MoviePy 和 Editly 解决的是素材合成，Pixelle-Video 解决的是从主题到成片的流程自动化，它们都能输出 MP4，但中间控制权完全不同。
另一个容易忽略的是许可证和生产化边界。Remotion 很成熟，但它的商业授权边界需要提前看清楚；HyperFrames 是 Apache-2.0，但分布式渲染能力还不像 Remotion Lambda 那么完整。选型时只看 demo 会很爽，真正上线时卡住的往往是这些不性感的地方。
还有一点：别期待 Agent 一次做出”审美完美”的视频。更现实的路径是让 Agent 先生成结构正确、可预览、可渲染的版本，然后人类用自然语言做 2 到 3 轮导演式修改。我的直觉是，未来很长一段时间里，Agent 更像助理剪辑师，而不是完全替代导演。
对开发者的启发
这类项目让我想到一个更大的变化：过去几年，开发者一直在把”文本”工程化——Markdown 变博客，Prompt 变模板，文档变知识库。现在轮到视频了。
视频以前很难进入工程系统，因为它太重、太感性、太依赖剪辑软件和人工审美。一个 .prproj、一个 .aep、一个 Final Cut 工程，对程序员来说都不像可 diff、可 review、可自动化的产物。坦白讲，这也是我以前对”自动做视频”没那么兴奋的原因：如果最后还是回到一个黑盒工程文件里，那程序员能参与的空间就很有限。
但短视频、产品演示、教学动画、数据可视化视频，很多并不需要电影级自由度。它们需要的是模板、节奏、结构、清晰的信息层级，以及稳定产出。
这就给了代码视频工具机会。
更准确地说，给了 Agent 机会。
因为 Agent 最怕的是开放式创作，最擅长的是有约束的生成。HTML composition、React component、Python scene、JSON edit spec、ComfyUI workflow，本质上都是把视频创作的自由度收束成可执行结构。
这也是为什么我看好这个方向。
不是因为所有人都会开始写代码剪视频。
而是因为越来越多视频会先被结构化，再被渲染出来。
到底该用哪个
我的建议很简单。
如果你已经在 React 技术栈里，要做参数化视频产品，先看 Remotion。
如果你想让 Agent 直接从网页、文档、数据生成视频，优先试 HyperFrames。
如果你做解释型动画、课程、技术演示，看 Motion Canvas；如果是数学和科普动画，看 Manim。
如果你要批量剪素材、合成字幕、拼音频，看 MoviePy 或 Editly；如果你要把这件事产品化成视频编辑应用，可以研究 Revideo。
如果你的目标是“一句话出短视频”，尤其是中文内容、口播、配图、TTS、模板合成这一整套，Pixelle-Video 值得单独试。
但不管选哪一个，我会盯住一个问题：
这个工具能不能让时间线被机器稳定理解？
能，它就可能进入 Agent 工作流。
不能，它就还是人的剪辑工具，只是多了几个脚本入口。
说点自己的感受
HyperFrames 让我最有感触的一点，是它没有试图发明一个更复杂的视频世界，反而回到了最朴素的东西：HTML、CSS、动画库、Chrome、FFmpeg。这些东西开发者已经会了，Agent 也大概率写得出来。所以它真正做的，不是把视频工具做得更像剪辑软件，而是把视频制作做得更像软件工程。
这可能就是下一波变化的开始。以前我们说”视频是内容”，后来我们说”视频是模板”，现在，视频开始变成一次构建。而只要它能被构建，Agent 就会想办法参与进去。
评论互动