WhisperX 词级时间戳与 CLIP 检索：四个分析工具串起了哪些能力

2026-08-09

翻 OpenMontage 的 Supported Providers 折叠块，注意力很容易被前面几张大表吃掉：视频生成 15 行、图像 11 行、TTS 5 行，一路划下来到 Analysis 那一格，只剩四行，很像凑数的边角料。

但这四行是整套系统里唯一「往回读」的一层。别的工具在往外产东西——生成视频、生成图、生成语音；这四个是把已有的素材和已经渲染出来的成片读回来，变成可检索、可对时间轴、可核对的结构化信息。它们接的两头，正好是这个项目里最容易被忽略的两个环节：素材从哪来，成片凭什么算通过。

先把这四行原样摆出来

Tool	做什么
Transcriber	WhisperX 语音转文字，带词级时间戳
Scene Detect	自动场景边界检测
Frame Sampler	智能抽帧
Video Understand	CLIP/BLIP-2 视觉语言分析

这是本文唯一整张引用的表——因为它一共就四行。视频、图像、TTS 那几张大表本批另有专篇在拆，这里不重复搬。

Transcriber：值得写进表的是「词级」两个字

第一行的信息量集中在修饰语上：不是「语音转文字」，而是「带词级时间戳的语音转文字」，README 点名的实现是 WhisperX。

为什么这个修饰语要单独写进表，看下游就明白了。后期制作那一格 README 标注为 always available、always free，共 7 项，其中一项是 Subtitle Gen，做的事是「从时间戳生成 SRT/VTT」。如果只有句级时间戳，这条链到常规字幕就到头了；有了词级时间戳，才接得上合成运行时那张表里 Remotion 那一行明写的能力之一——TikTok 式逐词字幕。

仓库里与这条链对应的 skill 文件是 skills/core/whisperx.md 和 skills/core/subtitle-sync.md。两份文件的正文我们没有读过，这里只按文件名说明存在这个对应关系，不描述里面写了什么。

顺着往下有一处编排上的反直觉，值得单独记一笔。逐词字幕这种听起来完全属于「后期」的能力，README 把它挂在 Remotion 那一行；而运行时的选择规则写得很硬：运行时在提案阶段被选定，记为 render_runtime，并通过 edit_decisions 锁定，在运行时之间静默切换被 README 直接称为一次治理违规（governance violation），完整决策矩阵指向 skills/core/hyperframes.md（这份文件我们没有读过，不展开）。也就是说，「这条片子走哪套运行时」这个决定发生的位置比大多数人以为的靠前得多：它在提案阶段就定下并锁进 edit_decisions，而逐词字幕这类能力恰恰是写在运行时那一行里的。至于 edit_decisions 这份 artifact 内部到底存了哪些字段，schemas/artifacts/edit_decisions.schema.json 这个文件我们只知道它存在，没读过内容，不猜。

这里再补一处可核实的文本差异：README 的前置条件写的是 Node.js 18+，而合成运行时表里 HyperFrames 那一行标的是 Local (Node.js ≥ 22)，Remotion 那一行只写 Local (Node.js)。两处 README 文本对不上，如实指出到此为止，我不推断哪个是准的，也不能由此断言 HyperFrames 一定跑不起来——我们没有装过，也没有运行过。

Video Understand：CLIP 不是花活，它撑着一整条流水线

第四行的 Video Understand 标的是 CLIP/BLIP-2 视觉语言分析。单看这一行，很容易当成「给片段自动写描述」的附加功能。翻到流水线那边才知道它的位置有多靠前。

pipeline_defs/documentary-montage.yaml 顶层的 description 字段原文，把这条流水线定义为 retrieval-first thematic montage pipeline：先用 Pexels、Archive.org（Prelinger et al.）、NASA、Wikimedia Commons、Unsplash 的真实素材建一个语义语料库（semantic corpus），再用 CLIP-based retrieval 按主题 brief 去填充槽位描述（slot descriptions），剪辑阶段按叙事节拍排列片段，配上音乐同步和跨不同年代素材的统一调色。README 的流水线表里那一行说法一致：从 CLIP 索引的免费素材与开放档案语料库剪出的主题蒙太奇，Best For 一栏写的是「不用付费生成 API 的真实素材视频」。

仓库里与之对应的两个文件是 lib/clip_embedder.py 和 lib/corpus.py。同样，内部实现我们没有读过，只提名字。

把这条路线和「文生视频」摆在一起看，差别不在质量而在资源方向：一边是调 provider 生成新素材，另一边是把现成素材嵌入成语义语料再检索。README 的免费素材来源在两张表里各有三家——视频侧是 Pexels、Pixabay、Wikimedia Commons，图像侧是 Pexels、Pixabay、Unsplash。合成运行时那张表还写了一条兜底：当没有配置任何视频生成 provider 时，agent 生成静态图，由 Remotion 把它们变成完全动起来的视频。

落到具体数值：这条流水线的 manifest 写死了什么

架构主张听多了会麻木，所以还是回到文件里数得出来的字段。documentary-montage.yaml 前 70 行里，这几行是硬的：

stability: beta
default_checkpoint_policy: guided

reference_input:
  supported: false

orchestration:
  mode: executive-producer
  budget_default_usd: 1.00
  max_revisions_per_stage: 3
  max_send_backs: 2
  max_wall_time_minutes: 60

extensions:
  custom_scripts: true
  custom_playbooks: true
  custom_skills: true
  custom_tools: false

逐条说怎么读：

stability: beta —— manifest 里有一个显式的稳定性标记，这条流水线自标 beta。

budget_default_usd: 1.00 —— 这是流水线自带的默认预算，低于 config.yaml 里的全局 10.00，说明流水线可以给自己配更紧的额度。必须说清楚的是，这是一个配置默认值，不是开销。README 里给出的那几个金额是项目方在 README 中自行标注的，我们没有调用过任何一个 provider API，也没有验证过任何一笔费用，更不能拿这些数字去推算「你做一条要花多少钱」。检索优先的路线看起来是省 API 的，但省多少不是这份 manifest 能回答的。

max_revisions_per_stage: 3、max_send_backs: 2、max_wall_time_minutes: 60 —— 每阶段最多改 3 次、最多打回 2 次、墙钟时间上限 60 分钟。编排模式叫 executive-producer。

extensions 四个开关里只有 custom_tools 是 false —— 字面含义就是这条流水线允许自定义脚本、playbook 和 skill，但不允许自定义工具。你要给这条检索链换一个自己写的分析工具，这一格写的是 false。

reference_input.supported: false —— 这条流水线不接受参考视频作为入口。README 在别处大力讲「从参考视频开始」，但至少在这一份 manifest 里，这个入口是关的。我们只读了这一份 manifest，其它流水线支不支持参考视频，不知道，也不猜。

Scene Detect 和 Frame Sampler：一个在入口，一个在出口

第二行的 Scene Detect，README 给的就是一句「自动场景边界检测」，再没有别的可核实的细节。我们没有读过对应实现，所以这里就停在这一句，不替它编用途。

第三行的 Frame Sampler（智能抽帧）反而有明确落点：它出现在渲染之后的自检环节里——成片渲染完成后的自审会在 4 个位置抽帧，配合 ffprobe、音频分析和承诺核验一起判断能不能出片。渲染后治理这一块本批另有一篇专门讲，这里只借它说明一件事：同一类分析能力在这个系统里被用了两次方向相反的用途，前面把素材读成可检索的向量，后面把自己渲出来的成片读回来核对。

顺带把阶段流补上，位置感会更清楚。README 写明每条流水线都遵循同一套结构化流程：

research -> proposal -> script -> scene_plan -> assets -> edit -> compose

有意思的是这条链的起点。documentary-montage.yaml 里第一个阶段 idea 的 tools_available 是空数组 []，同时 checkpoint_required: true、human_approval_default: true——一个工具都不调，却是第一个要人签字的地方。同一个阶段的 review_focus 里，music plan 和 end-tag plan 都标了 MANDATORY，只有用户显式选择退出才能为空，而 narration 本身标的是 OPTIONAL——原文给的理由是音乐加视觉加 end-tag 撑得住调性的话，没有旁白也行。

那这四个分析工具具体挂在哪个阶段的 tools_available 里？这一份 manifest 我们只读了前 70 行，scene_plan 之后的阶段定义没读过，其它 12 份 manifest 也没读过，所以这里不猜。能确定的只有一件事：idea 这个起点确实是空的。

读这几张表时的三个口径坑

一、计数口径不统一。 TTS 那张表列了 5 行，而 README 架构图里 tools/audio/ 写的是 4 TTS providers；视频那张表 15 行是按 provider 数的，架构图里 tools/video/ 写的是「13 video gen tools + compose, stitch, trim」，按 tool 数。这些都是可核实的差异，如实陈述即可；哪个是对的、为什么不一致，我不推断，也不拿它评价项目。你自己写文档或做技术选型时只要记住一点：引用这些数字必须说清是哪个口径。

二、README 的形容词是 README 的措辞。 那几张 provider 表的 Notes 里有 High quality、Cost-effective、State-of-the-art quality、Premium 一类说法，全部是 README 描述为如此。我们一个 API 都没调过，不复述成自己的评价，也不据此给选型建议。

三、工具名会变。 AGENT_GUIDE.md 的 What Not To Do 里明确写了：不要使用已删除的旧名称 tts_cloud、tts_engine、video_gen；也不要硬编码 provider 名、API key 名或安装 URL，要从 registry 的 install_instructions 和 dependencies 字段去读。所以包括本文提到的这四个分析工具名在内，最终以你本地 registry 报出来的为准。

怎么自己核一遍

README 在 agent 上手那节给的办法是不看文档看 registry：

python -c "from tools.tool_registry import registry; import json; registry.discover(); print(json.dumps(registry.provider_menu(), indent=2))"

AGENT_GUIDE.md 的 Mandatory Preflight 一节里给这条命令的注释是 # Full menu — grouped available/unavailable per capability.；同一节还有一条 support_envelope() 的命令，注释原文明确警告它慢、输出量大，只用于调试。展示口径也被写成了硬要求：不要孤立地呈现单个不可用工具，永远展示完整能力图景，用 “X of Y providers configured for this capability.” 这种说法。

这两条命令我们没有运行过，返回里有什么字段、长什么样，我们不知道也不猜——真实输出以你本地跑出来的为准。

本文依据 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，请以仓库最新内容为准。安全相关做法请结合自身环境评估，本文不构成安全方案建议。