Video Agent Loop：StarCut 的双循环架构，DeepSeek Harness 能接住吗？

onbing · 2026-08-21

Video Agent Loop：模型通过工具进入持续变化的视频项目

假设用户让 Agent 做一条三十秒的新品视频。Agent 看过当前项目，决定先生成一组产品特写；任务刚发出去，这一次模型运行就结束了。

素材还在生成，创作者没有停下来。他可能已经把开场从三秒剪到一秒半，删掉原来的镜头，又补了一句旁白。等图片返回时，Agent 面对的已经不是刚才那个项目。

这才是视频 Agent 的核心问题：一次模型运行很短，创作现场却持续变化。系统不只要记住“发出了什么”，还要让结果回来以后重新进入判断，而不是机械执行一份过期计划。

先把结论放在前面：StarCut 最终也没有离开这条基本循环，只是把它分成了两个时间尺度。内层是一次 Run 里的多 Step ToolLoop；外层是跨 Run、跨进程的持久 Session 恢复循环。下面从最小的一圈开始，看它为什么会一层层长成现在的样子。

一、先把 Agent 还原成一个 ToolLoop

大家经常用 ReAct 描述 Agent：reasoning、acting，再 reasoning。这个概念没有错，但它太容易停留在模型“会思考、会行动”的抽象层。工程真正需要实现的，其实只有一条可以运行的链路：

最小 Tool Loop：模型判断、调用工具、读取结果并进入下一步；多个 Step 构成 Run，多次 Run 构成 Session

一次模型请求是 Step；同一进程里的多个 Step 是 Run；跨越多次 Run 的持续任务才是 Session。我们称它 ToolLoop，因为它只描述可运行的事实：判断、调用、拿到结果、继续。

StarCut 的内层循环选择 Vercel AI SDK 7 的 ToolLoopAgent，把模型适配、参数校验、多 Step 和流式输出这些通用问题交给它；我们只设计视频业务真正不同的运行边界。

二、Tool 是手，Skill 是说明书

模型本身既看不见项目，也改不了时间线。它能做什么，取决于系统给了它什么样的手和感知系统。

Skill 是按需加载的方法，Tool 是视频 Agent 的感知、操作、协作和异步能力

Tool 真正作用于世界；Skill 只告诉模型何时、怎样组合 Tool。StarCut 让 Tool 保持稳定、可校验、可执行，只在基础上下文中放入 Skill 的名称和用途，需要时再加载完整方法。

到这里，一个普通 ToolLoop 已经能工作：查询模型、读取项目、编辑时间线、取得结果，然后继续。但视频创作很快会把这个循环撑破。

三、视频创作为什么把一个 Loop 撑成了两层

视频创作把三种差异塞进了同一个任务：工具可能在人、服务端、浏览器或 Worker 上执行；耗时从毫秒跨到几分钟；而 Session 还要活过断线、重启和部署。这三个约束共同推出 StarCut 的双循环：

StarCut Video Agent Loop：内循环在一次 Run 中连续使用工具，外循环在用户、任务和项目发生变化后恢复新的 Run

内循环推进当前判断，外循环把变化后的世界重新交给 Agent。Delta 只负责让用户即时看见过程；完整消息和 Inbox 才负责恢复。外循环也不让模型永远运行，而是让每个有限 Run 结束，再由新的事实触发下一次 Run。

这也是 DeepSeek Harness 真正值得观察的地方。它的 append-only Session Log、Inbox 和可替换 Agent Loop，覆盖的正是这层通用问题。但视频项目、后台 Task 和浏览器执行权是否能在不复制状态的前提下接进去，要继续往下看。

四、一条 Tool Call，怎样跨过四种执行边界

模型只应该知道“我要调用什么能力”，不应该知道当前是哪台服务器、哪个浏览器标签页或哪一个 Worker 在执行。于是我们把 Tool Call 本身和执行位置拆开。

同一 Tool Call 先成为已提交消息，再分别交给 Human、Server Runner、Client Runner 或 Task Worker；结果统一回到 Inbox

完整 Tool Call 先成为已提交消息；消息流让各类执行者都能看见它，执行策略、租约和凭证再决定谁能行动。结果统一回到 Inbox：Run 还在，就继续当前 Run；Run 已结束，就唤醒下一次。

`ask_user`：问题发出去以后，旧进程可以消失

假设 Agent 做到一半，需要用户决定成片用 16:9 还是 9:16。它保存问题，Run A 就可以结束：

ask_user 的完整时序：Run A 保存问题后结束，用户在 Editor 回答，答案进入 Inbox，Run B 从同一个问题继续

ask_user 验证的不是 Client Runner，而是更基础的一件事：一次 Run 可以结束，同一项任务仍然能够从人的回答继续。

`query`：为什么要绕一圈

生成图片或配音之前，Agent 要先查询适合的模型；权威目录在服务端，但具体查询不写进通用 Loop：

query 的完整时序：ToolLoop 保存调用，Server Runner 查询权威模型目录，结果经 Inbox 回到同一次 Run

多走这一圈不是为了异步，而是让 Loop 只管理调用的生命周期，应用层负责真实实现；即使中途崩溃，已经保存但尚未完成的查询仍能被找回来。

五、长任务怎样回来：Monitor 盯变化，Clock 盯时间

一段视频可能几分钟后才生成。模型进程不应该等在原地；StarCut 用两种方式把未来重新送回 Session：外部任务发生变化，交给 Monitor；Agent 想在未来主动复查，交给 Clock。

Monitor：任务变了，Agent 再判断

run_task 提交生成后就完成原 Tool Call，Task 自己继续运行：

Monitor 恢复长任务：Run A 提交任务后结束，Task 独立更新权威状态，Monitor 重新读取并整理变化，经 Inbox 唤醒 Run B

任务状态是事实，通知只是叫醒 Monitor；Monitor 重读并合并变化，再把新感知送回 Session，但不替模型做决定。

Clock：没有新事件，也可以在未来醒来

有时 Agent 等的不是“任务完成”，而是“十分钟后再检查一次”：

到点后，提醒进入 Inbox，新的 Run 再读取真实状态；等待期间没有进程在 sleep。Monitor 回答“外部世界变了什么”，Clock 回答“什么时候主动再看一眼”，最后都回到同一个外循环。

六、Agent 如何控制画布

AI 不直接拖动时间线，也不模拟鼠标。StarCut 把视频工程映射成一组可读、可修改的文件视图：时间线、脚本、MG 和 SVG 都有明确路径；Agent 读写这些文件，Editor 再把变化呈现在画布上。

Agent 通过文件视图控制画布：AI 读取并修改视频工程的文件视图，Editor 将变化写回同一个项目，时间线与画布随之更新

read、write、edit 只是文件视图上的通用动作，核心是让 AI 拥有一种稳定、可发现、可局部修改的视频工程界面。

人继续面对画布和时间线，Agent 面对文件视图；它们修改的是同一个项目。文件一变，画布更新；新的画布现场又成为 Agent 下一步判断的依据。

七、外部 Agent 如何进入同一块画布

StarCut 选择浏览器，是因为获客更直接、链接更容易传播，也能让 Codex、Claude Code 等外部 Agent 进入同一个编辑现场。代价是播放、预览和渲染仍然依赖一个真实在线的 Editor。

内置 Agent、MCP 和未来 CLI 通过统一 Project API 复用同一套画布能力，现场命令只交给一个在线 Editor

内置 Tool、当前的 MCP 和未来 CLI 都只是统一 Project API 的适配器：结构化编辑复用同一套语义操作；播放、预览和本地渲染交给一个在线 Editor，避免多个窗口重复行动。

八、最后，回到产品

如果把前面的架构压成一张图，就是下面这样：Harness 接住通用循环，StarCut 接住真实的创作现场。

StarCut Video Agent 完整架构：DeepSeek Harness 可承接通用 Session、Inbox 和 ToolLoop，StarCut 保留视频项目语义、媒体任务与在线 Editor，最终产出可继续编辑的视频项目

DeepSeek Harness 真正的挑战，不是能不能再跑一个 ToolLoop，而是能不能接入以后让系统变得更少：通用运行时由它承接，视频项目、媒体任务和编辑现场仍然只有一份事实。如果接完反而多出第二套状态，它就没有接住。

StarCut 是一个 Agent 可以直接创作、人也能随时接手精修的浏览器视频编辑器。你只需要说想做什么，Agent 会找素材、生成媒体、改时间线；中途关掉页面也没关系，回来还能从原来的项目继续。想看看这套 Loop 最后是不是能变成一条真正的视频，可以直接打开 StarCut 试试。