开源 Clips：一条链接让 Agent 读懂你的 bug

跟 AI Agent 协作时最烦的事之一，是给它交代 bug：手打一段文字描述问题、截图、粘贴控制台日志、复制失败的网络请求，弄完半天，Agent 还可能理解偏了。

Builder.io 创始人最近开源的 Chrome 扩展 Clips，把这套流程压缩成一次录制：点一下开始，边操作边说话，Clips 自动捕获屏幕视频、语音转录、网络请求、控制台日志和客户端错误，并自动脱敏，最后生成一条链接。把链接丢给 Agent，它就能直接读取视频和调试信息，理解你录下的 bug。

拉一下它的仓库 BuilderIO/agent-native 会发现，Clips 只是冰山露出水面的一角：它背后是一整套开源的 agent-native 框架，外加一组可以直接 fork 的完整应用模板。项目作者称这是「软件的未来」，这话有几分道理，本文结合仓库源码拆开来看。

传统报 bug 流程有多疼

给 AI Agent 报一个 bug，常见的动作是这样的：先截几张图，再手打文字描述「我点了什么、发生了什么」，然后打开 DevTools 复制 console 报错，切到 Network 面板复制失败的请求，最后把这些零碎信息拼进 prompt。这套动作重复几次就够呛，而 Agent 拿到的信息仍然不完整，只能靠猜。

Clips 把它变成一条流水线：

1. 点 Chrome 工具栏的 Clips 图标，开始录制；
2. 边操作边说话，比如「我点这个按钮，它应该跳转，但页面卡住了」；
3. Clips 在后台自动捕获屏幕视频、语音转录、网络请求、控制台日志、客户端错误，并对 token、密码等敏感信息自动脱敏；
4. 录完生成一条链接，直接丢给 Agent。

关键在最后一步的「直接丢给」。项目作者的原话是：

The link has special metadata for agents so just from the URL, the agent can pull all information from the clip automatically. No plugin or MCP server required.

链接里带特殊元数据，Agent 光从 URL 就能拉取 clip 的全部信息，不需要装插件，也不需要起一个 MCP 服务器。拿到链接后，Agent 可以读转录全文、在任意时间点抓视频帧快照、检查共享出来的日志和网络请求，等于有了眼睛和耳朵。

把可读性做进链接本身

让 Agent 理解富媒体，常见的思路是给它装一个 MCP server 或专用插件，让它具备解析视频和日志的能力。这个思路的问题在于，每换一个 Agent 就要重新配一遍，跨工具不通用。

Clips 换了个方向：把「可读性」做进链接本身。链接页面带结构化元数据，任何能联网的 Agent，不管是 Claude Code、Codex 还是 Cursor，只要能 fetch 这个 URL，就能拿到全部信息。打个比方，MCP 思路是给 Agent 装翻译器，Clips 的思路是把信息直接写成 Agent 的母语，后者天然跨平台。

这也符合一个更普遍的规律：与其让模型直接啃原始视频，几十 MB 的帧序列意味着海量无效 token，不如先把视频翻译成模型能高效消费的结构化文本。Clips 做的正是这件事，只不过翻译对象从影视素材换成了录屏加调试信息。

冰山之下：agent-native 框架

仓库 README 对自己的定义很精炼：

Agent-Native is an open-source framework for building robust agents that act inside real apps, not just chat next to them.

一个开源框架，用来构建在真实应用里行动的 agent，而不是只在应用旁边挂个聊天框。这句话点破了当下很多「AI 应用」的问题：聊天框和工具本身是两个割裂的世界。agent-native 想要的是，Agent 和 UI 成为同一个系统里的平等公民，每个操作既能点击触发，也能对话触发。

框架的核心原语只有一个函数，defineAction：

// One action powers UI, agent, HTTP, MCP, A2A, and CLI.
export default defineAction({
  schema: z.object({
    emailId: z.string(),
    body: z.string(),
  }),
  run: async ({ emailId, body }) => {
    await db.insert(replies).values({ emailId, body });
  },
});

定义一次 action，比如「回复邮件」，就能从六个地方调用：

写一次，六端复用。你不用为 UI 写一套逻辑、为 Agent 再写一套、为 API 又写一套，这是这套框架最实在的工程价值。

仓库的 templates/ 目录里放着 14 个完整的应用模板，每个都是可 clone、可 fork、可定制的成品应用，而不是脚手架：对标 Loom 加 Jam 的 Clips、给编码 Agent 用的可视化计划 Plans、生成交互原型的 Design、MDX 编辑器 Content、React 幻灯片 Slides、对话式数据分析 Analytics，以及 Mail、Calendar、Forms、Chat、Videos、Dispatch、Brain、Macros 等。项目作者对此的解释是：

Rather than bloated SaaS that charges you a ton of money and still doesn't even have the things you need, we get free open source canonical apps that you can fork and customize in any way you want.

与其付订阅费用臃肿的 SaaS，不如用免费开源的标准应用，想怎么改就怎么改。

它到底比 SaaS 和裸 Agent 好在哪

README 里那张对比表值得细看：

注意「定制」那一行：Agent modifies the app，Agent 能修改应用本身。这是最激进的一条，应用不再是固定交付物，而是可以被 Agent 持续加功能、修 bug、改界面的活物。

Agent 和 UI 是平等公民

这套架构有五个特征，每一个都值得琢磨：

1. 一切同步：一个数据库、一份状态，Agent 改了什么 UI 立刻反映，反过来也一样；
2. 实时多人协作：人和 Agent 编辑同一个文档，Agent 是一等公民的协作者，不是旁观者；
3. 上下文感知：Agent 知道你在看什么，选中文字按 Cmd+I 就能下达指令；
4. Agent 调 Agent：在任何应用里可以召唤另一个 Agent，它们通过 A2A 协议协作；
5. 自我改进：Agent 能给应用加功能、修 bug、优化 UI。

怎么用

直接用 Clips。 去 Chrome Web Store 装扩展（或从仓库自行构建），流程就是录制、操作、拿链接、丢给 Agent。

用框架建自己的应用。 一条命令起项目：

npx @agent-native/core@latest create my-app
cd my-app
pnpm install
pnpm dev

create 会让你选三种起点：完整模板，clone 一个或多个成品应用，比如 Mail、Calendar、Forms 组合起来自动共享认证；Chat，最小聊天 UI 加浏览器壳，最简单的起点；Headless，纯 action 没有 UI，先跑通 Agent 再补界面。

只给现有编码 Agent 加可视化规划。 不想建整个应用，可以只装两个斜杠命令，支持 Claude Code、Codex、Cursor 等：

npx @agent-native/core@latest skills add visual-plan

装完得到 /visual-plan 和 /visual-recap：前者让 Agent 在写代码前先产出带图表、线框图、文件级实现图和批注的可视化计划，你审过它再动手；后者在改动落地后把 PR 或 git diff 变成可视化回顾，不用再盯着生肉 diff 看。

Clips 本身是怎么实现的

从仓库看，Clips 是个三端应用：Chrome 扩展负责录制入口，捕获屏幕、日志和网络请求；桌面端用 Tauri 构建，走系统 webview，不打包 Chromium，体积和内存都比 Electron 路线省得多；Web 端用 React Router 做播放和分享，部署在 Cloudflare Pages 上，serverless。

轻量原生路线这两年明显在反攻 Electron，Tauri 用系统自带 webview 换来小体积低内存，对一个常驻工具栏的录屏扩展加桌面端组合来说，是很合理的技术选择。

为什么这事重要

第一，从「给应用加 AI」到「为 AI 重新设计应用」。大多数 AI 应用是在传统应用旁边塞个聊天框，agent-native 反过来，先设计 Agent 能理解的 action，再围绕它建 UI，这是范式级别的差别。

第二，defineAction 解决的是真实的重复劳动。同一个业务逻辑要为 UI、Agent、API、MCP、CLI 各写一遍，本来就是多端开发的顽疾，一次定义六端复用直接把这笔账砍掉。

第三，开源标准应用对抗臃肿 SaaS。你为录屏、表单、数据分析各自付一份订阅费，它们还都不让你定制，agent-native 给出的是可 fork 的开源等价物，代码就在仓库里。

第四，Agent 能修改应用本身。应用从一次性交付的固定产品，变成 Agent 持续优化的活物，用着用着它自己长出你需要的功能。如果这个模式跑通，软件的交付方式会被改写。

小结

一句话：Clips 是入口，agent-native 是框架。前者让你告别手打 bug 报告，后者试图回答「AI 应用到底该怎么建」：不是给应用加 AI，而是为 AI 重新设计应用，让 UI 和 Agent 成为平等公民。

如果你厌倦了给 SaaS 交订阅费、厌倦了给 Agent 手打 bug 报告，或者想看看下一代 AI 应用架构的样子，这个 MIT 协议的开源仓库值得花一个下午。

本文基于 BuilderIO/agent-native 仓库（https://github.com/BuilderIO/agent-native ，MIT 协议）与其官网 agent-native.com 整理，Clips 是仓库中的一个应用模板；文中英文引文来自项目作者的公开发言。