Browserbase

Browserbase 是一个专为 AI 代理构建的云端无头浏览器基础设施平台。该公司由前 Twilio 工程师兼 StreamClub CTO Paul Klein IV 于 2023 年创立，在云端运行沙盒化的 Chromium 实例，由 LLM 驱动的代理可通过标准的 Playwright、Puppeteer 或 Selenium 连接进行访问。它解决的核心问题被 Paul Klein 称为“API 无法触及的 85%”：那些没有机器可读 API 端点、纯粹为人类浏览器设计的网页、门户和经过身份验证的应用程序。Browserbase 使代理能够在生产规模上访问这些内容。

该平台分为三层。基础设施层提供按浏览器小时计费的云端浏览器会话，内置验证码（CAPTCHA）破解、隐身指纹识别、代理管理以及带视频回放的会话重放功能。Stagehand 是开源 SDK 层（MIT 许可证，支持 TypeScript 和 Python，拥有 22,400+ GitHub stars），它用四个 AI 原语封装了浏览器控制：用于执行自然语言操作的 act()、用于提取结构化数据的 extract()、用于预览操作效果的 observe()，以及用于自主多步任务委派的 agent()。Director 是 2025 年 6 月推出的自然语言 UI 层，允许非技术用户用通俗易懂的英语描述自动化流程，无需编写代码即可生成可运行的脚本。截至 2026 年 3 月，Browserbase 每月为 10,000 多家公司处理约 3,700 万个独立浏览器会话，Stagehand 每周的 SDK 下载量达到 80 万次。

Browserbase 在 2026 年 4 月的实际功能

Browserbase 的基础设施为代理提供了一个完整的 Chromium 浏览器实例，可通过 WebSocket 使用 Chrome DevTools Protocol 进行访问。只需更改一个端点，即可连接现有的 Playwright 或 Puppeteer 代码；会话将在 Browserbase 的云端而非您的服务器上运行。从那里，代理可以导航、点击、填写表单、处理重度依赖 JavaScript 的页面、自动解决验证码，并在请求之间保持 cookie。会话包含内置的实时视图（实时观看浏览器）、会话后视频重放、DOM 快照以及用于调试失败运行的提示词日志。

2025 年 10 月 29 日推出的 Stagehand v3 是一个重要的架构里程碑。早期版本的 Stagehand 构建在 Playwright 之上；v3 转向了原生 CDP，使其兼容 Puppeteer、Bun 和其他基于 CDP 的驱动程序。该框架现在的平均运行速度比 v2 快 44%，在嵌套 iframe 和 shadow DOM 交互方面提升尤为明显，而这些正是早期代理脚本在现代 Web 应用中的主要故障模式。Stagehand v3 还添加了自动元素缓存：一旦 act() 或 extract() 运行发现了页面元素，后续运行将重用这些元素，无需额外的 LLM 推理，从而降低了重复工作流的延迟和 API 成本。

该平台的监控可观测层值得单独提及，因为它是真正的差异化优势。会话重放包括完整视频、任意帧的 DOM 检查，以及触发了哪些 LLM 提示词及其返回结果的日志。当代理在 12 步工作流的第 7 步失败时，您可以拖动进度条到那一刻，准确查看浏览器当时的渲染内容以及模型的推理结果。竞争对手要么完全缺乏会话后重放功能，要么将其限制在企业计划中。

“它让我们为 AI 代理运行真实的浏览器会话变得异常简单。如果没有它，整个系统的构建和扩展难度将增加 10 倍。”—— Elijah Muraoka，Soshi 创始人，Product Hunt，2025 年 6 月

“该 API 易于集成，并提供了对众多业务用例至关重要的功能集。”—— Zach Tratar，Embra 创始人，Product Hunt，2025 年 5 月

Browserbase 与 Apify 和 Anchor Browser 的定位对比

无头浏览器和代理自动化领域至少有三种截然不同的架构，而 Browserbase、Apify 和 Anchor Browser 各自代表了其中一种。

Browserbase vs. Apify： Apify 是一个围绕“Actors”构建的自动化市场，Actors 是您编写一次并部署到其云端的无服务器 Node.js 或 Python 函数。关键的结构差异在于，Apify 的模式是执行库中预先编码的任务（针对 LinkedIn、Amazon 和 Google Maps 等特定网站的 4,000 多个现成 Actors），而 Browserbase 提供的是原始的、未编码的浏览器会话，您的代理逻辑在其之上运行。如果您需要抓取一个已经有 Apify Actor 的网站，使用 Apify 上手会更快。如果您正在构建一个会遇到不可预测的新页面的代理、一个在供应商门户中导航的软件销售工具，或者一个访问冷门政府数据库的研究代理，Apify 的 Actor 模型就无法满足您的需求。您会从编排器中将 Apify 作为一个已知工具来调用；而 Browserbase 则是您代理的整个浏览器循环所依赖的底层环境。成本模型也有所不同：Apify 按 Actor 计算单元和代理带宽计费，没有专为代理用例构建的会话重放调试层。

Browserbase vs. Anchor Browser： Anchor 在理念上更接近 Browserbase：两者都提供可通过 CDP 访问的云端浏览器会话。Anchor 的差异化优势在于其“代理工具”端点抽象，您调用的不是原始的 CDP 访问，而是诸如“执行 Web 任务”或“导航至”等更高级别的端点。Anchor 通过显式脚本优先考虑确定性执行。在 2025 年比较会话创建速度的基准测试中，Anchor 的平均时间为 13.1 秒，而 Browserbase 为 11.9 秒，不过 Anchor 处理了 3/3 的并行免费层会话，而 Browserbase 则是按顺序运行它们。Anchor 明显落后的地方在于生态系统：Anchor 没有类似于 Stagehand 的产品，后者是一个拥有 22k+ stars 的开源 SDK，已被数百个开发团队作为标准。Browserbase 的监控可观测工具（会话后视频重放、DOM 快照）也更完善；Anchor 在执行期间提供实时视图，但不提供会话后重放。对于希望获得原始浏览器访问权限以及围绕它构建的、有主见且支持良好的框架的团队来说，Browserbase 是完美的答案。对于希望获得确定性的高级任务 API 而无需编写自己的代理逻辑的团队来说，Anchor 值得评估。

Stagehand 代理循环的实际情况

Stagehand 工作流介于两种故障模式之间：纯 Playwright（快速且便宜，但每次类名更改时都会崩溃）和纯 LLM 代理循环（灵活但昂贵、缓慢且非确定性）。Stagehand 的设计迫使您逐步选择所需的 AI 参与程度。

对于典型的 SDR 代理，开发人员会为稳定部分（导航到已知 URL，使用存储的凭据登录）编写确定性代码，并对变化的部分（点击联系表单按钮，该按钮在不同网站上的标签可能不同）使用 act()。extract() 从页面中提取结构化数据，而无需您编写在重新设计时会失效的 CSS 选择器。observe() 允许您在提交之前预览 Stagehand 将执行的操作，这对于构建测试覆盖率或记录意图非常有用。agent() 原语将多步目标完全交给底层的 LLM，适用于路径未知的探索性任务。

开发人员面临的实际压力是成本。除非元素已从先前的运行中缓存，否则每次调用 act() 或 extract() 都会触发一次 LLM 调用。在开发初期，在缓存填充之前，成本会不断累积。Hacker News 上的开发人员指出，对于具有稳定、已知页面结构的工作流，纯 Playwright 可能会更便宜。Stagehand v3 的自动元素缓存直接解决了重复工作流的这一问题，但新页面每次仍会产生 LLM 推理成本。

调试是 Browserbase 平台相对于本地 Playwright 的价值所在。当代理在意外的页面状态、插页式广告、区域锁定错误或代理未见过的 A/B 测试变体处失败时，会话重放允许您拖动到确切的帧，并了解模型推理时的 DOM 状态。如果没有这个功能，调试失败的代理运行就像是从堆栈跟踪中重建崩溃现场。有了它，您就有了视频记录。

Browserbase 是为谁构建的

对于需要大规模与实时 Web 交互的生产级 AI 代理构建团队来说，Browserbase 是默认选择。这涵盖了广泛的产品类别：AI 销售开发代表（11x 是其知名客户）、从没有 API 的网站聚合数据的研究代理、处理政府门户和遗留表单的 RPA 替代方案、监控定价和职位列表的竞争情报工具，以及在不断变化的 UI 中运行基于浏览器的验收测试的开发人员工具。

Stagehand SDK 特别适合那些已经熟悉 Playwright 并希望在其之上叠加 AI 原语，而不是完全切换框架的 TypeScript 和 Python 开发人员。学习曲线很平缓：现有的 Playwright 脚本可以继续工作；您只需在以前使用脆弱选择器的地方添加 act() 调用即可。

企业团队可以从监控可观测层获得附加价值。能够准确重放代理在每一步看到的内容和做出的决定，对于受监管行业的合规性、调试客户报告的故障以及随着时间的推移改进代理提示词都非常重要。有 HIPAA 要求的公司可以在 Scale 计划中获得 BAA 覆盖。

该平台也非常适合希望完全跳过基础设施构建的初创公司。大规模运行可靠的无头浏览器涉及代理轮换、验证码服务、浏览器指纹识别、会话状态管理和监控。Browserbase 将所有这些抽象为一个单一的 API 和一份月度账单。

Browserbase 不是什么

当您需要大量非常短的浏览器会话时，Browserbase 不是正确的选择。一分钟的最低计费标准意味着 10 秒的表单检查也会按整整一分钟计费。如果您的工作流涉及数百次快速、确定性的交互、价格检查、状态 ping、webhook 验证，那么这种成本模型对您是不利的。自托管的 Playwright 设置或更轻量级的抓取 API 会更便宜。

当目标网站具有已知、稳定的结构，并且 Apify 市场中已经存在预构建的 Actors 时，它也不能替代传统的网页抓取基础设施。如果您需要大规模获取 Amazon 产品数据、来自结构化导出的 LinkedIn 个人资料或 Google SERP 结果，专用抓取工具针对这些已知目标的定价会更高效。

寻求在运行时完全没有 LLM 参与的完全确定性脚本的团队应该寻找其他方案，或者应该使用带有纯 Playwright 代码的 Browserbase 基础设施，并完全跳过 Stagehand。该平台在没有 Stagehand 的情况下也能工作；浏览器访问是基础。但是 Stagehand 的运行时 LLM 架构是一个真正的权衡：它会为您调用 AI 的每一步增加成本和非确定性。对于认为这可以接受的团队来说，Stagehand 对 UI 变化的弹性是值得的。对于构建严格控制、高频工作流且每次运行的每一分钱都很重要的团队来说，考量标准则完全不同。

最后，身份验证流程仍然是一个真正的可靠性问题。对涉及 OTP 代码和电子邮件验证的重度登录工作流的测试表明，失败率约为 60%。Browserbase 的验证码破解功能可以很好地处理视觉验证码；而对时间敏感的基于电子邮件的 OTP 流程需要额外的编排，该平台目前并未原生提供。