CutClaw: Agentic Hours-Long Video Editing via Music Synchronization

Paper: arXiv:2603.29664 Code: GVCLab/CutClaw Code reference: main @ db48d08b (2026-04-17)

1. Motivation (研究动机)

CutClaw 关注的是一个很具体但很难自动化的问题：给定数小时级原始视频、一首目标音乐和一条剪辑指令，自动剪出一个叙事连贯、画面好看、并且和音乐节奏对齐的短视频。这不是普通的 text-to-video 生成，也不是把若干已切好的短 clip 排序。论文把任务定位在“专业后期剪辑工作流”的自动化：系统需要先理解长视频素材，再理解音乐结构，最后在巨大搜索空间里选出精确入点和出点。人工剪辑的难点主要来自三类成本。第一，素材长度很长。一部电影、一次旅行 VLOG 或一段直播原片可能持续 1–3 小时。编辑者需要浏览大量无结构画面，找到符合主题、人物、情绪和节奏的片段。对当前 MLLM 来说，直接把数小时的视频帧塞进上下文是不现实的。

即使模型可以看长视频，也会遇到细节丢失、局部事件混淆、人物身份不稳定、全局叙事难以维持的问题。第二，剪辑不是单点检索，而是时间线构建。视频 temporal grounding / highlight detection 可以回答“某个事件在哪一段出现”。但剪辑需要回答的是“哪些片段按什么顺序组合，才能讲出一个符合指令的故事”。如果系统只做 top-k 检索，它可能找到很多相关镜头，却无法保证镜头之间有起承转合。它也无法保证同一个角色或主题在前后镜头中保持一致。第三，音乐同步不是简单卡点。专业剪辑中的“cut on the beat”不仅要求切点靠近节拍，还要求视觉内容的能量、情绪和叙事推进与音乐段落匹配。

例如 chorus 到来时需要更强烈的视觉爆发，而 verse 可能适合铺垫、环境或人物状态。单纯对齐下拍点会产生机械感；完全忽略音乐结构又会让视频看起来像随机拼接。

这篇论文的动机可以概括为：把“长素材理解 + 音乐结构理解 + 剪辑决策”拆成可管理的层级搜索，而不是让一个大模型在连续时间域里直接做全局优化。论文认为已有 AI 辅助剪辑方法有三个主要缺口。一类方法依赖预分段素材或显式脚本，不能直接处理 raw footage。一类方法能做 moment retrieval 或 highlight detection，但缺少目标时长和音乐节拍约束。一类 agentic video editing 系统能够调用工具，但仍受限于上下文窗口和粗粒度规划，难以做到精确音画同步。CutClaw 的核心挑战不是“能否识别一个镜头里有什么”，而是“如何把很多局部识别结果组织成一个可执行剪辑计划”。

因此论文强调 bottom-up multimodal deconstruction：先把连续视频和音频都离散成结构化语义单元。视频侧把 raw footage 转成 shots、scenes、人物/环境/动作描述。音频侧把 waveform 转成音乐结构单元、关键点和局部节奏/情绪 caption。这样一来，Playwriter 可以在相对短的结构化文本空间里规划叙事，而 Editor / Reviewer 再回到局部视频区间做精细取点。这也是本文与“直接让 MLLM 看整段视频并输出剪辑点”的主要区别。论文的实际应用场景是社媒短视频、角色混剪、电影片段 montage、旅行 VLOG 高光剪辑等。

这些场景共同要求：素材长、主题可控、音乐驱动、结果要像人剪出来，而不仅是语义相关。从研究角度看，这篇工作的贡献不是提出一个新的视觉编码器，而是把多模态理解模型组织成一个 coarse-to-fine agent pipeline。它把不可枚举的连续剪辑空间转化为三层决策：结构级规划、scene 级候选收缩、shot 级边界定位。论文给出的 benchmark 也围绕这个动机设计：5 部电影 + 5 个长 VLOG，覆盖专业摄影与自然记录两类素材。每组素材配音乐和两类指令：object-centric 与 narrative-centric。前者考验角色/物体定位，后者考验多角色或复杂事件的故事组织。

因此 CutClaw 的目标是同时优化四件事：画面质量、叙事流、指令一致性和音乐同步。 这四个目标经常互相冲突。 例如最美的镜头未必包含用户指定角色。 最相关的镜头未必落在音乐关键点附近。 最符合节拍的剪切可能破坏故事连贯性。 CutClaw 的设计价值就在于把这些冲突交给不同层级的 agent 和工具逐步解决。

2. Idea (核心思想)

核心思想：CutClaw 不直接在数小时视频上暴力搜索剪辑时间线，而是先把视频和音乐都解析成结构化语义单元，再用 Playwriter 进行音乐锚定的故事规划，最后由 Editor 与 Reviewer 在局部候选空间中迭代选择可用片段。 这个想法的关键是“音乐作为全局时间骨架”。 用户指令决定剪辑想讲什么。 原始视频决定可用素材有什么。 音乐结构决定最终短片在时间上应该怎样铺陈、何处转折、何处强化。 Playwriter 不是任意写剧本，而是在音乐段落上分配视觉 scene。

每个音乐 unit 都有固定时长和节奏结构，因此生成的 shot plan 天然受到音频时间约束。 Editor 只需要在被分配的 scene 或邻近 scene 中找到满足时长、语义和美学要求的 clip。 Reviewer 再检查重叠、时长、转场、人物/事件一致性和画面质量。 从优化角度看，论文把剪辑时间线记为： $\mathcal{E}=(c_1,\dots ,c_N),c_i=(t_i^{\mathrm{in}},t_i^{\mathrm{out}})$ 其中每个 $c_i$ 是从原视频 $\mathcal{V}$ 中截取的连续片段。

目标是最大化联合目标： ${\mathcal{E}}^{\ast }=\arg {\max }_{\mathcal{E}}({\lambda }_v{\mathcal{Q}}_{\mathrm{vis}}(\mathcal{E})+{\lambda }_n{\mathcal{Q}}_{\mathrm{narr}}(\mathcal{E})+{\lambda }_c{\mathcal{Q}}_{\mathrm{cond}}(\mathcal{E},\mathcal{I})+{\lambda }_s{\mathcal{Q}}_{\mathrm{sync}}(\mathcal{E},\mathcal{M}))$ 这里四个 score 分别对应视觉质量、叙事连贯、指令一致、节奏同步。论文没有给出这些 $\lambda$ 的训练式标定或可复现实验权重，因此应理解为任务分解和 agent 约束的形式化说明，而不是一个可直接求解的 differentiable objective。CutClaw 的实际求解方式是层级近似。第一层把连续视频离散化。通过 shot boundary detection 获得 atomic shots，再将相邻、语义一致的 shots 聚合为 scenes。对每个 shot / scene 生成文字描述、人物身份、环境和动作属性。第二层把连续音频离散化。

系统检测 downbeat、pitch change、spectral energy shift 等 cue，形成候选 keypoints。再把 keypoints 组织到 verse、chorus、intro 等结构单元中。第三层由 Playwriter 在“音乐 unit → 视觉 scene → shot plan”的抽象空间里规划。它输出的是可执行蓝图，而不是最终剪辑文件。第四层由 Editor 回到原视频局部窗口，用 VLM 工具做具体 timestamp grounding。第五层由 Reviewer 做 hard constraint 检查和质量反馈。这种 coarse-to-fine 的好处是，每一步都降低下一步的搜索空间。

如果没有视频 deconstruction，agent 需要在几小时连续帧里搜索。如果没有音频结构，agent 不知道最终时间线的节奏骨架。如果没有 Reviewer，Editor 可能会选择语义相关但重复、低质或时长不合适的片段。因此 CutClaw 更像一个“剪辑项目管理系统”，而不是单一模型。它把不同的 MLLM / VLM / 音频工具放到专业分工中。Playwriter 对应人类剪辑中的总编剧或剪辑导演。Editor 对应具体找素材、定入点出点的剪辑师。Reviewer 对应质检和 continuity supervisor。这种分工也解释了为什么论文强调 agentic：系统需要多轮规划、工具调用、反馈和 backtracking，而不是一次性输出 JSON。

与 NarratoAI 一类依赖字幕或脚本的工具相比，CutClaw 直接处理 raw video 和 music。与 UVCOM / Time-R1 等 retrieval 模型相比，CutClaw 把检索结果放入音乐锚定的叙事时间线。与传统模板化卡点剪辑相比，CutClaw 试图让音画同步服务于故事，而不是只追求切点落在 beat 上。

3. Method (方法)

3.1 Overall framework

CutClaw 的输入包括三部分。 原始视频素材 $\mathcal{V}$。 目标背景音乐 $\mathcal{M}$。 用户剪辑指令 $\mathcal{I}$。 输出是剪好的视频时间线 $\mathcal{E}$，它由若干 clip 组成。 每个 clip 都有原视频中的起止时间，并在最终视频中按音乐结构重新拼接。

Figure 1 解读：整条 pipeline 先把 raw footage 与 music 拆成结构化数据库，再让 Playwriter 产生 shot plan，然后 Editor/Reviewer 逐条落实 clip，最后渲染成片。

方法里最重要的设计是把全局搜索拆成两个阶段。 阶段 A：建立可检索的多模态素材库。 视频库包含 shot boundary、scene grouping、frame/shot captions、character-aware summaries。 音频库包含 keypoints、music units、energy/emotion captions。 阶段 B：围绕音乐结构生成和验证时间线。 Playwriter 处理全局叙事和时间预算。

Editor 处理局部时间戳选择。 Reviewer 处理硬约束和质量控制。 论文把这个过程称为 hierarchical search space analysis and pruning。 直观地说，系统先在“scene-level 文本空间”中决定大方向，再在“shot-level 视频空间”中找具体边界。

3.2 Bottom-up multimodal footage deconstruction: video side

视频侧的目标是把连续 raw footage 转成 MLLM 可读、agent 可检索的结构。 论文定义 atomic shots 集合 $\mathcal{S}$。 每个 shot 是由镜头切换边界包围的基本视觉单元。 实现上使用 PySceneDetect 做 shot boundary detection。 对每个 shot $s_i$，系统提取语义属性 $\mathcal{A}(s_i)$。 这些属性覆盖 cinematography、character dynamics、environment、action 等维度。

随后系统把相邻且语义连贯的 shots 聚合成 scenes $\mathcal{Z}$。 scene 是比 shot 更大的叙事单元，适合 Playwriter 做剧情分配。

Figure 2 解读：图中体现了从低层 shot caption 到高层 scene summary 的聚合过程；这一步把长视频从帧序列变成可索引的故事素材。

人物身份是视频 deconstruction 的关键细节。 如果 caption 只写 “a man walks into a room”，跨 scene 追踪会非常脆弱。 CutClaw 会把主要人物实体注入 MLLM 的场景分析提示，让描述更像 “Joker enters the room”。 这使得后续 object-centric 指令可以更可靠地找到同一主角。 电影素材中还可以使用字幕和 ASR 信息辅助理解对白和剧情。 VLOG 素材往往缺少密集对白，因此更依赖视觉事件和音乐结构。 这也是论文指出 NarratoAI 不适用于 VLOG 场景的原因：它依赖 speech/subtitle 线索，而 VLOG 可能没有足够字幕。 视频 deconstruction 的收益有三点。 第一，它降低上下文长度压力。 Playwriter 不需要看所有帧，只需要看结构化 scene summaries。 第二，它提供检索索引。 Editor 可以按 scene id 或邻域检索 shots，而不是全局扫描。 第三，它给 Reviewer 提供上下文。 Reviewer 可以判断候选 clip 是否破坏角色、情节或转场连续性。

3.3 Bottom-up multimodal footage deconstruction: audio side

音频侧的目标是把音乐 waveform 转成剪辑可用的时间网格。 CutClaw 不是只检测固定间隔，而是同时考虑微观节拍和宏观段落。 微观层面，系统在离散时间轴 $\mathcal{T}$ 上检测 sound keypoints $\mathcal{K}$。 论文列出三类 cue。 Downbeat point：对应强拍和小节感。 Pitch change：对应旋律或情绪变化。 Spectral energy shift：对应能量、密度、高潮变化。 宏观层面，系统用 MLLM / 音频理解模型把音乐划分为结构单元：intro、verse、chorus、bridge 等。

每个 unit $u_j$ 有起止时间，形成 $\mathcal{U}=\{u_j{\}}_{j=1}^M$。 在每个 unit 内，keypoint 的重要性由 cue intensity 加权得到： $\mathrm{score}(t)={\mathbf{\beta }}^{\top }\mathbf{i}(t),\mathbf{i}(t)=[{\mathrm{int}}_{\mathrm{db}}(t),{\mathrm{int}}_{\mathrm{pc}}(t),{\mathrm{int}}_{\mathrm{se}}(t){]}^{\top }$ 其中 ${\mathrm{int}}_{\ast }(t)$ 表示对应 cue 在时间 $t$ 的强度。 论文未详细说明 $\mathbf{\beta }$ 的具体取值或是否学习得到。 因此它更像是一个描述音频 keypoint ranking 的设计公式。 最终，audio parser 会为每个结构单元和局部片段生成 caption，描述 rhythm、emotion、energy。 这些 caption 让 Playwriter 可以把“音乐变强”“节奏放慢”“情绪转折”等信号映射到视觉叙事。 代码侧配置中，src/config.py 的 AUDIO_DETECTION_METHODS = ["downbeat", "pitch", "mel_energy"] 与论文三类 cue 对应。

同一文件中 VIDEO_FPS = 2，与论文“inference 时视频下采样到 2 FPS”一致。

3.4 Playwriter: music-anchored script synthesis

Playwriter 是全局规划者。 它接收三类结构化输入：视频 scenes、音频 units、用户 instruction。 它的输出是 shot plan，而不是最终 clip timestamps。 shot plan 通常包含每个音乐段对应哪些视觉 scene、每个 shot 需要什么内容、目标时长和叙事目的。

Figure 3 解读：Playwriter 把音乐结构作为时间骨架，将视觉 scene 安排到不同音乐段落中；它做的是 macro-to-micro 的计划生成。

论文把 Playwriter 的过程拆成两个层次。 第一层是 Structural Scene Allocation。 给定音乐 units $\mathcal{U}=\{u_j{\}}_{j=1}^M$，Playwriter 为每个 unit 选择候选 scenes 子集 ${\mathcal{Z}}_{u_j}$。 形式化为： ${\mathcal{Z}}_{u_j}={\Phi }_{\mathrm{macro}}(u_j,\mathcal{I}\mid \mathcal{Z})$ 其中 ${\Phi }_{\mathrm{macro}}$ 是由 LLM 实现的规划函数。 它需要同时看音乐 unit 的情绪/节奏、用户指令、已有 scene summaries。 第二层是 Content-grounded Scene Instantiation。 给定 $u_j$ 和被分配的 scene pool，Playwriter 生成具体 shot specification。 每个 specification 可写作 $p_i=({\tau }_i,z_{\mathrm{id}},d_i)$。 这里 ${\tau }_i$ 是目标时长，$z_{\mathrm{id}}$ 是分配的 scene，$d_i$ 是要找的视觉内容描述。

Playwriter 还必须满足时长硬约束： ${\sum }_{p\in P_j}\mathrm{Duration}(p)\equiv |u_j|$ 这意味着每个音乐 unit 的 shot plan 总时长要等于该音乐段时长。 这个约束很重要，因为它把“故事规划”绑定到音乐时间线上。 如果没有这个约束，LLM 可能写出语义合理但不可渲染的计划。 如果只有这个约束、没有内容 grounding，系统又会变成模板化卡点。 Playwriter 的价值在于同时处理音乐结构、用户目标和素材语义。 代码中对应的主要文件是 src/Screenwriter_scene_short.py。

其中 select_audio_segment 处理音频片段选择，generate_structure_proposal 产生结构分配，generate_shot_plan / generate_shot_plan_with_retry 生成最终 shot plan。 公开 README 也把输出命名为 shot_plan，后续 Editor 会基于它选择 shot_point。

3.5 Editor: local retrieval and fine-grained grounding

Editor 接收 Playwriter 给出的每个 retrieval specification $p_i=({\tau }_i,z_{\mathrm{id}},d_i)$。 它需要在指定 scene 或邻近 scene 中找到一个具体 clip $c_i=[t^{\mathrm{in}},t^{\mathrm{out}}]$。 这个 clip 必须接近目标时长 ${\tau }_i$。 它也必须满足内容描述 $d_i$、视觉质量和音乐同步要求。 论文把 Editor 的动作分成三类。 Action 1 是 Semantic Neighborhood Retrieval。

基础候选池是 assigned scene 内的所有 shots： ${\Omega }_i=\{s\mid s\in z_{\mathrm{id}}\}$ 如果候选不足或置信度不够，Editor 会扩展到邻近 scene： ${\Omega }_i^{\prime }={\Omega }_i\cup \{s\mid s\in \mathrm{Neighbor}(z_{\mathrm{id}},\Delta )\}$ 这样可以避免 Playwriter 的 scene 分配过窄导致检索死胡同。Action 2 是 Fine-Grained Shot Trimming。Editor 在候选 shot 内调用 VLM 分析工具，确定更精确的起止时间。这一步解决的是“scene 相关”到“clip 可用”的差距。例如 scene summary 可能说主角奔跑，但最终剪辑需要主角转身的一秒。Action 3 是 Commit / Backtrack。候选 clip 通过 Reviewer 后才会被写入 timeline。如果 Reviewer 拒绝，Editor 会根据反馈回到邻域中重新选择。公开代码中，src/core.py 对应 Editor 逻辑。

semantic_neighborhood_retrieval 对应 Action 1。fine_grained_shot_trimming 对应 Action 2。review_clip 与 commit 对应检查和写入。EditorCoreAgent 的工具列表包含 semantic_neighborhood_retrieval、fine_grained_shot_trimming、review_clip、commit。ParallelShotOrchestrator 则对应多 shot 并行/编排执行的工程化入口。这种设计很像 ReAct：agent 先选择工具，再根据 observation 决定下一步。

和一次性 JSON 输出相比，它允许系统发现候选不好时局部重试。

3.6 Reviewer: constraints and quality control

Reviewer 是 CutClaw 保证最终时间线可靠的关键。论文描述的 Reviewer 不只是打分器，而是执行 hard rejection sampling 的质量门。它检查 temporal and structural integrity。第一类约束是 non-overlap。同一段原视频不应被重复使用，避免最终短片出现重复画面。第二类约束是 duration fidelity。clip 长度和切点需要符合音乐网格，避免打乱 Playwriter 规划好的时间结构。第三类约束是 narrative / transition consistency。前后镜头需要在人物、动作、空间或情绪上有可接受的过渡。第四类约束是 perceptual quality。

低清、遮挡、构图差、主体不清的片段会被拒绝。代码中 src/Reviewer.py 含 review_clip、review_finish、Review_timeline、Review_audio_video_alignment 与 ReviewerAgent。src/core.py 内也有用于 Editor 回路的 review_clip 工具，并维护 used_time_ranges，用于检查候选 clip 与已用时间段是否重叠。这说明 released code 将“局部 clip 可用性检查”和“最终 timeline review”分成了多个入口。

Reviewer 的作用不是替代 Playwriter，而是限制 Editor 的局部选择不会破坏全局结构。如果候选 clip 不满足要求，Reviewer 返回结构化反馈，让 Editor 到相邻 scene 或其他时间段重新搜索。

3.7 Rendering and product pipeline

公开 README 描述了工程产物：系统先生成 shot_plan，再生成 shot_point，最后渲染视频。 shot_plan 是规划级输出，描述每个音乐段落/镜头想要什么。 shot_point 是执行级输出，包含具体时间戳。 render/render_video.py 负责根据 shot_plan、shot_point、原视频和音频渲染最终成片。 该文件包含 parse_shot_scenes、extract_all_clips、calculate_optimal_crop_center、render_video_ffmpeg 等函数。 README 还强调 content-aware cropping，可将内容裁成 9:16 等社媒比例。

这对应论文之外的产品化能力：同一剪辑决策可以适配不同平台画幅。

3.8 Source-based pseudocode

# based on GVCLab/CutClaw main@db48d08b
 
def cutclaw_pipeline(video_path, audio_path, instruction):
    # 1) preprocessing / deconstruction
    shots = detect_shots_with_pyscenedetect(video_path)
    shot_captions = caption_video_shots(video_path, shots, fps=2, short_side="360p")
    characters = extract_main_characters(video_path, subtitles_or_asr=True)
    scenes = merge_shots_into_scenes(shots, shot_captions, character_context=characters)
 
    # 2) audio parsing
    audio_keypoints = detect_audio_keypoints(audio_path,
                                             methods=["downbeat", "pitch", "mel_energy"])
    audio_units = segment_music_structure(audio_path, keypoints=audio_keypoints)
    audio_captions = caption_music_units(audio_units)
 
    # 3) Playwriter / Screenwriter
    structure_proposal = generate_structure_proposal(
        scenes=scenes,
        audio_units=audio_units,
        instruction=instruction,
    )
    shot_plan = generate_shot_plan_with_retry(
        structure_proposal=structure_proposal,
        scenes=scenes,
        audio_captions=audio_captions,
        instruction=instruction,
    )
 
    # 4) Editor loop
    shot_points = []
    used_time_ranges = []
    for spec in shot_plan["shots"]:
        candidate_pool = semantic_neighborhood_retrieval(
            scene_id=spec["scene_id"],
            description=spec["description"],
        )
        candidate_clip = fine_grained_shot_trimming(
            candidate_pool=candidate_pool,
            target_duration=spec["duration"],
            visual_requirement=spec["description"],
        )
        review = review_clip(candidate_clip, used_time_ranges=used_time_ranges)
        if not review.passed:
            candidate_clip = retry_in_neighbor_scenes(spec, review.feedback)
        commit(candidate_clip)
        shot_points.append(candidate_clip)
        used_time_ranges.append(candidate_clip.time_range)
 
    # 5) final review and rendering
    review_finish(shot_points, target_length_sec=sum(s["duration"] for s in shot_plan["shots"]))
    return render_video_ffmpeg(video_path, audio_path, shot_plan, shot_points)

3.9 Code mapping table

Code reference: main @ db48d08b (2026-04-17) — pseudocode and mapping below are based on this commit.

Paper Concept	Source File	Key Class/Function
CLI / local pipeline entry	local_run.py	main, --Video_Path, --Audio_Path, shot_plan_*, shot_point_*
Streamlit UI entry	app.py	start_pipeline, derive_shot_plan_path, derive_shot_point_path, pipeline_monitor
Video deconstruction	src/video/deconstruction/*	video_caption.py, scene_analysis_video.py, scene_merge.py, get_character.py
ASR / subtitles	src/video/preprocess/asr.py	subtitle extraction and speaker/character context helpers
Audio parsing	src/audio/audio_Madmom.py, src/audio/audio_caption_madmom.py	beat/keypoint detection, audio captioning
Audio config	src/config.py	AUDIO_DETECTION_METHODS=["downbeat","pitch","mel_energy"], VIDEO_FPS=2
Playwriter / Screenwriter	src/Screenwriter_scene_short.py	select_audio_segment, generate_structure_proposal, generate_shot_plan_with_retry
Editor tools	src/core.py	semantic_neighborhood_retrieval, fine_grained_shot_trimming, EditorCoreAgent
Reviewer loop	src/core.py, src/Reviewer.py	review_clip, review_finish, ReviewerAgent, used_time_ranges
Final rendering	render/render_video.py	extract_all_clips, calculate_optimal_crop_center, render_video_ffmpeg

3.10 Paper-code agreement and gaps

论文公式与 released code 实现差异：论文中的联合目标 ${\mathcal{Q}}_{\mathrm{vis}}/{\mathcal{Q}}_{\mathrm{narr}}/{\mathcal{Q}}_{\mathrm{cond}}/{\mathcal{Q}}_{\mathrm{sync}}$ 是方法说明层面的目标函数，公开代码没有暴露一个统一可微或显式加权的 objective optimizer。公开代码更接近 agent/tool pipeline：Playwriter 生成 JSON plan，Editor 调工具找 timestamp，Reviewer 做约束检查。

论文实现细节称 Editor/Reviewer 使用 MiniMax-M2.1、Playwriter 使用 Gemini3-Pro，视觉/音乐 caption 使用 Qwen3-VL-30B-A3B 与 Qwen3-Omni-30B-A3B。公开仓库通过 LiteLLM 配置模型，src/config.py 中相关 model 字段默认是空字符串，需要用户填入 API key/base URL/model。这意味着 note 中不能把 README 推荐模型当作实验固定配置。代码检查还发现 main@db48d08b 的 local_run.py 在第 454 行附近存在 IndentationError，直接 py_compile 失败。

因此本笔记的 source-based pseudocode 以 repository 中各模块函数为依据，但不声称该 commit 的 local_run.py 可以直接运行。 app.py、src/core.py、src/Screenwriter_scene_short.py、src/Reviewer.py、render/render_video.py 在语法检查中通过。 这属于 released code 工程质量 caveat，不影响论文方法结构，但影响复现者直接按 CLI 运行。

4. Experimental Setup (实验设置)

4.1 Benchmark

论文构建了一个专门用于 agentic video editing 的 benchmark。 数据包含 10 个 source pairs。 其中 5 个来自 feature-length films。 另 5 个来自 long-duration VLOGs。 每段 raw footage 长度约 1–3 小时。 正文描述总素材量约 24 小时。 这种设置的重点是让系统必须处理长上下文，而不是只在短视频上做 moment retrieval。 音频输入包含 10 段 segmented music tracks。 音乐风格覆盖 orchestral、pop、rock、lo-fi 等。 每个 source pair 对应两类 instruction。 Object-centric instruction 要求围绕单一主角或具体对象剪辑。 Narrative-centric instruction 要求包含多个角色、互动或更复杂叙事。 总计 20 个 evaluation cases，即 10 pairs × 2 instruction types。 论文还讨论了目标视频长度层级：短片段可覆盖几个 keypoints，约 1 分钟视频可覆盖一个结构单元，更长可覆盖整首音乐。

4.2 Baselines

论文比较了三类 baseline。 NarratoAI 是基于文本/字幕线索的自动剪辑工具。 它适合有 dense subtitles 的 film 场景，但在 VLOG 场景中因为缺少 speech/subtitle 而不适用。 UVCOM 是 unified video comprehension framework，用于 moment retrieval / highlight detection。 Time-R1 是 temporal video grounding 方向的模型。 由于 UVCOM 和 Time-R1 通常处理固定长度短视频，论文把它们适配到 long-form footage：先分割源视频，再选择 top-5 confidence clips，最后 trim 到目标时长。

这种适配方式对 baseline 是必要的，但也反映出它们不是原生为音乐同步剪辑设计。

4.3 Metrics

论文使用自动指标和用户研究两套评估。 自动指标有三类。 Visual Quality 衡量美学完整性、画面质量和主体突出程度。 Instruction Follow 衡量结果是否符合用户指令。 AV Harmony 衡量音画同步，尤其是 visual cuts 与 audio onsets / downbeats / pitch changes 的时间偏移。 论文把 AV Harmony 写成检测最小 temporal offset $\Delta t$，并奖励 $\Delta t\le 0.1s$ 的对齐。 Visual Quality 和 Instruction Follow 由 GPT-5.2 打分。 这点需要注意：自动评估本身依赖强 MLLM judge，而不是纯客观视觉指标。 用户研究评估四个维度。 前三个对应自动指标：Visual Quality、Instruction Follow、Audio-Visual Harmony。 第四个是 Human-Likeness，衡量剪辑节奏和逻辑是否像人类专业编辑。 用户研究招募 25 名参与者。 问卷包含 80 个 evaluation items。 总共收集 2,000 个 user opinions。

4.4 Implementation details

论文中核心 agentic framework 的模型分配如下。 Editor 和 Reviewer 使用 MiniMax-M2.1。 Playwriter 使用 Gemini3-Pro。 预处理阶段使用 PySceneDetect 做 shot boundary detection。 ASR 使用 Whisper-v3-turbo。 视觉 caption 使用 Qwen3-VL-30B-A3B。

音乐 caption 使用 Qwen3-Omni-30B-A3B。 推理时视频下采样到 short-side 360p 和 2 FPS，以降低计算成本。 公开代码则通过 LiteLLM 接入模型。 README 推荐在 UI 或 local_run.py 中指定 video、audio、instruction、target output length、crop ratio 等参数。 resource/video/、resource/audio/、resource/subtitle/ 分别放置视频、音频和可选字幕。

5. Experimental Results (实验结果)

5.1 Main quantitative results

主结果表报告 Visual Quality、Instruction Follow 和 AV Harmony。CutClaw 在三个平均指标上均为最高。Visual Quality 平均分：CutClaw 77.6，高于 NarratoAI 75.7、UVCOM 72.4、Time-R1 72.9。Instruction Follow 平均分：CutClaw 70.0，高于 NarratoAI 64.0、UVCOM 62.6、Time-R1 61.5。AV Harmony 平均分：CutClaw 86.5，高于 NarratoAI 84.9、UVCOM 79.3、Time-R1 76.4。

更细分地看，CutClaw 在 Film/Vlog 的视觉质量分别为 79.2 / 76.0。它在 object-centric / narrative-centric 指令上的 instruction follow 为 66.6 / 73.4。它在 Film/Vlog 的 AV Harmony 为 85.7 / 87.3。NarratoAI 在 VLOG 上没有结果，因为 VLOG 缺少 dense subtitles。这组结果支持论文的核心主张：CutClaw 的收益不仅来自视觉检索，还来自音乐结构和多 agent 反馈。如果只看 AV Harmony，NarratoAI 在 film 上也有 84.9，接近 CutClaw 的 85.7。

但 NarratoAI 的 instruction follow 只有 64.0，且无法处理 VLOG。这说明单靠字幕驱动的剪辑不具备泛化到无脚本素材的能力。

Figure 4 解读：定性比较中，baseline 往往表现为片段选择僵硬、音乐结构缺失或叙事断裂；CutClaw 更强调按音乐段落组织视觉事件。

5.2 Ablation study

消融实验分别移除 Audio Context、Editor、Reviewer。 完整 CutClaw 的平均分为 Visual Quality 77.6、Instruction Follow 70.0、AV Harmony 86.5。 w/o Audio 的平均分为 Visual Quality 75.5、Instruction Follow 68.9、AV Harmony 77.2。 音频上下文移除后，AV Harmony 从 86.5 降到 77.2，是最大幅度下降。 这直接验证音乐结构解析不是装饰模块，而是音画同步的关键。 w/o Editor 的平均分为 Visual Quality 77.0、Instruction Follow 65.6、AV Harmony 85.4。

Instruction Follow 明显下降，说明 Editor 的局部检索和细粒度 grounding 对执行指令很重要。 w/o Reviewer 的平均分为 Visual Quality 76.0、Instruction Follow 69.8、AV Harmony 87.2。 Reviewer 去掉后 Visual Quality 从 77.6 降到 76.0。 有趣的是 w/o Reviewer 的 AV Harmony 平均值 87.2 略高于完整模型 86.5。 这说明 Reviewer 可能会为了画面质量、连续性或非重叠约束牺牲少量节拍对齐。 因此 Reviewer 的作用不是单独最大化 AV Harmony，而是在多目标之间做质量门控。

5.3 User study

用户研究中 CutClaw 在四个维度平均票数均最高。 Visual Quality：CutClaw 49.8%，Time-R1 21.4%，UVCOM 17.4%，NarratoAI 11.4%。 Instruction Follow：CutClaw 50.2%，Time-R1 21.0%，UVCOM 16.0%，NarratoAI 12.8%。 Audio-Visual Harmony：CutClaw 53.0%，Time-R1 20.0%，UVCOM 15.2%，NarratoAI 11.8%。 Human-Like：CutClaw 48.8%，Time-R1 23.8%，UVCOM 17.2%，NarratoAI 10.2%。 论文强调 CutClaw 的 Visual Quality 和 AV Harmony 票数都超过第二名两倍以上。

Human-Like 维度尤其重要，因为它不是自动指标直接覆盖的内容。 CutClaw 在这个维度取得 48.8%，说明用户不只是觉得它“相关”，还觉得剪辑节奏和逻辑更接近人类编辑。

5.4 Execution workflow example

Figure 5 解读：execution workflow 展示了 Playwriter、Editor、Reviewer 的协作过程；它不是单轮规划，而是带局部反馈的多阶段执行。

这个图有助于理解为什么 CutClaw 需要 agentic 设计。 Playwriter 的计划可能合理但不一定每个 scene 都有可用 clip。 Editor 的候选可能语义相关但存在重复或低质问题。 Reviewer 的反馈会让 Editor 回到相邻候选区间重新搜索。 因此最终时间线是逐段 commit 的结果。

5.5 Teaser and qualitative takeaway

Figure 6 解读：teaser 强调了 CutClaw 的目标用户体验：输入长素材、音乐和指令，一键得到 cinematic montage。 从技术上看，最值得保留的 takeaway 是：音频不是后处理配乐，而是规划时间线的主轴。 视频不是直接由 MLLM 全量阅读，而是先变成结构化、可索引、可局部回查的素材库。 Agent 不是泛泛的聊天角色，而是围绕 shot_plan / shot_point / review / render 的工程闭环。

5.6 Limitations and caveats

论文承认系统仍缺少 advanced visual hooks。 例如生成式特效、特定 monologue highlight、夸张视觉转场等还不能自动合成。 未来可以接入 generative video model 来产生额外视觉元素。 第二个限制是高推理延迟。 多阶段 pipeline 需要处理大量 raw footage，包括 shot detection、caption、ASR、audio parsing、agent loop 和 rendering。 这对交互式剪辑不够友好。 公开 README 的 roadmap 也提到 low-cost mode 和 ARC-Chapter integration，说明开发者希望减少长视频 deconstruction 成本。 第三个 caveat 是评估依赖 GPT-5.2 作为自动 judge。 这使 Visual Quality 和 Instruction Follow 的绝对分数依赖 judge 偏好。 不过用户研究从主观侧补充了证据。 第四个 caveat 是代码复现状态。 公开仓库已经包含主要模块和 README，但 local_run.py 在当前 commit 存在语法错误。 复现者应优先检查 UI pipeline 或修复 CLI 后再运行完整实验。 这也意味着论文实验配置与开源默认配置之间仍有工程化落差。

5.7 Reading conclusion

CutClaw 的价值不在于一个单独模型指标，而在于把长视频剪辑任务重新组织成可执行的多模态 agent workflow。 它用 bottom-up deconstruction 解决长上下文问题。 它用音乐结构解决全局时间骨架问题。 它用 Playwriter / Editor / Reviewer 分工解决叙事规划、局部 grounding 和质量控制问题。 实验结果显示，这种分解在 Visual Quality、Instruction Follow、AV Harmony 和 Human-Likeness 上都优于 retrieval 或字幕驱动 baseline。 如果未来代码修复复现入口，并降低 deconstruction 成本，这类系统很适合作为专业剪辑软件中的“自动粗剪 + 音乐同步”模块。