Browserbase

Browserbase 把真实 Chromium Session 托管在云端，返回可供 Playwright、Puppeteer、Selenium 或 Stagehand 连接的地址，并默认录制过程。它真正解决的是：自动化必须登录、需要排障回放，或要在多次运行间保留 Cookie 与本地状态。若目标只是公开静态页正文，先用更轻的抓取 API 通常更合适。

先定一条需要登录态的验收任务

例如：打开目标站登录页，填入测试账号，进入账户设置或订单列表，读取一个可见字段（如显示名、订单号）并截图。把该字段与截图当作完成物；不要用“脚本跑完”代替验收。准备 API Key；创建 Session 时可省略 projectId（可从 Key 推断），也可显式传入 Settings 中的项目 ID。

第一次 Session：写入 Context

先调用 Contexts API 取得 contextId。再创建 Session，并设置：

• browserSettings.context.id = 该 Context
• browserSettings.context.persist = true（否则登录态不会写回）
• browserSettings.recordSession 保持默认 true，便于回放
• timeout 按任务长度设置（官方允许约 60–21600 秒）

用 chromium.connectOverCDP(session.connectUrl) 连接后，务必使用默认 context 与默认 page，以便录制和平台校验功能正常。创建后应尽快连接：官方说明新建 Session 约 5 分钟未连接会被终止。在默认页完成登录与字段读取，关闭浏览器连接并结束 Session；官方建议在 persist: true 的 Session 结束后等待数秒，再复用同一 Context。

第二次 Session：证明免登复用

用同一 contextId 再开 Session（仍可按需 persist: true），直接访问上次需登录才能打开的页面。若仍跳到登录页，先区分是 Context 未同步，还是网站主动使 Cookie 失效（改密、全端退出、服务端吊销等）。Context 本身在 Browserbase 侧可长期保留，但站点会话仍可能过期。

用回放判断“哪一步坏了”

官方示例把回放入口写成 https://browserbase.com/sessions/{session.id}。对照时间线检查：是否到达登录后页面、验证码是否自动处理（默认 solveCaptchas 多为开启）、目标字段出现前是否被弹窗挡住。需要跨断开续跑时再开 keepAlive（付费能力）；它不取消 timeout，两者常需同时配置。Live View 适合人工观察，最终仍以自动化结果与回放一致为准。

1. 记录 contextId、两次 session.id、目标 URL 与验收字段。
2. 第一次 Session 完成登录并读到字段，结束后等待 Context 同步。
3. 第二次 Session 免登打开同一受保护页并再次读到字段。
4. 打开回放确认关键步骤顺序与页面状态。
5. 释放 keepAlive（若启用），归档截图与字段值。

公开文档入口：https://www.browserbase.com/ 与 https://docs.browserbase.com/