用自然语言编辑视频：一个 AI Agent 的设计思考

当我们把视频编辑器的每一个操作都抽象成对一份结构化描述的修改时，一个有趣的可能性浮现了：让 AI 来做这些修改。

从一个事实开始

在构建视频编辑器的过程中，我注意到一件事：编辑器的所有状态，本质上可以用一份结构化描述来完整表达。有哪些轨道、每个片段的起止时间和位置大小、文字内容和样式、音频的音量和淡入淡出——界面上你能看到和操作的一切，都在这份结构化描述里有对应。

这意味着用户在编辑器里做的每一个操作——拖拽一个片段、调整音量、添加一段文字——本质上都是对这份描述的一次修改。

而 LLM 天生擅长两件事：理解自然语言意图，生成结构化数据。这两件事恰好对上了。

这不是一个我刻意寻找的结合点。它是在做编辑器的过程中自然浮现的——当你把问题看清楚了，解法就在那里。回头看，我觉得这是最重要的一步：找到 LLM 能力和业务需求之间真正自然的交叉点，比选择什么框架、什么模型重要得多。

两条路：操作界面，还是操作数据

当多模态大模型让 Agent 拥有了视觉理解能力之后，一个很直觉的想法是：既然 Agent 能”看到”屏幕，那让它直接操作界面不就行了？点击按钮、拖拽元素、填写输入框——像一个远程操控的人类用户一样完成任务。

这条路看起来通用，但实际效率和准确率都不高。原因在于 LLM 的本质——它是一个语言模型，最强的能力是理解和生成结构化文本。让它做视觉定位、像素级点击、拖拽距离估算，是在用它最弱的能力干活。每一步操作都要截图、识别、决策、执行，延迟高，容易出错，且难以回溯和纠正。

另一条路是让 Agent 直接读写结构化数据，通过 API 或函数调用来完成操作。这对 LLM 来说是完全不同的体验——输入是文本，输出也是文本，不需要做视觉理解，不需要计算坐标，效率和准确率不在一个量级。

一个很好的类比是 AWS。AWS 的 Web Console 极其复杂——几百个产品，无数页面和功能模块，对人来说都有很高的学习成本。如果让 Agent 通过操作 Web Console 来完成任务——理解每个页面的布局、找到正确的按钮、处理弹窗和确认流程——几乎不可能做得可靠。但 AWS 有非常完善的 Operations as Code 体系（CLI、SDK、CloudFormation）。同样的操作通过 API 来做，高效、稳定、可追溯、可复现。这就是为什么 Agent 在 AWS 生态里的落地，走的是 API 路线而不是模拟点击。

我们的视频编辑 Agent 走的正是这条路。不让 Agent 去操作编辑器界面，而是让它直接读写底层的结构化描述。对于 LLM 来说，理解一份结构化数据并生成一组修改操作，远比理解一张编辑器截图然后决定在哪个像素位置点击要自然得多。

这个选择背后有一个更普遍的判断：与其追求让 Agent 模拟人类的操作方式，不如找到问题本身的结构化表达，让 Agent 在它最擅长的领域工作。 模拟人类操作看起来是一条捷径，但它其实是在让机器做人类擅长的事，而不是让机器做机器擅长的事。

关于架构的克制

最初我考虑过设计一个多节点工作流——一个环节理解意图，一个生成操作，一个校验，一个重试。看起来很完整，但我最终没有这样做。

原因是回到问题本身看，这就是一个标准的”读取状态→理解需求→生成修改”循环。给 Agent 两个工具——读取当前编辑器状态、提交修改操作——让它自己决定什么时候该读、什么时候该改、出了错怎么修。LLM 的通用推理能力足以处理这个循环中的各种情况，不需要我用硬编码的状态机替它做决策。

这并不是说架构不重要。而是说在当前阶段，Agent 开发最大的陷阱是过度设计——你越试图预设行为路径，就越容易碰到预设之外的边界情况。把精力放在清晰的工具定义和可靠的反馈机制上，收益更大。

这也意味着这个 Video Agent 本质上是一个通用 Agent，只是配置了视频编辑相关的工具。同样的架构可以用在任何”用自然语言操作结构化状态”的场景。

增量修改 vs 全量替换

工具设计上有一个取舍值得展开说：让 Agent 每次输出修改后的完整状态，还是只描述”哪里改了什么”。

选择增量修改不只是因为效率——虽然一个视频项目可能包含几十个素材和时间轴元素，每次都输出完整状态确实浪费很大。更重要的原因是增量表达天然传递了意图：它说的不是”改完之后长什么样”，而是”我要改什么”。

这带来了一连串的好处。校验和错误定位变得很直接——逐条应用操作，哪条出错报哪条，Agent 可以精准修正。它也和编辑器的撤销/重做体系天然一致——Agent 提交的修改和用户手动操作在数据层面是同构的，不需要额外的转换层。

当然增量补丁也有代价：LLM 需要精确描述修改的路径和操作类型，早期确实出现过路径写错的情况。但通过清晰的提示词设计和逐条的错误反馈，这个问题被有效控制住了。比起全量替换带来的模糊性，路径偶尔写错是一个更容易处理的问题。

校验的时机决定了反馈质量

什么时候做合法性校验？我考虑过两种方案。

一种是只在最后同步给前端之前校验。性能好，但问题是——如果 Agent 在第三步操作就写坏了状态结构，它后面几步都在一个错误的基础上继续工作。最后拿到一堆错误反馈，很难定位到底是哪步出了问题，Agent 也很难有效修正。

所以我选择了每次修改都立即校验。逐条应用操作，出错立即报告——第几条操作、什么位置、什么问题。

这个设计有一个我没预料到的好处：Agent 自然而然地形成了一个自我纠错闭环。它改错了，系统告诉它具体哪里错了，它修正再试。这不是我预设的重试逻辑，是 Agent 观察到工具返回了错误后的自然行为。在实践中，大多数格式和引用错误都在一两轮反馈内被修正了。

这让我意识到一件事：对 Agent 来说，约束和校验不是限制，而是它可靠工作的基础设施。就像给一个人清晰的边界和即时的反馈，比模糊的自由更容易产出好结果。

多模态不是加分项

纯文本 Agent 有一个根本性的局限——它不知道视频里有什么。

用户说”把那段蓝色背景的部分删掉”，Agent 只能看到一堆文件名和 ID，不知道哪个素材有蓝色背景。用户说”音乐太吵了”，Agent 不知道音频实际听起来是什么感觉。这时候用户被迫去学习编辑器的术语——“第二个轨道上第三个片段”——来与一个本该让他们摆脱这些术语的工具沟通。这是矛盾的。

引入多模态能力之后，交互质量有了质的变化。Agent 可以直接”看到”和”听到”项目中的素材。用户可以说”那个有人在跑步的画面”，而不是去查找片段 ID。Agent 甚至可以主动去看最终合成的效果，判断编辑结果是否符合用户预期。

这里有一个工程上的现实问题：素材文件通常很大，不能每次对话都重新上传。我们在云端做了文件的上传和缓存管理，同一套素材在一段时间内只需上传一次，每次运行时自动检查缓存是否有效。这不是什么深奥的设计，但不解决它，多模态在产品里就用不起来。

回头看，多模态是这个产品体验的分水岭。之前的所有工作——结构化描述、增量修改、校验闭环——都是在让 Agent 能正确地操作数据。但多模态解决的是另一个层面的问题：让 Agent 的理解方式和人类用户的沟通方式真正对齐。

几个实践中才会碰到的问题

有些问题在设计阶段想不到，只有做了才会碰到。

指代消歧。 用户经常说”把这个调大一点”——“这个”是什么？在编辑器里，用户可能用鼠标选中了某个元素，但 Agent 看不到鼠标。解决方案是让前端把当前选中的元素信息传递给 Agent，同时在提示词里告诉 Agent：当用户使用”这个""当前""选中的”这类表达时，优先对应已选中的元素。一个小细节，但对交互自然度的影响很大。

结构化描述的持续演进。 视频编辑器的功能在不断迭代，结构化描述也会跟着变——新增元素类型、调整属性结构。早期我把每个字段的详细说明都写进了提示词，结果每次变化都要同步改提示词，维护成本很高。后来我意识到，只需要告诉 Agent 关键的结构规则和约束就够了，具体的字段它可以从读取到的实际数据中推断，校验层会兜底。这是一条教训：不要试图在提示词里穷举所有细节，告诉它规则，让校验替你守底线。

人机并行操作。 Agent 在工作的时候，用户可能同时在编辑器里手动操作，导致状态冲突。最终的方案是 Agent 工作时锁定编辑器界面。这类问题不复杂，但不处理的话用户体验会很差——Agent 改了一个东西，用户同时也改了，最后谁的结果生效？

这些问题最终都被抽象成了独立的中间件——校验、多模态缓存、选中状态注入、编辑锁——各自可以独立开关。Agent 的核心逻辑不需要知道它们的存在。这在调试和迭代时特别有用：怀疑哪个环节有问题，关掉对应的中间件就能快速定位。

回头看

做这个项目让我更清楚地理解了几件事。

视频编辑恰好处在 LLM 能力和业务需求的交叉点上——操作可以被结构化为增量修改，意图天然适合用自然语言表达。Agent 不需要”学会剪辑”，它只需要学会”正确地修改一份结构化描述”。这正是 LLM 擅长的事。

但这个交叉点本身不会自动带来可靠的产品。可靠性来自于围绕 Agent 构建的工程体系——增量修改让意图可追溯，逐步校验让错误可定位，中间件让关注点可分离，多模态让沟通方式可对齐。

这些东西单独看都不复杂。但它们组合在一起，决定了这个 Agent 是一个有趣的 demo，还是一个用户真的愿意在工作流里使用的工具。