最近研究视频制作，我遇到了一个很具体的问题：如果视频里需要一个能说话、做手势、保持形象一致的拟人角色，能否让 coding agent 编写代码，用游戏引擎驱动它？
这个方向在技术上可行。角色模型可以重复使用，动作可以编排，同一句台词也可以换镜头重新渲染。但从"代码能让角色动起来"到"能持续制作自然的视频"，中间还有模型、口型、身体表演和出片流程。
对刚进入这个领域的开发者，我的初步选型建议是：卡通讲解角色先评估浏览器 3D；写实数字人优先评估 Unreal 与 MetaHuman；需要长期维护角色应用、熟悉 C# 时，再重点比较 Unity。 如果只制作离线影片，Blender 也值得进入候选名单。
下面先解释两大引擎的位置，再把这些选择放进同一条制作链路。本文是截至 2026 年 10 月 20 日的文档与开源仓库调研，没有实际安装这些引擎进行同场景画质或性能测试。
Unreal 和 Unity，提供的是怎样的能力？
游戏引擎可以理解为一套可编程的实时场景系统：它加载模型和材质，计算骨骼与物理，控制摄像机和灯光，再生成画面。配套编辑器负责把这些资源组织起来。
制作游戏时，玩家输入决定场景如何变化；制作视频时，可以由预先写好的时间轴决定角色何时说话、转头、抬手和切换镜头。摄像机输出同样可以成为影片。
Unreal Engine，通常简称 UE，由 Epic Games 开发。 它在高规格 3D 游戏、写实场景和影视虚拟制作中有重要位置。对角色视频而言，值得关注的是 MetaHuman 数字人工具、Control Rig 角色控制、Sequencer 镜头时间轴，以及 Movie Render Pipeline 出片流程。底层编程以 C++ 为主，也有 Blueprint 可视化逻辑；Python 主要承担编辑器自动化，不能直接理解为一套通用的运行时 Python 接口。
Unity 由 Unity Technologies 开发。 它广泛用于移动游戏、独立游戏和跨平台互动应用，也能制作高质量 3D 内容。对程序员而言，C# 组件、Animator 动画系统、Timeline 和 Cinemachine 摄像机工具比较容易形成一套脚本驱动流程。角色模型与面部驱动通常需要另外选择资源或插件。
这些是生态倾向，不是画质上限。Unity 可以做写实画面，UE 也可以做卡通作品；决定最终效果的还有资产、渲染设置和制作人员。
市场位置也需要看统计口径。GDC 的 2026 年行业调查显示，在回答主要开发引擎问题的开发者中，42% 选择 Unreal，30% 选择 Unity；较早成立的独立工作室中，Unity 仍有较高使用率。整个调查覆盖超过 2,300 名行业从业者，但这不意味着每个人都回答了引擎问题。
这些比例说明它们都是主流选项，不能解释为全球游戏收入份额、安装量份额，更不能直接当成角色视频制作的市场份额。对我的需求而言，现成角色、动作资产和自动出片能力，比哪个引擎在某个榜单领先更重要。
一个说话角色，至少有四层工作
设想制作一段教学视频：角色说"请看左边的图"，同时转头、抬手指向图表。为了得到这几秒画面，需要解决四件事。
第一是角色资产。模型需要骨骼，才能弯曲手臂；面部需要可控制的变形，才能做口型和表情。常见的 blendshape，也叫混合形状，可以理解为"张嘴""微笑"等预先准备好的形变，程序通过权重混合它们。
第二是表演数据。语音需要对应嘴形，身体需要动作，视线需要目标。viseme 指发音时可见的嘴形，同一个嘴形可能对应多个声音。声音转口型只覆盖其中一部分，并不会自动生成自然的指向动作和手指接触。
第三是场景与渲染。把动作应用到角色，设置灯光、镜头和背景，再按指定时间输出画面。
第四是视频合成。把角色画面与字幕、图表、旁白、音乐放在同一条时间轴上，最后编码成 MP4。
注意图中蓝色的角色渲染边界：游戏引擎主要承担这一段，上游仍要提供角色与表演，下游仍要完成视频组织。
coding agent 可以加速数据转换、场景搭建和批量调用。它可以写出手臂旋转的代码，但如果模型没有合适的骨骼，代码无法凭空提供关节；如果动作本身缺少重心变化，代码执行正确，表演也可能僵硬。
这也解释了为什么一个"能聊天的数字人 Demo"，离可持续生产的视频系统还有距离。它可能只展示正面半身、实时播放和一种语言，没有覆盖全身走动、中文口型、镜头切换与可重复导出。
HyperFrames 的边界：有渲染引擎，也能承载浏览器 3D
我对 HyperFrames 的判断需要更精确一点。
它确实有名为 @hyperframes/engine 的包，但这里的 engine 是基于 Puppeteer 和 FFmpeg 的页面捕获与视频生成引擎。它不是 Unreal 或 Unity 那样的角色与场景编辑系统。
同时，HyperFrames 支持 Three.js 这类浏览器 3D 运行方式。Three.js 是 JavaScript 3D 库，能在网页里加载模型、播放骨骼动画并渲染场景。因此，"没有游戏引擎后端"并不意味着它只能制作二维文字动画。
这里有两种不同的接法。
一种是在浏览器内部驱动角色。 用 Three.js 加载角色，按时间采样动作和面部权重，让 HyperFrames 捕获画面。这样可以复用 JavaScript 工具链，但角色资产、动作控制和渲染确定性需要自己处理。
另一种是让外部引擎先渲染角色片段。 UE、Unity 或 Blender 输出视频或图片序列，再交给 HyperFrames 编排字幕与图表。这个架构边界比较清楚，代价是改动角色表演后，需要重新生成素材。它是可设计的集成方式，不能据此声称 HyperFrames 已提供这些引擎的现成适配器。
看图中上下两条路径：上方共用浏览器时间轴，下方通过素材文件连接。它们的维护成本不同，没必要一开始就为 UE 写一个深入 HyperFrames 内部的后端。
还有一个容易忽略的问题：实时播放流畅，不代表逐帧导出正确。 HyperFrames 会按时间定位画面。角色如果依赖真实时钟、网络返回或不断累积的物理状态，跳到第 10 秒时，结果可能与顺序播放到第 10 秒不同。
更适合离线视频的做法，是先固定语音、口型与动作数据，再用视频时间求出角色状态。头发、衣服和弹簧骨骼等带历史状态的模拟，也需要烘焙、确定性重放或其他专门处理。只把动画播放器的时间设置一下，未必能解决所有问题。
开源项目已经能提供哪些部分？
判断成熟度，我更关心项目是否有明确边界、文档、示例、版本维护和可追踪的问题，而不是单看星标。下面将"可复用组件"和"完整生产系统"分开判断；这些结论来自仓库与文档检查，不是部署验收。
浏览器角色：three-vrm 与 TalkingHead
pixiv/three-vrm 是在 Three.js 中使用 VRM 的开源实现，采用 MIT 许可证。VRM 是基于 glTF 的人形角色格式，补充了人形骨骼、表情等约定。对于希望用 JavaScript 驱动卡通或风格化角色的开发者，这是值得优先验证的基础组件。
它提供角色格式的加载与控制基础，不会自动把一篇稿件变成完整表演。角色文件的使用许可也独立于加载库的 MIT 许可。
met4citizen/TalkingHead 更接近"让 3D 角色开口说话"的应用组件，同样采用 MIT 许可证。它基于 Three.js，提供语音口型和角色动作相关接口，也有接入外部语音服务的示例。
两个边界尤其重要。它对模型骨骼和面部形变有要求，不能假设任意 VRM 文件都能直接工作；其 README 列出的内置口型语言也不包含中文。接入能提供 viseme 或面部数据的服务可以扩展能力，但必须核对具体服务、语言与角色映射。
我的评价是：three-vrm 适合作为角色格式基础，TalkingHead 适合作为说话角色的参考实现。要接入确定性离线视频，还需要验证或改造时间控制，不能把实时 Demo 直接视为出片方案。
Unity 角色：UniVRM，加上独立的动作与出片流程
vrm-c/UniVRM 是 Unity 中 VRM 的标准实现，采用 MIT 许可证。它是格式接入组件，适合在 Unity 中加载与使用 VRM 角色。
这条路线的优点是，可以把角色控制、镜头和业务逻辑放进熟悉的 C# 工程。缺口也明确：还需要口型来源、动作库、骨骼重定向，以及导出调度。重定向是把一个骨骼上的动作映射到另一套骨骼，模型能够导入，并不保证动作比例和脚部接触正确。
Unity 官方的 Recorder 包是需要认真核对的部分。Recorder 5.1 的官方限制说明：编辑器使用 -batchmode 启动时，Recorder 无法正常开始录制；Recorder 本身也属于编辑器工具，不能直接放进独立 Player 当作通用录像库。
这不表示 Unity 无法自动出片，而是意味着"命令行启动引擎"和"无人值守捕获视频"之间仍有工作。可以评估带图形环境的编辑器流程，或者另行实现渲染纹理读回和编码，但要在原型阶段实际验证。
写实角色：MetaHuman，以及 Audio2Face-3D
UE 的 MetaHuman 是成熟的商业工具生态，不能归入开源项目。它把高质量角色与面部制作工具放在同一套体系中，MetaHuman Animator 支持从音频、视频或深度数据生成面部动画。这让写实说话角色有较完整的起点。
身体动作仍然需要单独规划。即便工具支持某种捕捉方式，也要检查当前版本、操作系统、输入条件和输出骨骼；不能从"音频能驱动脸"推导出"台词能自动生成整段全身表演"。最终镜头可以用 Sequencer 组织，通过 Movie Render Pipeline 输出。
值得关注的开源方向是 NVIDIA/Audio2Face-3D。它是官方组件入口，包含 SDK、训练框架、模型与插件，核心任务是从音频生成面部动画数据，而非整部影片。
这里不能笼统地说"全套 MIT、任何电脑都能跑"。官方列表分别列出了代码、模型、容器与数据的许可证；SDK 使用 MIT，模型等部分使用另外的条款。所查 SDK 要求 Windows 或 Linux、支持相应 CUDA 的 NVIDIA GPU。对仅使用 Apple Silicon Mac 的开发者，这不是可直接原生运行的 SDK 路线，需要另外评估远程推理与数据传输。
它适合面部驱动能力的技术验证，但模型下载、推理环境、角色形变映射与影片输出都要继续集成。
Agent 控制编辑器：Unity MCP 与 Unreal MCP
CoplayDev/unity-mcp 可以让 agent 管理 Unity 场景、资源和脚本。仓库有文档及持续发布记录，适合进入候选工具清单。
chongdashu/unreal-mcp 提供 UE 编辑器控制与 Blueprint 操作，但仓库明确标注实验状态，并不建议当前用于生产。不能因为同样叫 MCP，就认为两者在覆盖范围和稳定性上相同。
MCP 是让 agent 调用工具的协议。它能减少编辑器里的重复操作，却不增加模型缺失的面部形变，也不保证生成的动作自然。选它们时，要测试 agent 能否读取场景状态、发现错误并修复资源引用，而非只看是否支持"创建一个物体"。
更轻的嘴形工具，以及完整开源引擎
DanielSWolf/rhubarb-lip-sync 可以从录音生成带时间戳的嘴形序列。它原本面向二维嘴形动画，也可作为自定义三维嘴形映射的输入，但这需要自己写映射层。非英语录音可以使用语言无关的 phonetic 识别器，项目也说明其结果通常不如英语识别器精确；中文效果需要听看对照验证。
如果"引擎本身必须开源"是硬条件，Godot 应进入候选。它采用 MIT 许可证，具备 2D/3D 场景与动画能力。不过，是否拥有适合目标画风的角色、口型和动作插件，还需要另外调查，不能只凭引擎开源就认为数字人流程已经齐全。
如果不需要实时互动，Blender 也值得验证。它是开源的三维制作软件，Python 自动化适合组织离线场景和渲染任务。对影片来说，实时帧率并非唯一目标；模型修整、动画调整与稳定出图有时更重要。它同样需要角色与表演资源。
这次调研的结论是：成熟的基础组件和商业制作工具已经存在；没有足够证据把某个开源仓库认定为覆盖"剧本、自然全身表演、中文口型、镜头、无人值守 MP4"的通用成熟方案。 这不等于断言全网不存在，而是说上述候选的能力边界尚未覆盖这套要求。
同样做角色视频，怎么选择起点？
我会先区分角色在视频里承担的任务。
如果是讲解型角色，主要站着或坐着说话，偶尔点头和指向图表，我会先选风格化角色，用 Three.js 与 three-vrm 做最小验证，再决定是否借鉴 TalkingHead 的语音与动作组织。它和 HyperFrames 都在浏览器技术栈里，比较适合 coding agent 修改和检查。代价是要自己建立可靠的口型与时间采样层。
如果是写实数字人，脸部特写和真实光照直接决定视频价值，我会优先试 UE 与 MetaHuman。接受较大的编辑器、资源管理和 GPU 成本，换取更完整的写实制作工具。此时应该先确认机器与所需 MetaHuman 功能的兼容性，再安排自动化。
如果已有 C# 或 Unity 基础，准备把角色扩展为长期运行的互动产品，Unity 与 UniVRM 值得重点考虑。对只想尽快制作第一段讲解视频的人，则需要先证明这些额外工程工作有必要。
如果是离线短片且需要精修动作，把 Blender 放进同一轮验证。若是双人对话、走动、递物或拥抱，真正困难的往往变成动作、接触与镜头设计；单纯更换引擎，很难消除这些制作工作。
成本也要分清。UE 可以查看源码，但不属于通常意义上的开源软件。其当前条款将渲染视频归入免版税的非引擎产品，不能直接套用游戏收入抽成规则；符合条件的非游戏商业使用仍可能需要席位订阅。MetaHuman 当前许可允许在其他引擎或创作软件使用，但导出、材质和骨骼适配仍是技术工作。
Unity 也属于商业许可软件。它已取消 Runtime Fee；Personal 的适用资格及非游戏、非娱乐项目的 Industry 条件，需要按实际主体与用途核对。引擎许可、角色模型、动作包和语音服务的成本应分别计算，不能用一句"引擎免费"覆盖整条制作链路。
先做 30 秒验证，再决定是否扩大投入
我会用一个刻意受限的原型做选择：一个角色、一个固定镜头、一段中文旁白，只包含待机、点头和一次指向动作，输出 1080p、30 fps 的 30 秒 MP4。
这里的时长和参数是建议的测试条件，不是性能实测结果。
第一步，选一份许可清楚、骨骼与嘴形可检查的模型。先确认角色能闭嘴、张嘴、转头和抬手，再写自动化。不要先让 agent 从零生成人体模型。
第二步，固定一段语音文件，生成或准备带时间戳的嘴形数据。中文测试里包含闭唇音、停顿、数字和中英混读，实际观察声音与嘴形的关系；只看音量驱动张嘴，无法证明口型准确。
第三步，把待机与手势绑定到明确的动作片段，处理进出混合。先观察肩膀、手腕和脚部有没有跳变，再考虑更多动作。随机眨眼等行为使用固定种子或预先生成的时间表。
第四步，建立统一时间轴。可以让 agent 生成一份类似下面的编排数据，再由浏览器或引擎适配器解释。它是自定义接口示意，不是 HyperFrames、UE 或 Unity 的现成 API；fps 等字段也是原型约定。
json
{
"fps": 30,
"duration": 30,
"audio": "speech.wav",
"actor": "presenter",
"gesture": {"clip": "point_left", "start": 8.2},
"gaze": {"target": "chart_left", "start": 8.0, "end": 10.5}
}对 30 fps 的视频，第 n 帧的时间是 n / 30 秒。嘴形、动作、镜头与字幕应使用同一个时间基准。涉及带状态的模拟时，需要额外确定烘焙或重放方案。
第五步，验证真正的出片流程：从干净启动开始，不手动点击导出，得到完整 MP4；再修改一句台词，重新生成对应片段。记录完成时间、峰值内存、输出帧数和人工修复步骤，再决定是否值得继续。
我会特别检查四个结果：重复导出时角色状态是否一致；停顿时嘴是否自然闭合；指向动作是否真的指到图表；改台词后，口型、动作和字幕是否一起更新。图片对比可以帮助发现差异，但不要求不同 GPU 的最终像素必然完全相同。
如果原型已经能稳定重做，下一步才是加入第二个角色和镜头切换。如果只有口型或动作不合格，先修这一个环节，避免一边换引擎，一边换模型和语音，最后不知道变化来自哪里。
对当前这个需求，我会从"风格化角色 + 浏览器 3D + 固定表演数据 + HyperFrames 合成"开始验证；当写实面部明确成为核心要求时，再投入 UE 与 MetaHuman。选型最终要回答的是：在可以承担的制作成本内，哪条路线能持续输出我愿意发布的角色表演。