1. 先给结论Agent 剪得完但必须给它画跑道最近总有朋友问我AI Agent 真能像人一样坐那剪一下午片子吗我一般会先反问一句你说的“独立”是完全撒手还是给足流程规范后的自动执行这个反问很关键因为大多数人一听到 Agent 就想象成一个能自主思考的视频剪辑师实际它更像一个有极强执行力的实习生你说得越清楚它做得越漂亮你越模糊它越自由发挥。为了把这件事验证透我用 OpenMontage 在本地搭了一套 AI Agent 工作流把两个小时的直播录像丢进去让它自己拆任务、自己调剪辑工具、自己生成字幕和渲染成片。这篇博文就是那次测试的完整记录包含环境配置、运行原理、实测数据和翻车现场。如果你也在关注直播切片自动剪辑、本地部署大模型、AI Agent 开发这些方向这一篇应该可以给你省掉很多弯路。1.1 我最想先说的结论先说结论AI Agent 确实能独立做完一条视频从素材筛选、镜头切割、语音转写、字幕生成到最终渲染全程不需要人手动干预。但这个“独立完成”有一个非常硬的前提——我给它配的 OpenMontage 工作流里已经把任务切分、工具权限、输出规范全部写死了。具体来说Agent 负责的是“在既定流程里做决策”比如判断哪一段内容更符合任务要求、在哪个时间点切一刀、字幕怎么断句、转场用什么节奏。真正执行剪切和编码的是 ffmpeg、MoviePy、Whisper 这些底层工具。Agent 更像一个调度员和质检员不是那个真的拿鼠标拖时间轴的人。这个定位如果一开始没想清楚后面会死得很惨。我第一次跑测试时抱着“全自主”的心态让它自由发挥结果它把一个十分钟的完整开头当成高光片段留了下来理由是“这段开头信息量很大”。我一看素材确实是完整口播开场但完全不是直播间的商品讲解高光。后来我改了提示词把“高光片段”的定义具体成“出现价格、优惠、库存紧张等关键词的连续 30 到 90 秒片段”效果立刻就不一样了。1.2 我给这次实测定的四个评价维度为了不让自己陷入“看着像成了但不知道成没成”的状态我在开跑之前列了四个评价维度后面所有日志和成片都按这四方面打分。维度我的判定标准实测结果任务拆解能否把一句“剪一条 3 分钟高光切片”拆成可执行的子任务序列可以拆出了 7 个子任务工具调用能否正确调用 ffmpeg、Whisper、视觉模型等工具并处理异常大部分正确首次失败在字幕字体路径成片可用性输出视频是否满足时长、分辨率、字幕可读性、关键内容完整度第二条合格补了一次人工重渲染人工干预次数整个流程中需要人插手修正的次数第一次跑需要 3 次调优后降到 1 次这四个维度我建议你也先定好再来评估自己手里的 Agent 方案。否则很容易被一个成片视频骗过去忽略掉中间无数次隐藏的人工救火。2. 概念扫盲Agent、LLM、大模型在一条视频里分别负责什么在写部署之前必须先把概念捋清楚。因为网上这几个词混着用聊到最后大家完全说不到一起去。其实它们的关系很简单LLM 是大模型的一种是大模型里专门负责理解和生成语言的那一类DeepSeek 属于 LLM而 Agent 不是模型是一个用 LLM 当大脑的“完整系统”。好展开说。2.1 LLM 是大脑但它不会干活你可以把 LLM 想成一个知识极其渊博但四肢不勤的人。你跟它说“帮我判断这段字幕有没有错别字”它能答得很好你让它“去把素材第 27 秒到 52 秒切出来”它做不到因为模型本身没有任何操作电脑的能力。它不知道文件在哪不知道 ffmpeg 怎么调用更不知道视频编码是什么。Agent 解决的就是这个问题。Agent 在 LLM 外面包了规划、记忆和工具调用三样东西。规划让它把一个复杂目标拆成步骤记忆让它记住项目状态和你的偏好工具调用让它能真正去执行 ffmpeg、Whisper 这些命令。所以你在新闻里看到的“AI Agent 自动剪视频”本质是 LLM 当大脑Agent 框架当手脚底层剪辑工具当肌肉。2.2 DeepSeek 属于哪一层好多朋友在评论区问“DeepSeek 是 AI Agent 吗”不是。DeepSeek 是一个大语言模型也就是 LLM。它负责的是“理解文本和生成文本”这个环节。在 OpenMontage 工作流里DeepSeek 可以在 Ollama 里作为本地模型跑起来充当 Agent 的推理后端但 DeepSeek 本身不会去调用 ffmpeg也不会自己去读视频文件。所以正确的关系是DeepSeek 是 Agent 的大脑OpenMontage 是连接大脑和外部工具的神经系统ffmpeg、Whisper 是手和脚。你只装一个 DeepSeek拿到的是一个可以和它聊天的模型你把它放进 Agent 框架里才可能得到一条自动化生产线。2.3 OpenMontage 到底是个什么东西OpenMontage 这个项目目标是把“多模态内容理解 自动剪辑调度”做成本地可跑的一套 Agent 管线。名字里的 Montage蒙太奇已经暗示了它的方向把镜头语言、剪辑节奏这些原本靠人经验判断的事变成 Agent 可以理解和决策的规则。它和普通剪辑软件最大的区别是剪辑软件给你工具OpenMontage 给你一个会分配任务给工具的系统。它会把视频拆成一个个可计算的任务单元比如拆帧、聚类、转写、片段评分、片段排序、字幕生成、渲染合成然后让 Agent 根据规则来决定怎么执行。我选择本地部署而不是用在线 API主要出于三个原因素材隐私、成本可控、可自由调试。直播录像里可能涉及用户信息和商品内容传到第三方 API 总不太放心本地部署模型虽然需要显卡但跑熟了以后边际成本几乎为零尤其适合每天要出几十条切片的内容团队。2.4 为什么你总觉得这些概念难分清楚因为厂商在宣传时故意把这几个词混着说了。模型厂商说自己是 Agent平台厂商也说自己是 Agent最后用户以为装了一个大模型就等于有了 Agent。实际上大模型只是发动机Agent 是整台车OpenMontage 这类工具是底盘和方向盘。你光把发动机放在地上它不会带你去任何地方只有装进车里、接上油门刹车才能真正跑起来。3. OpenMontage 本地部署我踩出来的最小可行配置下面进入实操环节。先说清楚不同机器、不同版本的系统部署细节会有差异我给的是我这台 Ubuntu 22.04 机器上跑通的配置同时也会说明哪些参数可以按你的硬件调。3.1 为什么我坚持本地部署如果你只是临时试一下用在线 API 完全可以。但我的场景是每天要做大量直播切片素材丢给第三方工具总有几个担心一是数据链路不可控二是每天几十次 API 调用算下来成本并不低三是没法深入调整提示词和工具行为。本地部署虽然前期折腾但后面每一个环节都能看到日志、能改代码、能断点调试出了问题翻日志就能定位。所以我的建议是如果你只是每周剪三五条直接用云端如果你想做成固定管线或者涉及敏感素材那就值得把本地这套东西搭起来。3.2 硬件与模型选型参考本地跑 Agent 最怕的不是 Agent 框架而是模型推理速度。剪辑链路里有两个模型调用比较重文本规划模型和视觉理解模型。我的机器配置是 i7-12700K、32GB 内存、RTX 4070 12GB。这个配置跑 7B 级别模型很舒服勉强可以跑 14B再大就有点喘了。环节模型显存占用说明任务规划qwen2.5:7b 或 deepseek-r1:7b约 6GB负责拆解任务、安排调用顺序视觉理解qwen2-vl:7b 或 llava:7b约 7GB识别关键帧、判断画面内容字幕/语音faster-whisper small/base约 2GB转写直播间语音记忆/检索nomic-embed-text约 0.5GB给项目片段做向量索引这套组合下整条视频自动剪辑的模型推理部分不会太慢瓶颈反而在 ffmpeg 重新编码。如果你只有 8GB 显存建议把视觉模型换成 qwen2-vl:3b文本规划保持 7B否则两个模型同时加载会爆显存。3.3 用 Ollama 把本地模型跑起来我这里选 Ollama 来管理本地模型原因很简单安装方便、命令统一、API 兼容 OpenAI 格式OpenMontage 可以直接把 base_url 指到 Ollama 的 11434 端口。先装 Ollama。Linux 和 macOS 可以直接用官方脚本Windows 下载安装包。装完后把模型拉下来ollama pull qwen2.5:7b ollama pull qwen2-vl:7b ollama pull nomic-embed-text拉完以后确认服务在跑ollama serve curl http://127.0.0.1:11434/api/tags能看到模型列表就说明 Ollama 正常。这里有个小细节如果 OpenMontage 跑在同一台机器base_url 用 127.0.0.1 就行如果 Agent 和模型分开两台机器记得把 Ollama 的监听地址改成 0.0.0.0并做好防火墙白名单。3.4 OpenMontage 本体安装与配置OpenMontage 目前是以源码方式发布的我这边直接把官方仓库 clone 到 ~/projects 下cd ~/projects git clone OpenMontage官方仓库地址 cd openmontage python -m venv .venv source .venv/bin/activate pip install -r requirements.txt装完依赖后核心是改配置文件。我用的是 config.yaml核心内容如下llm: provider: ollama model: qwen2.5:7b base_url: http://127.0.0.1:11434 temperature: 0.2 vision: provider: ollama model: qwen2-vl:7b memory: backend: sqlite path: ./data/openmontage.db tools: work_dir: ./projects ffmpeg: /usr/bin/ffmpeg whisper: faster-whisper font: /usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc output_format: mp4有几个参数必须解释一下。temperature 我设得很低0.2。因为剪辑这种任务需要稳定执行不需要模型发挥太多创造力太高的话同一个需求每次生成的切片策略可能都不一样没法复现。vision 模型单独指到 qwen2-vl因为文本模型看不懂视频必须配合多模态模型判断画面内容。font 路径是给字幕渲染用的。我之前吃过一次大亏默认字体路径不存在Agent 一直报错字幕压在视频上全是方块。你在 Linux 上可以先用fc-list :langzh查一下系统中文字体路径再填进去。3.5 启动前检查清单配置写完后不要急着跑大任务先花五分钟检查下面几项能省很多排查时间ollama list确认三个模型都已拉取如果显存不够一次只加载当前环节需要的模型。which ffmpeg确认 ffmpeg 在系统 PATH 里并且支持 libx264 编码。新建一个测试目录手动执行一条ffmpeg -i input.mp4 -ss 00:01:00 -t 5 test.mp4确认硬件编码或软件编码可工作。确认 OpenMontage 的 work_dir 有写入权限尤其是处理大批量素材时目录权限不够会让 Agent 产生“工具调用成功但文件没生成”的假象。这套检查做完再进入正式流程就不会被低级环境问题打断。4. 自动剪辑链路从一段直播录像到一条高光切片部署只是开始真正难的是把剪辑这个动作翻译成 Agent 能执行的链路。下面讲一下 OpenMontage 内部是怎么组织的。4.1 Agent 如何“看懂”一段视频Agent 本身看不懂视频至少文本模型看不懂。所以 OpenMontage 做了一层多模态桥接。第一步是抽帧比如每隔两秒抽一帧用视觉模型看每一帧内容打上标签人物、商品、价格牌、背景板、表情状态。第二步是连续帧聚类把画面内容接近的片段归成一个镜头。第三步是语音转写用 faster-whisper 把整个素材的讲话内容变成带时间戳的文本。这三步做完一段视频在 Agent 眼里就变成一个“带文本索引的镜头列表”。以后再让模型判断“第 32 分钟有没有讲到优惠券”它不需要重新看视频只需要检索这段文本索引就行。这也是为什么 Agent 流程能够跑得起来的关键不是模型硬看视频而是把视频先结构化。4.2 任务规划把剪视频当成多步骤项目OpenMontage 的 Planner 模块收到任务描述后会先把它拆成子任务。举个例子我输入“从直播录像里剪出介绍三款商品的高光切片总时长 3 分钟带字幕”它输出的任务序列大致是转写完整素材生成带时间戳文本。根据关键词规则在所有提及“优惠”“价格”“库存”“倒数三二一”的位置标记候选片段。对候选片段做去重合并相邻片段。用视觉模型验证候选片段画面里是否真的有对应商品出镜。计算总时长如果超出目标就按权重排序取舍。为最终选中的片段生成字幕。拼接片段、叠加字幕、重新渲染并输出成片。这串任务并不需要 Agent 凭空创造OpenMontage 内置了很多剪辑规则模型要做的是根据规则做选择和排序。所以这里又回到前面的结论流程越清晰Agent 表现得越聪明流程越模糊它越容易乱来。4.3 工具调用ffmpeg、Whisper、视觉模型各司其职Agent 在每一步要真正执行靠的是工具调用。在 OpenMontage 里工具被封装成类似 MCP 的方式Agent 通过结构化参数去调用ffmpeg负责切片、拼接、变色、压缩、叠加字幕。faster-whisper负责语音转写返回分段文本和起止时间。视觉模型负责判断画面中是否有目标主体给片段打分。SQLite 向量库负责把需求关键词和转写文本做相似度检索快速定位相关内容。Agent 的处理循环是模型输出一个“我要调用哪个工具、参数是什么”的结构体OpenMontage 执行工具后把结果返回给模型模型再根据结果决定下一步。这个过程就是业界常说的 ReAct 模式Reason 加 Act想想再动手动手后看结果再想。我第一次跑的时候看到一个现象Agent 在调用 ffmpeg 切出候选片段后会真的去读片段的元数据确认时长是 30 秒而不是 3 分钟。这说明它不只是机械执行而是有验证意识的。虽然验证逻辑还很粗糙但已经比“脚本一把梭”强很多了。4.4 一个子任务的实际调用长什么样光说原理有点虚我截一段实际日志给你看。这是它在验证某个候选片段时的过程[Planner] 子任务: verify_candidate(segment_id7, start125.3, end168.7) [Agent] 输入: 片段7包含优惠话术但需确认画面中是否出现商品A包装 [Tool] vision.query(frame_interval2, prompt画面中是否有商品A的包装盒) [Vision] qwen2-vl: 返回 [{frame_time: 126.8, object: 商品A包装盒, confidence: 0.92}] [Agent] 结论: 通过视觉验证保留候选片段7。这种日志非常有用。你能清楚看到 Agent 在哪个环节做了什么判断、调用了什么工具、基于什么信息得出结论。这也是我推荐本地部署的一个重要原因可观测性比云端黑盒强太多。4.5 记忆与上下文为什么 Agent 剪着剪着不会乱剪一条视频会涉及很多中间状态候选片段有哪些、哪些已经被排除、用户偏好是什么、当前处于什么阶段。这些状态如果只靠模型上下文传递7B 模型很快就会乱。OpenMontage 的做法是把状态写入 SQLite 记忆后端。比如一个片段被标记为“已排除”Agent 不会在上下文里反复讨论它而是直接查记忆知道不用再考虑。再比如用户偏好“不要保留长时间冷场”这个偏好会贯穿所有决策。记忆机制有个附带好处任务中断后可以恢复。有一次我机器重启之前的项目状态还保留在 SQLite 里Agent 接着上一次的进度继续跑不用从头开始。5. 完整实测记录18分钟产出一条3分钟视频以及一次翻车理论讲完看真实过程。我把完整的一次实测记录放在这里包括输入、输出、耗时和翻车点。5.1 测试素材与任务描述素材是一个两小时的直播录像内容是直播间里连续讲解多款日用商品中途有互动、抽奖、离场空镜等杂音。目标是把其中三款主推商品讲得最透、互动最热的片段剪成一条 3 分钟竖屏切片。任务描述文件 brief.md 我写了这些目标从 raw/live_0112.mp4 中制作一条 3 分钟竖屏高光切片。 内容要求 - 覆盖三款主推商品顺序按讲解时间排序 - 每段必须包含明确的优惠信息或限时话术 - 不要冷场片段 - 保留现场互动反应但总时长不超过 8 秒 输出要求 - 1080x1920 竖屏mp4H.264 - 硬字幕字体清晰白字黑边 - 片头 2 秒标题“0112 直播高光”。注意我把输出格式都写进去了。Agent 在处理这类任务时越明确的输出规范越能减少后期返工。5.2 运行过程实录启动命令很简单openmontage run projects/live_0112 --brief brief.md启动后日志会实时打印每个子任务的状态。第一阶段是转写耗时约 4 分钟生成了 1.2 万字的转写文本。第二阶段是候选片段定位Agent 在文本里标出 23 个包含“优惠”“最后”“上车”等词的片段去重后剩 11 个候选。第三阶段是视觉验证。Agent 用 qwen2-vl 逐段看画面确认每个候选片段里是否真的出现了对应的商品包装。这一步排掉了 4 个只有口播没有商品出镜的片段。第四阶段是片段排序和时长规划Agent 最终选择了 7 个片段总时长 2 分 58 秒。第五阶段生成字幕第六阶段渲染。整个流程从启动到输出成片总共跑完用了约 18 分钟其中模型推理大约 6 分钟ffmpeg 重编码大约 11 分钟。作为一个两小时素材压成三分钟的任务这个时间我觉得可以接受。5.3 成片效果和量化指标成片出来后我做了实际检查。总体完成度比预期高画面和语音同步没问题三款商品的讲解顺序正确字幕断句基本合理没有出现明显的口误字幕。唯一让我意外的是转场处理比我想象得保守Agent 默认用了硬切没有加任何过渡效果。这是因为 brief 里没有写转场风格它选了最安全的方式。指标结果成片时长2分58秒字幕准确率抽查约96%商品覆盖3/3无意义空镜无人工干预第1次运行需干预3处第2次降为1处从直播切片自动剪辑的实用角度看这个成片已经能作为粗剪稿交给后期微调了比从两小时素材里手动拖时间轴省力太多。5.4 一次翻车复现Agent 把“高光”理解偏了不过第一次跑可不是这个结果第一次它翻车了而且翻得很典型。我把那次日志抠出来复盘一下能帮你看清 Agent 的问题模式。第一次跑Agent 在候选片段里选中了一段约 2 分钟的开场口播理由是“开场信息密度高概括了整场直播的优惠力度”。从文本看这确实有道理但如果看过画面就会发现那一段既没有商品特写也没有互动弹幕节奏也很平完全不具备高光片段的冲击力。它为什么这么选因为文本规划模型的判断主要依赖转写文本它没有真正“看”过画面。OpenMontage 虽然配了视觉模型但筛选阶段 Agent 优先使用了成本更低的文本检索视觉验证排在后面。那一次视觉验证并没有被触发我看了日志候选片段排序时视觉模型的权重很低。发现问题后我在 config 里把“商品画面出镜”设为候选片段的必需条件没有通过视觉验证的片段直接一票否决。重新跑了一遍效果立刻改善。这个坑非常典型Agent 的决策非常依赖提示词和规则权重你以为它能像人一样“看片子”实际上它是在做加权计算。5.5 改进后的第二次运行结果修改规则后第二次运行候选片段从 11 个缩到 7 个成片质量明显提升。这次人工干预只出现了一次字幕渲染时中文字体路径又要重新指定我改了 font 配置后自动跑完了剩余流程。这里也给一个经验如果你配置了视觉模型一定要在流程中强制使用它的结果而不是让它作为“可选项”。否则模型一定会优先走省事的文本路径最后选出来的东西就会偏。6. 真正该避开的坑不是算力不够是 Agent 太爱自由发挥最后说说整个部署和测试过程中遇到的那些坑。硬件不够只是让你慢规则没定好才会让你疯。6.1 上下文窗口溢出转写文本太长怎么办两小时直播转写出来一万多字扔给 7B 模型的上下文窗口一次根本装不下。就算能装下模型在长文本里的注意力也会涣散后半段的字幕和候选片段容易漏。我用的方式是分段处理加摘要压缩。OpenMontage 会把转写文本按时间切成若干段每段先做局部候选提取再汇总到全局决策。这样既不会溢出上下文也能保留所有关键点。如果你自己搭 Agent也要注意这种“先局部后全局”的策略不要让模型一次处理全部素材。6.2 工具权限边界别让它动你的原始素材Agent 在调用 ffmpeg 时有时候会产生一些中间文件名字起得很乱。我测试时给它配置了 work_dir 的完整写权限结果有一次它写了一个输出文件到原始素材目录差点把源文件覆盖。从此我把工具权限做了一个隔离Agent 只能读 raw 目录所有中间产物和输出都进 output 和 tmp 目录。规则上再增加一条禁止 Agent 对 raw 目录执行删除、覆盖、重命名操作。这个权限设计非常重要尤其是你打算让它自动跑很多天的时候。6.3 字幕编码和字体小问题卡住大流程字幕这块我踩了两回。第一回是字体路径问题前面提到过中文字幕渲染出来是方框。第二回是编码问题faster-whisper 输出的是 UTF-8但 ffmpeg 的 subtitles 滤镜在部分 Linux 环境下对 UTF-8 支持很差会出现字幕丢失。我的解决办法是统一走 ASS 字幕轨道在生成字幕时直接指定字体名并在 ffmpeg 命令里用:force_styleFontNameNoto Sans CJK SC。这样比直接烧录 SRT 稳定得多也方便后期替换字幕样式。6.4 模型能力边界7B 模型不是全能规划师7B 模型做简单决策没问题但涉及多步因果推理时还是会犯低级错误。比如有一次它把一个 1 分钟的长片段拆成三段然后又把三段拼回去中间出现两次硬切观感非常差。它在逻辑上“觉得”可以拆但没考虑到切换效果。我的应对方式是在任务规划层加规则候选片段超过 45 秒就先做内部去重不允许无意义地拆分再拼接。也就是说越了解模型的边界越要在上层规则里替它把路铺好。让模型做它擅长的选择而不是逼它去理解剪辑美学。7. 我的取舍哪些环节交给 Agent哪些必须人工兜底整体跑下来我对 OpenMontage 这套方案的判断是它能承担一条视频制作里 70% 的重复性工作但最后 30% 的审美和风险控制最好还是留给人。7.1 可以放心交给 Agent 的环节素材转写、关键词定位、候选片段提取、初剪拼接、字幕生成、格式转换这些环节交给 Agent 完全没有问题。它的稳定性和速度远超人肉尤其是每天要处理几个小时的直播录像时Agent 能做到批量化和可复用。你只需要把规则定义好它就像一个不会疲倦的剪辑助理。7.2 我坚持人工把关的环节成片里的敏感内容审核、品牌话术是否合规、商品价格是否准确、转场节奏是否符合账号风格这几项我目前还是人工看。因为 Agent 对“内容风险”的理解还很浅它可能把一个主播说错的口误也剪进来只因为那个口误附近有“优惠”两个词。另外片头的设计和标题文案我也会自己定。Agent 生成的标题不是不好而是太“工整”缺少账号需要的个人风格。把创造性工作留给人把重复性工作留给机器这个分工我觉得是现阶段最合理的。7.3 给也想本地部署 Agent 做剪辑的人几点建议如果你也要搞这套我最后说三个建议。第一先拿一条 30 分钟以内的素材跑通全流程别一上来就挑战两小时否则你分不清是规则问题还是环境问题。第二把任务描述写得像给实习生写需求文档一样具体时长、格式、字体、是否保留空镜都写清楚越详细效果越好。第三跑完第一步就去看日志不要只看成片日志里写清楚了 Agent 每一步在想什么排查问题全靠它。我在第一次跑通之后又用同一套配置跑了三条不同主题的直播素材发现只需要微调 brief 里的关键词和时长就可以稳定复用。这种时候我才觉得为了搭这套本地 AI Agent 流所花的折腾时间是真的值回来了。