agent-browser 浏览器录屏：FPS 怎么选，证据才有用

浏览器录屏该用多少帧率？先看评审要判断什么

先从 30 fps 开始。这是新的默认值，足以清楚呈现普通点击、悬停状态、滚动、CSS 过渡和操作演示，同时不会承担 60 fps 带来的额外负载。

--fps 的有效范围是 1 到 60。帧率更高，并不代表证据一定更有力。如果页面实际重绘频率低于请求值，设置 60 fps 也无法凭空生成 60 个真正不同的页面状态。

v0.37.0 有哪些变化

录制器现在会把视频当作当前实际操作页面的计时视图。record start 和 record restart 默认以 30 fps 捕获当前活动页面，支持 --fps 1-60，并使用 Chrome 的 Page.startScreencast。这是 Chrome 自己输出的页面重绘帧，就像把摄像机直接接入浏览器的显示管线，而不是间歇性截取屏幕截图。

v0.37.0 版本说明也收紧了失败处理。缺少 ffmpeg、输出路径没有扩展名，或录制选项无效时，命令会在浏览器或录制状态发生变化前失败。如果替代录制无法启动，当前录制会被保留。录制期间发生导航时，过期的元素引用和 frame 状态也会像普通导航一样被清除。

这对真实 QA 循环很重要。错误的视频路径不该悄悄改变被测页面，开始第二段录制也不该在确认替代录制可用之前毁掉第一段。

浏览器自动化录像的五步流程

可靠的顺序是检查、打开、录制、断言、停止。最后一条命令也是证据契约的一部分，因为它负责刷新缓冲并保存文件。

agent-browser doctor
agent-browser open https://app.example.com/login
agent-browser record start ./login-flow.mp4 --fps 30
agent-browser snapshot -i
agent-browser click @e1
agent-browser wait --url "**/dashboard"
agent-browser record stop

1. 先检查编码器。 agent-browser doctor 会报告 ffmpeg 及其录制编码器。MP4 需要 libx264，WebM 需要 libvpx。标准的 Homebrew 或 Debian/Ubuntu ffmpeg 构建通常两者都包含。

2. 确保活动标签页打开了正确页面。 record start 不带 URL 时，录制器会原样连接当前活动页面，不会重新加载、打开新标签页，也不会创建干净的浏览器上下文。如果问题依赖已经完成水合的应用、登录会话或页面内状态，这一点很实用。如果提供 URL，活动标签页会先导航，待页面加载后再开始录制。

3. 通过扩展名选择封装格式。 .mp4 会通过 libx264 选择 H.264；.webm 会通过 libvpx 选择 VP8。其他扩展名会以 H.264 交给 ffmpeg，只有 ffmpeg 识别该封装格式时才能工作。没有扩展名的文件名会被拒绝。

4. 把通过/失败检查留在自动化流程里。 示例中的 wait --url 用于检查浏览器是否到达 dashboard。视频能帮助人理解发生了什么，但不会把画面自动变成测试断言。

5. 关闭前先停止录制。 record stop 会保存录制并刷新缓冲。如果先关闭会话，原本要保留的文件可能根本没有生成。需要结束当前片段并立即在活动页面开始下一段时，使用 record restart。

capturedFrames 和 frames 回答的是两个问题

可以把这两个计数器分别理解为素材和成片。capturedFrames 统计页面实际产生的不同帧，frames 统计写入视频文件的帧。即使页面静止、不同画面很少，ffmpeg 也可以写入重复帧，让录制结果能够正常观看。

这里有一个重要的计时限制。页面不再变化时，最后一帧会被保留。单次静止间隔最多保留五秒，之后未变化的剩余时段会被省略。实际效果是：视频会保留短暂停顿，但会压缩长时间空闲。不要把回放时长当成长时间稳定性测试的秒表。

因此，capturedFrames 数量低不一定代表录制失败，也可能只是页面没有变化。这也是只应在动态确实值得检查时使用 60 fps 的原因：录制指南指出，60 fps 的码率大约是 30 fps 的两倍，但不同帧的数量仍取决于页面重绘。

成本账里改变的那一项

如果团队已经在运行 agent-browser，获取基础视频证据就不必再从购买另一个录屏工具席位开始。v0.37.0 软件包声明采用 Apache-2.0 许可证，因此录制器本身没有按用户收取的软件许可费。新增成本来自实际运营环节：配置 ffmpeg、占用 CI 时间、存储产物，以及人工评审所花的时间。

这与购买完整的反馈或测试平台有实质区别。Jam Team按年付费时，每位创建者每月 $14。BugHerd Standard按月付费时，五位成员每月 $50，并包含视频反馈。BrowserStack Automate按年付费时，一个 Chrome Desktop 并行实例每月 $59，其调试工具中包含视频录制。

这些产品提供的不只是录屏，因此直接得出“可以替代它们”的结论并不准确。BrowserStack 提供托管式浏览器覆盖；BugHerd 和 Jam 提供协作、问题捕获与集成。真正有用的成本判断应更聚焦：当 agent-browser 已经在运行流程，唯一缺少的产物只是一段清楚可读的视频时，就不必再购买第二层捕获工具。

七类用法：按受益最大的团队排序

1. 排查 CI 流程失败的产品团队

如果登录或结账测试偶发失败，产品团队可以在高风险路径之前立即以 30 fps 开始录制，同时保留原有 URL 或元素断言；运行失败时，再把 MP4 作为 CI 产物保存。工程师可以看到文本日志可能遗漏的同意横幅、延迟出现的浮层、焦点跳转或过渡效果。直接收益是减少为复现间歇性状态而消耗的付费工程时间。

2. 评审拖拽、滚动和动画表现的前端团队

前端工程师可以隔离一段简短交互，以 60 fps 捕获，再配上起始与结束状态的截图。视频用来判断两个状态之间的动态是否流畅，截图则保留精确像素。当缺陷恰好出现在两张截图之间，例如掉帧或拖拽目标在错误时机被越过，这种组合最有价值。

3. 审计浏览器代理行为的 AI 产品团队

AI 产品团队可以在代理执行任务时，以 30 fps 录制当前已经登录的活动页面，再把视频与代理的命令轨迹和断言放在一起。评审者由此可以分辨：究竟是代理规划错误，还是页面在代理操作期间发生了变化。原本不透明的一次运行，就变成产品经理和工程师能够共同讨论的证据。

4. 复现状态依赖型缺陷的 QA 工程师

QA 工程师可以先把会话准备到满足缺陷前置条件，再运行不带 URL 的 record start。由于录制会原地连接页面，当前页面不会被一次冷启动导航取代。如果缺陷依赖累积的购物车状态、某个模态框、已登录路由，或其他一刷新就消失的条件，这种方式尤其有效。

5. 向客户交付版本的服务机构

Web 服务机构可以用 30 fps 录制一条验收路径，在关键决策点加入短暂停顿，再把节奏适合真人观看的视频交给客户。客户无需获得测试运行器的访问权限，就能评审确切路径。既然产物已经把流程展示清楚，服务机构就可以减少会议中逐步讲解的时间。

6. 保存长时间运行时间线的可靠性团队

当事件顺序比动态质量更重要时，可靠性工程师可以用 10 fps 录制长时间稳定性运行。与 30 或 60 fps 相比，较低帧率能减少录制开销和文件增长。视频仍可用于定位可见故障出现的时刻，但由于静止间隔会被压缩，时间戳必须以日志为准，不能取自回放时长。

7. 上报复杂浏览器问题的支持工程师

支持工程师可以在受控账户中复现客户路径，以 30 fps 录制，停止后把视频附在升级工单中。开发团队由此获得书面工单经常丢失的时序细节和意外浮层。前提是流程还必须阻止密钥和客户数据进入录制内容。

三个值得做成产品的方向

最佳机会：代理运行证据包

可以构建一个小型服务，把一次浏览器代理运行整理为一个统一评审包：断言结果、命令轨迹、最终截图、MP4、帧计数器，以及发布到 Jira 或 Linear 的链接。产品和工程团队愿意付费，是因为输出能直接进入他们已经在用的问题处理流程。

需求有明确数据支撑。美国关键词数据显示，“bug reporting tool”每月约有 590 次搜索，CPC 为 $43.80。现有支出也清晰可见：Jam Team 按年付费时，每位创建者每月 $14；BugHerd Standard 按月付费时，每月 $50。最小可售版本需要一个 agent-browser 封装器、产物存储、一项问题跟踪器集成，以及一份脱敏检查清单。

这是最值得优先考虑的机会，因为它卖的是交接成果，而不是编解码器。但其技术壁垒较浅：发布到 Jira 和存储视频都很容易被复制，因此产品必须特别擅长组装可信上下文，并防止敏感数据进入其中。

面向服务机构的 QA 交付门户

可以构建一个面向客户的评审页面：服务机构选择流程，让它在 staging 环境运行，再把断言、截图和节奏适当的视频放进同一个审批链接。买家是服务机构和按需 QA 团队，因为到了客户签字确认环节，技术证据往往仍要靠会议解释。

美国关键词数据显示，“website qa testing”每月有 110 次搜索，同比增长 55%，CPC 为 $23.91。MVP 可以支持若干可复用流程、30 fps 捕获、评论以及批准或拒绝。难点在于现有产品已经做得很深：BugHerd 的 Standard 套餐已经包含不限数量的项目、客户用户、截图、元数据和视频反馈。新产品必须靠代理生成的证据胜出，而不能只是再做一个评论图钉。

动态测试预设层

可以构建一个轻量 CI 工具，把测试标记为 timeline、default 或 motion，分别映射到 10、30 或 60 fps，并在捕获帧与写入帧之间出现异常差距时发出提示。前端平台团队会为跨动画和交互回归测试的一致证据付费。

美国关键词数据显示，“automated browser testing”每月有 110 次搜索，CPC 为 $14.96。更窄的商业关键词“automated browser testing tools”每月只有 20 次搜索，但 CPC 达 $63.21，说明这批规模不大的买家触达成本很高。MVP 包括测试清单、agent-browser 命令封装器、仅在失败时保留的视频，以及紧凑的产物索引。

难点在于增长势头较弱：较宽泛的关键词同比下降 18%，而 60 fps 会增加开销，且仍受页面重绘频率限制。它更适合作为证据产品中的一项功能起步，而不是独立公司。

浏览器录屏不能证明什么

视频提供的是可观测性，而不是正确性。它无法告诉你是否写入了正确的数据库记录、API 响应是否有效，也无法证明所有浏览器和设备上的表现都一致。断言、日志和截图仍应与视频一起保留。

它也无法消除环境风险。录制要求 PATH 中存在 ffmpeg，并配有匹配的编码器。更高帧率会增加开销，长时间录制会占用磁盘，资源受限的无头运行环境还可能存在编解码器或 GPU 限制。页面重绘速度慢时，每秒无法提供 60 个不同帧。

应把隐私当作产品要求来处理。录制器会捕获当前视口和页面内状态，这正是它有用的原因，也正因如此，测试账户、密钥遮盖、产物保留和访问控制都需要明确规则。这属于运营判断，并不是工具内置的脱敏承诺。

最后，agent-browser 负责记录证据，但不会解读证据。如果希望模型在运行结束后检查视频，那是另一个独立系统，更接近代理式视频理解。这一层应与确定性的通过/失败检查分开。

下周一就这样做

下周挑一条容易失败的登录、结账或发布路径。运行 doctor，以 30 fps 录制当前活动页面，保留现有断言，调用 record stop，再把 MP4 附到测试结果中。只有评审者无法判断动态缺陷时才升到 60 fps；长时间运行主要关注事件顺序时，则降到 10 fps。试点成功的标准，是评审者无需重跑就能诊断失败，而不是视频看起来是否足够流畅。

如果希望浏览器代理为团队生成可直接评审的证据，我可以围绕真实 QA 工作流为你构建。