1. 先说结论：AI Agent 和你想的可能不太一样
我直接用这句话开头吧：AI Agent 确实能独立做完一条视频，但它不是你想的那种“全自动一键出片”。
把标题里那个问号拆开看，很多人对 AI Agent 的第一印象是——丢给它几个素材，它自己写脚本、自己配音、自己剪好、自己导出，全程人不用管。老实说，我一开始也是这么想的，所以在本地把 OpenMontage 这套东西跑起来之前，我已经做好了“被惊艳”或者“被气笑”两种准备。结果实测下来，它的能力边界比我想象中清晰得多：素材分析、脚本生成、镜头筛选、粗剪排序这四件事，它基本能独立完成；但音频修整、色彩统一、节奏微调这些需要主观审美的动作，它仍然非常依赖人的介入。
更关键的是，很多人把 Agent 和 LLM、AI 模型混为一谈。比如有人问我：“DeepSeek 不是本地部署了吗，怎么还要装 OpenMontage？”这就是没分清楚——DeepSeek 属于 LLM（大语言模型），它的强项是“理解语言和生成内容”，但它本身不具备操作剪辑软件、扫描素材目录、调用渲染引擎的能力。而 Agent 可以理解为“一个能调用工具的 LLM 大脑”，它靠 LLM 做决策，靠外围工具（比如 MCP、脚本、API）做执行。OpenMontage 在这个链条里扮演的角色，就是把 Agent 和剪辑工具链缝在一起的那层胶水。
这篇内容我打算先把 Agent、LLM、模型这三者的关系说透，然后完整交代 OpenMontage 的本地部署过程、自动剪辑的实现逻辑，最后放上我的实测结果和踩坑记录。适合对 AI 自动化工作流感兴趣的剪辑师、自媒体运营、独立开发者，以及想本地跑 AI 工具但又不想被云服务限制的同学。
1.1 Agent、LLM、AI 模型到底差在哪
这三个词在热搜里天天出现，但大多数人其实没搞清楚边界。我用一个比较生活化的类比来说：
- AI 模型：相当于一个刚毕业的高材生，知识储备很足，但没有任何工作经验。你问它问题，它全能回答，但它不会主动去干活。
- LLM（大语言模型）：是 AI 模型中的一种，专门擅长理解和生成自然语言。像 DeepSeek、Qwen、Llama、GPT 都属于这一类。它解决的是“说什么”，不解决“做什么”。
- Agent（智能体）：相当于给这个高材生配了一套完整的办公桌——电脑、电话、文件夹、日历。它可以根据你的指令，自己去查资料、写邮件、排会议，甚至调用外部软件把活干完。
举个例子。你给 DeepSeek 一句话：“把这段采访视频剪出 30 秒的高光时刻。”DeepSeek 只能回你一段“应该怎么做”的文字建议，它动不了你的视频文件。但如果是一个配置好工具的 Agent，它可以自己扫描视频文件、转写字幕、用 LLM 分析哪几帧内容最有价值、然后调用剪辑软件完成剪切并导出成片。Agent 的价值不在生成，而在编排与执行。
1.2 为什么我坚持要“本地部署”
有人可能觉得现在云端的 AI 服务已经很成熟了，为什么还要折腾本地部署？我的答案很简单：视频素材涉及隐私和版权风险，而且素材量大，上传下载的时间成本根本耗不起。
本地部署的核心好处有三点：
- 数据不出机。原始视频、人物面孔、音频内容都留在自己的电脑/服务器里，不经过第三方平台，规避了素材泄露和版权争议。
- 无 API 费用和速率限制。云端调用按 token 计费，处理一条 20 分钟的视频可能需要几十万 token，成本不低；本地部署只要你配置好 Ollama + 开源模型，成本几乎为零，只是耗电。
- 可以自由改流程。本地部署意味着你可以直接修改 Agent 的工作流配置文件，比如自定义镜头筛选规则、拼接顺序、字幕样式，这些都是云端服务很难给你的自由度。
当然，本地部署的门槛也不是没有——需要一台像样的机器、需要解决显存/内存问题、需要看懂日志。但如果只是想跑通基础流程，8GB 显存 + 16GB 内存的机器其实是够用的，后面实测部分我会给具体配置。
2. 动手前要把三件事想清楚
在正式安装 OpenMontage 之前，我建议你先花十分钟把下面三件事捋清楚。因为安装步骤本身不复杂，真正决定你这套系统能不能跑起来、跑得好不好的，是你自己的素材、模型和工具链选型。
2.1 素材准备：你的视频要适合被“拆解”
Agent 剪辑视频的思路和人不一样。人是一边看一边剪，凭感觉；Agent 是先拆解后重组——它会把视频按镜头逐帧分析、转成文本、再由 LLM 判断每一段的“信息密度”，按照你给出的规则去挑选和排序。
所以，你的素材必须满足一个前提：画面里有可以被识别的信息。比如有人在说话（可以转文字）、有明显的场景切换（可以被抽帧识别）、或者有字幕/标题/图表（可以被 OCR 识别）。如果素材是一段纯黑屏、纯白噪点、或画面内容毫无变化的视频，Agent 会完全“瞎掉”，因为 LLM 没有视觉能力（除非你额外接入多模态模型），它只能依赖文本和元数据做判断。
我自己实测用的是三段素材，建议你参考这个思路准备：
- A 段：一段 8 分钟的访谈录屏，人物在说话、画面有轻微变化，用来测语音转写和关键词抽取。
- B 段：一段 12 分钟的产品演示视频，画面里有 UI 界面、鼠标移动、弹窗提示，用来测 OCR 和镜头分割。
- C 段：一段 3 分钟的纯风景 B-roll，没有对白，只有环境声，用来测“无文本素材”场景下 Agent 会怎么办。
这样做的好处是，你能快速摸清系统在不同素材类型下的表现边界。
2.2 模型选型：OpenMontage 该配什么“大脑”
OpenMontage 本身不自带 LLM，它像一个空壳公司，需要你给它雇佣一个“大脑”来做决策。我实测搭配的是Ollama 运行的 Qwen2.5-7B-Instruct，平时日常轻量测试用DeepSeek-R1-Distill-Qwen-7B做对比。为什么选这两个而不是更大的 70B 模型？
因为视频剪辑任务里面有大量的“结构判断”，不需要超强的推理能力，但需要稳定而快速的输出。7B 量级的模型在 4090 这类 24GB 显存显卡上，单次推理延迟只有几百毫秒，足够应付逐片段分析。用 70B 模型当然更聪明，但推理延迟会拉到几秒甚至十几秒，处理几十个切片时你会等到怀疑人生。
如果你显卡显存低于 8GB，也可以选更小的 Qwen2.5-3B，效果差一些但能跑。另外要提醒一句：模型量化格式会影响效果。Ollama 默认拉取的一般是 Q4_K_M 量化版，实测下来它对中文语境的理解比满精度差一丢丢，但在这个场景下完全够用；没必要为了追求效果去折腾 GGUF 满血版，体验差异不明显，还得自己编译依赖。
2.3 工具链：OpenMontage 到底帮你做了什么
在安装之前，我想先给你画一下这套系统的完整工具链条，免得你装完 OpenMontage 之后晕头转向：“这个东西到底是干嘛的？”其实它就是在一个工作流引擎里面，把下面这六件工具串起来了：
| 工具/模块 | 职责 | 类比 |
|---|---|---|
| OpenMontage 主程序 | 工作流编排、任务队列管理、进度跟踪 | 项目经理 |
| Ollama + LLM | 内容分析、脚本生成、决策输出 | 编剧/策划 |
| Whisper 或 FunASR | 音视频转文字（ASR） | 速记员 |
| FFmpeg | 抽帧、切片、拼接、转码 | 剪辑执行者 |
| Python 脚本/MCP 工具 | 镜头分割、OCR 识别、素材元数据提取 | 场记 |
| 文件系统（素材库） | 存放原始素材、中间产物、成片 | 素材库 |
OpenMontage 的核心价值就是让这些工具像流水线工人一样协作——它不替代终极剪辑效果，而是把“找素材、筛素材、按脚本粗剪、预生成字幕”这种枯燥重复的工作全部自动化。人工最后只需处理 AI 做不了的微调。工作流这块跑通之后，我最大的感受是：它不是我脑子的替代品，而是我双手的替代品。
3. OpenMontage 本地部署全流程实录
好了，进入正题。以下是我在实际环境里一步步操作的完整记录，所有命令都是验证过可用的，但你的环境多少会有些差异，别直接复制就完事，把每一步的检查项过一遍。
3.1 环境准备：硬件和系统要求
先说结论，我这套实验环境是：
- CPU：Intel i7-12700K
- 内存：32GB DDR5
- 显卡：NVIDIA RTX 4090 24GB
- 系统：Ubuntu 22.04 LTS
- 存储：NVMe SSD 1TB（素材读写很吃 IO，如果是机械硬盘建议换）
如果你配置低一些，也不是不能跑。我测试过的最低配置是：i5-10400 + 16GB 内存 + RTX 3060 12GB，素材短一点（3 分钟以内）、模型换小号（Qwen2.5-3B），流程依然能走通，就是慢。真正的硬性条件是：必须有一颗 NVIDIA 显卡，且驱动 + CUDA 环境可用，否则 Whisper 转写和 FFmpeg 硬件编码都会成为瓶颈。
装好系统之后，第一步先把基础环境补齐：
# 更新系统包 sudo apt update && sudo apt upgrade -y # 安装必备工具 sudo apt install -y git curl wget unzip ffmpeg python3 python3-pip python3-venv # 安装 NVIDIA 驱动和 CUDA（如果还没装） sudo apt install -y nvidia-driver-535 # 安装完成后 reboot 一次，然后验证驱动 nvidia-sminvidia-smi能正常显示 GPU 信息，说明驱动 OK。接着安装 CUDA 工具包，这里我直接用 Ollama 官方推荐的 CUDA 版本（实测 12.4 比较稳）：
wget https://developer.download.nvidia.com/compute/cuda/12.4.0/local_installers/cuda_12.4.0_550.54.14_linux.run sudo sh cuda_12.4.0_550.54.14_linux.run --toolkit --silent --overrideCUDA 装完记得把环境变量写进~/.bashrc，不然后面跑 Python 模型加速会找不到库。装好之后顺手验证一下：
echo 'export PATH=/usr/local/cuda-12.4/bin:$PATH' >> ~/.bashrc echo 'export LD_LIBRARY_PATH=/usr/local/cuda-12.4/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc source ~/.bashrc nvcc --version3.2 安装 Ollama 并拉取模型
OpenMontage 本身不直接调用 GPU，它通过 Ollama 这个本地推理服务来访问 LLM。Ollama 的安装非常简单：
curl -fsSL https://ollama.com/install.sh | sh装完以后先把服务启动起来：
systemctl start ollama systemctl enable ollama然后拉取模型。我实际用的命令是这样的：
ollama pull qwen2.5:7b-instruct-q4_K_M ollama pull deepseek-r1:7b这里要特别提醒：不要一次性把两个 7B 模型都拉下来再装 OpenMontage，先只拉一个，跑通整个流程再加第二个。我一开始就是贪多，两个模型都拉，加载 OpenMontage 的时候 Ollama 默认加载第一个，结果后面切换模型时缓存不干净，导致推理响应特别慢，排错排了半天。
拉完模型后验证一下 Ollama 能不能正常响应：
curl http://localhost:11434/api/generate -d '{ "model": "qwen2.5:7b-instruct-q4_K_M", "prompt": "你好，请用一句话说明你是语言模型", "stream": false }'如果返回了 JSON 格式的响应文本，说明 Ollama 服务稳定，可以继续下一步。
3.3 正式安装 OpenMontage 与最小配置验证
OpenMontage 的安装方式取决于你拉取的是哪个发行版。如果通过 Git 拉源码，流程是这样的：
git clone https://github.com/openmontage/openmontage.git cd openmontage python3 -m venv venv source venv/bin/activate pip install -r requirements.txt这里大概率会遇到一个坑：requirements.txt里某些依赖（比如torch、openai-whisper）体积很大，pip 默认源下载速度会想哭。建议先换国内 pip 源再装：
pip config set global.index-url https://mirrors.aliyun.com/pypi/simple/ pip install -r requirements.txt装完依赖后，需要做两件事：配置模型连接、初始化素材目录。
OpenMontage 的配置是一个 YAML 文件，比如config/config.yaml。核心的模型连接配置类似这样：
llm: provider: ollama base_url: http://localhost:11434 model: qwen2.5:7b-instruct-q4_K_M temperature: 0.3 max_tokens: 2048 agent: max_retries: 3 timeout: 300 enable_parallel: true storage: input_dir: ./data/input output_dir: ./data/output intermediate_dir: ./data/intermediate这里我花点篇幅解释几个关键参数：
temperature: 0.3：控制 LLM 输出的随机性。剪辑决策任务需要稳定性和一致性，所以我把温度调低到 0.3，防止同一个素材跑两次得到不同的剪辑结论。如果你希望 Agent 发挥更多“创意”（比如生成不同风格的文案），可以调到 0.7~0.9，但剪辑决策保持低温更靠谱。max_tokens: 2048：限制单次推理输出长度。视频片段分析任务通常不需要 LLM 写长篇大论，2048 够用，调太大反而拖慢响应。enable_parallel: true：允许 Agent 并行处理多个片段。如果你的机器只有 8GB 显存，这个参数建议改成false，不然多个并行请求会挤爆显存，直接 OOM。
配置完成后，初始化目录并做自检：
mkdir -p data/input data/output data/intermediate python main.py --init--init会检查依赖、目录权限、Ollama 连通性，并且跑一个 3 秒左右的“自检任务”——给 LLM 发一条return "ok"，验证整个链路通不通。看到system check passed或者类似的输出，就说明环境搭好了。这时候放一段短素材进去，跑一条最简单的“文本摘要”流程，确认整条流水线没问题，再进入下一步的自动剪辑实验。
4. 自动剪辑的核心实现逻辑
OpenMontage 部署成功只是万里长征第一步。真正有意思的东西在于它是怎么“自动剪辑”的。这部分我拆成三个环节来讲：理解素材、生成剪辑决策、执行渲染。
4.1 Agent 如何“看懂”一段视频
这是整个系统最关键也最容易被忽视的一环。Agent 没有眼睛，它不能像人一样通过观看视频来获取内容。它的“观看”路径是这样的：
- 音频转写：用 Whisper 把视频里的对白转成带时间戳的文本。比如
[00:00:03 - 00:00:08] "今天我们来聊一下Agent的实际应用…"。 - 抽帧 + OCR：每隔 N 秒抽一帧画面，用 PaddleOCR 识别画面里的文字、标题、UI 元素。这样即使没有人说话的 B-roll，只要画面有文字信息，Agent 也能“读”到内容。
- 镜头边界检测：用 PySceneDetect 或者其他镜头分割算法，把视频按画面切换切成多个独立的镜头片段，每个片段有自己的时长、分辨率、文件路径。
这三步完成后，一段视频在 Agent 眼里就变成了一个“带时间轴的文本剧本”加一堆“镜头素材文件”。它不需要真的“看视频”，它只需要读取这些元数据，然后交给 LLM 做判断。
这里有个实操细节：抽帧间隔不是越短越好。我一开始设的是 0.5 秒抽一帧，结果一个 10 分钟视频抽了 1200 帧，OCR 跑了将近 20 分钟，而且绝大多数帧内容重复，浪费大量算力。后来改成 2 秒抽一帧，效果完全够用，速度却快了 4 倍。对于对白密集的访谈类视频，甚至 5 秒一帧都行，因为 Whisper 的文本信息已经足够支撑判断了。
4.2 剪辑决策是怎么生成的
这一步是 Agent 的“大脑时刻”。OpenMontage 通过 Agent 工作流，将脚本生成、片段筛选和排序决策串联起来。
比如我希望 Agent 自动生成一条“高光时刻混剪”，我在 workflow 配置里给 Agent 的定义是：
系统提示词（System Prompt）： 你是一个视频剪辑助手。用户会提供一段视频的镜头列表，每个镜头包含：镜头ID、时间范围、文本转写内容、画面OCR文本。请从中选出3到8个最能体现视频核心观点的镜头，按叙事顺序排列。返回格式为JSON数组。然后 Agent 会把转写文本作为用户输入发给 LLM，LLM 返回类似这样的结果：
[ {"shot_id": "shot_003", "reason": "开场提出核心问题，建立观众预期"}, {"shot_id": "shot_017", "reason": "详细讲解关键概念，有清晰案例"}, {"shot_id": "shot_034", "reason": "总结观点并给出行动建议"} ]这个 JSON 就是剪辑决策的核心。后面 FFmpeg 怎么切、怎么拼、按什么顺序拼接，都是根据这个 JSON 来执行的。
这里有一个值得注意的点：Prompt 工程质量决定了剪辑质量。我用过两种 Prompt 风格做对比：
- 第一种（模糊型）：“选出最值得保留的镜头。”结果它选了 15 个，有一段 3 分钟的废话居然全被保留了。
- 第二种（结构化型）：列出明确的量化标准，比如“每个镜头不得超过 15 秒”“必须包含一次关键词 X”“优先选择人物正面特写、字幕出现完整、音频清晰无噪音的镜头”。结果输出的片段列表明显更精准。
所以如果你用 OpenMontage 做自动剪辑，不要只调模型，更应该花心思去打磨 workflow 的 Prompt 模板。
4.3 从 JSON 决策到成片的执行链路
决策出来后，剩下的事情就交给“执行型 Agent”。OpenMontage 内部维护着一个任务队列，会把 JSON 里的每个镜头都转成一个 FFmpeg 命令去执行。
举个实际例子，对于shot_003，它可能生成这样的命令：
ffmpeg -ss 00:00:03 -to 00:00:08 -i input.mp4 -c copy -avoid_negative_ts make_zero shot_003.mp4把每个选中的镜头都切成单独文件，然后再按顺序拼接：
ffmpeg -f concat -safe 0 -i list.txt -c copy output.mp4中间还会穿插字幕生成任务，Whisper 转写的结果会按镜头切分，自动生成 SRT 字幕文件，再用 FFmpeg 烧录进成片：
ffmpeg -i output.mp4 -vf subtitles=subtitle.srt final_with_sub.mp4整个执行链路有个容易踩的坑：FFmpeg 的 concat 拼接要求所有片段的编码参数一致（分辨率、帧率、编码器都要相同），否则拼出来的视频会音画不同步或者黑帧。解决办法是在切片时统一加上-r 30 -s 1920x1080这类参数，强制统一输出规格。
5. 完整实测：从素材到成片的真实表现
理论讲完，咱们来看真实数据。我用前面说的三段素材跑了一次完整的自动剪辑流程，目标是把三段素材自动合成一条 60 秒左右的“项目经验介绍视频”。
5.1 实测环境和参数
测试用的配置还是那套 RTX 4090 + Qwen2.5-7B。Workflow 的具体设置是：
- 目标时长：60 秒
- 目标镜头数量：6~10 个
- 转写模型：Whisper large-v3
- OCR 抽帧间隔：2 秒
- LLM 温度：0.3
- 输出分辨率：1920x1080 30fps
素材总共加起来约 23 分钟，视频文件总大小约 1.8GB。
5.2 实测过程中的时间分布
整个流程从丢素材进input目录到 final 成片输出，总共耗时约 18 分钟，各阶段耗时如下：
| 阶段 | 耗时 | 说明 |
|---|---|---|
| 镜头分割 + 元数据提取 | 3 分 20 秒 | 主要是 PySceneDetect + FFmpeg 抽帧 |
| Whisper 音频转写 | 7 分 10 秒 | 用 GPU 加速，否则这一步要 30 分钟以上 |
| OCR 文字识别 | 2 分 05 秒 | PaddleOCR 跑 23 分钟素材的抽帧 |
| LLM 剪辑决策 | 1 分 40 秒 | 几百个镜头片段逐批送入 LLM 分析 |
| FFmpeg 切片 + 拼接 + 字幕烧录 | 3 分 30 秒 | 硬件编码，速度很快 |
对比我人工剪同样一条视频，光是把 23 分钟素材完整看一遍就要 25 分钟，再加上思考结构和拼接，怎么也要两三个小时。这套流程在时间上确实有数量级的优势。
5.3 成片质量的客观评价
说句公道话，成片质量不是“惊艳”，而是“可用”。
先说做得好的部分：
- 叙事结构确实成立。Agent 选的镜头顺序是：提出问题 → 展示方案 → 演示效果 → 总结价值，这和我人工会选择的叙事逻辑几乎一致。
- 无“无效镜头”。23 分钟素材里大量的停顿、废话、操作失误镜头全部被筛掉了，成品里没有任何一段明显多余的画面。
- 字幕时间轴准确。Whisper 的转写精度非常高，烧录进成片的字幕基本没有错别字。
再说它的短板：
- B-roll 场景直接放弃了。那段纯风景素材被 Agent 判定为“无有效叙事信息”，全部排除在外。这意味着如果你希望成片里有精美的空镜穿插，Agent 目前做不到，需要人工手动补充。
- 配音衔接生硬。两个不同场景的镜头拼接处，背景音突然切换，听感上像“跳台”，没有人工剪辑时常见的“自然过渡”处理。
- 无法处理情绪节奏。它能保证逻辑通顺，但没法像人一样判断“这里需要一个停顿来强化共情”“这句之后要留 3 秒空白让观众消化”。
所以我的结论是：Agent 可以帮你完成 80% 的粗剪工作量，但剩下 20%的画龙点睛还得靠你自己来。如果你把这套系统定位成“剪辑助理”而非“剪辑师”，它的价值会发挥得最好。
6. 常见问题与坑位排查实录
这一段是我最想写的部分。因为在折腾 OpenMontage 的过程中，我几乎把能踩的坑全踩了一遍，下面这些内容全是我实际遇到并且验证过解决方案的。
6.1 本地部署最常见的 5 个问题
| 问题 | 现象 | 原因 | 解决办法 |
|---|---|---|---|
| Ollama 没启动 | 访问localhost:11434连接被拒绝 | 服务没启动或开机不自启 | systemctl start ollama并systemctl enable ollama |
| 模型加载奇慢 | 第一条推理等 30 秒以上 | 显存不足或模型被反复换进换出 | 关掉其他占用显存的应用；减少OLLAMA_NUM_PARALLEL；只保留一个模型 |
| FFmpeg 拼接黑帧 | 成片中间有 0.5 秒黑屏 | 切片编码参数不一致 | 切片时统一-r、-s、-c:v参数；用concat demuxer前先转码成统一规格 |
| Whisper 显存溢出 | 进程直接崩掉或者 killed | large-v3 显存占用太大 | 换成small或medium模型；降低 batch size；或用 CPU 推理（慢但稳） |
| Agent 输出 JSON 解析失败 | 工作流卡住，报 JSONDecodeError | LLM 偶尔输出带解释文字的假 JSON | 在 Prompt 中指定“只输出 JSON，不要任何解释”；在后端代码里加一层容错解析，用正则提取{...}部分再 json.loads |
6.2 一个很容易被忽略的“硬伤”：素材目录权限
这个问题不复杂，但很隐蔽。当时我把素材放进data/input目录，结果 Agent 一直报“找不到文件”。排查了半天才发现，input_dir路径是相对路径，而 OpenMontage 的定时任务是用systemd跑的，工作目录不是项目路径，导致它找的是/data/input而不是/home/user/openmontage/data/input。
解决方案有两种：
# 方案一：启动脚本里强制 cd 到项目目录 cd /home/user/openmontage && python main.py # 方案二：配置里写成绝对路径 # config.yaml storage: input_dir: /home/user/openmontage/data/input这种看起来“笨”的问题最容易浪费大量时间，建议你在开始跑之前就把配置里的路径全部改成绝对路径。
6.3 超大素材的处理技巧
如果你素材超过 30 分钟，会遇到另一个问题：LLM 上下文窗口装不下。Whisper 转写一段 30 分钟视频的文本大约有 8000~10000 个 token，加上系统提示词和镜头列表，很容易把 7B 模型的 8K 上下文窗口撑爆。
我的处理方式是：分批处理。让 Agent 先把完整视频按时长切成 3~5 分钟的小段，每段单独做转写和镜头分析，最后再汇总所有小段的结果交给 LLM 做“全局决策”。这样既能绕开上下文限制，还能利用 Agent 的并行能力同时处理多个小段，总耗时反而更低。
另外一个提升效率的技巧是：素材导入前先用 FFmpeg 做无损压缩。比如把 4K 素材先降采样到 1080p，Whisper 只提取音频不受分辨率影响，OCR 抽帧的分辨率要求也没有那么高。这样处理速度能快两三倍，成片质量差异几乎看不出来。
6.4 关于“自主创作”的边界反思
最后说点题外话，也是这几天实测下来我个人体会最深的一点。
AI Agent 在视频制作这件事上，目前的真实定位其实是“高密度执行的执行者”而非“创作者”。它能不知疲倦地看完所有素材、准确转写出每一个字、严格遵循规则筛选镜头——这些是人的短板。但“为什么这一段要留？”“这一段放在哪里最能打动人？”“整条片子要有怎样的情绪节奏？”这些问题，它不会主动去思考。
我也试过通过修改系统提示词让 Agent 加入创意，比如“请用电影化叙事手法排序镜头”“请加入悬念感”。结果是它能照做，但做出来总有一股“正确的无聊感”。就像一个很努力但缺乏天分的实习生，你交代什么它做什么，做得规规矩矩，但谈不上灵气。
所以我现在的工作流是：Agent 负责粗剪，我负责二改。它快速产出一个逻辑通顺的初版，我再花 15~20 分钟调整节奏、补充转场、处理音频细节。相比以前从零开始剪，整体效率提升了不止一倍。这或许才是 AI Agent 在视频制作领域最务实、也最有效的使用方式。
最后分享一个实操中的小技巧，也是我这几天的压箱底心得：跑完一次完整流程后，把 Workflow 配置里 Agent 生成的中间 JSON 决策文件都留好。这些数据是你调优 Prompt 的黄金资料，因为你可以对照人工剪辑的结果反推 Agent 的判断哪里出了问题，然后精准修改提示词，而不是像无头苍蝇一样瞎试参数。这个习惯让我在工作流改进上省了大量时间。
