VibeCut - 智能剪辑探索与实现

在数字媒体时代，视频已成为信息传播、社交互动与品牌营销的核心载体。随着短视频平台的崛起和用户生成内容（UGC）的井喷式增长，行业对高质量、高效率的视频内容生产提出了前所未有的需求。然而传统繁杂的视频剪辑工作流成了内容创作的重要瓶颈。专业级剪辑软件（如Adobe Premiere Pro, Final Cut Pro）功能强大，但学习曲线陡峭，对普通用户不友好；而轻量级、模板化的在线剪辑工具虽降低了门槛，却往往导致内容同质化，难以满足创作者个性化的叙事与视觉表达需求。为应对上述挑战，业界开始探索不同于传统软件和在线工具二元划分的新路径。基于人工智能技术的新一代自动化方案应运而生，它们既非传统剪辑软件的简单迭代，也非在线模板工具的延续，而是旨在融合专业工具的深度与在线工具的便捷，试图从根本上变革视频创作的范式。下表列举了其中几种代表性的方案：

上表所列举的方案，正是人工智能技术在视频创作领域应用的具体体现。特别是以文本生成视频（Text-to-Video）为代表的AIGC技术，展示了从零开始生成视频片段的潜力。然而，当前技术在生成视频的时长、逻辑连贯性、语义可控性等方面仍存在局限，难以直接应用于结构复杂、要求精细的视频项目中。因此，如何在自动化提升效率与保留创作者主导权之间寻求最佳平衡点，填补“全手动”与“全自动”之间的巨大鸿沟，已成为智能内容创作领域亟待解决的关键问题与难点。

近年来，以GPT系列为代表的大语言模型（LLM）在自然语言理解、意图识别和任务规划方面取得了突破性进展。这使得机器能够更深刻地理解用户通过自然语言表达的复杂创作意图。将LLM作为“大脑”，结合能够执行特定任务的多个智能体（Agent），构建多智能体（Multi-Agent）系统，为自动化完成复杂工作流提供了全新的解决范式。

在视频剪辑领域，一个复杂的剪辑任务可以被拆解为一系列子任务，例如：剪辑意图细化、草稿审阅、素材检索与筛选、资源理解、生成剪辑计划和执行剪辑等。每个子任务均可由对应的智能体负责执行。通过多智能体系统的协同工作，有望将用户从繁琐的机械操作中解放出来，使其角色从“剪辑”回归“导演”，专注于创意构思与宏观把控。这种人机协同的模式，既能大幅优化生产效率，又能保证最终成品的质量与创作者的个人风格。

“如何将问题有效自动化”是计算机科学的核心。基于上述背景，尝试在新兴的B站的在线视频剪辑工具WebCut上探索一种前沿的自动化剪辑解决方案，即VibeCut。本文聚焦于设计并实现一个基于多智能体的自动化视频剪辑系统。该系统以用户的文本描述和原始视频素材作为输入，通过智能体间的协同，自动完成大部分剪辑工作，并生成一个可供用户二次精修的剪辑工程（草稿）。本研究的意义在于，它意图提升WebCut平台的核心竞争力，更希望为下一代智能内容创作工具提供一个兼具效率与创造力的可行范例，与行业一起共同探索视频创作的智能化转型。

为实现如视频剪辑这类复杂任务的自动化，普遍依赖于一套由大型语言模型（LLM）驱动的技术栈。该技术栈的核心概念层层递进，构成了智能自动化系统的基础。

首先，LLM是该技术栈的认知核心。它基于海量文本语料数据预训练，能够将输入的文本序列（上下文）映射为语义连贯的新序列，并展现出上下文理解、逻辑推理与任务规划等关键能力。这使其能够解析高层次的用户指令，并将其分解为一系列逻辑步骤，构成了意图理解的基础。

其次，为了将LLM的规划转化为实际操作，函数调用（Function Calling）（亦称工具使用（Tool Use））技术至关重要。该机制允许LLM根据预定义的工具（Tools）描述，生成结构化的数据输出（如JSON格式）。这些结构化数据随后能被程序确定性地解析，并转化为对外部工具或API的精确调用，从而连接了自然语言意图与外部工具的执行。

函数调用为模型提供了将指令转化为结构化API请求的能力，但它本质上仍是一种模型端的输出格式规范。为了将这些调用意图无缝传递给程序外部系统执行，需要一个标准的通信协议，这便是模型上下文协议（Model Context Protocol, MCP）的核心作用。MCP可以被视为函数调用的“传输层”，它定义了一种标准化的数据格式与交互模式，用于封装由函数调用生成的工具名称及参数。通过这种方式，MCP将LLM的调用意图与工具的具体实现在架构上进行了解耦，LLM生成的调用请求不再直接绑定到特定的本地代码，而是作为一个遵循MCP规范的标准化消息，可被任何理解该协议的后端服务接收与处理，从而提升了系统的灵活性与可扩展性。

基于以上能力，便形成了当前讨论的火热的智能体（Agent）。智能体是一个封装了LLM，并被赋予特定目标和一套可用工具的自主实体，它能在“推理-行动-反馈”的循环中自主工作，直至完成目标。然而，面对视频剪辑等高度复杂的系统性工程，单一智能体难以覆盖所有专业领域。因此，多智能体（Multi-Agent）架构成为一个更具前景的解决方案。该方案将复杂问题分解，由多个具备不同专长（如草稿分析、素材检索和UI交互等）的专家智能体协同解决。为了确保这些智能体能够高效协作，通常需要一个协调者或编排器（Orchestrator）来负责管理智能体的生命周期、任务分发、状态同步和智能体间的通信。

综上所述，从单个智能体到由编排器协调的多智能体系统，其整个架构均建立在LLM的两大基础能力之上：一是强大的语义理解与推理能力，二是通过函数调用实现的结构化输出与工具使用能力。

目前在应用场景下有多种智能体设计规范。选取业界具有代表性的范式进行展开。

OpenAI对多智能体的设计提供了两种可参考的范式：

^{图片来源：https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf}

• Manager模式，有一个Manager作为中心枢纽来根据用户意图规划并调用不同的工具，在工具内部，又有不同子智能体（subagent）来实现具体的该工具应当完成的任务，最终由Manager汇总所有工具的调用结果，交付给用户。即agents as tools；

• Decentralized模式，没有一个统一的意图规划负责人，用户在输入问题后，数据在不同agent之间流转，最终某些包含交付结果功能的agent可以向用户展示任务进度或结果。即agents handing off to agents；

在Manger模式中，工具调用通过Manager扁平化管理，工作流程更清晰。然而对于复杂场景（比如视频剪辑），涉及到的工具可能较多，Manager既负责任务规划，又负责在众多工具中选择合适的工具以及对应参数进行调用，这对Manager的LLM上下文长度，意图理解以及工具调用准确性有较高要求。

在Decontralized模式中，任务执行的流程更加灵活，但相对应的，任务的流程也更不可控，对每个subagent的所负责领域的设计有较高要求。

Anthropic对工作流程也提供了两种规范：

^{图片来源：https://www.anthropic.com/engineering/building-effective-agents}

• Orchestrator-workers模式，与OpenAI的Manager模式类似，由一个编排者来负责任务调度，最后交由一个agent来汇总结果；

• Evaluator-optimizer模式，与生成对抗网络（GAN）类似，由Generator生成方案，由Evaluator评估，通过生成-评估-生成的循环，最终产出一份高质量的解决方案；

^{图片来源：https://www.anthropic.com/engineering/building-effective-agents}

Orchestrator-workers模式与Manager的优势与弊端相似。Evaluator-optimizer适合具有明确评估标准的任务，由于引入了生成-评估-生成的循环，对LLM的token消耗也更大。对于具有对外交互功能的Agent，Anthropic更推荐使用提示此工程来使LLM能够正确对待并优化来自工具调用的反馈。

Cognition针对目前的多智能体系统，提出了若干实际应用时容易出现的问题，并给出了他们的解决方案。

问题包括：

1.  指数级的错误累积

当任务在一个由多个智能体组成的链条上传递时，前一个智能体的微小错误会被后一个智能体继承并放大。错误像滚雪球一样越滚越大，导致最终结果完全不可用。一个包含 N 个步骤的流程，其成功率是每个步骤成功率的 N 次方，这使得长链条任务的成功率趋近于零。

2.  上下文丢失与高昂的通信开销

当任务在不同智能体之间传递时，宝贵的上下文信息会大量丢失。每个智能体只了解自己负责的一小部分，缺乏对整个项目背景、历史决策和总体目标的全面理解。为了弥补这一点，系统需要耗费大量资源在智能体之间传递和同步上下文，这本身就效率低下且容易出错。

3.  固化的协作结构

大多数多智能体系统（如 AutoGen 或 CrewAI）都依赖于一个预先定义好的、固定的协作图（collaboration graph）。然而，现实世界中的复杂问题（如软件工程和视频剪辑）的解决路径是动态且不可预测的。僵化的流程无法应对预料之外的情况，导致系统在遇到未知挑战时很容易崩溃。

4.  责任分散与调试困难

当系统失败时，很难确定是哪个环节、哪个智能体出了问题。错误隐藏在复杂的交互流程中，使得调试和定位根本原因变得极其困难。

针对以上多智能体系统普遍存在的挑战，我们在探索与构建WebCut Multi-Agent的过程中也进行了深入的实践与验证。我们发现，与其构建一个复杂的代理团队，不如借鉴 Cognition AI 在其博文^[https://cognition.ai/blog/dont-build-multi-agents] 中提出的思路，为解决这些难题提供了可靠的思路。核心思路如下：

1.  状态管理与迭代改进

显式地在Agent中通过工程方法引入状态管理机制，辅助LLM来理解当前任务的执行状态，避免错误发生时隐式思考时被忽略。正如Cognition AI所指出的，这意味着工程重点从提示工程（Prompt Engineering）转向了上下文工程（Context Engineering）。智能体的每一步行动都基于其完整的、持续更新的历史上下文，而非孤立的指令，从而能有效处理长链条、高复杂的任务，并实现动态的自我修正与优化。

2.  单一长时运行的智能体

放弃多智能体，仅使用单个智能体实现规划并调用所有工具。这个智能体不会在完成一个子任务后就消失，而是会持续存在，拥有从开始到结束的所有记忆和上下文。这使得上下文丢失的问题以及高昂的通讯开销可以避免。

3.  专注于构建强大的基础能力

将原来多个Agent内部的工具重新规划，形成一套极小的、可以独立验证的工具集。该工具集赋予了智能体丰富且细致的基础能力，且这种方法论将犯错的成本降至最低。即便某一步出错了，也只是一个微小的、易于修复的错误，智能体可以轻松地撤销并修正它。

^{图片来源：https://cognition.ai/blog/dont-build-multi-agents}

在人工智能浪潮的推动下，视频剪辑软件正经历一场深刻的智能化变革。AI不再仅仅是辅助工具，而是深度融入创作流程，从效率提升到创意生成，全方位地重塑着视频内容的生产方式。传统专业软件与新兴的消费级软件都在积极布局，但其AI化的路径和侧重点各有不同。

• Premiere Pro - by Adobe

作为行业标杆级的剪辑软件，Premiere Pro在AI整合上采取了全面而深入的策略，其核心目标是利用AI赋能专业创作者，在不破坏其成熟工作流的前提下，极致提升效率和创意上限。

Premiere Pro的AI功能全面覆盖了剪辑流程的多个环节。其核心优势在于将AI无缝整合进既有的专业工作流中。 除了文字编辑、自动色调映射、音频智能修复（如自动闪避和语音增强）等功能外，近期通过集成Adobe Firefly系列模型，推出了生成式AI功能，例如生成式扩展（Generative Extend），能够智能地延长或缩短片段，无缝衔接场景。 这代表了其从分析式AI向生成式AI的战略延伸。

不过该软件本身面向专业剪辑从业者，功能复杂，而且订阅制使用成本高，普通用户难以上手。

• Filmora - by 万兴

Filmora将AI能力拆分成了丰富且具体的功能点，如“智能素材检索”、”画面优化“以及“字幕生成与翻译“等。而AI Mate工具则作为这些AI能力以及基础剪辑能力的枢纽，为用户提供了快速从自然语言索引到对应具体能力的行为。

实际体验下来，AI Mate的能力更像是一个剪辑能力导引的AI客服，并没有提供智能剪辑类似规划剪辑任务并执行的能力。类似于为程序员提供的早期的代码补全智能助手。

• Descript - sponsored by OpenAI

Descript将独立的AI能力作为进入剪辑页的入口，展示在app的首页，而不是作为类似Copilot助手式的常驻服务，体现了该产品在剪辑与智能之间的倾向性与Filmora的差异。

在剪辑页可以与Copilot（Underlord）助手互动，目前互动的能力边界应当包含了字幕文本生成以及一系列预置的基础能力，比如“文本优化”、“生成合适的图片“以及“编写大纲”等偏向内容生成的功能。

上图中测试了一项视频理解+片段剪切能力，要求将轨道中的视频里出现男角色画面的片段剪掉，但该需求Descript并不能如愿完成。

为了探索与验证AI在剪辑软件中集成的具体方案与能力边界，我们先后在PC必剪以及Web轻剪上进行了改造。

PC必剪智能剪辑

在基于QT的PC必剪中集成AI能力的套件并不轻松，所以选择使用MCP来外接成熟的LLM对话的开源工具——CherryStudio。CherryStudio 通过MCP调用必剪客户端以实现AI剪辑。流程细节如下图所示：

整体设计锚定了Cognition AI的设计规范，使用单个LLM来装配多个工具实现自动化剪辑能力。

装配的工具能力范围参考了Filmora的设计思路，以时间轴上用户可以直接使用的能力为准，通过Qt组件树以及事件循环机制来尽量少侵入地集中管理和实现了对LLM暴露的能力接口。

完整视频：

由于单个LLM对规划多个工具调用的理解能力有限、工具过多（10+）以及用户意图不明确等问题，导致同一个剪辑需求，执行的工具调用链很可能不一样。工程规划和执行流程的健壮性需要进一步验证。

WebCut多智能体

在WebCut上通过实现素材RAG检索以及视频资源理解等功能，丰富了剪辑Agent的能力多样性。并且为了便于调试，设计了一套先分析，再生成剪辑计划，最终提交的流程。生成的剪辑计划包含了当前时间线中若干处结构或数值变动。

该流程中，Orchestrator即负责规划任务，也负责调用工具并分析工具的结果。

然而在实际测试中，整套流程对LLM的上下文长度有较高要求，在多次素材检索、视频理解以及草稿检索后，最终生成的剪辑计划与最初的需求有较大差距。而且用户输入的剪辑意图很有可能是模糊的，有歧义的，而该流程没有提供纠偏和明确意图的能力，也是最终剪辑计划生成不正确的一大原因。

总体来说AI能力已经逐渐成为了视频剪辑软件的基础能力之一，也是商用、专业视频剪辑软件的收费点之一。不过目前市面上视频剪辑软件的AI能力主要作为对剪辑时间线的补充上，体现为碎片化的、业务强相关的以及独立的局部能力中，比如字幕生成、素材智能检索以及封面生成等等。尚难以通过AI来规划一系列剪辑动作，自主调用各个基础能力来完成非线性时间轴的编辑，与设想中的视频剪辑智能体还有很大的距离。

为了能够验证剪辑智能体的可行性，我们先后在PC必剪以及WebCut上，根据不同的设计规范做了自动化、智能化剪辑的尝试。这些尝试包括针对不同平台（PC, Web）的通信流程适配、单智能体和多智能体的差异测试、工具设计的粒度以及抽象程度测试以及不同LLM模型针对同一流程的稳定性和效率测试等。

这些探索与尝试并没有造就一个稳定可用的剪辑智能体，但是结合目前商用软件中AI能力的集成经验以及相关的Agent设计规范，我们得以在理想的剪辑智能体能力上限与工程实践的结果下限之间寻得一个稳定的，能力可拓展的剪辑智能体设计思路的折中。

针对视频剪辑这一复杂领域的特性，为解决当前智能体技术的核心痛点而设计。

通过前期研究与实践，我们认为以AutoGen或CrewAI为代表的传统多智能体协作模式，尽管在特定任务中表现出色，但其链式结构在应用于开放式、长流程、非线性的视频剪辑时，会面临严峻挑战，主要体现在错误累积效应、高昂的通信与上下文同步开销以及调试与归责困难上。

因此，我们的核心设计理念从构建多个各司其职的Agent转向构建一个职责明确、通信高效的协同系统。受Cognition AI关于单体长时运行Agent理念的启发，并结合视频剪辑任务的实际需要，我们提出了一套基于计划者-执行者（Orchestrator-Executor）分离模式，并以共享上下文（Shared Context）为唯一事实源的双智能体架构，试图在从根本上解决上述难题。

其实现方法建立在以下关键设计之上：

• 任务规划与工具执行解耦：我们将Agent的核心职责一分为二。Orchestrator负责高层次的意图理解与任务规划，生成结构化的行动方案；Executor则专注于根据指令精确调用工具。这种分离降低了单个LLM的认知负担，显著提升了复杂任务的规划可靠性。

• 以结构化上下文作为唯一事实源：我们摒弃了在Agent间传递自然语言对话历史的方式，转而维护一个中心化的、结构化的共享上下文对象。它不仅包含了任务规划的全部步骤与状态，也承载了对时间轴核心状态的抽象描述，从根本上解决了上下文长度瓶颈与状态不一致问题。同时该上下文也是UI友好的，便于向用户展示任务规划与当前执行状态。

• 以直接更改草稿代替UI交互：Agent直接面向草稿内容进行编辑，而不是使用复杂的业务侧/UI侧提供给用户的接口进行编辑，这样可以避免Agent与复杂前端界面的交互逻辑，回归视频剪辑的本质，即使用非线性的资源片段组合（草稿结构）来表达最终成片效果（渲染结果）。

剪辑Copilot / Agent通过直接更改Timeline ViewModel来同步草稿以及UI。这样避免了从UI/业务层提取的Tool过多导致的LLM工作效率低的问题。

通过将视频剪辑、素材检索以及视频理解等独立能力封装成MCP Server便于单独维护，剪辑Agent通过接入MCP Server具备了拓展的能力。

具体的，VibeCut智能剪辑主要通过两个Agent实现：

• 计划者有三个基本职责：

1.  根据用户剪辑意图生成共享上下文（包含若干个子任务）；

2.  根据执行者的工具调用结果，流转当前执行的子任务的状态；

3.  针对出错的子任务，增量地给出后续的任务规划；

• 执行者只有一个基本职责：根据当前的共享上下文以及正在执行的子任务需求，从装配的多个工具中选择一个合适的执行；

该方案融合了OpenAI的Manager模式，以及Cognition AI关于上下文压缩的思路，实现了既通过多Agent降低了LLM的认知负担，职责划分明确，又通过引入共享上下文约束多个Agent以相同目标，相同进度的认知进行推理和工具调用。

更进一步，在哔哩哔哩内部AI Workflow平台上，使用Agent搭配Workflow在实现前后端分离的同时，实现了基础的剪辑智能体流程。

引入共享上下文作为唯一事实来协调多Agent的认知以及任务流程的表达。且该上下文是结构化的，且人类友好的，所以可以很方便地作为结构化数据展示到UI上。

该上下文由Orchestrator根据用户的剪辑意图以及上下文设计规范生成，在每次工具执行后，再由Orchestrator根据已有上下文和工具执行的结果来评估当前子任务的状态更新结果。以此来保证上下文作为唯一事实的全局一致性。

^{图片来源：https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus}

特别的，如果子任务状态被更新为“failed”，则Orchestrator则会保留已完成的历史子任务，删除尚未执行的子任务，从失败的任务开始，根据失败原因重新规划后续的任务，以此来维护上下文的鲁棒性（这与最近Manus 关于他们在上下文工程的实践里提到的“保留失误”方法^[https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus] 不谋而合）。

工具与系统提示词共同决定了剪辑智能体能力的上限。设计合理的工具以及设计合理数量的工具都有助于保障智能体的能力。

在探索阶段，我们没有选择Filmora式的以面向业务的、细分的工具设计思路，而是参考了vscode 插件cline，使用较少的，但通用的工具划分。

对于一般的视频剪辑软件，从业务角度简单可以分为四个区域：资源区、预览区、参数区以及时间轴区。其中预览区域暂不是我们关心的要点，参数区和时间轴区中的大部分内容都可以通过草稿内容体现，统称为剪辑区域。所以对于剪辑智能体来说，其具备的功能应当至少包含：资源区域交互以及剪辑区域交互，再加上通用的UI交互能力。结合以上推论，我们的剪辑智能体工具设计包含：

• UI交互工具。负责与UI交互，向用户反馈信息，比如提问问题、等待用户审批计划以及展示结果。

• 资源查询工具。负责查询资源区域的内容，包括内置素材检索以及用户资源理解，用于提供剪辑所需的充分的前提条件。

• 剪辑工具。负责与草稿/时间轴交互，根据当前草稿内容以及已知的用户意图和资源内容，生成剪辑方案并执行。

其中UI交互工具与业务实现强相关，使用LLM内置工具的形式实现，而资源查询工具和剪辑工具的实现相对独立，使用MCP的形式集成。

为了以zero-shot的方式获取视频、音频以及图片资源的结构化信息，在该Tool内部嵌入了一个专用于资源理解的智能体。

该智能体接受Executor传入的资源实例以及任务导向的针对该资源的理解需求。通过将视频上传云端缓存和局部查询（设置查询时间片段以及FPS参数）等方式，快速获取针对该视频的结构化理解数据，从而满足Executor工具调用的需求。

事实上，该工具是整个Web剪辑智能体可以感知当前草稿工程下某一时间戳画面内容的关键环节。因为该工具提供了针对原始资源的多角度理解的能力，而针对资源（视频、音频和图片等）的剪辑行为，本质上是在时间轴上引用和复制原始资源，并对引用资源进行参数修改，这些能力大部分理论上可以被带范围查询和FPS调节的VLM能力所覆盖。因此，当时间轴比较复杂时，在不导出视频的情况下，结合资源理解工具以及当前时间轴结构，剪辑智能体仍可以对工程呈现出的最终画面效果有粗略的认知。

素材智能检索为智能体提供了高效检索满足用户意图的素材的能力，这些素材一般包括贴纸、转场、特效、滤镜和字幕等品类。

为了完成高效的素材智能检索，需要经过两个处理阶段。

• 预处理阶段。素材作为一种渲染能力，需要与输入源（视频或图片）结合才能产生效果。我们将目前可用的全量素材通过与预置的视频批量组合渲染，再通过视频语言模型（VLM）得到素材效果的结构化信息。再通过LLM对结构化信息打标签，最终存储在向量数据库中。

• 检索阶段。用户的剪辑意图在经过智能体分析提取后，部分转换为了素材检索的需求，通过输入需要的素材的文本描述，在预先存储好的向量数据库中查询高维空间中余弦相似度最高的若干素材数据，完成素材智能检索的过程。

为了验证VibeCut剪辑智能体的效果，我们将从token消耗、剪辑耗时、剪辑成果以及流程故障率等多个指标进行评估。由于缺乏严格相似的同类产品，因此实验数据不包含对照组。

测试内容覆盖视频与基础字幕的剪辑能力。

以上需求都在包含一条30s时长的视频轨道草稿中执行。

• 需求-1

执行流程：

效果预览：

在执行流程中，智能体一共展现了两次human-in-the-loop阶段，分别用来得到视频理解的权限审批，以及从用户侧获取添加口播字幕的样式。最终的剪辑结果基本满足原始意图。

• 需求-2

执行流程：

效果预览：

• 需求-3

执行流程：

效果预览：

针对实验用的三个需求，分别观测需求输入后的完整流程，并记录下流程中各个节点的资源消耗情况，以Agent为单位汇总表格如下：

Executor Agent统计明细

Orchestrator Agent统计明细

数据说明：

• 每条需求重复三次，针对观测数据取均值。

• 每个动作即每次LLM/VLM请求，输入和输出Token独立计算，不主动开启cache，使用sdk提供的方法记录消耗。

• ask_followup_question的统计包含了等待用户输入的时长。

• vlm_request仅包含请求vlm api并获取返回值的时长，video_understanding包含了上传视频以及vlm_request的总时长。

• 需求-2的总token消耗明显偏多，是因为需求-2的测试场景中已经包含了基础字幕片段，其他需求的测试场景只有视频片段。

• 开销项以输入token ¥2/1M，输出token ¥20/1M核算。

为了验证剪辑智能里内不同部分的参数对结果的影响，即论证各部分的必要性，选取LLM差异性进行消融实验。

由于能够出色完成对视频理解以及结构化输出理解的能力的视频语言模型并不多，仅对Orchestrator Agent和Executor Agent两个智能体的模型进行消融。

候选模型有deepseek-v3、deepseek-r1以及一个小模型qwen3-8b。

消融实验使用的需求是：“将轨道中的视频片段按照从1开始的斐波那契数列时长（单位秒）进行切分，切分出的每个子片段都单独占用一个新的轨道，保留时间相对位置不变”。

用来测试剪辑智能体在非视频理解场景下的用户需求理解能力以及剪辑能力，正确的剪辑结果应当是：

实验中，不开启深度思考模式的qwen3-8b、deepseek-v3和r1在大部分情况下都无法正常完成整个工作流程，主要体现在无法正确输出指定的结构化数据，导致流程错误。而开启深度思考模式的qwen3-8b作为Orchestrator时无法正确评估任务进行的状态（本该完成的任务仍被评定为进行中），作为Executor时经常无法合理选择使用什么工具来完成当前的任务。

因此，消融实验中的组合都暂不能以当前流程正常完成剪辑任务。可能需要针对性的对提示词、工具的设计做进一步微调。在微调取得显著收益前，使用对工具调用有较强适应性的多参数大语言模型可以获得更稳定的效果。

为进一步验证VibeCut智能剪辑体在多样化场景下的适应性和扩展潜力，我们将目光转向视频网站中常见的图文模板类型视频剪辑需求。通常从静态文本或图像出发，输出动态叙事视频，如科普类、故事讲解类或营销推广片段。它是用户生成内容领域的典型应用，以此案例实践VibeCut在融合文本生成、图像处理与非线性编辑方面的适应性。通过这一探索，旨在证明VibeCut的多智能体设计并非局限于视频素材处理，而是能灵活适应从零创作的场景，从而为内容创作者提供更好用的剪辑 Agent。

具体而言，我们为VibeCut新增了三项关键工具：编写分镜脚本、生成角色样图和生成分镜图片。这些工具基于现有的多智能体架构以及大语言模型的图像生成与图像编辑能力，实现从用户意图到视觉元素的自动化映射。同时，通过改写计划者的提示词，我们为VibeCut预设了图文模板的业务语境，例如强调叙事逻辑、视觉一致性和相邻分镜视觉元素的相关性。这种调整确保了系统能将模糊的文本描述（如“讲述一个勇者斗魔王的冒险故事”）转化为结构化的分镜计划，并逐步执行图像生成与视频剪辑，从而完成基本的图文模板视频生成与编辑流程。实践中，保留了人机交互的空间，用户可在Agent执行过程介入修改分镜或样式，实现个性化表达。

图文模板类视频的生成流程以用户输入的文本描述为核心，借助VibeCut的共享上下文作为桥梁，实现多工具协同。蓝色标注的工具为图文场景新增，黄色标注的工具则复用通用剪辑能力。具体如下：

• 输入阶段：用户提供自然语言描述和相关设置参数。计划者首先解析意图，生成初始共享上下文，包括分镜大纲和所需元素列表。规划与生成阶段：计划者调用“编写分镜脚本”工具，输出结构化脚本（包含场景描述、时长和过渡逻辑）；随后并行调用“生成角色样图”和“生成分镜图片”工具，利用VLM（如Stable Diffusion或类似模型）创建静态图片资产。这些资产存储在素材库中，便于后续检索。

• 生成与剪辑阶段：执行者基于共享上下文，调用通用工具如“资源查询”和“剪辑工具”，将生成的图像置入时间轴，添加转场、字幕和背景音乐。整个过程支持用户反馈（human-in-loop），用户可审批或微调中间输出。

• 输出阶段：生成完整视频草稿，用户可进一步精修或导出。

这一流程将生成式AI与编辑能力解耦，避免了传统模板工具的刚性限制，同时通过共享上下文确保了叙事连贯性。

为展示该衍生应用的实际效果，我们选取两个典型故事进行测试，分别代表娱乐叙事和科普讲解场景。实验过程中使用开源的qwen-image和qwen-image-edit作为图片生成以及图片编辑的核心模型。

输入：

中间过程：

输出：

输入：

中间过程：

输出：

本次研究围绕在 Web 端视频剪辑工具中构建一个智能剪辑体的目标VibeCut，进行了深入的理论探索、架构设计与实验验证。我们最终得出以下结论：

1.  人机协同智能体的可行性得到验证

通过计划者-执行者的双智能体架构，结合共享上下文和模块化工具集的设计，我们成功构建了一个能够理解用户模糊意图、进行多步任务规划，并与用户进行有效交互的剪辑助手原型。实验表明，该系统能完成跨越音频理解、草稿编辑、视频内容理解等多个维度的复杂剪辑任务，证明了在 Web 环境下实现剪辑自动化的技术路径是可行的。

2.  计划和执行分离与共享上下文是关键

相较于单一智能体或复杂的传统多智能体系统，本方案提出的架构能有效规避 LLM 上下文长度限制和错误累积等常见问题。将任务规划与工具执行分离，并通过一个结构化、人类友好的“共享上下文”来同步状态，不仅提升了系统的稳定性和可调试性，也为用户提供了清晰的任务进度反馈，改善了人机交互的体验。

3.  AI 剪辑能力的本质是相关工具的智能编排

剪辑智能体的核心是将用户的宏观意图，拆解并委派给一系列碎片化、业务强相关的原子工具（如字幕生成、素材检索、视频理解等）来执行。其智能水平高度依赖于底层工具的丰富度与可靠性。

综上所述，本文为在Web端实现视频剪辑智能体给出了相关的探索与具体方案，所设计的架构与实现方案为在工程实践与理想的智能体能力上限之间，寻得了一个稳定且能力可拓展的折中，尤其通过对图文模板业务的尝试，展示了其在多样化内容生成领域的应用前景，对未来智能剪辑产品的发展具有重要的参考价值。

虽然本文提出的方案在功能和架构上得到了验证，但距离一个成熟高效的智能剪辑产品仍有广阔的探索空间。未来的工作将围绕以下几个核心方向展开：

1.  模型与性能优化

当前方案依赖大语言模型较高层次的任务理解能力，只有在通用任务上表现分数较高的模型能够恰当地完成剪辑任务。这也意味着模型调用的Token开销和相应延迟较高（如实验中video_understanding和vlm_request的耗时所示）。下一步的核心工作是探索使用更小的、经过领域知识微调的模型。我们将构建一个包含用户剪辑意图-任务规划-工具调用链的高质量数据集，对轻量级模型（如 qwen3-8b 等）进行微调，旨在让模型更懂剪辑意图，在降低成本和延迟的同时，提升任务规划和工具调用的准确性^[https://arxiv.org/pdf/2506.02153]。

针对Orchestrator和Executor的不同职责，采用差异化的模型策略。Orchestrator 负责复杂的意图理解和规划，可继续使用能力更强的模型；而 Executor 负责将明确指令映射到工具调用，可以采用经过微调的更小模型，从而实现LLM响应速度、成本与性能的平衡。

除了模型优化，我们还将探索工程层面的优化。例如，引入对视频分析结果的缓存机制，避免重复理解；或采用简化流程，在用户输入剪辑意图前，预先对当前草稿结构进行预处理，用来避免智能体规划的第一个任务总是查询时间轴的现象；或采取更能命中模型厂商Context Cache的提示词设计，以期缩减成本。

2.  智能体能力拓展

当前的交互主要基于文本。未来将引入更丰富的多模态理解能力。例如，允许用户通过语音下达指令，或上传一张参考图片并要求“将视频色调调整为这种风格”。智能体需要具备更深层次的音频情感分析（如识别音乐的节奏和情绪来匹配剪辑节奏）和视觉风格迁移的能力。

此外，扩展原子工具集是提升Agent能力上限的关键。计划增加包括智能配乐、B-roll自动匹配、音频降噪以及基于运动追踪的特效添加等在内的高级工具。这些工具本身也将由独立的AI模型驱动，形成一个分层的智能工具库。

3.  完善架构与评估体系

引入持久化的用户偏好记忆机制。Agent可以学习并记住特定用户的剪辑风格（如常用的转场、字幕样式、色调偏好），在新的剪辑任务中主动提出符合用户个性的建议。

为了更科学地衡量剪辑智能体的智能水平，未来将建立一个面向AI视频剪辑任务的评测基准。该基准将包含一系列意图明确剪辑任务（如“为这段Vlog制作一个快节奏的开场”、“将这段采访中的无效片段剪掉并添加字幕”），并定义定量的评估指标，如任务成功率、编辑路径长度、工具执行正确率/成功率、成片质量指标等，用以评估不同模型和架构的优劣，用于持续迭代和优化剪辑智能体。

• https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf

• https://www.anthropic.com/engineering/building-effective-agents

• https://cognition.ai/blog/dont-build-multi-agents

• https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus

• https://arxiv.org/pdf/2506.02153

• https://mastra.ai/

-End-

作者丨carrol、Yrom

AI赋能的视频剪辑工具，目前主要有云端和本地客户端两种构建形式。大家是如何理解它们各自的优势与局限的？

欢迎在留言区分享你的见解~

转发本文至朋友圈并留言，即可参与下方抽奖⬇️

小编将抽取1位幸运的小伙伴获取蛇来运转系列 小电视毛绒挂件

抽奖截止时间：10月17日12:00

如果喜欢本期内容的话，欢迎点个“在看”吧！