HyperFrames v0.8.21:Agent 在 Studio 中获得“眼睛与双手“——WebMCP 驱动的可见、可编辑、可动效的协作式视频创作
2026/9/12 21:18:52 网站建设 项目流程

HyperFrames v0.8.21:Agent 在 Studio 中获得"眼睛与双手"——WebMCP 驱动的可见、可编辑、可动效的协作式视频创作

【免费下载链接】hyperframesWrite HTML. Render video. Built for agents.项目地址: https://gitcode.com/GitHub_Trending/hy/hyperframes

HyperFrames v0.8.21(发布于 2026-08-31)是 Studio Agent 能力的一次集中落地:浏览器内的 AI 代理现在可以看到当前帧、选择并检查元素、编辑文本与样式、变换布局,并通过 WebMCP 直接创作动画。与此同时,本版本修复了预览资产刷新、隐藏子合成层恢复与播放器静默故障等三个稳定性问题。读完本文,你将掌握 v0.8.21 新增的 12 个 WebMCP 工具及其调用链、写回执(write receipt)的语义,以及本轮四个修复项背后的实现原理,并能直接对照源码验证每一个行为。

一、发布概览:从"遥控器"到"协作者"

v0.8.21 之前,Agent 通过 WebMCP 操作 Studio 更多像是"盲操作"——可以发指令,却无法判断指令的效果。本次发布集中补齐了四个能力(对应四次核心合并):

能力提交 / PR说明
让 Agent 创作动画2d6b055f3 / #3520新增studio_add_animationstudio_update_animationstudio_add_keyframestudio_delete_animation
让 Agent 受控地编辑文本与样式f84b4c23d / #3518studio_set_textstudio_set_style走 Studio 同款提交管道并受守卫
给 Agent 一双眼睛3337cc899 / #3516新增studio_frame,按时间点渲染 PNG 帧
让 Agent 驱动选择与播放头0e558d591 / #3515studio_selectstudio_seek与人类操作等价

官方发布说明用一句话概括了这轮变化:"Studio agents can now see the current frame, select and inspect elements, edit content, transform layouts, and author motion through WebMCP."(见 releases/v0.8.21.md)。这份说明与 docs/guides/webmcp.mdx 中的"Let an agent drive Studio"指南相互印证——发布说明是能力的清单,指南则是完整的调用协议。

二、给 Agent 一双眼睛:studio_frame的实现与使用

studio_frame是本版本最重要的新增工具。正如源码注释所写(frameTools.ts):

studio_frame: the eyes. Without this the tool set is a remote control. With it an agent can author a change, look at the instant it affects, judge it, and adjust.

没有它,工具集只是一副遥控器;有了它,Agent 才能形成"改 → 看 → 判断 → 调整"的闭环——因为"2.4 秒时这个画面长什么样"是源文件无法回答的问题。

2.1 调用方式

studio_frame {"time":2.4} -> capture the composition at 2.4 seconds

输入参数(STUDIO_FRAME_INPUT_SCHEMA):

参数类型默认值说明
timenumber播放头当前位置捕获时刻(秒),省略则取当前播放头位置
settleMsnumber150捕获前等待的毫秒数,上限5000,确保刚写入的编辑已被渲染进帧内

返回值包含url(可拉取的 PNG 地址)、实际捕获的timecompositionPath以及等待耗时settledMs

2.2 两个关键实现细节

帧来自磁盘文件,而非实时预览 DOM。studio_frame复用 Studio 现有的捕获端点utils/frameCapture,服务端用 Puppeteer 渲染合成,因此"帧反映的是磁盘上的文件,不是预览 iframe 里的 DOM"(见 frameTools.ts)。

默认等待 150ms 是为了规避一个真实的历史 bug。源码中DEFAULT_SETTLE_MS = 150的注释解释了缘由:项目文件监听器有约 40ms 的写入稳定性阈值,预览签名由文件监听器失效;如果捕获请求抢在监听器之前发出,渲染出的将是编辑前的画面。Agent 若把这种过期帧误读为"我的编辑失败了",就会陷入无谓的重试循环。因此工具默认等待 150ms(覆盖监听阈值加文件系统延迟),并在工具描述中明确建议:若帧仍显陈旧,应提高settleMs而非断言编辑失败(见 frameTools.ts)。

三、12 个 WebMCP 工具全景

工具在 Studio 加载时自动注册一次(通过useStudioAgentTools,见 useStudioAgentTools.ts)。官方指南给出了一个典型的协作流程示例:

studio_look -> find the headline and copy its handle studio_select {"handle":"hf:abc123"} -> share the target with the person in Studio studio_inspect {"handle":"hf:abc123"} -> read its styles, text, and capabilities studio_set_style {"handle":"hf:abc123", "styles":{"color":"red"}} -> write that source-backed element studio_frame {"time":2.4} -> capture the composition at 2.4 seconds

12 个工具分为"读"与"改"两组:

读取类(只读)

工具回答的问题
studio_look当前项目与合成、播放头、选择、撤销状态,以及按嵌套顺序排列的有界 source-backed 场景
studio_inspect单个元素的完整信息:解析后的样式、文本字段、盒模型、动画及其可接受的能力
studio_frame任意时刻合成的 PNG

变更类(写入)

工具作用
studio_select选中元素,与鼠标点击完全等价
studio_seek移动播放头
studio_set_text重写文本
studio_set_style设置内联样式
studio_transform移动、缩放或旋转
studio_add_animation在播放头处添加 GSAP 动画
studio_update_animation修改时长、缓动或位置
studio_add_keyframe向动画添加关键帧
studio_delete_animation移除动画

3.1 Handle:source-safe 地址而非 CSS 选择器

studio_look返回的每个元素都带一个handle,同时报告sourceFileparentHandledepthchildCount,使 Agent 能在两个嵌套的场景文件中区分相同作者 ID 的元素。写入时必须原样回传 handle。从源码看(writeCoordinator.ts),写入端会验证 handle 必须是当前项目的 v2 版本化 handle,否则返回refused——这防止了跨项目或过期 handle 的误写。

3.2 写回执(Write Receipt):区分"接受"与"证明"

所有元素写入都走 Studio 自身使用的同一批 commit actor。v0.8.21 的官方文档明确规定了回执的五个阶段:

阶段证明了什么
refused没有 commit actor 运行。修复 handle、输入、能力或 Studio 状态后重试
dispatchedactor 接受了请求,但工具没有持久化版本或独立读回。需用studio_inspectstudio_frame跟进
savedStudio 收到了版本化证据,证明命名的源文件已持久化写入
verified写入已保存,且独立读回观察到了结果
failedcommit actor 运行后失败。检查kindreasonhint

源码中这三个证明级别对应三种 evidence 结构(writeCoordinator.ts):dispatch(仅派发)、content-version(源文件 + 版本号)、readback(源文件 + 版本号 + before/after)。changed与阶段无关——一个被保存的 no-op 也是真实的:文件接受了请求,但值本来就已存在。样式写入按属性出具回执,因此可以是部分成功的。

四、让 Agent 创作动画:动画工具的实现细节

v0.8.21 首次让 Agent 能够创作动画(此前只能读和改静态内容)。实现集中在 animationTools.ts,有几个值得注意的约束:

  • studio_add_animation在播放头处插入,工具本身不控制时间——Agent 需先调用studio_seek选择起始点,结果会报告播放头实际所在位置(insertedAtSeconds)。
  • GSAP 方法白名单method只能是tofromsetfromTo四种(见 animationTools.ts),其余值直接refused
  • 拒绝原始 JS 表达式:值为__raw:前缀的字符串会被拒绝(raw JavaScript expressions are not accepted),这是对注入式内容的安全防线(见 animationTools.ts)。
  • 动画 ID 归属校验studio_update_animationstudio_add_keyframestudio_delete_animation在预检阶段会校验animationId必须属于目标 handle 的动画列表(animationBelongsToTarget),防止跨元素误操作。
  • 关键帧一次性提交studio_add_keyframe的所有属性落在同一次 commit 里,因此是一条撤销记录
  • 结算语义:添加/更新/删除动画的成功响应意味着"持久化与实时预览同步均已结束",但动画处理器目前上报dispatched——它们不声称具备版本化持久性或独立读回(关键帧 actor 不回传落地信号),源码注释明确建议事后用studio_inspect确认精确的已写入值(见 animationTools.ts)。

五、两条协作规则与关闭方式

5.1 先表达意图,再显式寻址每次写入

在第一次写入某目标前,应先调用studio_select,让人在 Studio 中看到与 Agent 相同的选中框和检查器。选择表达意图,但不授予写权限——studio_set_textstudio_set_stylestudio_transform及动画工具仍要求来自studio_look的目标 handle,因此人类随后的点击无法重定向一条已寻址的写入。

5.2 协作可见性

这是为人与 Agent 共同查看同一合成而设计的:Studio 正常显示选中状态,并在事务解析期间在被寻址元素周围叠加一个Topology Lens(仅 Studio 内的交易反馈,不会进入导出的 HTML、预览 iframe、捕获帧或缩略图)。写入成功后,打开的预览已同步该编辑,观看者无需拖动时间线或刷新浏览器。接受源文件变更后,Studio 会推进项目缩略图版本并重新生成可见的合成缩略图,让侧边栏收敛到已保存的项目而非缓存的旧像素。

注意:当自动保存暂停、或文件外部变更正等待你的裁决时,Studio 会拒绝 Agent 写入并告知原因——解决横幅后可继续。

5.3 关闭

目前没有设置开关,需通过控制台修改 Studio 偏好并重载:

const KEY = "hf-studio-ui-preferences"; const prefs = JSON.parse(localStorage.getItem(KEY) ?? "{}"); localStorage.setItem(KEY, JSON.stringify({ ...prefs, agentToolsEnabled: false })); location.reload();

务必先读取再展开(spread)原对象——直接写入{agentToolsEnabled: false}会覆盖整个偏好对象,丢失面板尺寸、缩放和时间线设置。浏览器仍会在自己的权限提示中把关工具访问,注册工具 ≠ 授予访问权。

六、三项稳定性修复的源码依据

6.1 Studio Server:每次请求都重新验证预览资产(#3565)

此前的预览缓存可能因文件监听器失效与请求时序问题而返回过期内容。本次修复让预览资产在每个请求上重新验证。从 preview.ts 可以看到相关机制:预览路由用 ETag 加盐——当?variables=参数变化时,variablesEtagSalt对原始参数字符串做 SHA-1 摘要(取前 12 位十六进制)拼入 ETag,使缓存随变量值变化而失效;文件内容变更导致的签名失效则由injectProjectSignature注入项目签名处理。这与studio_frame的 150ms 等待机制互为表里:一个是服务端保证预览/捕获端到端的新鲜度,一个是客户端避免竞态。

6.2 Studio:隐藏的子合成子层可以重新显示(#3559)

修复了"子合成(sub-composition)中某个隐藏层一旦隐藏便无法通过 Studio 再次显示"的问题。该问题源于隐藏状态在子合成场景中的传播/恢复路径缺失,本次修复补齐了子层显隐状态的回写能力,使 Agent 或用户在嵌套场景中调整hidden后能可靠地恢复。

6.3 Player:重新绑定时间线并约束暂停态 seek(#3489)

Player/runtime 层面修复了时间线绑定丢失的问题:当运行时重新绑定时间线时,暂停状态下的 seek 现在会被正确约束(bound),避免播放头在暂停状态下越界或行为不一致。这是 Player 内部状态机的一次健壮性修正。

6.4 Player:运行时投递错误改为上报并 fail-closed(#3472)

Player 对运行时投递错误(runtime delivery errors)从"静默停滞"改为"显式上报并失败关闭"。此前若渲染/投递管线出错,播放器可能无声地停在原地,用户无法判断是卡顿还是故障;现在错误会浮出表面,方便用户与 Agent 依据错误信息定位问题——这与 WebMCP 写入回执的failed阶段"检查 kind、reason、hint"的哲学一脉相承:不让错误静默

七、Catalog:手写体家族的"书写波浪"

本版本还向 Registry 新增了hw-write-titleblock 及其控制面板——"Hw write-on wave"(#3557)。这是手写体(handwritten)家族的新成员,可在 registry/blocks/hw-write-title 目录中查看其 HTML 实现、注册 JSON 与配套字体资源。它展示了手写标题的"逐笔书写"动画效果,与 v0.8.21 的 Agent 动效创作能力形成了很好的配合场景:Agent 可以给标题元素添加书写动画,再用studio_frame逐帧验证笔迹进度。

八、如何验证这些能力

  • 阅读官方协议:docs/guides/webmcp.mdx 完整描述了 12 个工具的调用契约、浏览器支持矩阵(Chrome 149 / Edge 150 Origin Trial、ChatGPT Desktop 已内置、Brave Leo 实验性、Firefox/Safari 未支持)以及document.modelContext(而非navigator.modelContext)的正确用法。
  • 本地验证:Chrome 下启用chrome://flags/#enable-webmcp-testing并重启,然后在 Studio 控制台执行await document.modelContext.getTools()确认工具列表(注意注册是异步的,应等待toolchange事件或轮询直至数量稳定在 12 个)。
  • 阅读源码:工具实现集中在 packages/studio/src/webmcp,其中 registrar.ts 是唯一直接接触 WebMCP API 的文件,writeCoordinator.ts 定义了写回执与 evidence 结构,对应的单元测试(如 frameTools.test.ts、writeCoordinator.test.ts 同级测试)与端到端测试 webmcp-edit-loop.mjs 可帮助你复现完整流程。

总结

v0.8.21 标志着 HyperFrames Studio 的 Agent 协作从"单点指令"进化为"完整创作闭环":studio_frame提供了判断依据,动画工具组补上了"创作"这一环,写回执机制让每个写入都有明确的证明级别,而四项修复则保证了预览新鲜度、嵌套场景可恢复性与错误可见性。对开发者而言,这份发布说明 + WebMCP 指南 + webmcp 源码目录三者对照阅读,即可完整复现并扩展这套 Agent 驱动 Studio 的能力。

【免费下载链接】hyperframesWrite HTML. Render video. Built for agents.项目地址: https://gitcode.com/GitHub_Trending/hy/hyperframes

创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询