browser-use/video-use：LLM 不看视频，它读视频
> 原文链接：https://github.com/browser-use/video-use
一个数字对比，胜过千言万语
你想让 LLM 剪一段视频。最直觉的做法是什么？
把视频拆成帧，一帧一帧喂给 LLM。
一段 20 分钟的 1080p 视频，30fps，大约 36000 帧。每帧约 1500 tokens。总共 5400 万 tokens。GPT-5 的上下文窗口是 200 万，塞不下。就算塞得下，成本是 5400 万 tokens × $15/M = $810。剪一段视频花 800 美元，还没开始剪。
browser-use/video-use 的做法：12KB 文本 + 几张 PNG。同样的视频，同样的 LLM，成本从 $810 降到不到 $0.01。
这不是优化，是范式切换。
两层抽象：把视频变成 LLM 能读的文本
video-use 的核心设计是两层抽象：
Layer 1：Audio Transcript（始终加载）
调用 ElevenLabs Scribe 转录音频，得到词级时间戳 + 说话人分离 + 音频事件。所有 take 打包成一个 takes_packed.md，大约 12KB。这是 LLM 的"主阅读视图"。
格式长这样：
## C0103 (duration: 43.0s, 8 phrases)
[002.52-005.36] S0 Ninety percent of what a web agent does is completely wasted.
[006.08-006.74] S0 We fixed this.
LLM 读这个就能知道：谁在什么时候说了什么、有没有笑声/掌声/停顿。剪切的决策点全在这个文本里——"umm"和"uh"是废词要剪掉、false starts 要剪掉、停顿太长要剪掉。
Layer 2：Visual Composite（按需生成）
timeline_view 生成一个filmstrip + waveform + word labels 的 PNG，只在决策点调用——歧义停顿、retake 对比、cut point sanity check。
这一层不是每帧都生成，而是只在 LLM 需要视觉确认时才触发。一段 20 分钟的视频可能只需要 5-10 张 PNG。
关键洞察：和 browser-use 同构的设计哲学
video-use 的 README 里有句话："Same idea as browser-use giving an LLM a structured DOM instead of a screenshot — but for video."
这不是巧合。browser-use 团队做的是同一件事的两次应用：
- browser-use：不让 LLM 看截图，给它结构化 DOM。从"看像素"换成"读 HTML"。
- video-use：不让 LLM 看视频帧，给它词级转录。从"看帧"换成"读文本"。
这是"换层面解决问题"概念谱系的又一个成员。不是让 LLM 变得更擅长看视频，而是换一个层面——从视觉层面换到文本层面——让 LLM 用已有的强项解决问题。
Pipeline：转录→打包→推理→EDL→渲染→自评
Transcribe ──> Pack ──> LLM Reasons ──> EDL ──> Render ──> Self-Eval
│
└─ issue? fix + re-render (max 3)
每一步都值得注意：
1. Transcribe：ElevenLabs Scribe 一次调用，词级时间戳。
2. Pack：所有 take 打包成 12KB 的 takes_packed.md。
3. LLM Reasons：LLM 读转录，提出剪辑策略，等用户确认。
4. EDL（Edit Decision List）：LLM 输出结构化的剪辑决策列表，不是直接操作 ffmpeg。
5. Render：根据 EDL 调 ffmpeg 渲染。
6. Self-Eval：在每个 cut 边界调用 timeline_view 检查——视觉跳变、音频 pop、字幕隐藏。max 3 次修复。
Self-Eval 是最关键的设计。LLM 剪完不直接交付，先自己看一遍每个 cut 点。这和 AREX 的"验证作为控制信号"、ADR 的"两层检测"同构——验证不是事后过滤器，是流程的内置组件。
设计原则：12 条硬规则 + 艺术自由
video-use 的 SKILL.md 里有 12 条硬规则，包括：
- Text + on-demand visuals：文本是主表面，视觉按需。
- Audio is primary, visuals follow：剪切点来自语音边界和静默间隙。
- Ask → confirm → execute → self-eval → persist：不碰剪切未经策略批准。
- Zero assumptions about content type：不预设是 talking head 还是 montage。
- Production-correctness is non-negotiable. Taste isn't.：生产正确性必须，品味不必须。
为什么这个思路能跑通：LLM 的文本推理远强于视觉推理
这不是秘密：LLM 在文本上的推理能力远超视觉。GPT-5 在 MMLU 上 92%，但在视觉 benchmark 上经常翻车。原因很简单——LLM 的训练数据和架构都是文本优先的。
video-use 的设计利用了这个不对称：把视觉任务转成文本任务，让 LLM 用强项工作。转录文本里有时间戳、有说话人、有音频事件，LLM 能用文本推理做所有剪辑决策——哪里有废词、哪里停顿太长、哪两个 take 讲的是同一件事。
视觉只在"文本推理不够用"的时候才调用——比如两个 take 的内容几乎一样，需要看表情和节奏判断哪个更好。这是"分工比统一更有效"原则的又一次应用：文本处理大部分决策，视觉只处理文本处理不了的。
数据说话
- Token 消耗：12KB 文本 + 几张 PNG vs 5400 万 tokens（朴素方案）
- 成本对比：< $0.01 vs $810（朴素方案）
- 自评循环：每个 cut 边界自动检查，max 3 次修复
- 支持 Agent：Claude Code、Codex、Hermes、Openclaw 等任何有 shell access 的 Agent
- 依赖：ffmpeg（必需）、yt-dlp（可选）、ElevenLabs API（转录）
- 开源协议：100% open source
给 Agent 开发者的启示
1. 降维是 Agent 处理高维数据的核心策略：不是让 LLM 变强，而是换层面让 LLM 用强项工作。video-use 把视频降维成文本，browser-use 把网页降维成 DOM。 2. Self-Eval 是生产级 Agent 的必备：不自己检查输出的 Agent 不能上生产。video-use 在每个 cut 边界自评，这和 ADR 的两层检测、AREX 的验证信号同构。 3. EDL 比 ffmpeg 命令更好：LLM 输出结构化决策列表，由确定性代码执行。这和 Euclid-MCP 的"LLM 当诗人，Prolog 当会计"同构——强项留给模型，弱项外包。 4. 规则即对齐：12 条硬规则通过 Markdown skill 约束 LLM 行为，不需要重训。
---
一句话总结：browser-use/video-use 把视频降维成 12KB 文本 + 按需 PNG，让 LLM 用文本推理做剪辑决策。朴素方案 5400 万 tokens，它只要 12KB。这不是优化，是范式切换——从"看视频"换成"读视频"。
> 仓库：browser-use/video-use > Browser Use Cloud：try video-use in browser