不是工具，是神器——AI视频生产的下一场革命

丞相曰：AI这场逐鹿，比的不是谁马快，是谁粮多。粮就是算力，就是数据。

故事是这样的。

前几天有个后生找我，说想做视频，问我用啥工具。这问题问得让我有点恍惚。前两年，问这个问题的还是"我想做个动画""我想剪个片子"，现在变成了"我有个idea，能变成视频吗"。变化太快，让人甚至有点跟不上。

但我当时就有点不对劲。

不是工具本身不对，是这问题本身就暴露了一个深层的困惑——我们好像终于能造出把想法变成视频的工具了，可我们还是不知道怎么用好它。

这不是个新鲜事。还记得几年前我们搞AI绘画的时候吗？那时候大家兴奋坏了，说这下好了，随便画几笔就是大片。结果呢？学会用工具的人更焦虑了。因为工具是好用了，但怎么把工具用好，还是得靠脑子。你说，这算进步吗？

这次也一样。

你说现在AI视频生成工具够多了吗？Runway、Pika、Luma……多到什么程度？多到你根本记不住那么多名字。每个工具都说自己是最好的，每个都说能帮你快速出片。但问题是，它们能帮你出片，但能帮你搞定整个项目吗？

屏幕前的你，你应该知道我说的是什么。

视频制作从来不是加个按钮生成个视频就完事了。它是一串连串的决策链——你选什么风格、调什么参数、接什么素材、怎么剪辑、怎么转场、怎么配乐、怎么调整节奏……这一串下来，不是加一个「generate video」按钮就能解决的。

传统的视频软件之所以复杂，是因为它把这一串东西都塞在一个界面里，让你手动做决策。

AI能解决这个吗？

AI模型能生成好画面，但它没法帮你做决策。它不会说「这一段转场用淡入淡出更好」，也不会主动建议你「这儿的节奏太慢了，建议缩短」。它就是个工具，你得知道怎么用。

这就是一个有意思的地方。

我们这行有个奇怪的趋势——总是在追"下一个大模型"。哪个模型更好、哪个模型生成得更快、哪个模型细节更丰富。但这有个问题：模型再好，也只是工具。好工具≠好产品。工具是用来用的，产品是用来解决问题的。

有人开始意识到这个问题了。

最近我注意到一个叫OpenMontage的东西，源代码在GitHub上。讲真，我一开始没在意。又是"AI视频生成"？这年头还有啥新鲜玩意儿？但我翻了两页，就有点不一样了。

它的描述不是"AI视频生成器"，而是"video agentic framework"。agentic，中文叫代理。这个词听起来挺洋气，但意思其实很简单——它不是让你操作工具，而是让你写一个「代理」来代替你做决策。

你想啊，这是个什么逻辑。

传统方式：你写提示词 → 工具生成视频 → 你不满意 → 你调参数 → 再生成 → 再调……周而复始。

OpenMontage方式：你描述你要什么结果 → 代理看懂了 → 代理自己调用各种工具、调整参数、一步步完成……你只需要等。

这种思路本身不新鲜。ChatGPT时代大家就开始聊"如何让AI做决策链"。GitHub Copilot能帮你写代码，不是因为它能比你写得快，而是因为它能读懂你的意图。AutoGPT能自主完成任务，不是因为它有多聪明，而是因为它能自己拆解任务、调用工具、优化过程。

但在视频制作这个场景下，真正落地成可用的系统，OpenMontage是较早把这条路走通的。

它的核心思路很清晰。不要让用户去操作一个个工具，而是让用户写一个「代理」来代替他们做决策。这个代理会看输入——脚本、素材、风格要求——然后自己调用各种工具、调整参数、一步步完成视频制作。用户不需要懂具体的操作逻辑，只需要描述「我要什么样的结果」，剩下的交给代理。

这个项目有个创始人，叫calesthio。关于这个人，公开信息很少。从他能做出一个这么完整的视频Agentic框架来看，我猜他是技术背景深厚的人——要么是开发者自己被传统视频软件的繁琐折磨到受不了，要么就是做内容创作的，深知视频制作的痛点。

你想想，这种动机多合理。

真正有价值的产品，往往不是想"做个更有用的工具"，而是"我自己有需求，这个需求没被满足"。不是因为"我觉得这个市场很大"所以来做，而是因为"这事儿老子有经验，这事儿老子有痛点"。

从公开信息来看，calesthio的动机可以从两个角度理解：

技术角度——他已经理解了当前AI视频生成的能力边界。模型能做的是"生成画面"，而不是"做决策"。他想要做的，是把这个边界往后推一步，让AI从"工具"变成"过程管理者"。

实践角度——他可能本身就是视频制作或者AI研究者，深知视频制作这个领域有多复杂。传统工具的痛点、AI工具的局限、用户需求的缺口，这些他都清楚。

第一个真正让人印象深刻的信号，是他没有选择做一个"又一个AI视频生成器"。市面上已经有太多这样的项目了，他选择了一个更难的路径：做视频制作的框架，而不是做单一功能的产品。

为什么说这条路更难？

单一功能的产品，只需要解决一个任务——让模型生成好画面。但框架要解决的是一系列任务：如何让多个AI模型协同工作？如何让代理学会判断何时该用哪种工具？如何让用户能方便地定义自己的代理？如何让整个系统能够扩展？这不是一个"模型优化"的问题，而是一个"系统设计"的问题。

从这个角度看，OpenMontage的起点就不是一个"能跑通"MVP，而是一个有明确技术路线和设计理念的产品。这一点从项目一开始就立住了——它不是"试试水"的项目，而是"这条路我要走到底"的决心。

它的发展历程，大概可以分成这么几个阶段：

萌芽期，从idea到MVP。这是最关键的阶段。一个好的Agentic框架，必须先有一个能跑通的"最小闭环"。OpenMontage的早期版本，应该已经实现了模型调用层、工作流编排、代理调度这些核心能力。如果这些基础能力在早期版本就具备了，那说明calesthio在框架设计阶段就做对了一件事：抽象层级要足够高，但接口要足够开放。

太高了，用户用不了；太低了，做不到Agentic化。这个平衡点很难找，但OpenMontage显然已经迈过了这个坎。

增长期，功能完善与生态扩展。有了框架，接下来就是往里面填充内容。这一阶段的关键是让框架变得"有用"——不仅仅是能跑通一个demo，而是能解决真实用户的问题。OpenMontage在这个阶段做了几件事：增加预训练模型、扩展工作流模板、增加编辑工具。

这一步的意义在于，它把一个"概念性的框架"变成了"可用的产品"。用户不再需要自己设计工作流，只需要选一个模板，填好内容，然后代理自己会把视频做完。

成熟期，社区建设与影响力扩大。这一阶段的关键信号是，开始有人贡献代码、提出问题、分享使用案例。更多第三方模型接入、更多工作流模板、教程和文档完善。这个阶段的重要性在于，它标志着项目从一个"个人项目"变成了"社区项目"。社区不仅是用户，也是共同的建设者。这种反馈循环会让项目越做越好。

我有时候在想，这个故事里面有没有什么值得琢磨的地方。

回顾OpenMontage的发展历程，有几个关键决策点值得玩味。

第一个决策，是选择"框架"而不是"单一产品"。这是最核心的决策。如果calesthio选择做一个"又一个AI视频生成器"，他现在可能是在跟Runway、Pika竞争，拼的是模型能力、用户体验。但他选择了框架，这让他跳出了红海竞争，进入了一个更蓝海的领域。

这个决策的本质，是选择了"难但长远"的路径。难，因为框架的设计难度远高于单一产品；长远，因为框架的价值在于"持续扩展"，而不是"一次性功能"。

第二个决策，是强调"AI Agentic"而不是"AI Video"。这个决策说明calesthio对AI发展方向的判断是准确的。当前AI的最大趋势之一，就是从"生成内容"向"管理内容"转变。ChatGPT不仅能聊天，还能帮你写代码、订票、规划行程；GitHub Copilot不仅能提供建议，还能直接编辑代码；AutoGPT不仅能回答问题，还能自主完成一连串任务。

OpenMontage选择的是这个趋势的"视频制作版"。它强调的不是"AI能生成什么画面"，而是"AI能帮你做什么决策"。

这个决策的重要性在于，它把OpenMontage和其他AI视频工具区分开了。不是所有做AI视频的项目，都会想到"Agentic"这个方向。但那些想到的，已经走在前面了。

第三个决策，是保持开源。开源有两个好处：一是让更多人能用、能贡献、能改进；二是降低使用门槛——用户不需要企业才能用得起。

但开源也有代价：维护成本高、容易被抄袭、商业化路径不清晰。很多项目都想开源，但真正能坚持下来的不多。

OpenMontage选择开源，说明calesthio的愿景很明确：他不想做一个"封闭的工具"，而是想做一个"开放的生态"。他愿意承担维护成本，愿意让社区一起建设，这需要信心和决心。

说到这儿，我想跟你说个有意思的现象。

如果我们按"AI视频生成"这个维度来看，OpenMontage有大量直接竞品：RunwayML、Pika Labs、Luma Dream Machine、Stable Video Diffusion相关工具……这些都是做"AI生成视频"的。

但如果我们按"Agentic框架"这个维度来看，OpenMontage几乎是独一无二的。目前市面上还没有其他明确以"Agentic"为核心卖点的视频制作系统。

这里会出现一个有趣的分化：

从AI视频生成工具的角度看，OpenMontage是一个竞品，而且是后来者。

从Agentic框架的角度看，OpenMontage是一个独占性很强的产品，几乎没有直接竞品。

这个判断很重要，因为它决定了OpenMontage的竞争策略。

如果把它当成AI视频工具的竞品，那它需要跟RunwayML、Pika这些巨头竞争，拼的是模型能力、用户体验、商业化路径。这条路很难走，但胜在市场规模大。

如果把它当成Agentic框架，那它需要的是构建生态、吸引开发者、证明框架的普适性。这条路也不容易，但胜在竞争少、壁垒高。

从目前的发展趋势来看，OpenMontage明显在走第二条路——它强调的是框架、工作流、代理调度，而不是单一功能。这说明calesthio对这个定位的判断是清晰的。

有意思的是，如果把主要竞品也放到时间线上看，它们的起源和演变路径有什么不同？

Runway的起源和OpenMontage很不一样。它不是从"解决某个痛点"开始，而是从"AI视频生成"这个概念直接切入。早期的Runway主要解决的问题是"如何用AI帮你快速生成视频"。它的第一个版本可能只是简单的"文本生成视频"功能，然后慢慢扩展到更多功能。

Runway的演进路径是"从点到面"——从一个核心功能，逐步扩展到整个视频制作流程。它的核心矛盾是"如何在保持简单易用的同时，做更多功能"。

Pika的起源和Runway也很不一样。它不是从"完整平台"切入，而是从"极简体验"切入。它的第一个版本可能只是简单的"文本生成视频"，而且只用了一个按钮，输入文字描述就能生成视频。

Pika的演进路径是"从简单到复杂"——从单一功能，逐步扩展到更多功能。它的核心矛盾是"如何在保持简单易用的同时，增加更多功能"。

OpenMontage的起源和Runway、Pika都不一样。它不是从"功能"切入，而是从"框架"切入。它的第一个版本可能不是一个"能用的视频生成器"，而是一个"能跑通的Agentic框架"。

OpenMontage的演进路径是"从框架到应用"——从抽象的框架，逐步扩展到具体的应用。它的核心矛盾是"如何在保持框架抽象性的同时，让它变得有用"。

这个路径的优点是技术路线清晰，长期价值明确，缺点是初期用户获取困难，需要很长时间才能证明自己的价值。但OpenMontage的优势是设计理念清晰，社区更容易理解它的长期价值。

我有时候会觉得，OpenMontage的故事有点像当年那些坚持做基础设施的项目。

那帮人不是不做"应用"，而是知道"应用"会随时间变化，但"基础设施"能长久存在。模型会迭代，但框架的设计思想不会过时。场景会变化，但代理的协作逻辑不会改变。

这条路不好走。一开始你看不到效果，没人愿意用，社区不起来，生态建立不起来。但这条路走通了，就能形成壁垒。这壁垒不是靠某个特定模型，而是靠积累的知识和经验。

这让我想到一个问题。

技术发展到现在，我们是不是已经开始追逐"下一个大工具"了？看哪个模型能生成什么、看哪个工具功能更多、看哪个平台体验更好。但有没有人停下来想过，工具再好，也得有人会用。而要用好一个工具，你得先理解它背后在想什么。

这就回到了OpenMontage的核心——它不是在教你"怎么用这个工具"，而是在教你"怎么让AI帮你做决策"。

这个思路很有意思。因为一旦你理解了这一点，你会发现它不仅仅适用于视频制作。

它适用于任何复杂的、需要多步骤决策的任务。写代码？让AI帮你规划模块、优化结构。写文章？让AI帮你梳理逻辑、补充细节。做项目？让AI帮你拆解任务、管理进度。

这不是一个"AI视频工具"的问题，这是一个"Agentic思维"的问题。

我有时候会想，如果曹操生在现代，他会怎么思考这个问题？

他那帮谋士，文有荀彧郭嘉，武有五子良将。他们不是单个厉害，而是协同起来特别厉害。郭嘉出主意，荀彧搞后勤，张辽冲阵地。这个组合才强大，不是单个人厉害。

现在的AI也是一样。一个模型再厉害，也不如一个能协调多个模型、能做决策的框架强大。

这就是为什么我看好OpenMontage。

它不是在做"下一个大模型"，而是在做"下一个曹操的谋士团"。它让AI从孤零零的工具，变成能协作、能决策的代理群。

这条路很难。难在不是技术问题，是认知问题。很多人还停留在"AI是工具"的阶段，很难理解"AI是决策者"这个转变。

但路的方向是对的。从"生成内容"到"管理内容"，从"工具"到"代理"，这是一个明显的趋势。OpenMontage是较早把这条路走通的人之一。

最终，OpenMontage的命运，取决于calesthio的判断和决策。他需要平衡"保持开源和独立"与"获得资源和影响力"；他需要平衡"追求技术理想"与"满足用户需求"；他需要平衡"长期愿景"与"短期生存"。

这些判断和决策，会决定OpenMontage的未来。

说到这儿，我想起了那句话——别人的路是讲出来的，我的路是踩出来的。

AI这条路，也一样。

丞相曰：AI这场逐鹿，比的不是谁马快，是谁粮多。粮就是算力，就是数据。

既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看老夫的文章，我们，下次再见。

/ 作者：曹丞相的AI之路 / 投稿或爆料，请联系邮箱：caochengxiangai@126.com^[1]

引用链接