OpenChatCut：让 AI 代理直接操作多轨时间线的开源视频编辑器
该项目围绕「Open-source, local-first conversational AI video editor with a professional multi-track timeline, Agent Skills, MCP integration, and Remotion rendering.」构建，适用于实际场景的开源实践，提供可复用的工具链与集成方式。
秒懂
- 它是什么？
- OpenChatCut 是一款本地优先、代理原生的视频编辑器，把 Codex、Claude Code 等外部代理和内置代理接入同一套时间线编辑工具。它强调可撤销、可检查的真实剪辑，而不是一次性生成的不可变视频。
- 适合谁用？
- 适合两类人采用：一是希望用自然语言驱动剪辑、但又不想放弃时间线精确控制的创作者；二是愿意把视频项目当作可编程资产、通过 MCP 协议让外部代理直接读写的开发者。不适合追求一键成片、不愿接触工程细节的用户，也不适合需要严格保密、不能接受 AGPL 传染性的商业团队。
- 能商用吗？
- 可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。
- 还在维护吗？
- 在维护。仓库最近一次提交在 5 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的不是剪辑问题，而是代理与时间线的割裂
传统剪辑软件给你精确的轨道控制，但 AI 生成工具通常只给你一个不可变的成品。OpenChatCut 想填平这道沟：让代理读项目、改项目、导出项目，而每一步都落在真实的时间线上。README 里那句「does not merely generate a video that can no longer be changed」是它的核心立场。它面向的是创作者和开发者，尤其是那些已经在用 Codex、Claude Code 这类代理工具、又不想放弃手动微调能力的人。如果你只是想要一个输入提示词就出片的工具，这个项目不是为你准备的。
核心机制：代理与编辑器共享同一套工具
OpenChatCut 的关键设计是「内置代理和外部 MCP 代理共享相同的编辑工具」。这意味着无论你从内置聊天框发起指令，还是从 Codex 或 Claude Code 通过 MCP 协议接入，代理操作的底层函数是同一套。项目文件里保存的是真实的轨道、片段、转场、字幕、效果和媒体，不是渲染后的死画面。编辑循环在 README 中写得很清楚：描述目标，代理读取项目，产生可验证的编辑，写入时间线，然后预览、调整、撤销，最后导出。这个循环的每一步都留下可检查的状态，因此你可以手动接管，也可以把项目交给另一个代理继续做。
从安装到跑通：具体命令与配置
README 的 Quick Start 部分没有给出完整命令，但从项目布局和常见 Electron 应用惯例可以推断，你需要先克隆仓库，然后安装依赖并启动开发模式。由于仓库是 TypeScript 写的 Electron 桌面应用，典型的启动流程是 npm install 后运行 npm run dev 或类似脚本。实际命令应以仓库内的 package.json 为准。API 密钥的配置遵循 BYOK 原则：密钥保留在服务端，不写进本地项目文件。这意味着你接入外部模型服务时，密钥管理在服务端完成，本地项目保持干净。MCP 接入方式在「Agent / MCP」章节有专门说明，但 README 被截断，具体配置键名无法确认。动手之前，先看仓库里的 README_ZH.md 和 package.json，那里才有准确的启动步骤。
转录驱动剪辑：字幕与画面的绑定关系
一个值得注意的能力是「转录驱动编辑」：词级转录、基于文本的剪切、暂停处理、说话人识别和关联字幕。这意味着你可以像编辑文档一样剪辑视频，按词选择保留或删除片段。字幕不是事后烧录的独立元素，而是与时间线片段关联。配合「视觉几何」功能，浏览器内的人像分割和面部安全区可以让字幕自动避开说话人，重构图跟随主体，叠加图形落在空白区域。这个组合解决了一个真实痛点：字幕遮挡人脸，或者图形压在主体上。不过，人像分割和面部安全区目前只在浏览器内运行，性能取决于你的机器，这一点文档没有给出量化指标。
导出与渲染：Remotion 的边界在哪里
导出能力包括 MP4、音频、字幕、FCPXML 和完整项目数据。Remotion 被列为渲染方案之一，这说明项目用 React 组件来描述视频帧，然后通过 Remotion 的渲染管线生成最终文件。这意味着导出过程是确定性的，代理生成的每个时间线状态都能被精确地渲染。但 Remotion 渲染通常需要 Node.js 环境和较长的渲染时间，尤其是复杂时间线。文档没有提到渲染性能或 GPU 加速情况，所以如果你需要批量导出大量视频，这个环节可能是瓶颈。FCPXML 导出是一个加分项，它允许你把项目移交到 Final Cut Pro 继续精剪，这比其他封闭格式的 AI 生成器更开放。
局限与失败模式：AGPL 与代理的不可预测性
最明显的限制是许可证。AGPL-3.0 意味着如果你修改了代码并通过网络提供服务，你必须公开源码。对于内部使用没问题，但如果你打算基于它做 SaaS 产品，AGPL 的传染性会是一个法律风险。另一个限制是代理本身的行为不可预测。虽然编辑是可撤销的，但代理理解自然语言并映射到时间线操作的准确性，完全取决于底层模型的推理能力。README 强调「可验证的编辑」，但验证的责任在用户身上。此外，项目还在快速迭代，v0.2.9 到 v0.2.11 相隔几天就发布一次，这意味着 API 和配置可能不稳定，升级成本需要计入。最后，本地优先意味着媒体文件存在你机器上，如果你在多台设备间切换，项目同步需要自己解决。
替代方案对比：传统编辑器与一次性生成器
直接替代品是商业的 ChatCut，但 OpenChatCut 明确表示自己是独立开源实现，不隶属 ChatCut。另一类替代是传统时间线编辑器，比如 DaVinci Resolve 或 Premiere，它们给你完全的控制，但没有任何代理接入能力，你无法用自然语言修改项目。还有一类是一次性 AI 生成器，比如 Runway 或 Pika，它们速度快，但输出不可编辑。OpenChatCut 的差异化在于它试图同时占据两边的优点：时间线精确性和自然语言操控。但这也意味着它比传统编辑器更复杂，比生成器更慢。如果你的需求只是快速出片，传统生成器更合适；如果你需要精细控制且愿意学习代理工作流，OpenChatCut 才有意义。
编辑结论
适合两类人采用：一是希望用自然语言驱动剪辑、但又不想放弃时间线精确控制的创作者；二是愿意把视频项目当作可编程资产、通过 MCP 协议让外部代理直接读写的开发者。不适合追求一键成片、不愿接触工程细节的用户，也不适合需要严格保密、不能接受 AGPL 传染性的商业团队。采用前先验证两件事：确认你的剪辑工作流是否真的需要代理介入，而不是只想要一个自动生成器；检查 AGPL-3.0 对你的分发方式是否构成约束，尤其是如果你计划修改后对外提供服务。最后，在 v0.2.11 这个阶段，项目仍处于快速迭代中，任何生产依赖都应该先锁定版本并跟踪 changelog。
社区笔记